From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 23:28:18 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B083F37B401 for ; Tue, 29 Jul 2003 23:28:18 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3519343FAF for ; Tue, 29 Jul 2003 23:28:16 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 56493 invoked by uid 1000); 30 Jul 2003 06:28:18 -0000 Date: Tue, 29 Jul 2003 23:28:18 -0700 (PDT) From: Nate Lawson To: John Hay In-Reply-To: <20030730055859.GA15943@zibbi.icomtek.csir.co.za> Message-ID: <20030729232207.M56472@root.org> References: <20030730055859.GA15943@zibbi.icomtek.csir.co.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: strange umass/scsi behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2003 06:28:19 -0000 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: 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. > uhci0: port 0xece0-0xecff irq 11 at device 7.2 on pci0 > usb0: 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 [13424/15/63] at ata0-master UDMA33 > acd0: CDROM at ata1-master PIO4 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 1.000MB/s transfers > da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C) Device probed. -Nate