Hi,
As some of you may remember, I'm one of the unfortunate GL811e-based HDD
enclosure owners, who are trying to use it under Linux... And with my desktop
PC, even with all the recent patches discussed in this list, the bloody box
crashes constantly on writing attempts... However, there are som
> Compared to the previous "fix" CPU usage during USB transfer is much
> > lower.
> > In contrast to the audio driver (snd_intel8x0) the driver also seems to
> > handle ACPI and S3 just fine.
>
> On Thu, 15 Jul 2004, Max Zaitsev wrote:
> > Tested it on my GL811E
Tested it on my GL811E enclosure yesterday. Negative. Writing 4GB of zeroes
to /dev/sda1 kills the box with the 100% probability. I've tried increasing
the delay to 600, but that gave nothing. Sorry about the bad news :-(
Regards,
Max
On Monday 21 June 2004 22:09, Alan Stern wrote:
> I made up
> FYI, that command means to send one billion blocks where each block is
> 16 MB. Altogether that makes for a 16 exabyte transfer -- I could
> understand that crashing your drive. :-)
>
Well, you are wright and I was wrong. But I have an excuse because I'd just
came from a party that time... :-))
> Maybe not. If you haven't already, take a look at this thread:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107962180123336&w=2
>
> You should see if your device behaves in the same way.
>
it does not crash with that short sequence (see my other post)
> > Actually, another sanity check
I couldn't crash my drive with the byte sequence given. However, it crashes if
I try to transfer 1GB of zeroes:
dd if=/dev/zero of=/dev/sda8 bs=16M count=1G
kills the device with a 100% probability. With regard to Windows -- I've
managed to copy 30-40 GB of media files to the drive and did not
Hi folks,
I've tried the described experiment and what I've seen seem to tell me that
it's really the device controller, who dies rather than anything in the host.
First of all, when the controller dies the "connection" LED on the USB hub
goes down. Secondly, the other USB2 device (usb-stick) c
> You know, I didn't realize it at first, but that's rather surprising.
> The CSW patch should not have made any difference at all to the failure
> mode you were seeing. All it did was tell the computer to expect a larger
> CSW packet _from_ the drive; it did not affect the data being sent _to_
>
> The error in the log you attached does look very much like the sort of
> thing we typically see with Genesys devices. The activity LED remaining
> on just indicates that the controller has crashed. I have no idea why
> writing and reading should behave any differently. Have you tried doing
> l
Hi Alan,
> There are lots of messages in the usb-devel mailing list archives from
> people having trouble with Genesys devices. You could try searching there
> for solutions. For example, here's one message that might help:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107525535629425&w=
Hi List,
I've initially sent this post to usb-users abd was redirrected here as the
problem seems to be too technical / low level.
I have a problem with the combo USB2/Firewire HDD enclosure. The box runs
under windows, but gives problems under linux. As I connect the drive to my
box it gets r
11 matches
Mail list logo
