[email protected]
[Top] [All Lists]

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

Subject: kern/43264: umass(4) devices that need scsi(4)/sd(4) quirks
Date: Wed, 5 May 2010 21:05:00 +0000 UTC
>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
System: NetBSD wormulon.kollasch.net 5.0_STABLE NetBSD 5.0_STABLE (WORMULON) 
#20: Thu Apr 22 17:12:56 UTC 2010 
[email protected]:/local/wormulon-src-5/src/sys/arch/amd64/compile/WORMULON
Architecture: x86_64
Machine: amd64
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.

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.

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

<Prev in Thread] Current Thread [Next in Thread>
  • kern/43264: umass(4) devices that need scsi(4)/sd(4) quirks, jakllsch <=