1 |
On Mon, Oct 31, 2011 at 12:21 PM, Alex Schuster <wonko@×××××××××.org> wrote: |
2 |
> Michael Mol writes: |
3 |
> |
4 |
>> My point is that the numbers aren't what mattered here. My point is |
5 |
>> that SAMSUNG sold me a shoddy product, replaced it with another |
6 |
>> instance of the the same shoddy product, wouldn't replace it again, |
7 |
>> and never addressed a detailed technical report of a systemic problem |
8 |
>> in the same. Bad tech, bad customer service, and it looked like this |
9 |
>> was a more common scenario than among other manufacturers. All of it |
10 |
>> boiled down to a nasty case of being a bad candidate for spending time |
11 |
>> and money. |
12 |
> |
13 |
> Samsung, uh? Here's my story of today. My fried just bought two external |
14 |
> USB drives. I wanted to know which brand the HD is, so I checked with |
15 |
> hdparm -I, and googled for SAMSUNG HD204UI. I found a story about a bug |
16 |
> which makes the drive sometimes forget to write a block when it is |
17 |
> attached to a SATA adapter in AHCI mode and when the ATA command |
18 |
> "IDENTIFY DEVICE" is sent (like in hdparm -I or when using the |
19 |
> smartmontools). There is a firmware patch for this, this is good. But on |
20 |
> the annoying side: |
21 |
|
22 |
That could very likely be the nature of the initial symptom for my |
23 |
second failed drive. I recall being angry about silent corruption, |
24 |
with SMART not reporting anything interesting. Drive failed |
25 |
differently later on, IIRC. I still have it in the same eSATA external |
26 |
enclosure I was using at the time. I'll have to look. |
27 |
|
28 |
> |
29 |
> - You need to make a DOS boot floppy and copy the patch there. I don't |
30 |
> know how exactly to do this, and I read about people using Linux who |
31 |
> needed over an hour for this or even failed. Can't they just let me |
32 |
> download an image I can boot from? |
33 |
|
34 |
Any idea if it works from FreeDOS? |
35 |
|
36 |
> |
37 |
> - It doesn't work over USB, so I would have to install the drive in a PC. |
38 |
|
39 |
Does the enclosure doens't contain an eSATA port? That's almost |
40 |
certain to be a direct passthrough. |
41 |
|
42 |
> |
43 |
> - The new firmware has exactly the same revision number. How stupid is |
44 |
> this?? I cannot even find out whether the drives have the problem or |
45 |
> not. Except by trying to reproduce the problem. |
46 |
|
47 |
Sounds like the only way you can be certain the drives don't have the |
48 |
problem is by installing the patched firmware. |
49 |
|
50 |
> |
51 |
> Here's a link to the but I described, but It's German only. |
52 |
> http://www.heise.de/ct/meldung/Firmware-Patch-fuer-Samsung-Festplatte-EcoGreen-F4-HD204UI-Update-1150154.html |
53 |
> I also read some angry comments about Samsung there. Question is, are |
54 |
> other manufacturers better? And wasn't Samsung Electronics bought by |
55 |
> Seagate anyway? |
56 |
> |
57 |
> |
58 |
> Any idea whether an external USB drive case might count as a SATA |
59 |
> controller in AHCI mode? I tried to trigger the bug, but that did not |
60 |
> happen, so I guess it's fine, at least when being in the USB case. |
61 |
|
62 |
The drive inside is SATA, so the USB enclosure is translating USB |
63 |
mass-storage commands to commands the SATA drive can understand. |
64 |
AFAIK, AHCI vs Legacy mode is a function of the SATA *controller*, not |
65 |
of the drive itself; legacy mode takes an older protocol, converts it |
66 |
to SATA commands, and then dispatches those SATA commands. I'll |
67 |
venture a guess that when going through Legacy mode, whatever commands |
68 |
trigger the bug aren't used in the Legacy->SATA conversion, whereas |
69 |
AHCI, with its closer-to-metal nature, exposes those commands for use. |
70 |
Whether or not the USB enclosure will trigger those bugs would depend |
71 |
on whether or not the USB Mass Storage<->SATA translation uses those |
72 |
commands or not. |
73 |
|
74 |
(In my mind, this is feels like the old AGP->PCI Express transition. |
75 |
Early PCIe video cards were actually AGP cards with an AGP->PCIe |
76 |
bridge/adapter chip onboard, because it was faster and cheaper to get |
77 |
to market by throwing an adapter component in the sequence. However, I |
78 |
don't know enough about the ASIC market for USB hard drive enclosures |
79 |
to know whether chips with adapter layers (like that legacy->SATA |
80 |
command translation, but at a hardware level, making it |
81 |
USB->legacy->SATA) will be the cheaper part to source than chips which |
82 |
convert more directly between the USB Mass Storage and SATA |
83 |
protocols.) |
84 |
|
85 |
|
86 |
> |
87 |
> Another problem is that data access frequently stalls on her PC, like when |
88 |
> transferring data or doing a mke2fs. After a while, this message appears |
89 |
> in syslog, and the process continues for a while, until it happens again: |
90 |
> |
91 |
> usb 1-4: reset high speed USB device using ehci_hcd and address 7 |
92 |
|
93 |
That looks incredibly familiar. I kept getting those, and then |
94 |
switched to my enclosure's eSATA port. That's when the drive started |
95 |
giving me different problems. At the time, I'd assumed it was the |
96 |
enclosure's USB components at fault. |
97 |
|
98 |
> |
99 |
> Same problem with a GRML boot cd and on another USB port. Happens with |
100 |
> both drives. But it is fine on my PC. |
101 |
|
102 |
|
103 |
It sounds like the drives might be salvageable with a firmware patch, |
104 |
now. I'd suggest extracting the drives, plugging them into a PC, |
105 |
updating the firmware, and then putting them back in the enclosure. |
106 |
That way, you're certain the drives don't still have the known-buggy |
107 |
firmware, at the expense of some labor. |
108 |
|
109 |
-- |
110 |
:wq |