Hi,
This is with 2.6.31.1.
I'm having a lot of problems with a lacie external hd[1]. It seems the
actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
In normal usage what I see is that if I don't use the disk after a
while hear a loud click (as if something got stuck) and then I cannot
use it any more; I have to turn it off and on again.
But then I started to see some problems on one fs, so I ran badblocks
and I noticed a lot of strange behavior. It seems once I get a
read/write error then I get more of them in a row, and after a while I
hear another loud click, and then I only get read/write errors
constantly.
I noticed in 'unusual_devs.h' there's already a quirk for another
JMicron product, so I tried to do the same:
+UNUSUAL_DEV( 0x152d, 0x2339, 0x0000, 0xffff,
+ "JMicron",
+ "USB to ATA/ATAPI Bridge",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_IGNORE_RESIDUE | US_FL_SANE_SENSE ),
This seemed to help with the consecutive errors, but not with the loud click.
This is what I get when this click happens:
Oct 3 13:14:54 annwn kernel: [ 351.099096] usb 1-1: reset high speed
USB device using ehci_hcd and address 3
Oct 3 13:14:54 annwn kernel: [ 351.213541] usb 1-1: device firmware changed
Oct 3 13:14:54 annwn kernel: [ 351.213588] usb 1-1: USB disconnect, address 3
Oct 3 13:14:54 annwn kernel: [ 351.213633] sd 4:0:0:0: Device
offlined - not ready after error recovery
Oct 3 13:14:54 annwn kernel: [ 351.213650] sd 4:0:0:0: [sdb]
Unhandled error code
Oct 3 13:14:54 annwn kernel: [ 351.213655] sd 4:0:0:0: [sdb] Result:
hostbyte=DID_ABORT driverbyte=DRIVER_OK
Oct 3 13:14:54 annwn kernel: [ 351.213663] end_request: I/O error,
dev sdb, sector 8596352
Oct 3 13:14:54 annwn kernel: [ 351.213774] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213816] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213852] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213891] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213927] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213962] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.213997] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:54 annwn kernel: [ 351.214202] sd 4:0:0:0: rejecting I/O
to offline device
Oct 3 13:14:55 annwn kernel: [ 351.317278] usb 1-1: new high speed
USB device using ehci_hcd and address 4
Oct 3 13:14:55 annwn kernel: [ 351.432192] usb 1-1: New USB device
found, idVendor=152d, idProduct=2339
Oct 3 13:14:55 annwn kernel: [ 351.432196] usb 1-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=5
Oct 3 13:14:55 annwn kernel: [ 351.432199] usb 1-1: Product: USB to
ATA/ATAPI Bridge
Oct 3 13:14:55 annwn kernel: [ 351.432202] usb 1-1: Manufacturer: JMicron
Oct 3 13:14:55 annwn kernel: [ 351.432204] usb 1-1: SerialNumber: 5D27FFFFFFFF
Oct 3 13:14:55 annwn kernel: [ 351.432321] usb 1-1: configuration #1
chosen from 1 choice
Oct 3 13:14:55 annwn kernel: [ 351.432791] scsi5 : SCSI emulation
for USB Mass Storage devices
Can anyone help? This disk is important for me =/
Cheers.
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 62 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=152d ProdID=2339 Rev= 1.00
S: Manufacturer=JMicron
S: Product=USB to ATA/ATAPI Bridge
S: SerialNumber=152D203380B6
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
[1] http://www.lacie.com/us/products/product.htm?pid=11016
--
Felipe Contreras
On Sat, Oct 03, 2009 at 01:35:58PM +0300, Felipe Contreras wrote:
> Hi,
>
> This is with 2.6.31.1.
>
> I'm having a lot of problems with a lacie external hd[1]. It seems the
> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
>
> In normal usage what I see is that if I don't use the disk after a
> while hear a loud click (as if something got stuck) and then I cannot
> use it any more; I have to turn it off and on again.
>
> But then I started to see some problems on one fs, so I ran badblocks
> and I noticed a lot of strange behavior. It seems once I get a
> read/write error then I get more of them in a row, and after a while I
> hear another loud click, and then I only get read/write errors
> constantly.
>
> I noticed in 'unusual_devs.h' there's already a quirk for another
> JMicron product, so I tried to do the same:
>
> +UNUSUAL_DEV( 0x152d, 0x2339, 0x0000, 0xffff,
> + "JMicron",
> + "USB to ATA/ATAPI Bridge",
> + US_SC_DEVICE, US_PR_DEVICE, NULL,
> + US_FL_IGNORE_RESIDUE | US_FL_SANE_SENSE ),
>
> This seemed to help with the consecutive errors, but not with the loud click.
>
> This is what I get when this click happens:
>
> Oct 3 13:14:54 annwn kernel: [ 351.099096] usb 1-1: reset high speed
> USB device using ehci_hcd and address 3
> Oct 3 13:14:54 annwn kernel: [ 351.213541] usb 1-1: device firmware changed
> Oct 3 13:14:54 annwn kernel: [ 351.213588] usb 1-1: USB disconnect, address 3
> Oct 3 13:14:54 annwn kernel: [ 351.213633] sd 4:0:0:0: Device
> offlined - not ready after error recovery
> Oct 3 13:14:54 annwn kernel: [ 351.213650] sd 4:0:0:0: [sdb]
> Unhandled error code
> Oct 3 13:14:54 annwn kernel: [ 351.213655] sd 4:0:0:0: [sdb] Result:
> hostbyte=DID_ABORT driverbyte=DRIVER_OK
> Oct 3 13:14:54 annwn kernel: [ 351.213663] end_request: I/O error,
> dev sdb, sector 8596352
> Oct 3 13:14:54 annwn kernel: [ 351.213774] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213816] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213852] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213891] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213927] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213962] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.213997] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:54 annwn kernel: [ 351.214202] sd 4:0:0:0: rejecting I/O
> to offline device
> Oct 3 13:14:55 annwn kernel: [ 351.317278] usb 1-1: new high speed
> USB device using ehci_hcd and address 4
> Oct 3 13:14:55 annwn kernel: [ 351.432192] usb 1-1: New USB device
> found, idVendor=152d, idProduct=2339
> Oct 3 13:14:55 annwn kernel: [ 351.432196] usb 1-1: New USB device
> strings: Mfr=1, Product=2, SerialNumber=5
> Oct 3 13:14:55 annwn kernel: [ 351.432199] usb 1-1: Product: USB to
> ATA/ATAPI Bridge
> Oct 3 13:14:55 annwn kernel: [ 351.432202] usb 1-1: Manufacturer: JMicron
> Oct 3 13:14:55 annwn kernel: [ 351.432204] usb 1-1: SerialNumber: 5D27FFFFFFFF
> Oct 3 13:14:55 annwn kernel: [ 351.432321] usb 1-1: configuration #1
> chosen from 1 choice
> Oct 3 13:14:55 annwn kernel: [ 351.432791] scsi5 : SCSI emulation
> for USB Mass Storage devices
>
> Can anyone help? This disk is important for me =/
The log shows the device just disconnected from the system. You should
post more of the logfile before the disconnect so we can see if it's an
issue with the USB core. Did it work with a previous kernel?
It could be that your disk is just dying, and occasionally
disconnecting. Or you could have a bad cable or a hub that's
introducing noise. Can you try a different USB cable?
Sarah Sharp
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 62 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=152d ProdID=2339 Rev= 1.00
> S: Manufacturer=JMicron
> S: Product=USB to ATA/ATAPI Bridge
> S: SerialNumber=152D203380B6
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>
> [1] http://www.lacie.com/us/products/product.htm?pid=11016
>
> --
> Felipe Contreras
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 3, 2009 at 6:48 PM, Sarah Sharp
<[email protected]> wrote:
> On Sat, Oct 03, 2009 at 01:35:58PM +0300, Felipe Contreras wrote:
>> Hi,
>>
>> This is with 2.6.31.1.
>>
>> I'm having a lot of problems with a lacie external hd[1]. It seems the
>> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
>>
>> In normal usage what I see is that if I don't use the disk after a
>> while hear a loud click (as if something got stuck) and then I cannot
>> use it any more; I have to turn it off and on again.
>>
>> But then I started to see some problems on one fs, so I ran badblocks
>> and I noticed a lot of strange behavior. It seems once I get a
>> read/write error then I get more of them in a row, and after a while I
>> hear another loud click, and then I only get read/write errors
>> constantly.
>>
>> I noticed in 'unusual_devs.h' there's already a quirk for another
>> JMicron product, so I tried to do the same:
>>
>> +UNUSUAL_DEV( 0x152d, 0x2339, 0x0000, 0xffff,
>> + "JMicron",
>> + "USB to ATA/ATAPI Bridge",
>> + US_SC_DEVICE, US_PR_DEVICE, NULL,
>> + US_FL_IGNORE_RESIDUE | US_FL_SANE_SENSE ),
>>
>> This seemed to help with the consecutive errors, but not with the loud click.
>>
>> This is what I get when this click happens:
>>
>> Oct 3 13:14:54 annwn kernel: [ 351.099096] usb 1-1: reset high speed
>> USB device using ehci_hcd and address 3
>> Oct 3 13:14:54 annwn kernel: [ 351.213541] usb 1-1: device firmware changed
>> Oct 3 13:14:54 annwn kernel: [ 351.213588] usb 1-1: USB disconnect, address 3
>> Oct 3 13:14:54 annwn kernel: [ 351.213633] sd 4:0:0:0: Device
>> offlined - not ready after error recovery
>> Oct 3 13:14:54 annwn kernel: [ 351.213650] sd 4:0:0:0: [sdb]
>> Unhandled error code
>> Oct 3 13:14:54 annwn kernel: [ 351.213655] sd 4:0:0:0: [sdb] Result:
>> hostbyte=DID_ABORT driverbyte=DRIVER_OK
>> Oct 3 13:14:54 annwn kernel: [ 351.213663] end_request: I/O error,
>> dev sdb, sector 8596352
>> Oct 3 13:14:54 annwn kernel: [ 351.213774] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213816] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213852] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213891] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213927] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213962] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.213997] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:54 annwn kernel: [ 351.214202] sd 4:0:0:0: rejecting I/O
>> to offline device
>> Oct 3 13:14:55 annwn kernel: [ 351.317278] usb 1-1: new high speed
>> USB device using ehci_hcd and address 4
>> Oct 3 13:14:55 annwn kernel: [ 351.432192] usb 1-1: New USB device
>> found, idVendor=152d, idProduct=2339
>> Oct 3 13:14:55 annwn kernel: [ 351.432196] usb 1-1: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=5
>> Oct 3 13:14:55 annwn kernel: [ 351.432199] usb 1-1: Product: USB to
>> ATA/ATAPI Bridge
>> Oct 3 13:14:55 annwn kernel: [ 351.432202] usb 1-1: Manufacturer: JMicron
>> Oct 3 13:14:55 annwn kernel: [ 351.432204] usb 1-1: SerialNumber: 5D27FFFFFFFF
>> Oct 3 13:14:55 annwn kernel: [ 351.432321] usb 1-1: configuration #1
>> chosen from 1 choice
>> Oct 3 13:14:55 annwn kernel: [ 351.432791] scsi5 : SCSI emulation
>> for USB Mass Storage devices
>>
>> Can anyone help? This disk is important for me =/
>
> The log shows the device just disconnected from the system. You should
> post more of the logfile before the disconnect so we can see if it's an
> issue with the USB core. Did it work with a previous kernel?
There was nothing special in the log. I think it was completely silent
for a while. I'll grab more logs and post them.
I'm not sure if it was working properly on previous kernels. If it
did, it was probably a long time ago. I least I can remember this
behavior since .28.
> It could be that your disk is just dying, and occasionally
> disconnecting. Or you could have a bad cable or a hub that's
> introducing noise. Can you try a different USB cable?
I already tried with a different cable. Another external drive I have,
worked perfectly (badblocks didn't return a single bad one) with both
cables.
Cheers.
--
Felipe Contreras
On Sat, 3 Oct 2009, Felipe Contreras wrote:
> Hi,
>
> This is with 2.6.31.1.
>
> I'm having a lot of problems with a lacie external hd[1]. It seems the
> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
>
> In normal usage what I see is that if I don't use the disk after a
> while hear a loud click (as if something got stuck) and then I cannot
> use it any more; I have to turn it off and on again.
This sounds very much like a hardware problem, either in the drive or
in the bridge chip. There's no direct way to tell which; you would
have to try attaching the drive to a different chip or the chip to a
different drive.
The two places where your listings showed the Serial number (the kernel
log and the /sys/kernel/debug/usb/devices file) have different values,
suggesting that the chip is at fault. But this isn't definitive.
Alan Stern
On Sun, Oct 4, 2009 at 12:26 AM, Alan Stern <[email protected]> wrote:
> On Sat, 3 Oct 2009, Felipe Contreras wrote:
>
>> Hi,
>>
>> This is with 2.6.31.1.
>>
>> I'm having a lot of problems with a lacie external hd[1]. It seems the
>> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
>>
>> In normal usage what I see is that if I don't use the disk after a
>> while hear a loud click (as if something got stuck) and then I cannot
>> use it any more; I have to turn it off and on again.
>
> This sounds very much like a hardware problem, either in the drive or
> in the bridge chip. There's no direct way to tell which; you would
> have to try attaching the drive to a different chip or the chip to a
> different drive.
I'm not sure I can do that. There doesn't seem to be any way to open
the device and I don't have a way to test neither the disk, nor the
bridge. I would like to leave that as last option.
> The two places where your listings showed the Serial number (the kernel
> log and the /sys/kernel/debug/usb/devices file) have different values,
> suggesting that the chip is at fault. But this isn't definitive.
The first reported serial number seems to be correct, but the second
one (after the click) isn't.
Anyway, what about all the errors before the loud click? Couldn't it
be that the driver is causing the device to malfunction? At least the
patch seems to decrease the number of reported bad blocks. Once
applying the patch the first block of bad blocks is always the same,
but the second is always different, then the click happens.
I'm attaching the full log.
--
Felipe Contreras
On Tue, 6 Oct 2009, Felipe Contreras wrote:
> On Sun, Oct 4, 2009 at 12:26 AM, Alan Stern <[email protected]> wrote:
> > On Sat, 3 Oct 2009, Felipe Contreras wrote:
> >
> >> Hi,
> >>
> >> This is with 2.6.31.1.
> >>
> >> I'm having a lot of problems with a lacie external hd[1]. It seems the
> >> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
> >>
> >> In normal usage what I see is that if I don't use the disk after a
> >> while hear a loud click (as if something got stuck) and then I cannot
> >> use it any more; I have to turn it off and on again.
> >
> > This sounds very much like a hardware problem, either in the drive or
> > in the bridge chip. There's no direct way to tell which; you would
> > have to try attaching the drive to a different chip or the chip to a
> > different drive.
>
> I'm not sure I can do that. There doesn't seem to be any way to open
> the device and I don't have a way to test neither the disk, nor the
> bridge. I would like to leave that as last option.
Then it doesn't really matter whether the problem is in the drive or in
the chip, since separating them is impractical.
> > The two places where your listings showed the Serial number (the kernel
> > log and the /sys/kernel/debug/usb/devices file) have different values,
> > suggesting that the chip is at fault. But this isn't definitive.
>
> The first reported serial number seems to be correct, but the second
> one (after the click) isn't.
>
> Anyway, what about all the errors before the loud click? Couldn't it
> be that the driver is causing the device to malfunction?
I doubt that very much. And besides, if the device were designed
properly then it wouldn't malfunction, no matter what the driver did.
> At least the
> patch seems to decrease the number of reported bad blocks. Once
> applying the patch the first block of bad blocks is always the same,
> but the second is always different, then the click happens.
>
> I'm attaching the full log.
A usbmon trace would contain more information. We could see the exact
sequence of commands and error codes. I'm not sure it would help solve
anything, though.
You could try plugging the device into a different computer and see if
it behaves the same way. If it does, your best course might be to
exchange it for something that works better.
Alan Stern
On Tue, Oct 6, 2009 at 11:10 PM, Alan Stern <[email protected]> wrote:
> On Tue, 6 Oct 2009, Felipe Contreras wrote:
>
>> On Sun, Oct 4, 2009 at 12:26 AM, Alan Stern <[email protected]> wrote:
>> > On Sat, 3 Oct 2009, Felipe Contreras wrote:
>> >
>> >> Hi,
>> >>
>> >> This is with 2.6.31.1.
>> >>
>> >> I'm having a lot of problems with a lacie external hd[1]. It seems the
>> >> actual disk is a seagate ST375064, and the bridge is a JMicron 2339.
>> >>
>> >> In normal usage what I see is that if I don't use the disk after a
>> >> while hear a loud click (as if something got stuck) and then I cannot
>> >> use it any more; I have to turn it off and on again.
>> >
>> > This sounds very much like a hardware problem, either in the drive or
>> > in the bridge chip. There's no direct way to tell which; you would
>> > have to try attaching the drive to a different chip or the chip to a
>> > different drive.
>>
>> I'm not sure I can do that. There doesn't seem to be any way to open
>> the device and I don't have a way to test neither the disk, nor the
>> bridge. I would like to leave that as last option.
>
> Then it doesn't really matter whether the problem is in the drive or in
> the chip, since separating them is impractical.
Not in my particular case, but if it turns out to be some kind of
hardware defect then we know other people would not be affected.
>> > The two places where your listings showed the Serial number (the kernel
>> > log and the /sys/kernel/debug/usb/devices file) have different values,
>> > suggesting that the chip is at fault. But this isn't definitive.
>>
>> The first reported serial number seems to be correct, but the second
>> one (after the click) isn't.
>>
>> Anyway, what about all the errors before the loud click? Couldn't it
>> be that the driver is causing the device to malfunction?
>
> I doubt that very much. And besides, if the device were designed
> properly then it wouldn't malfunction, no matter what the driver did.
Indeed, but I guess there's a reason you have a quirks list: some
devices are not designed properly.
>> At least the
>> patch seems to decrease the number of reported bad blocks. Once
>> applying the patch the first block of bad blocks is always the same,
>> but the second is always different, then the click happens.
>>
>> I'm attaching the full log.
>
> A usbmon trace would contain more information. We could see the exact
> sequence of commands and error codes. I'm not sure it would help solve
> anything, though.
I followed the tutorial and the resulting log is 73M long. I don't
know what I'm looking for, so there it is:
http://people.freedesktop.org/~felipec/1.mon.out
> You could try plugging the device into a different computer and see if
> it behaves the same way. If it does, your best course might be to
> exchange it for something that works better.
I'll try to do that, but it might take me a while to find one that
doesn't run Linux.
Thanks for the help so far.
--
Felipe Contreras
On Thu, Oct 8, 2009 at 11:46 PM, Felipe Contreras
<[email protected]> wrote:
> On Tue, Oct 6, 2009 at 11:10 PM, Alan Stern <[email protected]> wrote:
>> A usbmon trace would contain more information. We could see the exact
>> sequence of commands and error codes. I'm not sure it would help solve
>> anything, though.
>
> I followed the tutorial and the resulting log is 73M long. I don't
> know what I'm looking for, so there it is:
> http://people.freedesktop.org/~felipec/1.mon.out
Can you take a look? Is there anything else I can provide?
--
Felipe Contreras
On Mon, 19 Oct 2009, Felipe Contreras wrote:
> On Thu, Oct 8, 2009 at 11:46 PM, Felipe Contreras
> <[email protected]> wrote:
> > On Tue, Oct 6, 2009 at 11:10 PM, Alan Stern <[email protected]> wrote:
> >> A usbmon trace would contain more information. We could see the exact
> >> sequence of commands and error codes. I'm not sure it would help solve
> >> anything, though.
> >
> > I followed the tutorial and the resulting log is 73M long. I don't
> > know what I'm looking for, so there it is:
> > http://people.freedesktop.org/~felipec/1.mon.out
>
> Can you take a look? Is there anything else I can provide?
Unforunately the usbmon trace isn't much help. It shows several
unrecovered read errors, but you already know that the disk has a bunch
of bad sectors.
Then near the end, for no apparent reason, it shows a failure right in
the middle of a READ command. The computer tried to read 128 sectors;
the drive sent back 48 sectors of data and then stopped responding.
Something in the firmware crashed; my guess is that the bridge chip
failed.
Alan Stern