Skip to contentSkip to conversation

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

DISCUSSION Florian Westphal 3 participants 5 messages Apr 29, 2013 – May 21, 2013

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Florian" == Florian Westphal <[email protected]> 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?

Signature · 12 lines
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 <[email protected]>
CC: adam radford <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
drivers/scsi/3w-xxxx.c +3 -1
index 56662ae..b9276d1 100644
@@ -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;
 	}
#2 lore raw
Quoted 4 lines · Martin K. Petersen

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:

Quoted 8 lines

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

author Tested-by
#3 lore raw
In reply to Martin K. Petersen
Quoted 7 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Florian" == Florian Westphal <[email protected]> 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.

Quoted 2 lines

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.

Quoted 9 lines

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.

Thanks again.

maintainer Acked-by
#4 lore raw
In reply to Martin K. Petersen
Quoted 48 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Florian" == Florian Westphal <[email protected]> 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.

drivers/scsi/3w-xxxx.c +1 -0
index 56662ae..b9276d1 100644
@@ -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 */

drivers/scsi/3w-xxxx.c static int tw_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_c · line 2017

Quoted 9 lines
drivers/scsi/3w-xxxx.c +2 -1
@@ -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.