Re: [PATCH ver2 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, Sep 10, 2007 at 10:35:25PM +0300, Boaz Harrosh wrote: > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 20a72aa..a02400c 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -590,42 +590,23 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd) > } > > /** > - * scsi_send_eh_cmnd - submit a scsi command as part of error recory > + * scsi_eh_prep_cmnd - Save a scsi command info as part of error recory > * @scmd: SCSI command structure to hijack > - * @cmnd: CDB to send > + * @ses:structure to save restore information > + * @cmnd: CDB to send. Can be NULL if no new cmnd is needed > * @cmnd_size: size in bytes of @cmnd > - * @timeout:timeout for this request > - * @copy_sense: request sense data if set to 1 > + * @copy_sense: size of sense data to copy. or 0 > * > - * This function is used to send a scsi command down to a target device > - * as part of the error recovery process. If @copy_sense is 0 the command > - * sent must be one that does not transfer any data. If @copy_sense is 1 > - * the command must be REQUEST_SENSE and this functions copies out the > - * sense buffer it got into @scmd->sense_buffer. > - * > - * Return value: > - *SUCCESS or FAILED or NEEDS_RETRY > + * This function is used to save a scsi command information before > re-execution > + * as part of an error recovery process. If @copy_sense is 0 the command > + * given must be one that does not transfer any data. If @copy_sense != 0 > + * the command should be NULL and this functions sets up the cmnd and > + * command buffers to be read into @scmd->sense_buffer. > **/ > -static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, > - int cmnd_size, int timeout, unsigned copy_sense) > +void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses, > + unsigned char *cmnd, int cmnd_size, unsigned copy_sense) I'm not terribly keen on the naming of copy_sense, tho I see what you're trying to do. A better name and better comments about what it means when != 0 would fix this. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver My mother not mind to die for stoppink Windows NT! She is rememberink Stalin! -- Pitr User Friendly, 9/6/1998 pgpe8ZGDfkPEc.pgp Description: PGP signature
Re: 2.6.23-rc4-mm1
On 9/10/07, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 12:20:38 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Mon, 10 Sep 2007 20:59:49 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]> > > wrote: > > > The system boots, reads the partition tables, starts the RAID and then > > > kicks one drive out because of errors. > > > > Andy is using qla1280. You're using sata. So it's probably a different > > bug, with the same symptoms. > > This might be a sg chaining bug too (probabaly sg chaining libata > patch). > > Can you try the following patch that I've just sent: > > http://lkml.org/lkml/2007/9/10/251 > > The patch also disables chaining sg list for libata. > With this patch 2.6.23-rc4-mm1 works for me. Mainline 2.6.23-rc5-git1 works also without needing any patches. Torsten - 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: [0/22] Advansys updates 2007-09-09
On Sun, 9 Sep 2007 08:53:58 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> Here's another mammoth patch series for the advansys driver against
> scsi-misc. I've tested that it compiles at each stage and that the
> final result works.
>
> Some important parts to note:
>
> 1/22 Essential bugfix. Please apply ASAP.
> 4/22 Reformat microcode. Boring and large.
> 6,7,8,9/22 Remove internal queueing from driver
> 11/22 Allow advansys to accept 16-byte commands for wide boards
> 13/22 Remove some custom wrappers
> 15/22 Add DRV_NAME
> 16/22 Eliminate prototypes. Boring and large.
> 19/22 Fix simultaneous calls to ->queuecommand
This is on the top of the patchset. Can I get your ACK on it?
This depends on scsi-misc, the patchset, and sg chaining stuff.
--
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] advansys: convert to use the data buffer accessors
- remove the unnecessary map_single path.
- convert to use the new accessors for the sg lists and the
parameters.
- add sg chaining support
Jens Axboe <[EMAIL PROTECTED]> added sg chaining support.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c | 93 +++
1 files changed, 29 insertions(+), 64 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index abad6d1..62b58a7 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -4499,15 +4499,7 @@ advansys_proc_info(struct Scsi_Host *shost, char
*buffer, char **start,
static void asc_scsi_done(struct scsi_cmnd *scp)
{
- struct asc_board *boardp = ASC_BOARDP(scp->device->host);
-
- if (scp->use_sg)
- dma_unmap_sg(boardp->dev,
-(struct scatterlist *)scp->request_buffer,
-scp->use_sg, scp->sc_data_direction);
- else if (scp->request_bufflen)
- dma_unmap_single(boardp->dev, scp->SCp.dma_handle,
-scp->request_bufflen, scp->sc_data_direction);
+ scsi_dma_unmap(scp);
ASC_STATS(scp->device->host, done);
@@ -8460,12 +8452,12 @@ static void adv_isr_callback(ADV_DVC_VAR *adv_dvc_varp,
ADV_SCSI_REQ_Q *scsiqp)
* then return the number of underrun bytes.
*/
resid_cnt = le32_to_cpu(scsiqp->data_cnt);
- if (scp->request_bufflen != 0 && resid_cnt != 0 &&
- resid_cnt <= scp->request_bufflen) {
+ if (scsi_bufflen(scp) != 0 && resid_cnt != 0 &&
+ resid_cnt <= scsi_bufflen(scp)) {
ASC_DBG1(1,
"adv_isr_callback: underrun condition %lu
bytes\n",
(ulong)resid_cnt);
- scp->resid = resid_cnt;
+ scsi_set_resid(scp, resid_cnt);
}
break;
@@ -9410,12 +9402,12 @@ static void asc_isr_callback(ASC_DVC_VAR *asc_dvc_varp,
ASC_QDONE_INFO *qdonep)
* If there was no error and an underrun condition, then
* return the number of underrun bytes.
*/
- if (scp->request_bufflen != 0 && qdonep->remain_bytes != 0 &&
- qdonep->remain_bytes <= scp->request_bufflen) {
+ if (scsi_bufflen(scp) != 0 && qdonep->remain_bytes != 0 &&
+ qdonep->remain_bytes <= scsi_bufflen(scp)) {
ASC_DBG1(1,
"asc_isr_callback: underrun condition %u
bytes\n",
(unsigned)qdonep->remain_bytes);
- scp->resid = qdonep->remain_bytes;
+ scsi_set_resid(scp, qdonep->remain_bytes);
}
break;
@@ -10147,6 +10139,8 @@ static int advansys_slave_configure(struct scsi_device
*sdev)
static int asc_build_req(asc_board_t *boardp, struct scsi_cmnd *scp,
struct asc_scsi_q *asc_scsi_q)
{
+ int use_sg;
+
memset(asc_scsi_q, 0, sizeof(*asc_scsi_q));
/*
@@ -10189,40 +10183,27 @@ static int asc_build_req(asc_board_t *boardp, struct
scsi_cmnd *scp,
* Build ASC_SCSI_Q for a contiguous buffer or a scatter-gather
* buffer command.
*/
- if (scp->use_sg == 0) {
+ use_sg = scsi_dma_map(scp);
+ if (use_sg == 0) {
/*
* CDB request of single contiguous buffer.
*/
ASC_STATS(scp->device->host, cont_cnt);
- scp->SCp.dma_handle = scp->request_bufflen ?
- dma_map_single(boardp->dev, scp->request_buffer,
- scp->request_bufflen,
- scp->sc_data_direction) : 0;
- asc_scsi_q->q1.data_addr = cpu_to_le32(scp->SCp.dma_handle);
- asc_scsi_q->q1.data_cnt = cpu_to_le32(scp->request_bufflen);
- AS
Re: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 12:20:38 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 20:59:49 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > On 9/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> > > > wrote: > > > > > > > I have a couple of old NUMA-Q systems which are unable to read their > > > > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > > > > even the partition tables read correctly, and then they go pop: > > > > I reported a similar problem on Sep 1, but until now got no response. > > You still haven't had a response ;) Let's add a cc. > > Oh, you reported it against 2.6.23-rc4-mm1 > (http://lkml.org/lkml/2007/9/1/92) and I did cc linux-ide in my response. > > I'll continue to point out where this sort of thing occurs because last > week I was told that a reson why so many bug reports are ignored is because > "linux-kernel has too much traffic". many SCSI people don't subscribe to linux-kernel, I think. > > The system boots, reads the partition tables, starts the RAID and then > > kicks one drive out because of errors. > > Andy is using qla1280. You're using sata. So it's probably a different > bug, with the same symptoms. This might be a sg chaining bug too (probabaly sg chaining libata patch). Can you try the following patch that I've just sent: http://lkml.org/lkml/2007/9/10/251 The patch also disables chaining sg list for libata. - 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 ver2 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/arm/fas216.c | 16 +++-
drivers/scsi/arm/fas216.h |3 +++
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index fb5f202..a715632 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, struct
scsi_cmnd *SCpnt,
* the upper layers to process. This would have been set
* correctly by fas216_std_done.
*/
+ scsi_eh_restore_cmnd(SCpnt, &info->ses);
SCpnt->scsi_done(SCpnt);
}
@@ -2103,23 +2104,12 @@ request_sense:
if (SCpnt->cmnd[0] == REQUEST_SENSE)
goto done;
+ scsi_eh_prep_cmnd(SCpnt, &info->ses, NULL, 0, ~0);
fas216_log_target(info, LOG_CONNECT, SCpnt->device->id,
"requesting sense");
- memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd));
- SCpnt->cmnd[0] = REQUEST_SENSE;
- SCpnt->cmnd[1] = SCpnt->device->lun << 5;
- SCpnt->cmnd[4] = sizeof(SCpnt->sense_buffer);
- SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]);
- SCpnt->SCp.buffer = NULL;
- SCpnt->SCp.buffers_residual = 0;
- SCpnt->SCp.ptr = (char *)SCpnt->sense_buffer;
- SCpnt->SCp.this_residual = sizeof(SCpnt->sense_buffer);
- SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer);
+ init_SCp(SCpnt);
SCpnt->SCp.Message = 0;
SCpnt->SCp.Status = 0;
- SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer);
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
- SCpnt->use_sg = 0;
SCpnt->tag = 0;
SCpnt->host_scribble = (void *)fas216_rq_sns_done;
diff --git a/drivers/scsi/arm/fas216.h b/drivers/scsi/arm/fas216.h
index 00e5f05..c39882e 100644
--- a/drivers/scsi/arm/fas216.h
+++ b/drivers/scsi/arm/fas216.h
@@ -16,6 +16,8 @@
#define NO_IRQ 255
#endif
+#include
+
#include "queue.h"
#include "msgqueue.h"
@@ -311,6 +313,7 @@ typedef struct {
/* miscellaneous */
int internal_done; /* flag to indicate
request done */
+ struct scsi_eh_save *ses; /* holds request sense restore
info */
unsigned long magic_end;
} FAS216_Info;
--
1.5.3.1
-
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: 2.6.23-rc4-mm1
On 9/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 20:59:49 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > On 9/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> > > > wrote: > > I reported a similar problem on Sep 1, but until now got no response. > > You still haven't had a response ;) Let's add a cc. But the mail from Andy was a nice point to try to another cc, i.e. linux-scsi that you added. :) > Oh, you reported it against 2.6.23-rc4-mm1 > (http://lkml.org/lkml/2007/9/1/92) and I did cc linux-ide in my response. > [snip] > Andy is using qla1280. You're using sata. So it's probably a different > bug, with the same symptoms. Yes, but you (Andrew) also said in response to Andy: "If it's not that then perhaps something in scsi core broke, dunno." So I wanted to add that my problem migth point this bug into the core direction. > Can you please confirm that this bug is present in -mm and not present in > mainline (yet)? Currently using 2.6.23-rc3-mm1, that works for me. Now downloading 2.6.23-rc5-git1... Torsten - 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 ver2 4/5] NCR5380: Use scsi_eh API for REQUEST_SENSE invocation
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/NCR5380.c | 23 +--
drivers/scsi/NCR5380.h |7 +++
drivers/scsi/atari_NCR5380.c | 23 ---
drivers/scsi/sun3_NCR5380.c | 18 +++---
4 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index f8e449a..575c715 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -1542,9 +1542,7 @@ part2:
hostdata->connected = cmd;
hostdata->busy[cmd->device->id] |= (1 << cmd->device->lun);
- if (cmd->SCp.ptr != (char *)cmd->sense_buffer) {
- initialize_SCp(cmd);
- }
+ initialize_SCp(cmd);
return 0;
@@ -2280,19 +2278,16 @@ static void NCR5380_information_transfer(struct
Scsi_Host *instance) {
cmd->result = (cmd->result &
0x00) | (DID_ERROR << 16);
#ifdef AUTOSENSE
+ if ((cmd->cmnd[0] == REQUEST_SENSE) &&
+ hostdata->ses.cmd_len) {
+ scsi_eh_restore_cmnd(cmd,
&hostdata->ses);
+ hostdata->ses.cmd_len = 0 ;
+ }
+
if ((cmd->cmnd[0] != REQUEST_SENSE) &&
(status_byte(cmd->SCp.Status) == CHECK_CONDITION)) {
+ scsi_eh_prep_cmnd(cmd,
&hostdata->ses, NULL, 0, ~0);
+
dprintk(NDEBUG_AUTOSENSE,
("scsi%d : performing request sense\n", instance->host_no));
- cmd->cmnd[0] = REQUEST_SENSE;
- cmd->cmnd[1] &= 0xe0;
- cmd->cmnd[2] = 0;
- cmd->cmnd[3] = 0;
- cmd->cmnd[4] =
sizeof(cmd->sense_buffer);
- cmd->cmnd[5] = 0;
-
- cmd->SCp.buffer = NULL;
- cmd->SCp.buffers_residual = 0;
- cmd->SCp.ptr = (char *)
cmd->sense_buffer;
- cmd->SCp.this_residual =
sizeof(cmd->sense_buffer);
LIST(cmd,
hostdata->issue_queue);
cmd->host_scribble = (unsigned
char *)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index bccf13f..f9587e6 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -30,6 +30,10 @@
#include
+#ifdef AUTOSENSE
+#include
+#endif
+
#define NCR5380_PUBLIC_RELEASE 7
#define NCR53C400_PUBLIC_RELEASE 2
@@ -281,6 +285,9 @@ struct NCR5380_hostdata {
unsigned pendingr;
unsigned pendingw;
#endif
+#ifdef AUTOSENSE
+ struct scsi_eh_save ses;
+#endif
};
#ifdef __KERNEL__
diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index 03dbe60..b253d37 100644
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -2235,24 +2235,17 @@ static void NCR5380_information_transfer(struct
Scsi_Host *instance)
cmd->result = (cmd->result &
0x00) | (DID_ERROR << 16);
#ifdef AUTOSENSE
+ if ((cmd->cmnd[0] == REQUEST_SENSE) &&
+ hostdata->ses.cmd_len) {
+ scsi_eh_restore_cmnd(cmd,
&hostdata->ses);
+ hostdata->ses.cmd_len = 0 ;
+ }
+
if ((cmd->cmnd[0] != REQUEST_SENSE) &&
(status_byte(cmd->SCp.Status) ==
CHECK_CONDITION)) {
+ scsi_eh_prep_cmnd(cmd,
&hostdata->ses, NULL, 0, ~0);
+
ASEN_PRINTK("scsi%d: performing
request sense\n", HOSTNO);
- cmd->cmnd[0] = REQUEST_SENSE;
- cmd->cmnd[1] &= 0xe0;
- cmd->cmnd[2] = 0;
- cmd->cmnd[3] = 0;
- cmd->cmnd[4] =
sizeof(cmd->sense_buffer);
- cmd->cmnd[5] = 0;
- cmd->cmd_len =
COMMAND_SIZE(cmd->cmnd[0]);
-
- cmd->use_sg =
[PATCH ver2 3/5] usb: transport.c use scsi_eh API in REQUEST_SENSE execution
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/usb/storage/transport.c | 46 +++---
1 files changed, 4 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 323293a..c646750 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -50,7 +50,7 @@
#include
#include
-#include
+#include
#include
#include "usb.h"
@@ -580,25 +580,11 @@ void usb_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
/* Now, if we need to do the auto-sense, let's do it */
if (need_auto_sense) {
int temp_result;
- void* old_request_buffer;
- unsigned short old_sg;
- unsigned old_request_bufflen;
- unsigned char old_sc_data_direction;
- unsigned char old_cmd_len;
- unsigned char old_cmnd[MAX_COMMAND_SIZE];
- int old_resid;
+ struct scsi_eh_save ses;
US_DEBUGP("Issuing auto-REQUEST_SENSE\n");
- /* save the old command */
- memcpy(old_cmnd, srb->cmnd, MAX_COMMAND_SIZE);
- old_cmd_len = srb->cmd_len;
-
- /* set the command and the LUN */
- memset(srb->cmnd, 0, MAX_COMMAND_SIZE);
- srb->cmnd[0] = REQUEST_SENSE;
- srb->cmnd[1] = old_cmnd[1] & 0xE0;
- srb->cmnd[4] = 18;
+ scsi_eh_prep_cmnd(srb, &ses, NULL, 0, US_SENSE_SIZE);
/* FIXME: we must do the protocol translation here */
if (us->subclass == US_SC_RBC || us->subclass == US_SC_SCSI)
@@ -606,36 +592,12 @@ void usb_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
else
srb->cmd_len = 12;
- /* set the transfer direction */
- old_sc_data_direction = srb->sc_data_direction;
- srb->sc_data_direction = DMA_FROM_DEVICE;
-
- /* use the new buffer we have */
- old_request_buffer = srb->request_buffer;
- srb->request_buffer = us->sensebuf;
-
- /* set the buffer length for transfer */
- old_request_bufflen = srb->request_bufflen;
- srb->request_bufflen = US_SENSE_SIZE;
-
- /* set up for no scatter-gather use */
- old_sg = srb->use_sg;
- srb->use_sg = 0;
-
/* issue the auto-sense command */
- old_resid = srb->resid;
srb->resid = 0;
temp_result = us->transport(us->srb, us);
/* let's clean up right away */
- memcpy(srb->sense_buffer, us->sensebuf, US_SENSE_SIZE);
- srb->resid = old_resid;
- srb->request_buffer = old_request_buffer;
- srb->request_bufflen = old_request_bufflen;
- srb->use_sg = old_sg;
- srb->sc_data_direction = old_sc_data_direction;
- srb->cmd_len = old_cmd_len;
- memcpy(srb->cmnd, old_cmnd, MAX_COMMAND_SIZE);
+ scsi_eh_restore_cmnd(srb, &ses);
if (test_bit(US_FLIDX_TIMED_OUT, &us->flags)) {
US_DEBUGP("-- auto-sense aborted\n");
--
1.5.3.1
-
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 ver2 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
- Drivers/transports that want to send a synchronous REQUEST_SENSE command
as part of their .queuecommand sequence, have 2 new API's that facilitate
in doing so and abstract them from scsi-ml internals.
void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
struct scsi_eh_save *sesci, unsigned char *cmnd,
int cmnd_size, int copy_sense)
Will hijack a command and prepare it for request sense if needed.
And will save any later needed info into a scsi_eh_save structure.
void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd,
struct scsi_eh_save *sesci);
Will undo any changes done to a command by above function. Making
it ready for completion.
- Re-factor scsi_send_eh_cmnd to use above APIs
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_error.c | 125 ++---
include/scsi/scsi_eh.h| 23 -
2 files changed, 95 insertions(+), 53 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 20a72aa..a02400c 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -590,42 +590,23 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
}
/**
- * scsi_send_eh_cmnd - submit a scsi command as part of error recory
+ * scsi_eh_prep_cmnd - Save a scsi command info as part of error recory
* @scmd: SCSI command structure to hijack
- * @cmnd: CDB to send
+ * @ses:structure to save restore information
+ * @cmnd: CDB to send. Can be NULL if no new cmnd is needed
* @cmnd_size: size in bytes of @cmnd
- * @timeout:timeout for this request
- * @copy_sense: request sense data if set to 1
+ * @copy_sense: size of sense data to copy. or 0
*
- * This function is used to send a scsi command down to a target device
- * as part of the error recovery process. If @copy_sense is 0 the command
- * sent must be one that does not transfer any data. If @copy_sense is 1
- * the command must be REQUEST_SENSE and this functions copies out the
- * sense buffer it got into @scmd->sense_buffer.
- *
- * Return value:
- *SUCCESS or FAILED or NEEDS_RETRY
+ * This function is used to save a scsi command information before re-execution
+ * as part of an error recovery process. If @copy_sense is 0 the command
+ * given must be one that does not transfer any data. If @copy_sense != 0
+ * the command should be NULL and this functions sets up the cmnd and
+ * command buffers to be read into @scmd->sense_buffer.
**/
-static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
-int cmnd_size, int timeout, unsigned copy_sense)
+void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses,
+ unsigned char *cmnd, int cmnd_size, unsigned copy_sense)
{
struct scsi_device *sdev = scmd->device;
- struct Scsi_Host *shost = sdev->host;
- DECLARE_COMPLETION_ONSTACK(done);
- unsigned long timeleft;
- unsigned long flags;
-
- unsigned char old_cmd_len;
- unsigned char old_cmnd[MAX_COMMAND_SIZE];
- enum dma_data_direction old_data_direction;
- unsigned old_bufflen;
- void *old_buffer;
- unsigned short old_use_sg;
- int old_resid;
- int old_result;
-
- struct scatterlist sgl;
- int rtn;
/*
* We need saved copies of a number of fields - this is because
@@ -634,14 +615,14 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_cmd_len = scmd->cmd_len;
- memcpy(old_cmnd, scmd->cmnd, sizeof(scmd->cmnd));
- old_data_direction = scmd->sc_data_direction;
- old_bufflen = scmd->request_bufflen;
- old_buffer = scmd->request_buffer;
- old_use_sg = scmd->use_sg;
- old_resid = scmd->resid;
- old_result = scmd->result;
+ ses->cmd_len = scmd->cmd_len;
+ memcpy(ses->cmnd, scmd->cmnd, sizeof(scmd->cmnd));
+ ses->data_direction = scmd->sc_data_direction;
+ ses->bufflen = scmd->request_bufflen;
+ ses->buffer = scmd->request_buffer;
+ ses->use_sg = scmd->use_sg;
+ ses->resid = scmd->resid;
+ ses->result = scmd->result;
if (cmnd) {
memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
@@ -650,9 +631,9 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
}
if (copy_sense) {
- sg_init_one(&sgl, scmd->sense_buffer,
+ sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
sizeof(scmd->sense_buffer));
- scmd->request_buffer = &sgl;
+ scmd->request_buffer = &ses->sense_sgl;
scmd->sc_data_direction = DMA_FROM_DEVICE;
scmd->request_bufflen = min_t(unsigned,
sizeof(scmd->sense_b
[PATCH ver2 1/5] scsi_error: code cleanup before refactoring of scsi_send_eh_cmnd()
- regrouped variables for easier reviewing of next patch
- Support of cmnd==NULL in call to scsi_send_eh_cmnd()
- In the copy_sense case set transfer size to the minimum
size of sense_buffer and passed copy_sense. cmnd[4] is
set accordingly.
- REQUEST_SENSE is set into cmnd[0] so if copy_sense is
not Zero passed cmnd can/should be NULL.
- Also save/restore resid of faild command.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_error.c | 63 +
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c8e351f..20a72aa 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -607,21 +607,24 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
*SUCCESS or FAILED or NEEDS_RETRY
**/
static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
-int cmnd_size, int timeout, int copy_sense)
+int cmnd_size, int timeout, unsigned copy_sense)
{
struct scsi_device *sdev = scmd->device;
struct Scsi_Host *shost = sdev->host;
- int old_result = scmd->result;
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
unsigned long flags;
- struct scatterlist sgl;
+
+ unsigned char old_cmd_len;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
enum dma_data_direction old_data_direction;
- unsigned short old_use_sg;
- unsigned char old_cmd_len;
unsigned old_bufflen;
void *old_buffer;
+ unsigned short old_use_sg;
+ int old_resid;
+ int old_result;
+
+ struct scatterlist sgl;
int rtn;
/*
@@ -631,24 +634,37 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_buffer = scmd->request_buffer;
- old_bufflen = scmd->request_bufflen;
+ old_cmd_len = scmd->cmd_len;
memcpy(old_cmnd, scmd->cmnd, sizeof(scmd->cmnd));
old_data_direction = scmd->sc_data_direction;
- old_cmd_len = scmd->cmd_len;
+ old_bufflen = scmd->request_bufflen;
+ old_buffer = scmd->request_buffer;
old_use_sg = scmd->use_sg;
+ old_resid = scmd->resid;
+ old_result = scmd->result;
- memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
- memcpy(scmd->cmnd, cmnd, cmnd_size);
+ if (cmnd) {
+ memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
+ memcpy(scmd->cmnd, cmnd, cmnd_size);
+ scmd->cmd_len = COMMAND_SIZE(scmd->cmnd[0]);
+ }
if (copy_sense) {
sg_init_one(&sgl, scmd->sense_buffer,
sizeof(scmd->sense_buffer));
-
- scmd->sc_data_direction = DMA_FROM_DEVICE;
- scmd->request_bufflen = sgl.length;
scmd->request_buffer = &sgl;
+ scmd->sc_data_direction = DMA_FROM_DEVICE;
+ scmd->request_bufflen = min_t(unsigned,
+ sizeof(scmd->sense_buffer), copy_sense);
scmd->use_sg = 1;
+ memset(scmd->cmnd, 0, 6);
+ scmd->cmnd[0] = REQUEST_SENSE;
+ scmd->cmnd[4] = scmd->request_bufflen;
+ /*
+* Zero the sense buffer. The scsi spec mandates that any
+* untransferred sense data should be interpreted as being zero.
+*/
+ memset(scmd->sense_buffer, 0, sizeof(scmd->sense_buffer));
} else {
scmd->request_buffer = NULL;
scmd->request_bufflen = 0;
@@ -657,18 +673,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
}
scmd->underflow = 0;
- scmd->cmd_len = COMMAND_SIZE(scmd->cmnd[0]);
- if (sdev->scsi_level <= SCSI_2)
+ if (sdev->scsi_level <= SCSI_2 && sdev->scsi_level != SCSI_UNKNOWN)
scmd->cmnd[1] = (scmd->cmnd[1] & 0x1f) |
(sdev->lun << 5 & 0xe0);
- /*
-* Zero the sense buffer. The scsi spec mandates that any
-* untransferred sense data should be interpreted as being zero.
-*/
- memset(scmd->sense_buffer, 0, sizeof(scmd->sense_buffer));
-
shost->eh_action = &done;
spin_lock_irqsave(shost->host_lock, flags);
@@ -716,12 +725,13 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
/*
* Restore original data
*/
- scmd->request_buffer = old_buffer;
- scmd->request_bufflen = old_bufflen;
+ scmd->cmd_len = old_cmd_len;
memcpy(scmd->cmnd, old_cmnd, sizeof(scmd->cmnd));
scmd->sc_data_direction = old_data_direction;
- scmd->cmd_len = old_cmd_len;
+ scmd->request_bufflen = ol
Re: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 11:19:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > > > I have a couple of old NUMA-Q systems which are unable to read their > > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > > even the partition tables read correctly, and then they go pop: > > > > qla1280: QLA1040 found on PCI bus 0, dev 10 > > cc's added. > > > Clocksource tsc unstable (delta = 99922590 ns) > > Time: jiffies clocksource has been installed. > > scsi(0:0): Resetting SCSI BUS > > scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter > > Firmware version: 7.65.06, Driver version 3.26 > > scsi 0:0:0:0: Direct-Access IBM DGHS18X 0360 PQ: 0 > > ANSI: 3 > > scsi(0:0:0:0): Sync: period 10, offset 12, Wide > > scsi 0:0:1:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:1:0): Sync: period 10, offset 12, Wide > > scsi 0:0:2:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:2:0): Sync: period 10, offset 12, Wide > > scsi 0:0:3:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:3:0): Sync: period 10, offset 12, Wide > > scsi 0:0:4:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:4:0): Sync: period 10, offset 12, Wide > > st: Version 20070203, fixed bufsize 32768, s/g segs 256 > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sda: sda1 > > sd 0:0:0:0: [sda] Attached SCSI disk > > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:1:0: [sdb] Write Protect is off > > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:1:0: [sdb] Write Protect is off > > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdb: unknown partition table > > sd 0:0:1:0: [sdb] Attached SCSI disk > > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:2:0: [sdc] Write Protect is off > > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:2:0: [sdc] Write Protect is off > > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdc: sdc1 > > sd 0:0:2:0: [sdc] Attached SCSI disk > > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:3:0: [sdd] Write Protect is off > > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:3:0: [sdd] Write Protect is off > > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdd: sdd1 > > sd 0:0:3:0: [sdd] Attached SCSI disk > > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:4:0: [sde] Write Protect is off > > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:4:0: [sde] Write Protect is off > > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sde: unknown partition table > > sd 0:0:4:0: [sde] Attached SCSI disk > > sd 0:0:0:0: Attached scsi generic sg0 type 0 > > sd 0:0:1:0: Attached scsi generic sg1 type 0 > > sd 0:0:2:0: Attached scsi generic sg2 type 0 > > sd 0:0:3:0: Attached scsi generic sg3 type 0 > > sd 0:0:4:0: Attached scsi generic sg4 type 0 > > serio: i8042 KBD port at 0x60,0x64 irq 1 > > serio: i8042 AUX port at 0x60,0x64 irq 12 > > mice: PS/2 mouse device common for all mice > > input: AT Translated Set 2 keyboard as /class/input/input0 > > oprofile: using NMI interrupt. > > TCP cubic registered > > NET: Registered protocol family 1 > > NET: Registered protocol family 17 > > Using IPI Shortcut mode > > input: PS/2 Logitech Mouse as /class/input/input1 > > RAMDISK: cramfs filesystem found at block 0 > > RAMDISK: Loading 1244KiB [1 disk] into ram disk... > > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/done. > > VFS: Mounted root (cramfs filesystem) readonly. > > Freeing unused kernel memory: 220k freed > > initrd-tools: 0.1.81.1 > > mount: fs type devfs not supported by kernel > > FATAL: Module sd_mod n
Re: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 20:59:49 +0200 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > On 9/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > > > > > I have a couple of old NUMA-Q systems which are unable to read their > > > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > > > even the partition tables read correctly, and then they go pop: > > I reported a similar problem on Sep 1, but until now got no response. You still haven't had a response ;) Let's add a cc. Oh, you reported it against 2.6.23-rc4-mm1 (http://lkml.org/lkml/2007/9/1/92) and I did cc linux-ide in my response. I'll continue to point out where this sort of thing occurs because last week I was told that a reson why so many bug reports are ignored is because "linux-kernel has too much traffic". > The system boots, reads the partition tables, starts the RAID and then > kicks one drive out because of errors. Andy is using qla1280. You're using sata. So it's probably a different bug, with the same symptoms. > > > qla1280: QLA1040 found on PCI bus 0, dev 10 > > > Clocksource tsc unstable (delta = 99922590 ns) > > > Time: jiffies clocksource has been installed. > > > scsi(0:0): Resetting SCSI BUS > > > scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter > > > Firmware version: 7.65.06, Driver version 3.26 > > > scsi 0:0:0:0: Direct-Access IBM DGHS18X 0360 PQ: 0 > > > ANSI: 3 > > > scsi(0:0:0:0): Sync: period 10, offset 12, Wide > > > scsi 0:0:1:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > > ANSI: 2 > > > scsi(0:0:1:0): Sync: period 10, offset 12, Wide > > > scsi 0:0:2:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > > ANSI: 2 > > > scsi(0:0:2:0): Sync: period 10, offset 12, Wide > > > scsi 0:0:3:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > > ANSI: 2 > > > scsi(0:0:3:0): Sync: period 10, offset 12, Wide > > > scsi 0:0:4:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > > ANSI: 2 > > > scsi(0:0:4:0): Sync: period 10, offset 12, Wide > > > st: Version 20070203, fixed bufsize 32768, s/g segs 256 > > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > > sd 0:0:0:0: [sda] Write Protect is off > > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > > DPO and FUA > > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > > sd 0:0:0:0: [sda] Write Protect is off > > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > > DPO and FUA > > >sda: sda1 > [snip] > > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > > end_request: I/O error, dev sda, sector 63 > > > Buffer I/O error on device sda1, logical block 0 > > > Buffer I/O error on device sda1, logical block 1 > > > Buffer I/O error on device sda1, logical block 2 > > > Buffer I/O error on device sda1, logical block 3 > > > mount: fs type devfs not supported by kernel > > > ext3: No journal on filesystem on sda1 > > > umount: devfs: not mounted > > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > > end_request: I/O error, dev sda, sector 28010831 > > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > > end_request: I/O error, dev sda, sector 31080815 > > >From my log: > [3.89] scsi0 : sata_sil24 > [3.90] scsi1 : sata_sil24 > [3.90] ata1: SATA max UDMA/100 host [EMAIL PROTECTED] port > 0xefef8000 irq 16 > [3.92] ata2: SATA max UDMA/100 host [EMAIL PROTECTED] port > 0xefefa000 irq 16 > [4.30] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [4.36] ata1.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133 > [4.37] ata1.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) > [4.43] ata1.00: configured for UDMA/100 > [4.50] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0010dc5cc354] > [4.50] ieee1394: Host added: ID:BUS[0-01:1023] GUID[0011d8c4c261] > [4.79] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [4.85] ata2.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133 > [4.86] ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) > [4.92] ata2.00: configured for UDMA/100 > [4.93] scsi 0:0:0:0: Direct-Access ATA MAXTOR > STM332082 3.AA PQ: 0 ANSI: 5 > [4.96] sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 > MB) > [4.98] sd 0:0:0:0: [sda] Write Protect is off > [4.99] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [4.99] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [5.02] sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 > MB) > [5.04] sd 0:0:0:0: [sda] Write Protect is off > [5.05] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [5.05]
[patchset ver2 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
Thank you Christoph, Randy, Alen for your comments. Here is ver 2 incorporating all your suggestions. On Mon, Sep 10 2007 at 18:12 +0300, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > I think just struct "struct scsi_eh_save *save" is descriptive enough and > almost fits on a line as well.. Also continuation of the prototype > is indented by two tabs normally. > I think you can kill the old prefixes in the struct, they're saved > per defintion. Done On Mon, Sep 10 2007 at 18:58 +0300, Alan Stern <[EMAIL PROTECTED]> wrote: > A trivial problem is that quilt complains about patch 3, which leaves > extra whitespace at the end of line 591 in transport.c. > Thanks > More seriously, why make the caller define a static generic_sense > array? Why not put the array in scsi_eh_prep_cmnd(), where it can be > used whenever copy_sense is nonzero? > I hope you like my solution > The line initializing the sense buffer to zero should be inside the > copy_sense conditional block. > Thanks > The code setting the LUN bits in scmd[1] is wrong. It should be like > the code in scsi_dispatch_cmd(); i.e., those bits should not be set if > the scsi_level is SCSI_UNKNOWN. > Thanks, good catch > Finally, a really serious problem. The code sets the buffer length for > the REQUEST SENSE command to be the length of scmd->sense_buffer, which > is 96. But many USB devices won't work properly unless the requesed > sense data length is 18. The appropriate adjustment must be added to > transport.c in patch 3. > I was afraid of that at the beginning. But testing both with a Seagate USB sata hard-disk and Sandisk 2Gb usb-stick. They both returned a short read of 56 but other wise were happy. So I thought it is leftovers from The time the sense buffer was driver allocated. Also the standard recommends a short-read behavior. But I have taken your advise to hart and changed the code accordingly. Please check me out. In motivation to abstract scsi_cmnd members and insulate drivers/transports from scsi_cmnd internals. The last place left was the REQUEST_SENSE sequence when done synchronous, by drivers. Also all these drivers would do a use_sg==0 command invocation, preventing from doing cleanups on these drivers/transports. So this patchset is left-overs from Christoph's 2.6.18 cleanups. In this patchset I have re-factored scsi_error to make it possible for drivers to use an abstract (easy to use, I hope) API for invoking a REQUEST_SENSE command. The API is declared in scsi/scsi_eh.h [patch 1/5] scsi_error: code cleanup before refactoring of scsi_send_eh_cmnd() Move some code around and add new fixtures here. So next patch is left a Mechanical breakup of code. [patch 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE Here new API is introduced in scsi/scsi_eh.h and mechanical move of code to the new functions. [PATCH 3/5] usb: transport.c use scsi_eh API in REQUEST_SENSE execution Use above API for drivers/usb/storage/transport.c. Now that last User of use_sg==0, we can do the USB storage cleanups. [PATCH 4/5] NCR5380: Use scsi_eh API for REQUEST_SENSE invocation All NCR5380 family of drivers used to send a REQUEST_SENSE command. [PATCH 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation drivers/scsi/arm/fas216.c need change also. Please Test as much as possible, and report any problems/differences. Boaz Harrosh - 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: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 11:19:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > > > I have a couple of old NUMA-Q systems which are unable to read their > > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > > even the partition tables read correctly, and then they go pop: > > > > qla1280: QLA1040 found on PCI bus 0, dev 10 > > cc's added. > > > Clocksource tsc unstable (delta = 99922590 ns) > > Time: jiffies clocksource has been installed. > > scsi(0:0): Resetting SCSI BUS > > scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter > > Firmware version: 7.65.06, Driver version 3.26 > > scsi 0:0:0:0: Direct-Access IBM DGHS18X 0360 PQ: 0 > > ANSI: 3 > > scsi(0:0:0:0): Sync: period 10, offset 12, Wide > > scsi 0:0:1:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:1:0): Sync: period 10, offset 12, Wide > > scsi 0:0:2:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:2:0): Sync: period 10, offset 12, Wide > > scsi 0:0:3:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:3:0): Sync: period 10, offset 12, Wide > > scsi 0:0:4:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:4:0): Sync: period 10, offset 12, Wide > > st: Version 20070203, fixed bufsize 32768, s/g segs 256 > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sda: sda1 > > sd 0:0:0:0: [sda] Attached SCSI disk > > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:1:0: [sdb] Write Protect is off > > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:1:0: [sdb] Write Protect is off > > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdb: unknown partition table > > sd 0:0:1:0: [sdb] Attached SCSI disk > > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:2:0: [sdc] Write Protect is off > > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:2:0: [sdc] Write Protect is off > > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdc: sdc1 > > sd 0:0:2:0: [sdc] Attached SCSI disk > > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:3:0: [sdd] Write Protect is off > > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:3:0: [sdd] Write Protect is off > > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sdd: sdd1 > > sd 0:0:3:0: [sdd] Attached SCSI disk > > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:4:0: [sde] Write Protect is off > > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > > sd 0:0:4:0: [sde] Write Protect is off > > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sde: unknown partition table > > sd 0:0:4:0: [sde] Attached SCSI disk > > sd 0:0:0:0: Attached scsi generic sg0 type 0 > > sd 0:0:1:0: Attached scsi generic sg1 type 0 > > sd 0:0:2:0: Attached scsi generic sg2 type 0 > > sd 0:0:3:0: Attached scsi generic sg3 type 0 > > sd 0:0:4:0: Attached scsi generic sg4 type 0 > > serio: i8042 KBD port at 0x60,0x64 irq 1 > > serio: i8042 AUX port at 0x60,0x64 irq 12 > > mice: PS/2 mouse device common for all mice > > input: AT Translated Set 2 keyboard as /class/input/input0 > > oprofile: using NMI interrupt. > > TCP cubic registered > > NET: Registered protocol family 1 > > NET: Registered protocol family 17 > > Using IPI Shortcut mode > > input: PS/2 Logitech Mouse as /class/input/input1 > > RAMDISK: cramfs filesystem found at block 0 > > RAMDISK: Loading 1244KiB [1 disk] into ram disk... > > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/done. > > VFS: Mounted root (cramfs filesystem) readonly. > > Freeing unused kernel memory: 220k freed > > initrd-tools: 0.1.81.1 > > mount: fs type devfs not supported by kernel > > FATAL: Module sd_mod n
Re: 2.6.23-rc4-mm1
On 9/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > > > I have a couple of old NUMA-Q systems which are unable to read their > > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > > even the partition tables read correctly, and then they go pop: I reported a similar problem on Sep 1, but until now got no response. The system boots, reads the partition tables, starts the RAID and then kicks one drive out because of errors. > > qla1280: QLA1040 found on PCI bus 0, dev 10 > > Clocksource tsc unstable (delta = 99922590 ns) > > Time: jiffies clocksource has been installed. > > scsi(0:0): Resetting SCSI BUS > > scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter > > Firmware version: 7.65.06, Driver version 3.26 > > scsi 0:0:0:0: Direct-Access IBM DGHS18X 0360 PQ: 0 > > ANSI: 3 > > scsi(0:0:0:0): Sync: period 10, offset 12, Wide > > scsi 0:0:1:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:1:0): Sync: period 10, offset 12, Wide > > scsi 0:0:2:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:2:0): Sync: period 10, offset 12, Wide > > scsi 0:0:3:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:3:0): Sync: period 10, offset 12, Wide > > scsi 0:0:4:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 > > ANSI: 2 > > scsi(0:0:4:0): Sync: period 10, offset 12, Wide > > st: Version 20070203, fixed bufsize 32768, s/g segs 256 > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports > > DPO and FUA > >sda: sda1 [snip] > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 63 > > Buffer I/O error on device sda1, logical block 0 > > Buffer I/O error on device sda1, logical block 1 > > Buffer I/O error on device sda1, logical block 2 > > Buffer I/O error on device sda1, logical block 3 > > mount: fs type devfs not supported by kernel > > ext3: No journal on filesystem on sda1 > > umount: devfs: not mounted > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 28010831 > > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > > end_request: I/O error, dev sda, sector 31080815 >From my log: [3.89] scsi0 : sata_sil24 [3.90] scsi1 : sata_sil24 [3.90] ata1: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xefef8000 irq 16 [3.92] ata2: SATA max UDMA/100 host [EMAIL PROTECTED] port 0xefefa000 irq 16 [4.30] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.36] ata1.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133 [4.37] ata1.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.43] ata1.00: configured for UDMA/100 [4.50] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0010dc5cc354] [4.50] ieee1394: Host added: ID:BUS[0-01:1023] GUID[0011d8c4c261] [4.79] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.85] ata2.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133 [4.86] ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.92] ata2.00: configured for UDMA/100 [4.93] scsi 0:0:0:0: Direct-Access ATA MAXTOR STM332082 3.AA PQ: 0 ANSI: 5 [4.96] sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) [4.98] sd 0:0:0:0: [sda] Write Protect is off [4.99] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [4.99] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [5.02] sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) [5.04] sd 0:0:0:0: [sda] Write Protect is off [5.05] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.05] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [5.08] sda: sda1 sda2 [5.11] sd 0:0:0:0: [sda] Attached SCSI disk [5.12] scsi 1:0:0:0: Direct-Access ATA MAXTOR STM332082 3.AA PQ: 0 ANSI: 5 [5.14] sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) [5.17] sd 1:0:0:0: [sdb] Write Protect is off [5.18] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [5.18] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [5.21] sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) [5.23] sd 1:0:0:0: [sdb] Write Protect is off [5.24] sd 1:0:0
Re: 2.6.23-rc4-mm1
On Mon, 10 Sep 2007 18:49:26 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote: > I have a couple of old NUMA-Q systems which are unable to read their > boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and > even the partition tables read correctly, and then they go pop: > > qla1280: QLA1040 found on PCI bus 0, dev 10 cc's added. > Clocksource tsc unstable (delta = 99922590 ns) > Time: jiffies clocksource has been installed. > scsi(0:0): Resetting SCSI BUS > scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter > Firmware version: 7.65.06, Driver version 3.26 > scsi 0:0:0:0: Direct-Access IBM DGHS18X 0360 PQ: 0 ANSI: 3 > scsi(0:0:0:0): Sync: period 10, offset 12, Wide > scsi 0:0:1:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 ANSI: 2 > scsi(0:0:1:0): Sync: period 10, offset 12, Wide > scsi 0:0:2:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 ANSI: 2 > scsi(0:0:2:0): Sync: period 10, offset 12, Wide > scsi 0:0:3:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 ANSI: 2 > scsi(0:0:3:0): Sync: period 10, offset 12, Wide > scsi 0:0:4:0: Direct-Access IBM OEM DCHS09X 5454 PQ: 0 ANSI: 2 > scsi(0:0:4:0): Sync: period 10, offset 12, Wide > st: Version 20070203, fixed bufsize 32768, s/g segs 256 > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO > and FUA > sd 0:0:0:0: [sda] 35843670 512-byte hardware sectors (18352 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO > and FUA >sda: sda1 > sd 0:0:0:0: [sda] Attached SCSI disk > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:1:0: [sdb] Write Protect is off > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO > and FUA > sd 0:0:1:0: [sdb] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:1:0: [sdb] Write Protect is off > sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO > and FUA >sdb: unknown partition table > sd 0:0:1:0: [sdb] Attached SCSI disk > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:2:0: [sdc] Write Protect is off > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO > and FUA > sd 0:0:2:0: [sdc] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:2:0: [sdc] Write Protect is off > sd 0:0:2:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO > and FUA >sdc: sdc1 > sd 0:0:2:0: [sdc] Attached SCSI disk > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:3:0: [sdd] Write Protect is off > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO > and FUA > sd 0:0:3:0: [sdd] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:3:0: [sdd] Write Protect is off > sd 0:0:3:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO > and FUA >sdd: sdd1 > sd 0:0:3:0: [sdd] Attached SCSI disk > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:4:0: [sde] Write Protect is off > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports DPO > and FUA > sd 0:0:4:0: [sde] 17796077 512-byte hardware sectors (9112 MB) > sd 0:0:4:0: [sde] Write Protect is off > sd 0:0:4:0: [sde] Write cache: disabled, read cache: enabled, supports DPO > and FUA >sde: unknown partition table > sd 0:0:4:0: [sde] Attached SCSI disk > sd 0:0:0:0: Attached scsi generic sg0 type 0 > sd 0:0:1:0: Attached scsi generic sg1 type 0 > sd 0:0:2:0: Attached scsi generic sg2 type 0 > sd 0:0:3:0: Attached scsi generic sg3 type 0 > sd 0:0:4:0: Attached scsi generic sg4 type 0 > serio: i8042 KBD port at 0x60,0x64 irq 1 > serio: i8042 AUX port at 0x60,0x64 irq 12 > mice: PS/2 mouse device common for all mice > input: AT Translated Set 2 keyboard as /class/input/input0 > oprofile: using NMI interrupt. > TCP cubic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Using IPI Shortcut mode > input: PS/2 Logitech Mouse as /class/input/input1 > RAMDISK: cramfs filesystem found at block 0 > RAMDISK: Loading 1244KiB [1 disk] into ram disk... > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/done. > VFS: Mounted root (cramfs filesystem) readonly. > Freeing unused kernel memory: 220k freed > initrd-tools: 0.1.81.1 > mount: fs type devfs not supported by kernel > FATAL: Module sd_mod not found. > umount: devfs: not mounted > ext3: No journal on filesystem on sda1 > sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00 > end_request: I/O error, dev sda, sector 63 > Buffer I/O error on device sda1, logical block 0 > Buffer I/O error on device sda1, logical block 1 >
mptsas related problem [2.6.22], LSI SAS1064ET PCI-E
Hello,
SR2520SAXS platform (S5000VSA mainboard in 2U SR2520 chassis) with
08:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET
PCI-Express Fusion-MPT SAS (rev 02)
onboard (well afaik on backplane) and four SATA discs in various software
raids level (1, 5 and 10) per partition.
Under bigger I/O load mptsas kicks out hdd disks like:
mptsas: ioc0: removing sata device, channel 0, id 24, phy 2
So far it dropped sdb twice and sdc once. Not sure if these are fauly
harddrives or controller problems or driver problems. Any hints?
ps. If someone knows how FwRev=0110h relates to firmware version at
http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=2487&OSFullName=OS+Independent&lang=eng&strOSs=38&submit=Go%21
then that's also interesting. Simply 01 10 ...== 1.16.0.0 ?
mptbase: Initiating ioc0 bringup
ioc0: SAS1064E: Capabilities={Initiator}
PCI: Setting latency timer of device :08:00.0 to 64
scsi0 : ioc0: LSISAS1064E, FwRev=0110h, Ports=1, MaxQ=511, IRQ=16
Device driver host0 lacks bus and class support for being resumed.
Device driver phy-0:0 lacks bus and class support for being resumed.
Device driver port-0:0 lacks bus and class support for being resumed.
Device driver expander-0:0 lacks bus and class support for being resumed.
Device driver phy-0:1 lacks bus and class support for being resumed.
Device driver phy-0:2 lacks bus and class support for being resumed.
Device driver phy-0:3 lacks bus and class support for being resumed.
Device driver phy-0:0:4 lacks bus and class support for being resumed.
Device driver phy-0:0:5 lacks bus and class support for being resumed.
Device driver port-0:0:0 lacks bus and class support for being resumed.
Device driver end_device-0:0:0 lacks bus and class support for being resumed.
Device driver target0:0:0 lacks bus and class support for being resumed.
scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD321KJ 0-10 PQ: 0 ANSI: 5
Device driver phy-0:0:6 lacks bus and class support for being resumed.
Device driver port-0:0:1 lacks bus and class support for being resumed.
Device driver end_device-0:0:1 lacks bus and class support for being resumed.
Device driver target0:0:1 lacks bus and class support for being resumed.
scsi 0:0:1:0: Direct-Access ATA SAMSUNG HD321KJ 0-10 PQ: 0 ANSI: 5
Device driver phy-0:0:7 lacks bus and class support for being resumed.
Device driver phy-0:0:8 lacks bus and class support for being resumed.
Device driver port-0:0:2 lacks bus and class support for being resumed.
Device driver end_device-0:0:2 lacks bus and class support for being resumed.
Device driver target0:0:2 lacks bus and class support for being resumed.
scsi 0:0:2:0: Direct-Access ATA SAMSUNG HD321KJ 0-10 PQ: 0 ANSI: 5
Device driver phy-0:0:9 lacks bus and class support for being resumed.
Device driver port-0:0:3 lacks bus and class support for being resumed.
Device driver end_device-0:0:3 lacks bus and class support for being resumed.
Device driver target0:0:3 lacks bus and class support for being resumed.
scsi 0:0:3:0: Direct-Access ATA SAMSUNG HD321KJ 0-10 PQ: 0 ANSI: 5
Device driver phy-0:0:10 lacks bus and class support for being resumed.
Device driver port-0:0:4 lacks bus and class support for being resumed.
Device driver phy-0:0:11 lacks bus and class support for being resumed.
Device driver phy-0:0:12 lacks bus and class support for being resumed.
Device driver phy-0:0:13 lacks bus and class support for being resumed.
Device driver phy-0:0:14 lacks bus and class support for being resumed.
Device driver port-0:0:5 lacks bus and class support for being resumed.
Device driver port-0:0:5 lacks bus and class support for being resumed.
Device driver end_device-0:0:5 lacks bus and class support for being resumed.
Device driver target0:0:4 lacks bus and class support for being resumed.
scsi 0:0:4:0: Enclosure ESG-SHV. SCA HSBP M13 2.04 PQ: 0 ANSI: 3
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 73 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 73 00 00 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:1:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: 73 00 00 08
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:1:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: 73 00 00 08
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sdb: sdb1 sdb2 sdb3 sdb4
sd 0:0:1:0: [sdb] Attach
Re: [patchset 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, 2007-09-10 at 10:03 -0700, Matthew Dharm wrote: > On Mon, Sep 10, 2007 at 05:11:23PM +0300, Boaz Harrosh wrote: > > > > In motivation to abstract scsi_cmnd members and insulate > > drivers/transports from scsi_cmnd internals. The last > > place left was the REQUEST_SENSE sequence when done > > synchronous, by drivers. > > This probably isn't serious, but I noticed one thing (beyond what Alan's > analysis noted)... > > I've always assumed that the scatterlist structs passed to an HCD were, > themselves, allocated from DMA-able memory. That is, not just the transfer > buffers themselves, but the struct scatterlist also. They are, but this is an artifact of the command allocation. Commands (as in the 6, 10 12 or 16 bytes of command sequence) are designed to be DMAable, meaning that everything that makes up a struct scsi_cmnd is automatically DMAable. However, the design is for the dma_mapped scatterlist to be converted to a form the underlying HBA can use. I don't currently know of any HBA whose descriptor format matches those of struct scatterlist, so I don't think there'll be any impact to putting the scatterlist in memory that might not be DMAable by the HBA. > In this implementation, the struct scatterlist used for the single-element > transfer of the request sense buffer is part of the > struct scsi_eh_save_cmnd_info, which is allocated on the stack (for at > least usb-storage). And, stack isn't DMA-able on all arches. > > It is not a problem for usb-storage, since the struct scatterlists are > processed in code into a series of URBs, so nobody actually does DMA the > scatterlist structures. However, I don't know enough about the other HCDs > to be certain about them. 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: [patchset 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, Sep 10, 2007 at 05:11:23PM +0300, Boaz Harrosh wrote: > > In motivation to abstract scsi_cmnd members and insulate > drivers/transports from scsi_cmnd internals. The last > place left was the REQUEST_SENSE sequence when done > synchronous, by drivers. This probably isn't serious, but I noticed one thing (beyond what Alan's analysis noted)... I've always assumed that the scatterlist structs passed to an HCD were, themselves, allocated from DMA-able memory. That is, not just the transfer buffers themselves, but the struct scatterlist also. In this implementation, the struct scatterlist used for the single-element transfer of the request sense buffer is part of the struct scsi_eh_save_cmnd_info, which is allocated on the stack (for at least usb-storage). And, stack isn't DMA-able on all arches. It is not a problem for usb-storage, since the struct scatterlists are processed in code into a series of URBs, so nobody actually does DMA the scatterlist structures. However, I don't know enough about the other HCDs to be certain about them. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpPGNEVQ5NsY.pgp Description: PGP signature
Re: [patchset 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, 10 Sep 2007, Boaz Harrosh wrote: > In motivation to abstract scsi_cmnd members and insulate > drivers/transports from scsi_cmnd internals. The last > place left was the REQUEST_SENSE sequence when done > synchronous, by drivers. > > Also all these drivers would do a use_sg==0 command > invocation, preventing from doing cleanups on these > drivers/transports. So this patchset is left-overs > from Christoph's 2.6.18 cleanups. > > In this patchset I have re-factored scsi_error to > make it possible for drivers to use an abstract > (easy to use, I hope) API for invoking a REQUEST_SENSE > command. The API is declared in scsi/scsi_eh.h This is a good idea, but the implementation has a few problems. A trivial problem is that quilt complains about patch 3, which leaves extra whitespace at the end of line 591 in transport.c. More seriously, why make the caller define a static generic_sense array? Why not put the array in scsi_eh_prep_cmnd(), where it can be used whenever copy_sense is nonzero? The line initializing the sense buffer to zero should be inside the copy_sense conditional block. The code setting the LUN bits in scmd[1] is wrong. It should be like the code in scsi_dispatch_cmd(); i.e., those bits should not be set if the scsi_level is SCSI_UNKNOWN. Finally, a really serious problem. The code sets the buffer length for the REQUEST SENSE command to be the length of scmd->sense_buffer, which is 96. But many USB devices won't work properly unless the requesed sense data length is 18. The appropriate adjustment must be added to transport.c in patch 3. Alan Stern - 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 2/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, 10 Sep 2007 17:23:52 +0300 Boaz Harrosh wrote:
Hi Boaz,
Just a small nit: several of the kernel-doc lines need ':' added.
See below.
> Sign-off-by Boaz Harrosh <[EMAIL PROTECTED]>
> ---
> drivers/scsi/scsi_error.c | 133
> +++--
> include/scsi/scsi_eh.h| 23 -
> 2 files changed, 102 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 0bcfbe5..0327e20 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -590,42 +590,24 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
> }
>
> /**
> - * scsi_send_eh_cmnd - submit a scsi command as part of error recory
> + * scsi_prep_eh_cmnd - Save a scsi command info as part of error recory
> * @scmd: SCSI command structure to hijack
> - * @cmnd: CDB to send
> + * @sesci structure to save restore information
* @sesci:
> + * @cmnd: CDB to send. Can be NULL if no new cmnd is needed
> * @cmnd_size: size in bytes of @cmnd
> - * @timeout:timeout for this request
> * @copy_sense: request sense data if set to 1
> *
> **/
> -static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
> - int cmnd_size, int timeout, int copy_sense)
> +void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
> + struct scsi_eh_save_cmnd_info *sesci, unsigned char *cmnd,
> + int cmnd_size, int copy_sense)
> {
> @@ -676,7 +659,62 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
> unsigned char *cmnd,
>
> +/**
> + * scsi_restore_eh_cmnd - Restore a scsi command info as part of error
> recory
> + * @scmd: SCSI command structure to restore
> + * @sescisaved information from a coresponding call to scsi_prep_eh_cmnd
* @sesci:
> + *
> + * Undo any damage done by above scsi_prep_eh_cmnd().
> + **/
> +void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd,
> + struct scsi_eh_save_cmnd_info *sesci)
> +{
> +}
> +EXPORT_SYMBOL(scsi_eh_restore_cmnd);
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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 2/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
> +void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
> + struct scsi_eh_save_cmnd_info *sesci, unsigned char *cmnd,
> + int cmnd_size, int copy_sense)
I think just struct "struct scsi_eh_save *save" is descriptive enough and
almost fits on a line as well.. Also continuation of the prototype
is indented by two tabs normally.
> +struct scsi_eh_save_cmnd_info {
> + int old_result;
> + enum dma_data_direction old_data_direction;
> + unsigned char old_cmd_len;
> + unsigned char old_cmnd[MAX_COMMAND_SIZE];
> +
> + void* old_buffer;
void *old_buffer;
> + unsigned old_bufflen;
> + unsigned short old_use_sg;
> + int old_resid;
> +
> + struct scatterlist sense_sgl;
> +};
I think you can kill the old prefixes in the struct, they're saved
per defintion.
Except for these cosmetic details the patch looks fine to me,
thanks a lot!
-
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 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/arm/fas216.c |5 ++---
drivers/scsi/arm/fas216.h |3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index fb5f202..d80702b 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, struct
scsi_cmnd *SCpnt,
* the upper layers to process. This would have been set
* correctly by fas216_std_done.
*/
+ scsi_eh_restore_cmnd(SCpnt, &info->sesci);
SCpnt->scsi_done(SCpnt);
}
@@ -2103,6 +2104,7 @@ request_sense:
if (SCpnt->cmnd[0] == REQUEST_SENSE)
goto done;
+ scsi_eh_prep_cmnd(SCpnt, &info->sesci, NULL, 0, 1);
fas216_log_target(info, LOG_CONNECT, SCpnt->device->id,
"requesting sense");
memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd));
@@ -2117,9 +2119,6 @@ request_sense:
SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer);
SCpnt->SCp.Message = 0;
SCpnt->SCp.Status = 0;
- SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer);
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
- SCpnt->use_sg = 0;
SCpnt->tag = 0;
SCpnt->host_scribble = (void *)fas216_rq_sns_done;
diff --git a/drivers/scsi/arm/fas216.h b/drivers/scsi/arm/fas216.h
index 00e5f05..8449416 100644
--- a/drivers/scsi/arm/fas216.h
+++ b/drivers/scsi/arm/fas216.h
@@ -16,6 +16,8 @@
#define NO_IRQ 255
#endif
+#include
+
#include "queue.h"
#include "msgqueue.h"
@@ -311,6 +313,7 @@ typedef struct {
/* miscellaneous */
int internal_done; /* flag to indicate
request done */
+ struct scsi_eh_save_cmnd_info *sesci; /* holds request sense
restore info */
unsigned long magic_end;
} FAS216_Info;
--
1.5.3.1
-
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 4/5] NCR5380: Use scsi_eh API for REQUEST_SENSE invocation
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/NCR5380.c | 25 +++--
drivers/scsi/NCR5380.h |7 +++
drivers/scsi/atari_NCR5380.c | 25 ++---
drivers/scsi/sun3_NCR5380.c | 20 +---
4 files changed, 37 insertions(+), 40 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index f8e449a..1ca3727 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -1542,9 +1542,7 @@ part2:
hostdata->connected = cmd;
hostdata->busy[cmd->device->id] |= (1 << cmd->device->lun);
- if (cmd->SCp.ptr != (char *)cmd->sense_buffer) {
- initialize_SCp(cmd);
- }
+ initialize_SCp(cmd);
return 0;
@@ -2280,19 +2278,18 @@ static void NCR5380_information_transfer(struct
Scsi_Host *instance) {
cmd->result = (cmd->result &
0x00) | (DID_ERROR << 16);
#ifdef AUTOSENSE
+ if ((cmd->cmnd[0] == REQUEST_SENSE) &&
+ hostdata->sesci.old_cmd_len) {
+ scsi_eh_restore_cmnd(cmd,
&hostdata->sesci);
+ hostdata->sesci.old_cmd_len = 0
;
+ }
+
if ((cmd->cmnd[0] != REQUEST_SENSE) &&
(status_byte(cmd->SCp.Status) == CHECK_CONDITION)) {
+ unsigned char cmnd[6] =
{REQUEST_SENSE ,0 ,0 ,0 ,0 ,0};
+ scsi_eh_prep_cmnd(cmd,
&hostdata->sesci, cmnd,
+
sizeof(cmnd), 1);
+
dprintk(NDEBUG_AUTOSENSE,
("scsi%d : performing request sense\n", instance->host_no));
- cmd->cmnd[0] = REQUEST_SENSE;
- cmd->cmnd[1] &= 0xe0;
- cmd->cmnd[2] = 0;
- cmd->cmnd[3] = 0;
- cmd->cmnd[4] =
sizeof(cmd->sense_buffer);
- cmd->cmnd[5] = 0;
-
- cmd->SCp.buffer = NULL;
- cmd->SCp.buffers_residual = 0;
- cmd->SCp.ptr = (char *)
cmd->sense_buffer;
- cmd->SCp.this_residual =
sizeof(cmd->sense_buffer);
LIST(cmd,
hostdata->issue_queue);
cmd->host_scribble = (unsigned
char *)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index bccf13f..73855fc 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -30,6 +30,10 @@
#include
+#ifdef AUTOSENSE
+#include
+#endif
+
#define NCR5380_PUBLIC_RELEASE 7
#define NCR53C400_PUBLIC_RELEASE 2
@@ -281,6 +285,9 @@ struct NCR5380_hostdata {
unsigned pendingr;
unsigned pendingw;
#endif
+#ifdef AUTOSENSE
+ struct scsi_eh_save_cmnd_info sesci;
+#endif
};
#ifdef __KERNEL__
diff --git a/drivers/scsi/atari_NCR5380.c b/drivers/scsi/atari_NCR5380.c
index 03dbe60..a4bdd4c 100644
--- a/drivers/scsi/atari_NCR5380.c
+++ b/drivers/scsi/atari_NCR5380.c
@@ -2235,24 +2235,19 @@ static void NCR5380_information_transfer(struct
Scsi_Host *instance)
cmd->result = (cmd->result &
0x00) | (DID_ERROR << 16);
#ifdef AUTOSENSE
+ if ((cmd->cmnd[0] == REQUEST_SENSE) &&
+ hostdata->sesci.old_cmd_len) {
+ scsi_eh_restore_cmnd(cmd,
&hostdata->sesci);
+ hostdata->sesci.old_cmd_len = 0
;
+ }
+
if ((cmd->cmnd[0] != REQUEST_SENSE) &&
(status_byte(cmd->SCp.Status) ==
CHECK_CONDITION)) {
+ unsigned char cmnd[6] =
{REQUEST_SENSE ,0 ,0 ,0 ,0 ,0};
+ scsi_eh_prep_cmnd(cmd,
&hostdata->sesci, cmnd,
+
sizeof(cmnd), 1);
+
ASEN_PRINTK("scsi%d: performing
request sense\n", HOSTNO);
- cmd->cmnd[0] = REQUEST_SENSE;
- cmd->cmnd[1]
[PATCH 3/5] usb: transport.c use scsi_eh API in REQUEST_SENSE execution
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/usb/storage/transport.c | 51 ++
1 files changed, 8 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 323293a..92dec34 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -50,7 +50,7 @@
#include
#include
-#include
+#include
#include
#include "usb.h"
@@ -580,62 +580,27 @@ void usb_stor_invoke_transport(struct scsi_cmnd *srb,
struct us_data *us)
/* Now, if we need to do the auto-sense, let's do it */
if (need_auto_sense) {
int temp_result;
- void* old_request_buffer;
- unsigned short old_sg;
- unsigned old_request_bufflen;
- unsigned char old_sc_data_direction;
- unsigned char old_cmd_len;
- unsigned char old_cmnd[MAX_COMMAND_SIZE];
- int old_resid;
+ struct scsi_eh_save_cmnd_info sesci;
+ static unsigned char generic_sense[6] =
+ {REQUEST_SENSE, 0, 0, 0, 0, 0};
US_DEBUGP("Issuing auto-REQUEST_SENSE\n");
- /* save the old command */
- memcpy(old_cmnd, srb->cmnd, MAX_COMMAND_SIZE);
- old_cmd_len = srb->cmd_len;
-
- /* set the command and the LUN */
- memset(srb->cmnd, 0, MAX_COMMAND_SIZE);
- srb->cmnd[0] = REQUEST_SENSE;
- srb->cmnd[1] = old_cmnd[1] & 0xE0;
- srb->cmnd[4] = 18;
-
+ scsi_eh_prep_cmnd(srb, &sesci, generic_sense,
+ sizeof(generic_sense), 1);
+
/* FIXME: we must do the protocol translation here */
if (us->subclass == US_SC_RBC || us->subclass == US_SC_SCSI)
srb->cmd_len = 6;
else
srb->cmd_len = 12;
- /* set the transfer direction */
- old_sc_data_direction = srb->sc_data_direction;
- srb->sc_data_direction = DMA_FROM_DEVICE;
-
- /* use the new buffer we have */
- old_request_buffer = srb->request_buffer;
- srb->request_buffer = us->sensebuf;
-
- /* set the buffer length for transfer */
- old_request_bufflen = srb->request_bufflen;
- srb->request_bufflen = US_SENSE_SIZE;
-
- /* set up for no scatter-gather use */
- old_sg = srb->use_sg;
- srb->use_sg = 0;
-
/* issue the auto-sense command */
- old_resid = srb->resid;
srb->resid = 0;
temp_result = us->transport(us->srb, us);
/* let's clean up right away */
- memcpy(srb->sense_buffer, us->sensebuf, US_SENSE_SIZE);
- srb->resid = old_resid;
- srb->request_buffer = old_request_buffer;
- srb->request_bufflen = old_request_bufflen;
- srb->use_sg = old_sg;
- srb->sc_data_direction = old_sc_data_direction;
- srb->cmd_len = old_cmd_len;
- memcpy(srb->cmnd, old_cmnd, MAX_COMMAND_SIZE);
+ scsi_eh_restore_cmnd(srb, &sesci);
if (test_bit(US_FLIDX_TIMED_OUT, &us->flags)) {
US_DEBUGP("-- auto-sense aborted\n");
--
1.5.3.1
-
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 2/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
- Drivers/transports that want to send a synchronous REQUEST_SENSE command
as part of their .queuecommand sequence, have 2 new API's that facilitate
in doing so and abstract them from scsi-ml internals.
void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
struct scsi_eh_save_cmnd_info *sesci, unsigned char *cmnd,
int cmnd_size, int copy_sense) -
Will hijack a command and prepare it for request sense if needed.
And will save any later needed info into a scsi_eh_save_cmnd_info
structure.
void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd,
struct scsi_eh_save_cmnd_info *sesci);
Will undo any changes done to a command by above function. Making
it ready for completion.
- Re-factor scsi_send_eh_cmnd to use above APIs
Sign-off-by Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_error.c | 133 +++--
include/scsi/scsi_eh.h| 23 -
2 files changed, 102 insertions(+), 54 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 0bcfbe5..0327e20 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -590,42 +590,24 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd)
}
/**
- * scsi_send_eh_cmnd - submit a scsi command as part of error recory
+ * scsi_prep_eh_cmnd - Save a scsi command info as part of error recory
* @scmd: SCSI command structure to hijack
- * @cmnd: CDB to send
+ * @sesci structure to save restore information
+ * @cmnd: CDB to send. Can be NULL if no new cmnd is needed
* @cmnd_size: size in bytes of @cmnd
- * @timeout:timeout for this request
* @copy_sense: request sense data if set to 1
*
- * This function is used to send a scsi command down to a target device
- * as part of the error recovery process. If @copy_sense is 0 the command
- * sent must be one that does not transfer any data. If @copy_sense is 1
- * the command must be REQUEST_SENSE and this functions copies out the
- * sense buffer it got into @scmd->sense_buffer.
- *
- * Return value:
- *SUCCESS or FAILED or NEEDS_RETRY
+ * This function is used to save a scsi command information before re-execution
+ * as part of an error recovery process. If @copy_sense is 0 the command
+ * given must be one that does not transfer any data. If @copy_sense is 1
+ * the command must be REQUEST_SENSE and this functions sets up the
+ * command buffers to be read into @scmd->sense_buffer.
**/
-static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd,
-int cmnd_size, int timeout, int copy_sense)
+void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd,
+ struct scsi_eh_save_cmnd_info *sesci, unsigned char *cmnd,
+ int cmnd_size, int copy_sense)
{
struct scsi_device *sdev = scmd->device;
- struct Scsi_Host *shost = sdev->host;
- DECLARE_COMPLETION_ONSTACK(done);
- unsigned long timeleft;
- unsigned long flags;
-
- unsigned char old_cmd_len;
- unsigned char old_cmnd[MAX_COMMAND_SIZE];
- enum dma_data_direction old_data_direction;
- unsigned old_bufflen;
- void *old_buffer;
- unsigned short old_use_sg;
- int old_resid;
- int old_result;
-
- struct scatterlist sgl;
- int rtn;
/*
* We need saved copies of a number of fields - this is because
@@ -634,14 +616,14 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_cmd_len = scmd->cmd_len;
- memcpy(old_cmnd, scmd->cmnd, sizeof(scmd->cmnd));
- old_data_direction = scmd->sc_data_direction;
- old_bufflen = scmd->request_bufflen;
- old_buffer = scmd->request_buffer;
- old_use_sg = scmd->use_sg;
- old_resid = scmd->resid;
- old_result = scmd->result;
+ sesci->old_cmd_len = scmd->cmd_len;
+ memcpy(sesci->old_cmnd, scmd->cmnd, sizeof(scmd->cmnd));
+ sesci->old_data_direction = scmd->sc_data_direction;
+ sesci->old_bufflen = scmd->request_bufflen;
+ sesci->old_buffer = scmd->request_buffer;
+ sesci->old_use_sg = scmd->use_sg;
+ sesci->old_resid = scmd->resid;
+ sesci->old_result = scmd->result;
if (cmnd) {
memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
@@ -650,14 +632,15 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
}
if (copy_sense) {
- sg_init_one(&sgl, scmd->sense_buffer,
+ struct scatterlist* sgl = &sesci->sense_sgl;
+ sg_init_one(sgl, scmd->sense_buffer,
sizeof(scmd->sense_buffer));
scmd->sc_data_direction = DMA_FROM_DEVICE;
- scmd->request_bufflen = sgl.length;
- scmd->request_buffer = &sgl;
+ scmd->request_bufflen = sgl
[PATCH 1/5] scsi_error: code cleanup before refactoring of scsi_send_eh_cmnd()
- regrouped variables for easier reviewing of next patch
- Support of cmnd==NULL in call to scsi_send_eh_cmnd()
- In the REQUEST_SENSE case set cmnd[4] to the size of
sense_buffer. It was previously set by caller but needed
to be in sync with sense_buffer size.
- Also save/restore resid of faild command.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_error.c | 37 +++--
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c8e351f..0bcfbe5 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -611,17 +611,20 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
{
struct scsi_device *sdev = scmd->device;
struct Scsi_Host *shost = sdev->host;
- int old_result = scmd->result;
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
unsigned long flags;
- struct scatterlist sgl;
+
+ unsigned char old_cmd_len;
unsigned char old_cmnd[MAX_COMMAND_SIZE];
enum dma_data_direction old_data_direction;
- unsigned short old_use_sg;
- unsigned char old_cmd_len;
unsigned old_bufflen;
void *old_buffer;
+ unsigned short old_use_sg;
+ int old_resid;
+ int old_result;
+
+ struct scatterlist sgl;
int rtn;
/*
@@ -631,15 +634,20 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
* we will need to restore these values prior to running the actual
* command.
*/
- old_buffer = scmd->request_buffer;
- old_bufflen = scmd->request_bufflen;
+ old_cmd_len = scmd->cmd_len;
memcpy(old_cmnd, scmd->cmnd, sizeof(scmd->cmnd));
old_data_direction = scmd->sc_data_direction;
- old_cmd_len = scmd->cmd_len;
+ old_bufflen = scmd->request_bufflen;
+ old_buffer = scmd->request_buffer;
old_use_sg = scmd->use_sg;
+ old_resid = scmd->resid;
+ old_result = scmd->result;
- memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
- memcpy(scmd->cmnd, cmnd, cmnd_size);
+ if (cmnd) {
+ memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
+ memcpy(scmd->cmnd, cmnd, cmnd_size);
+ scmd->cmd_len = COMMAND_SIZE(scmd->cmnd[0]);
+ }
if (copy_sense) {
sg_init_one(&sgl, scmd->sense_buffer,
@@ -649,6 +657,7 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
scmd->request_bufflen = sgl.length;
scmd->request_buffer = &sgl;
scmd->use_sg = 1;
+ scmd->cmnd[4] = sgl.length;
} else {
scmd->request_buffer = NULL;
scmd->request_bufflen = 0;
@@ -657,7 +666,6 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
}
scmd->underflow = 0;
- scmd->cmd_len = COMMAND_SIZE(scmd->cmnd[0]);
if (sdev->scsi_level <= SCSI_2)
scmd->cmnd[1] = (scmd->cmnd[1] & 0x1f) |
@@ -716,12 +724,13 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
/*
* Restore original data
*/
- scmd->request_buffer = old_buffer;
- scmd->request_bufflen = old_bufflen;
+ scmd->cmd_len = old_cmd_len;
memcpy(scmd->cmnd, old_cmnd, sizeof(scmd->cmnd));
scmd->sc_data_direction = old_data_direction;
- scmd->cmd_len = old_cmd_len;
+ scmd->request_bufflen = old_bufflen;
+ scmd->request_buffer = old_buffer;
scmd->use_sg = old_use_sg;
+ scmd->resid = old_resid;
scmd->result = old_result;
return rtn;
}
@@ -738,7 +747,7 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
static int scsi_request_sense(struct scsi_cmnd *scmd)
{
static unsigned char generic_sense[6] =
- {REQUEST_SENSE, 0, 0, 0, 252, 0};
+ {REQUEST_SENSE, 0, 0, 0, 0, 0};
return scsi_send_eh_cmnd(scmd, generic_sense, 6, SENSE_TIMEOUT, 1);
}
--
1.5.3.1
-
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
[patchset 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
In motivation to abstract scsi_cmnd members and insulate drivers/transports from scsi_cmnd internals. The last place left was the REQUEST_SENSE sequence when done synchronous, by drivers. Also all these drivers would do a use_sg==0 command invocation, preventing from doing cleanups on these drivers/transports. So this patchset is left-overs from Christoph's 2.6.18 cleanups. In this patchset I have re-factored scsi_error to make it possible for drivers to use an abstract (easy to use, I hope) API for invoking a REQUEST_SENSE command. The API is declared in scsi/scsi_eh.h [patch 1/5] scsi_error: code cleanup before refactoring of scsi_send_eh_cmnd() Move some code around and add new fixtures here. So next patch is left a Mechanical breakup of code. [patch 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE Here new API is introduced in scsi/scsi_eh.h and mechanical move of code to the new functions. [PATCH 3/5] usb: transport.c use scsi_eh API in REQUEST_SENSE execution Use above API for drivers/usb/storage/transport.c. Now that last User of use_sg==0, we can do the USB storage cleanups. [PATCH 4/5] NCR5380: Use scsi_eh API for REQUEST_SENSE invocation All NCR5380 family of drivers used to send a REQUEST_SENSE command. [PATCH 5/5] arm: fas216 Use scsi_eh API for REQUEST_SENSE invocation drivers/scsi/arm/fas216.c need change also. Please Test as much as possible, and report any problems/differences. Boaz Harrosh - 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: sata & scsi suggestion for make menuconfig
On 09/10/2007 08:38 AM, Stefan Richter wrote: Nevertheless we should try to arrange the menus in a way that makes sense to as many people as possible. The difficulty is, different environments call for different menu layouts, as your previous example of SATA DVD-only boxes demonstrates. However, liberal usage of 'select' is not the ultimate solution to create menus that work for more people. Just one problem with select is that it works behind the back of the people configuring kernels (unless they use an UI with debug options turned on) --- they have less control, they are less informed. ATA already 'select's SCSI. What do we gain from hiding the fact that Linux' SCSI option is not just for those 50-wire ribbons (which people still think SCSI stands for) but is a very central Linux subsystem for even more than what complies to the SCSI family of standards? 'select' should really be limited to switch on small library-like code without further dependencies or requirements. SCSI, together with its upper layer options, is not of this kind of library. We should think about order and grouping of prompts and the labels of prompts (there were already suggestions in this discussion) before we resort to 'select' --- or even worse, select options unconditionally which are not always necessary to be enabled. A pro pos grouping of options --- consider how options for another central subsystem are laid out: Networking Networking options ... TCP/IP networking ... ... Device Drivers ... Network device support ... Ethernet (10 or 100MBit) ... ... This also happens to reflect the layout of sources in directories, and the current SCSI menu layout is close to source layout too --- but it doesn't have to be that way. If someone's keen on really restructuring these things -- in this analogy: Storage Storage Options ... Disk Optical ... ... Device Drivers ... Storage Support ... IDE PATA SATA SCSI USB FW ... ... (sound is an example where both in the menus and the tree everything is kept under one top-level sound/ directory, not sound/ and drivers/sound/ as for networking -- opinions may vary which one's better I guess). This is just config menus -- on a source code level, it would also make sense at least at some point to introduce "storage/" alongside net/ and sound/ and move things around I guess. Rene. - 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: 2.6.22 oops kernel BUG at block/elevator.c:366!
On Thu, 30 Aug 2007 13:29:37 +0200 Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
wrote:
> On Wednesday 29 of August 2007, Jens Axboe wrote:
> > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > > > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > > > > I guess I should sent these here since it looks like not scsi bug
> > > > > > > anyway.
> > > > > >
> > > > > > It's stex, right? It seems to have some issues with multiple
> > > > > > completions of commands, which craps out the block layer of course.
> > > > >
> > > > > Yes, stex. I'm staying with 2.6.19 in that case since it works fine
> > > > > in that version.
> > > > >
> > > > > So scsi bug ... 8-)
> > > >
> > > > And you based that conclusion on what exactly?
Could be viewed as a scsi deficiency at least. Is it unheard of for
"independent" queues to have shared resources? If so, then yeah, perhaps
some driver-private locking as James suggested is appropriate. But if
other drivers face similar problems then perhaps it is something which scsi
core should offer support for.
But whatever. The situation is that Ed suggested a fix eight months ago,
James suggested enhancements and afaict nobody did anything more, and
machines which use this driver are still crashing.
OK, Ed's email client breaks message threading, so you need to hyperjump to
a "different" thread a few days later, in which Ed points out that qla4xxx
also has a shared tag queue.
Ed's email client proceeds to splatter the discussion all over the Jan 2007
archive. Ed finds a possible bug in qla4xxx. Jens proposes a block patch.
Ed disagrees, Jeff agrees with Ed, discussion dies, driver still
crashing..
> > > Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)
> >
> > Yep indeed, I thought you meant that it was a scsi bug (and not an stex
> > one). You could try and copy the 2.6.19 stex driver into 2.6.20 and see
> > if that works, though.
>
> Looks like this bug is known for months :-(
>
> Ed Lin pointed to http://lkml.org/lkml/2007/1/23/268 with possible patch
> (that
> unfortunately serialises access to storage devices, well...)
>
> There is also: http://bugzilla.kernel.org/show_bug.cgi?id=7842
>
> I'm running 2.6.22 with that patch now, did huge (few hours) rsync that
> previously caused oopses and now everything works properly.
>
> Can we get some form of this patch into Linus tree?
Here's Ed's patch again. As a suboptimal driver is better than a crashing
one, perhaps we should merge it until we can sort out something better?
From: "Ed Lin" <[EMAIL PROTECTED]>
The block layer uses lock to protect request queue. Every scsi device has
a unique request queue, and queue lock is the default lock in struct
request_queue. This is good for normal cases. But for a host with shared
queue tag (e.g. stex controllers), a queue lock per device means the
shared queue tag is not protected when multiple devices are accessed at a
same time. This patch is a simple fix for this situation by introducing a
host queue lock to protect shared queue tag. Without this patch we will
see various kernel panics (including the BUG() and kernel errors in
blk_queue_start_tag and blk_queue_end_tag of ll_rw_blk.c) when accessing
another in smp kernels).
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |2 +-
drivers/scsi/stex.c |2 ++
include/scsi/scsi_host.h |3 +++
3 files changed, 6 insertions(+), 1 deletion(-)
diff -puN
drivers/scsi/scsi_lib.c~scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host
drivers/scsi/scsi_lib.c
---
a/drivers/scsi/scsi_lib.c~scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host
+++ a/drivers/scsi/scsi_lib.c
@@ -1670,7 +1670,7 @@ struct request_queue *__scsi_alloc_queue
{
struct request_queue *q;
- q = blk_init_queue(request_fn, NULL);
+ q = blk_init_queue(request_fn, shost->req_q_lock);
if (!q)
return NULL;
diff -puN
drivers/scsi/stex.c~scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host
drivers/scsi/stex.c
---
a/drivers/scsi/stex.c~scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host
+++ a/drivers/scsi/stex.c
@@ -1234,6 +1234,8 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
+ spin_lock_init(&host->__req_q_lock);
+ host->req_q_lock = &host->__req_q_lock;
err = scsi_init_shared_tag_map(host, host->can_queue);
if (err) {
printk(KERN_ERR DRV_NAME "(%s): init shared queue failed\n",
diff -puN
include/scsi/scsi_host.h~scsi-use-lock-per-host-instead-of-
