* RE: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
@ 2005-07-10 18:50 Protasevich, Natalie
2005-07-11 9:06 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Protasevich, Natalie @ 2005-07-10 18:50 UTC (permalink / raw)
To: Michel Bouissou, linux-kernel; +Cc: stern, mingo
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of
> Michel Bouissou
> Sent: Sunday, July 10, 2005 2:11 AM
> To: linux-kernel@vger.kernel.org
> Cc: stern@rowland.harvard.edu; mingo@redhat.com
> Subject: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
>
> Hi there,
>
> I use a Gigabyte GA7-VAXP motherboard that has been fine for
> more than 2 years with 2.4 series kernels, and that gives
> trouble with 2.6.12 (and previous) kernels.
>
> The problem seems to sit between the UP IO-APIC and USB
> uhci_hcd driver.
>
> The GA7-VAXP MB is equipped with an Athlon 2000+ XP and a VIA
> KT400 chipset.
>
> Using 2.4 series kernel the IO-APIC is used just fine. Was
> never source of any kind of problem.
>
> Using 2.6.12 kernel, if the IO-APIC is enabled in the kernel
> configuration, then the interrupt controlling the uhci_hcd
> USB controller gets disabled as soon as uhci_hcd is initialized.
Michel,
Symptoms that you describe resemble several IRQ problems with VIA
chipset reported by others (but not quite...) Could you check on
bugzilla #4843 please
http://bugzilla.kernel.org/show_bug.cgi?id=4843 and see if the patch
fixes your problem.
Thanks,
--Natalie
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-10 18:50 Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble Protasevich, Natalie
@ 2005-07-11 9:06 ` Michel Bouissou
2005-07-11 18:36 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 9:06 UTC (permalink / raw)
To: Protasevich, Natalie; +Cc: linux-kernel, stern, mingo
Le Dimanche 10 Juillet 2005 20:50, Protasevich, Natalie a écrit :
>
> Michel,
> Symptoms that you describe resemble several IRQ problems with VIA
> chipset reported by others (but not quite...) Could you check on
> bugzilla #4843 please
> http://bugzilla.kernel.org/show_bug.cgi?id=4843 and see if the patch
> fixes your problem.
Hi Nathalie,
Thanks for your answer and pointer. Unfortunately it doesn't help.
The patch you mention won't apply on my kernel alone, I need first to apply
the patch from
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c434b7a6aedfe428ad17cd61b21b125a7b7a29ce ,
then your patch applies OK.
Unfortunately, it doesn't solve my issue. Booting this kernel still results in
an interrupt issue with uhci_hcd.
After boot, "cat /proc/interrupts" shows:
CPU0
0: 188066 IO-APIC-edge timer
1: 308 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 413 IO-APIC-edge serial
7: 3 IO-APIC-edge parport0
14: 1177 IO-APIC-edge ide4
15: 1186 IO-APIC-edge ide5
18: 1028 IO-APIC-level eth0, eth1
19: 8513 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
21: 100000 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
22: 0 IO-APIC-level VIA8233
NMI: 0
LOC: 187967
ERR: 0
MIS: 0
(The problem is with IRQ 21 for uhci_hcd)
(It is to note that without those patches, I didn't see any IRQ managed by
"XT-PIC", all were managed by the IO-APIC...)
The errors I get in /var/log/messages are :
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
PCI: Via IRQ fixup for 0000:00:10.0, from 10 to 5
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:10.0: irq 21, io base 0x0000cc00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.1, from 10 to 5
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#2)
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.1: irq 21, io base 0x0000d000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#3)
usb 1-1: new low speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.2: irq 21, io base 0x0000d400
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:10.0-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
PCI: Via IRQ fixup for 0000:00:10.3, from 11 to 3
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:10.3: irq 19, io mem 0xe3009000
ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
usb 1-1: USB disconnect, address 2
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
usb 1-1: new low speed USB device using uhci_hcd and address 3
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:10.0-1
usb 3-2: new full speed USB device using uhci_hcd and address 3
irq 21: nobody cared!
[__report_bad_irq+42/144] __report_bad_irq+0x2a/0x90
[<c013cb5a>] __report_bad_irq+0x2a/0x90
[handle_IRQ_event+57/112] handle_IRQ_event+0x39/0x70
[<c013c449>] handle_IRQ_event+0x39/0x70
[note_interrupt+163/208] note_interrupt+0xa3/0xd0
[<c013cc83>] note_interrupt+0xa3/0xd0
[__do_IRQ+320/352] __do_IRQ+0x140/0x160
[<c013c5c0>] __do_IRQ+0x140/0x160
[do_IRQ+50/112] do_IRQ+0x32/0x70
[<c01054f2>] do_IRQ+0x32/0x70
[common_interrupt+26/32] common_interrupt+0x1a/0x20
[<c0103812>] common_interrupt+0x1a/0x20
[path_lookup+197/448] path_lookup+0xc5/0x1c0
[<c016f935>] path_lookup+0xc5/0x1c0
[do_page_fault+457/1427] do_page_fault+0x1c9/0x593
[<c0113a09>] do_page_fault+0x1c9/0x593
[open_exec+50/272] open_exec+0x32/0x110
[<c016a9e2>] open_exec+0x32/0x110
[pg0+947004132/1069421568] usb_hcd_irq+0x44/0x90 [usbcore]
[<f8b3f2e4>] usb_hcd_irq+0x44/0x90 [usbcore]
[handle_IRQ_event+57/112] handle_IRQ_event+0x39/0x70
[<c013c449>] handle_IRQ_event+0x39/0x70
[do_execve+66/592] do_execve+0x42/0x250
[<c016bc82>] do_execve+0x42/0x250
[sys_execve+70/176] sys_execve+0x46/0xb0
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[<c0102dfb>] sysenter_past_esp+0x54/0x75
handlers:
[pg0+947004064/1069421568] (usb_hcd_irq+0x0/0x90 [usbcore])
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
[pg0+947004064/1069421568] (usb_hcd_irq+0x0/0x90 [usbcore])
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
[pg0+947004064/1069421568] (usb_hcd_irq+0x0/0x90 [usbcore])
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
Disabling IRQ #21
At boot, IRQs seem to be distributed this way:
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router default [1106/3189] at 0000:00:00.0
PCI->APIC IRQ transform: 0000:00:0a.0[A] -> IRQ 18
PCI->APIC IRQ transform: 0000:00:0b.0[A] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:0f.0[A] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:10.0[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.1[B] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.2[C] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.3[D] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:11.1[A] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:11.5[C] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:13.0[A] -> IRQ 18
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
Machine check exception polling timer started.
Hope this may help...
(Please copy me on answers, I'm not subscribed to the linux-kernel ML)
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 9:06 ` Michel Bouissou
@ 2005-07-11 18:36 ` Alan Stern
2005-07-11 19:33 ` [SOLVED ??] " Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-11 18:36 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel, mingo
On Mon, 11 Jul 2005, Michel Bouissou wrote:
> Hi Nathalie,
>
> Thanks for your answer and pointer. Unfortunately it doesn't help.
>
> The patch you mention won't apply on my kernel alone, I need first to apply
> the patch from
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c434b7a6aedfe428ad17cd61b21b125a7b7a29ce ,
> then your patch applies OK.
>
> Unfortunately, it doesn't solve my issue. Booting this kernel still results in
> an interrupt issue with uhci_hcd.
>
> After boot, "cat /proc/interrupts" shows:
> CPU0
> 0: 188066 IO-APIC-edge timer
> 1: 308 IO-APIC-edge i8042
> 2: 0 XT-PIC cascade
> 4: 413 IO-APIC-edge serial
> 7: 3 IO-APIC-edge parport0
> 14: 1177 IO-APIC-edge ide4
> 15: 1186 IO-APIC-edge ide5
> 18: 1028 IO-APIC-level eth0, eth1
> 19: 8513 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
> 21: 100000 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> 22: 0 IO-APIC-level VIA8233
> NMI: 0
> LOC: 187967
> ERR: 0
> MIS: 0
>
> (The problem is with IRQ 21 for uhci_hcd)
>
> (It is to note that without those patches, I didn't see any IRQ managed by
> "XT-PIC", all were managed by the IO-APIC...)
It's possible that the errors you're getting are caused by some other
device erroneously generating interrupt requests on IRQ 21. Then when
uhci-hcd enables that IRQ, there's no driver available to handle the
interrupts...
It's also possible that the UHCI controllers are generating the unwanted
interrupt requests. You should make sure that Legacy USB Support is
turned off in your BIOS settings. You can also try adding the
"usb-handoff" kernel parameter to your boot command line.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 18:36 ` Alan Stern
@ 2005-07-11 19:33 ` Michel Bouissou
2005-07-11 19:43 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 19:33 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel, mingo
Le Lundi 11 Juillet 2005 20:36, Alan Stern a écrit :
> It's also possible that the UHCI controllers are generating the unwanted
> interrupt requests. You should make sure that Legacy USB Support is
> turned off in your BIOS settings.
My motherboard both holds USB 1.1 and USB 2.0 controllers. I don't have a
"Legacy USB Support" option in my BIOS, all my USB options are the following:
Enable USB 1.1 controller: YES (Surely relates to my true USB 1.1 controller)
Enable USB 2.0 controller: YES (Same for the high speed controller ?)
Enable USB keyboard: NO
Enable USB mouse support: YES (Well, I have one ;-)
I didn't change anything regarding these so far.
> You can also try adding the "usb-handoff" kernel parameter to your boot
> command line.
Hey !! This one looks like the MIRACLE-OPTION !!
I just booted using my 2.6.12 kernel patched with Nathalie's patches (don't
know if they help in there...) and the problem seems to be gone !
Nothing complains anymore about the interrupt. I have:
[root@totor etc]# cat /proc/interrupts
CPU0
0: 934501 IO-APIC-edge timer
1: 4611 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 2779 IO-APIC-edge serial
7: 3 IO-APIC-edge parport0
14: 7909 IO-APIC-edge ide4
15: 7918 IO-APIC-edge ide5
16: 38447 IO-APIC-level nvidia
18: 2982 IO-APIC-level eth0, eth1
19: 37041 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
21: 52036 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
22: 2850 IO-APIC-level VIA8233
NMI: 0
LOC: 934453
ERR: 0
MIS: 0
...now let's see with time if this is stable...
A thousand thanks for your suggestion Alan !
(Kernel 2.4 was working plain good without such a boot option, I didn't know
it existed...)
(Please copy me on answers, as I'm not subscribed to the linux-kernel mailing
list.)
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 19:33 ` [SOLVED ??] " Michel Bouissou
@ 2005-07-11 19:43 ` Alan Stern
2005-07-11 20:02 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-11 19:43 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel, mingo
On Mon, 11 Jul 2005, Michel Bouissou wrote:
> Le Lundi 11 Juillet 2005 20:36, Alan Stern a écrit :
> > It's also possible that the UHCI controllers are generating the unwanted
> > interrupt requests. You should make sure that Legacy USB Support is
> > turned off in your BIOS settings.
>
> My motherboard both holds USB 1.1 and USB 2.0 controllers. I don't have a
> "Legacy USB Support" option in my BIOS, all my USB options are the following:
>
> Enable USB 1.1 controller: YES (Surely relates to my true USB 1.1 controller)
>
> Enable USB 2.0 controller: YES (Same for the high speed controller ?)
>
> Enable USB keyboard: NO
>
> Enable USB mouse support: YES (Well, I have one ;-)
That's what I was talking about. BIOS support for keyboard and mouse is
called "Legacy" support, because it emulates plain old non-USB AT-type
devices. I bet if you turned off the "Enable USB mouse support" option
then everything would work.
> I didn't change anything regarding these so far.
>
> > You can also try adding the "usb-handoff" kernel parameter to your boot
> > command line.
>
> Hey !! This one looks like the MIRACLE-OPTION !!
>
> I just booted using my 2.6.12 kernel patched with Nathalie's patches (don't
> know if they help in there...) and the problem seems to be gone !
>
> Nothing complains anymore about the interrupt. I have:
>
> [root@totor etc]# cat /proc/interrupts
> CPU0
> 0: 934501 IO-APIC-edge timer
> 1: 4611 IO-APIC-edge i8042
> 2: 0 XT-PIC cascade
> 4: 2779 IO-APIC-edge serial
> 7: 3 IO-APIC-edge parport0
> 14: 7909 IO-APIC-edge ide4
> 15: 7918 IO-APIC-edge ide5
> 16: 38447 IO-APIC-level nvidia
> 18: 2982 IO-APIC-level eth0, eth1
> 19: 37041 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
> 21: 52036 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> 22: 2850 IO-APIC-level VIA8233
> NMI: 0
> LOC: 934453
> ERR: 0
> MIS: 0
>
>
> ...now let's see with time if this is stable...
>
> A thousand thanks for your suggestion Alan !
You're welcome.
> (Kernel 2.4 was working plain good without such a boot option, I didn't know
> it existed...)
A lot has changed since 2.4... not always for the better!
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 19:43 ` Alan Stern
@ 2005-07-11 20:02 ` Michel Bouissou
2005-07-11 20:16 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 20:02 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Lundi 11 Juillet 2005 21:43, Alan Stern a écrit :
> >
> > Enable USB mouse support: YES (Well, I have one ;-)
>
> That's what I was talking about. BIOS support for keyboard and mouse is
> called "Legacy" support, because it emulates plain old non-USB AT-type
> devices. I bet if you turned off the "Enable USB mouse support" option
> then everything would work.
Aha. And what would be your advice ? Rather leave the BIOS mouse option ON and
use "usb-handoff", or remove both ?
I'll check without both tomorrow anyway, it's a bit late tonight for keeping
on breaking the machine ;-)
> > A thousand thanks for your suggestion Alan !
>
> You're welcome.
Well, you really deserve my thanks :-)
> A lot has changed since 2.4... not always for the better!
Hmmm... I've seen... 2.6.12 is the first release that seems to be willing to
work on my system -- with some tweaking, coffee and aspirin. Previous 2.6.x
releases I had tried (2.6.3, 2.6.6) were horribly broken on my poor VIA
hardware ;-)
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 20:02 ` Michel Bouissou
@ 2005-07-11 20:16 ` Alan Stern
2005-07-11 20:46 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-11 20:16 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Mon, 11 Jul 2005, Michel Bouissou wrote:
> Le Lundi 11 Juillet 2005 21:43, Alan Stern a écrit :
> > >
> > > Enable USB mouse support: YES (Well, I have one ;-)
> >
> > That's what I was talking about. BIOS support for keyboard and mouse is
> > called "Legacy" support, because it emulates plain old non-USB AT-type
> > devices. I bet if you turned off the "Enable USB mouse support" option
> > then everything would work.
>
> Aha. And what would be your advice ? Rather leave the BIOS mouse option ON and
> use "usb-handoff", or remove both ?
Well, some people don't have a choice. They need to leave BIOS USB
keyboard/mouse support turned on in order to use their USB keyboard/mouse
before the Linux kernel has loaded (within Grub, for instance).
If you don't care about that, then it's cleaner to turn off the BIOS
support. Of course, you may find that you still need to use
"usb-handoff" anyway!
In the end it doesn't make much difference. Do whatever works best for
you.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 20:16 ` Alan Stern
@ 2005-07-11 20:46 ` Michel Bouissou
2005-07-11 20:58 ` Michel Bouissou
2005-07-11 21:21 ` [SOLVED ??] " Alan Stern
0 siblings, 2 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 20:46 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Lundi 11 Juillet 2005 22:16, Alan Stern a écrit :
> > Aha. And what would be your advice ? Rather leave the BIOS mouse option
> > ON and use "usb-handoff", or remove both ?
>
> Well, some people don't have a choice. They need to leave BIOS USB
> keyboard/mouse support turned on in order to use their USB keyboard/mouse
> before the Linux kernel has loaded (within Grub, for instance).
>
> If you don't care about that, then it's cleaner to turn off the BIOS
> support. Of course, you may find that you still need to use
> "usb-handoff" anyway!
Well, I'm afraid I spoke too fast :-(
I rebooted my system with "usb-handoff" again, but still the USB mouse enabled
in BIOS, and this time got the punishent again :-(
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
PCI: Via IRQ fixup for 0000:00:10.0, from 10 to 5
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:10.0: irq 21, io base 0x0000cc00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.1, from 10 to 5
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#2)
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.1: irq 21, io base 0x0000d000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#3)
usb 1-1: new low speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.2: irq 21, io base 0x0000d400
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.3, from 11 to 3
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:10.3: irq 19, io mem 0xe3009000
ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
usbcore: registered new driver hiddev
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
usbhid: probe of 1-1:1.0 failed with error -5
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
irq 21: nobody cared!
...etc :-(
Well, this time, I deactivated the mouse in BIOS, rebooted again, also with
"usb-handoff", and "again it works"...
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 20:46 ` Michel Bouissou
@ 2005-07-11 20:58 ` Michel Bouissou
2005-07-11 21:21 ` [NOT solved] " Michel Bouissou
2005-07-11 21:21 ` [SOLVED ??] " Alan Stern
1 sibling, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 20:58 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Lundi 11 Juillet 2005 22:46, Michel Bouissou a écrit :
>
> Well, this time, I deactivated the mouse in BIOS, rebooted again, also with
> "usb-handoff", and "again it works"...
...at least, it worked until I unplugged my USB scanner...
Jul 11 22:52:54 totor kernel: usb 3-2: USB disconnect, address 2
...then replugged my USB scanner...
Jul 11 22:53:08 totor kernel: usb 3-2: new full speed USB device using
uhci_hcd and address 3
Jul 11 22:53:08 totor kernel: irq 21: nobody cared!
Oh no :-(
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [NOT solved] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 20:58 ` Michel Bouissou
@ 2005-07-11 21:21 ` Michel Bouissou
0 siblings, 0 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 21:21 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Lundi 11 Juillet 2005 22:58, Michel Bouissou a écrit :
>
> Oh no :-(
Well, I give up for tonight :-(
This time I rebooted with the mouse disabled in BIOS, with the usb-handoff
option, with the scanner unplugged... And it went wrong simply by itself.
"irq 21: nobody cared!"
The only thing I'm sure about is that there is something either with UP
IO-APIC support, or with the uhci_hcd module.
When both are combined, as you can see, this is completely unstable. One time
it works, one time it doesn't.
But if I use a kernel compiled without UP IO-APIC, or if I boot an
IO-APIC-capable kernel with the "noapic" option, then the problem is gone,
and it is stable (really, this time).
But of course, I don't have no IO-APIC anymore...
[root@totor etc]# cat /proc/interrupts
CPU0
0: 423482 XT-PIC timer
1: 1083 XT-PIC i8042
2: 0 XT-PIC cascade
4: 1106 XT-PIC serial
7: 1543 XT-PIC parport0
10: 3527 XT-PIC uhci_hcd:usb3, eth0, eth1, VIA8233
11: 24934 XT-PIC ide0, ide1, ide2, ide3, uhci_hcd:usb2,
ehci_hcd:usb4
12: 13809 XT-PIC uhci_hcd:usb1, nvidia
14: 3245 XT-PIC ide4
15: 3254 XT-PIC ide5
NMI: 0
LOC: 423403
ERR: 270
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 20:46 ` Michel Bouissou
2005-07-11 20:58 ` Michel Bouissou
@ 2005-07-11 21:21 ` Alan Stern
2005-07-11 21:34 ` Michel Bouissou
1 sibling, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-11 21:21 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Mon, 11 Jul 2005, Michel Bouissou wrote:
> Well, I'm afraid I spoke too fast :-(
>
> I rebooted my system with "usb-handoff" again, but still the USB mouse enabled
> in BIOS, and this time got the punishent again :-(
> irq 21: nobody cared!
>
> ...etc :-(
>
> Well, this time, I deactivated the mouse in BIOS, rebooted again, also with
> "usb-handoff", and "again it works"...
> ...at least, it worked until I unplugged my USB scanner...
>
> Jul 11 22:52:54 totor kernel: usb 3-2: USB disconnect, address 2
>
> ...then replugged my USB scanner...
>
> Jul 11 22:53:08 totor kernel: usb 3-2: new full speed USB device using
> uhci_hcd and address 3
> Jul 11 22:53:08 totor kernel: irq 21: nobody cared!
>
> Oh no :-(
Don't jump to hasty conclusions. Problems like this are often caused by
unrelated things that you wouldn't suspect at first. Getting something to
work once doesn't mean the problem has been fixed. And you can be fooled
by coincidences. (I would be surprised if that event above was really
caused by plugging in the scanner, unless your UHCI hardware is broken.)
One thing you might try, time-consuming though it will be, is to remove or
disable as much hardware as possible from your system. If you can
reliably determine that the problem occurs only when one particular piece
of hardware is enabled, then you'll know how to proceed.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 21:21 ` [SOLVED ??] " Alan Stern
@ 2005-07-11 21:34 ` Michel Bouissou
2005-07-12 1:54 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-11 21:34 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Lundi 11 Juillet 2005 23:21, Alan Stern a écrit :
> Don't jump to hasty conclusions. Problems like this are often caused by
> unrelated things that you wouldn't suspect at first.
I know... Been working with computers for... Uh... 25 years ?
> Getting something to work once doesn't mean the problem has been fixed.
That's so sadly right ;-)
> And you can be fooled by coincidences. (I would be surprised if that event
> above was really caused by plugging in the scanner, unless your UHCI
> hardware is broken.)
I don't believe the hardware is broken, as it's been running for more than 2
years 100% stable with a 24/7/365 uptime. And with me plugging and unplugging
USB devices...
Never had a single problem of the kind with any 2.4.x kernel. Get those
problems only with 2.6.x kernels, and, in 2.6.12, only when UP IO-APIC is
enabled (which ran perfectly good in 2.4).
So the problem is circled to 2.6 kernel, uhci_hcd and UP IO-APIC.
> One thing you might try, time-consuming though it will be, is to remove or
> disable as much hardware as possible from your system. If you can
> reliably determine that the problem occurs only when one particular piece
> of hardware is enabled, then you'll know how to proceed.
I can hardly remove my VIA chipset from the mobo, and the USB thing is in the
VIA thing ;-))
And I'm afraid I won't have the time to play that much with hardware, besides
the fact that this is supposed to be a server which usually has uptimes over
90 days rather than reboot-for-testing-the-damn-kernel-once-again ;-))
But I'm pretty sure this is no hardware problem, unless 2.6 considers "bad
hardware" what 2.4 used to consider "nice hardware"...
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [SOLVED ??] Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-11 21:34 ` Michel Bouissou
@ 2005-07-12 1:54 ` Alan Stern
2005-07-12 7:54 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-12 1:54 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Mon, 11 Jul 2005, Michel Bouissou wrote:
> Le Lundi 11 Juillet 2005 23:21, Alan Stern a écrit :
> > Don't jump to hasty conclusions. Problems like this are often caused by
> > unrelated things that you wouldn't suspect at first.
>
> I know... Been working with computers for... Uh... 25 years ?
35 years for me... My, how the time flies!
> I don't believe the hardware is broken, as it's been running for more than 2
> years 100% stable with a 24/7/365 uptime. And with me plugging and unplugging
> USB devices...
>
> Never had a single problem of the kind with any 2.4.x kernel. Get those
> problems only with 2.6.x kernels, and, in 2.6.12, only when UP IO-APIC is
> enabled (which ran perfectly good in 2.4).
>
> So the problem is circled to 2.6 kernel, uhci_hcd and UP IO-APIC.
Don't rule out the hardware too quickly. 2.4 and 2.6 manage the UHCI
controllers in different ways. In particular, the usb-uhci driver in 2.4
does not suspend the controller when no devices are attached, whereas
uhci-hcd in 2.6 does. (So does the "alternate" uhci driver in 2.4.) I
recently handled a bug report -- from another Frenchman -- where it turned
out that his UHCI hardware instantly crashed the entire system whenever
it resumed from the suspended state!
To try and help pin things down, tomorrow (i.e., Tuesday) I'll send you a
test patch to completely disable the UHCI controllers, leaving them awake
and idle, not generating interrupts. If you still get those spurious
IRQs, they will have to come from somewhere else. (Assuming you can
devote server time to this sort of testing...)
And of course, if the spurious IRQs stop then we'll know where to probe
further.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 1:54 ` Alan Stern
@ 2005-07-12 7:54 ` Michel Bouissou
2005-07-12 14:12 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-12 7:54 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Mardi 12 Juillet 2005 03:54, Alan Stern a écrit :
> > So the problem is circled to 2.6 kernel, uhci_hcd and UP IO-APIC.
>
> Don't rule out the hardware too quickly. 2.4 and 2.6 manage the UHCI
> controllers in different ways.
I saw ;-)
> In particular, the usb-uhci driver in 2.4 does not suspend the controller
> when no devices are attached, whereas uhci-hcd in 2.6 does. (So does the
> "alternate" uhci driver in 2.4.) [...]
> To try and help pin things down, tomorrow (i.e., Tuesday) I'll send you a
> test patch to completely disable the UHCI controllers, leaving them awake
> and idle, not generating interrupts. If you still get those spurious
> IRQs, they will have to come from somewhere else. (Assuming you can
> devote server time to this sort of testing...)
I'll try my best, although I will have little time for playing with this until
the end of this week, and will be on travel next week. But if you send me a
test patch, I'll try my best to test it.
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 7:54 ` Michel Bouissou
@ 2005-07-12 14:12 ` Alan Stern
2005-07-12 17:03 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-12 14:12 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Tue, 12 Jul 2005, Michel Bouissou wrote:
> > To try and help pin things down, tomorrow (i.e., Tuesday) I'll send you a
> > test patch to completely disable the UHCI controllers, leaving them awake
> > and idle, not generating interrupts. If you still get those spurious
> > IRQs, they will have to come from somewhere else. (Assuming you can
> > devote server time to this sort of testing...)
>
> I'll try my best, although I will have little time for playing with this until
> the end of this week, and will be on travel next week. But if you send me a
> test patch, I'll try my best to test it.
Okay, the patch (for 2.6.12) is below. It does several things:
Prevents the system from reading the port status registers,
so the computer won't know when any devices are plugged in.
Makes the system think there always is a device plugged in,
so it will never automatically suspend the controllers.
Leaves all the interrupt-enable bits turned off, so the
controllers won't ever generate an interrupt request.
Prints a message to the system log every time the interrupt
handler is called.
In case it's not already clear, when you install this patch the UHCI
controllers will not be useable.
Alan Stern
Index: linux-2.6.12/drivers/usb/host/uhci-hub.c
===================================================================
--- linux-2.6.12.orig/drivers/usb/host/uhci-hub.c
+++ linux-2.6.12/drivers/usb/host/uhci-hub.c
@@ -38,6 +38,7 @@ static int uhci_hub_status_data(struct u
struct uhci_hcd *uhci = hcd_to_uhci(hcd);
int port;
+ return 0;
*buf = 0;
for (port = 0; port < uhci->rh_numports; ++port) {
if ((inw(uhci->io_addr + USBPORTSC1 + port * 2) & RWC_BITS) ||
@@ -154,6 +155,7 @@ static int uhci_hub_control(struct usb_h
if (to_pci_dev(hcd->self.controller)->vendor ==
PCI_VENDOR_ID_VIA)
status ^= USBPORTSC_OC;
+ status = 0;
/* UHCI doesn't support C_RESET (always false) */
wPortChange = lstatus = 0;
Index: linux-2.6.12/drivers/usb/host/uhci-hcd.c
===================================================================
--- linux-2.6.12.orig/drivers/usb/host/uhci-hcd.c
+++ linux-2.6.12/drivers/usb/host/uhci-hcd.c
@@ -169,6 +169,7 @@ static irqreturn_t uhci_irq(struct usb_h
* "HC Halted" status bit is persistent: it is RO, not R/WC.
*/
status = inw(io_addr + USBSTS);
+ dev_info(uhci_dev(uhci), "IRQ, status = %x\n", status);
if (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */
return IRQ_NONE;
outw(status, io_addr + USBSTS); /* Clear it */
@@ -282,6 +283,7 @@ static int ports_active(struct uhci_hcd
int connection = 0;
int i;
+ return 1;
for (i = 0; i < uhci->rh_numports; i++)
connection |= (inw(io_addr + USBPORTSC1 + i * 2) & USBPORTSC_CCS);
@@ -389,8 +391,10 @@ static int start_hc(struct uhci_hcd *uhc
/* Turn on PIRQ and all interrupts */
pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP,
USBLEGSUP_DEFAULT);
+#if 0
outw(USBINTR_TIMEOUT | USBINTR_RESUME | USBINTR_IOC | USBINTR_SP,
io_addr + USBINTR);
+#endif
/* Start at frame 0 */
outw(0, io_addr + USBFRNUM);
@@ -757,8 +761,10 @@ static int uhci_resume(struct usb_hcd *h
0);
outw(uhci->frame_number, uhci->io_addr + USBFRNUM);
outl(uhci->fl->dma_handle, uhci->io_addr + USBFLBASEADD);
+#if 0
outw(USBINTR_TIMEOUT | USBINTR_RESUME | USBINTR_IOC |
USBINTR_SP, uhci->io_addr + USBINTR);
+#endif
uhci->resume_detect = 1;
pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP,
USBLEGSUP_DEFAULT);
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 14:12 ` Alan Stern
@ 2005-07-12 17:03 ` Michel Bouissou
2005-07-12 18:15 ` Alan Stern
2005-07-12 18:16 ` Michel Bouissou
0 siblings, 2 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-12 17:03 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Mardi 12 Juillet 2005 16:12, Alan Stern a écrit :
>
> Okay, the patch (for 2.6.12) is below. It does several things:
>
> Prevents the system from reading the port status registers,
> so the computer won't know when any devices are plugged in.
>
> Makes the system think there always is a device plugged in,
> so it will never automatically suspend the controllers.
>
> Leaves all the interrupt-enable bits turned off, so the
> controllers won't ever generate an interrupt request.
>
> Prints a message to the system log every time the interrupt
> handler is called.
>
> In case it's not already clear, when you install this patch the UHCI
> controllers will not be useable.
Okay, the patch applied easily and the kernel is now compiling. When
installed, I'll try and boot it (and will use a PS/2 mouse instead of my
current USB mouse, or should I rather try to plug my USB mouse to the
ehci_hcd controller ?).
How would you like me to boot ? With or without the "usb-handoff" option ?
With or without the BIOS "USB mouse support" option ?
And once booted, what information will you be interested in ?
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 17:03 ` Michel Bouissou
@ 2005-07-12 18:15 ` Alan Stern
2005-07-12 18:16 ` Michel Bouissou
1 sibling, 0 replies; 26+ messages in thread
From: Alan Stern @ 2005-07-12 18:15 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Tue, 12 Jul 2005, Michel Bouissou wrote:
> > In case it's not already clear, when you install this patch the UHCI
> > controllers will not be useable.
>
> Okay, the patch applied easily and the kernel is now compiling. When
> installed, I'll try and boot it (and will use a PS/2 mouse instead of my
> current USB mouse, or should I rather try to plug my USB mouse to the
> ehci_hcd controller ?).
USB mice generally run at low speed. This means that you _can't_ plug it
into an EHCI controller -- the controller will see that it's not a
high-speed device and will hand it over to a companion controller, which
in your case will be UHCI.
> How would you like me to boot ? With or without the "usb-handoff" option ?
> With or without the BIOS "USB mouse support" option ?
Use "usb-handoff" and turn off BIOS USB mouse support.
> And once booted, what information will you be interested in ?
I'll be interested in seeing if you still get the "IRQ 21 nobody cared"
message.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 17:03 ` Michel Bouissou
2005-07-12 18:15 ` Alan Stern
@ 2005-07-12 18:16 ` Michel Bouissou
2005-07-12 18:57 ` Alan Stern
1 sibling, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-12 18:16 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
Le Mardi 12 Juillet 2005 19:03, Michel Bouissou a écrit :
>
> Okay, the patch applied easily and the kernel is now compiling. When
> installed, I'll try and boot it (and will use a PS/2 mouse instead of my
> current USB mouse, or should I rather try to plug my USB mouse to the
> ehci_hcd controller ?).
>
> How would you like me to boot ? With or without the "usb-handoff" option ?
> With or without the BIOS "USB mouse support" option ?
I've booted with the patched kernel in the following way:
- BIOS option for mouse support still off ;
- Kernel commandline:
kernel /vmlinuz-2.6.12-6mib7test root=/dev/evms/lv_racine ro 3 usb-handoff
devfs=nomount noquiet vga=791
- USB mouse plugged to what I believe to be the USB 2.0 controller (according
to the motherboard manual)
First thing I notice at boot is that "mouse doesn't work".
cat /proc/interrupts shows :
CPU0
0: 208937 IO-APIC-edge timer
1: 334 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 464 IO-APIC-edge serial
7: 3 IO-APIC-edge parport0
14: 1321 IO-APIC-edge ide4
15: 1330 IO-APIC-edge ide5
18: 822 IO-APIC-level eth0, eth1
19: 14157 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
21: 33962 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
22: 0 IO-APIC-level VIA8233
NMI: 0
LOC: 208855
ERR: 0
MIS: 0
Looking at dmesg or /var/log/mesages shows a huge number of :
Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.0: IRQ, status = 0
Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.1: IRQ, status = 0
Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
(3043 similar lines...)
...immediately at startup, then it stops complaining
The interesting thing is that I unplugged my USB mouse at 19:45 -- nothing
happened, and plugged it back at 19:45:40, while looking at a "tail
-f /var/log/messages"
And see what happened in the attached copy of my /var/log/messages for this
session...
Doesn't mean anything to me ;-) but I hope it will be of some help for you...
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
[-- Attachment #2: linux-2.6.12-6mib7test-msgs.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 6916 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 18:16 ` Michel Bouissou
@ 2005-07-12 18:57 ` Alan Stern
2005-07-12 20:40 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-12 18:57 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Tue, 12 Jul 2005, Michel Bouissou wrote:
> I've booted with the patched kernel in the following way:
>
> - BIOS option for mouse support still off ;
>
> - Kernel commandline:
> kernel /vmlinuz-2.6.12-6mib7test root=/dev/evms/lv_racine ro 3 usb-handoff
> devfs=nomount noquiet vga=791
Okay, good.
> - USB mouse plugged to what I believe to be the USB 2.0 controller (according
> to the motherboard manual)
>
> First thing I notice at boot is that "mouse doesn't work".
As I explained in the previous message, the mouse ends up being connected
to a UHCI controller no matter what port you plug it in to.
> cat /proc/interrupts shows :
> CPU0
> 0: 208937 IO-APIC-edge timer
> 1: 334 IO-APIC-edge i8042
> 2: 0 XT-PIC cascade
> 4: 464 IO-APIC-edge serial
> 7: 3 IO-APIC-edge parport0
> 14: 1321 IO-APIC-edge ide4
> 15: 1330 IO-APIC-edge ide5
> 18: 822 IO-APIC-level eth0, eth1
> 19: 14157 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
> 21: 33962 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
> 22: 0 IO-APIC-level VIA8233
> NMI: 0
> LOC: 208855
> ERR: 0
> MIS: 0
Interesting, isn't it? Even though the UHCI controllers are unable to
generate interrupts, you're still getting thousands of interrupts requests
on IRQ 21.
> Looking at dmesg or /var/log/mesages shows a huge number of :
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.0: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.1: IRQ, status = 0
> Jul 12 19:36:58 totor kernel: uhci_hcd 0000:00:10.2: IRQ, status = 0
>
> (3043 similar lines...)
>
> ...immediately at startup, then it stops complaining
>
> The interesting thing is that I unplugged my USB mouse at 19:45 -- nothing
> happened, and plugged it back at 19:45:40, while looking at a "tail
> -f /var/log/messages"
>
> And see what happened in the attached copy of my /var/log/messages for this
> session...
>
> Doesn't mean anything to me ;-) but I hope it will be of some help for you...
Status = 0 means the UHCI controller has no reason to request an
interrupt. Given the good record of your hardware in the past, this
probably means that the controllers really were not generating interrupt
requests. The alternative is that one of them _is_ generating an IRQ when
it's not supposed to -- this seems pretty unlikely.
On the other hand, _something_ was generating an interrupt request that
got mapped to IRQ 21 by the hardware. And these requests do seem to be
associated with USB activity. Maybe the EHCI controller is responsible?
One of your postings showed both uhci_hcd:usb2 and ehci_hcd:usb4 mapped to
IRQ 11. That could indicate a shared signal line, which is currently
being mapped incorrectly.
You can test this a couple of ways. The easiest is to rmmod ehci_hcd, or
prevent it from being loaded in the first place, by renaming
/lib/modules/.../drivers/usb/host/ehci_hcd.ko so that modprobe can't find
it. Also your BIOS may offer the option of disabling USB 2.0 support
entirely. Try doing this under the kernel that has the test patch
installed.
Without ehci_hcd loaded, the EHCI controller should not generate any
interrupt requests. If your problem then goes away, and plugging or
unplugging the mouse doesn't cause anything unusual to happen, that will
be a pretty clear indication.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 18:57 ` Alan Stern
@ 2005-07-12 20:40 ` Michel Bouissou
2005-07-12 21:37 ` Alan Stern
0 siblings, 1 reply; 26+ messages in thread
From: Michel Bouissou @ 2005-07-12 20:40 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Mardi 12 Juillet 2005 20:57, Alan Stern a écrit :
> On the other hand, _something_ was generating an interrupt request that
> got mapped to IRQ 21 by the hardware. And these requests do seem to be
> associated with USB activity. Maybe the EHCI controller is responsible?
> One of your postings showed both uhci_hcd:usb2 and ehci_hcd:usb4 mapped to
> IRQ 11. That could indicate a shared signal line, which is currently
> being mapped incorrectly.
>
> You can test this a couple of ways. The easiest is to rmmod ehci_hcd, or
> prevent it from being loaded in the first place, by renaming
> /lib/modules/.../drivers/usb/host/ehci_hcd.ko so that modprobe can't find
> it. Also your BIOS may offer the option of disabling USB 2.0 support
> entirely. Try doing this under the kernel that has the test patch
> installed.
I've tested as you suggest :
- Disabled USB 2.0 in BIOS
- Renamed ehci_hcd.ko so that modprobe can't find it
- Booted the test-patched kernel with same options as previously, MOUSE
UNPLUGGED.
- After boot "cat /proc/interrupts" shows "0" count for IRQ 21
- Nothing special isn't logged anymore in dmesg or /var/log/messages.
- Plugging / unplugging the mouse or other devices doesn't cause anything
visible to happen. Nothing gets logged, IRQ 21 counter stays at 0. I could as
well not have done it ;-)
> Without ehci_hcd loaded, the EHCI controller should not generate any
> interrupt requests. If your problem then goes away, and plugging or
> unplugging the mouse doesn't cause anything unusual to happen, that will
> be a pretty clear indication.
Well, so that's a pretty clear indication, but surely clearer to you than to
me ;-)
So, what's up, doc ? ;-))
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 20:40 ` Michel Bouissou
@ 2005-07-12 21:37 ` Alan Stern
2005-07-12 22:01 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Alan Stern @ 2005-07-12 21:37 UTC (permalink / raw)
To: Michel Bouissou; +Cc: Protasevich, Natalie, linux-kernel
On Tue, 12 Jul 2005, Michel Bouissou wrote:
> I've tested as you suggest :
>
> - Disabled USB 2.0 in BIOS
>
> - Renamed ehci_hcd.ko so that modprobe can't find it
>
> - Booted the test-patched kernel with same options as previously, MOUSE
> UNPLUGGED.
>
> - After boot "cat /proc/interrupts" shows "0" count for IRQ 21
>
> - Nothing special isn't logged anymore in dmesg or /var/log/messages.
>
> - Plugging / unplugging the mouse or other devices doesn't cause anything
> visible to happen. Nothing gets logged, IRQ 21 counter stays at 0. I could as
> well not have done it ;-)
>
> > Without ehci_hcd loaded, the EHCI controller should not generate any
> > interrupt requests. If your problem then goes away, and plugging or
> > unplugging the mouse doesn't cause anything unusual to happen, that will
> > be a pretty clear indication.
>
> Well, so that's a pretty clear indication, but surely clearer to you than to
> me ;-)
>
> So, what's up, doc ? ;-))
Then it's definite. The EHCI controller is issuing interrupt requests on
IRQ 21, but its driver is registered on a different IRQ. Hence the
interrupts aren't getting handled correctly.
So probably the usb_handoff parameter won't be needed. And if you leave
USB 2.0 disabled in the BIOS then there's no need to hide ehci_hcd.ko, as
it won't get loaded anyway. You should be able to remove the test patch
and resume normal operations.
On Tue, 12 Jul 2005, Protasevich, Natalie wrote:
> I suspect that some device is actually on the IRQ 21, and that's how its
> IO-APIC line is set up. Later on, its driver tries to assign different
> IRQ, due to some discrepancy, and the handler gets registered on say IRQ
> 11, and to a wrong pin, so the actual interrupts go unattended. If this
> what's happening, the trace will hopefully tell the story. I suggest to
> boot with "apic=debug" and also perhaps with "pci=routeirq" and collect
> the trace. You can attach the part up to the point when it reports usb
> devices set up.
At this point I can leave it up to the two of you. Now that we know which
is the offending device, it should be easy to find out why the IRQ
assignments go wrong. That certainly needs to be fixed, even though
Michel's problem appears to be solved.
Alan Stern
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 21:37 ` Alan Stern
@ 2005-07-12 22:01 ` Michel Bouissou
0 siblings, 0 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-12 22:01 UTC (permalink / raw)
To: Alan Stern; +Cc: Protasevich, Natalie, linux-kernel
Le Mardi 12 Juillet 2005 23:37, Alan Stern a écrit :
>
> Then it's definite. The EHCI controller is issuing interrupt requests on
> IRQ 21, but its driver is registered on a different IRQ. Hence the
> interrupts aren't getting handled correctly.
>
> So probably the usb_handoff parameter won't be needed. And if you leave
> USB 2.0 disabled in the BIOS then there's no need to hide ehci_hcd.ko, as
> it won't get loaded anyway. You should be able to remove the test patch
> and resume normal operations.
I've just booted an IO-APIC capable kernel without the test patch (but with
Nathalie's 2 patches), without "usb_handoff", with USB 2.0 DISABLED and USB
mouse support ENABLED in BIOS.
It seems it works good, and ehci support is not loaded.
[root@totor etc]# cat /proc/interrupts
CPU0
0: 425367 IO-APIC-edge timer
1: 1698 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 1169 IO-APIC-edge serial
7: 2 IO-APIC-edge parport0
14: 3337 IO-APIC-edge ide4
15: 3346 IO-APIC-edge ide5
16: 15142 IO-APIC-level nvidia
18: 1707 IO-APIC-level eth0, eth1
19: 25211 IO-APIC-level ide0, ide1, ide2, ide3
21: 3210 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
22: 2761 IO-APIC-level VIA8233
NMI: 0
LOC: 425302
ERR: 0
MIS: 0
Plugging or unplugging USB devices doesn't cause no IRQ insults anymore ;-)
> On Tue, 12 Jul 2005, Protasevich, Natalie wrote:
> > I suspect that some device is actually on the IRQ 21, and that's how its
> > IO-APIC line is set up. Later on, its driver tries to assign different
> > IRQ, due to some discrepancy, and the handler gets registered on say IRQ
> > 11, and to a wrong pin, so the actual interrupts go unattended. If this
> > what's happening, the trace will hopefully tell the story. I suggest to
> > boot with "apic=debug" and also perhaps with "pci=routeirq" and collect
> > the trace. You can attach the part up to the point when it reports usb
> > devices set up.
>
> At this point I can leave it up to the two of you.
Well, many thanks again for you precious help Alan !
> Now that we know which is the offending device, it should be easy to find
> out why the IRQ assignments go wrong. That certainly needs to be fixed,
> even though Michel's problem appears to be solved.
Well, it's solved by currently giving me the choice between no USB 2.0 and
IO-APIC, or USB 2.0 and no IO-APIC. That makes a temporary solution, but I'd
love to have both (and recall the happy times of 2.4x that was happy with
both ;-)
Natalie, could you please tell me which kernel (I have started to have a
number of them ;-) you'd like me << to boot with "apic=debug" and also
perhaps with "pci=routeirq" and collect the trace >>, and with which BIOS
setup ? (i.e. USB 2.0 enabled or disabled ?).
When you speak about "collecting the trace", I assume you mean the dmesg
or /var/log/messages I'll get after booting this way ?
Thanks again to both of you Alan and Natalie. Everytime I run into serious
trouble I remember why I love Free Software and the Free Software
Community ;-)
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
@ 2005-07-12 23:16 Protasevich, Natalie
2005-07-13 6:46 ` Michel Bouissou
0 siblings, 1 reply; 26+ messages in thread
From: Protasevich, Natalie @ 2005-07-12 23:16 UTC (permalink / raw)
To: Michel Bouissou, Alan Stern; +Cc: linux-kernel
> > Now that we know which is the offending device, it should
> be easy to
> > find out why the IRQ assignments go wrong. That certainly
> needs to be
> > fixed, even though Michel's problem appears to be solved.
>
> Well, it's solved by currently giving me the choice between
> no USB 2.0 and IO-APIC, or USB 2.0 and no IO-APIC. That makes
> a temporary solution, but I'd love to have both (and recall
> the happy times of 2.4x that was happy with both ;-)
>
> Natalie, could you please tell me which kernel (I have
> started to have a number of them ;-) you'd like me << to
> boot with "apic=debug" and also perhaps with "pci=routeirq"
> and collect the trace >>, and with which BIOS setup ? (i.e.
> USB 2.0 enabled or disabled ?).
At this point, you'll need to set the system back to its original state
that you started with, and have both "apic=debug" and "pci=routeirq" as
boot options. I'd say use the last kernel that you prepared with USB
support there (and all usual devices enabled in BIOS).
> When you speak about "collecting the trace", I assume you
> mean the dmesg or /var/log/messages I'll get after booting this way ?
Yes, the dmesg will have all early setup information, including
interrupts setup. With pci=routeirq, all the PCI IRQ mappings should be
there, too, and you might need to include part of /var/log/messages
where USB devices get configured.
Thanks,
--Natalie
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
2005-07-12 23:16 Protasevich, Natalie
@ 2005-07-13 6:46 ` Michel Bouissou
0 siblings, 0 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-13 6:46 UTC (permalink / raw)
To: Protasevich, Natalie; +Cc: Alan Stern, linux-kernel
Le Mercredi 13 Juillet 2005 01:16, Protasevich, Natalie a écrit :
>
> At this point, you'll need to set the system back to its original state
> that you started with, and have both "apic=debug" and "pci=routeirq" as
> boot options. I'd say use the last kernel that you prepared with USB
> support there (and all usual devices enabled in BIOS).
OK. I used the kernel that had your 2 patches anyway, as I didn't have another
APIC-capable kernel without Alan's test patch on hand. Booted with your
options.
This time, the mouse was working OK after bootup, but unplugging and
replugging it in cause the "irq 21: nobody cared" message and IRQ21 was
disabled again.
/proc/interrupts said :
CPU0
0: 114049 IO-APIC-edge timer
1: 140 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 189 IO-APIC-edge serial
7: 3 IO-APIC-edge parport0
14: 547 IO-APIC-edge ide4
15: 556 IO-APIC-edge ide5
18: 460 IO-APIC-level eth0, eth1
19: 7442 IO-APIC-level ide0, ide1, ide2, ide3, ehci_hcd:usb4
21: 10464 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
22: 0 IO-APIC-level VIA8233
NMI: 0
LOC: 113962
ERR: 0
MIS: 0
dmesg said :
0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) XP 2000+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
Getting VERSION: 40010
Getting VERSION: 40010
Getting ID: 0
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-10, 2-11, 2-17, 2-20, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 24.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 0 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 0 0 0 0 0 1 1 71
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 001 01 0 0 0 0 0 1 1 79
0d 001 01 0 0 0 0 0 1 1 81
0e 001 01 0 0 0 0 0 1 1 89
0f 001 01 0 0 0 0 0 1 1 91
10 001 01 1 1 0 1 0 1 1 99
11 000 00 1 0 0 0 0 0 0 00
12 001 01 1 1 0 1 0 1 1 A1
13 001 01 1 1 0 1 0 1 1 A9
14 000 00 1 0 0 0 0 0 0 00
15 001 01 1 1 0 1 0 1 1 B1
16 001 01 1 1 0 1 0 1 1 B9
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ21 -> 0:21
IRQ22 -> 0:22
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1674.0154 MHz.
..... host bus clock speed is 267.0864 MHz.
[...]
PCI: PCI BIOS revision 2.10 entry at 0xf9ea0, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Disabled
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:00.0
PCI: Using IRQ router default [1106/3189] at 0000:00:00.0
querying PCI -> IRQ mapping bus:0, slot:10, pin:0.
PCI->APIC IRQ transform: 0000:00:0a.0[A] -> IRQ 18
querying PCI -> IRQ mapping bus:0, slot:11, pin:0.
PCI->APIC IRQ transform: 0000:00:0b.0[A] -> IRQ 19
querying PCI -> IRQ mapping bus:0, slot:15, pin:0.
PCI->APIC IRQ transform: 0000:00:0f.0[A] -> IRQ 19
querying PCI -> IRQ mapping bus:0, slot:16, pin:0.
PCI->APIC IRQ transform: 0000:00:10.0[A] -> IRQ 21
querying PCI -> IRQ mapping bus:0, slot:16, pin:1.
PCI->APIC IRQ transform: 0000:00:10.1[B] -> IRQ 21
querying PCI -> IRQ mapping bus:0, slot:16, pin:2.
PCI->APIC IRQ transform: 0000:00:10.2[C] -> IRQ 21
querying PCI -> IRQ mapping bus:0, slot:16, pin:3.
PCI->APIC IRQ transform: 0000:00:10.3[D] -> IRQ 19
querying PCI -> IRQ mapping bus:0, slot:17, pin:0.
PCI->APIC IRQ transform: 0000:00:11.1[A] -> IRQ 22
querying PCI -> IRQ mapping bus:0, slot:17, pin:2.
PCI->APIC IRQ transform: 0000:00:11.5[C] -> IRQ 22
querying PCI -> IRQ mapping bus:0, slot:19, pin:0.
PCI->APIC IRQ transform: 0000:00:13.0[A] -> IRQ 18
querying PCI -> IRQ mapping bus:1, slot:0, pin:0.
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
[...]
Freeing unused kernel memory: 200k freed
Generic RTC Driver v1.07
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
PCI: Via IRQ fixup for 0000:00:10.0, from 10 to 5
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:10.0: irq 21, io base 0x0000cc00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.1, from 10 to 5
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#2)
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.1: irq 21, io base 0x0000d000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (#3)
usb 1-1: new low speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.2: irq 21, io base 0x0000d400
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:10.0-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
PCI: Via IRQ fixup for 0000:00:10.3, from 11 to 3
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:10.3: irq 19, io mem 0xe3009000
ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
usb 1-1: USB disconnect, address 2
EXT3 FS on dm-5, internal journal
usb 1-1: new low speed USB device using uhci_hcd and address 3
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:10.0-1
[...]
(When I unplugged the mouse:)
usb 1-1: USB disconnect, address 3
(Then plugged it back in:)
usb 1-1: new low speed USB device using uhci_hcd and address 4
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:10.0-1
irq 21: nobody cared!
[<c013cb5a>] __report_bad_irq+0x2a/0x90
[<c013c449>] handle_IRQ_event+0x39/0x70
[<c013cc83>] note_interrupt+0xa3/0xd0
[<c013c5c0>] __do_IRQ+0x140/0x160
[<c01054f2>] do_IRQ+0x32/0x70
[<c0103812>] common_interrupt+0x1a/0x20
handlers:
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
[<f8b3f2a0>] (usb_hcd_irq+0x0/0x90 [usbcore])
Disabling IRQ #21
Hope this helps...
Cheers.
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
@ 2005-07-12 21:02 Protasevich, Natalie
0 siblings, 0 replies; 26+ messages in thread
From: Protasevich, Natalie @ 2005-07-12 21:02 UTC (permalink / raw)
To: Michel Bouissou, Alan Stern; +Cc: linux-kernel
> > On the other hand, _something_ was generating an interrupt request
> > that got mapped to IRQ 21 by the hardware. And these
> requests do seem
> > to be associated with USB activity. Maybe the EHCI
> controller is responsible?
> > One of your postings showed both uhci_hcd:usb2 and ehci_hcd:usb4
> > mapped to IRQ 11. That could indicate a shared signal
> line, which is
> > currently being mapped incorrectly.
I suspect that some device is actually on the IRQ 21, and that's how its IO-APIC line is set up. Later on, its driver tries to assign different IRQ, due to some discrepancy, and the handler gets registered on say IRQ 11, and to a wrong pin, so the actual interrupts go unattended. If this what's happening, the trace will hopefully tell the story. I suggest to boot with "apic=debug" and also perhaps with "pci=routeirq" and collect the trace. You can attach the part up to the point when it reports usb devices set up.
--Natalie
^ permalink raw reply [flat|nested] 26+ messages in thread
* Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble
@ 2005-07-10 8:11 Michel Bouissou
0 siblings, 0 replies; 26+ messages in thread
From: Michel Bouissou @ 2005-07-10 8:11 UTC (permalink / raw)
To: linux-kernel; +Cc: stern, mingo
Hi there,
I use a Gigabyte GA7-VAXP motherboard that has been fine for more than 2 years
with 2.4 series kernels, and that gives trouble with 2.6.12 (and previous)
kernels.
The problem seems to sit between the UP IO-APIC and USB uhci_hcd driver.
The GA7-VAXP MB is equipped with an Athlon 2000+ XP and a VIA KT400 chipset.
Using 2.4 series kernel the IO-APIC is used just fine. Was never source of
any kind of problem.
Using 2.6.12 kernel, if the IO-APIC is enabled in the kernel configuration,
then the interrupt controlling the uhci_hcd USB controller gets disabled as
soon as uhci_hcd is initialized.
This however doesn't happen all the times. I would say that it happens at
bootup about 50% of the times. However, if the uhci_hcd happened to
initialize OK, then it will work just good until the machine is rebooted.
When it fails, I get the following messages in syslog:
Jul 9 12:28:06 totor kernel: usbcore: registered new driver usbfs
Jul 9 12:28:06 totor kernel: usbcore: registered new driver hub
Jul 9 12:28:06 totor kernel: USB Universal Host Controller Interface driver
v2.2
Jul 9 12:28:06 totor kernel: PCI: Via IRQ fixup for 0000:00:10.0, from 10 to
5
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.0: VIA Technologies, Inc.
VT82xxxxx UHCI USB 1.1 Controller
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.0: new USB bus registered,
assigned bus number 1
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.0: irq 21, io base
0x0000ac00
Jul 9 12:28:06 totor kernel: hub 1-0:1.0: USB hub found
Jul 9 12:28:06 totor kernel: hub 1-0:1.0: 2 ports detected
Jul 9 12:28:06 totor kernel: PCI: Via IRQ fixup for 0000:00:10.1, from 10 to
5
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.1: VIA Technologies, Inc.
VT82xxxxx UHCI USB 1.1 Controller (#2)
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.1: new USB bus registered,
assigned bus number 2
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.1: irq 21, io base
0x0000b000
Jul 9 12:28:06 totor kernel: hub 2-0:1.0: USB hub found
Jul 9 12:28:06 totor kernel: hub 2-0:1.0: 2 ports detected
Jul 9 12:28:06 totor kernel: PCI: Via IRQ fixup for 0000:00:10.2, from 10 to
5
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.2: VIA Technologies, Inc.
VT82xxxxx UHCI USB 1.1 Controller (#3)
Jul 9 12:28:06 totor kernel: usb 1-1: new low speed USB device using uhci_hcd
and address 2
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.2: new USB bus registered,
assigned bus number 3
Jul 9 12:28:06 totor kernel: uhci_hcd 0000:00:10.2: irq 21, io base
0x0000b400
Jul 9 12:28:06 totor kernel: hub 3-0:1.0: USB hub found
Jul 9 12:28:06 totor kernel: hub 3-0:1.0: 2 ports detected
Jul 9 12:28:06 totor kernel: PCI: Via IRQ fixup for 0000:00:10.3, from 11 to
3
Jul 9 12:28:06 totor kernel: ehci_hcd 0000:00:10.3: VIA Technologies, Inc.
USB 2.0
Jul 9 12:28:06 totor kernel: ehci_hcd 0000:00:10.3: new USB bus registered,
assigned bus number 4
Jul 9 12:28:06 totor kernel: ehci_hcd 0000:00:10.3: irq 19, io mem 0xe3006000
Jul 9 12:28:06 totor kernel: ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI
1.00, driver 10 Dec 2004
Jul 9 12:28:06 totor kernel: usbcore: registered new driver hiddev
Jul 9 12:28:06 totor kernel: hub 4-0:1.0: USB hub found
Jul 9 12:28:06 totor kernel: hub 4-0:1.0: 6 ports detected
Jul 9 12:28:06 totor kernel: usbhid: probe of 1-1:1.0 failed with error -5
Jul 9 12:28:06 totor kernel: usbcore: registered new driver usbhid
Jul 9 12:28:06 totor kernel: drivers/usb/input/hid-core.c: v2.01:USB HID core
driver
Jul 9 12:28:06 totor kernel: usb 1-1: USB disconnect, address 2
Jul 9 12:28:06 totor kernel: irq 21: nobody cared!
Jul 9 12:28:06 totor kernel: [__report_bad_irq+42/144]
__report_bad_irq+0x2a/0x90
Jul 9 12:28:06 totor kernel: [<c0136e5a>] __report_bad_irq+0x2a/0x90
Jul 9 12:28:06 totor kernel: [handle_IRQ_event+57/112]
handle_IRQ_event+0x39/0x70
Jul 9 12:28:06 totor kernel: [<c01368f9>] handle_IRQ_event+0x39/0x70
Jul 9 12:28:06 totor kernel: [note_interrupt+163/208]
note_interrupt+0xa3/0xd0
Jul 9 12:28:06 totor kernel: [<c0136f83>] note_interrupt+0xa3/0xd0
Jul 9 12:28:06 totor kernel: [__do_IRQ+240/256] __do_IRQ+0xf0/0x100
Jul 9 12:28:06 totor kernel: [<c0136a20>] __do_IRQ+0xf0/0x100
Jul 9 12:28:06 totor kernel: [do_IRQ+54/112] do_IRQ+0x36/0x70
Jul 9 12:28:06 totor kernel: [<c01050e6>] do_IRQ+0x36/0x70
Jul 9 12:28:06 totor kernel: [common_interrupt+26/32]
common_interrupt+0x1a/0x20
Jul 9 12:28:06 totor kernel: [<c0103526>] common_interrupt+0x1a/0x20
Jul 9 12:28:06 totor kernel: handlers:
Jul 9 12:28:06 totor kernel: [pg0+947137696/1069564928] (usb_hcd_irq+0x0/0x90
[usbcore])
Jul 9 12:28:06 totor kernel: [<f8b3cca0>] (usb_hcd_irq+0x0/0x90 [usbcore])
Jul 9 12:28:06 totor kernel: [pg0+947137696/1069564928] (usb_hcd_irq+0x0/0x90
[usbcore])
Jul 9 12:28:06 totor kernel: [<f8b3cca0>] (usb_hcd_irq+0x0/0x90 [usbcore])
Jul 9 12:28:06 totor kernel: [pg0+947137696/1069564928] (usb_hcd_irq+0x0/0x90
[usbcore])
Jul 9 12:28:06 totor kernel: [<f8b3cca0>] (usb_hcd_irq+0x0/0x90 [usbcore])
Jul 9 12:28:06 totor kernel: Disabling IRQ #21
Jul 9 12:28:06 totor kernel: usb 1-1: new low speed USB device using uhci_hcd
and address 3
Jul 9 12:28:06 totor kernel: input: USB HID v1.10 Mouse [Logitech USB
Receiver] on usb-0000:00:10.0-1
Jul 9 12:28:06 totor kernel: usb 3-2: new full speed USB device using
uhci_hcd and address 2
Starting there, USB devices cause trouble -- including my mouse that responds
very slowly and erratically, probably because its interrupt got disabled ?
If the kernel is compiled without support for UP IO-APIC
(CONFIG_X86_UP_IOAPIC), or booted with the "noapic" option, then this trouble
doesn't happen -- but the system doesn't use its IO-APIC, which is annoying.
Here follows other syslog boot messages that may be relevant to this IRQ
problem. Any clue ?
N.B.: I'm not subscribed to the Linux-kernel ML. Please copy me on answers.
TIA, cheers.
Jul 9 12:28:06 totor kernel: Linux version 2.6.12-3mib4v
(root@totor.bouissou.net) (gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk))
#6 Sat Jul 9 12:16:43 CEST 2005
Jul 9 12:28:06 totor kernel: BIOS-provided physical RAM map:
Jul 9 12:28:06 totor kernel: BIOS-e820: 0000000000000000 - 000000000009fc00
(usable)
Jul 9 12:28:06 totor kernel: BIOS-e820: 000000000009fc00 - 00000000000a0000
(reserved)
Jul 9 12:28:06 totor kernel: BIOS-e820: 00000000000f0000 - 0000000000100000
(reserved)
Jul 9 12:28:06 totor kernel: BIOS-e820: 0000000000100000 - 000000003fff0000
(usable)
Jul 9 12:28:06 totor kernel: BIOS-e820: 000000003fff0000 - 000000003fff3000
(ACPI NVS)
Jul 9 12:28:06 totor kernel: BIOS-e820: 000000003fff3000 - 0000000040000000
(ACPI data)
Jul 9 12:28:06 totor kernel: BIOS-e820: 00000000fec00000 - 00000000fec01000
(reserved)
Jul 9 12:28:06 totor kernel: BIOS-e820: 00000000fee00000 - 00000000fee01000
(reserved)
Jul 9 12:28:06 totor kernel: BIOS-e820: 00000000ffff0000 - 0000000100000000
(reserved)
Jul 9 12:28:06 totor kernel: 127MB HIGHMEM available.
Jul 9 12:28:06 totor kernel: 896MB LOWMEM available.
Jul 9 12:28:06 totor kernel: found SMP MP-table at 000f4c50
Jul 9 12:28:06 totor kernel: DMI 2.3 present.
Jul 9 12:28:06 totor kernel: Intel MultiProcessor Specification v1.4
Jul 9 12:28:06 totor kernel: Virtual Wire compatibility mode.
Jul 9 12:28:06 totor kernel: OEM ID: OEM00000 Product ID: PROD00000000 APIC
at: 0xFEE00000
Jul 9 12:28:06 totor kernel: Processor #0 6:6 APIC version 17
Jul 9 12:28:06 totor kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Jul 9 12:28:06 totor kernel: Enabling APIC mode: Flat. Using 1 I/O APICs
Jul 9 12:28:06 totor kernel: Processors: 1
Jul 9 12:28:06 totor kernel: Allocating PCI resources starting at 40000000
(gap: 40000000:bec00000)
Jul 9 12:28:06 totor kernel: Built 1 zonelists
Jul 9 12:28:06 totor kernel: Initializing CPU#0
Jul 9 12:28:06 totor kernel: Kernel command line: root=/dev/evms/lv_racine ro
devfs=nomount noquiet vga=791
Jul 9 12:28:06 totor kernel: PID hash table entries: 4096 (order: 12, 65536
bytes)
Jul 9 12:28:06 totor kernel: Detected 1674.892 MHz processor.
Jul 9 12:28:06 totor kernel: Using tsc for high-res timesource
Jul 9 12:28:06 totor kernel: Console: colour dummy device 80x25
Jul 9 12:28:06 totor kernel: Dentry cache hash table entries: 131072 (order:
7, 524288 bytes)
Jul 9 12:28:06 totor kernel: Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Jul 9 12:28:06 totor kernel: Memory: 1032408k/1048512k available (1820k
kernel code, 15220k reserved, 740k data, 196k init, 131008k highmem,
0k BadRAM)
Jul 9 12:28:06 totor kernel: Checking if this processor honours the WP bit
even in supervisor mode... Ok.
Jul 9 12:28:06 totor kernel: Security Framework v1.0.0 initialized
Jul 9 12:28:06 totor kernel: Capability LSM initialized
Jul 9 12:28:06 totor kernel: Mount-cache hash table entries: 512
Jul 9 12:28:06 totor kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jul 9 12:28:06 totor kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jul 9 12:28:06 totor kernel: Intel machine check architecture supported.
Jul 9 12:28:06 totor kernel: Intel machine check reporting enabled on CPU#0.
Jul 9 12:28:06 totor kernel: CPU: AMD Athlon(tm) XP 2000+ stepping 02
Jul 9 12:28:06 totor kernel: Enabling fast FPU save and restore... done.
Jul 9 12:28:06 totor kernel: Enabling unmasked SIMD FPU exception support...
done.
Jul 9 12:28:06 totor kernel: Checking 'hlt' instruction... OK.
Jul 9 12:28:06 totor kernel: ENABLING IO-APIC IRQs
Jul 9 12:28:06 totor kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Jul 9 12:28:06 totor kernel: checking if image is initramfs...it isn't (no
cpio magic); looks like an initrd
Jul 9 12:28:06 totor kernel: Freeing initrd memory: 3097k freed
Jul 9 12:28:06 totor kernel: NET: Registered protocol family 16
Jul 9 12:28:06 totor kernel: PCI: PCI BIOS revision 2.10 entry at 0xf9ea0,
last bus=1
Jul 9 12:28:06 totor kernel: PCI: Using configuration type 1
Jul 9 12:28:06 totor kernel: mtrr: v2.0 (20020519)
Jul 9 12:28:06 totor kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Jul 9 12:28:06 totor kernel: PnPBIOS: Disabled
Jul 9 12:28:06 totor kernel: PCI: Probing PCI hardware
Jul 9 12:28:06 totor kernel: PCI: Probing PCI hardware (bus 00)
Jul 9 12:28:06 totor kernel: PCI: Using IRQ router default [1106/3189] at
0000:00:00.0
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:0a.0[A] -> IRQ
18
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:0b.0[A] -> IRQ
19
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:0f.0[A] -> IRQ
19
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:10.0[A] -> IRQ
21
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:10.1[B] -> IRQ
21
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:10.2[C] -> IRQ
21
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:10.3[D] -> IRQ
19
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:11.1[A] -> IRQ
22
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:11.5[C] -> IRQ
22
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:00:13.0[A] -> IRQ
18
Jul 9 12:28:06 totor kernel: PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ
16
Jul 9 12:28:06 totor kernel: Machine check exception polling timer started.
Jul 9 12:28:06 totor kernel: apm: BIOS version 1.2 Flags 0x07 (Driver version
1.16ac)
Jul 9 12:28:06 totor kernel: audit: initializing netlink socket (disabled)
Jul 9 12:28:06 totor kernel: audit(1120904798.619:0): initialized
Jul 9 12:28:06 totor kernel: highmem bounce pool size: 64 pages
Jul 9 12:28:06 totor kernel: inotify device minor=63
[...]
--
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-07-13 6:46 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-10 18:50 Kernel 2.6.12 + IO-APIC + uhci_hcd = Trouble Protasevich, Natalie
2005-07-11 9:06 ` Michel Bouissou
2005-07-11 18:36 ` Alan Stern
2005-07-11 19:33 ` [SOLVED ??] " Michel Bouissou
2005-07-11 19:43 ` Alan Stern
2005-07-11 20:02 ` Michel Bouissou
2005-07-11 20:16 ` Alan Stern
2005-07-11 20:46 ` Michel Bouissou
2005-07-11 20:58 ` Michel Bouissou
2005-07-11 21:21 ` [NOT solved] " Michel Bouissou
2005-07-11 21:21 ` [SOLVED ??] " Alan Stern
2005-07-11 21:34 ` Michel Bouissou
2005-07-12 1:54 ` Alan Stern
2005-07-12 7:54 ` Michel Bouissou
2005-07-12 14:12 ` Alan Stern
2005-07-12 17:03 ` Michel Bouissou
2005-07-12 18:15 ` Alan Stern
2005-07-12 18:16 ` Michel Bouissou
2005-07-12 18:57 ` Alan Stern
2005-07-12 20:40 ` Michel Bouissou
2005-07-12 21:37 ` Alan Stern
2005-07-12 22:01 ` Michel Bouissou
-- strict thread matches above, loose matches on Subject: below --
2005-07-12 23:16 Protasevich, Natalie
2005-07-13 6:46 ` Michel Bouissou
2005-07-12 21:02 Protasevich, Natalie
2005-07-10 8:11 Michel Bouissou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).