"David C. Hoos, Sr." wrote:
>
> Hi all,
>
> I am experiencing some difficulty using the generic device
> driver (sg) for Linux SCSI.
>
> I am running kernel 2.2.12 and sg3_30013.
>
> The device with which I am trying to communicate is a SCSI-1
> device, characterized as a Direct-Access device with a 1-byte
> block size. The device is actually a modem.
>
> The sg3_utilities/sg_readcap utility returns:
> Read Capacity results:
> Last block address = 10412 (0x28ac), Number of blocks = 10413
> Block size = 1 bytes
>
> The device has three LUNs (0, 1, and 2). 0 may be used for reads
> and writes, but it is preferred to use LUN 1 for reads, and
> LUN 2 for writes.
Now the aic7xxx and the sg output indicate only one scsi device
is found at id=4, lun=0. Is the configuration parameter
CONFIG_SCSI_MULTI_LUN set in the kernel build? [Perhaps is will
cause more problems if it is, but it may be worth a try.]
If the 3 separate luns get registered then you could use
sg to open up a file descriptors for each one.
Another approach is to use the SG_FLAG_LUN_INHIBIT constant in
the 'flags' member of sg_io_hdr. Usually sg overrides the top
3 bits of the second byte of each scsi command with the lun
associated with the open device. With the SG_FLAG_LUN_INHIBIT
set that overwrite does not take place and the user can set
any value they like (e.g. 0x20 for lun 1, 0x40 for lun 2).
> All reads and writes are to/from a region starting at Logical Block
> Address 0. The device supports bus disconnect.
>
> I am using an Adaptec 2930 Host Adapter.
>
> I am using the write-followed-by-read method, instead of the
> SG_IO ioctl, method.
>
> The device file is opened read-write, non-blocking.
>
> The timeouts specified in the sg_io_hdr_t structures for both
> read and write are 5000 milliseconds;
>
> The goal is to be able to monitor the device continuously for,
> and read incoming data, and to be able to write (send) data
> as required.
>
> The problem I am having is evidenced in the attached syslog file
> which covers the time from the most recent reboot until the
> problem occurs.
So I guess the 2930 adapter is controlled by the aic7xxx driver.
Just in case there are more recent drivers you may like to
check up on: http://people.redhat.com/dledford .
> The dump of the /proc/scsi files is also attached.
>
> It seems that there is contention for the SCSI bus, and that when
> a write is attempted while a read is being attempted (and possibly
> times out), the write cannot proceed. This would not be so bad
> in, and of itself, but when the command times out, the computer
> is non-responsive (evidenced, e.g., by an ongoing ping from
> another computer) for about two seconds.
> This, is of course unacceptable.
Unfortunately adapters the use the old scsi error handling code
retry commands on timeouts even though sg tells them not to.
This makes timeouts messy since it involves bus resets.
> It appears that if I could somehow avoid attempting to read unless
> there is data (i.e., thereby avoiding the read timeout) things would
> be OK. To this end, I attempted to use the SG_GET_NUM_WAITING
> ioctl, but it appears that this does not return correct data unless
> the read command has been written to the device -- but, of course,
> by then it's too late to avoid the timeout if there is no data available to
> be read. I have considered using the poll() system call, instead,
> but a look at the sg code seems to indicate that this would be equivalent
> to the use of the ioctl.
SG_GET_NUM_WAITING and poll() only refer to SCSI response
data waiting in the kernel for the user. As you point out
they are only valid after a scsi command has been written
to the device (via write() ). You want to find out whether
data is waiting at the device (modem in your case). It's
a wild guess, but polling the read lun with TEST UNIT
READY may be worth a try (i.e. it might only report
ready when data is available).
> The transferred data is correct in all respects, both ways.
>
> Some of the data in the syslog and the /proc files is mystifying,
> as well. For example, despite the fact that I am writing to LUN 2,
> and reading from LUN 1, these files show only LUN 0. Note
> that the syslog plainly shows the LUNs 1 and 2 to be in the
> read(10) and write(10) commands.
Well I looked at the logs and I can find no reference to luns 1
or 2 in the "aborting ..." messages and all the second bytes
of the read(10) and write(10) commands seems to be 0 (indicating
lun 0).
> I have considered several possibilities to explain this behavior, viz.:
>
> 1. The SG driver does not work correctly with SCSI-1 devices.
> For example, the format of the INQUIRY data is different, and
> both the sg3_utilities and the Adaptec 2930 SCSI_Select
> utility in the Host Adapter EPROM display it as though it
> were SCSI-2 data, (despite the fact that ANSI version 1 is
> returned in the data).
Dug up some SCSI 1 material which says the response to an INQUIRY
looks like this:
INQUIRY Data
==============================================================================
Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Byte | | | | | | | | |
==============================================================================
0 | Peripheral Device Type |
-----|-----------------------------------------------------------------------|
1 | RMB | Device-Type Qualifier |
-----|-----------------------------------------------------------------------|
2 | ISO Version | ECMA Version | ANSI Version |
-----|-----------------------------------------------------------------------|
3 | Reserved |
-----|-----------------------------------------------------------------------|
4 | Additional Length (n) |
==============================================================================
| Vendor Unique Parameters |
==============================================================================
5 _ | Vendor Unique |
n+4 | Parameter Bytes |
==============================================================================
So it looks like our INQUIRY response assumptions are not compliant
with SCSI 1. Such a response doesn't really give us much useful
information at all.
> 2. There is something wrong with the Host Adapter
The aic7xxx driver can handle SCSI 3 devices on a U160 bus.
Getting it to gracefully handle SCSI 1 modems seems like
an interesting excercise in backward compatibility.
> 3. I have misunderstood the operation of the SG_GET_NUM_WAITING
> ioctl, or some other aspect of the sg driver.
It seems to me you understand them correctly (and that
they do not suit your need).
> 4. I need to specify some options to the driver.
Try the SG_FLAG_LUN_INHIBIT option. It will be interesting to
get some feedback because I have no multi-lun scsi device
to test it on.
> Any other suggestions are welcome.
Good luck.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
