mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org
Subject: Re: Annoying problems with lacie external hd (JMicron 0x2339?)
Date: Thu, 8 Oct 2009 23:46:21 +0300	[thread overview]
Message-ID: <94a0d4530910081346j57b155a1o10e4a4545e7548b3@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0910061604160.3002-100000@iolanthe.rowland.org>

On Tue, Oct 6, 2009 at 11:10 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 6 Oct 2009, Felipe Contreras wrote:
>
>> On Sun, Oct 4, 2009 at 12:26 AM, Alan Stern <stern@rowland.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.

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

  reply	other threads:[~2009-10-08 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-03 10:35 Felipe Contreras
2009-10-03 15:48 ` Sarah Sharp
2009-10-03 16:53   ` Felipe Contreras
2009-10-03 21:26 ` Alan Stern
2009-10-06 18:57   ` Felipe Contreras
2009-10-06 20:10     ` Alan Stern
2009-10-08 20:46       ` Felipe Contreras [this message]
2009-10-18 22:17         ` Felipe Contreras
2009-10-19 14:39           ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94a0d4530910081346j57b155a1o10e4a4545e7548b3@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®