Date: Sun, 14 Mar 1999 16:42:06 -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: <199903142342.QAA14908@panzer.plutotech.com> In-Reply-To: <19990314142415.23439@uriah.heep.sax.de> from J Wunsch at "Mar 14, 1999 2:24:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch wrote... > 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. 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 Generally, you should test under the following conditions: With write caching enabled: 64, 32, 16, 8, 4, 3, 2 and 1 tags With write caching disabled: 64, 32, 16, 8, 4, 3, 2 and 1 tags To view the current number of tags: camcontrol tags To view the maximum and minimum number of tags: camcontrol tags -v To set the number of tags: camcontrol tags -n da -u 3 -N 32 To disable tagged queueing (i.e. set the number of tags to 1): camcontrol negotiate -T disable The man page in the above patch should explain things. There are a number of other options to the 'tags' and 'negotiate' arguments. The patches are almost ready to be checked in. I think they just need some cleanup and the man page is missing descriptions of a couple of things. > > 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. Probably so. > > 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? 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. The da driver looks for a "medium not present" type of error code (i.e., asc == 0x3a). If it sees an error message like that, it determines that media isn't present and attaches anyway. But I thought that you were trying to get the system to boot with a disk in the drive, but not spinning. > > 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. 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. > With a spinning medium in the drive, it boots well (and da2 even > `arrives' before da1). Okay, let me see if I've got this straight: - It works with media in the drive and spinning. - If there is no media in the drive, it doesn't work. What happens in this case? - 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. How long does the start unit command take for that drive? The timeout for the start unit command in the error recovery code is 50 seconds. (The start unit is done in cam_periph.c) > > 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. Hmm, yeah, could be something like that. The pass device will attach to anything that responds to an inquiry. You wouldn't have been able to spin up the drive using the pass driver if the pass driver weren't attached. You're correct -- when you did a rescan, since there was no new device found, it didn't broadcast a "found device" async callback, so no new peripheral drivers attached. 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?199903142342.QAA14908>