Date: Sun, 14 Mar 1999 14:24:15 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Message-ID: <19990314142415.23439@uriah.heep.sax.de> In-Reply-To: <199903140828.BAA11613@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:28:20AM -0700 References: <19990314084849.47902@uriah.heep.sax.de> <199903140828.BAA11613@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote: (IBM DCAS & tagged queuing) > Yeah, I'm interested to see your results. If you want, I can send > you camcontrol diffs that will allow you to set the number of tags > for a device on the fly. That would be great. > The problem is that your drive returns a non-standard response when > it isn't spun up. The only response that can really conclusively be > read as "I need to be spun up" is 0x04, 0x02, or "Logical unit not > ready, initializing cmd. required". This is not very surprising. By the time the firmware of this device has been designed (cca. 1990), SCSI-2 wasn't available yet. I guess 0x04, 0x00 was the standard response for a device not being ready then, kinda. > When the error recovery code sees 0x04,0x00 or 0x04,0x01, it assumes > that the drive is just taking a while to become ready. So it sends > a test unit ready every .5 seconds for a minute to see if the drive > is ready. If the drive isn't ready after that, it just assumes that > it won't be ready. What surprises me however is, it's a removable device (and properly announced as this), so a medium shouldn't even be required to be in the drive at boot time, should it? > If you want your drive to be spun up when it returns 0x04,0x00, you > need to add a quirk entry to the sense code table that will tell the > error recovery code to do what you want it to do. I've attached a > quirk entry that may do the trick. Let me know if it works. Thanks!, i was hoping for some advice like this. (Btw., it's IMHO safe to only test for SONY SMO-*, they are all such old devices.) Alas, it doesn't work. :( Right after probing the CD-ROM drive (which is on the other bus), it now jams its SCSI bus. (The following has been written on a sheet of paper, so typos are mine.) ncr1: SCSI phase error fixup: CCB already dequeued (0xc07b0000) ncr1: timeout nccb=0xc07b0000 (skip) ncr1: timeout nccb=0xc07b0000 (skip) ncr1: timeout nccb=0xc07b0000 (skip) (da2:ncr1:0:3:0) got CAM status 0x4b (da2:ncr1:0:3:0) fatal error, failed to attach device (da2:ncr1:0:3:0) lost device (da2:ncr1:0:3:0) removing device entry At this point, the system effectively halts. Upon waiting indefinitely, it would eventually timeout a few more CCBs, but i lost my patience and hit reset. With a spinning medium in the drive, it boots well (and da2 even `arrives' before da1). > I'm not sure why the da driver didn't attach when you rescanned the > drive. I'd have to think on that to figure it out, and it's too > late for thinking too much. :) Understood. My suspicion (just guessing, i don't have an idea of the program flow in the CAM code) is that my attempt to spinup the drive using the pass device (which succeeded) caused the drive to become `half-known', as a subsequent camcontrol devlist seems to confirm (device assigned to pass4, but not to any other driver). A following camcontrol rescan didn't notice it as a new entry, so nothing happened. I played a little, turned off the drive, camcontrol rescan so it had to remove the entry completely. Then turned on the drive again (which also causes it to spin up), and voilá, the next camcontrol rescan makes the drive accessible as both, pass4 and da2. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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?19990314142415.23439>