From owner-freebsd-current Mon Sep 21 15:07:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21377 for freebsd-current-outgoing; Mon, 21 Sep 1998 15:07:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21207; Mon, 21 Sep 1998 15:06:42 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA09558; Mon, 21 Sep 1998 16:06:10 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809212206.QAA09558@panzer.plutotech.com> Subject: Re: [CAM] boot messages, not configured devices In-Reply-To: <199809211932.VAA00566@qix> from Jean-Marc Zucconi at "Sep 21, 98 09:32:31 pm" To: jmz@FreeBSD.ORG (Jean-Marc Zucconi) Date: Mon, 21 Sep 1998 16:06:10 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM906415570-9512-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM906415570-9512-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jean-Marc Zucconi wrote... > Thanks to the latest changes in the ncr driver I am able to boot a cam > kernel. It works well, but I get a lot of > 'MSG_MESSAGE_REJECT received (2:8)' messages during boot (see log > below). What do they mean? It looks like one of your CDROM drives doesn't like it when we try to scan additional LUNs. I've attached a patch to cam_xpt.c, see if that elminates the messages. > In addition the cd driver refuses to attach my CD-R if there is > no CD inside at boot time (cd2: fatal error: NOT READY), although it is > correctly probed during the scan phase: > pass5 at ncr1 bus 0 target 3 lun 0 > pass5: Removable CD-ROM SCSI2 device > pass5: 3.300MB/s transfers Well, that's the passthrough driver, not the probe pseudo-peripheral. The passthrough driver will attach to anything that survives the probe phase. (i.e., anything that responds to an inquiry) > Here are the boot messages: > [...] > Intel Pentium F00F detected, installing workaround [ ... ] > (probe0:ncr0:0:2:7): MSG_MESSAGE_REJECT received (2:8). > (probe0:ncr0:0:2:7): MSG_MESSAGE_REJECT received (2:8). > sa0 at ncr1 bus 0 target 4 lun 0 > sa0: Removable Sequential Access SCSI2 device > sa0: 10.0MB/s transfers (10.0MHz, offset 8) > da2 at ncr1 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI2 device > da2: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled > da2: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) > da1 at ncr0 bus 0 target 6 lun 0 > da1: Fixed Direct Access SCSI2 device > da1: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled > da1: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) > cd0 at ncr0 bus 0 target 2 lun 0 > cd0: Removable CD-ROM SCSI2 device > cd0: 4.32MB/s transfers (4.32MHz, offset 8) > cd0: cd present [337280 x 2048 byte records] > cd1 at ncr0 bus 0 target 5 lun 0 > cd1: Removable CD-ROM SCSI2 device > cd1: 3.968MB/s transfers (3.968MHz, offset 8) > cd1: Attempt to query device size failed: NOT READY, Medium not present > da0 at ncr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI2 device > da0: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > changing root device to da0s4a > changing root device to da0a > cd2: fatal error: NOT READY, Logical unit not ready, cause not reportable -- failed to attach to device > (cd2:ncr1:0:3:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd2:ncr1:0:3:0): NOT READY asc:4,0 > (cd2:ncr1:0:3:0): Logical unit not ready, cause not reportable There are a couple of possible explanations for this. How long is your bus settle delay? It's possible that it takes a while to figure out that doesn't have a CD in it or something like that. Try increasing SCSI_DELAY to 30000 (30 seconds). Generally, when CDROM/WORM drives don't have any media on board, they return a status of 0x3a,0x00. (medium not present) If that fixes the problem, you can decrease it gradually until you figure out how long it needs. If increasing the bus settle delay doesn't fix it, there are other things we can do that will probably fix the problem. Ken -- Kenneth Merry ken@plutotech.com --ELM906415570-9512-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=cam_xpt.sony.diffs Content-Description: cam_xpt.sony.diffs Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/cam_xpt.c#156 - /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c ==== *** /tmp/tmp.6338.0 Mon Sep 21 16:02:41 1998 --- /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c Mon Sep 21 15:57:10 1998 *************** *** 300,305 **** --- 300,312 ---- CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, { + /* This drive doesn't like multiple LUN probing */ + { + T_CDROM, SIP_MEDIA_REMOVABLE, "SONY", "CDU-80*", "*" + }, + CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 + }, + { /* Default tagged queuing parameters for all devices */ { T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, --ELM906415570-9512-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message