Re: [linux-usb-devel] trouble with hdd on usb2-ide bridge
Moe Wibble wrote: http://mbox.bz/pub/lsusb-v-before.txt [17k, before timeout] http://mbox.bz/pub/lsusb-v-after.txt [16k, after timeout] After the device went bad lsusb announces protocol errors while querying it. That's not surprising but I put the after- output there too, for completeness. That one message seems to happen because the config descriptor's wTotalLength is one byte too big. Not enough quality assurance... You are right. I overlooked it before but it really is a GeneSys. Do you happen know an usb2-ide bridge (sold in a 2.5 external hdd-case?) that definately works in linux 2.4? I don't use them enough to recommend one, but only this newish batch of GeneSys-based devices seems to be generating significant problem reports. You might be able to turn up some more information with this EHCI diagnostic patch (for 2.4), which just dumps the hardware data structures at the moment usb-storage times out the transfer. What it's shown in similar cases is that the GeneSys adapter got part way through a transfer and then stopped responding. ... The additional debug messages reveal that the device behaves just the way you described (if i parse them right that is). It seems to block in the middle of transfer and times out. That's my reading too. More specifically, the device locks up solid, part way through the write -- solid enough that it won't even reset properly. One person had better luck after applying a patch that slowed down EHCI on an NForce2 southbridge ... the fact that it even mattered is in indication of problems in the GeneSys device. I assume the wintendo drivers use a similar hack to make the Not on that ALI controller they don't -- it doesn't support the relevant hardware feature, so it can't be turned off! If I were to guess at hacks, my first one would be just to throttle the write rate down by pausing periodically, on the theory that it locks up when it can't buffer for some reason. (This was a big series of writes, shorter ones were ok...) It might be worth having usb-storage have a quirk for this device. Maybe just emit a warning when it's running at high speed, if there's no workaround we can apply. thing work then. What really pi**es me off right now is that the case has the USB2.0-logo printed on it. Yet another worthless cert... Not entirely, but it's more focussed on basics (which have been problematic on occasion) than on bugs that somehow don't appear except with non-MSFT drivers. Again, that's a vendor quality assurance issue: they didn't test with Linux. - Dave --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] trouble with hdd on usb2-ide bridge
)On Tue, 30 Sep 2003, Moe Wibble wrote: hello, i have a problem with a hdd in an external usb-ide-case. the drive works fine when plugged into one of the onboard usb-ports (usb1.0). when i try to use it with my pci usb 2.0 controller it behaves very strange. it works for about a minute (or a couple of read/write operations) but then freezes the whole machine for a moment (sometimes about 20s, sometimes so short its barely noticable) and then, well, crashes and burns. below appended is the (commented) syslog transcript of a test-session. i did: 1. boot the machine with the drive plugged into the usb 2.0 controller (it is properly recognized and works fine at first...) 2. mount the drive 3. copy a large file to the drive (which reproducably fails after about ~450M) 4. curse can anybody make sense of this? i have seen other people report similar problems with usb2-ide bridges, is there a fix available or in the works? environment: - vanilla kernel 2.4.22 (no patches) - USB Controller: Acer Laboratories Inc. [ALi] USB 2.0 Controller (rev 01) [pci card] - USB Controller: VIA Technologies, Inc. USB (rev 23) [onboard] - the external usb-ide case is a cheapo bulk thing in silver aluminium. it has the word BEN and the new USB 2.0 logo printed on it in blue. the drive works fine on the usb2-controller in win98. Have you tried running 2.6.0? Debugging will be easier in that environment. It has a sysfs file that exposes the internal state of the EHCI driver. The contents of that file at the time you get the freezes and the control/bulk timeout messages might be very revealing. Also, debugging the USB drivers might be easier if you don't use a USB mouse at the same time. And using a normal console screen rather than an X window can help; maybe you're already doing that. Lastly, there is a setting in the EHCI driver that affects how rapidly it sends packets. I can't remember what that setting is or where to find it in the source files, but David Brownell (author of the EHCI driver) monitors this mailing list and he ought to be able to help. Alan Stern --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] trouble with hdd on usb2-ide bridge
Moe Wibble wrote:
1. boot the machine with the drive plugged into the usb 2.0 controller
(it is properly recognized and works fine at first...)
2. mount the drive
3. copy a large file to the drive (which reproducably fails after about ~450M)
4. curse
can anybody make sense of this?
i have seen other people report similar problems with usb2-ide bridges,
is there a fix available or in the works?
...
13:12:06 sim k: hub.c: port 6, portstatus 503, change 10, 480 Mb/s
13:12:06 sim k: hub.c: new USB device 00:0e.3-6, assigned address 2
13:12:06 sim k: usb.c: kmalloc IF dfdabd40, numif 1
13:12:06 sim k: usb.c: descriptor data left
Hmm, can you forward lsusb -v output for this device?
I'm curious what's up with those descriptors.
And the rest of the debug log ... with initialization dump
for the EHCI controller, at 00:0e.3 ? Looks like that
was immediately before what you sent.
13:12:06 sim k: usb.c: new device strings: Mfr=0, Product=1, SerialNumber=0
13:12:06 sim k: usb.c: USB device number 2 default language ID 0x409
13:12:06 sim k: Product: USB TO IDE
13:12:06 sim k: scsi1 : SCSI emulation for USB Mass Storage devices
...
The first thing that comes to mind is that this looks like one
of those GeneSys devices that have been causing problems. The
diagnostic with descriptor data left seems to be a new clue.
You might be able to turn up some more information with this
EHCI diagnostic patch (for 2.4), which just dumps the hardware
data structures at the moment usb-storage times out the transfer.
What it's shown in similar cases is that the GeneSys adapter
got part way through a transfer and then stopped responding.
One person had better luck after applying a patch that slowed
down EHCI on an NForce2 southbridge ... the fact that it even
mattered is in indication of problems in the GeneSys device.
But I have no idea if your ALI hardware even implements the
feature being turned off (you snipped the 00:0e.3 init info).
Also, as Alan Stern commented, it's worth trying this on 2.6
kernels. If nothing else, the usb-storage/scsi fault recovery
code is more robust there, and you're using it to recover from
this problem.
- Dave
--- 1.16/drivers/usb/host/ehci-q.c Thu Jun 19 06:51:52 2003
+++ edited/ehci-q.c Sun Aug 10 12:06:53 2003
@@ -267,6 +267,7 @@
unsignedcount = 0;
int do_status = 0;
u8 state;
+ u8 dumped = 0;
if (unlikely (list_empty (qh-qtd_list)))
return count;
@@ -347,6 +348,19 @@
do_status = 0;
continue;
}
+#if 1
+ switch (urb-status) {
+ default:
+ break;
+ case -ECONNRESET: /* canceled */
+ case -ENOENT:
+ if (!dumped) {
+ dumped = 1;
+ dbg_qh (cancel, ehci, qh);
+ }
+ dbg_qtd (cancel, ehci, qtd);
+ }
+#endif
/* token in overlay may be most current */
if (state == QH_STATE_IDLE
Re: [linux-usb-devel] trouble with hdd on usb2-ide bridge
On Wed, Oct 01, 2003 at 09:58:24AM -0700, David Brownell wrote: Moe Wibble wrote: 1. boot the machine with the drive plugged into the usb 2.0 controller (it is properly recognized and works fine at first...) 2. mount the drive 3. copy a large file to the drive (which reproducably fails after about ~450M) ... 13:12:06 sim k: hub.c: port 6, portstatus 503, change 10, 480 Mb/s 13:12:06 sim k: hub.c: new USB device 00:0e.3-6, assigned address 2 13:12:06 sim k: usb.c: kmalloc IF dfdabd40, numif 1 13:12:06 sim k: usb.c: descriptor data left Hmm, can you forward lsusb -v output for this device? I'm curious what's up with those descriptors. I've put it here: http://mbox.bz/pub/lsusb-v-before.txt [17k, before timeout] http://mbox.bz/pub/lsusb-v-after.txt [16k, after timeout] After the device went bad lsusb announces protocol errors while querying it. That's not surprising but I put the after- output there too, for completeness. And the rest of the debug log ... with initialization dump for the EHCI controller, at 00:0e.3 ? Looks like that was immediately before what you sent. Sorry, I trimmed too much by accident. Here is the uncut version: http://mbox.bz/pub/kern.log [1.7M] or http://mbox.bz/pub/kern.log.bz2 [ 73k] 13:12:06 sim k: usb.c: new device strings: Mfr=0, Product=1, SerialNumber=0 13:12:06 sim k: usb.c: USB device number 2 default language ID 0x409 13:12:06 sim k: Product: USB TO IDE 13:12:06 sim k: scsi1 : SCSI emulation for USB Mass Storage devices ... The first thing that comes to mind is that this looks like one of those GeneSys devices that have been causing problems. The diagnostic with descriptor data left seems to be a new clue. You are right. I overlooked it before but it really is a GeneSys. Do you happen know an usb2-ide bridge (sold in a 2.5 external hdd-case?) that definately works in linux 2.4? Just in case this one doesn't work out... You might be able to turn up some more information with this EHCI diagnostic patch (for 2.4), which just dumps the hardware data structures at the moment usb-storage times out the transfer. What it's shown in similar cases is that the GeneSys adapter got part way through a transfer and then stopped responding. I just attacked the drive again, with the patch applied and USB Mass Storage debug verbosity enabled. Here is the relevant parts from the log of that session: http://mbox.bz/pub/kern_ehci-debug.log [2.2M] or http://mbox.bz/pub/kern_ehci-debug.log.bz2 [ 18k] The full log was 103M. I cut out large chunks of the repeated error messages to bring it down to a reasonable size. The cut out parts were replaced with a few hundred hash-lines. So you can skip to the next part of the log by searching for . The additional debug messages reveal that the device behaves just the way you described (if i parse them right that is). It seems to block in the middle of transfer and times out. One person had better luck after applying a patch that slowed down EHCI on an NForce2 southbridge ... the fact that it even mattered is in indication of problems in the GeneSys device. I assume the wintendo drivers use a similar hack to make the thing work then. What really pi**es me off right now is that the case has the USB2.0-logo printed on it. Yet another worthless cert... But I have no idea if your ALI hardware even implements the feature being turned off (you snipped the 00:0e.3 init info). Also, as Alan Stern commented, it's worth trying this on 2.6 kernels. If nothing else, the usb-storage/scsi fault recovery code is more robust there, and you're using it to recover from this problem. Unfornationally I cannot switch to 2.6 at this time[1] but I will try it once soon, just to see if the bridge works in there. Thanks for your advice so far. Best regards Moe [1] I Need VMWare and I doubt the kernel-modules will work in 2.6 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
