Distribution:Gentoo Linux 1.4 Hardware Environment: Via KT400 Motherboard (Soltek 75-frv), AMD Athlon-xp, "noname" IDE to USB 2.0 case, Hitachi hard drive 80Go. Software Environment: GNU, cat from "GNU coreutils" Problem Description: First, please excuse for annoying you if the problem is on my side, and for my bad english, and for being a newbie. I promise you that i've googled and RTFM and everything. The problem is that a new hardware, certified by the vendor to be UMS-compliant, is shortly acessible then hang; altough it work "well" (as well as the rest) on a win2k PC. My USB mouse works when i connect it to the same port. The most strange is that onetime I was even able to mount a partition and copy 20Go to it. But then i've done a "cat..." and disk hanged. It also hang when reiserfs try to replay log. Perhaps it's when i acess to certain sectors of the disk or to too concomitant sectors ? I've tried with and without "new taskfile code", "preemptible kernel" and "usbfs" (among others). The usb (1.1) key of my brother works on the same connector. Steps to reproduce: 1- Connect the peripheral. 2- Do a cat /dev/sda (or a hdparm -t /dev/sda or wathever) 3- Wait. After 3 lines, cat hangs and kernel seems to do the same thing in loop. 4- If i wait very long, cat die with "cat: /dev/sda: Erreur d'entr
Created attachment 2084 [details] The dmesg before i connect the peripheral
Created attachment 2085 [details] The dmesg close after i connect it
Created attachment 2086 [details] The dmesg close after the cat
Created attachment 2087 [details] The dmesg after cat died
If I connect it during the boot phase of the kernel (before EHCI initialisation ?), it works but at USB 1.1 speed. So i've thinked that this is a bug of EHCI driver and moved it to this category, please correct me if it is a mistake.
Created attachment 2096 [details] The dmesg output after reiserfs crash I've told about crash just while mounting reiserfs partition; this time I've logged it. Kernel say that there is a bug in "fs/reiserfs/prints.c:339"; but i'm not sure of it because the disk could have simply became suddenly unreachable. Also, as those crash of reiserfs block all sync or mount/umount and so can lead to loss of data, i've changed severity to High (according to the Bugzilla help). Please excuse me if this is exagerated.
If that can help, i've founded the datashet of the chip included in this case (PDF). http://www.genesyslogic.com/eimages_product/GL811EDatasheet_111.pdf
First, this is a Genesys Logic device. They have compatibility problems with Linux which appear to be chip bugs (in some chips). However, this could be something else.... What makes this case interesting is that the reset-recovery seems to work here, at least some. We can get back into a state where we can exchange commands with the device (TEST_UNIT_READY, etc.) repeatedly, but we can't seem to get that big data exchange to work. With most complaints about GL devices, we can never get back into a good state. David -- perhaps this would be a good candidate for your EHCI debugging patches? If those don't show anything, then I'm going to write this off as another bad Genesys Logic unit. Also, the crashes coming from the ReiserFS code should be looked at by the ReiserFS people. It looks like they can't handle journal recovery on flaky disks.
Created attachment 2258 [details] Reduce transfer rate Try this patch, which reduces the transfer throughput.
An entire month has passed with no new data. Closing as "Insufficient Data"