"David C. Hoos, Sr." wrote:
>
> 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.
Perhaps disconnect is a red herring. That mid-level flag that
sg prints out is showing 0 for both my both my IBM DCHSU disks
which is pretty unlikely. Doing a grep on the mid-level code
seems to indicate that the mid-level has no interest in the
state of that flag (i.e. it is left to the HBA driver). If
so perhaps I should replace that column with something more
useful.
> 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?
SCSI messages are left to the HBA driver or its silicon.
CAM3 (FreeBSD) can optionally interface at that level
if the HBA driver supports it.
> 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?
I don't think so. At the time of 3.0.4 the same sg built on
lk 2.2+2.3 . Around 3.0.9 it was split into 3.0.10 for lk 2.2
and 3.1.10 for lk 2.3 . Nearly all of the changes have been
on the lk 2.3 side (mid level changes, bugs etc). You can
re-install sg 3.0.4 to do a regression test. Please tell
me if that makes a difference.
While you are trying regression testing, why not wind the
aic7xxx driver back to the earlier version as well.
> 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.
Looking at the logs, all 3 luns are now picked up. Was that
as a result of turning the MULTI_LUN config switch on?
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
