Subject: Re: WE scsi startup
To: Henric Jungheim <henric@zoom.com>
From: Michael L. Hitch <osymh@gemini.oscs.montana.edu>
List: port-amiga
Date: 03/31/1996 19:09:54
On Mar 31, 4:24pm, Henric Jungheim wrote:
> hang when configuring my hard drives) so I recompiled my kernel with some
> of the debugging options enabled (specifically, DDB, DIAGNOSTIC, KTRACE,
> DEBUG, SYSCALL_DEBUG, and SCSIDEBUG). This new kernel starts properly,
^^^^^^^^^
> but since I did a 'sup' between my non-working kernel and this new one, I
> don't know if it's the config or if it's something else. Anyway, I get an
I did recently make some changes in the 53c710 driver (used on the
WarpEngine), but I don't think they would have fixed any hangs. Besides
the A4000T fixes, I eliminated some possible NULL pointer references.
If these had been occuring previously, the kernel should have paniced
(although maybe it might act differently during the device configuration).
> odd line in my startup (twice actually; once for each of my drives):
> scsi_inqmatch: 2/0/0 <, , >
>
> I think this is generated in /usr/src/sys/scsi/scsiconf.c. From looking
> at scsiconf.c, it seems that the stuff between the "<" and the ">" should
> be vendor, product, and revision strings. Am I missing something obvious
> here?
Setting SCSIDEBUG enables a print on each match of the vendor, product,
and revision strings with entries in table that's being searched. I
originally thought it was with the scsi_quirk table, but I finally
figured out it was with a table used to determine if the device is
valid for the sd driver. That table has 0 length strings for the
vendor, product, and revision information. These will match sucessfully,
and prints out the scsi_inqmatch message you are seeing. (It's the
information in the matching table entry that's printed, not the information
from the device.)
Michael
--
Michael L. Hitch INTERNET: osymh@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA