home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.92 / text0059.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  1.9 KB  |  41 lines
  1. Dear Folks,
  2.  
  3.     One of the modifications that we're working on is the ability  
  4. to use Macintosh formatted floppies directly from Executor (rather  
  5. than having to go though HFS_XFer).  However, we ran into problems  
  6. when we began running programs directly off of floppies.  A close  
  7. inspection showed that the fast a-line dispatching kernel mods were  
  8. corrupting the user stack pointer.
  9.  
  10.     We now have a new version of "ardimods.s", which appears to  
  11. fix the bug.  This bug appears to have the side effect of sometimes  
  12. crashing Executor when Executor first starts up and when Executor has  
  13. just printed something. I have placed a copy of our new "ardimods.s"  
  14. in:
  15.  
  16. unmvax.cs.unm.edu:/usr/spool/ftp/pub/ardi/Source/ardimods.s
  17.  
  18.     I will be happy to mail it to anyone who doesn't have access  
  19. to ftp (it's only 126 lines long).  The new mods will automatically  
  20. be part of Exector-MSW V1.2 which has been delayed a bit by this bug  
  21. and some display postscript bugs we've bumped into.
  22.  
  23. TECHNICAL DESCRIPTION THAT YOU DON'T NEED TO READ FOLLOWS:
  24.  
  25.     I suspect what was happening is that either the copyin or the  
  26. copyout was causing a page-fault and the page-fault handling code  
  27. expected us to have saved more state than we did; because the problem  
  28. appears to be limited to unexpected crashes of Executor (most likely  
  29. when Executor is just starting, or just after you've printed a  
  30. document), it may be as simple as the page-fault handling code  
  31. assuming that it can manipulate the user stack pointer with impunity,  
  32. since it is saved at the beginning of normal traps and restored at  
  33. the end of normal traps (our a-line dispatching code deliberately  
  34. tries to save as little state as possible, to keep a-line traps  
  35. dispatching as quickly as possible; the problem is that since we  
  36. don't have the source to mach, it's hard to tell what the minimum  
  37. amount of state to store is).
  38.  
  39.     --Cliff
  40.  
  41.