On Thu, 1 Sep 2005, Dominik Wezel wrote: > Hi all again > > >>>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. > >>Borrow one for testing. > > Who'd do that? I'd have to buy one. My budget is very tight, > particularly in the light of the option that the other hub might also > have its caprice. But if all else fails, I'll reconsider the advice =:) > > >>Also, plug Palm directly into computer. Surely it has more than one > >>USB connector. > > Yes, it has 2 of them. However, plugging the Palm cable into the > computer directly didn't help (actually it broke something, see below). > I have two cables, one of which I would rather leave plugged in, so > the hub might be the better choice all else being equal. > > > It looks to me more like a timing problem with initialization of the > > external high-speed hub. Try this patch: > > > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112439094723976&w=2 > > I've tried the patch. First, everything seemed to work well, but then I > noticed that I wasn't able to sync my Treo. I plugged it directly into > the computer's 2nd USB slot (see comments above), but then the lights on > the hub turned suddenly off. Just to clarify: The Palm and the Treo are in fact the same device, yes? > Afterwards I found out that the failing recognition of the palm is yet > another problem to be solved (udev doesn't execute the rule I've written > for it; this worked on the unpatched kernel in which ehci_hcd is enabled > and seems to have "precedence" over uhci ... it didn't work either with > the kernel only supporting uhci_hcd). > > 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. > ---8<--- > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: state 5 ports 6 chg 0000 > evt 0008 > Sep 1 13:38:36 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001803 POWER sig=j CSC CONNECT > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: port 3, status 0501, change > 0001, 480 Mb/s > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: debounce: port 3: total > 100ms stable 100ms status 0x501 > Sep 1 13:38:36 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001002 POWER sig=se0 CSC > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -107 > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: state 5 ports 6 chg 0000 > evt 0008 > Sep 1 13:38:36 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001803 POWER sig=j CSC CONNECT > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: port 3, status 0501, change > 0001, 480 Mb/s > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: debounce: port 3: total > 100ms stable 100ms status 0x501 > Sep 1 13:38:36 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001004 POWER sig=se0 PE > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -107 > Sep 1 13:38:36 solaris kernel: hub 4-0:1.0: state 5 ports 6 chg 0000 > evt 0008 > ---8<--- > > This goes on for about a dozen pages, interspersed with messages from > other devices coming up. Later on, I also have: > > ---8<--- > Sep 1 13:38:39 solaris kernel: hub 4-0:1.0: state 5 ports 6 chg 0000 > evt 0008 > Sep 1 13:38:39 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001803 POWER sig=j CSC CONNECT > Sep 1 13:38:39 solaris kernel: hub 4-0:1.0: port 3, status 0501, change > 0001, 480 Mb/s > Sep 1 13:38:39 solaris kernel: hub 4-0:1.0: debounce: port 3: total > 100ms stable 100ms status 0x501 > Sep 1 13:38:39 solaris kernel: ehci_hcd 0000:00:1d.7: port 3 high speed > Sep 1 13:38:39 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001005 POWER sig=se0 PE CONNECT > Sep 1 13:38:39 solaris kernel: usb 4-3: new high speed USB device using > ehci_hcd and address 84 > Sep 1 13:38:39 solaris kernel: ehci_hcd 0000:00:1d.7: devpath 3 ep0out > 3strikes > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001002 POWER sig=se0 CSC > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -107 > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: port 3 reset > error -110 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: hub_port_status failed (err > = -32) > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -32 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port 3 not enabled, trying > reset again... > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001803 POWER sig=j CSC CONNECT > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -22 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port 3 not enabled, trying > reset again... > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001002 POWER sig=se0 CSC > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -107 > Sep 1 13:38:40 solaris kernel: usb 4-3: device not accepting address > 84, error -22 > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001002 POWER sig=se0 CSC > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -107 > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: port 3 reset > error -110 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: hub_port_status failed (err > = -32) > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -32 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port 3 not enabled, trying > reset again... > Sep 1 13:38:40 solaris kernel: ehci_hcd 0000:00:1d.7: GetStatus port 3 > status 001803 POWER sig=j CSC CONNECT > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port_wait_reset: err = -22 > Sep 1 13:38:40 solaris kernel: hub 4-0:1.0: port 3 not enabled, trying > reset again... > ---8<--- > > So I'm again using the old kernel with ehci_hcd disabled, this being the > least impeding version (in order to sync my treo, I have to reboot into > a kernel with ehci_hcd support [which will also honor my udev rule], but > at least the hub reliably serves my keyboard and mouse). > > Albeit I can live with the status quo, I'd really like to get this > fixed, so I'm still standing here ... =:) > Unfortunately my know how on USB is far too small, and I can't get > into it, as I have only so much spare time left as to write to this list > and do a couple of beta tests per week on my machine, which btw isn't a > spare server or so, but a productive laptop --- so I can't go and > install windoze just for testing how the hub would behave unter abnormal > conditions ... besides that I'm afraid my laptop would bite my hand if I > tried =;) > > 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. 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? 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. 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 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. > For me, perhaps the way to go is find out why udev doesn't run my rule > with the 2.6.12.4 kernel from 2005-08-12. If I can somehow motivate or > convince udev to run this rule, things are fine for me (until I need to > plug a device that requires ehci_hcd, i.e. a hi-speed only device, of > course). For the kernel USB team, I guess I can contribute in another > way. If you guys are willing to help me a bit here, I'm willing to go > into beta mode and share my findings. Otherwise, I'll rather try to > break the udev resistence, as it's closer to my knowledge. Which way > should I go? 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. 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. Alan Stern ------------------------------------------------------- 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
