Date: Tue, 4 Jan 2000 00:39:08 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Bernd Walter <ticso@cicely.de> Cc: freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <Pine.LNX.3.95.1000104001636.332A-100000@localhost> In-Reply-To: <20000102233944.B87267@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Jan 2000, Bernd Walter wrote:
> On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote:
> >=20
> > On Sun, 2 Jan 2000, Bernd Walter wrote:
> > The XPT takes decision of starting the device unit based on the sense
> > information returned by the device. The device (da6) should return CHEC=
K
> > CONDITION status on TUR (test unit ready command) and then provide the
> > corresponding sense information on a subsequent REQUEST SENSE command. =
The
> > REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if =
a
> > CHECK CONDITION status is returned.=20
> >=20
> > It would be interesting to know how drive da6 responds to a TUR. You ma=
y
> > use the following command and report result:=20
> >=20
> > camcontrol tur da6 -v
> >=20
> bash-2.03# camcontrol tur -u 6 -n da
> Unit is not ready
I was expecting the whole sense data or at least asc/ascq values. There
are numerous way to be not ready for a device and only one is documented by
SCSI as suggesting a start command to be sent by the initiator.
Values are ASC=3D4, ASCQ=3D2
ASC=3D4 means 'not ready', ASCQ value tells about the reason or suggests th=
e=20
next action to apply. ASCQ=3D2 when ASC=3D4 suggest initializing command to=
be=20
sent to the device.
If your device does not return these values, then quirked it should be, in
my opinion.
'man camcontrol' talk about the -v option used with tur subcommand to
display sense data in case of CHECK CONDITION. Could you give a try with
the -v option and report result.
> nothing unusual here.
But not enough to make sure CAM received relevant information from the
device.
> > You probably noticed that the device is claiming SCSI-CCS which is kind=
of
> > pre-scsi-2 standard. This may explain the difference if the sense data
> > returned by the device are not understood by the CAM XPT. Just a guess.=
=20
>=20
> That's a possible reason - I never thought about something special with
> the drive as I never got such problems - but all of my other CCS drives
> start up direct after power-on.
> Nevertheless TUR shows that the drive returns te right sense so it's not
> the TUR itself what confuses XPT.
May-be the XPT has not been confused but just misinformed by the device.
> > I suggest you to play with 'camcontrol', and, for example, to send
> > explicit start_stop commands to the device, try sync negotiations with =
it
> > and see how it behaves.=20
>=20
> The drive can't do sync transfers so async is correct.
Ok.
=20
> There is nothing unusual beside that I need to manualy send a start comma=
nd
> to the drive.
>=20
> Anyway if you think it has nothing to do with your driver and it's not wo=
rth
> to think about the reason - I can live with it as it's only a camcontrol
> command in /etc/rc . I just worried it might happen on other drives too.
By the way, some devices seem already quirked in scsi_all.c for CAM to
send them a start command appropriately. :)
G=E9rard.
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?Pine.LNX.3.95.1000104001636.332A-100000>