http://bugzilla.kernel.org/show_bug.cgi?id=1752
------- Additional Comments From [EMAIL PROTECTED] 2006-01-29 00:15 ------- PIC-mode bits look normal too. Same exercise: print_PIC() from acpi_irq() when it finds work to do. The 1st one is presumably a real interrupt: printing PIC contents ... PIC IMR: 2678 ... PIC IRR: 0000 ... PIC ISR: 0000 ... PIC ELCR: 0a80 The 6 in IMR 2678 means bit 9 1, so IRQ9 is masked = DISABLED -- which makes sense since we're printing this from its handler... ELCR a80 has bit 9 is set meaning IRQ9 is LEVEL sensitive, just like IRQ 7 and 11 -- as expected. Later when invoked via irqpoll... printing PIC contents ... PIC IMR: 2479 ... PIC IRR: 0000 ... PIC ISR: 0000 ... PIC ELCR: 0a80 The 4 in IMR means that bit 9 is now CLEAR, which means that IRQ9 is indeed UNMASKED and ready for action -- So in both the PIC and IOAPIC cases, the interrupt controller sits ready for the SCI, but the input pin is not being driven again after its first invocation. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
