Alan Stern wrote:
I've found an article suggesting to
echo Y > /sys/module/usbcore/parameters/old_scheme_first
Very funny.
You mean this shouldn't work?
Pete Zaitcev wrote that, not me. Presumably he did mean that it won't
work.
Well, if it doesn't work, I hope it won't hurt either.
After this hub failure, every boot with the patched kernel failed to
bring up the hub again. I get:
Wait a minute. The patched kernel worked with the hub to begin with, but
then it stopped working? And it hasn't worked ever since then? Even if
you power down both the computer and the hub between reboots? That sounds
more like a hardware failure than a software error.
It was exactly as you say. Whenever I'm using a kernel with ehci_hcd
enabled, the USB behaviour (of the hub, not the computer) becomes
unstable; this was also true before the patch, albeit not in such a long
sequence. I take it for possible that the few times the patched kernel
ran properly were a mere coincidence.
As soon as I use a kernel with ehci_hcd disabled though, the USB
behavior is stable ... I will now build a kernel with ehci_hcd enabled
only, just to see if there is an interference (1).
Btw, there are some sub-options under the ehci_hcd kernel parameter. I
currently have the following settings (with the patched kernel):
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
Now I have:
- a 2.6.8 vanilla debian kernel which I only use in case of emergency.
The hub dies when I boot into it.
- a 2.6.11.10 kernel from 2005-06-16. I didn't have the hub then, and
of course, it doesn't support the hub (ehci_hcd enabled). I use this
kernel to sync with my treo, since it's the only one under which udev
runs my visor/palm/treo rule (I have written the rule when this kernel
was running).
- a 2.6.12.4 kernel from 2005-08-12. In this kernel, I have disabled
ehci_hcd, so the hub works, but my udev rule does not (this is utterly
weird: what has a kernel version to do with whether udev runs a rule in
/etc/udev/rules.d/00_local_rules or not?!?) Udev recognizes the palm (I
see it in lsusb as soon as I press the sync button; I also get the
entries /sys/bus/usb-serial/devices/ttyUSB{1,2}).
- a 2.6.12.4 kernel from 2005-08-31 with Alan's patch applied. This ran
until I tried a hotsync and switched the cable to the PC USB connector.
I did not recognize the Treo.
It wasn't my patch. Even though I suggested you try it, the patch was
written by David Brownell.
Errh, so I'll refer to it as the full patch from now on...
Now let me get this straight. You have two otherwise identical
2.6.12.4 kernels, which differ only by that one patch. The one without
the patch works when you plug in the hub and the one with the patch does
not (even with nothing plugged into the second USB port). Is that
correct? Or are there other differences between the two kernels?
You refer to the 2005-08-12 and the (patched) 2005-08-31? These kernel
have a difference in that the older one has ehci_hcd disabled. The
2005-06-16 is almost like the (patched) 2005-08-31 (a lesser version,
but instead with ehci_hcd enabled), but both kernels won't work with the
hub. The hub always runs /reliably/ when ehci_hcd disabled, and
sometimes (actually rarely) when ehci_hcd enabled.
That's why I think the problem must be either with ehci_hcd or an
interaction between ehci_hcd and uhci_hcd.
The error messages in your logs above show the hub apparently
disconnecting itself from the USB bus. They could indicate a problem with
the hub or with the EHCI driver. However the patch does not alter
ehci-hcd at all.
This would corroborate my theory that the successful operation of the
patched kernel in the beginning was a mere coincidence I attributed to
the patch.
A simplified version of that patch was posted recently;
maybe you'll have better luck using it instead of the full-blown patch:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112551468126219&w=2
I'll try it (2) and report the outcome (but not after the first 2-3
boots this time =;)
Note that you don't have to disable ehci-hcd in the kernel configuration
to prevent it from being used. Provided you compiled it as a module, you
can simply rmmod it whenever you want.
I'll try that (3). I particularly wonder whether the port lights will
turn on with the patched kernel as soon as I rmmod ehci_hcd.
Which version of udev are you using? Is it the version currently
distributed with Fedora 3? That version doesn't work with 2.6.12 kernels.
$ udevinfo -V
udevinfo, version 056
I don't know which version Fedora 3 is using, as I'm using debian 3.1.
I posted a fix for it:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163438
(see especially comment #8). Redhat seems to be taking its time about
issuing an update.
My problem is still different. While udev (or hotplug) detects the Treo
(Palm), makes its entries in /sys/bus/usb-serial/device, which is also
reflected in lsusb, the /dev/ttyUSB* entries are missing, and so is the
symlink /dev/pilot. The rule I set is:
$ cat /etc/udev/rules.d/010-udev.rules
BUS="usb-serial",ID="ttyUSB1",NAME="%k",SYMLINK="pilot",MODE="0666"
This rule works fine with the 2.6.11.10 kernel from 2005-06-16, but not
with the later ones. This may actually point at a version breach, and
thereby at the solution: I should build a 2.6.11.10 kernel with
ehci_hcd disabled (4). I'll report on this detour, too.
--
Thanx and hasta luego.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
