From owner-freebsd-hackers  Wed Dec 18 12:50:50 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id MAA26509
          for hackers-outgoing; Wed, 18 Dec 1996 12:50:50 -0800 (PST)
Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26482
          for <FreeBSD-hackers@freebsd.org>; Wed, 18 Dec 1996 12:50:47 -0800 (PST)
Received: by iafnl.es.iaf.nl with UUCP id AA00880
  (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Wed, 18 Dec 1996 21:50:29 +0100
Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id VAA02364 for FreeBSD-hackers@freebsd.org; Wed, 18 Dec 1996 21:49:14 +0100 (MET)
From: Wilko Bulte <wilko@yedi.iaf.nl>
Message-Id: <199612182049.VAA02364@yedi.iaf.nl>
Subject: more on Ultrastor U24f and a solution (sort of)
To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list)
Date: Wed, 18 Dec 1996 21:49:14 +0100 (MET)
X-Mailer: ELM [version 2.4 PL24 ME8a]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi

Did some more testing 'n hacking on the Ultrastor 24f. It has proven
to be a combination of the U24f driver and the Toshiba CDROM I have
in this box:

During boot/probe the SCSI CD driver does:

...
        /*
         * Use the subdriver to request information regarding
         * the drive. We cannot use interrupts yet, so the
         * request must specify this.
         *
         * XXX dufault@hda.com:
         * Need to handle this better in the case of no record.  Rather than
         * a state driven sense handler I think we should make it so that
         * the command can get the sense back so that it can selectively log
         * errors.
         */
        cd_get_parms(unit, SCSI_NOSLEEP | SCSI_NOMASK);
        if (dp->disksize) {
                printf("cd present.[%ld x %ld byte records]",
                    cd->params.disksize,
                    cd->params.blksize);
        } else {
                printf("can't get the size\n");
        }
...

The Toshiba's (I have multiple, all behave the same) report something like:

(ncr0:4:0): "TOSHIBA CD-ROM XM-5301TA 0925" type 5 removable SCSI 2
cd0(ncr0:4:0): CD-ROM 
cd0(ncr0:4:0): 250ns (4 Mb/sec) offset 8.

cd0(ncr0:4:0): NOT READY asc:4,1
cd0(ncr0:4:0):  Logical unit is in process of becoming ready
can't get the size

This is how it works with the Pentium machine. The 486 EISA however locks
up the U24f driver during the check for a loaded CDROM. This only seems
to happen if the system has been power cycled and then booted. Whether
a CD is loaded or not makes no difference.

Uncommenting piece of code that does this probe results in a working system.
So, for now I assume the lower level U24f driver cannot handle somewhat
special reqs the cd_get_parms() has.

It's somewhat nasty because the bootfloppy kills itself in a similar
fashion. My question: is there any reason to do this cd_get_parms() 
in this early stage of probing? Why not do this on a first normal open()
when the kernel is up & running? 

Fixing the ultra14f.c to not lockup is of course also an option ;-)

Wilko
_     ____________________________________________________________________
 |   / o / /  _  Bulte  email: wilko@yedi.iaf.nl - Arnhem, The Netherlands
 |/|/ / / /( (_) 	Do, or do not. There is no 'try' - Yoda
--------------------------------------------------------------------------