Bug 11292 - CPU core stops receiving interrupts after resuming from suspend
CPU core stops receiving interrupts after resuming from suspend
Status: CLOSED INVALID
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
All Linux
: P1 normal
Assigned To: acpi_power-sleep-wake
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2008-08-09 08:10 UTC by Michael Brennan
Modified: 2008-08-14 04:41 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6
Tree: Mainline
Regression: Yes


Attachments
acpidump (298.15 KB, application/octet-stream)
2008-08-09 08:14 UTC, Michael Brennan
Details
dmesg when suspending to disk (30.56 KB, application/octet-stream)
2008-08-09 08:17 UTC, Michael Brennan
Details
lspci -vv (16.70 KB, application/octet-stream)
2008-08-09 08:17 UTC, Michael Brennan
Details

Description Michael Brennan 2008-08-09 08:10:56 UTC
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.
Comment 1 Michael Brennan 2008-08-09 08:14:09 UTC
Created attachment 17152 [details]
acpidump
Comment 2 Michael Brennan 2008-08-09 08:17:00 UTC
Created attachment 17153 [details]
dmesg when suspending to disk
Comment 3 Michael Brennan 2008-08-09 08:17:43 UTC
Created attachment 17154 [details]
lspci -vv
Comment 4 Shaohua 2008-08-12 23:46:20 UTC
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.
Comment 5 Michael Brennan 2008-08-14 03:47:49 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.