Bug#500552: Module ehci_hcd disables IRQ, drops USB connections!
Package: kernel
Version: 2.6.18-6
When using external USB2 hard-disk, intensive I/O operations to the disk (such as scanning my music collection or performing a file system check) will cause the IRQ of the USB port to be disabled effectively stopping all file transfers and forcing the hard-disk offline. System must then be rebooted to restore the hard-disk to a functional status. Here is the error output I get:
irq 3: nobody cared (try booting with the "irqpoll" option)
[<c0131f0f>] __report_bad_irq+0x2b/0x69
[<c01320d5>] note_interrupt+0x188/0x1bf
[<c01318b3>] __do_IRQ+0x72/0xa1
[<c0105073>] do_IRQ+0x43/0x50
[<c0103a9a>] common_interrupt+0x1a/0x20
[<c011855a>] __do_softirq+0x2c/0x75
[<c01185c5>] do_softirq+0x22/0x26
[<c0105078>] do_IRQ+0x48/0x50
[<c0103a9a>] common_interrupt+0x1a/0x20
[<c4a05e20>] usb_get_urb+0xc/0x10 [usbcore]
[<c4a0562d>] hcd_submit_urb+0x10a/0x6ba [usbcore]
[<c0105078>] do_IRQ+0x48/0x50
[<c02750a4>] schedule+0x46e/0x4d2
[<c02750a4>] schedule+0x46e/0x4d2
[<c0105078>] do_IRQ+0x48/0x50
[<c4a05df1>] usb_submit_urb+0x1bb/0x1de [usbcore]
[<c4c517fd>] usb_stor_msg_common+0x92/0xe9 [usb_storage]
[<c4c51bc7>] usb_stor_bulk_transfer_buf+0x39/0x64 [usb_storage]
[<c4c520d5>] usb_stor_Bulk_transport+0x13f/0x207 [usb_storage]
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c4c521b2>] usb_stor_invoke_transport+0x15/0x22c [usb_storage]
[<c0111cba>] default_wake_function+0x0/0xc
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c4c52dda>] usb_stor_control_thread+0xfa/0x169 [usb_storage]
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c4c52ce0>] usb_stor_control_thread+0x0/0x169 [usb_storage]
[<c0122b9c>] kthread+0xaf/0xdb
[<c0122aed>] kthread+0x0/0xdb
[<c0101005>] kernel_thread_helper+0x5/0xb
handlers:
[<c4a0529b>] (usb_hcd_irq+0x0/0x4a [usbcore])
[<c4a2b430>] (yenta_interrupt+0x0/0xac [yenta_socket])
[<c4a0529b>] (usb_hcd_irq+0x0/0x4a [usbcore])
[<c4a0529b>] (usb_hcd_irq+0x0/0x4a [usbcore])
[<c4a0529b>] (usb_hcd_irq+0x0/0x4a [usbcore])
Disabling IRQ #3
I am able to reproduce this error by unmounting the hard-disk and running fsck.ext3 on the volume (/dev/sda1). Here is what I do:
(root): umount -U "disk UUID"
(root): fsck.ext3 /dev/sda1
To troubleshoot this, I have currently blacklisted the kernel module 'ehci_hcd'. This makes things very very slow, but I no longer observe any errors, even when running fsck. The relevant hardware is as follows:
Ricoh RL5c475 Cardbus Adapter (module yenta_socket)
VIA chipset based USB2 port card/hub (modules uhci_hcd for USB1.1, ehci_hcd for USB2)
Seagate FreeAgent external usb hard-disk
Interrupts:
0: 2324767 XT-PIC timer
1: 13486 XT-PIC i8042
2: 0 XT-PIC cascade
3: 508 XT-PIC uhci_hcd:usb1, yenta, uhci_hcd:usb2, uhci_hcd:usb3
5: 37503 XT-PIC NE2000
6: 3 XT-PIC floppy
7: 0 XT-PIC parport0
8: 1 XT-PIC rtc
9: 1292 XT-PIC au8820
12: 662263 XT-PIC i8042
14: 98748 XT-PIC ide0
15: 132 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
Complete hardware listing:
00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
00:01.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:01.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:09.0 CardBus bridge: Ricoh Co Ltd RL5c475
00:0a.0 Multimedia audio controller: Aureal Semiconductor Vortex 1 (rev 02)
00:0b.0 Multimedia video controller: 3Dfx Interactive, Inc. Voodoo 2 (rev 02)
00:0c.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
01:00.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
01:00.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
01:00.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65)
I am using Debian GNU/Linux 4.0 "Etch" with the default kernel.
Reply to: