537943 – irq 19: nobody cared after suspend; Disabling IRQ #19

Bug 537943 - irq 19: nobody cared after suspend; Disabling IRQ #19

Summary: irq 19: nobody cared after suspend; Disabling IRQ #19

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Fedora
Classification:	Fedora
Component:	kernel
Sub Component:
Version:	12
Hardware:	All
OS:	Linux
Priority:	low
Severity:	medium
Target Milestone:	---
Assignee:	John W. Linville
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2009-11-16 21:07 UTC by Stefan Assmann
Modified:	2013-01-10 08:04 UTC (History)
CC List:	9 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2010-03-08 20:36:51 UTC
Type:	---
Embargoed:
Dependent Products:

Attachments	(Terms of Use)
/var/log/messages after resume (18.07 KB, text/plain) 2009-11-16 21:07 UTC, Stefan Assmann	no flags	Details
View All

Description Stefan Assmann 2009-11-16 21:07:47 UTC

Created attachment 369785 [details]
/var/log/messages after resume

Description of problem:
After returning from suspend the following shows up:
Nov 16 21:55:30 localhost kernel: irq 19: nobody cared (try booting with the "irqpoll" option)
Nov 16 21:55:30 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.31.5-127.fc12.i686.PAE #1
Nov 16 21:55:30 localhost kernel: Call Trace:
Nov 16 21:55:30 localhost kernel: [<c047c235>] __report_bad_irq+0x33/0x74
Nov 16 21:55:30 localhost kernel: [<c047c370>] note_interrupt+0xfa/0x152
Nov 16 21:55:30 localhost kernel: [<c047c8e8>] handle_fasteoi_irq+0x83/0xa2
Nov 16 21:55:30 localhost kernel: [<c040b195>] handle_irq+0x40/0x4b
Nov 16 21:55:30 localhost kernel: [<c040a959>] do_IRQ+0x46/0x9a
Nov 16 21:55:30 localhost kernel: [<c0409670>] common_interrupt+0x30/0x38
Nov 16 21:55:30 localhost kernel: [<c042007b>] ? machine_kexec_cleanup+0x25/0x2b
Nov 16 21:55:30 localhost kernel: [<c04300e0>] ? dequeue_entity+0xfa/0x1fc
Nov 16 21:55:30 localhost kernel: [<c045bdad>] ? tick_nohz_stop_sched_tick+0x309/0x315
Nov 16 21:55:30 localhost kernel: [<c04080fd>] cpu_idle+0x74/0xaf
Nov 16 21:55:30 localhost kernel: [<c0765784>] rest_init+0x58/0x5a
Nov 16 21:55:30 localhost kernel: [<c09a78c3>] start_kernel+0x32b/0x330
Nov 16 21:55:30 localhost kernel: [<c09a7081>] i386_start_kernel+0x70/0x77
Nov 16 21:55:30 localhost kernel: handlers:
Nov 16 21:55:30 localhost kernel: [<c067f6ee>] (usb_hcd_irq+0x0/0x6f)
Nov 16 21:55:30 localhost kernel: [<f8b0630c>] (ath_isr+0x0/0x130 [ath9k])
Nov 16 21:55:30 localhost kernel: Disabling IRQ #19

did not happen on F11

Version-Release number of selected component (if applicable):
kernel-PAE-2.6.31.5-127.fc12.i686

How reproducible:
always

Steps to Reproduce:
1. suspend

Actual results:
Disabling IRQ #19
atheros wireless seems very flacky, often drops connection

Additional info:
lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac] (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02)
01:00.0 Network controller [0280]: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) [168c:002a] (rev 01)
03:00.0 Ethernet controller [0200]: Attansic Technology Corp. Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller [1969:1026] (rev b0)

cat /proc/interrupts 
            CPU0       CPU1       
   0:     196702          0   IO-APIC-edge      timer
   1:       2928        486   IO-APIC-edge      i8042
   8:          1          0   IO-APIC-edge      rtc0
   9:       2135        363   IO-APIC-fasteoi   acpi
  12:      17442          0   IO-APIC-edge      i8042
  14:      25454          0   IO-APIC-edge      ata_piix
  15:          0          0   IO-APIC-edge      ata_piix
  16:       2602        819   IO-APIC-fasteoi   uhci_hcd:usb5, i915@pci:0000:00:02.0, HDA Intel
  18:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
  19:     200001          0   IO-APIC-fasteoi   uhci_hcd:usb3, ath
  23:         37          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
  27:          2          0   PCI-MSI-edge      eth0
 NMI:          0          0   Non-maskable interrupts
 LOC:     147304     220947   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 CNT:          0          0   Performance counter interrupts
 PND:          0          0   Performance pending work
 RES:      20584      29880   Rescheduling interrupts
 CAL:         25         82   Function call interrupts
 TLB:        291        686   TLB shootdowns
 TRM:          0          0   Thermal event interrupts
 THR:          0          0   Threshold APIC interrupts
 MCE:          0          0   Machine check exceptions
 MCP:          3          3   Machine check polls
 ERR:          0
 MIS:          0

Comment 1 Matthew Garrett 2009-11-16 21:21:04 UTC

Does the atheros work correctly if you don't try a suspend cycle?

Comment 2 Stefan Assmann 2009-11-17 07:33:29 UTC

I've justed tested that and the connection drops appear without the suspend cycle as well. So it does not seem to be related directly.

Comment 3 Peter Svensson 2009-11-18 19:55:39 UTC

I get the same error message after suspend on my ASUS S101 netbook. After resume the root filesystem which is connected via USB is not available. 

It worked fine with F11.

Any more information you want me to collect?

Comment 4 Matthew Garrett 2009-11-18 20:05:40 UTC

Stefan;

If you blacklist the atheros driver (ath5k or ath9k) in order to make sure that it's never loaded, do you see the same behaviour?

Comment 5 Stefan Assmann 2009-11-19 08:03:56 UTC

After blacklisting ath9k the trace does not show up anymore.

Comment 6 Peter Svensson 2009-11-19 13:01:16 UTC

I tried only rmmod:ing the ath9k driver before suspend and modprobe:ing it after. The bug disappeared and the usB mass storage device (holding root) kept working as it should. The ath9k driver works as normal after the modprobe.

Comment 7 Matthew Garrett 2009-11-19 14:19:51 UTC

Sounds like a wireless issue. Linville?

Comment 8 Peter Svensson 2009-11-21 17:19:05 UTC

The problem went away when I installed the newer ath9k driver from linuxwireless.org (I used compat-wireless-2009-11-21). Suspend/resume works as expected. Both the net and the USB host that shares the IRQ seems to function well after resume.

Comment 9 Luis R. Rodriguez 2009-12-09 22:26:40 UTC

Try merging these:

commit eff563cf10e2f24e3b025d352c3aa174cf0111b3
Author: Sujith <Sujith.Manoharan>
Date:   Thu Aug 13 09:34:37 2009 +0530

    ath9k: Set HW state properly

    This patch fixes a bug in ath9k_stop() where the HW
    was not put into FULL_SLEEP state. Not doing so will
    cause issues in suspend-resume and the HW will not respond
    to chip resets.

    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: John W. Linville <linville>

commit 523c36fc9cf75ccf605d9acf68ae9eb857de3f58
Author: Sujith <Sujith.Manoharan>
Date:   Thu Aug 13 09:34:35 2009 +0530

    ath9k: Fix bug in PCI resume

    This patch fixes a bug where the device was enabled
    before restoring the PCI state.

    Signed-off-by: Sujith <Sujith.Manoharan>
    Signed-off-by: John W. Linville <linville>


I have pointed out other possible fixes not merged on 2.6.31 here:

http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt

Unfortunately those were not CC'd stable and therefore not propagated but indeed a lot were candidates...

Comment 10 Luis R. Rodriguez 2009-12-09 22:31:44 UTC

BTW I've updated this here:

http://wireless.kernel.org/en/users/Drivers/ath9k/bugs#Minimal_kernel_requirements

If these patches do fix your suspend issue I'll ensure this gets merged upstream for the next 2.6.31.y release and mention it there on that page.

In the future if anyone has general issues please feel free to refer to that page. New issues and fixes will be mentioned there.

Comment 11 John W. Linville 2010-01-14 19:11:31 UTC

Did Luis's patches help?  I'll close this soon if there is no response...

Comment 12 Stefan Assmann 2010-01-15 08:18:55 UTC

Hi John,

have these patches been integrated in F12? I'm still experiencing this problem.

Comment 13 John W. Linville 2010-01-15 14:36:59 UTC

Are you using a 2.6.32-based kernel?  Those patches are present in 2.6.32.  There seem to be 2.6.32 kernel builds in Koji, dunno what has been pushed to updates.

Comment 14 Stefan Assmann 2010-01-19 08:21:04 UTC

from a day of playing around with 2.6.32 it seems a lot better. Fixes should be backported to F12.

Comment 15 Luis R. Rodriguez 2010-01-19 19:10:28 UTC

The 2.6.31 kernel is now closed, no future extra version releases will be made for it, as such for updates you should use 2.6.32. These are a list of patches I think could have been merged to 2.6.31 but we completely slacked on getting them propagated:

http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt

For 2.6.32 I believe we are good.

Comment 16 Stefan Assmann 2010-01-20 08:12:08 UTC

Do you know if F12 is going for 2.6.32 anytime soon?

Comment 17 John W. Linville 2010-01-20 14:21:09 UTC

Looks like the kernel package in CVS is using 2.6.32, and there seem to be Koji builds for it.  However, I have no idea about the update plans...

Comment 18 John W. Linville 2010-01-21 14:58:18 UTC

http://koji.fedoraproject.org/koji/buildinfo?buildID=152098

Comment 19 John W. Linville 2010-02-01 19:12:33 UTC

Setting to MODIFIED pending a 2.6.32 kernel in F-12...

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