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

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

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

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

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

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

[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

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

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

[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

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

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

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.