Bug 35792 - irq 18/23: nobody cared just after resume from hibernate
Summary: irq 18/23: nobody cared just after resume from hibernate
Status: RESOLVED OBSOLETE
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2011-05-25 07:34 UTC by Dmitry Nezhevenko
Modified: 2012-08-24 12:39 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.39
Subsystem:
Regression: No
Bisected commit-id:


Attachments
2.6.39 dmesg after resume (73.57 KB, text/plain)
2011-05-25 07:34 UTC, Dmitry Nezhevenko
Details

Description Dmitry Nezhevenko 2011-05-25 07:34:54 UTC
Created attachment 59332 [details]
2.6.39 dmesg after resume

Just after resuming from hibernate I'm getting followed:

[  195.936053] irq 18: nobody cared (try booting with the "irqpoll" option)
[  195.936104] Pid: 0, comm: swapper Not tainted 2.6.39 #1
[  195.936142] Call Trace:
[  195.936162]  <IRQ>  [<ffffffff81314abd>] ? __report_bad_irq+0x38/0xa0
[  195.936221]  [<ffffffff8108ad44>] ? note_interrupt+0x15f/0x1d3
[  195.938076]  [<ffffffff81089711>] ? handle_irq_event_percpu+0x16d/0x18b
[  195.939916]  [<ffffffff8100dcb1>] ? paravirt_read_tsc+0x5/0x8
[  195.940051]  [<ffffffff81061550>] ? timekeeping_get_ns+0xe/0x2e
[  195.940051]  [<ffffffff81089763>] ? handle_irq_event+0x34/0x55
[  195.940051]  [<ffffffff810666f5>] ? arch_local_irq_save+0x11/0x17
[  195.940051]  [<ffffffff8108b372>] ? handle_fasteoi_irq+0x79/0x9b
[  195.940051]  [<ffffffff8100a89d>] ? handle_irq+0x1d/0x21
[  195.940051]  [<ffffffff8100a5dd>] ? do_IRQ+0x42/0x98
[  195.940051]  [<ffffffff8131a893>] ? common_interrupt+0x13/0x13
[  195.940051]  <EOI>  [<ffffffff810666ce>] ? arch_local_irq_restore+0x2/0x8
[  195.940051]  [<ffffffff81008237>] ? cpu_idle+0x6e/0xd7
[  195.940051]  [<ffffffff8169db37>] ? start_kernel+0x3b9/0x3c4
[  195.940051]  [<ffffffff8169d140>] ? early_idt_handlers+0x140/0x140
[  195.940051]  [<ffffffff8169d3c4>] ? x86_64_start_kernel+0x104/0x111
[  195.940051] handlers:
[  195.940051] [<ffffffffa00e5bcb>] (usb_hcd_irq+0x0/0x7e [usbcore])
[  195.940051] Disabling IRQ #18


[  196.634522] irq 23: nobody cared (try booting with the "irqpoll" option)
[  196.636234] Pid: 0, comm: swapper Not tainted 2.6.39 #1
[  196.637965] Call Trace:
[  196.638520]  <IRQ>  [<ffffffff81314abd>] ? __report_bad_irq+0x38/0xa0
[  196.638520]  [<ffffffff8108ad44>] ? note_interrupt+0x15f/0x1d3
[  196.638520]  [<ffffffff81089711>] ? handle_irq_event_percpu+0x16d/0x18b
[  196.638520]  [<ffffffff8100dcb1>] ? paravirt_read_tsc+0x5/0x8
[  196.638520]  [<ffffffff81061550>] ? timekeeping_get_ns+0xe/0x2e
[  196.638520]  [<ffffffff81089763>] ? handle_irq_event+0x34/0x55
[  196.638520]  [<ffffffff8105f440>] ? sched_clock_idle_wakeup_event+0xf/0x17
[  196.638520]  [<ffffffff8108b372>] ? handle_fasteoi_irq+0x79/0x9b
[  196.638520]  [<ffffffff8100a89d>] ? handle_irq+0x1d/0x21
[  196.638520]  [<ffffffff8100a5dd>] ? do_IRQ+0x42/0x98
[  196.638520]  [<ffffffff8131a893>] ? common_interrupt+0x13/0x13
[  196.638520]  <EOI>  [<ffffffffa025d3af>] ? arch_local_irq_enable+0x7/0x8 [processor]
[  196.638520]  [<ffffffffa025dcb8>] ? acpi_idle_enter_c1+0x86/0xa2 [processor]
[  196.638520]  [<ffffffff8124841e>] ? cpuidle_idle_call+0xe8/0x16f
[  196.638520]  [<ffffffff81008266>] ? cpu_idle+0x9d/0xd7
[  196.638520]  [<ffffffff8169db37>] ? start_kernel+0x3b9/0x3c4
[  196.638520]  [<ffffffff8169d140>] ? early_idt_handlers+0x140/0x140
[  196.638520]  [<ffffffff8169d3c4>] ? x86_64_start_kernel+0x104/0x111
[  196.638520] handlers:
[  196.638520] [<ffffffffa00e5bcb>] (usb_hcd_irq+0x0/0x7e [usbcore])
[  196.638520] Disabling IRQ #23
[  201.172048] pm_op(): usb_dev_restore+0x0/0xd [usbcore] returns -110

It's possible to continue work, however machine will freeze on reboot. this is probably regression or difference between 32 vs 64bit kernel.

s2ram works

Hardware: Asus F6A laptop.

dion@laptop:~% cat /proc/interrupts 
           CPU0       CPU1       
  0:     337241      15178   IO-APIC-edge      timer
  1:       3107         54   IO-APIC-edge      i8042
  8:          0          1   IO-APIC-edge      rtc0
  9:       2170        476   IO-APIC-fasteoi   acpi
 12:      48554        455   IO-APIC-edge      i8042
 18:     100002          0   IO-APIC-fasteoi   ehci_hcd:usb1
 19:         64         63   IO-APIC-fasteoi 
 23:     198826       1176   IO-APIC-fasteoi   ehci_hcd:usb2
 40:          0          0   PCI-MSI-edge      PCIe PME
 41:          0          0   PCI-MSI-edge      PCIe PME
 42:          0          0   PCI-MSI-edge      PCIe PME
 43:          0          0   PCI-MSI-edge      PCIe PME
 45:       6557      16914   PCI-MSI-edge      i915@pci:0000:00:02.0
 46:      20882       4907   PCI-MSI-edge      ahci
 47:      16962          0   PCI-MSI-edge      iwlagn
 48:         74         97   PCI-MSI-edge      hda_intel
NMI:          6          3   Non-maskable interrupts
LOC:      35045     167993   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          5          3   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:       2296       2201   Rescheduling interrupts
CAL:        624        541   Function call interrupts
TLB:       1266       1232   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:          5          5   Machine check polls
ERR:          0
MIS:          0
Comment 1 Rafael J. Wysocki 2011-05-25 20:23:09 UTC
Well, I'm certainly unable to reproduce this issue on three different x86-64
systems.

What hardware is this?  Does 2.6.38 work correctly?
Comment 2 Dmitry Nezhevenko 2011-05-26 12:44:48 UTC
Hi,

I've tested 2.6.38 and then 2.6.37 kernels. Basically both provides same behavior. (2.6.37 also complains about ReiserFS corruption just after resume).

However I was unable to reproduce it on minimal rootfs. So after investigation I've found that the cause is unloaded uhci_hcd module just before hibernate.

So followed test case fails for me on 2.6.37 - 2.6.39 (not sure about earilier versions, can retest if needed);:

- boot
- rmmod uhci_hcd
- hibernate
- resume

I don't know, is it expected behavior. But I think that it's NOT. I think that kernel should always forbid suspending/hibernating if it'll definitely crash on resume.

I can retest 32bit kernels if required.
Comment 3 Dmitry Nezhevenko 2011-05-26 12:45:39 UTC
PS. Hardware: It's Intel-based Core2DUO laptop on ICH9 chipset.

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
02:00.0 Network controller: Intel Corporation WiFi Link 5100
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Comment 4 Rafael J. Wysocki 2011-05-26 21:47:36 UTC
I wonder how the kernel is supposed to know it will crash in advance?
Never mind.

At this point I have no idea what the problem may be.  It looks like a
problem with interrupts, though.

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