Date: Sun, 2 Jan 2000 22:41:21 +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.1000102212512.362A-100000@localhost> In-Reply-To: <20000102105945.B33204@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Jan 2000, Bernd Walter wrote:
> I'm using the sym driver under FreeBSD alpha and I have two drives that
> are configured to need a start command.
>=20
> The drives in question are da6 and either da2 or da3.
> Usually I would think it's a problem in a general layer but the drive on =
the
> ahc0 apapter starts just fine.
>=20
> Some interesting side point - SRM can't boot from from the sym1
> controller even if it's alone in the host but ARC can.
I can't help you here, since I haven't ever played with alpha machines.
> The cards are nearly the same but sym1 already has the lsi logo and only =
sym0
> has an external oszilator.
Could that mean that sym1 HA is taking the SCSI clock from the PCI BUS
clock? This is fairly stupid since 10 Mega-transfers/second will not be
possible using a 33 MHz SCSI clock, but this can obviously exist. Btw, the
sym driver only detects 40MHz, 50MHz and 80MHz SCSI clock and assumes 40
MHz in such situation. A 33MHz wrongly assumed 40 MHz SCSI clock may
slightly affect SCSI timing, but since the offending drive (da6) seems to
want asynchronous transfers, I don't think such a SCSI clock mismatch to
be the cause of the problem.=20
The XPT takes decision of starting the device unit based on the sense
information returned by the device. The device (da6) should return CHECK
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
It would be interesting to know how drive da6 responds to a TUR. You may
use the following command and report result:=20
camcontrol tur da6 -v
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
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
G=E9rard.=20
Just quoting da2/3/6:
=20
> da2 at ahc0 bus 0 target 9 lun 0
> da2: <SEAGATE ST318275LC 0001> Fixed Direct Access SCSI-2 device=20
> da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing E=
nabled
> da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C)
> da3 at ahc0 bus 0 target 10 lun 0
> da3: <SEAGATE ST318275LC 0001> Fixed Direct Access SCSI-2 device=20
> da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing E=
nabled
> da3: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C)
> da6 at sym1 bus 0 target 2 lun 0
> da6: <DEC RZ55 (C) DEC 0900> Fixed Direct Access SCSI-CCS device=20
> da6: 3.300MB/s transfers
> da6: 316MB (649040 512 byte sectors: 64H 32S/T 316C)
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.1000102212512.362A-100000>