Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jun 1998 16:13:40 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        shafeeq@cyrus.watson.org (Shafeeq Sinnamohideen)
Cc:        freebsd-scsi@freebsd.org, gibbs@pluto.plutotech.com
Subject:   Re: disappearing cdrom w/ Bt948+CAM
Message-ID:  <199806152213.QAA26718@panzer.plutotech.com>
In-Reply-To: <Pine.BSF.3.96.980615164041.7047B-100000@fledge.watson.org> from Shafeeq Sinnamohideen at "Jun 15, 98 04:45:14 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
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: <CONNER CFA270S P109> 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: <NEC CD-ROM DRIVE:500 1.0> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806152213.QAA26718>