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 21:57:27 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
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 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.

> 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

View attachment "usb.txt" of type "text/plain" (29147 bytes)