Date: Sun, 2 Jan 2000 23:39:44 +0100 From: Bernd Walter <ticso@cicely.de> To: Gerard Roudier <groudier@club-internet.fr> Cc: Bernd Walter <ticso@cicely.de>, freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000102233944.B87267@cicely8.cicely.de> In-Reply-To: <Pine.LNX.3.95.1000102212512.362A-100000@localhost> References: <20000102105945.B33204@cicely8.cicely.de> <Pine.LNX.3.95.1000102212512.362A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > > 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. > > > > 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. > > > > 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. I asume noone can help me here beside digital/compaq - I just wanted to note this. It causes no problems for me because I can boot with the other controller. > > > 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. I don't know where they get the clock from and the only sync device on this bus is the cdrom which is negotiated with the usual frequency for this kind of drive. I have the same controller in an i386 host using the old ncr driver and both drives are negotiated to 10MHz. Wonder if it realy does 10MHz? One of the disks can do nearly 10MB/sec if the data is in the cache - and it does less currently. There's free space for an Oszilator on the PCB - Guess I should solder one. I remember that there is a configuration wire soldered which might have something to do with the clock - Maybe that's the reason for the SRM problem. > 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. > > It would be interesting to know how drive da6 responds to a TUR. You may > use the following command and report result: > > camcontrol tur da6 -v > bash-2.03# camcontrol tur -u 6 -n da Unit is not ready nothing unusual here. > 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. 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. > 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. The drive can't do sync transfers so async is correct. There is nothing unusual beside that I need to manualy send a start command to the drive. Anyway if you think it has nothing to do with your driver and it's not worth 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. > > da6 at sym1 bus 0 target 2 lun 0 > > da6: <DEC RZ55 (C) DEC 0900> Fixed Direct Access SCSI-CCS device > > da6: 3.300MB/s transfers > > da6: 316MB (649040 512 byte sectors: 64H 32S/T 316C) -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?20000102233944.B87267>