My guess is for a problem with the driver as well ! The problem is that i've searched for a solution and the only one that may have anything to do with it is for 2.6 (Fedora Core 2). Since the patch that i've seen is for that particular kernel, my guess is that it will unfortunately also be a problem with Fedora Core 2. I may look into if the 2.6 fix can also be applied for 2.4. But I just need to find it again since i initially dumped it because i did not think it would apply to a 2.4 kernel. Lasse On Wednesday 10 March 2004 23:58, Keith Lofstrom wrote: > Lasse K. Christiansen <lasse@xxxxxxxxxxxxxxxxx> writes about a problem > > with his Maxtor 300GB USB2 drive: > > The problems is that it mounts just fine and works for a brief period of > > time (not sure that it uses USB2 driver on my machine though) and in the > > middle of copying files it stops working and tells me that it cannot copy > > files. Invalid Block device and i cannot unmount it. > > > > Only solution that i've found is a reboot ! and then it works for a > > couple of minutes again. > > ... > > > Have anyone seen anything similar ?? I've encountered this issue with all > > kernel for Fedora core 1 that i've tried. When booting knoppix and trying > > to copy files it just works ?? > > Keith Lofstrom replies: > > I see the very same thing, on Redhat 9 and on Fedora Core 1. You do not > need to reboot; rmmod'ing and insmod'ing the usb drivers, then plugging > and unplugging the USB, will probably make your drive come back. > > In my case, this occurs with a Sanmax InClose USB2-to-ATA6 swap cage. > This uses the Cypress chipset. I do NOT see the same problem with the > similar but slower ViPower swap cage. While I don't know the details > of implementation, I strongly suspect a bug in the USB2 driver. I am > lazy, however. Rather than track this down, submit a bug to bugzilla, > and watch nothing happen, I thought I would wait to see if the problem > is fixed in Fedora Core 2 before raising a fuss. Wrong move. Sorry. > > The Cypress chipset in the Sanmax has larger FIFOs, and runs twice as > fast as the Vipower cage does. However, throttling down the transfer > rate with a program with built-in delays does not help. The system > goes for an *average* of 40GB before hanging, and producing the error > messages you mention. However, it seems purely random, and sometimes > it can move 80GB without a problem, and sometimes it hangs after 1GB. > > Engineer Jack Mich at Sanmax did some tests on their product under > Windows. No problems observed. He says they are using the Cypress > recommended code in their product. This, and the fact that the > rmmod/insmod trick works, also points at a driver bug. > > For more details, see http://www.keithl.com/usb2bug.html . > > I have other ways of accessing my big drives; obviously, you do not > have that luxury. I am not much of a programmer, but I can compile > a kernel, and have a spare machine to run the tests on. If there are > any experiments I can run to help isolate the bug, I can try to fit > them into my schedule. I can also loan (via FedEx to a US address) > both a Sanmax and a ViPower swap cage to anyone who can convince me > they are ABLE and MOTIVATED to fix this bug (I'll want them back). > A usb2 card and a >=40GB test hard drive would be needed, of course. > > Lasse, forgive my complacency in not reporting this earlier; it might > have saved you from purchasing an expensive hard drive you will not be > able to immediately use. That said, it should be possible to locate the > problem in the usb code and patch it, given a sufficiently talented and > persistent programmer, and there might be one or two of those around here. > > Keith
