Keith Lofstrom wrote:
With all the chiptalk etc. My 120Gbyte Maxtor drives extremly good. I am very very careful with the USB intake though, thus with 5 usb connecttors, the drive is on the inside one...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
If your drive is mounted and you do a fsck or fs2ch, that can result in disaster, somewhow it is still flakey, th book tells that it is a usb->scsi emulation, that might be the cause of troubles mentioned above.
-- Peace is everywhere http://gershwin.xs4all.nl
