From owner-freebsd-scsi Mon Jun 15 15:14:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08674 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 15:14:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08619 for ; Mon, 15 Jun 1998 15:13:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA26718; Mon, 15 Jun 1998 16:13:40 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806152213.QAA26718@panzer.plutotech.com> Subject: Re: disappearing cdrom w/ Bt948+CAM In-Reply-To: from Shafeeq Sinnamohideen at "Jun 15, 98 04:45:14 pm" To: shafeeq@cyrus.watson.org (Shafeeq Sinnamohideen) Date: Mon, 15 Jun 1998 16:13:40 -0600 (MDT) Cc: freebsd-scsi@freebsd.org, gibbs@pluto.plutotech.com X-Mailer: ELM [version 2.4ME+ PL28s (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 Shafeeq Sinnamohideen wrote... > So, I decided to try out CAM on my SMP machine with a Bt-948. > The problem is that during the bus probe, it fails to discover the NEC > CDR-500 at id 6, along with the attached error messages. If I understand > correctly, the messages are the result of trying to probe LUNs of device > 0? The messages from the scsi probe section of a CAM & non CAM kernel are > below, & I'd be glad to provide any other information that would help. > messages from CAM kernel : > > Jun 9 23:03:02 luthien /kernel.CAM: bt0: Using Strict Round Robin Mailbox Mode > Jun 9 23:03:02 luthien /kernel.CAM: SMP: AP CPU #1 Launched! > Jun 9 23:03:02 luthien /kernel.CAM: SMP: CPU1 apic_initialize(): > Jun 9 23:03:02 luthien /kernel.CAM: lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): INQUIRY. CDB: 12 20 0 0 24 0 > Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): error code 67 [ CONNER hard drive returning bogus error codes when it's probed on luns greater than 0 ] > Jun 9 23:03:04 luthien /kernel.CAM: pass0 at bt0 bus 0 target 0 lun 0 > Jun 9 23:03:04 luthien /kernel.CAM: pass0: Fixed Direct Access SCSI2 device > Jun 9 23:03:04 luthien /kernel.CAM: pass0: 10.0MB/s transfers (10.0MHz, offset 15) I would suggest adding a quirk entry to xpt_quirk_table in sys/cam/cam_xpt.c like this: { /* Barfs on luns > 0 */ { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFA270S", "*" }, CAM_QUIRK_NOLUNS, /*mintags*/2, /*maxtags*/64 }, Put that entry just before the last quirk entry in the table and see if it helps any. Let me know if that fixes your problem, we can put it in the quirk table by default if it does. As for why your second CDROM drive isn't getting recognized, I don't really have any quick answers for you. One thing to keep in mind is that the drive isn't even making it through the probe sequence. If it were, the passthrough driver at least would attach. I have a similar drive on one of my machines (running CAM): cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers ) cd0: cd present [314535 x 2048 byte records] Although it is on an Adaptec controller, not a BusLogic controller. The probe sequence is generally: standard inquiry [ If we have a tagged queueing device, get the control mode page to determine whether or not tagged queueing is disabled or not ] serial number test unit ready (for negotiation) One thing you might be able to do is put some printfs in probedone() to see whether various commands are succeeding or failing, and possibly get a better handle on the problem. I would suggest initially just putting a scsi_sense_print() in the PROBE_INQUIRY case of probedone(), like this: [ .... ] } else if ((done_ccb->ccb_h.status & CAM_SIM_QFRZN) != 0) { /* Don't wedge the queue */ xpt_release_devq(done_ccb->ccb_h.path->device, /*run_queue*/TRUE); } /* XXX this is new XXX */ if ((done_ccb->ccb_h.target_id == 6) && (done_ccb->ccb_h.target_lun == 0)) { printf("got an error back while probing the CDROM\n"); scsi_sense_print(&done_ccb->csio); } /* XXX end of new code */ /* * If we get to this point, we got an error status back * from the inquiry and the error status doesn't require [ .... ] You'll add that little snippet of code in around line 3422 of cam_xpt.c. Anyway, see if that reveals anything. Justin may have some ideas, since he wrote the BusLogic driver. Don't expect to hear from him until next week, though. (we'll both be at Usenix this week) One other thing....I assume you're running the latest CAM snapshot? (May 20th) If not, you need to upgrade, since there were some significant bugs in earlier versions of the CAM BusLogic driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message