15:58:28fitzsimthe interrupt controller (i8259) delivers an interrupt to the CPU, but it (the controller) forgot which interrupt needed to be delivered
15:59:35fitzsimI'm paraphrasing/clarifying for myself, something that you'd written before
16:01:25fitzsimanyway, I'll start with the dmesg on my next break
16:05:42froggeyin this case what's being reported as IRQ 7 isn't a real IRQ 7. the device attached to IRQ 7 didn't do anything and is uninvolved
16:07:19froggeyin fact, at this point IRQ 7 is masked at the PIC, so even if there was a real IRQ 7 being generated the PIC wouldn't interrupt the CPU
16:09:36froggeywhat I think is happening is that one of the IRQ lines (probably IRQ 0, as it's the only one unmasked during our tests) is going high, causing the PIC to signal an interrut
16:10:25froggeywhen the CPU gets around to handle it, it asks the PIC which interrupt it is, and the PIC determines this by looking at the active interrupt lines (after masking, I think)
16:10:40froggeyand sending the highest priority one back to the CPU
16:11:00froggeyif there are no active interrupt lines, the PIC sends back IRQ 7
16:13:25froggeybut I have no idea how this could be happening. this is how it all worked on the original IBM PC, but modern PCs only emulate this behaviour. they don't have real i8259 chips