On 2012-09-11 02:49, Maciej W. Rozycki wrote: > On Sun, 9 Sep 2012, Matthew Ogilvie wrote: > >> This bug manifested itself when the guest was Microport UNIX >> System V/386 v2.1 (ca. 1987), because it would sometimes mask >> off IRQ14 in the slave IMR after it had already been asserted. >> The master would still try to deliver an interrupt even though >> IRQ2 had dropped again, resulting in a spurious interupt >> (IRQ15) and a panicked UNIX kernel. > > That is quite weird actually -- from my experience the spurious vector is > never sent from a slave (quite understandably -- since the interrupt is > gone and no other is pending, the master has no reason to select a slave > to supply a vector and therefore supplies the spurious vector itself) and > therefore a spurious IRQ7 is always issued regardless of whether the > discarded request came from a slave or from the master. As we do not clear IRQ14 in IRR of the slave nor do we clear IRQ2 of the master, the master has a good reason to ask the slave for the vector. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
