| 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
| ||
|
Date: Thu, 8 Oct 2009 23:46:21 +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 Tue, Oct 6, 2009 at 11:10 PM, Alan Stern <stern@...land.harvard.edu> wrote: > 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. 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 -- 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/
Powered by blists - more mailing lists