Device driver problems

[David C. Hoos, Sr.]

Hi all,

This message is cross-posted because I do not know whether this
is a low-level (aic7xxx) or high-level (sg) problem, or my own problem.

To facilitate diagnosis, I have attached some dumps of the files under
/proc/scsi, as well as the /var/log/messages file from the point of the
last reboot until the problem manifests itself.  The aic7xxx driver
was loaded at boot time with the following options:

verbose:0xFFFF,seltime:1,dump_card,dump_sequencer

I am trying to communicate with a SCSI-1 device for which LUN 0
will disconnect from the SCSI bus if there is no data available to read,
provided the host has reported its ability to disconnect in an Identify
message.

As the /proc/scsi/sg/devices dump shows, the driver thinks the
device does not support disconnect.

I am wondering whether the fact that the device is SCSI-1 (which
has some data structure differences from SCSI-2), causes this
to be incorrectly reported.  The device does work as advertised
on other platforms (e.g. Sun Ultra Sparc).

I have been using the sg_io_hdr_t data structure with write and read
calls to communicate.  What appears to happen is that when a read
command is sent, and no data is available, the device remains
connected to the bus (preventing any write commands from being
sent), until the read command times out.  The drawback to this
(aside from the fact that the delay is unacceptable) is the fact that
something (I don't know whether the driver, the host adapter, or
what puts the machine into a cycle of every 20-seconds (the
read timeout value) resetting, which leaves the machine non-responsive
for two seconds -- i.e. the machine is responsive for twenty seonds,
non-responsive for two, responsive for twenty.... ad infinitum. 

One thing that is not clear to me from the documentation is how
SCSI messages (as opposed to commands) are sent and received.
Can this be done from user-level code, or must it be done in
the kernel?

Do I need a modified device driver to deal with SCSI-1 (vendor
specific) status, codes, etc.?

Is the sg 3.0.13 (20000323) any different from 3.0.4 (991127) in any
respect affecting disconnect?

The reason I ask this question is that one individual with whom I'm in
contact reports no problems with this device using the 3.0.4 driver,
but I was reluctant to take a step backwards, if not necessary.
 
 David C. Hoos, Sr.
 ------------------
The primary purpose of the DATA statement is to give names to
constants; instead of referring to pi as 3.141592653589793 at every
appearance, the variable PI can be given that value with a DATA
statement and used instead of the longer form of the constant.  This
also simplifies modifying the program, should the value of pi change.
                 -- FORTRAN manual for Xerox Computers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: scsi_proc_dump.out
Type: application/octet-stream
Size: 45281 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/aic7xxx/attachments/20000410/7ea0809e/scsi_proc_dump.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messages.scsi
Type: application/octet-stream
Size: 36947 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/aic7xxx/attachments/20000410/7ea0809e/messages.obj