Genesys USB 2.0 enclosures

Genesys USB 2.0 enclosures

[Jan De Luyck]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

Hello lists,

(a mail for the archives)

I've posted in the past about problems with these enclosures - increasing the 
delay seems to fix it, albeit temporarily. The further you go in using the 
disk in such an enclosure, the higher the udelay() had to be - atleast that's 
what I'm seeing here (I've got two of these now :/ )

One permanent fix is adding a powered USB-hub in between the drive enclosures 
and the computer. Since I've done that, I've no longer seen any of the 
problems (i've attached the 'fault' log). Weird but true, since the drives 
come with their own powersupply.

Hope this helps anyone in the future running into the same problem.
-- 
"To vacillate or not to vacillate, that is the question ... or is it?"

[-- Attachment #2: usblog.bad --]
[-- Type: text/plain, Size: 8620 bytes --]

usb 4-3: new high speed USB device using ehci_hcd and address 8
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
  Vendor: Maxtor 6  Model: Y080P0            Rev: 0811
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: assuming drive cache: write through
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: assuming drive cache: write through
 sda: sda1
Attached scsi disk sda at scsi5, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi5, channel 0, id 0, lun 0,  type 0
usb-storage: device scan complete
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
usb 4-3: USB disconnect, address 8
scsi: Device offlined - not ready after error recovery: host 5 channel 0 id 0 lun 0
SCSI error : <5 0 0 0> return code = 0x10000
end_request: I/O error, dev sda, sector 80067680
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
scsi5 (0:0): rejecting I/O to device being removed
SCSI error : <5 0 0 0> return code = 0x10000
end_request: I/O error, dev sda, sector 80067744
scsi5 (0:0): rejecting I/O to device being removed
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bc21       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
Filesystem "sda1": Log I/O Error Detected.  Shutting down filesystem: sda1
Please umount the filesystem, and rectify the problem(s)
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bca1       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bce1       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bd21       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bd61       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bda1       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bde1       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x4c5bc61       ("xlog_iodone") error 5 buf count 32768
xfs_force_shutdown(sda1,0x2) called from line 952 of file fs/xfs/xfs_log.c.  Return address = 0xc020af08
I/O error in filesystem ("sda1") meta-data dev sda1 block 0x68f3968       ("xfs_trans_read_buf") error 5 buf count 8192
xfs_force_shutdown(sda1,0x2) called from line 717 of file fs/xfs/xfs_log.c.  Return address = 0xc020aa34
xfs_force_shutdown(sda1,0x1) called from line 353 of file fs/xfs/xfs_rw.c.  Return address = 0xc02278bd
xfs_force_shutdown(sda1,0x1) called from line 353 of file fs/xfs/xfs_rw.c.  Return address = 0xc02278bd

Re: [linux-usb-devel] Genesys USB 2.0 enclosures

[Alan Stern]

On Sat, 3 Sep 2005, Jan De Luyck wrote:

> Hello lists,
> 
> (a mail for the archives)
> 
> I've posted in the past about problems with these enclosures - increasing the 
> delay seems to fix it, albeit temporarily. The further you go in using the 
> disk in such an enclosure, the higher the udelay() had to be - atleast that's 
> what I'm seeing here (I've got two of these now :/ )
> 
> One permanent fix is adding a powered USB-hub in between the drive enclosures 
> and the computer. Since I've done that, I've no longer seen any of the 
> problems (i've attached the 'fault' log). Weird but true, since the drives 
> come with their own powersupply.
> 
> Hope this helps anyone in the future running into the same problem.

This one certainly goes into the Bizarro file.

Just out of curiosity -- when you use the powered hub, does the drive work 
even if you remove that delay completely?

Alan Stern

Re: [linux-usb-devel] Genesys USB 2.0 enclosures

[Jan De Luyck]

On Sunday 04 September 2005 03:53, Alan Stern wrote:
>
> This one certainly goes into the Bizarro file.
>
> Just out of curiosity -- when you use the powered hub, does the drive work
> even if you remove that delay completely?

I haven't tested that. I will, next time I need the drive, which will probably 
be in about a week. 

I just wanted to make my backup, and finally managed to do that. I don't get 
it either what's really wrong with these chips - but it was one of the 
recommendations i found on the linux-usb device list pages. And it seems to 
work.

If now only I can get the firewire part of one of them working without 
serialize_io, then I can use that too.

Jan

-- 
A billion here, a billion there -- pretty soon it adds up to real money.
		-- Sen. Everett Dirksen, on the U.S. defense budget

Re: [linux-usb-devel] Genesys USB 2.0 enclosures

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote:
> On Sat, 3 Sep 2005, Jan De Luyck wrote:
> 
> > I've posted in the past about problems with these enclosures - increasing the 
> > delay seems to fix it, albeit temporarily. The further you go in using the 
> > disk in such an enclosure, the higher the udelay() had to be - atleast that's 
> > what I'm seeing here (I've got two of these now :/ )
> > 
> > One permanent fix is adding a powered USB-hub in between the drive enclosures 
> > and the computer. Since I've done that, I've no longer seen any of the 
> > problems (i've attached the 'fault' log). Weird but true, since the drives 
> > come with their own powersupply.
> > 
> > Hope this helps anyone in the future running into the same problem.
> 
> This one certainly goes into the Bizarro file.
> 
> Just out of curiosity -- when you use the powered hub, does the drive work 
> even if you remove that delay completely?

Aren't USB 2.0 hubs more "intelligent" as part of the requirement to
support 1.1 and 2.0 devices?  I wonder if it's really a 2.0 drive, and if
the timing is different enough with the hub to make a difference.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK!!!!
					-- Greg
User Friendly, 3/27/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-usb-devel] Genesys USB 2.0 enclosures

[Grant Coady]

On Sun, 4 Sep 2005 14:04:46 -0700, Matthew Dharm <mdharm-kernel@one-eyed-alien.net> wrote:

>On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote:
>> On Sat, 3 Sep 2005, Jan De Luyck wrote:
>> 
>> > I've posted in the past about problems with these enclosures - increasing the 
>> > delay seems to fix it, albeit temporarily. The further you go in using the 
>> > disk in such an enclosure, the higher the udelay() had to be - atleast that's 
>> > what I'm seeing here (I've got two of these now :/ )
>> > 
>> > One permanent fix is adding a powered USB-hub in between the drive enclosures 
>> > and the computer. Since I've done that, I've no longer seen any of the 
>> > problems (i've attached the 'fault' log). Weird but true, since the drives 
>> > come with their own powersupply.
>> > 
>> > Hope this helps anyone in the future running into the same problem.
>> 
>> This one certainly goes into the Bizarro file.
>> 
>> Just out of curiosity -- when you use the powered hub, does the drive work 
>> even if you remove that delay completely?
>
>Aren't USB 2.0 hubs more "intelligent" as part of the requirement to
>support 1.1 and 2.0 devices?  I wonder if it's really a 2.0 drive, and if
>the timing is different enough with the hub to make a difference.

Fixed a USB powered (two USB plugs) Genesys based 2.5" HDD enclosure with 
extra 5V supply bypass capacitors, the HDD was shutting down without loss 
of data with a 'soft' 5V supply.  Now USB drive works everywhere except a 
laptop with a single USB.  HDD uses 700mA, USB is spec'd 500mA per socket.

Some bugs are the hardware :o)

Grant.