From owner-freebsd-scsi Sun Mar 14 21:48:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5027514CD5 for ; Sun, 14 Mar 1999 21:48:52 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA17045; Sun, 14 Mar 1999 22:48:27 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903150548.WAA17045@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 15, 1999 0:23:24 am" To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 14 Mar 1999 22:48:27 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Sun, 14 Mar 1999, Kenneth D. Merry wrote: > > I'm sure we can get the thing working properly, if I can just get a handle > > on what error codes the device returns for these two situations: > > > > - no disc in the drive > > eisa-test# camcontrol rescan 2 > > (da5:dpt0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da5:dpt0:0:3:0): NOT READY asc:a,0 > (da5:dpt0:0:3:0): Error log overflow > (da5:dpt0:0:3:0): fatal error, failed to attach to device > (da5:dpt0:0:3:0): lost device > (da5:dpt0:0:3:0): removing device entry I must say, that is truly bizarre. Well, here's a quick and dirty way to make the drive attach without media present. In scsi_da.c, in the DA_CCB_PROBE case of dadone(), you'll see an if statement. Make it look like this: ================================================= /* * With removable media devices, we expect * 0x3a (Medium not present) errors, since not * everyone leaves a disk in the drive. If * the error is anything else, though, we * shouldn't attach. */ if ((have_sense) && ((asc == 0x3a) || (asc == 0xa)) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), "Attempt to query device " "size failed: %s, %s", scsi_sense_key_text[sense_key], scsi_sense_desc(asc,ascq, &cgd.inq_data)); else { ================================================= i.e., just add the asc == 0xa part in. That isn't the best solution for the problem, certainly. A more permanent solution will require some more work. I've got two ideas that would fix it, but I'll have to think about which one would be the best. I don't think it's a good idea to have 0xa be an "acceptable" error code for the da driver in the general case. It's fine for this special case, but I'd rather not enable it for all devices. > eisa-test# camcontrol devlist > ... > at scbus2 target 3 lun 0 (pass13) > ... > > > - disc is in, but isn't spinning > > > eisa-test# camcontrol stop -n pass -u 13 > Unit stopped successfully > > eisa-test# camcontrol rescan 2 > > eisa-test# camcontrol rescan 2 > > da5 at dpt0 bus 0 target 3 lun 0 > da5: Removable Direct Access SCSI-CCS device > da5: 281MB (576999 512 byte sectors: 64H 32S/T 281C) > eisa-test# camcontrol tur -n da -u 5 > Unit is not ready > > eisa-test# camcontrol start -n da -u 5 > > Unit started successfully > > This only means that the drive remembered the capacity of the disk I had > in before I spun the disk down. My unit automatically spins up the > platter when I insert it so I'm not sure I'll be able to provide you with > a test of the rescan with the unit stopped. :/ Hmm, oh well. Well, maybe Joerg's behaves differently. Perhaps he can boot his system without the disc spinning. > Any specific commands you want me to test? I'm guessing I should compile > CAMDEBUG into the kernel if I'm to be of any use to you. Well, I think I've got a handle on things I suppose. Does the drive return the 0xa error on boot when there is no media inserted? What I want to make sure of is that the "Error log overflow" error wasn't brought on somehow by inserting/removing the device from the bus or from some other activity. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message