[Trac #1202] 1GB SD card in a USB multi-card reader caused Divide Error

[Zarro Boogs per Child]

#1202: 1GB SD card in a USB multi-card reader caused Divide Error
---------------------------------+------------------------------------------
 Reporter:  RussNelson           |        Owner:  wmb at firmworks.com
     Type:  defect               |       Status:  assigned         
 Priority:  normal               |    Milestone:  BTest-3          
Component:  ofw - open firmware  |   Resolution:                   
 Keywords:                       |  
---------------------------------+------------------------------------------
Comment (by wmb at firmworks.com):

 Okay, I think I know what is happening.  The problem is that multi-readers
 have several slots at different "addresses" (logical unit numbers in the
 SCSI-like addressing domain  of USB storage devices).

 When the OFW USB stack discovers the device, it does not probe to the
 ultimate level, thus it does not know in advance which set of unit numbers
 contain actual cards.  Instead, it creates a "wildcard node" like
 /usb at f,4/scsi at 0,0/disk .  An actual unit number can be supplied later, as
 in /usb at f,4/scsi at 0,0/disk at 2 (for LUN 2).

 If you try to access the device without explicitly supplying the LUN, it
 defaults to LUN 0.  If the card happens to be in slot 0, you win.  If the
 card is in a different slot, you lose.

 Russ's multi-reader probably has slot 0 as the Compact FLASH slot, which
 is why that card worked but the SD didn't.  My multi-reader has slot 0 as
 the SD slot, which explains my success.

 We have seen this problem (missing LUN specifier) before, but the
 manifestation was different.  Instead of a divide error, the previous
 symptom was a clean failure to open the device.

 The different is due to the fact that Russ's reader, instead of returning
 a failure code when attempting to access an empty slot via the "mode
 sense" command, returned a success code, but bogus data.  (My reader
 cleanly fails both read_capacity and mode_sense on an empty slot).

 I'll bet that Russ's reader will work if the appropriate LUN is supplied.

 There are two possible solutions to this problem.

 a) The "right" solution is to fully probe the multi-reader to determine
 which slots are actually populated, creating explictly-addressed nodes for
 them.  But that will take a fair amount of work ...

 b) An easy short term workaround is to omit the mode_sense fallback from
 the block-size determination code.  That should cause Russ's device to
 fail cleanly.  The mode_sense fallback is dubious anyway.  Based on my
 reading of the SCSI RBC spec, I don't think that the mode_sense thing
 actually works.  It used to work for SCSI-1, but things are different now.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1202#comment:8>
One Laptop Per Child <http://laptop.org/>