kern/43264: umass(4) devices that need scsi(4)/sd(4) quirks

[jakllsch%NetBSD.org@localhost]

>Number:         43264
>Category:       kern
>Synopsis:       certian umass(4) devices need special care at the SCSI layer
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 05 21:05:00 +0000 2010
>Originator:     Jonathan A. Kollasch
>Release:        NetBSD 5.0_STABLE
>Organization:
>Environment:
System: NetBSD wormulon.kollasch.net 5.0_STABLE NetBSD 5.0_STABLE (WORMULON) 
#20: Thu Apr 22 17:12:56 UTC 2010 
root%wormulon.kollasch.net@localhost:/local/wormulon-src-5/src/sys/arch/amd64/compile/WORMULON
 amd64
Architecture: x86_64
Machine: amd64
>Description:
I have a few USB Mass Storage Class devices that do not behave according
to the various applicable standards.

These include a device that claims to be removable, but becomes unresponsive
after being issued a SCSI_PREVENT_ALLOW_MEDIUM_REMOVAL (0x1e) command and
reporting failure in the CSW.  (Due to other bugs, plugging this device in
and having it fail this way not uncommonly results in a kernel panic.)

A more commonly occuring quirk is a off-by-one error perpetuated by the
difference in the way SCSI and ATA devices report media capacity.
This hardware/firmware bug isn't nearly as bad, but it makes using GPT
on the disk quite difficult.

>How-To-Repeat:
Use one of the multitude of buggy umass(4) devices.  Note how they could
be handled better.  Note that Linux and other OSes do handle many of
them better.

>Fix:
Figure out how to violate layering without actually violating layering. :-)