From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 22:57:44 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 3FBDC37B401 for ; Wed, 30 Jul 2003 22:57:44 -0700 (PDT) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33AB343FBF for ; Wed, 30 Jul 2003 22:57:42 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [IPv6:::1]) h6V5vd5v062295; Thu, 31 Jul 2003 07:57:40 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.12.9/8.12.9/Submit) id h6V5vd4m062294; Thu, 31 Jul 2003 07:57:39 +0200 (SAST) (envelope-from jhay) Date: Thu, 31 Jul 2003 07:57:39 +0200 From: John Hay To: Nate Lawson Message-ID: <20030731055738.GA62002@zibbi.icomtek.csir.co.za> References: <20030730055859.GA15943@zibbi.icomtek.csir.co.za> <20030729232207.M56472@root.org> <20030730064434.GA17559@zibbi.icomtek.csir.co.za> <20030730142800.V58222@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030730142800.V58222@root.org> User-Agent: Mutt/1.4i 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: Thu, 31 Jul 2003 05:57:44 -0000 > > > > 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) > > > ... > > > 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". > > No, according to your message it's "Retrying Command (per Sense Data)". Yip, you are right, I was looking here locally, but that was after trying lots of camcontrol commands. > > That is a little strange > > because I thought we only do 10 byte commands to usb devices. > > That message is from GEOM and has nothing to do with 10 byte commands. ok > > 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. > > Sounds like a GEOM problem. Unless you have other errors from da0 after > the last line you posted, it appears the command retry attempt succeeded. > At that point, the problem is likely with GEOM not parsing the partition > table when it appears and making the slice show up. > > But I don't know enough about GEOM to claim this its fault. Ok, but why does geom pick it up correctly when booting with the disk plugged in? Does geom mabe get called before the disk is ready? If that "Opened disk ..." message is from geom, the order of things looks like geom gets called just after the "Unretryable error". John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org