On Mon, Oct 31, 2011 at 12:21 PM, Alex Schuster <wo...@wonkology.org> 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 > know how exactly to do this, and I read about people using Linux who > needed over an hour for this or even failed. Can't they just let me > download 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 > this?? I cannot even find out whether the drives have the problem or > not. 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-EcoGreen-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 when > 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. -- :wq
