From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RKv7m-0003dj-PM for garchives@archives.gentoo.org; Mon, 31 Oct 2011 16:54:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E3CAF21C067; Mon, 31 Oct 2011 16:54:05 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id B87B521C09E for ; Mon, 31 Oct 2011 16:53:13 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3476448bkb.40 for ; Mon, 31 Oct 2011 09:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=zfMv7ode6Y1tWOfEGCniPpfFP8YPl276x4MbvEk1mN0=; b=DKBn/c52ocOlprnXcNB8PNkP7aV2AKbsyXgds/x3R4fPzNpt0mfRiZUUIFLh2tUs01 iMEtRrXUUmA0yxwRqqNoPAtb3gbrrIL0GbNcFGN2e/AcaeCtug2VWSeK8HEgYZ0ldOc4 SXwVpnl83VFqrZLlLM91kJTpXyu+hBpelwpH4= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.139.199 with SMTP id f7mr4191461bku.88.1320079992581; Mon, 31 Oct 2011 09:53:12 -0700 (PDT) Received: by 10.204.37.16 with HTTP; Mon, 31 Oct 2011 09:53:12 -0700 (PDT) In-Reply-To: <20111031172123.334a2089@weird.wonkology.org> References: <4EA9130A.6070807@gmail.com> <3548470.itfJ2OrkKu@localhost> <2509854.gnJJdlHcqy@localhost> <20111031172123.334a2089@weird.wonkology.org> Date: Mon, 31 Oct 2011 12:53:12 -0400 Message-ID: Subject: Re: [gentoo-user] Re: Hard drive RPMs and data speed. From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 91d2ac31-12ea-4847-bec1-9ed71464fd0a X-Archives-Hash: 5caad3378cdadfaedf2c9983635b5991 On Mon, Oct 31, 2011 at 12:21 PM, Alex Schuster wrote= : > Michael Mol writes: > >> My point is that the numbers aren't what mattered here. My point is >> that SAMSUNG sold me a shoddy product, replaced it with another >> instance of the the same shoddy product, wouldn't replace it again, >> and never addressed a detailed technical report of a systemic problem >> in the same. Bad tech, bad customer service, and it looked like this >> was a more common scenario than among other manufacturers. All of it >> boiled down to a nasty case of being a bad candidate for spending time >> and money. > > Samsung, uh? Here's my story of today. My fried just bought two external > USB drives. I wanted to know which brand the HD is, so I checked with > hdparm -I, and googled for SAMSUNG HD204UI. I found a story about a bug > which makes the drive sometimes forget to write a block when it is > attached to a SATA adapter in AHCI mode and when the ATA command > "IDENTIFY DEVICE" is sent (like in hdparm -I or when using the > smartmontools). There is a firmware patch for this, this is good. But on > the annoying side: That could very likely be the nature of the initial symptom for my second failed drive. I recall being angry about silent corruption, with SMART not reporting anything interesting. Drive failed differently later on, IIRC. I still have it in the same eSATA external enclosure I was using at the time. I'll have to look. > > - You need to make a DOS boot floppy and copy the patch there. I don't > =C2=A0know how exactly to do this, and I read about people using Linux wh= o > =C2=A0needed over an hour for this or even failed. Can't they just let me > =C2=A0download an image I can boot from? Any idea if it works from FreeDOS? > > - It doesn't work over USB, so I would have to install the drive in a PC. Does the enclosure doens't contain an eSATA port? That's almost certain to be a direct passthrough. > > - The new firmware has exactly the same revision number. How stupid is > =C2=A0this?? I cannot even find out whether the drives have the problem o= r > =C2=A0not. Except by trying to reproduce the problem. Sounds like the only way you can be certain the drives don't have the problem is by installing the patched firmware. > > Here's a link to the but I described, but It's German only. > http://www.heise.de/ct/meldung/Firmware-Patch-fuer-Samsung-Festplatte-Eco= Green-F4-HD204UI-Update-1150154.html > I also read some angry comments about Samsung there. Question is, are > other manufacturers better? And wasn't Samsung Electronics bought by > Seagate anyway? > > > Any idea whether an external USB drive case might count as a SATA > controller in AHCI mode? I tried to trigger the bug, but that did not > happen, so I guess it's fine, at least when being in the USB case. The drive inside is SATA, so the USB enclosure is translating USB mass-storage commands to commands the SATA drive can understand. AFAIK, AHCI vs Legacy mode is a function of the SATA *controller*, not of the drive itself; legacy mode takes an older protocol, converts it to SATA commands, and then dispatches those SATA commands. I'll venture a guess that when going through Legacy mode, whatever commands trigger the bug aren't used in the Legacy->SATA conversion, whereas AHCI, with its closer-to-metal nature, exposes those commands for use. Whether or not the USB enclosure will trigger those bugs would depend on whether or not the USB Mass Storage<->SATA translation uses those commands or not. (In my mind, this is feels like the old AGP->PCI Express transition. Early PCIe video cards were actually AGP cards with an AGP->PCIe bridge/adapter chip onboard, because it was faster and cheaper to get to market by throwing an adapter component in the sequence. However, I don't know enough about the ASIC market for USB hard drive enclosures to know whether chips with adapter layers (like that legacy->SATA command translation, but at a hardware level, making it USB->legacy->SATA) will be the cheaper part to source than chips which convert more directly between the USB Mass Storage and SATA protocols.) > > Another problem is that data access frequently stalls on her PC, like whe= n > transferring data or doing a mke2fs. After a while, this message appears > in syslog, and the process continues for a while, until it happens again: > > usb 1-4: reset high speed USB device using ehci_hcd and address 7 That looks incredibly familiar. I kept getting those, and then switched to my enclosure's eSATA port. That's when the drive started giving me different problems. At the time, I'd assumed it was the enclosure's USB components at fault. > > Same problem with a GRML boot cd and on another USB port. Happens with > both drives. But it is fine on my PC. It sounds like the drives might be salvageable with a firmware patch, now. I'd suggest extracting the drives, plugging them into a PC, updating the firmware, and then putting them back in the enclosure. That way, you're certain the drives don't still have the known-buggy firmware, at the expense of some labor. --=20 :wq