Genesys USB 2.0 enclosures

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* Genesys USB 2.0 enclosures
       [not found]   ` <42499406.7090406@ipom.com>
@ 2005-09-03 16:12     ` Jan De Luyck
  2005-09-04  1:53       ` [linux-usb-devel] " Alan Stern
  0 siblings, 1 reply; 5+ messages in thread
From: Jan De Luyck @ 2005-09-03 16:12 UTC (permalink / raw)
  To: USB Storage list; +Cc: USB development list, linux-kernel

[-- 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-usb-devel] Genesys USB 2.0 enclosures
  2005-09-03 16:12     ` Genesys USB 2.0 enclosures Jan De Luyck
@ 2005-09-04  1:53       ` Alan Stern
  2005-09-04  8:46         ` Jan De Luyck
  2005-09-04 21:04         ` Matthew Dharm
  0 siblings, 2 replies; 5+ messages in thread
From: Alan Stern @ 2005-09-04  1:53 UTC (permalink / raw)
  To: Jan De Luyck; +Cc: USB Storage list, USB development list, linux-kernel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-usb-devel] Genesys USB 2.0 enclosures
  2005-09-04  1:53       ` [linux-usb-devel] " Alan Stern
@ 2005-09-04  8:46         ` Jan De Luyck
  2005-09-04 21:04         ` Matthew Dharm
  1 sibling, 0 replies; 5+ messages in thread
From: Jan De Luyck @ 2005-09-04  8:46 UTC (permalink / raw)
  To: linux-kernel; +Cc: Alan Stern, USB Storage list, USB development list

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-usb-devel] Genesys USB 2.0 enclosures
  2005-09-04  1:53       ` [linux-usb-devel] " Alan Stern
  2005-09-04  8:46         ` Jan De Luyck
@ 2005-09-04 21:04         ` Matthew Dharm
  2005-09-04 22:10           ` Grant Coady
  1 sibling, 1 reply; 5+ messages in thread
From: Matthew Dharm @ 2005-09-04 21:04 UTC (permalink / raw)
  To: Alan Stern
  Cc: Jan De Luyck, USB Storage list, USB development list,
	linux-kernel

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [linux-usb-devel] Genesys USB 2.0 enclosures
  2005-09-04 21:04         ` Matthew Dharm
@ 2005-09-04 22:10           ` Grant Coady
  0 siblings, 0 replies; 5+ messages in thread
From: Grant Coady @ 2005-09-04 22:10 UTC (permalink / raw)
  To: Matthew Dharm
  Cc: Alan Stern, Jan De Luyck, USB Storage list, USB development list,
	linux-kernel

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-09-04 22:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.44L0.0412151627350.2419-100000@ida.rowland.org>
     [not found] ` <200503291344.42951.lkml@kcore.org>
     [not found]   ` <42499406.7090406@ipom.com>
2005-09-03 16:12     ` Genesys USB 2.0 enclosures Jan De Luyck
2005-09-04  1:53       ` [linux-usb-devel] " Alan Stern
2005-09-04  8:46         ` Jan De Luyck
2005-09-04 21:04         ` Matthew Dharm
2005-09-04 22:10           ` Grant Coady

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox