"WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

"WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

[Florian Westphal]

After update to 3.8 dmesg is spammed with:

kernel: [ 280.272094] 3w-xxxx: scsi8: Unknown scsi opcode: 0x41
kernel: [ 280.272107] sd 8:0:0:0: [sda] Unhandled error code
kernel: [ 280.272110] sd 8:0:0:0: [sda]
kernel: [ 280.272112] Result: hostbyte=0x04 driverbyte=0x00
kernel: [ 280.272114] sd 8:0:0:0: [sda] CDB:
kernel: [ 280.272116] cdb[0]=0x41: 41 00 10 09 aa 22 00 00 08 00
kernel: [ 280.272123] end_request: I/O error, dev sda, sector 269068834
kernel: [ 280.272130] sda6: WRITE SAME failed. Manually zeroing.
[..]

This goes on and on.

I am not familiar with block layer or scsi drivers, so I don't know if this
is an issue with the 3w-xxxx driver or the block layer.

I've hacked around this by reverting "block: Make blkdev_issue_zeroout use WRITE SAME"
(579e8f3c7b2ecf7db91398d942d76457a3ddba21), as this hw doesn't support
write_same anyway.

Re: "WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

[Martin K. Petersen]

>>>>> "Florian" == Florian Westphal <fw@strlen.de> writes:

Florian> After update to 3.8 dmesg is spammed with: kernel: [
Florian> 280.272094] 3w-xxxx: scsi8: Unknown scsi opcode: 0x41 kernel: [
Florian> 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: 

Interesting. It looks like the 3ware handles this at the driver level
instead of passing the command through to the disk and letting it
fail. That in turn means that the logic we have in place to disable WS
when the disk does not support it does not get triggered.

The driver should really fill out the sense buffer in that case.

Could you please test the patch below?


Florian> This goes on and on.

The second question is what it is that's issuing these zeroouts at boot?
Which filesystem are you using? What's your DM/MD config?

-- 
Martin K. Petersen	Oracle Linux Engineering


3w-xxxx: Create sense buffer for unsupported commands

Make the driver return appropriate sense data when an unsupported
operation is queued. This will cause the SCSI layer to stop issuing the
offending command.

Reported-by: Florian Westphal <fw@strlen.de>
CC: adam radford <aradford@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
index 56662ae..b9276d1 100644
--- a/drivers/scsi/3w-xxxx.c
+++ b/drivers/scsi/3w-xxxx.c
@@ -216,6 +216,7 @@
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_tcq.h>
 #include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_eh.h>
 #include "3w-xxxx.h"
 
 /* Globals */
@@ -2009,7 +2010,8 @@ static int tw_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_c
 			printk(KERN_NOTICE "3w-xxxx: scsi%d: Unknown scsi opcode: 0x%x\n", tw_dev->host->host_no, *command);
 			tw_dev->state[request_id] = TW_S_COMPLETED;
 			tw_state_request_finish(tw_dev, request_id);
-			SCpnt->result = (DID_BAD_TARGET << 16);
+			SCpnt->result = (DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION;
+			scsi_build_sense_buffer(1, SCpnt->sense_buffer, ILLEGAL_REQUEST, 0x20, 0);
 			done(SCpnt);
 			retval = 0;
 	}

Re: "WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

[Florian Westphal]

Martin K. Petersen <martin.petersen@oracle.com> wrote:
> Florian> After update to 3.8 dmesg is spammed with: kernel: [
> Florian> 280.272094] 3w-xxxx: scsi8: Unknown scsi opcode: 0x41 kernel: [
> Florian> 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: 
> 
> Interesting. It looks like the 3ware handles this at the driver level
> instead of passing the command through to the disk and letting it
> fail. That in turn means that the logic we have in place to disable WS
> when the disk does not support it does not get triggered.
> 
> The driver should really fill out the sense buffer in that case.
> 
> Could you please test the patch below?

Sure, I'll report back tomorrow.

Thanks for the quick response,
Florian

Re: "WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

[Florian Westphal]

Martin K. Petersen <martin.petersen@oracle.com> wrote:
> >>>>> "Florian" == Florian Westphal <fw@strlen.de> writes:
> 
> Florian> After update to 3.8 dmesg is spammed with: kernel: [
> Florian> 280.272094] 3w-xxxx: scsi8: Unknown scsi opcode: 0x41 kernel: [
> Florian> 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: 
> 
> Could you please test the patch below?

Works. Only one WRITE_SAME error at boot, max_write_same_blocks in sysfs
is 0, which wasn't the case before.

> The second question is what it is that's issuing these zeroouts at boot?
> Which filesystem are you using? What's your DM/MD config?

ext4, no DM/MD is used.  I guess the zeroouts are from postgres, but i'm
not sure.

> 3w-xxxx: Create sense buffer for unsupported commands
> 
> Make the driver return appropriate sense data when an unsupported
> operation is queued. This will cause the SCSI layer to stop issuing the
> offending command.
> 
> Reported-by: Florian Westphal <fw@strlen.de>
> CC: adam radford <aradford@gmail.com>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Tested-by: Florian Westphal <fw@strlen.de>

Thanks again.

Re: "WRITE SAME failed. Manually zeroing" with 3w-xxxx driver

[adam radford]

On Mon, Apr 29, 2013 at 9:13 AM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Florian" == Florian Westphal <fw@strlen.de> writes:
>
> Florian> After update to 3.8 dmesg is spammed with: kernel: [
> Florian> 280.272094] 3w-xxxx: scsi8: Unknown scsi opcode: 0x41 kernel: [
> Florian> 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel:
>
> Interesting. It looks like the 3ware handles this at the driver level
> instead of passing the command through to the disk and letting it
> fail. That in turn means that the logic we have in place to disable WS
> when the disk does not support it does not get triggered.
>
> The driver should really fill out the sense buffer in that case.
>
> Could you please test the patch below?
>
>
> Florian> This goes on and on.
>
> The second question is what it is that's issuing these zeroouts at boot?
> Which filesystem are you using? What's your DM/MD config?
>
> --
> Martin K. Petersen      Oracle Linux Engineering
>
>
> 3w-xxxx: Create sense buffer for unsupported commands
>
> Make the driver return appropriate sense data when an unsupported
> operation is queued. This will cause the SCSI layer to stop issuing the
> offending command.
>
> Reported-by: Florian Westphal <fw@strlen.de>
> CC: adam radford <aradford@gmail.com>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>
> diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
> index 56662ae..b9276d1 100644
> --- a/drivers/scsi/3w-xxxx.c
> +++ b/drivers/scsi/3w-xxxx.c
> @@ -216,6 +216,7 @@
>  #include <scsi/scsi_host.h>
>  #include <scsi/scsi_tcq.h>
>  #include <scsi/scsi_cmnd.h>
> +#include <scsi/scsi_eh.h>
>  #include "3w-xxxx.h"
>
>  /* Globals */
> @@ -2009,7 +2010,8 @@ static int tw_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_c
>                         printk(KERN_NOTICE "3w-xxxx: scsi%d: Unknown scsi opcode: 0x%x\n", tw_dev->host->host_no, *command);
>                         tw_dev->state[request_id] = TW_S_COMPLETED;
>                         tw_state_request_finish(tw_dev, request_id);
> -                       SCpnt->result = (DID_BAD_TARGET << 16);
> +                       SCpnt->result = (DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION;
> +                       scsi_build_sense_buffer(1, SCpnt->sense_buffer, ILLEGAL_REQUEST, 0x20, 0);
>                         done(SCpnt);
>                         retval = 0;
>         }

Thanks Martin.  This patch looks good.

Acked-by: Adam Radford <aradford@gmail.com>