Bug 11665
Summary: | power button stops working after suspend (irq 9: nobody cared) | ||
---|---|---|---|
Product: | ACPI | Reporter: | Andrej Shadura (andrew) |
Component: | Power-Sleep-Wake | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, shaohua.li |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
kernel log
acpidump output lspci -vvvxxx before suspend lspci -vvvxxx after suspend |
Description
Andrej Shadura
2008-09-28 14:23:49 UTC
Created attachment 18098 [details]
kernel log
Suspend starts at 23:54:41 [ 59.373748].
P.S. Problem first appeared when I installed new 2.6.24 kernel from "etch", I used 2.6.17 before, and it worked well. Will you please attach the output of acpidump? It will be great if you can attach the output of lspci -vvvxxx after and before suspend. Thanks. Ok, I will do this. Btw, the same problem occurs with 2.6.26 kernel from lenny ("2.6.26-1-686 #1 SMP Wed Sep 10 16:46:13 UTC 2008") Created attachment 18159 [details]
acpidump output
Created attachment 18160 [details]
lspci -vvvxxx before suspend
Created attachment 18161 [details]
lspci -vvvxxx after suspend
Will you please try the boot option of "idle=poll" on the latest kernel and see whether the problem still exists? Thanks. Are you really sure option should be "idle=poll"? I tried 2.6.26-1-686 (latest in lenny), with idle=poll option, and still the same result. Will you please the following patch and see whether the problem still exists? >http://marc.info/?l=linux-kernel&m=122307130419753&w=2 Just compiled 2.6.26-1-686 from Debian with that patch. No visible result, it is still here :-( -- WBR, Andrew Sorry for the late response. Will you please try the debug patch in in http://bugzilla.kernel.org/show_bug.cgi?id=11255#C49 and see whether the problem still exists? Thanks. ping andrew Hi As the box can work on the kernel of 2.6.17, will you please use git-bisect to identify which commit introduces the regression? Will you please not load the device driver for the following devices and see whether the problem still exists? a. ethernet(02.00.0) b. Multimedia audio controller(02.09.0) c. Game port(02.09.1) Please disable the above three devices in BIOS. d. USB device (by add the boot option of "nousb") Thanks. Hello. Sorry for not answering. I have very little free time, but I will try both in next week, I hope. -- WBR, Andrew Ping Andrew again. :) How about the boot option noapic? I want to check if there is related with ioapic. please apply the patch in bug #11268 comment #18 and #19 and attach the dmesg output with these two patches ping Andrew pong sorry, I'm too busy will try to apply these patches, but can guarantee nothing about time, sorry again too much work, no time to patch/reboot just built kernel with http://bugzilla.kernel.org/show_bug.cgi?id=11665#c12 patch. rebooting, will post dmesg if it wouldn't help just made 3 tests. 1st. Kernel with patch from comment #12 no visible result, dmesg output is the same as without patch 2nd. The same kernel, noapic option added again, no visible result 3rd. The same kernel, irqpoll option added, noapic removed system boots, suspends, but doesn't wake - it hangs after videobios initialized. Will try to test another patched -- WBR, Andrew please attach the output of "cat /proc/interrupt" Hello. Sorry for late reply. This is done just after boot: [root#pc-linux:~]: cat /proc/interrupts CPU0 0: 98 IO-APIC-edge timer 1: 12453 IO-APIC-edge i8042 3: 63 IO-APIC-edge lirc_serial 4: 6 IO-APIC-edge 6: 5 IO-APIC-edge floppy 7: 485890 IO-APIC-edge parport0 8: 9 IO-APIC-edge rtc0 9: 0 IO-APIC-fasteoi acpi 12: 85839 IO-APIC-edge i8042 14: 0 IO-APIC-edge ide0 15: 86338 IO-APIC-edge ide1 16: 555788 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb4, nvidia 18: 48953 IO-APIC-fasteoi uhci_hcd:usb3, ata_piix 19: 0 IO-APIC-fasteoi uhci_hcd:usb2 20: 50243 IO-APIC-fasteoi eth0 23: 442186 IO-APIC-fasteoi ehci_hcd:usb5, EMU10K1 NMI: 0 Non-maskable interrupts LOC: 1296844 Local timer interrupts RES: 0 Rescheduling interrupts CAL: 0 function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 0 MIS: 0 [root#pc-linux:~]: suspend.now.ram Stopping lirc daemon: lircmd lircd. Switching from vt7 to vt1 Calling save_state Allocated buffer at 0x2010 (base is 0x0) ES: 0x0201 EBX: 0x0000 Calling restore_state_from Function not supported? switching back to vt7 Starting lirc daemon: lircd. Setting drive speed of device /dev/cdrom to 1.. OK [root#pc-linux:~]: cat /proc/interrupts CPU0 0: 98 IO-APIC-edge timer 1: 12525 IO-APIC-edge i8042 3: 63 IO-APIC-edge 4: 6 IO-APIC-edge 6: 5 IO-APIC-edge floppy 7: 485890 IO-APIC-edge parport0 8: 9 IO-APIC-edge rtc0 9: 100001 IO-APIC-fasteoi acpi 12: 93920 IO-APIC-edge i8042 14: 0 IO-APIC-edge ide0 15: 87486 IO-APIC-edge ide1 16: 564367 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb4, nvidia 18: 53701 IO-APIC-fasteoi uhci_hcd:usb3, ata_piix 19: 0 IO-APIC-fasteoi uhci_hcd:usb2 20: 51401 IO-APIC-fasteoi eth0 23: 448184 IO-APIC-fasteoi ehci_hcd:usb5, EMU10K1 NMI: 0 Non-maskable interrupts LOC: 1320339 Local timer interrupts RES: 0 Rescheduling interrupts CAL: 0 function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 0 MIS: 0 P.S. About nvidia: there are no visible changes without nvidia driver, all symptoms are the same. Sorry for the late response. Will you please try the 2.6.28.3 stable kernel and see whether the issue still exists? If it still exists, please attach the following output before suspned/resume. > grep . /sys/firmware/acpi/interrupts/* thanks. close this bug as there is no response from the bug reporter for more than 2 months. please reopen it if the bug still exists in the latest upstream kernel and you can provide the info requested in comment #26. Just compiled 2.6.28.3. It works perfectly! The only problem with it is that I cannot compile some additional kernel modules (i.e. lirc-related), but I hope I'll fix this. Thank you very much. |