Date: Mon, 15 Mar 1999 23:07:10 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Message-ID: <199903160607.XAA23750@panzer.plutotech.com> In-Reply-To: <19990315083937.29224@uriah.heep.sax.de> from J Wunsch at "Mar 15, 1999 8:39:37 am"
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch wrote... > As Kenneth D. Merry wrote: > > > Well, to avoid having to send the patches to too many more people, > > I've put them here: > > > http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 > > (OK, will have to test this later on.) > > > Right, media should not be required. What we *do* require is that > > the device tell us in some intelligible way that there is no media > > in it. > > Hmm, what we'd probably need here is a document describing the SCSI > CCS. See my below. > > > Hmm. The CAM status 0x4b means that the command timed out, and that > > the queue for that device was frozen. I don't know why it hung your > > system. > > Weird. Is there any way to further debug this. I think so. See my comments on read capacity below. > > Okay, let me see if I've got this straight: > > > > - It works with media in the drive and spinning. > > Yep. > > > - If there is no media in the drive, it doesn't work. What happens > > in this case? > > I didn't test myself, but it probably won't attach. Here's the result > i get from an attempted `start' command without a medium: > > uriah # camcontrol tur -v -u 2 > Unit is not ready > (pass4:ncr1:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass4:ncr1:0:3:0): NOT READY asc:a,0 > (pass4:ncr1:0:3:0): Error log overflow > > Right now that i see it, i can remember i've seen the `Error log > overflow' before. Okay, that's the same error Matthew Dodd was getting. What happens if you do what I suggested that he do? i.e., change the code in the probe case in dadone(), so that 0xa is an acceptable ASC? My guess is that will allow you to attach without media. > > - If there is media in the drive that isn't spinning, and you've got > > the quirk entry in scsi_all.c, the spinup command may be timing > > out. > > Yep, although camcontrol's spinup command would work later. > > > How long does the start unit command take for that drive? > > A few seconds, about 5 to 10 if the medium is (optically) clean. In > the case of an unclean medium, it might take up to one minute > approximately, until the drive will eject the medium. > > > The timeout for the start unit command in the error recovery code > > is 50 seconds. (The start unit is done in cam_periph.c) > > That should suffice. Btw., IIRC the medium did _not_ spin up in the > case where it hung the bus, so the START STOP UNIT command apparently > didn't make it to the drive. The command that timed out in that case, I'm pretty sure, was the read capacity. One question I have is this -- once the media is spinning, how long does it take to do a read capacity? You can find out like this: /usr/bin/time camcontrol cmd -t 60 -v -n da -u 2 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" What happens if the media is not spinning and you do a read capacity? Does the drive try to spin itself up? The default timeout for the read capacity in the DA driver is 5 seconds. If the MO drive attempts, for whatever reason, to spin itself up when it gets a read capacity, we may need to bump the timeout on the read capacity command. Of course I could be barking up the wrong tree here... But it does kinda fit what you were saying -- that starting the drive from camcontrol worked, even when the DA driver failed to attach. Anyway, I think we're starting to get a handle on what this device does... Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903160607.XAA23750>