http://bugzilla.kernel.org/show_bug.cgi?id=11832
--- Comment #28 from M. Vefa Bicakci <bic...@superonline.com> 2009-03-30 01:31:13 --- Hello, I apologize for not responding earlier; I wanted to gather more data before posting a message. I took 2.6.24's source and reduced its spurious interrupt limit to 10 in "kernel/irq/spurious.c". I called this 2.6.24-suspect. Testing this kernel was not helpful because after a certain amount of uptime and with a certain pattern of network activity, iwl3945 started to print error messages which are appended to this message. After a few "rmmod iwl3945" and "modprobe iwl3945" cycles, I got crashes. This occurred at least three times. In addition to this, I got the following "nobody cared" message one time while testing 2.6.24-suspect: === 8< === irq 17: nobody cared (try booting with the "irqpoll" option) Pid: 29141, comm: Xorg Not tainted 2.6.24-suspect #1 [<c0157ee6>] __report_bad_irq+0x36/0x75 [<c0158139>] note_interrupt+0x214/0x273 [<c01577e9>] handle_IRQ_event+0x23/0x51 [<c01586af>] handle_fasteoi_irq+0x85/0xa5 [<c010672f>] do_IRQ+0x55/0x6e [<c0184a4f>] sys_ioctl+0x45/0x5e [<c010497f>] common_interrupt+0x23/0x28 ======================= handlers: [<f8882d7a>] (usb_hcd_irq+0x0/0x56 [usbcore]) [<f8ddccfd>] (i915_driver_irq_handler+0x0/0x18e [i915]) Disabling IRQ #17 === >8 === However, this message occurred when I was trying CompizFusion - I was switching it on and off. To be honest, I don't know if this "nobody cared" message was printed because of the same problem as the one I had when I opened this bug report, or because 10 is a really low limit. The longest uptime I was able to achieve with 2.6.24-suspect before I got crashes was 4 days. Because wireless is essential for me, I didn't continue my tests with 2.6.24-suspect. I then used Sidux's 2.6.28.7 based kernel, unmodified. After an uptime of 15 days without any problems, I decided to test vanilla 2.6.28.7 with a low spurious interrupt limit. This time I used 99 as the spurious interrupt limit. I called this kernel 2.6.28.7-spurious. I am still running this kernel, and my current uptime is 15 days. So, in other words, I haven't been able to reproduce this problem with 2.6.28.7. (Yet?) However, I am going to try 2.6.24.7 and 2.6.29 with 99 as the spurious interrupt limit, so please do not close this bug report yet. Any suggestions on which of these two versions I should test next, how much time I should wait before deciding that I cannot reproduce this problem, and what would be a good spurious interrupt limit (instead of 10 or 99) ? There is one more important thing which happened: Before testing 2.6.24-suspect, I upgraded my laptop's BIOS. I can downgrade the BIOS if it becomes necessary to confirm the role of the BIOS version in this problem. Once again, sorry for my late response. Thank you, M. Vefa Bicakci ######################################################################## Here's the message iwl3945 prints: === 8< === Error sending REPLY_SCAN_ABORT_CMD: time out after 500ms. Error sending REPLY_RXON: time out after 500ms. === >8 === -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. ------------------------------------------------------------------------------ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
