Le Dimanche 17 Juillet 2005 22:36, vous avez écrit :
> Determining whether or not the system is working shouldn't be hit-or-miss.
Hum, yes, we're not using Windows ;-)
> To start out, try to determine whether each of the UHCI controllers really
> is mapped to IRQ 21. Do this by booting with no USB devices plugged in,
> and then plugging a full- or low-speed device (like a USB mouse) into each
> of the ports in turn. Check to make sure it works in each port and that
> that counts for IRQ 21 in /proc/interrupts increase each time. To make
> this even more reliable you should run the test twice -- you don't have to
> reboot in between. The first time, rmmod ehci-hcd before plugging in
> anything; the second time modprobe ehci-hcd before plugging.
I'm afraid I won't have time for this today. It's already more than 11 PM here
and I'm leaving early tomorrow for travel...
But AFAIR, when I performed previous tests, I had tried about every USB socket
on my computer (I have 6 of them...) to the same result.
> The results you have reported make me a little suspicious. The best way
> to see whether the EHCI controller really is at fault is to plug in a
> high-speed USB device. I'm not totally familiar with the operation of
> ehci-hcd, and it's quite possible that plugging in a low- or full-speed
> device would not cause it to generate enough interrupts to be a problem --
> even though you did trigger the fault by plugging in a low-speed mouse --
> but plugging in a high-speed device ought to, provided ehci-hcd is loaded.
> Again, monitor the numbers in /proc/interrupts to see which is going up:
> IRQ 19 or IRQ 21.
Humm. I'm not sure about what you call a "full speed" device, for when I plug
my USB scanner, my kernel reports it as a "full speed" USB device, and says
it's managed by uhci (not ehci):
Jul 17 22:46:42 totor kernel: usb 3-2: new full speed USB device using
uhci_hcd and address 3
I just tried an USB flashdisk that "used to work good with 2.4" and that I
hadn't tried yet in 2.6. It's identified as "high speed" and ehci would like
to manage it, but it seems I'm out of luck in some other aspect:
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 25
totor kernel: usb 4-4: device not accepting address 25, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 35
totor kernel: usb 4-4: device not accepting address 35, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 36
totor kernel: usb 4-4: device not accepting address 36, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 38
totor kernel: usb 4-4: device not accepting address 38, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 48
totor kernel: usb 4-4: device not accepting address 48, error -71
...ad nauseam until I unplug the key...
Shhh...
Doesn't like the front panel socket ? Let me try another USB socket... Just
close to my mouse...
totor kernel: usb 4-2: new high speed USB device using ehci_hcd and address 16
totor kernel: SCSI subsystem initialized
totor kernel: Initializing USB Mass Storage driver...
totor kernel: scsi0 : SCSI emulation for USB Mass Storage devices
totor kernel: usbcore: registered new driver usb-storage
totor kernel: USB Mass Storage support registered.
Looks better, isn't it ?
Now, I checked that I can mount it and see its contents. That's OK.
I'm currently running with IO-APIC disabled, so my interrupts shows as:
[root@totor etc]# cat /proc/interrupts
CPU0
0: 12540579 XT-PIC timer
1: 22352 XT-PIC i8042
2: 0 XT-PIC cascade
4: 38647 XT-PIC serial
7: 18470 XT-PIC parport0
10: 863039 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
eth0, eth1, VIA8233, nvidia
11: 155832 XT-PIC ide0, ide1, ide2, ide3, ehci_hcd:usb4
14: 112325 XT-PIC ide4
15: 112334 XT-PIC ide5
NMI: 0
LOC: 12539533
ERR: 350
> The instability you mention is another cause for concern. It may indicate
> that at some times, or under certain circumstances, the IRQs are routed
> wrongly whereas at others they are routed correctly. And without any
> changes to the software! If this is a random hardware fault it may be
> impossible to fix. (But then why would it be so reliable under 2.4?)
I know that what I'm going to write will look crazy ;-) because it doesn't
seem to make any sense, but I've noticed a pattern that tends to emerge from
the different tests I've made with IO-APIC enabled and different 2.6.12
kernels (patches, boot options, etc...) :
1/ When I'm testing a new kernel for the first time, I usually call it
manually by typing the different relevant option manually from my grub
(bootloader) commandline, and most of the times, it works without "losing IRQ
21".
That's why I had thought, with your first suggestion of "usb-handoff" option,
that my problem was solved.
Once I believe it works and want to test it again, I then put this as the
default entry in my bootloader, then I reboot without touching anything (I
let the bootloader select its default entry), and, usually, it then fails.
So I would say that a patterns looks emerging : When I have typed things on
the keyboard at the bootloader stage, then loaded Linux, it may work. On the
contrary, when I let the machine boot by itself without having touched
anything, then I usually get these IRQ 21 losses.
Yes, I know this look completely silly ;-) but I mentioned it to be as
complete as possible about what I noticed, and that may or may not be
relevant...
Cheers.
--
Michel Bouissou <[email protected]> OpenPGP ID 0xDDE8AC6E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|