Re: strange umass/scsi behaviour

On Tue, Jul 29, 2003 at 11:28:18PM -0700, Nate Lawson wrote:
> On Wed, 30 Jul 2003, John Hay wrote:
> > Does anyone have an idea why the umass/scsi code behave differently
> > between if you boot with a device already plugged in as opposed to
> > plugging it in later? In my case it is a Sandisk Cruiser. If I plug
> > it in before booting, it works just great, but if I plug it in later,
> > it does not want to work.
> >
> > umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <SanDisk Cruzer 2.00> Removable Direct Access SCSI-0 device
> > da0: 1.000MB/s transfers
> > da0: Attempt to query device size failed: NOT READY, Medium not present
> > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
> > (da0:umass-sim0:0:0:0): NOT READY asc:3a,0
> > (da0:umass-sim0:0:0:0): Medium not present
> > (da0:umass-sim0:0:0:0): Unretryable error
> > Opened disk da0 -> 6
> > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
> > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition
> > (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
> > (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
> > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
> 
> There's nothing sinister going on here.  What happens is your device is
> slow to power up and initialize when plugged in.  It's not ready for the
> bus scan from CAM but it's awake enough to answer the initial INQUIRY.
> When you boot with it attached, there's a longer delay between when the
> port is powered up and CAM scans the device and so you don't get any
> messages.
> 
> What behavior does the device give after you get the above dmesg?  Does it
> print out errors on console that the retry failed? (see last line of the
> dmesg).  I've been thinking about adding a bit of a delay to the umass CAM
> attach call for such devices.

The last message is "Opened disk da0 -> 6". That is a little strange
because I thought we only do 10 byte commands to usb devices. The
"problem" is that only da0 pitch up in the /dev directory. There should
be a da0s1 too. Using fdisk on da0 does show what looks like a valid
partition table with one DOS partition. I have tried camcontrol reset,
inquiry, start and rescan, but can't get da0s1 to make its appearance.

> 
> > uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xece0-0xecff irq 11 at device 7.2 on pci0
> > usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
> > usb0: USB revision 1.0
> > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> > uhub0: 2 ports with 2 removable, self powered
> > umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2
> 
> Port powered up.
> [~3 secs, perhaps]
> 
> > ad0: 6194MB <IBM-DADA-26480> [13424/15/63] at ata0-master UDMA33
> > acd0: CDROM <TEAC CD-ROM CD-224E> at ata1-master PIO4
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <SanDisk Cruzer 2.00> Removable Direct Access SCSI-0 device
> > da0: 1.000MB/s transfers
> > da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C)
> 
> Device probed.

Yip, if I get that far, the disk is accessable.

John
-- 
John Hay -- John.Hay_at_icomtek.csir.co.za / jhay_at_FreeBSD.org