Latest working kernel version: N/A Earliest failing kernel version: 2.6.20 (I have not been able to test earlier versions) Distribution: Debian Hardware Environment: Thinkpad R61i, Intel Pentium Dual Core Software Environment: Problem Description: According to /proc/interrupts, one of the cpu cores, CPU1, stops receiving interrupts after resuming from suspend to ram or disk. LOC, RES and CAL are an exception since their counters still increase after resume. Before doing any suspend both cpu cores gets about the same number of interrupts. I have tested random versions from 2.6.20 to 2.6.27-rc2 with no difference. Example output from /proc/interrupts where you can see that there are much more interrupts for CPU0 than for CPU1 since they have stopped counting: CPU0 CPU1 0: 241085 65684 IO-APIC-edge timer 1: 5052 413 IO-APIC-edge i8042 8: 4 0 IO-APIC-edge rtc0 9: 6878 1904 IO-APIC-fasteoi acpi 12: 85357 10445 IO-APIC-edge i8042 14: 28386 15041 IO-APIC-edge ata_piix 15: 0 0 IO-APIC-edge ata_piix 16: 0 0 IO-APIC-fasteoi uhci_hcd:usb4, yenta, i915@pci:0000:00:02.0 17: 26948 58 IO-APIC-fasteoi uhci_hcd:usb5, HDA Intel, firewire_ohci 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb6 19: 0 0 IO-APIC-fasteoi ehci_hcd:usb7 20: 164668 41821 IO-APIC-fasteoi uhci_hcd:usb1 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2 22: 6 1 IO-APIC-fasteoi ehci_hcd:usb3 217: 14340 573 PCI-MSI-edge eth0 218: 31788 22136 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 79314 155455 Local timer interrupts RES: 25939 48970 Rescheduling interrupts CAL: 18086 15730 function call interrupts TLB: 95 104 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 Steps to reproduce: Suspend to ram or disk, and resume.
Created attachment 17152 [details] acpidump
Created attachment 17153 [details] dmesg when suspending to disk
Created attachment 17154 [details] lspci -vv
can you manually move one interrupt to cpu1? like: echo "2" > /proc/irq/14/smp_affinity if you can see the interrupt increment in irq 14, then this isn't a bug.
I had it in mind that this might not been a bug, but it seemed strange to get this change after a resume. Moving the interrupt to cpu1 worked, so sorry for sending in a bogus report.