home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / NOVELL / PKTDRV7.ZIP / 8259.NOT / text0001.txt < prev    next >
Encoding:
Text File  |  1990-07-26  |  3.7 KB  |  76 lines
  1. I seem to have run into a a real hardware bug in the Dell System 325
  2. Chips & Technologies 8259 clone interrupt controller.
  3.  
  4. Summary:
  5.  
  6. Sending this interrupt controller a Non Specific End of Interrupt
  7. (EOI) command causes it to reset all In Service Register (ISR) bits
  8. instead of only the most recent one with the highest priority.
  9.  
  10. Long Winded Explanation:
  11.  
  12. I had a serious bug with my high-performance Western Digital wd80x3
  13. packet driver.  Transmitting and receiving on it at high rates caused
  14. it to go west in many different ways.  After tearing my hair out for a
  15. while, I added logging code which logged all procedure entries and
  16. exits along with detailed chip status in a large ring.  I finally
  17. discovered that the impossible was happening.  During my packet copy
  18. routine (which can take > 1.5ms to copy a 1500 byte packet), my
  19. interrupt handler was being reentered and was trashing the stack.
  20. This "shouldn't happen" since I was not giving an EOI command to the
  21. interrupt controller until the very end of the interrupt handler.  The
  22. interrupt did however reenable processor and ethernet chip interrupts
  23. fairly early.
  24.  
  25. After tearing my hair out some more and checking my code thouroughly,
  26. I decided that I must be getting some other interrupt in the middle of
  27. my code somewhere.  I added some more logging code to record interrupt
  28. controller status, and changed my packet copy routine to enable
  29. processor interrupts AFTER the copy instead of before it.  Sure
  30. enough, at the point the bug hit, my log indicated that timer had
  31. fired and a timer interrupt was now pending.  Also, I had received a
  32. new packet, and the ethernet chip also had a new interrupt pending
  33. although it was still blocked because it already had an interrupt in
  34. service.  However, immediately after reenabling processor interrupts,
  35. my log indicated that my interrupt handler was reentered.  This
  36. indicated to me that the timer interrupt handler was somehow resetting
  37. not only its ISR bit but mine also.
  38.  
  39. After disassembling the timer interrupt handler, I determined that the
  40. only thing it was doing was sending a Non Specific EOI to the primary
  41. interrupt controller (using mov al,20h; out 20h,al).  To make my case
  42. for a hardware bug even stronger, I next coded my own timer interrupt
  43. handler.  Just before and just after the mov/out instructions, I made
  44. log entries.  Sure enough, while my log showed the ISR register
  45. reading 21h (IR5 and IR0 in service) just before the EOI was sent, it
  46. read 0 just after.  I then changed the code to use a specific EOI
  47. instruction to reset the timer interrupt instead of a non specific
  48. EOI.  The problem went away!
  49.  
  50. Finally, I tested the code with a non specific EOI on a stock IBM
  51. PC/AT with a real Intel 8259.  It didn't exhibit the problem.
  52.  
  53. Since I can't change the real timer interrupt handler (its in BIOS), I
  54. had to use a different workaround.  Just before reenabling processor
  55. interrupts, I now disable further ethernet device interrupts by
  56. setting its Interrupt Mask Register (IMR) bit.  At the end of
  57. interrupt handler, I reset the bit.  This insures that I can't get
  58. further device interrupts even if the timer interrupt clears my ISR bit.
  59.  
  60. Synopsis:
  61.  
  62. If you write high performance drivers where:
  63. 1.  The interrupt handler runs with other interrupts enabled at the
  64. processor and at the interrupt controller,
  65. 2.  The interrupt handler reenables interrupts at the device while 1.
  66. is true and further device interrupts are possible before the
  67. interrupt handler again disables interrupts and returns,
  68. 3.  You want to the driver to work in clones with C&T chips
  69.  
  70. Then, you better use a technique like the one I use to guarantee that
  71. you can't get reentrant interrupts.
  72.  
  73. Drew
  74.  
  75.  
  76.