problem with samsung flash

[Nate Lawson]

Nate Lawson wrote:
> Ivan Frosty wrote:
>> hello there, i have freebsd 6.1 pentiumII 355mhz processor and 128mb
>> of ram. everytime i put my samsung 512mb in tha usb the machine doesnt
>> boot it halts where the error be at if i pull it out it
>> boots.........then if i put it back in i get an error.......whats with
>> umass? i basically installed everybit and software of the unix i have
>> so i dont know why i get the error anyhelp will be highly appreciated!
>>
>> this is the error:
>>
>> da0 at umass-sim0 bus0 target0wn0
>> da0:<SAMSUNG flash Disk 1.06> Removable Direct Access SCSI-0 device
>> da0:1.000MB/s transfers
>> da0:511mb(1046720 512 byte sectors:64H 32s/T s11c)
>> umass0:phase Error, residue = 0
>> (da0:umass-sim0:0:0:0):synchronize cache failed, status == 0x4,scsi
>> status == 0x0 opened disk da0->5!
>>
>> thank you for your time
> 
> Hi, this is a common error and should be a FAQ somewhere.  Some USB 
> devices can't handle SYNC CACHE, the command that says to write their 
> data out to storage.  Most can or reject it with an error and continue. 
>  Some hang, including yours.  You can add a SCSI quirk (no sync cache). 
>  See the entries at the beginning of scsi_da.c for an example how to do 
> it.  Your string would be "SAMSUNG", "flash Disk", "*".  See if that helps.
> 
> As far has fixing this problem permanently, does anyone have an idea on 
> how the experimental work went with disabling sync cache if the INQ data 
> indicates the device doesn't cache data (similar to Linux)?
> 
> Also, what do the scsi@ guys think of me adding a tunable/sysctl that is 
> unit-specific so people can disable it without a quirk?  Example:
> dev.da.0.no_sync_cache="1".  It would be off by default, of course.

Sorry for following up so quickly.  The sysctl doesn't make sense since 
the device isn't available until it's probed and bus reordering makes a 
unit-specific quirk seem dumb.

I have one other question -- why are we calling sync cache during the 
boot and probe process?  Shouldn't that only happen when the dev node is 
opened and then closed again (i.e. unmount)?  Is this caused by GEOM 
opening the drive to taste it and closing it again?  If so, it seems an 
easy partial fix would be to have GEOM open dev nodes read-only.  Then, 
make scsi-da only do sync cache if the device was opened r/w, if it 
doesn't already implement that behavior.

This would fix this problem for the common case of "plug in umass flash, 
mount, use, umount, eject".  The sync cache after umount would fail, but 
the device is disappearing very soon anyway.  The only thing it wouldn't 
fix is umounting/remounting, and perhaps the experimental check for WC 
bit or whatever will be necessary to fix that.  Still, this GEOM 
behavior might be good anyway.

Thoughts?

-- 
Nate