linux-kernel - Re: Annoying problems with lacie external hd (JMicron 0x2339?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Oct 2009 16:10:47 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Contreras <felipe.contreras@...il.com>
cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>
Subject: Re: Annoying problems with lacie external hd (JMicron 0x2339?)

On Tue, 6 Oct 2009, Felipe Contreras wrote:

> On Sun, Oct 4, 2009 at 12:26 AM, Alan Stern <stern@...land.harvard.edu> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/