--90e6ba53ad10b9c7b1049c555499
Content-Type: text/plain; charset=UTF-8
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
--90e6ba53ad10b9c7b1049c555499
Content-Type: application/octet-stream; name="wd-extern-hdd-1021.patch"
Content-Disposition: attachment; filename="wd-extern-hdd-1021.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gk72dtmd0
ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNibWlzYy91bWFzcy91bWFzcy5jIGIvc3lzL2Rldi91c2Jt
aXNjL3VtYXNzL3VtYXNzLmMKaW5kZXggNjRjODliYi4uOTEwNzIyOCAxMDA2NDQKLS0tIGEvc3lz
L2Rldi91c2JtaXNjL3VtYXNzL3VtYXNzLmMKKysrIGIvc3lzL2Rldi91c2JtaXNjL3VtYXNzL3Vt
YXNzLmMKQEAgLTkyMCwxMSArOTIwLDYgQEAgc3RhdGljIHN0cnVjdCB1bWFzc19kZXZkZXNjcl90
IHVtYXNzX2RldmRlc2Nyc1tdID0gewogCSAgLnByb3RvICA9IFVNQVNTX1BST1RPX1NDU0kgfCBV
TUFTU19QUk9UT19CQkIsCiAJICAucXVpcmtzID0gTk9fSU5RVUlSWV9FVlBECiAJfSwKLQkvKiBX
ZXN0ZXJuIEV4dGVybmFsIEhERCAxMDIxICovCi0JeyAudmVuZG9yID0gMHgxMDU4LCAucHJvZHVj
dCA9IDB4MTAyMSwgLnJlbGVhc2UgPSBXSUxEQ0FSRF9JRCwKLQkgIC5wcm90byAgPSBVTUFTU19Q
Uk9UT19TQ1NJIHwgVU1BU1NfUFJPVE9fQkJCLAotCSAgLnF1aXJrcyA9IElHTk9SRV9SRVNJRFVF
IHwgTk9fVEVTVF9VTklUX1JFQURZCi0JfSwKIAkvKiBXaW5NYXhHcm91cCBVU0IgRmxhc2ggRGlz
ayAqLwogCXsgLnZlbmRvciA9IDB4MGVkMSwgLnByb2R1Y3QgPSAweDY2NjAsIC5yZWxlYXNlID0g
V0lMRENBUkRfSUQsCiAJICAucHJvdG8gID0gVU1BU1NfUFJPVE9fU0NTSSB8IFVNQVNTX1BST1RP
X0JCQiwK
--90e6ba53ad10b9c7b1049c555499--