[PATCH] sbp2: fix panic when ejecting an ipod

[PATCH] sbp2: fix panic when ejecting an ipod

[Stefan Richter]

sbp2: fix panic when ejecting an ipod

Sbp2 did not catch some bogus transfer directions in requests from upper
layers.  Problem became apparent when iPods were to be ejected:
http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
Debugging and original variant of the patch by Andrew de Quincey.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Andrew de Quincey <adq@lidskialf.net>

---

Corresponding fix of the places where transfer direction is actually set and
how to clean sbp2_create_command_orb() up after this fix is being discussed.
A patch for SCSI mid and high level has been submitted.
http://marc.theaimsgroup.com/?t=113400010000001
Please apply the following patch to prevent kernel panics as the first step.

 drivers/ieee1394/sbp2.c |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

--- linux/drivers/ieee1394.orig/sbp2.c	2005-11-24 23:10:21.000000000 +0100
+++ linux/drivers/ieee1394/sbp2.c	2005-12-10 11:57:41.000000000 +0100
@@ -1784,6 +1784,12 @@ static int sbp2_create_command_orb(struc
 			break;
 	}
 
+	if (orb_direction != ORB_DIRECTION_NO_DATA_TRANSFER &&
+	    scsi_request_bufflen == 0) {
+		SBP2_WARN("Enforcing transfer direction DMA_NONE");
+		orb_direction = ORB_DIRECTION_NO_DATA_TRANSFER;
+	}
+
 	/*
 	 * Set-up our pagetable stuff... unfortunately, this has become
 	 * messier than I'd like. Need to clean this up a bit.   ;-)
@@ -1900,16 +1906,6 @@ static int sbp2_create_command_orb(struc
 			command_orb->misc |= ORB_SET_DATA_SIZE(scsi_request_bufflen);
 			command_orb->misc |= ORB_SET_DIRECTION(orb_direction);
 
-			/*
-			 * Sanity, in case our direction table is not
-			 * up-to-date
-			 */
-			if (!scsi_request_bufflen) {
-				command_orb->data_descriptor_hi = 0x0;
-				command_orb->data_descriptor_lo = 0x0;
-				command_orb->misc |= ORB_SET_DIRECTION(1);
-			}
-
 		} else {
 			/*
 			 * Need to turn this into page tables, since the

Re: [stable] [PATCH] sbp2: fix panic when ejecting an ipod

[Greg KH]

On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
> sbp2: fix panic when ejecting an ipod
> 
> Sbp2 did not catch some bogus transfer directions in requests from upper
> layers.  Problem became apparent when iPods were to be ejected:
> http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
> Debugging and original variant of the patch by Andrew de Quincey.
> 
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Andrew de Quincey <adq@lidskialf.net>

Is this in linus's tree yet?  Do the 1394 maintainers accept it as a
valid fix?

thanks,

greg k-h

Re: [stable] [PATCH] sbp2: fix panic when ejecting an ipod

[Stefan Richter]

Greg KH wrote:
> On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
> 
>>sbp2: fix panic when ejecting an ipod
>>
>>Sbp2 did not catch some bogus transfer directions in requests from upper
>>layers.  Problem became apparent when iPods were to be ejected:
>>http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
>>http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
>>Debugging and original variant of the patch by Andrew de Quincey.
>>
>>Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>>Cc: Andrew de Quincey <adq@lidskialf.net>
> 
> 
> Is this in linus's tree yet? 

My idea was that it goes in parallel to Linus and to -stable, hence the 
selection of recipients of my posting.

I will submit two related cleanup patches for sbp2 to linux1394-devel on 
Sunday morning. They will remove obsolete code and reformat code for 
readability. IMO they will *not* be suitable for Linus' tree before the 
next subsystem merge window.

> Do the 1394 maintainers accept it as a valid fix?

Ben Collins and I are *sbp2* maintainers. I consider it a valid fix (but 
see below.) Jody McIntyre and Ben are *1394* maintainers. Jody posted a 
NAK a few hours ago:
|| NAK.  James has a patch to fix this in the SCSI layer, which is his
|| preference.

I agree with Jody and the SCSI people that Jens' and James' patches are 
the actual fixes. What I want to accomplish is twofold:
  - Don't let tiny mistakes lead to catastrophic failure (panic) if it
    can be avoided without additional code.
  - Get the panic fixed in -stable in one way or another ASAP.

James, I assume Jens' and your patch will be in Linus' tree soon. 
Therefore and because my pending sbp2 cleanups will land in Linus' tree 
eventually, this sbp2 patch here is not vital for the current kernel. 
But do you consider to submit the SCSI fixes or a derivative to -stable 
too? If not, I recommend my patch to be included in -stable.

Jody, I very much respect and appreciate your opinion. Please continue 
to step in the way when I'm doing goofy things. :-)
-- 
Stefan Richter
-=====-=-=-= ==-- -=-==
http://arcgraph.de/sr/

Re: [stable] [PATCH] sbp2: fix panic when ejecting an ipod

[Stefan Richter]

I wrote on 2005-12-11:
> Greg KH wrote:
>> On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
>>> Sbp2 did not catch some bogus transfer directions in requests from upper
>>> layers.
...
>> Is this in linus's tree yet? 
...
>> Do the 1394 maintainers accept it as a valid fix?
...
> Jody posted a NAK a few hours ago:
> || NAK.  James has a patch to fix this in the SCSI layer, which is his
> || preference.

FYI, James' fix for sd_init_command etc. is this one:
http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=c9526497cf03ee775c3a6f8ba62335735f98de7a

It depends on the following patch to apply cleanly (but does not 
actually require it to work and fix the iPod related panic):
http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=a8c730e85e80734412f4f73ab28496a0e8b04a7b

Sorry for any confusion I might have created,
-- 
Stefan Richter
-=====-=-=-= ==-- -===-
http://arcgraph.de/sr/

Re: [stable] [PATCH] sbp2: fix panic when ejecting an ipod

[Greg KH]

On Wed, Dec 14, 2005 at 09:09:41PM +0100, Stefan Richter wrote:
> I wrote on 2005-12-11:
> >Greg KH wrote:
> >>On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
> >>>Sbp2 did not catch some bogus transfer directions in requests from upper
> >>>layers.
> ...
> >>Is this in linus's tree yet? 
> ...
> >>Do the 1394 maintainers accept it as a valid fix?
> ...
> >Jody posted a NAK a few hours ago:
> >|| NAK.  James has a patch to fix this in the SCSI layer, which is his
> >|| preference.
> 
> FYI, James' fix for sd_init_command etc. is this one:
> http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=c9526497cf03ee775c3a6f8ba62335735f98de7a
> 
> It depends on the following patch to apply cleanly (but does not 
> actually require it to work and fix the iPod related panic):
> http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=a8c730e85e80734412f4f73ab28496a0e8b04a7b
> 
> Sorry for any confusion I might have created,

Ok, care to submit something to stable@ to get the fix into the next
2.6.14.y queue?

thanks,

greg k-h

[PATCH 2.6.14.3 1/2] SCSI: fix transfer direction in sd (kernel panic when ejecting iPod)

[Stefan Richter]

SCSI: fix transfer direction in sd (kernel panic when ejecting iPod)

sd_init_command could issue WRITE requests with zero buffer length.
This may lead to kernel panic or oops with some SCSI low-level drivers.
Seen with the command "eject /dev/sdX" when disconnecting an iPod:
http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435

Derived from -rc patches from Jens Axboe and James Bottomley.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---

Patch is reassembled for -stable from patches:
[SCSI] fix panic when ejecting ieee1394 ipod
[SCSI] Consolidate REQ_BLOCK_PC handling path (fix ipod panic)

 drivers/scsi/scsi_lib.c  |   20 ++++++++++++++++++++
 drivers/scsi/sd.c        |   16 +---------------
 include/scsi/scsi_cmnd.h |    1 +
 3 files changed, 22 insertions(+), 15 deletions(-)

--- linux-2.6.14.3/drivers/scsi.orig/scsi_lib.c	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/drivers/scsi/scsi_lib.c	2005-12-14 22:23:13.000000000 +0100
@@ -1129,6 +1129,26 @@ static void scsi_generic_done(struct scs
 	scsi_io_completion(cmd, cmd->result == 0 ? cmd->bufflen : 0, 0);
 }
 
+void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd, int retries)
+{
+	struct request *req = cmd->request;
+
+	BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
+	memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
+	cmd->cmd_len = req->cmd_len;
+	if (!req->data_len)
+		cmd->sc_data_direction = DMA_NONE;
+	else if (rq_data_dir(req) == WRITE)
+		cmd->sc_data_direction = DMA_TO_DEVICE;
+	else
+		cmd->sc_data_direction = DMA_FROM_DEVICE;
+	
+	cmd->transfersize = req->data_len;
+	cmd->allowed = retries;
+	cmd->timeout_per_command = req->timeout;
+}
+EXPORT_SYMBOL_GPL(scsi_setup_blk_pc_cmnd);
+
 static int scsi_prep_fn(struct request_queue *q, struct request *req)
 {
 	struct scsi_device *sdev = q->queuedata;
--- linux-2.6.14.3/drivers/scsi.orig/sd.c	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/drivers/scsi/sd.c	2005-12-14 22:23:13.000000000 +0100
@@ -231,24 +231,10 @@ static int sd_init_command(struct scsi_c
 	 * SG_IO from block layer already setup, just copy cdb basically
 	 */
 	if (blk_pc_request(rq)) {
-		if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-			return 0;
-
-		memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-		SCpnt->cmd_len = rq->cmd_len;
-		if (rq_data_dir(rq) == WRITE)
-			SCpnt->sc_data_direction = DMA_TO_DEVICE;
-		else if (rq->data_len)
-			SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-		else
-			SCpnt->sc_data_direction = DMA_NONE;
-
-		this_count = rq->data_len;
+		scsi_setup_blk_pc_cmnd(SCpnt, SD_PASSTHROUGH_RETRIES);
 		if (rq->timeout)
 			timeout = rq->timeout;
 
-		SCpnt->transfersize = rq->data_len;
-		SCpnt->allowed = SD_PASSTHROUGH_RETRIES;
 		goto queue;
 	}
 
--- linux-2.6.14.3/include/scsi.orig/scsi_cmnd.h	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/include/scsi/scsi_cmnd.h	2005-12-14 22:23:14.000000000 +0100
@@ -150,5 +150,6 @@ extern struct scsi_cmnd *scsi_get_comman
 extern void scsi_put_command(struct scsi_cmnd *);
 extern void scsi_io_completion(struct scsi_cmnd *, unsigned int, unsigned int);
 extern void scsi_finish_command(struct scsi_cmnd *cmd);
+extern void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd, int retries);
 
 #endif /* _SCSI_SCSI_CMND_H */

[PATCH 2.6.14.3] SCSI: fix transfer direction in scsi_lib and st

[Stefan Richter]

SCSI: fix transfer direction in scsi_lib and st

scsi_prep_fn and st_init_command could issue WRITE requests with zero
buffer length. This may lead to kernel panic or oops with some SCSI
low-level drivers.

Derived from -rc patches from Jens Axboe and James Bottomley.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---

Patch is reassembled for -stable from patches:
[SCSI] fix panic when ejecting ieee1394 ipod
[SCSI] Consolidate REQ_BLOCK_PC handling path (fix ipod panic)

Depends on patch "SCSI: fix transfer direction in sd (kernel panic when
ejecting iPod)". Also modifies the already correct sr_init_command to
fully match the corresponding -rc patch.

 drivers/scsi/scsi_lib.c |   13 +------------
 drivers/scsi/sr.c       |   20 +++-----------------
 drivers/scsi/st.c       |   19 +------------------
 3 files changed, 5 insertions(+), 47 deletions(-)

--- linux-2.6.14.3/drivers/scsi.orig/scsi_lib.c	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/drivers/scsi/scsi_lib.c	2005-12-14 22:23:13.000000000 +0100
@@ -1284,18 +1304,7 @@ static int scsi_prep_fn(struct request_q
 				goto kill;
 			}
 		} else {
-			memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
-			cmd->cmd_len = req->cmd_len;
-			if (rq_data_dir(req) == WRITE)
-				cmd->sc_data_direction = DMA_TO_DEVICE;
-			else if (req->data_len)
-				cmd->sc_data_direction = DMA_FROM_DEVICE;
-			else
-				cmd->sc_data_direction = DMA_NONE;
-			
-			cmd->transfersize = req->data_len;
-			cmd->allowed = 3;
-			cmd->timeout_per_command = req->timeout;
+			scsi_setup_blk_pc_cmnd(cmd, 3);
 			cmd->done = scsi_generic_done;
 		}
 	}
--- linux-2.6.14.3/drivers/scsi.orig/sr.c	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/drivers/scsi/sr.c	2005-12-14 22:23:13.000000000 +0100
@@ -320,25 +320,11 @@ static int sr_init_command(struct scsi_c
 	 * these are already setup, just copy cdb basically
 	 */
 	if (SCpnt->request->flags & REQ_BLOCK_PC) {
-		struct request *rq = SCpnt->request;
+		scsi_setup_blk_pc_cmnd(SCpnt, MAX_RETRIES);
 
-		if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-			return 0;
-
-		memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-		SCpnt->cmd_len = rq->cmd_len;
-		if (!rq->data_len)
-			SCpnt->sc_data_direction = DMA_NONE;
-		else if (rq_data_dir(rq) == WRITE)
-			SCpnt->sc_data_direction = DMA_TO_DEVICE;
-		else
-			SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-
-		this_count = rq->data_len;
-		if (rq->timeout)
-			timeout = rq->timeout;
+		if (SCpnt->timeout_per_command)
+			timeout = SCpnt->timeout_per_command;
 
-		SCpnt->transfersize = rq->data_len;
 		goto queue;
 	}
 
--- linux-2.6.14.3/drivers/scsi.orig/st.c	2005-11-24 23:10:21.000000000 +0100
+++ linux-2.6.14.3/drivers/scsi/st.c	2005-12-14 22:23:13.000000000 +0100
@@ -4196,27 +4196,10 @@ static void st_intr(struct scsi_cmnd *SC
  */
 static int st_init_command(struct scsi_cmnd *SCpnt)
 {
-	struct request *rq;
-
 	if (!(SCpnt->request->flags & REQ_BLOCK_PC))
 		return 0;
 
-	rq = SCpnt->request;
-	if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
-		return 0;
-
-	memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
-	SCpnt->cmd_len = rq->cmd_len;
-
-	if (rq_data_dir(rq) == WRITE)
-		SCpnt->sc_data_direction = DMA_TO_DEVICE;
-	else if (rq->data_len)
-		SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-	else
-		SCpnt->sc_data_direction = DMA_NONE;
-
-	SCpnt->timeout_per_command = rq->timeout;
-	SCpnt->transfersize = rq->data_len;
+	scsi_setup_blk_pc_cmnd(SCpnt, 0);
 	SCpnt->done = st_intr;
 	return 1;
 }

Re: [PATCH 2.6.14.3] SCSI: fix transfer direction in scsi_lib and st

[Stefan Richter]

PS: This was of course "[PATCH 2.6.14.3 2/2] ...".
-- 
Stefan Richter
-=====-=-=-= ==-- -===-
http://arcgraph.de/sr/

Re: [stable] Re: [PATCH 2.6.14.3] SCSI: fix transfer direction in scsi_lib and st

[Greg KH]

On Wed, Dec 14, 2005 at 11:43:35PM +0100, Stefan Richter wrote:
> PS: This was of course "[PATCH 2.6.14.3 2/2] ...".

Both of them have been applied to the queue, thanks.

greg k-h

(no subject)

[Jody McIntyre]

James Bottomley <James.Bottomley@SteelEye.com>
Bcc: 
Subject: Re: [PATCH] sbp2: fix panic when ejecting an ipod
Reply-To: 
In-Reply-To: <200512101125.jBABP7Z9001085@einhorn.in-berlin.de>

On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
> sbp2: fix panic when ejecting an ipod
> 
> Sbp2 did not catch some bogus transfer directions in requests from upper
> layers.  Problem became apparent when iPods were to be ejected:
> http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
> Debugging and original variant of the patch by Andrew de Quincey.

NAK.  James has a patch to fix this in the SCSI layer, which is his
preference.

Cheers,
Jody

> 
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Andrew de Quincey <adq@lidskialf.net>
> 
> ---
> 
> Corresponding fix of the places where transfer direction is actually set and
> how to clean sbp2_create_command_orb() up after this fix is being discussed.
> A patch for SCSI mid and high level has been submitted.
> http://marc.theaimsgroup.com/?t=113400010000001
> Please apply the following patch to prevent kernel panics as the first step.
> 
>  drivers/ieee1394/sbp2.c |   16 ++++++----------
>  1 files changed, 6 insertions(+), 10 deletions(-)
> 
> --- linux/drivers/ieee1394.orig/sbp2.c	2005-11-24 23:10:21.000000000 +0100
> +++ linux/drivers/ieee1394/sbp2.c	2005-12-10 11:57:41.000000000 +0100
> @@ -1784,6 +1784,12 @@ static int sbp2_create_command_orb(struc
>  			break;
>  	}
>  
> +	if (orb_direction != ORB_DIRECTION_NO_DATA_TRANSFER &&
> +	    scsi_request_bufflen == 0) {
> +		SBP2_WARN("Enforcing transfer direction DMA_NONE");
> +		orb_direction = ORB_DIRECTION_NO_DATA_TRANSFER;
> +	}
> +
>  	/*
>  	 * Set-up our pagetable stuff... unfortunately, this has become
>  	 * messier than I'd like. Need to clean this up a bit.   ;-)
> @@ -1900,16 +1906,6 @@ static int sbp2_create_command_orb(struc
>  			command_orb->misc |= ORB_SET_DATA_SIZE(scsi_request_bufflen);
>  			command_orb->misc |= ORB_SET_DIRECTION(orb_direction);
>  
> -			/*
> -			 * Sanity, in case our direction table is not
> -			 * up-to-date
> -			 */
> -			if (!scsi_request_bufflen) {
> -				command_orb->data_descriptor_hi = 0x0;
> -				command_orb->data_descriptor_lo = 0x0;
> -				command_orb->misc |= ORB_SET_DIRECTION(1);
> -			}
> -
>  		} else {
>  			/*
>  			 * Need to turn this into page tables, since the
> 

-- 

Re: [PATCH] sbp2: fix panic when ejecting an ipod

[Stefan Richter]

Jody McIntyre wrote:
> On Sat, Dec 10, 2005 at 12:24:59PM +0100, Stefan Richter wrote:
> 
>>sbp2: fix panic when ejecting an ipod
>>
>>Sbp2 did not catch some bogus transfer directions in requests from upper
>>layers.  Problem became apparent when iPods were to be ejected:
>>http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
>>http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
>>Debugging and original variant of the patch by Andrew de Quincey.
> 
> 
> NAK.  James has a patch to fix this in the SCSI layer, which is his
> preference.

The fix for SCSI mid/high layer is to send the proper transfer 
direction. (BTW, note that there are _many_ places where the transfer 
direction is generated, not just where Jeff's and James' patches correct 
things. The code which generates transfer directions will keep changing. 
Userspace can set transfer directions.)

The fix for sbp2 is to not cause a kernel panic should an improper 
transfer direction be send. All SCSI low level drivers have to handle 
the transfer direction one way or another. Most chose not to panic.

My patch is not the fix for the wrong direction. It is solely meant not 
to crash the whole machine after a minor mistake. Also, my patch is not 
meant to hide mistakes that occurred in higer levels --- and it doesn't 
do so.

I absolutely agree with you et al that bugs must be fixed in the layer 
where they occur. However I also strongly believe that a bug in one 
layer should not trickle down two or more layers and increase the damage 
up to a catastrophe --- *if this can be avoided by simple means*, i.e. 
without bloat. (Note the diffstat. I am basically moving existing code 
up in an if/else cascade. Also, another cleanup for 
sbp2_create_command_orb will follow next week.)

Please apply.

>>Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>>Cc: Andrew de Quincey <adq@lidskialf.net>
>>
>>---
>>
>>Corresponding fix of the places where transfer direction is actually set and
>>how to clean sbp2_create_command_orb() up after this fix is being discussed.
>>A patch for SCSI mid and high level has been submitted.
>>http://marc.theaimsgroup.com/?t=113400010000001
>>Please apply the following patch to prevent kernel panics as the first step.
>>
>> drivers/ieee1394/sbp2.c |   16 ++++++----------
>> 1 files changed, 6 insertions(+), 10 deletions(-)
>>
>>--- linux/drivers/ieee1394.orig/sbp2.c	2005-11-24 23:10:21.000000000 +0100
>>+++ linux/drivers/ieee1394/sbp2.c	2005-12-10 11:57:41.000000000 +0100
>>@@ -1784,6 +1784,12 @@ static int sbp2_create_command_orb(struc
>> 			break;
>> 	}
>> 
>>+	if (orb_direction != ORB_DIRECTION_NO_DATA_TRANSFER &&
>>+	    scsi_request_bufflen == 0) {
>>+		SBP2_WARN("Enforcing transfer direction DMA_NONE");
>>+		orb_direction = ORB_DIRECTION_NO_DATA_TRANSFER;
>>+	}
>>+
>> 	/*
>> 	 * Set-up our pagetable stuff... unfortunately, this has become
>> 	 * messier than I'd like. Need to clean this up a bit.   ;-)
>>@@ -1900,16 +1906,6 @@ static int sbp2_create_command_orb(struc
>> 			command_orb->misc |= ORB_SET_DATA_SIZE(scsi_request_bufflen);
>> 			command_orb->misc |= ORB_SET_DIRECTION(orb_direction);
>> 
>>-			/*
>>-			 * Sanity, in case our direction table is not
>>-			 * up-to-date
>>-			 */
>>-			if (!scsi_request_bufflen) {
>>-				command_orb->data_descriptor_hi = 0x0;
>>-				command_orb->data_descriptor_lo = 0x0;
>>-				command_orb->misc |= ORB_SET_DIRECTION(1);
>>-			}
>>-
>> 		} else {
>> 			/*
>> 			 * Need to turn this into page tables, since the
>>
> 
> 


-- 
Stefan Richter
-=====-=-=-= ==-- -=-=-
http://arcgraph.de/sr/