Date: Wed, 30 Jul 2003 08:44:34 +0200 From: John Hay <jhay@icomtek.csir.co.za> To: Nate Lawson <nate@root.org> Cc: current@freebsd.org Subject: Re: strange umass/scsi behaviour Message-ID: <20030730064434.GA17559@zibbi.icomtek.csir.co.za> In-Reply-To: <20030729232207.M56472@root.org> References: <20030730055859.GA15943@zibbi.icomtek.csir.co.za> <20030729232207.M56472@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@icomtek.csir.co.za / jhay@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030730064434.GA17559>