Ard van Breemen wrote:
>
> [snip]
> >
> > There are 2 ways that I can think of that you did this "pass through":
> > - using the SCSI_IOCTL_SEND_COMMAND ioctl()
> > - using the scsi generic (sg) device.
> >
> > Given the problem that you are reporting my guess is that you
> > used the first one. There are 2 problems with that, retries
> > are attempted (that in the worst case can lead to SCSI bus resets)
> > and that ioctl either gives your data back (in the case of a read
> > like command) or a sense buffer (in the case of any non-zero
> > status/error).
> Well, actually, no. Although AMI's megamgr does use the
> SCSI_IOCTL_SEND_COMMAND, I cannot use it. The program I work on is meant
> to initialize the raid-controller's configuration. There are no
> logical SD devices yet, only one sg device: the SAF-TE.
Ok, it was a bad guess. Confusion arises because there
are 2 error processing units within the SCSI mid-level
depending on whether the newer "error handling" is selected
by the low level driver or not. What I wrote applied to the
error logic in scsi_error.c while the megaraid driver uses
the older error processing in scsi_obsolete.c . To date Eric
Youngdale doesn't seem to have been very successful in
getting HBAs moved to the newer logic, unfortunately.
> [snip]
> > Even though the SCSI_IOCTL_SEND_COMMAND ioctl() is deprecated
> > it is still supported. Recently I wrote some documentation for
> > it that appears in front of the
> > scsi_ioctl::scsi_ioctl_send_command() function definition in
> > the lk 2.3 tree. It is also discussed in
> > http://www.torque.net/sg/p/scsi-generic_long.txt .
> I need stable. Currently I'm using sg-II. It works fine, except
> for the megaraid driver returning "bogus".
The semantics of the SCSI_IOCTL_SEND_COMMAND ioctl() haven't
changed since 2.0 . I needed to make a change to it in the 2.3
tree to maintain backward compatibility with 2.2 and 2.0 . [This
involved truncating the sense buffer returned to 16 bytes even
though it is now longer in 2.3 .] While I was there I added
some documentation which is echoed in the document that is
cited above. From memory, someone asked several months ago on
this group whether any documentation for that ioctl existed.
> [snip]
> Now for another approach:
> My problem is that I have to give the megaraid controller commands,
> and not any devices on the scsi-bus. So I was wondering: isn't it
> wise to have the driver register itself as a scsi device (which it
> actually is)? I then could open the /dev/sgx device to the controller,
> and not to a real device, and use that as a way to reach the
> controller. I think it makes sense, especially if you want to cluster
> machines with the scsi-bus as the major communications channel... :)
Yes, or perhaps it may be easier to have a separate character
device to talk to the megaraid controller firmware.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
