[PATCH] bsg: update sg_io_v4 structure
This updates sg_io_v4 structure (based on Doug's RFC, release 1.3).
One minor change I made is using 'spare_out' and 'padding' instead of
'spare_out' and 'spare_out2' to be consistent with 'spare_in'.
I added dout_iovec_count and din_iovec_count though I'm not sure bsg
needs to implement iovec support (and how if bsgs needs to do). But I
think that it would be better to put them for possible future
changes. Even if bsg doesn't support it, it's not bad to be kind to
other OSes that might use sg_io_v4 structure and support iovec.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
include/linux/bsg.h | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/linux/bsg.h b/include/linux/bsg.h
index 0dd01f9..094c0a0 100644
--- a/include/linux/bsg.h
+++ b/include/linux/bsg.h
@@ -9,17 +9,21 @@ struct sg_io_v4 {
__u32 request_len; /* [i] in bytes */
__u64 request; /* [i], [*i] {SCSI: cdb} */
+ __u64 request_tag; /* [i] {SCSI: task tag (only if flagged)} */
__u32 request_attr; /* [i] {SCSI: task attribute} */
- __u32 request_tag; /* [i] {SCSI: task tag (only if flagged)} */
__u32 request_priority; /* [i] {SCSI: task priority} */
+ __u32 request_extra;/* [i] {spare, for padding} */
__u32 max_response_len; /* [i] in bytes */
__u64 response; /* [i], [*o] {SCSI: (auto)sense data} */
- /* "din_" for data in (from device); "dout_" for data out (to device) */
+/* "dout_": data out (to device); "din_": data in (from device) */
+ __u32 dout_iovec_count; /* [i] 0 -> "flat" dout transfer else
+ dout_xfer points to array of iovec */
__u32 dout_xfer_len;/* [i] bytes to be transferred to device */
+ __u32 din_iovec_count; /* [i] 0 -> "flat" din transfer */
__u32 din_xfer_len; /* [i] bytes to be transferred from device */
- __u64 dout_xferp; /* [i], [*i] */
- __u64 din_xferp;/* [i], [*o] */
+ __u64 dout_xfer;/* [i], [*i] */
+ __u64 din_xfer; /* [i], [*o] */
__u32 timeout; /* [i] units: millisecond */
__u32 flags;/* [i] bit mask */
@@ -34,7 +38,8 @@ struct sg_io_v4 {
__u32 duration; /* [o] time to complete, in milliseconds */
__u32 response_len; /* [o] bytes of response actually written */
__s32 din_resid;/* [o] actual_din_xfer_len - din_xfer_len */
- __u32 generated_tag;/* [o] {SCSI: task tag that transport chose} */
+ __s32 dout_resid; /* [o] actual_dout_xfer_len - dout_xfer_len */
+ __u64 generated_tag;/* [o] {SCSI: transport generated task tag} */
__u32 spare_out;/* [o] */
__u32 padding;
--
1.4.4.3
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] stex: fix id mapping issue(v3)
On Wed, 2007-04-04 at 16:56 -0700, Ed Lin wrote:
> The correct internal mapping of stex controllers should be:
> id:0~15, lun:0~7 (st_shasta)
> id:0, lun:0~127 (st_yosemite)
> id:0~127, lun:0 (st_vsc and st_vsc1)
>
> Unfortunately we can not use the internal id/lun as scsi
> mid layer id/lun. The Linux kernel has a config option
> CONFIG_SCSI_MULTI_LUN. This option is not selected
> in some major Linux releases. If it is not selected,
> then st_shasta can expose 16 LDs(logical drive)
> at most, while st_yosemite can expose only one LD.
> This is clearly unacceptable.
Erm, there's a simple way out of this: That's the BLIST_FORCELUN
option. This is why most of the RAID devices have entries in
scsi_devinfo.c like:
{"ADAPTEC", "AACRAID", NULL, BLIST_FORCELUN},
Which overrides the CONFIG_SCSI_MULTI_LUN setting for the particular
device. We can easily add an entry for stex as well.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] stex: fix id mapping issue(v3)
The correct internal mapping of stex controllers should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)
Unfortunately we can not use the internal id/lun as scsi
mid layer id/lun. The Linux kernel has a config option
CONFIG_SCSI_MULTI_LUN. This option is not selected
in some major Linux releases. If it is not selected,
then st_shasta can expose 16 LDs(logical drive)
at most, while st_yosemite can expose only one LD.
This is clearly unacceptable.
This patch is a workaround for this issue. Since every
LD is 'normal', and should be ignored/skipped in no
circumstances, we report that the max_id for LD is
128, then when commands are sent out by scsi
mid layer, we map id/lun pair based on controller type.
Please consider the situation, and apply the patch.
Thanks.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..d114e4c 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B = 0x40, /* 64 bit item */
SG_CF_HOST = 0x20, /* sg in host memory */
- ST_MAX_ARRAY_SUPPORTED = 16,
- ST_MAX_TARGET_NUM = (ST_MAX_ARRAY_SUPPORTED+1),
- ST_MAX_LUN_PER_TARGET = 16,
-
st_shasta = 0,
st_vsc = 1,
st_vsc1 = 2,
@@ -581,12 +577,11 @@ stex_queuecommand(struct scsi_cmnd *cmd,
{
struct st_hba *hba;
struct Scsi_Host *host;
- unsigned int id,lun;
+ unsigned int id;
struct req_msg *req;
u16 tag;
host = cmd->device->host;
id = cmd->device->id;
- lun = cmd->device->channel; /* firmware lun issue work around */
hba = (struct st_hba *) &host->hostdata[0];
switch (cmd->cmnd[0]) {
@@ -606,9 +601,9 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
case INQUIRY:
- if (id != ST_MAX_ARRAY_SUPPORTED)
+ if (id != host->max_id - 1)
break;
- if (lun == 0 && (cmd->cmnd[1] & INQUIRY_EVPD) == 0) {
+ if ((cmd->cmnd[1] & INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
sizeof(console_inq_page));
cmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
@@ -624,7 +619,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
- ver.console_id = ST_MAX_ARRAY_SUPPORTED;
+ ver.console_id = host->max_id - 1;
ver.host_no = hba->host->host_no;
cmd->result = stex_direct_copy(cmd, &ver, sizeof(ver)) ?
DID_OK << 16 | COMMAND_COMPLETE << 8 :
@@ -645,11 +640,15 @@ stex_queuecommand(struct scsi_cmnd *cmd,
req = stex_alloc_req(hba);
- if (hba->cardtype == st_yosemite) {
- req->lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
+ if (hba->cardtype == st_shasta) {
+ req->lun = id % 8;
+ req->target = id / 8;
+ } else if (hba->cardtype == st_yosemite){
+ req->lun = id;
req->target = 0;
} else {
- req->lun = lun;
+ /* st_vsc and st_vsc1 */
+ req->lun = 0;
req->target = id;
}
@@ -1229,11 +1228,8 @@ stex_probe(struct pci_dev *pdev, const s
hba->copy_buffer = hba->dma_mem + MU_BUFFER_SIZE;
hba->mu_status = MU_STATE_STARTING;
- /* firmware uses id/lun pair for a logical drive, but lun would be
- always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
- channel to map lun here */
- host->max_channel = ST_MAX_LUN_PER_TARGET - 1;
- host->max_id = ST_MAX_TARGET_NUM;
+ host->max_channel = 0;
+ host->max_id = 128 + 1;
host->max_lun = 1;
host->unique_id = host->host_no;
host->max_cmd_len = STEX_CDB_LENGTH;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Wed, 4 Apr 2007, Kern Sibbald wrote: > On Wednesday 04 April 2007 20:46, Kai Makisara wrote: ... > > > > c. There is a real lack of information about any error condition > > > > (read/write). One can probably get it via direct SCSI commands, > but > > > > why not through an ioctl. > > > > This is true. The problem is what and how to tell the user so that the > > solution is satisfactory for a reasonable number of years. The solutions I > > have thought about have not passed this test. One alternative is to pass > > the latest sense data to the user but thinking about the different error > > conditions, this is a problematic choice. Here also suggestions from and > > discussion with real users is needed. > > Well, you have in front of you a "real" user. Yes, you are one of the people I meant with "real users". > I was thinking about a new > ioctl() that would hopefully be simple, generic, and extensible enough that > it might be picked up by all Unixes. This is one case were even if it is a > Linux only solution, I will be really happy. Basically, when I get a -1 > return from a read/write and ERRNO=EIO, I would like to be able to call an > ioctl() and get back some basic info about soft errors, hard errors, ... If > you don't tell me that a new ioctl() is out of the question, I'll make a > proposal -- it will take me some time to put it together. > The general attitude seems to be against new ioctls but I don't want to rule out that. The mt interface already uses ioctls and they solve the serialisation problem nicely in this case. Whatever the method of delivery will be, the most difficult question is the contents and format. I don't know any good examples from other systems, so it has to be Linux-specific (and hopefully adopted by others as you say). I will wait with interest for your suggestion. ... > > > >e. Apparently only root can do the following (IMO, this is a bug or > > > >programming oversight): > > > > > > > > struct mtop mt; > > > > mt.mt_op = MTSETDRVBUFFER; > > > > mt.mt_count = MT_ST_CLEARBOOLEANS; > > > > mt.mt_count |= MT_ST_FAST_MTEOM; > > > > ... > > > > ioctl(fd, MIOCTOP, &mt); > > > > > > > > Typically Bacula runs tape daemon as non-root. Is there a good > reason > > > >why program that has write permission on the device cannot do > this > > > >ioctl() and is it possible to change this? > > > > > > This is not a bug or an oversight, it is a design decision. The idea is > > that the system provides the same view of the tape to all users. This view > > is defined by the system manager (probably with startup scripts). If each > > user can change the behaviour, the next user never knows what to expect. > > Well, I agree that all users should have the same view. However, when Bacula > has the drive open, it has it open exclusively, so no other users can view > the drive. When Bacula opens the drive, it should be able to ensure that the > drive, agrees with Bacula's concept of the drive. When Bacula closes the > drive, I have no problem if the OS resets values to the common view. Today, > if Bacula is running as bacula:disk rather than root:root, it cannot make the > above changes, even if the disk group has write access to the drive. OK. I have not thought about this properly but one possible solution might be something like this: - separate the current and permanent behaviour flags; the current flags define the behaviour - the permanent flags are copied into the current flags when the device is opened (or at some other well-defined point) - the booleans set with MTSETDRVBUFFER change always the current flags; if the user has CAP_SYS_ADMIN, also the permanent flags are changed This would enable anyone to change the behaviour for his/her own purposes but there would still be a stable system-defined behaviour. There already are attributes that have a current and default value like block size. I can see several problems in the details of this suggestion but I will think about those. One is that if someone having CAP_SYS_ADMIN wants just a temporary change, it is not possible. A solution would to have a new op code for temporary changes but this would require explicit changes to programs. Comments are welcome. ... > > Strictly speaking MTSETDRVBUFFER does not need root privileges. It needs > > CAP_SYS_ADMIN. (Now I see that the error message is misleading and must be > > fixed.) Does using some other capability make your use easier but, at same > > time, limit the access to this command to a selected group of users? > > Being relatively ignorant of the kernel, I wasn't aware of CAP_SYS_ADMIN. I > now have a rough idea of what it is, I am unsure if another capability would > resolve the problem, because I'm not familar with how they are set. > Yes, setting the capabilitie
Re: Linux tape drivers
On Wed, 4 Apr 2007 23:31:06 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > On Wednesday 04 April 2007, Andrew Morton wrote: > > On Wed, 4 Apr 2007 12:22:35 -0700 > > "Willem Riede" <[EMAIL PROTECTED]> wrote: > > > > > On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > > > > > alternative, > > > > > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or > > > > fixing > > > > bugs in it or anything. The only reason we retain ide-scsi at all is, > > > > err, > > I haven't heard about any major bugs besides well known module unload problem. > > What have I missed? oop, caught making unsubstantiatable assertions. I've seen an ongoing dribble of doesn't-work and it-crashes reports and I simply have not made any record of them, because it's ide-scsi and I don't expect there's anything we can do about them :( Often these reports are from people who are writing CDROMs and the usual response is "use cdrecord dev=/dev/hdc". I think Alan and Jens might have some thoughts on the ide-scsi status? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Wednesday 04 April 2007, Andrew Morton wrote: > On Wed, 4 Apr 2007 12:22:35 -0700 > "Willem Riede" <[EMAIL PROTECTED]> wrote: > > > On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > > > > alternative, > > > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing > > > bugs in it or anything. The only reason we retain ide-scsi at all is, > > > err, I haven't heard about any major bugs besides well known module unload problem. What have I missed? > > > because some tape drives need it. > > > > > > If we have no alternative to using ide-scsi, and if the tape controllers > > > in > > > question are not some terribly obscure things which nobody would seriously > > > use then we have a bit of a problem. I don't know of anyone who we can > > > turn to to get anything done in ide-scsi. > > > > Andrew, > > > > Kai suggests that libata should be able to take over from ide-scsi. > > Do you concur? > > That would be very nice if we can make it happen. I don't know how close > we are to that, but the fine folks on linux-ide might be able tell us. > > > That may be a better way forward than ide-scsi. > > I know, because I had a hard enough time with it when I needed > > to fix it so it worked for osst, at least. > > > > Regards, Willem Riede. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sg_v4 interface, release 1.3
Attached is the SCSI generic version 4 interface, release
1.3
ChangeLog for release 1.3 [20070404]
- increase tag size to 64 bits to comply with SAM-4 and SRP
- add request_extra and spare_out2 for alignment
Doug Gilbert
SCSI Generic version 4 interface structure
==
Release 1.3
Goals:
- handle both generalized request/response and data_out/data_in
independently in same invocation (i.e. synchronous usage).
- alternatively the request and data_out could be instigated in one
invocation with pointers given for the incoming response and data_in.
Then a second invocation (as a result of polling or asynchronous
notification) reports the response and/or data_in is done, plus
provides error/resid/timing information. This is asynchronous usage.
This allows for the most complicated SCSI commands: tagged, variable
length cdbs with bidirectional data transfers.
- support multiple protocols. If they are generalized request-response
protocols then they can choose either the request/response part of the
interface or the data_out/data_in part.
- layered error/condition reporting: (OS) driver, transport and device
(logical unit). Method used to present this struct to OS (e.g. ioctl())
may also report error (e.g. EPERM).
- allow for auxiliary information to be passed back for the application
client to consider
- same structure can be used for a synchronous (e.g. interruptible ioctl)
or asynchronous (e.g. ioctl()/read() ) pass through.
- leave device (lu) or target addressing issues to some other mechanism
(what SCSI standards call the I_T_L or the I_T nexus respectively) as
they are transport dependent. However do include the tag level (the
"_Q" part of a I_T_L_Q nexus).
- stay close enough to struct sg_io_hdr (sg version 3 interface) to use
with existing SG_IO ioctls, current implementations expect 'S' in
'guard'
Comments:
- unsigned 64 bit integers used as pointer carriers to ease 32/64
bit code interworking (e.g. 32 bit app on 64 bit kernel)
- should there be more (or less) spare fields?
- the write() usage in the sg driver's asynchronous interface has
caused problems when mistakenly applied to a block device node
rather than a sg device node. Using an ioctl(flag_async) followed
by a read() for asynchronous work offers similar functionality and
is safer. Using ioctl(flag_async_start) and ioctl(flag_async_finish)
is another possibility.
- rather than have a separate ATA pass through mechanism, the SAT
defined ATA PASS THROUGH SCSI commands could be used with the
driver implementation routing the ATA commands to their
subsystem. This could be flagged so it didn't preclude a SAT layer
in a SCSI transport (e.g. MPT SAS HBA firmware).
- if SAM/SPC does not define an enumeration for lesser used input
fields, then use the value 0 for inert/off/don't_care .
ChangeLog for release 1.3 [20070404]
- increase tag size to 64 bits to comply with SAM-4 and SRP
- add request_extra and spare_out2 for alignment
ChangeLog for release 1.2 [20070314]
- add dout_resid
- re-arrange uint64_t types (i.e. pointer carriers) to be on a
8 byte boundary
- reinstate dout_iovec_count and din_iovec_count (they were in
release 1.1 but bsg dropped them)
- change name: response_len_wr to response_len
- pick up some descriptions from bsg
ChangeLog for release 1.1 [20061106]
- was called sg version 4 interface, version 1.1
so change the second "version" to "release"
---
#include
struct sg_io_v4
{
int32_t guard; /* [i] 'Q' to differentiate from v3 */
uint32_t protocol; /* [i] 0 -> SCSI , */
uint32_t subprotocol; /* [i] 0 -> SCSI command, 1 -> SCSI task
management function, */
uint32_t request_len; /* [i] in bytes {SCSI: cdb length} */
uint64_t request; /* [i], [*i] {SCSI: cdb} */
uint64_t request_tag; /* [i] {SCSI: task tag (only if flagged)} */
uint32_t request_attr; /* [i] {SCSI: task attribute} */
uint32_t request_priority; /* [i] {SCSI: task priority} */
uint32_t request_extra; /* [i] {spare, for padding} */
uint32_t max_response_len; /* [i] in bytes */
uint64_t response; /* [i], [*o] {SCSI: (auto)sense data} */
/* "dout_": data out (to device); "din_": data in (from device) */
uint32_t dout_iovec_count; /* [i] 0 -> "flat" dout transfer */
/* else dout_xfer points to array of iovec */
uint32_t dout_xfer_len; /* [i] bytes to be
Re: Linux tape drivers
On Wednesday 04 April 2007 20:46, Kai Makisara wrote: ... > > > > > > Issues for discussion: > > > > > > 1. Bugs: > > >a. Other than the OSST driver, apparently no IDE/SATA tape driver works > > >with Bacula. I don't have such a drive (working on it), but from user > > >reports, it appears to me that there are problems of permitting > > >variable length blocks, and more serious, when writing to the end of > > >the tape, either the logical end of tape indicator is ignored, or when > > >it is encountered, all further I/O is prohibited -- including a WEOF. > > >This makes reliable writing of multiple reel tapes impossible. > > > > > >By the way, these IDE/SATA drives work with Bacula using the same > > >source code cross-compiled with GNU C++ on Linux, then run on Windows > > >machines, so it is most likely a driver issue rather than anything in > > >Bacula or the hardware. > > > > > Others have already answered this and I agree with their view. All of the > tape drives seem to use the SSC command set or something close to that. > One high-level driver should be enough to implement the user semantics. > > Libata should be able to drive the SATA/IDE drives using and the drives > are visible as SCSI devices in Linux. In future there should be no real > need for ide-scsi. Probably very few people have tried libata with tapes > and there may be some problems to fix. Someone should test this with > real devices and report the problems back to libata maintainers. Thanks, I'll look into using libdata and ask our users to try it. > > > > 2. Usability of the current tape driver API (not bugs) > > > a. With the new O_NONBLOCK flag introduced in kernel 2.5.x, opening > > > a tape drive and finding out if a volume is mounted is much more > > > complicated. It is really inconvenient and required a lot more code > > > in prior kernels. This should be an item for discussion. > > The reasons for the change were: > 1. To be compatible with the Unix standards, and > 2. To be compatible with other Unix tape driver semantics. > > Because of these reasons the changes should probably not be reversed but > there may be something to improve in the implementation. Suggestions? I was aware of the reasons for the change, and see the limitations in what can be done. I will spend a little time making my thoughts/suggestions clear and get back to you. > > > > b. There is no simple way to determine if a tape is in a drive -- it is > > > at least 20 or 30 lines of C code to do it right. > > Why not use GMT_ONLINE() with MTIOCGET? The definition from the st man > page is: > > GMT_ONLINE(x): The last open() found the drive with a tape in place and > ready for operation. > > If it does not work correctly, it can be fixed. (Of course, if you want to > see if a tape is in a drive but not loaded, it is more difficult.) I will look at it, but have not tried it because it is a Linux specific solution, which I try to avoid. I'll respond more on this when responding correctly to item a above. > > > > c. There is a real lack of information about any error condition > > > (read/write). One can probably get it via direct SCSI commands, but > > > why not through an ioctl. > > This is true. The problem is what and how to tell the user so that the > solution is satisfactory for a reasonable number of years. The solutions I > have thought about have not passed this test. One alternative is to pass > the latest sense data to the user but thinking about the different error > conditions, this is a problematic choice. Here also suggestions from and > discussion with real users is needed. Well, you have in front of you a "real" user. I was thinking about a new ioctl() that would hopefully be simple, generic, and extensible enough that it might be picked up by all Unixes. This is one case were even if it is a Linux only solution, I will be really happy. Basically, when I get a -1 return from a read/write and ERRNO=EIO, I would like to be able to call an ioctl() and get back some basic info about soft errors, hard errors, ... If you don't tell me that a new ioctl() is out of the question, I'll make a proposal -- it will take me some time to put it together. > > > > d. The same as c. above, but for all kinds of error information that > > >can be important -- particularly soft errors. An ioctl() that returns > > >additional information could be very useful. Currently we get it by > > >using external SCSI programs such as mtx tapeinfo for TapeAlerts, > > >and smartclt for errors. > > Looking at what the current drives provide in log and what the kernel can > log, I currently think that this information is best obtained with > external tools, like you do. The number of things that can be asked from > the drives is very large and de
Re: Linux tape drivers
On Wed, 4 Apr 2007 12:22:35 -0700 "Willem Riede" <[EMAIL PROTECTED]> wrote: > On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > > > alternative, > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing > > bugs in it or anything. The only reason we retain ide-scsi at all is, err, > > because some tape drives need it. > > > > If we have no alternative to using ide-scsi, and if the tape controllers in > > question are not some terribly obscure things which nobody would seriously > > use then we have a bit of a problem. I don't know of anyone who we can > > turn to to get anything done in ide-scsi. > > Andrew, > > Kai suggests that libata should be able to take over from ide-scsi. > Do you concur? That would be very nice if we can make it happen. I don't know how close we are to that, but the fine folks on linux-ide might be able tell us. > That may be a better way forward than ide-scsi. > I know, because I had a hard enough time with it when I needed > to fix it so it worked for osst, at least. > > Regards, Willem Riede. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Wed, 4 Apr 2007 21:21:08 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > On Wednesday 04 April 2007 20:55, Andrew Morton wrote: > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > alternative, > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing > > bugs in it or anything. The only reason we retain ide-scsi at all is, err, > > because some tape drives need it. > > > > If we have no alternative to using ide-scsi, and if the tape controllers in > > question are not some terribly obscure things which nobody would seriously > > use then we have a bit of a problem. I don't know of anyone who we can > > turn to to get anything done in ide-scsi. > > > > > > That's quite clear, thanks. I'll update our documentation to say that > ide-scsi doesn't work with Bacula, is not actively supported and may be > removed from the kernel. That seems like a good idea, I'm afraid. > What non-SCSI drivers do you feel are or should be well supported? > libata as Kai indicates? I don't know this stuff well enough to be able to answer that usefully, sorry. > Once I am sure, I'll point Bacula users to those drivers. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
Kai Makisara wrote: > On Tue, 3 Apr 2007, Andrew Morton wrote: > >> (cc's added, with permission) >> >> On Tue, 3 Apr 2007 15:08:37 +0200 >> Kern Sibbald <[EMAIL PROTECTED]> wrote: >> >>> Hello, >>> >>> I am the project manager for Bacula, an Open Source network backup program >>> that runs on all popular OSes. After your presentation at FOSDEM in >>> Febrary, >>> we briefly talked about Linux tape driver problems I am encountering, and >>> you >>> offered to put me in touch with the appropriate kernel developers. >>> >>> I would much appreciate any help in this. Since the problems concern all >>> tape >>> drivers, I provide a very brief outline of what my would like to discuss. >>> First, I must mention that the Linux SCSI driver works perfectly fine with >>> Bacula, it is simply a question of possible improvements, under item 2 >>> below. >>> >>> Issues for discussion: >>> >>> 1. Bugs: >>>a. Other than the OSST driver, apparently no IDE/SATA tape driver works >>>with Bacula. I don't have such a drive (working on it), but from user >>>reports, it appears to me that there are problems of permitting >>>variable length blocks, and more serious, when writing to the end of >>>the tape, either the logical end of tape indicator is ignored, or >>> when >>>it is encountered, all further I/O is prohibited -- including a >>> WEOF. >>>This makes reliable writing of multiple reel tapes impossible. >>> >>>By the way, these IDE/SATA drives work with Bacula using the same >>>source code cross-compiled with GNU C++ on Linux, then run on Windows >>>machines, so it is most likely a driver issue rather than anything in >>>Bacula or the hardware. >>> > > Others have already answered this and I agree with their view. All of the > tape drives seem to use the SSC command set or something close to that. > One high-level driver should be enough to implement the user semantics. > > Libata should be able to drive the SATA/IDE drives using and the drives > are visible as SCSI devices in Linux. In future there should be no real > need for ide-scsi. Probably very few people have tried libata with tapes > and there may be some problems to fix. Someone should test this with > real devices and report the problems back to libata maintainers. > >>> 2. Usability of the current tape driver API (not bugs) >>> a. With the new O_NONBLOCK flag introduced in kernel 2.5.x, opening >>> a tape drive and finding out if a volume is mounted is much more >>> complicated. It is really inconvenient and required a lot more code >>> in prior kernels. This should be an item for discussion. > > The reasons for the change were: > 1. To be compatible with the Unix standards, and > 2. To be compatible with other Unix tape driver semantics. > > Because of these reasons the changes should probably not be reversed but > there may be something to improve in the implementation. Suggestions? Kai, Perhaps an ignore_nonblock sysfs attribute or driver option could be added for the old semantics. As I have found in the past, programs the scan for devices by opening device nodes don't play well with drivers that hang on open. >>> b. There is no simple way to determine if a tape is in a drive -- it is >>> at least 20 or 30 lines of C code to do it right. > > Why not use GMT_ONLINE() with MTIOCGET? The definition from the st man > page is: > > GMT_ONLINE(x): The last open() found the drive with a tape in place and > ready for operation. > > If it does not work correctly, it can be fixed. (Of course, if you want to > see if a tape is in a drive but not loaded, it is more difficult.) Sound like a TEST UNIT READY is all that is needed. They could call out to a utility like sg_turs or sdparm and check the exit status. They could also build with sg3_utils-libs and call sg_ll_test_unit_ready(). [All sg3_utils code is C++ friendly.] Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aacraid: Correct SMC products in aacraid.txt
Correct a spelling mistake for the SMC product names (replace 'B' with 'R') in the Documentation/scsi/aacraid.txt file. This is a follow-up to a documentation patch '[PATCH] aacraid: Add SMC and SUN products to README' submitted and accepted to scsi-misc-2.6 on March 27 2007. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patches. This attached patch is against current scsi-misc-2.6 Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> --- Sincerely -- Mark Salyzyn aacraid_SMC_documentation.patch Description: aacraid_SMC_documentation.patch
Re: Linux tape drivers
On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > I'm all in favor of deprecating ide-tape if ide-scsi is a viable alternative, ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing bugs in it or anything. The only reason we retain ide-scsi at all is, err, because some tape drives need it. If we have no alternative to using ide-scsi, and if the tape controllers in question are not some terribly obscure things which nobody would seriously use then we have a bit of a problem. I don't know of anyone who we can turn to to get anything done in ide-scsi. Andrew, Kai suggests that libata should be able to take over from ide-scsi. Do you concur? That may be a better way forward than ide-scsi. I know, because I had a hard enough time with it when I needed to fix it so it worked for osst, at least. Regards, Willem Riede. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Wednesday 04 April 2007 20:55, Andrew Morton wrote: > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable alternative, > > ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing > bugs in it or anything. The only reason we retain ide-scsi at all is, err, > because some tape drives need it. > > If we have no alternative to using ide-scsi, and if the tape controllers in > question are not some terribly obscure things which nobody would seriously > use then we have a bit of a problem. I don't know of anyone who we can > turn to to get anything done in ide-scsi. > > That's quite clear, thanks. I'll update our documentation to say that ide-scsi doesn't work with Bacula, is not actively supported and may be removed from the kernel. What non-SCSI drivers do you feel are or should be well supported? libata as Kai indicates? Once I am sure, I'll point Bacula users to those drivers. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Tue, 3 Apr 2007, Andrew Morton wrote: > > (cc's added, with permission) > > On Tue, 3 Apr 2007 15:08:37 +0200 > Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > I am the project manager for Bacula, an Open Source network backup program > > that runs on all popular OSes. After your presentation at FOSDEM in > > Febrary, > > we briefly talked about Linux tape driver problems I am encountering, and > > you > > offered to put me in touch with the appropriate kernel developers. > > > > I would much appreciate any help in this. Since the problems concern all > > tape > > drivers, I provide a very brief outline of what my would like to discuss. > > First, I must mention that the Linux SCSI driver works perfectly fine with > > Bacula, it is simply a question of possible improvements, under item 2 > > below. > > > > Issues for discussion: > > > > 1. Bugs: > >a. Other than the OSST driver, apparently no IDE/SATA tape driver works > >with Bacula. I don't have such a drive (working on it), but from user > >reports, it appears to me that there are problems of permitting > >variable length blocks, and more serious, when writing to the end of > >the tape, either the logical end of tape indicator is ignored, or > > when > >it is encountered, all further I/O is prohibited -- including a > > WEOF. > >This makes reliable writing of multiple reel tapes impossible. > > > >By the way, these IDE/SATA drives work with Bacula using the same > >source code cross-compiled with GNU C++ on Linux, then run on Windows > >machines, so it is most likely a driver issue rather than anything in > >Bacula or the hardware. > > Others have already answered this and I agree with their view. All of the tape drives seem to use the SSC command set or something close to that. One high-level driver should be enough to implement the user semantics. Libata should be able to drive the SATA/IDE drives using and the drives are visible as SCSI devices in Linux. In future there should be no real need for ide-scsi. Probably very few people have tried libata with tapes and there may be some problems to fix. Someone should test this with real devices and report the problems back to libata maintainers. > > 2. Usability of the current tape driver API (not bugs) > > a. With the new O_NONBLOCK flag introduced in kernel 2.5.x, opening > > a tape drive and finding out if a volume is mounted is much more > > complicated. It is really inconvenient and required a lot more code > > in prior kernels. This should be an item for discussion. The reasons for the change were: 1. To be compatible with the Unix standards, and 2. To be compatible with other Unix tape driver semantics. Because of these reasons the changes should probably not be reversed but there may be something to improve in the implementation. Suggestions? > > b. There is no simple way to determine if a tape is in a drive -- it is > > at least 20 or 30 lines of C code to do it right. Why not use GMT_ONLINE() with MTIOCGET? The definition from the st man page is: GMT_ONLINE(x): The last open() found the drive with a tape in place and ready for operation. If it does not work correctly, it can be fixed. (Of course, if you want to see if a tape is in a drive but not loaded, it is more difficult.) > > c. There is a real lack of information about any error condition > > (read/write). One can probably get it via direct SCSI commands, but > > why not through an ioctl. This is true. The problem is what and how to tell the user so that the solution is satisfactory for a reasonable number of years. The solutions I have thought about have not passed this test. One alternative is to pass the latest sense data to the user but thinking about the different error conditions, this is a problematic choice. Here also suggestions from and discussion with real users is needed. > > d. The same as c. above, but for all kinds of error information that > >can be important -- particularly soft errors. An ioctl() that > > returns > >additional information could be very useful. Currently we get it by > >using external SCSI programs such as mtx tapeinfo for TapeAlerts, > >and smartclt for errors. Looking at what the current drives provide in log and what the kernel can log, I currently think that this information is best obtained with external tools, like you do. The number of things that can be asked from the drives is very large and defining a kernel interface is difficult. The set also is evolving. (User's suggestions are also here welcome :-) One way to proceed might be to make a user space library that presents an API to users and implements it using SG_IO. If the API seems to stabilize and be suitable for kernel implementation, it could be later implemented in the kernel. > >e. Apparent
Re: Linux tape drivers
On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > alternative, ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing bugs in it or anything. The only reason we retain ide-scsi at all is, err, because some tape drives need it. If we have no alternative to using ide-scsi, and if the tape controllers in question are not some terribly obscure things which nobody would seriously use then we have a bit of a problem. I don't know of anyone who we can turn to to get anything done in ide-scsi. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SG: cap reserved_size values at max_sectors
Alan Stern wrote:
> This patch (as857) modifies the SG_GET_RESERVED_SIZE and
> SG_SET_RESERVED_SIZE ioctls in the sg driver, capping the values at
> the device's request_queue's max_sectors value. This will permit
> cdrecord to obtain a legal value for the maximum transfer length,
> fixing Bugzilla #7026.
>
> The patch also caps the initial reserved_size value. There's no
> reason to have a reserved buffer larger than max_sectors, since it
> would be impossible to use the extra space.
>
> The corresponding ioctls in the block layer are modified similarly,
> and the initial value for the reserved_size is set as large as
> possible. This will effectively make it default to max_sectors.
> Note that the actual value is meaningless anyway, since block devices
> don't have a reserved buffer.
>
> Finally, the BLKSECTGET ioctl is added to sg, so that there will be a
> uniform way for users to determine the actual max_sectors value for
> any raw SCSI transport.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Alan,
I have voiced my concerns about this earlier but I will
now sign off to unblock the process (and deal with the
consequences to sg users, if any).
Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]>
>
> ---
>
> Index: usb-2.6/drivers/scsi/sg.c
> ===
> --- usb-2.6.orig/drivers/scsi/sg.c
> +++ usb-2.6/drivers/scsi/sg.c
> @@ -917,6 +917,8 @@ sg_ioctl(struct inode *inode, struct fil
> return result;
> if (val < 0)
> return -EINVAL;
> + val = min_t(int, val,
> + sdp->device->request_queue->max_sectors * 512);
> if (val != sfp->reserve.bufflen) {
> if (sg_res_in_use(sfp) || sfp->mmap_called)
> return -EBUSY;
> @@ -925,7 +927,8 @@ sg_ioctl(struct inode *inode, struct fil
> }
> return 0;
> case SG_GET_RESERVED_SIZE:
> - val = (int) sfp->reserve.bufflen;
> + val = min_t(int, sfp->reserve.bufflen,
> + sdp->device->request_queue->max_sectors * 512);
> return put_user(val, ip);
> case SG_SET_COMMAND_Q:
> result = get_user(val, ip);
> @@ -1061,6 +1064,9 @@ sg_ioctl(struct inode *inode, struct fil
> if (sdp->detached)
> return -ENODEV;
> return scsi_ioctl(sdp->device, cmd_in, p);
> + case BLKSECTGET:
> + return put_user(sdp->device->request_queue->max_sectors * 512,
> + ip);
> default:
> if (read_only)
> return -EPERM; /* don't know so take safe approach */
> @@ -2339,6 +2345,7 @@ sg_add_sfp(Sg_device * sdp, int dev)
> {
> Sg_fd *sfp;
> unsigned long iflags;
> + int bufflen;
>
> sfp = kzalloc(sizeof(*sfp), GFP_ATOMIC | __GFP_NOWARN);
> if (!sfp)
> @@ -2369,7 +2376,9 @@ sg_add_sfp(Sg_device * sdp, int dev)
> if (unlikely(sg_big_buff != def_reserved_size))
> sg_big_buff = def_reserved_size;
>
> - sg_build_reserve(sfp, sg_big_buff);
> + bufflen = min_t(int, sg_big_buff,
> + sdp->device->request_queue->max_sectors * 512);
> + sg_build_reserve(sfp, bufflen);
> SCSI_LOG_TIMEOUT(3, printk("sg_add_sfp: bufflen=%d, k_use_sg=%d\n",
> sfp->reserve.bufflen, sfp->reserve.k_use_sg));
> return sfp;
> Index: usb-2.6/block/ll_rw_blk.c
> ===
> --- usb-2.6.orig/block/ll_rw_blk.c
> +++ usb-2.6/block/ll_rw_blk.c
> @@ -1925,6 +1925,8 @@ blk_init_queue_node(request_fn_proc *rfn
> blk_queue_max_hw_segments(q, MAX_HW_SEGMENTS);
> blk_queue_max_phys_segments(q, MAX_PHYS_SEGMENTS);
>
> + q->sg_reserved_size = INT_MAX;
> +
> /*
>* all done
>*/
> Index: usb-2.6/block/scsi_ioctl.c
> ===
> --- usb-2.6.orig/block/scsi_ioctl.c
> +++ usb-2.6/block/scsi_ioctl.c
> @@ -78,7 +78,9 @@ static int sg_set_timeout(request_queue_
>
> static int sg_get_reserved_size(request_queue_t *q, int __user *p)
> {
> - return put_user(q->sg_reserved_size, p);
> + unsigned val = min(q->sg_reserved_size, q->max_sectors << 9);
> +
> + return put_user(val, p);
> }
>
> static int sg_set_reserved_size(request_queue_t *q, int __user *p)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 04, 2007 10:36 AM
> To: Ed Lin
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
> On Wed, 2007-04-04 at 10:31 -0700, Ed Lin wrote:
>
> > Sorry. It seems the mail server has problem. The patch is
> here in plain
> > text. I hope this time it does not mess up. I have problem with
> > linux-scsi
> > mail list, if you have comment please cc me. Thanks.
> > --Ed Lin
>
> The lines are still broken, I'm afraid ... you can just resend as an
> attachement git-applypatch copes fine with that ... inline is
> just good
> for quoting and replying.
> > + if (hba->cardtype == st_shasta) {
> > + host->max_channel = 7;
> > + host->max_id = 16 + 1;
> > + } else if (hba->cardtype == st_yosemite) {
> > + host->max_channel = 127;
> > + host->max_id = 1 + 1;
> > + } else {
> > + /* st_vsc and st_vsc1 */
> > + host->max_channel = 0;
> > + host->max_id = 128 + 1;
>
> This is OK. The use of ->channel is still a bit strange ... could we
> not simply use lun instead of channel (i.e. map the adapter id/lun to
> the mid-layer id/lun instead of using id/channel)?
>
This is because there is a CONFIG_SCSI_MULTI_LUN option.
If this option is not selected, max_scsi_luns will be set to 1 and
the RAID arrays with lun>0 will disappear(because they are not
scanned). That is unacceptable from a user's view point. I have
also explained this in the code comment:
/*
* firmware uses id/lun pair for a logical drive, but lun would be
* always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
* channel to map lun here
*/
If it is not allowed to map channel to lun, then maybe I have to
report 128 targets and do the mapping in queuecommand...
After all there must be a mapping somewhere so I don't see
much difference here...
I paste the patch again, is the format ok?
The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
from st_shasta. The original driver code can only map first 16 'entities'
for st_vsc and st_vsc1 while there are actually 128 available.
The correct mapping should be:
channel:0~7, id:0~15 (st_shasta, console is channel:0, id:16, lun:0)
channel:0~127, id:0 (st_yosemite, console is channel:0, id:1, lun:0)
channel:0, id:0~127 (st_vsc and st_vsc1, console is channel:0, id:128, lun:0)
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..29a7b61 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B = 0x40, /* 64 bit item */
SG_CF_HOST = 0x20, /* sg in host memory */
- ST_MAX_ARRAY_SUPPORTED = 16,
- ST_MAX_TARGET_NUM = (ST_MAX_ARRAY_SUPPORTED+1),
- ST_MAX_LUN_PER_TARGET = 16,
-
st_shasta = 0,
st_vsc = 1,
st_vsc1 = 2,
@@ -606,7 +602,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
case INQUIRY:
- if (id != ST_MAX_ARRAY_SUPPORTED)
+ if (id != host->max_id - 1)
break;
if (lun == 0 && (cmd->cmnd[1] & INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
@@ -624,7 +620,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
- ver.console_id = ST_MAX_ARRAY_SUPPORTED;
+ ver.console_id = host->max_id - 1;
ver.host_no = hba->host->host_no;
cmd->result = stex_direct_copy(cmd, &ver, sizeof(ver)) ?
DID_OK << 16 | COMMAND_COMPLETE << 8 :
@@ -645,13 +641,8 @@ stex_queuecommand(struct scsi_cmnd *cmd,
req = stex_alloc_req(hba);
- if (hba->cardtype == st_yosemite) {
- req->lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
- req->target = 0;
- } else {
- req->lun = lun;
- req->target = id;
- }
+ req->lun = lun;
+ req->target = id;
/* cdb */
memcpy(req->cdb, cmd->cmnd, STEX_CDB_LENGTH);
@@ -1229,11 +1220,22 @@ stex_probe(struct pci_dev *pdev, const s
hba->copy_buffer = hba->dma_mem + MU_BUFFER_SIZE;
hba->mu_status = MU_STATE_STARTING;
- /* firmware uses id/lun pair for a logical drive, but lun would be
- always 0 if CONFIG_SCSI_MULTI_LUN not configured, so we use
- channel to map lun here */
- host->max_cha
Re: [patch 1/1] scsi: Disable short inquiry log by default
James Bottomley wrote: > On Mon, 2007-04-02 at 16:20 -0500, [EMAIL PROTECTED] wrote: >> If a scsi device reports less than 36 bytes of standard inquiry >> data, scsi core logs a KERN_INFO printk indicating this. It was >> observed that this results in lots of clutter in the log on >> systems with devices that respond to a SCSI Inquiry with PQ=3 or >> PQ=1 with less than 36 bytes of inquiry data, such as ibmvscsi. >> Disable this log by default. > > It shouldn't be doing this ... the standards are pretty clear, say SPC-3 > section 6.4.2 > > "The standard INQUIRY data shall contain at least 36 bytes" > > Horrible things happen when this rule is violated (as it is by some > badly constructed devices), so I'd really like to leave the print in so > we know what we're debugging. > > Can't you fix ibmvscsi to be standards compliant? James, You can drop this patch. I've verified that the current ibmvscsi server does not do this. I wasn't using the latest ibmvscsi server implementation. Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
On Wed, 2007-04-04 at 10:31 -0700, Ed Lin wrote:
> Sorry. It seems the mail server has problem. The patch is here in plain
> text. I hope this time it does not mess up. I have problem with
> linux-scsi
> mail list, if you have comment please cc me. Thanks.
> --Ed Lin
The lines are still broken, I'm afraid ... you can just resend as an
attachement git-applypatch copes fine with that ... inline is just good
for quoting and replying.
> + if (hba->cardtype == st_shasta) {
> + host->max_channel = 7;
> + host->max_id = 16 + 1;
> + } else if (hba->cardtype == st_yosemite) {
> + host->max_channel = 127;
> + host->max_id = 1 + 1;
> + } else {
> + /* st_vsc and st_vsc1 */
> + host->max_channel = 0;
> + host->max_id = 128 + 1;
This is OK. The use of ->channel is still a bit strange ... could we
not simply use lun instead of channel (i.e. map the adapter id/lun to
the mid-layer id/lun instead of using id/channel)?
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for console device
> -Original Message-
> From: Ed Lin
> Sent: Monday, April 02, 2007 4:02 PM
> To: James Bottomley
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for
> console device
>
>
>
>
> > -Original Message-
> > From: James Bottomley [mailto:[EMAIL PROTECTED]
> > Sent: Monday, April 02, 2007 11:28 AM
> > To: Ed Lin
> > Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> > Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for
> > console device
> >
> >
> > On Mon, 2007-04-02 at 11:14 -0700, Ed Lin wrote:
> > > I just saw the routine name scsi_eh_try_stu, and didn't notice the
> > > allow_restart (partly because I thought it was not harmful...).
> > > But the TEST_UNIT_READY must stay.
> >
> > Sure ... I was just checking since your change log implied
> you'd seen
> > the problem from the error handler ... however, we can add it ...
> > there's a possibility of getting spin up on init from sd anyway.
> >
>
> You make the decision. But after reconsideration, I think it's better
> to remove unused code. It also needs change since the patch about
> id mapping is modified in another mail.
>
> How about the attachment here?
>
Sorry. I think the mail server has problem with attachment. The patch
is here in plain text. Sorry for the inconvenience. I have problem with
linux-scsi mail list, if you have comment please cc me. Thanks.
--Ed Lin
After reset completed, the scsi error handler sends out TEST_UNIT_READY
to
the device. For 'normal' devices this command will be handled by
firmware.
However, because the RAID console only interfaces to scsi mid layer, the
firmware will not process this command for it. This will make the
console
to be offlined right after reset. Add the handling in driver to fix this
problem.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 4c6ce6a..85c779b 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -601,6 +601,13 @@ stex_queuecommand(struct scsi_cmnd *cmd,
stex_invalid_field(cmd, done);
return 0;
}
+ case TEST_UNIT_READY:
+ if (id == host->max_id - 1) {
+ cmd->result = DID_OK << 16 | COMMAND_COMPLETE <<
8;
+ done(cmd);
+ return 0;
+ }
+ break;
case INQUIRY:
if (id != host->max_id - 1)
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
> -Original Message-
> From: Ed Lin
> Sent: Monday, April 02, 2007 4:01 PM
> To: 'James Bottomley'
> Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> Subject: RE: [PATCH 1/4] [SCSI]stex: fix id mapping issue
>
>
>
>
> > -Original Message-
> > From: James Bottomley [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, March 31, 2007 7:22 AM
> > To: Ed Lin
> > Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
> > Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
> >
> >
> > On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote:
> > > The internal id/lun mapping of st_vsc and st_vsc1
> > controllers is different
> > > from st_shasta. The original driver code can only map
> > first 16 'entities'
> > > for st_vsc and st_vsc1 while there are actually 128 available.
> > >
> > > Also the ST_MAX_LUN_PER_TARGET should be 8, although this can do
> > > no harm because inquiries beyond boundary are discarded
> by firmware.
> > >
> > > The correct internal mapping should be:
> > > id:0~15, lun:0~7 (st_shasta)
> > > id:0, lun:0~127 (st_yosemite)
> > > id:0~127, lun:0 (st_vsc and st_vsc1)
> > > To scsi mid layer they are all channel:0~7, id:0~15, lun:0,
> > with a maximun
> > > 'entity' number of 128. The RAID console only interfaces to
> > scsi mid layer
> > > and is always mapped at channel:0, id:16, lun:0.
> >
> > I'm with Christoph here ... if we're going to break the backwards
> > compatibility of the mappings (which your code does) then we
> > could just
> > dump channel and use the SCSI id and lun directly.
> >
> > Understanding this code is predicated on this quirky definition in
> > stex_queuecommand:
> >
> > id = cmd->device->id;
> > lun = cmd->device->channel; /* firmware lun issue work around */
> >^^^
> >
> > > @ -645,12 +645,16 @@ stex_queuecommand(struct scsi_cmnd *cmd,
> > >
> > > req = stex_alloc_req(hba);
> > >
> > > - if (hba->cardtype == st_yosemite) {
> > > - req->lun = lun * (ST_MAX_TARGET_NUM - 1) + id;
> >
> > This looks to be correct, it goes up id 0 to
> ST_MAX_TARGET_NUM -1 then
> > takes the next channel.
> >
> > > - req->target = 0;
> > > - } else {
> > > + if (hba->cardtype == st_shasta) {
> > > req->lun = lun;
> > > req->target = id;
> > > + } else if (hba->cardtype == st_yosemite){
> > > + req->lun = id * ST_MAX_LUN_PER_TARGET + lun;
> > > + req->target = 0;
> > > + } else {
> > > + /* st_vsc and st_vsc1 */
> > > + req->lun = 0;
> > > + req->target = id * ST_MAX_LUN_PER_TARGET + lun;
> >
> > These both look to be wrong. You're taking the channel as
> the lowest
> > common denominator, so your first target is on channel 1 id
> > 0, your next
> > on channel 2, id 0 and so on. That's really going to mess with the
> > ordering (which will be user visible) is that really what you want?
> >
>
> How about the attached one?
>
Sorry. It seems the mail server has problem. The patch is here in plain
text. I hope this time it does not mess up. I have problem with
linux-scsi
mail list, if you have comment please cc me. Thanks.
--Ed Lin
The internal id/lun mapping of st_vsc and st_vsc1 controllers is
different
from st_shasta. The original driver code can only map first 16
'entities'
for st_vsc and st_vsc1 while there are actually 128 available.
The correct mapping should be:
channel:0~7, id:0~15 (st_shasta, console is channel:0, id:16, lun:0)
channel:0~127, id:0 (st_yosemite, console is channel:0, id:1, lun:0)
channel:0, id:0~127 (st_vsc and st_vsc1, console is channel:0, id:128,
lun:0)
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 69be132..29a7b61 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -113,10 +113,6 @@ enum {
SG_CF_64B = 0x40, /* 64 bit item
*/
SG_CF_HOST = 0x20, /* sg in host
memory */
- ST_MAX_ARRAY_SUPPORTED = 16,
- ST_MAX_TARGET_NUM =
(ST_MAX_ARRAY_SUPPORTED+1),
- ST_MAX_LUN_PER_TARGET = 16,
-
st_shasta = 0,
st_vsc = 1,
st_vsc1 = 2,
@@ -606,7 +602,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
return 0;
}
case INQUIRY:
- if (id != ST_MAX_ARRAY_SUPPORTED)
+ if (id != host->max_id - 1)
break;
if (lun == 0 && (cmd->cmnd[1] & INQUIRY_EVPD) == 0) {
stex_direct_copy(cmd, console_inq_page,
@@ -624,7 +620,7 @@ stex_queuecommand(struct scsi_cmnd *cmd,
ver.oem = ST_OEM;
ver.build = ST_BUILD_VER;
ver.signature[0] = PASSTHRU_SIGNATURE;
- ver.console_id = ST_MAX_ARRAY_SUPPOR
[PATCH 1/1] cciss: add init of drv->cylinders back to cciss_geometry_inquiry
PATCH 1/1
This patch adds initialization of drv->cylinders back into the failing case in
cciss_geometry_inquiry. I inadvertently removed it in one my 2TB updates.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
--
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 072e18e..14d7806 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1915,6 +1915,7 @@ static void cciss_geometry_inquiry(int c
"does not support reading geometry\n");
drv->heads = 255;
drv->sectors = 32; // Sectors per track
+ drv->cylinders = total_size + 1;
drv->raid_level = RAID_UNKNOWN;
} else {
drv->heads = inq_buff->data_byte[6];
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux tape drivers
On Wednesday 04 April 2007 05:00, Willem Riede wrote: > > Kern Sibbald <[EMAIL PROTECTED]> wrote: ... Hello Willem, > > Osst supports both scsi and ide models of the Onstream dirves it is > designed for. > It uses ide-scsi for the ide model. In the past, I did look at > ide-tape to see if it could be made to work properly for the ide > Onstream tape, but that would have taken so much work, I decided to > limit myself to ide-scsi. > > For other ide tape drives, the same could be done, using Kai's st > driver (of which osst is a clone). Ide-tape could be deprecated, left > to use for drives/applications it happens to work for. Given that the > new sata world is using st also, this concentrates effort where it has > maximum leverage. I'm all in favor of deprecating ide-tape if ide-scsi is a viable alternative, and if that is the only one you kernel guys would like to support. Let's concentrate on the drivers that will be the most important over the next few years (SATA?) > > If there are issues using Bacula on ide drives with ide-scsi and st, > we should debug those. If my previous experience getting osst to work > properly with Bacula can be of any use, I'll be happy to help where I > can. Your previous experience could be particularly helpful. Thanks for the offer. I'm in the process of taking a mini-Bacula survey of the problems. Here are the results for the moment: === Sebastiaan: He returned his Quantum DLT-V4 SATA drive, which did not work with Bacula, in exchange for a SCSI drive. Bob: He has a SDX-260V ATAPI AIT-E and reports the following: 1. Sony SDX-260V 2. ATAPI 3. Tried both ide-scsi and ide-tape 4. ide-scsi simply locked up my machine after ANY attempt to write data to the tape. I tried various combinations of block sizes and such. ide-tape would wirte to the tape and could read it but failed the positioning tests under btape. Specifically it would read any block from the first file on the tape. When a block from the second file was requested, the machine would lock up. 5. Gentoo Linux 2.6.20 - gcc 4.1.2 - glibc 2.5 - paludis 0.22.2 - bacula 2.0.3 Robert: Reports: A year ago I used the IDE drive on Linux. If I remember correctly the problem only occurred when using DMA, PIO worked but was very, very slow. The symptoms changed depending on whether I used the SCSI driver stack or the ide-tape driver; but neither worked properly. === Please tell me the best way to proceed. I don't have the hardware, but understand Bacula, the users have the hardware, but don't understand Bacula's needs (Robert knows Bacula in detail) -- not the best of situations. I will buy the hardware if required, but I'd like to limit ($$$) to what is going to be mostly used in the future. On the other general issues of the tape API (read/write/open/ioctl), I briefly sketched my problems/concerns. If anyone is interested in any of those points, I can be a lot more specific. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SATA (AHCI) (or disk) probs on Intel Server Board S5000PAL
On a regular basis now (but not very frequently - it happened two times in a single month so far), a system based on the abovementioned board fails to work with a hard drive, on an idle system. Like this (too bad it's not an 1st April joke): Apr 1 01:36:09 ata2.00: exception Emask 0x10 SAct 0x2 SErr 0x280100 action 0x2 frozen Apr 1 01:36:09 ata2.00: (irq_stat 0x0800, interface fatal error) Apr 1 01:36:09 ata2.00: cmd 60/80:08:dd:57:f8/00:00:0f:00:00/40 tag 1 cdb 0x0 data 65536 in Apr 1 01:36:09 res 40/00:08:dd:57:f8/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:09 ata2: soft resetting port Apr 1 01:36:10 ata2: softreset failed (1st FIS failed) Apr 1 01:36:10 ata2: softreset failed, retrying in 5 secs Apr 1 01:36:15 ata2: hard resetting port Apr 1 01:36:22 ata2: port is slow to respond, please be patient (Status 0x80) Apr 1 01:36:45 ata2: port failed to respond (30 secs, Status 0x80) Apr 1 01:36:45 ata2: COMRESET failed (device not ready) Apr 1 01:36:45 ata2: hardreset failed, retrying in 5 secs Apr 1 01:36:50 ata2: hard resetting port Apr 1 01:36:50 ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 1 01:36:50 ata2.00: configured for UDMA/133 Apr 1 01:36:50 ata2: EH complete Apr 1 01:36:50 SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) Apr 1 01:36:50 sdb: Write Protect is off Apr 1 01:36:50 sdb: Mode Sense: 00 3a 00 00 Apr 1 01:36:50 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Apr 1 01:36:53 ata2.00: exception Emask 0x10 SAct 0xef SErr 0x280100 action 0x2 frozen Apr 1 01:36:53 ata2.00: (irq_stat 0x0800, interface fatal error) Apr 1 01:36:53 ata2.00: cmd 60/80:00:5d:d5:fc/00:00:0f:00:00/40 tag 0 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:08:dd:ce:fc/00:00:0f:00:00/40 tag 1 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:10:dd:d0:fc/00:00:0f:00:00/40 tag 2 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:18:dd:d2:fc/00:00:0f:00:00/40 tag 3 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 61/10:20:ba:65:7a/00:00:00:00:00/40 tag 4 cdb 0x0 data 8192 out Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 61/10:28:92:93:bb/00:00:00:00:00/40 tag 5 cdb 0x0 data 8192 out Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 61/08:30:4a:95:bb/00:00:00:00:00/40 tag 6 cdb 0x0 data 4096 out Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 61/08:38:52:96:bb/00:00:00:00:00/40 tag 7 cdb 0x0 data 4096 out Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 61/08:40:62:96:bb/00:00:00:00:00/40 tag 8 cdb 0x0 data 4096 out Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:48:5d:d4:fc/00:00:0f:00:00/40 tag 9 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:50:5d:cf:fc/00:00:0f:00:00/40 tag 10 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:58:5d:d3:fc/00:00:0f:00:00/40 tag 11 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:60:5d:d0:fc/00:00:0f:00:00/40 tag 12 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:68:dd:d1:fc/00:00:0f:00:00/40 tag 13 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:70:dd:cd:fc/00:00:0f:00:00/40 tag 14 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:78:5d:d2:fc/00:00:0f:00:00/40 tag 15 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:80:dd:cc:fc/00:00:0f:00:00/40 tag 16 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:dd:d4:fc/00:00:0f:00:00/40 Emask 0x10 (ATA bus error) Apr 1 01:36:53 ata2.00: cmd 60/80:88:5d:cd:fc/00:00:0f:00:00/40 tag 17 cdb 0x0 data 65536 in Apr 1 01:36:53 res 40/00:98:d
RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)
By bad... 'interrpt' typo -Original Message- From: Duane Cox Sent: Monday, April 02, 2007 3:04 PM To: 'Salyzyn, Mark'; Judith Lebzelter Cc: James Bottomley; linux-scsi@vger.kernel.org Subject: RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test) Attempted to compile 2.6.20.3 kernel results in... CC drivers/scsi/aacraid/rx.o drivers/scsi/aacraid/rx.c: In function '_aac_rx_init': drivers/scsi/aacraid/rx.c:869: error: 'aac_rx_disable_interrpt' undeclared (first use in this function) drivers/scsi/aacraid/rx.c:869: error: (Each undeclared identifier is reported only once drivers/scsi/aacraid/rx.c:869: error: for each function it appears in.) make[3]: *** [drivers/scsi/aacraid/rx.o] Error 1 make[2]: *** [drivers/scsi/aacraid] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 -Original Message- From: Salyzyn, Mark [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 2:57 PM To: Judith Lebzelter Cc: James Bottomley; linux-scsi@vger.kernel.org; Duane Cox Subject: RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test) Judith, another layer on this onion also discovered by Duane, the interrupt enable handler also needed to be set ... The interrupt enable was called from within the synchronous command handler. My private email with the fix was sent a whole 5 minutes ahead of yours ;-> Here is the jist of it for the observers: /* Failure to reset here is an option ... */ dev->a_ops.adapter_sync_cmd = rx_sync_cmd; + dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt; dev->OIMR = status = rx_readb (dev, MUnit.OIMR); Yes, the disable interrupt method patched into the enable int platform function. Later init code will reset it accordingly. Sincerely -- Mark Salyzyn > -Original Message- > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 3:44 PM > To: Salyzyn, Mark > Cc: Judith Lebzelter; James Bottomley; linux-scsi@vger.kernel.org; > Duane Cox > Subject: Re: [PATCH] aacraid: Panics during init time reset > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during > 'insmod' for kexec test) > > > On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote: > > Duane discovered in the scsi-misc-2.6 code that the reset > handler could > > be called without the sync command handler set up resulting > in a panic. > > Judith discovered this issue within minutes and has > recently reported > > it. Here is a fix. > > Mark, > > I applied this patch and ran a kexec test again and I still got a > panic: > > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M ko module^M > ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, > low) -> IRQ 3^M Unable to handle kernel NULL pointer dereference at > RIP: ^M [<>]^M PGD 4791067 PUD > 473c067 PMD 0 ^M > Oops: 0010 [1] ^M > CPU 0 ^M > Modules linked in: aacraid^M > Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M > RIP: 0010:[<>] [<>]^M > RSP: :81000474dbf0 EFLAGS: 00010246^M > RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M > RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M > RBP: fffee138 R08: 81001c20 R09: 8143593e^M > R10: 810004c537a0 R11: R12: 81000474dc7c^M > R13: R14: R15: ^M > FS: 0057b850(0063) GS:814d6000() > knlGS:^M > CS: 0010 DS: ES: CR0: 8005003b^M > CR2: CR3: 04745000 CR4: 06e0^M > Process insmod (pid: 977, threadinfo 81000474c000, task > 81000443cf40)^M > Stack: 88008e82 3e00fc1f > 810004fe4cd8^M 810004fe4800 8800a6dd > 0032^M 88008c3b > 81000474dc7c^M Call Trace:^M [] > :aacraid:rx_sync_cmd+0x15c/0x16a^M > [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M > [] :aacraid:_aac_rx_init+0x7b/0x2fc^M > [] :aacraid:aac_probe_one+0x1a2/0x457^M > [] pci_device_probe+0x4c/0x75^M > [] really_probe+0xc4/0x148^M [] > __driver_attach+0x6d/0xab^M [] > __driver_attach+0x0/0xab^M [] > __driver_attach+0x0/0xab^M [] > bus_for_each_dev+0x43/0x6e^M [] > bus_add_driver+0x6b/0x18d^M [] > __pci_register_driver+0x72/0xa7^M [] > :aacraid:aac_init+0x3a/0x75^M [] > sys_init_module+0x1195/0x12e6^M [] > system_call+0x7e/0x83^M ^M ^M > Code: Bad RIP value.^M > RIP [<>]^M > RSP ^M > CR2: ^M > > There is an extra line in the call trace for the 'rx_sync_cmd'. > > Judith > > > > > IMHO, this needs to be applied immediately regardless of > the status of > > the kexec patc
RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test)
Attempted to compile 2.6.20.3 kernel results in... CC drivers/scsi/aacraid/rx.o drivers/scsi/aacraid/rx.c: In function '_aac_rx_init': drivers/scsi/aacraid/rx.c:869: error: 'aac_rx_disable_interrpt' undeclared (first use in this function) drivers/scsi/aacraid/rx.c:869: error: (Each undeclared identifier is reported only once drivers/scsi/aacraid/rx.c:869: error: for each function it appears in.) make[3]: *** [drivers/scsi/aacraid/rx.o] Error 1 make[2]: *** [drivers/scsi/aacraid] Error 2 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 -Original Message- From: Salyzyn, Mark [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 2:57 PM To: Judith Lebzelter Cc: James Bottomley; linux-scsi@vger.kernel.org; Duane Cox Subject: RE: [PATCH] aacraid: Panics during init time reset (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during 'insmod' for kexec test) Judith, another layer on this onion also discovered by Duane, the interrupt enable handler also needed to be set ... The interrupt enable was called from within the synchronous command handler. My private email with the fix was sent a whole 5 minutes ahead of yours ;-> Here is the jist of it for the observers: /* Failure to reset here is an option ... */ dev->a_ops.adapter_sync_cmd = rx_sync_cmd; + dev->a_ops.adapter_enable_int = aac_rx_disable_interrupt; dev->OIMR = status = rx_readb (dev, MUnit.OIMR); Yes, the disable interrupt method patched into the enable int platform function. Later init code will reset it accordingly. Sincerely -- Mark Salyzyn > -Original Message- > From: Judith Lebzelter [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 3:44 PM > To: Salyzyn, Mark > Cc: Judith Lebzelter; James Bottomley; linux-scsi@vger.kernel.org; > Duane Cox > Subject: Re: [PATCH] aacraid: Panics during init time reset > (Was: [PATCH] aacraid: [Fastboot] Panics for AACRAID driver during > 'insmod' for kexec test) > > > On Mon, Apr 02, 2007 at 02:34:36PM -0400, Salyzyn, Mark wrote: > > Duane discovered in the scsi-misc-2.6 code that the reset > handler could > > be called without the sync command handler set up resulting > in a panic. > > Judith discovered this issue within minutes and has > recently reported > > it. Here is a fix. > > Mark, > > I applied this patch and ran a kexec test again and I still got a > panic: > > Loading aacraid.Adaptec aacraid driver (1.1-5[2437]-mh4)^M ko module^M > ACPI: PCI Interrupt :03:0e.0[A] -> Link [LNKC] -> GSI 3 (level, > low) -> IRQ 3^M Unable to handle kernel NULL pointer dereference at > RIP: ^M [<>]^M PGD 4791067 PUD > 473c067 PMD 0 ^M > Oops: 0010 [1] ^M > CPU 0 ^M > Modules linked in: aacraid^M > Pid: 977, comm: insmod Not tainted 2.6.21-rc3-kdump #1^M > RIP: 0010:[<>] [<>]^M > RSP: :81000474dbf0 EFLAGS: 00010246^M > RAX: c201 RBX: 810004fe4cd8 RCX: 5b540e96^M > RDX: c201 RSI: 81000443cf40 RDI: 810004fe4cd8^M > RBP: fffee138 R08: 81001c20 R09: 8143593e^M > R10: 810004c537a0 R11: R12: 81000474dc7c^M > R13: R14: R15: ^M > FS: 0057b850(0063) GS:814d6000() > knlGS:^M > CS: 0010 DS: ES: CR0: 8005003b^M > CR2: CR3: 04745000 CR4: 06e0^M > Process insmod (pid: 977, threadinfo 81000474c000, task > 81000443cf40)^M > Stack: 88008e82 3e00fc1f > 810004fe4cd8^M 810004fe4800 8800a6dd > 0032^M 88008c3b > 81000474dc7c^M Call Trace:^M [] > :aacraid:rx_sync_cmd+0x15c/0x16a^M > [] :aacraid:aac_rx_restart_adapter+0x7e/0x169^M > [] :aacraid:_aac_rx_init+0x7b/0x2fc^M > [] :aacraid:aac_probe_one+0x1a2/0x457^M > [] pci_device_probe+0x4c/0x75^M > [] really_probe+0xc4/0x148^M [] > __driver_attach+0x6d/0xab^M [] > __driver_attach+0x0/0xab^M [] > __driver_attach+0x0/0xab^M [] > bus_for_each_dev+0x43/0x6e^M [] > bus_add_driver+0x6b/0x18d^M [] > __pci_register_driver+0x72/0xa7^M [] > :aacraid:aac_init+0x3a/0x75^M [] > sys_init_module+0x1195/0x12e6^M [] > system_call+0x7e/0x83^M ^M ^M > Code: Bad RIP value.^M > RIP [<>]^M > RSP ^M > CR2: ^M > > There is an extra line in the call trace for the 'rx_sync_cmd'. > > Judith > > > > > IMHO, this needs to be applied immediately regardless of > the status of > > the kexec patch as this issue is present in the > scsi-misc-2.6 driver for > > all existing init-time recovery actions. This patch in > principal would > > not be different w/o the kexec patch. > > > > ObligatoryDisclaimer: Please accept my condolences > regarding Outlook's > > handling of patches. > > > > This attached patch is against current scsi-mi
