Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jun 2000 00:08:40 -0600
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        Takefumi SAYO <stake@niagara.shiojiri.ne.jp>
Cc:        thomas.graichen@innominate.de, tech@ioiscsi.com, scsi@FreeBSD.ORG
Subject:   Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE
Message-ID:  <20000615000840.A39913@panzer.kdm.org>
In-Reply-To: <20000614225332T.stake@po.shiojiri.ne.jp>; from stake@niagara.shiojiri.ne.jp on Wed, Jun 14, 2000 at 10:53:32PM %2B0900
References:  <20000611013840D.stake@po.shiojiri.ne.jp> <Pine.LNX.4.21.0006130836410.5729-300000@h2o.bln.innominate.de> <20000614225332T.stake@po.shiojiri.ne.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 14, 2000 at 22:53:32 +0900, Takefumi SAYO wrote:
> From: "Kenneth D. Merry" <ken@kdm.org>
> Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE
> Date: Tue, 13 Jun 2000 10:46:23 -0600
> 
> > On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote:
> > > On Sun, 11 Jun 2000, Takefumi SAYO wrote:
> > > > and 
> > > > 
> > > > (cd0:iha0:0:6:0): got CAM status 0xb
> > > > (cd0:iha0:0:6:0): fatal error, failed to attach to device
> > > > (cd0:iha0:0:6:0): lost device
> > > > (cd0:iha0:0:6:0): removing device entry
> > > > 
> > > > if no media presents in the removable device.
> > > > 
> > > > Could you fix this if you have time?  Because I don't know
> > > > anything about SCSI and CAM. :-(
> > > > 
> > > i don't know much more either :-) ... but i think you may ask this
> > > on the scsi list (i'll cc this mail to it too) - maybe someone
> > > there might help
> > 
> > Status 0xb is a command timeout.  It means the drive didn't respond to the
> > READ CAPACITY command within 20 seconds.
> 
> When I used 'cdrecord' on FreeBSD 3.4-RELEASE with IOI's driver,
> cdrecord said ... timeout or something like that, and I could not 
> burn CD-R.  But on 2.2.8-RELEASE, there was no problem, I think. 

Okay, that's good to know -- it likely worked at one point.

> > What kind of CDROM drive are you using? 
> 
> a SCSI-2 CD-R drive producted by Matsushita.
> kernel says the followings when booting.
> 
> cd0 at iha0 bus 0 target 6 lun 0
> cd0: <MATSHITA CD-R   CW-7502 4.10> Removable CD-ROM SCSI-2 device
> cd0: 20.000MB/s transfers (20.000MHz, offset 15)
> cd0: cd present [328831 x 2048 byte records]
> 
> (As I mentioned in the report to Graichen, 'got CAM status 0xb' is
> not displayed if media is present in drive.)

Seems like a normal drive, I guess.  Here's one thing you can try.  In
sys/cam/scsi/scsi_cd.c, in the cdstart() function, in the CD_STATE_PROBE
case, you'll find the following function call:

                scsi_read_capacity(csio,
                                   /*retries*/1,
                                   cddone,
                                   MSG_SIMPLE_Q_TAG,
                                   rcap,
                                   SSD_FULL_SIZE,
                                   /*timeout*/20000);

The default timeout is 20 seconds.  Try increasing that value to say 300
seconds (i.e. 300000 milliseconds).

See if your drive reports a reasonable status then.

If it does, try decreasing the timeout until you find the place where it
fails.

Some drives take a long time to return a read capacity command when there
is no media present.  Until now, 20 seconds has been long enough to catch
most of them, but it may be that the timeout is too short for your drive.

If we can find a timeout that'll do the trick, and it isn't too long, we
may be able to increase the default timeout in the driver.

If you'd like a slightly faster way to test this out, without recompiling
your kernel, you can try this:

camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4"

That will issue a SCSI READ CAPACITY command to pass0, with a timeout of
300 seconds.

If there is no media in the drive, and the command hasn't timed out, you
should get SCSI sense information like this:

# camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4"
camcontrol: error sending command
(pass2:ahc1:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
(pass2:ahc1:0:4:0): NOT READY asc:3a,0
(pass2:ahc1:0:4:0): Medium not present

If there is media in the drive, you should get output like this:

# camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4"
187384 2048 

If the command times out, you should get some sort of CAM status back that
would indicate a timeout (probably 0xb).

Anyway, you can start with say 300 seconds, and then decrease the timeout
gradually until you get a failure with a timeout instead of SCSI sense
information.

> > Does it do the same thing with
> > other SCSI cards?
> 
> Sorry... I don't have any other SCSI card.  I bought IOI's card, because
> I saw penguin ready logo on it and it was not so expensive. :-)
> And is is not fully daemon ready now ... X-<

Unfortunately, you may be right.

If you can manage to borrow another kind of SCSI card, we might be able to
eliminate the driver as a possible source of problems.

> > Even though the cd(4) driver doesn't attach, the pass(4) driver should
> > attach if you have it configured.  Type 'camcontrol devlist' to see which
> > pass(4) driver instance is attached to the drive, then you can do things
> > like:  (if the drive is attached as 'pass5')
> > 
> > camcontrol inquiry pass5
> > camcontrol tur pass5 -v
> 
> I tried.
> 
> bash-2.04# camcontrol devlist
> <MATSHITA CD-R   CW-7502 4.10>     at scbus0 target 6 lun 0 (pass0)
> bash-2.04# camcontrol tur pass0 -v
> Unit is not ready
> CAM status is 0x280

Now that is strange -- that indicates the following status:

        CAM_REQ_INPROG,         /* CCB request is in progress */
        CAM_AUTOSNS_VALID = 0x80,
        CAM_SIM_QUEUED   = 0x200,/* SIM has this command in it's queue */

If the command is returned, it shouldn't have a status of "in progress".
It should either have a status of CAM_REQ_CMP, or some sort of error and
possibly include some SCSI sense data.

> (insert some CD-ROM into drive)
> 
> bash-2.04# camcontrol tur pass0 -v
> Unit is ready

That's the expected behavior of course.

> > > maybe some more words about the initio driver: i currently have
> > > absolutely no time to further work on this - so it would be
> > > really fine if anyone might find the time to get this
> > > going ... i may test it - i have both conteollers
> > > here - one a100 and one 9100u ...
> > 
> > Maybe someone will volunteer to work on it.
> 
> I read 'newbusified' diffs that Graichen sent to me, but I could not
> understand how to newbusify Initio's driver...
> If some experts work on it, I'll be happy.

The conversion to newbus will only remove the warning about using
compatibility shims, it shouldn't have any effect on the problem you're
having.

Ken
-- 
Kenneth Merry
ken@kdm.org


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?20000615000840.A39913>