Western Digital Extern HDD 1021

[Matthias Rampke]

Hello,

I had two (separate, as far as I can tell) problems with my Western
Digital Elements Desktop USB hard disk on x86_64 2.8-RELEASE.

(a) the disk would be recognised, but not usable after a reboot, but
worked fine after either power cycling the machine (i.e. turning it
off and on again) or after re-attaching the disk. In both cases the
disk powers itself down, during a reboot it does not. I have not
cross-tested this on master, but I think I had the same problem there.

(b) when writing large amounts of data to the same disk (formatted
with HAMMER) the system would panic (see the screenshot at [1]). This
does NOT happen on master.

I have found (through guessing and trial&error) a fix for both
problems: adding an entry to the quirks table in
sys/dev/usbmisc/umass/umass.c - see the attached patch or the gist at
[2].

(a) is fixed by adding the NO_TEST_UNIT_READY quirk. From the
description of said flag this is plausible.
(b) is fixed through IGNORE_RESIDUE. This sounds more-or-less
plausible as well, but I do not understand why this panic did not
occur on master even without this patch (umass.c has not changed
between 2.8-RELEASE and master). I can not find where this particular
quirk is ever observed, so I am at loss here concerning the underlying
reason for this.

My guess is (from what I understand about IGNORE_RESIDUE) that this
flag causes some part of the driver stack to disregard some count from
the disk and relies solely on it's own knowledge of the state of a
transfer, thus not choking on this count being off. Has this perhaps
been made the default?


Regards,
Matthias


PS: Thanks swildner for the advice and patience!


[1] http://twitpic.com/405ogp
[2] https://gist.github.com/825244
Attachment:
wd-extern-hdd-1021.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00000.bin
Type: application/octet-stream
Size: 690 bytes
Desc: "Description: Binary data"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20110215/a653e368/attachment-0019.bin>