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 
lin

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

[PATCH 2.6.20-rc1 01/10] TURBOchannel update to the driver model

2006-12-20 Thread Maciej W. Rozycki 
 This is a set of changes to convert support for the TURBOchannel bus to 
the driver model.  It implements the usual set of calls similar to what 
other bus drivers have: tc_register_driver(), tc_unregister_driver(), etc.  
All the platform-specific bits have been removed and headers from 
asm-mips/dec/ have been merged into linux/tc.h, which should be included 
by drivers.

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

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-tc-sysfs-78
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/MAINTAINERS 
linux-mips-2.6.18-20060920/MAINTAINERS
--- linux-mips-2.6.18-20060920.macro/MAINTAINERS2006-09-20 
04:56:08.0 +
+++ linux-mips-2.6.18-20060920/MAINTAINERS  2006-11-30 01:54:54.0 
+
@@ -2910,6 +2910,11 @@ L:   [EMAIL PROTECTED]
 W: http://vtun.sourceforge.net/tun
 S: Maintained
 
+TURBOCHANNEL SUBSYSTEM
+P: Maciej W. Rozycki
+M: [EMAIL PROTECTED]
+S: Maintained
+
 U14-34F SCSI DRIVER
 P: Dario Ballabio
 M: [EMAIL PROTECTED]
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile 
linux-mips-2.6.18-20060920/drivers/tc/Makefile
--- linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile2003-06-05 
04:03:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/Makefile  2006-10-03 
21:01:58.0 +
@@ -4,7 +4,7 @@
 
 # Object file lists.
 
-obj-$(CONFIG_TC) += tc.o
+obj-$(CONFIG_TC) += tc.o tc-driver.o
 obj-$(CONFIG_ZS) += zs.o
 obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o
 
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 
linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c
--- linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 1970-01-01 
00:00:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c   2006-12-19 
22:29:49.0 +
@@ -0,0 +1,110 @@
+/*
+ * TURBOchannel driver services.
+ *
+ * Copyright (c) 2005  James Simmons
+ * Copyright (c) 2006  Maciej W. Rozycki
+ *
+ * Loosely based on drivers/dio/dio-driver.c and
+ * drivers/pci/pci-driver.c.
+ *
+ * This file is subject to the terms and conditions of the GNU
+ * General Public License.  See the file "COPYING" in the main
+ * directory of this archive for more details.
+ */
+
+#include 
+#include 
+#include 
+
+/**
+ * tc_register_driver - register a new TC driver
+ * @drv: the driver structure to register
+ *
+ * Adds the driver structure to the list of registered drivers
+ * Returns a negative value on error, otherwise 0.
+ * If no error occurred, the driver remains registered even if
+ * no device was claimed during registration.
+ */
+int tc_register_driver(struct tc_driver *tdrv)
+{
+   return driver_register(&tdrv->driver);
+}
+EXPORT_SYMBOL(tc_register_driver);
+
+/**
+ * tc_unregister_driver - unregister a TC driver
+ * @drv: the driver structure to unregister
+ *
+ * Deletes the driver structure from the list of registered TC drivers,
+ * gives it a chance to clean up by calling its remove() function for
+ * each device it was responsible for, and marks those devices as
+ * driverless.
+ */
+void tc_unregister_driver(struct tc_driver *tdrv)
+{
+   driver_unregister(&tdrv->driver);
+}
+EXPORT_SYMBOL(tc_unregister_driver);
+
+/**
+ * tc_match_device - tell if a TC device structure has a matching
+ *   TC device ID structure
+ * @tdrv: the TC driver to earch for matching TC device ID strings
+ * @tdev: the TC device structure to match against
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * tc_device_id structure or %NULL if there is no match.
+ */
+const struct tc_device_id *tc_match_device(struct tc_driver *tdrv,
+  struct tc_dev *tdev)
+{
+   const struct tc_device_id *id = tdrv->id_table;
+
+   if (id) {
+   while (id->name[0] || id->vendor[0]) {
+   if (strcmp(tdev->name, id->name) == 0 &&
+   strcmp(tdev->vendor, id->vendor) == 0)
+   return id;
+   id++;
+   }
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(tc_match_device);
+
+/**
+ * tc_bus_match - Tell if a device structure has a matching
+ *TC device ID structure
+ * @dev: the device structure to match against
+ * @drv: the device driver to search for matching TC device ID strings
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns 1 if there
+ * is a match or 0 otherwise.
+ */
+static int tc_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct tc_dev *tdev = to_tc_dev(dev);
+   struct tc_driver *tdrv = to_tc_driver(drv);
+   const struct tc_device_id *id;
+
+   id = tc_match_device(tdrv, t

[PATCH 2.6.20-rc1 00/10] TURBOchannel update to the driver model

2006-12-20 Thread Maciej W. Rozycki 
Hello,

 It has been much longer than expected, but finally it is here!  This 
series of patches converts support for the TURBOchannel bus to the driver 
model.  As a nice side effect, the generic part of the code is now really 
generic, that is no more dependencies on MIPS specifics under drivers/tc/ 
and platform specific code for MIPS got moved where it belongs.  As to 
whether other relevant platforms will add TURBOchannel support or not I 
cannot tell right now. ;-)

 All the changes have been successfully tested with a DECstation 5000/133 
and the necessary bits of additional hardware as appropriate.  Where 
drivers supporting different bus attachments were concerned, they were 
built for configurations enabling all the other buses supported and 
run-time checked if possible.

 And last but not least, thanks to James Simmons for beginning this work a 
while ago as his code was great to start with.

  Maciej
-
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.6.20-rc1 01/10] TURBOchannel update to the driver model

2006-12-20 Thread Andrew Morton 
On Wed, 20 Dec 2006 12:01:30 + (GMT)
"Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:

> +/**
> + * tc_register_driver - register a new TC driver
> + * @drv: the driver structure to register
> + *
> + * Adds the driver structure to the list of registered drivers
> + * Returns a negative value on error, otherwise 0.
> + * If no error occurred, the driver remains registered even if
> + * no device was claimed during registration.
> + */
> +int tc_register_driver(struct tc_driver *tdrv)
> +{
> + return driver_register(&tdrv->driver);
> +}
> +EXPORT_SYMBOL(tc_register_driver);
> +
> +/**
> + * tc_unregister_driver - unregister a TC driver
> + * @drv: the driver structure to unregister
> + *
> + * Deletes the driver structure from the list of registered TC drivers,
> + * gives it a chance to clean up by calling its remove() function for
> + * each device it was responsible for, and marks those devices as
> + * driverless.
> + */
> +void tc_unregister_driver(struct tc_driver *tdrv)
> +{
> + driver_unregister(&tdrv->driver);
> +}
> +EXPORT_SYMBOL(tc_unregister_driver);

I spose making these inline would save a bit of code, stack space and 
a couple of exports.
-
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 Jens Axboe 
On Thu, Dec 21 2006, FUJITA Tomonori wrote:
> 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?

Yep, we should.

-- 
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] 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