Re: [PATCH 4/6] bsg: add sg_io_v4 structure

2006-12-20 Thread Jens Axboe 
On Wed, Dec 20 2006, FUJITA Tomonori wrote:
 This patch adds sg_io_v4 structure that Doug proposed last month.
 
 There's one major change from the RFC. I dropped iovec, which needs
 compat stuff. The bsg code simply calls blk_rq_map_user against
 dout_xferp/din_xferp. So if possible, the page frames are directly
 mapped. If not possible, the block layer allocates new page frames and
 does memory copies.
 
 Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
 ---
  include/linux/bsg.h |   43 +++
  1 files changed, 43 insertions(+), 0 deletions(-)
 
 diff --git a/include/linux/bsg.h b/include/linux/bsg.h
 index dc0d728..0d212cc 100644
 --- a/include/linux/bsg.h
 +++ b/include/linux/bsg.h
 @@ -1,6 +1,47 @@
  #ifndef BSG_H
  #define BSG_H
  
 +struct sg_io_v4 {
 + int32_t guard;  /* [i] 'Q' to differentiate from v3 */
 + uint32_t protocol;  /* [i] 0 - SCSI ,  */

I prefer using the u32 types and so on for explicitly sized variables.
I'll make that change.

-- 
Jens Axboe

-
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 5/6] bsg: replace SG v3 with SG v4

2006-12-20 Thread Jens Axboe 
On Wed, Dec 20 2006, FUJITA Tomonori wrote:
 This patch replaces SG v3 in bsg with SG v4 (except for SG_IO).
 
 Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
 ---
  block/bsg.c |  198 
 ---
  1 files changed, 121 insertions(+), 77 deletions(-)
 
 diff --git a/block/bsg.c b/block/bsg.c
 index 53a09a5..6d139d2 100644
 --- a/block/bsg.c
 +++ b/block/bsg.c
 @@ -103,8 +103,8 @@ struct bsg_command {
   struct request *rq;
   struct bio *bio;
   int err;
 - struct sg_io_hdr hdr;
 - struct sg_io_hdr __user *uhdr;
 + struct sg_io_v4 hdr;
 + struct sg_io_v4 __user *uhdr;
   char sense[SCSI_SENSE_BUFFERSIZE];
  };
  
 @@ -235,57 +235,82 @@ static struct bsg_command *bsg_get_comma
   return bc;
  }
  
 +static int blk_fill_sgv4_hdr_rq(request_queue_t *q, struct request *rq,
 + struct sg_io_v4 *hdr, int has_write_perm)
 +{
 + memset(rq-cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
 +
 + if (copy_from_user(rq-cmd, (void *)(unsigned long)hdr-request,
 +hdr-request_len))
 + return -EFAULT;

Strange casting, that should be cleaned up. Also reminds me that the
sg_io_v4 header needs proper __user annotation.

-- 
Jens Axboe

-
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 6/6] bsg: add SG_IO to SG v4

2006-12-20 Thread Jens Axboe 
On Wed, Dec 20 2006, FUJITA Tomonori wrote:
 This adds SG_IO support to SG v4.
 
 Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
 ---
  block/bsg.c |   23 +--
  1 files changed, 21 insertions(+), 2 deletions(-)
 
 diff --git a/block/bsg.c b/block/bsg.c
 index 6d139d2..9dc5d36 100644
 --- a/block/bsg.c
 +++ b/block/bsg.c
 @@ -945,8 +945,27 @@ bsg_ioctl(struct inode *inode, struct fi
   void __user *uarg = (void __user *) arg;
   return scsi_cmd_ioctl(file, bd-disk, cmd, uarg);
   }
 - case SG_IO:
 - return -EINVAL;
 + case SG_IO: {
 + struct request *rq;
 + struct bio *bio;
 + struct sg_io_v4 hdr;
 +
 + if (copy_from_user(hdr, uarg, sizeof(hdr)))
 + return -EFAULT;
 +
 + rq = bsg_map_hdr(bd, hdr);
 + if (IS_ERR(rq))
 + return PTR_ERR(rq);
 +
 + bio = rq-bio;

Pointless assignment. In fact the bio can be completely removed.

 + blk_execute_rq(bd-queue, bd-disk, rq, 0);
 + blk_complete_sgv4_hdr_rq(rq, hdr, bio);
 +
 + if (copy_to_user(uarg, hdr, sizeof(hdr)))
 + return -EFAULT;
 + else
 + return 0;

Kill the else.

I'll make both changes. Applying your series as-is, and making the
changes I noted in the previous mails.

-- 
Jens Axboe

-
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 6/6] bsg: add SG_IO to SG v4

2006-12-20 Thread Jens Axboe 
On Wed, Dec 20 2006, Jens Axboe wrote:
 On Wed, Dec 20 2006, FUJITA Tomonori wrote:
  This adds SG_IO support to SG v4.
  
  Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
  ---
   block/bsg.c |   23 +--
   1 files changed, 21 insertions(+), 2 deletions(-)
  
  diff --git a/block/bsg.c b/block/bsg.c
  index 6d139d2..9dc5d36 100644
  --- a/block/bsg.c
  +++ b/block/bsg.c
  @@ -945,8 +945,27 @@ bsg_ioctl(struct inode *inode, struct fi
  void __user *uarg = (void __user *) arg;
  return scsi_cmd_ioctl(file, bd-disk, cmd, uarg);
  }
  -   case SG_IO:
  -   return -EINVAL;
  +   case SG_IO: {
  +   struct request *rq;
  +   struct bio *bio;
  +   struct sg_io_v4 hdr;
  +
  +   if (copy_from_user(hdr, uarg, sizeof(hdr)))
  +   return -EFAULT;
  +
  +   rq = bsg_map_hdr(bd, hdr);
  +   if (IS_ERR(rq))
  +   return PTR_ERR(rq);
  +
  +   bio = rq-bio;
 
 Pointless assignment. In fact the bio can be completely removed.

  +   blk_execute_rq(bd-queue, bd-disk, rq, 0);
  +   blk_complete_sgv4_hdr_rq(rq, hdr, bio);

My mistake, the bio assignment is fine and of course needed.

-- 
Jens Axboe

-
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: [Bugme-new] [Bug 7717] New: Tapes unreadable after unload

2006-12-20 Thread Andrew Morton 

(please respond via emailed reply-to-all)

On Wed, 20 Dec 2006 02:31:18 -0800
[EMAIL PROTECTED] wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=7717
 
Summary: Tapes unreadable after unload
 Kernel Version: tested 2.6.17 through 2.6.29 with various results

I assume that means 2.6.17 and 2.6.19 failed.

 Status: NEW
   Severity: blocking
  Owner: [EMAIL PROTECTED]
  Submitter: [EMAIL PROTECTED]
 
 
 Most recent kernel where this bug did *NOT* occur: 2.6.19

And that means that 2.6.19 did not fail.

Please clarify.

 Distribution: Slackware/Fedora
 Hardware Environment: HP 530, HP Dl380
 Software Environment: tar, mtx
 Problem Description: Doing a tar backup works well. Data is written and is
 readable. Binary restore comparison is ok. After unload/load the tape produces
 Input/output errors. The tape is unreadable with working kernels too. Any
 attempt to restore data from faulty tapes were in vain until now. 
 
 Steps to reproduce:
 tar cvf /dev/st0 /path/to/something
 mtx -f /dev/sg1 unload
 mtx -f /dev/sg1 load X
 tar tvf /dev/st0
 
 tar output:
 tar: /dev/st0: Cannot read: Input/output error
 tar: At beginning of tape, quitting now
 tar: Error is not recoverable: exiting now
 
 All read() attempts fail after 42 bytes. (I can attach those 42 bytes if they
 are of any help).

-
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: [Bugme-new] [Bug 7717] New: Tapes unreadable after unload

2006-12-20 Thread Bgs 



Andrew Morton wrote:

Kernel Version: tested 2.6.17 through 2.6.29 with various results


I assume that means 2.6.17 and 2.6.19 failed.


I tested it with 2.6.17 through 2.6.19 including subversions (like 
2.6.17.3 and such). I found that 2.6.19 works and also found two other 
version in the line that work. The other about 4-5 version that I have 
tried, did not work. The works/not works is not consistent as I found 
2.6.17.x kernel that did work and 2.6.18 that did not.


If the problem is known, I'd also like to know what the problem was as I 
need to recover two tapes that are inaccessible now. (LTO3 400GB tapes 
so there was no time to erase all data even if something near the 
beginning of the tape is bad).




Status: NEW
  Severity: blocking
 Owner: [EMAIL PROTECTED]
 Submitter: [EMAIL PROTECTED]


Most recent kernel where this bug did *NOT* occur: 2.6.19


And that means that 2.6.19 did not fail.


Right now I'm using 2.6.19 and it works. Haven't tried it with 2.6.19.1 
yet though.

-
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.6.20-rc1 10/10] dec_esp: Driver model for the PMAZ-A

2006-12-20 Thread Maciej W. Rozycki 
 This is a set of changes that converts the PMAZ-A support to the driver
model.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 The use of the driver model required switching to the hotplug SCSI 
initialization model, which in turn required a change to the core NCR53C9x 
driver.  I decided not to break all the frontend drivers and introduced an 
additional parameter for esp_allocate() to select between the old and the 
new model.  I hope this is OK, but I would be fine with converting 
NCR53C9x to the new model unconditionally as long as I do not have to fix 
all the other frontends (OK, perhaps I could do some of them ;-) ).

 Please apply.

  Maciej

patch-2.6.20-rc1-tc-pmaz-a-5
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.c 
linux-2.6.20-rc1/drivers/scsi/NCR53C9x.c
--- linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.c  2006-12-14 
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/NCR53C9x.c2006-12-18 21:29:38.0 
+
@@ -528,12 +528,16 @@ void esp_bootup_reset(struct NCR_ESP *es
 /* Allocate structure and insert basic data such as SCSI chip frequency
  * data and a pointer to the device
  */
-struct NCR_ESP* esp_allocate(struct scsi_host_template *tpnt, void *esp_dev)
+struct NCR_ESP* esp_allocate(struct scsi_host_template *tpnt, void *esp_dev,
+int hotplug)
 {
struct NCR_ESP *esp, *elink;
struct Scsi_Host *esp_host;
 
-   esp_host = scsi_register(tpnt, sizeof(struct NCR_ESP));
+   if (hotplug)
+   esp_host = scsi_host_alloc(tpnt, sizeof(struct NCR_ESP));
+   else
+   esp_host = scsi_register(tpnt, sizeof(struct NCR_ESP));
if(!esp_host)
panic(Cannot register ESP SCSI host);
esp = (struct NCR_ESP *) esp_host-hostdata;
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.h 
linux-2.6.20-rc1/drivers/scsi/NCR53C9x.h
--- linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.h  2006-12-14 
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/NCR53C9x.h2006-12-18 21:29:38.0 
+
@@ -652,7 +652,7 @@ extern int nesps, esps_in_use, esps_runn
 
 /* External functions */
 extern void esp_bootup_reset(struct NCR_ESP *esp, struct ESP_regs *eregs);
-extern struct NCR_ESP *esp_allocate(struct scsi_host_template *, void *);
+extern struct NCR_ESP *esp_allocate(struct scsi_host_template *, void *, int);
 extern void esp_deallocate(struct NCR_ESP *);
 extern void esp_release(void);
 extern void esp_initialize(struct NCR_ESP *);
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/blz1230.c 
linux-2.6.20-rc1/drivers/scsi/blz1230.c
--- linux-2.6.20-rc1.macro/drivers/scsi/blz1230.c   2006-12-14 
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/blz1230.c 2006-12-18 21:29:38.0 
+
@@ -121,7 +121,8 @@ int __init blz1230_esp_detect(struct scs
 */
address = ZTWO_VADDR(board);
eregs = (struct ESP_regs *)(address + REAL_BLZ1230_ESP_ADDR);
-   esp = esp_allocate(tpnt, (void *)board+REAL_BLZ1230_ESP_ADDR);
+   esp = esp_allocate(tpnt, (void *)board + REAL_BLZ1230_ESP_ADDR,
+  0);
 
esp_write(eregs-esp_cfg1, (ESP_CONFIG1_PENABLE | 7));
udelay(5);
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/blz2060.c 
linux-2.6.20-rc1/drivers/scsi/blz2060.c
--- linux-2.6.20-rc1.macro/drivers/scsi/blz2060.c   2006-12-14 
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/blz2060.c 2006-12-18 21:29:38.0 
+
@@ -100,7 +100,7 @@ int __init blz2060_esp_detect(struct scs
unsigned long board = z-resource.start;
if (request_mem_region(board+BLZ2060_ESP_ADDR,
   sizeof(struct ESP_regs), NCR53C9x)) {
-   esp = esp_allocate(tpnt, (void *)board+BLZ2060_ESP_ADDR);
+   esp = esp_allocate(tpnt, (void *)board + BLZ2060_ESP_ADDR, 0);
 
/* Do command transfer with programmed I/O */
esp-do_pio_cmds = 1;
diff -up --recursive --new-file 
linux-2.6.20-rc1.macro/drivers/scsi/cyberstorm.c 
linux-2.6.20-rc1/drivers/scsi/cyberstorm.c
--- linux-2.6.20-rc1.macro/drivers/scsi/cyberstorm.c2006-12-14 
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/cyberstorm.c  2006-12-18 21:29:38.0 
+
@@ -126,7 +126,7 @@ int __init cyber_esp_detect(struct scsi_
   sizeof(struct ESP_regs));
return 0;
}
-   esp = esp_allocate(tpnt, (void *)board+CYBER_ESP_ADDR);
+   esp = esp_allocate(tpnt, (void *)board + CYBER_ESP_ADDR, 0);
 
/* Do command transfer with programmed I/O */
esp-do_pio_cmds = 1;
diff -up --recursive --new-file 
linux-2.6.20-rc1.macro/drivers/scsi/cyberstormII.c

Re: [Bugme-new] [Bug 7717] New: Tapes unreadable after unload

2006-12-20 Thread Kai Makisara 
On Wed, 20 Dec 2006, Andrew Morton wrote:

 
 (please respond via emailed reply-to-all)
 
 On Wed, 20 Dec 2006 02:31:18 -0800
 [EMAIL PROTECTED] wrote:
 
  http://bugzilla.kernel.org/show_bug.cgi?id=7717
  
 Summary: Tapes unreadable after unload
  Kernel Version: tested 2.6.17 through 2.6.29 with various results
 
 I assume that means 2.6.17 and 2.6.19 failed.
 
  Status: NEW
Severity: blocking
   Owner: [EMAIL PROTECTED]
   Submitter: [EMAIL PROTECTED]
  
  
  Most recent kernel where this bug did *NOT* occur: 2.6.19
 
 And that means that 2.6.19 did not fail.
 
 Please clarify.
 
  Distribution: Slackware/Fedora
  Hardware Environment: HP 530, HP Dl380
  Software Environment: tar, mtx
  Problem Description: Doing a tar backup works well. Data is written and is
  readable. Binary restore comparison is ok. After unload/load the tape 
  produces
  Input/output errors. The tape is unreadable with working kernels too. Any
  attempt to restore data from faulty tapes were in vain until now. 
  
  Steps to reproduce:
  tar cvf /dev/st0 /path/to/something
  mtx -f /dev/sg1 unload
  mtx -f /dev/sg1 load X
  tar tvf /dev/st0
  

I tried this with 2.6.19 and the tape was readable. Unfortunately I don't 
have any older kernels around to test. I have not heard about any problem 
like this.

Note that the data becomes unreadable after the tape is touched by mtx 
through sg device, i.e, bypassing st.

  tar output:
  tar: /dev/st0: Cannot read: Input/output error
  tar: At beginning of tape, quitting now
  tar: Error is not recoverable: exiting now
  
Do you find any messages with dmesg or in system log?

  All read() attempts fail after 42 bytes. (I can attach those 42 bytes if 
  they
  are of any help).
 
Interesting byte count :-)

-- 
Kai
-
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 4/6] bsg: add sg_io_v4 structure

2006-12-20 Thread FUJITA Tomonori 
From: Jens Axboe [EMAIL PROTECTED]
Subject: Re: [PATCH 4/6] bsg: add sg_io_v4 structure
Date: Wed, 20 Dec 2006 11:13:14 +0100

 On Wed, Dec 20 2006, FUJITA Tomonori wrote:
  This patch adds sg_io_v4 structure that Doug proposed last month.
  
  There's one major change from the RFC. I dropped iovec, which needs
  compat stuff. The bsg code simply calls blk_rq_map_user against
  dout_xferp/din_xferp. So if possible, the page frames are directly
  mapped. If not possible, the block layer allocates new page frames and
  does memory copies.
  
  Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
  ---
   include/linux/bsg.h |   43 +++
   1 files changed, 43 insertions(+), 0 deletions(-)
  
  diff --git a/include/linux/bsg.h b/include/linux/bsg.h
  index dc0d728..0d212cc 100644
  --- a/include/linux/bsg.h
  +++ b/include/linux/bsg.h
  @@ -1,6 +1,47 @@
   #ifndef BSG_H
   #define BSG_H
   
  +struct sg_io_v4 {
  +   int32_t guard;  /* [i] 'Q' to differentiate from v3 */
  +   uint32_t protocol;  /* [i] 0 - SCSI ,  */
 
 I prefer using the u32 types and so on for explicitly sized variables.
 I'll make that change.

I see though we need to use __u32 instead of u32, don't we?
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] fusion: fibre channel: return DID_ERROR for MPI_IOCSTATUS_SCSI_IOC_TERMINATED

2006-12-20 Thread Michael Reed 
The fibre channel IOC may kill a request for a variety of
reasons, some of which may be recovered by a retry, some of
which are unlikely to be recovered.  Return DID_ERROR
instead of DID_RESET to permit retry of the command,
just not an infinite number of them.

Signed-off-by: Michael Reed [EMAIL PROTECTED]
The fibre channel IOC may kill a request for a variety of
reasons, some of which may be recovered by a retry, some of
which are unlikely to be recovered.  Return DID_ERROR
instead of DID_RESET to permit retry of the command,
just not an infinite number of them.

Signed-off-by: Michael Reed [EMAIL PROTECTED]

--- kdbu/drivers/message/fusion/mptscsih.c	2006-08-04 02:10:22.0 -0500
+++ kdb/drivers/message/fusion/mptscsih.c	2006-12-16 12:54:13.952128107 -0600
@@ -702,9 +702,14 @@ mptscsih_io_done(MPT_ADAPTER *ioc, MPT_F
 	}
 }
 			}
+			else if (ioc-bus_type == FC) {
+/* i/o killed by IOC */
+sc-result = DID_ERROR  16;
+break;
+			}
 
 			/*
-			 * Allow non-SAS  non-NEXUS_LOSS to drop into below code
+			 * Allow non-FC, non-SAS  non-NEXUS_LOSS to drop into below code
 			 */
 
 		case MPI_IOCSTATUS_SCSI_TASK_TERMINATED:	/* 0x0048 */

Re: [PATCH] scsi_execute_async() should add to the tail of the queue

2006-12-20 Thread Steven Hayter 

Dan Aloni wrote:

Hello,

scsi_execute_async() has replaced scsi_do_req() a few versions ago, 
but it also incurred a change of behavior. I noticed that over-queuing 
a SCSI device using that function causes I/Os to be starved from 
low-level queuing for no justified reason.
 
I think it makes much more sense to perserve the original behaviour 
of scsi_do_req() and add the request to the tail of the queue.


As far as I'm aware the way in which scsi_do_req() was to insert at the 
head of the queue, leading to projects like SCST to come up with 
scsi_do_req_fifo() as queuing multiple commands using scsi_do_req() with 
constant head insertion might lead to out of order execution.


Just thought I'd throw some light on the history and what others have 
done in the past.


Steve
-
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] scsi_execute_async() should add to the tail of the queue

2006-12-20 Thread Jeremy Linton 

So instead of adding a parameter, we can make scsi_execute_async()
decide for itself based on the SCSI command, with read/write I/Os
taking the lowest priority.
	This seems like a bad idea, I can come up with a number of cases where 
the priority of a request would better be optimized by a higher level 
subsystem, rather than a simple prioritization based on the command type.


The original suggestion to provide both head and tail insertion options 
seems like the obvious solution, short of a full priority queuing system.





-
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] scsi_execute_async() should add to the tail of the queue

2006-12-20 Thread Dan Aloni 

Steven Hayter wrote:

Dan Aloni wrote:

Hello,

scsi_execute_async() has replaced scsi_do_req() a few versions ago, 
but it also incurred a change of behavior. I noticed that 
over-queuing a SCSI device using that function causes I/Os to be 
starved from low-level queuing for no justified reason.
 
I think it makes much more sense to perserve the original behaviour 
of scsi_do_req() and add the request to the tail of the queue.


As far as I'm aware the way in which scsi_do_req() was to insert at 
the head of the queue, leading to projects like SCST to come up with 
scsi_do_req_fifo() as queuing multiple commands using scsi_do_req() 
with constant head insertion might lead to out of order execution.


Just thought I'd throw some light on the history and what others have 
done in the past.


In Linux 2.4.31 scsi_do_req() still inserts at the tail. This was also 
valid until 2.6.5.
James, is the change you inserted in Linux 2.6.5 still relevant in 2.6 
today?


[EMAIL PROTECTED]
   [PATCH] add device quiescing to the SCSI API
  
   This patch adds the ability to quiesce a SCSI device.  The idea 
is that

   user issued commands (including filesystem ones) would get blocked,
   while mid-layer and device issued ones would be allowed to proceed.
   This is for things like Domain Validation which like to operate 
on an

   otherwise quiet device.
  
   There is one big change: to get all of this to happen correctly,
   scsi_do_req() has to queue on the *head* of the request queue, 
not the
   tail as it was doing previously.  The reason is that deferred 
requests
   block the queue, so anything needing executing after a deferred 
request

   has to go in front of it.  I don't think there are any untoward
   consequences of this.

--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

-
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