home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / ibm / pc / hardware / 23726 < prev    next >
Encoding:
Text File  |  1992-09-08  |  3.1 KB  |  67 lines
  1. Newsgroups: comp.sys.ibm.pc.hardware
  2. Path: sparky!uunet!utcsri!geac!itcyyz!jhs
  3. From: jhs@ipsa.reuter.com (Henri Schueler)
  4. Subject: IRQ8-15 (was IRQ2=trouble?)
  5. Message-ID: <1992Sep8.191232.7073@ipsa.reuter.com>
  6. Organization: H&h Software, Toronto, Ontario
  7. Date: Tue, 8 Sep 1992 19:12:32 GMT
  8. Lines: 57
  9.  
  10. In a recent article steveq@swifty.dap.CSIRO.AU (Stephen Quigg) writes:
  11.  
  12. > In the AT/386/486 etc, there is a second 8259A 
  13. >interrupt controller, called a slave, while the first one is configured as
  14. >a master. The master handles IRQ0 through IRQ7 and the slave handles IRQ8 
  15. >through IRQ15. Simple so far. Now; the IRQ_OUT from the master goes to the
  16. >processor, and the IRQ_OUT from the slave goes to the IRQ2 pin of the master.
  17. >(ie IRQ8 through IRQ15 is cascaded through IRQ2). When the master receives
  18. >an interrupt acknowledge for IRQ2, instead of putting an interrupt vector
  19. >on the bus, it tells the slave to output a vector. 
  20.  
  21. I am familiar with this, but I have a question about the relationship
  22. between the two PICs, specifically with respect to priority handling.
  23.  
  24. In a single PIC situation (e.g. the XT), and with the normal IBM PC
  25. configuration of the PIC, the IRQs have a strict priority, and use
  26. the non-specific EOI to signal end-of-interrupt.  Once the PIC has
  27. signaled an IRQ, it won't signal another interrupt of the same or
  28. lesser priority until that IRQ is 'ended'.  (sorry for being boring).
  29.  
  30. In the two PIC case, when the primary has received an interrupt
  31. request from the secondary (i.e. on IRQ2) and has signaled this to
  32. the CPU, what happens when the primary gets another request from the
  33. secondary before the interrupt has 'ended'? The primary must assume
  34. this interrupt is of higher priority (else why would the secondary
  35. signal it), so I assume the primary will signal the CPU.
  36.  
  37. Can anyone comment if I am right in making this assumption?
  38.  
  39. If no, then a device on IRQ15 (once it generates an interrupt) will be
  40. blocking a device on IRQ8-14. That doesn't sound right.
  41.  
  42. If yes, then I see a potential problem with the DOS/BIOS software
  43. re-direction of IRQ9 to IRQ2. In my Phoenix BIOS, the secondary PIC
  44. is EOI'd, and then IRQ2 (INT 0Ah) is invoked.  At this point the
  45. device that thinks it is hanging off IRQ2 goes merrily about its
  46. business and at some point EOI's the primary.  
  47.  
  48. The danger is this: another IRQ9 (=2) can be invoked, and if the ISR
  49. isn't re-entrant, then a mess might ensue.  If so, then perhaps this
  50. is a reason for warning users to avoid the IRQ2 in at ISA bus.
  51.  
  52. Of course if the ISR actually hangs off IRQ9 (i.e. INT 71h), then the
  53. ISR will be expected to send an EOI to both, and it can protect
  54. itself against being re-entered (assuming it wants to). (But checking
  55. mouse.com from Windows, I see that it favours INT 0A, not INT 71.)
  56.  
  57. If the DOS/BIOS redirector at INT 71 were to invoke INT 0A, and send
  58. an EOI to the secondary *afterwards* then other problems might ensue
  59. (e.g. if the INT 0A handler were to wait as the keyboard handler does
  60. in a PAUSE situation), but overall it seems like a safer approach
  61. (then EOI'ing first).
  62.  
  63. /jhs
  64.  
  65. -- 
  66. J. Henri Schueler, H&h Software, Toronto    +1 416 698 9075 
  67.