scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

[Dmitry Katsubo]

Hello,

In continuation to the issue described in [1] and [2]:

Unfortunately, I still suffer from the same problem on Linux kernel
v4.2.3. The problem is in detailed described in [3], in particular I see
the following in dmesg:

sd 6:0:0:0: [sdd] 234441648 512-byte logical blocks: (120 GB/111 GiB)
sd 6:0:0:0: [sdd] 4096-byte physical blocks
sd 6:0:0:0: [sdd] Write Protect is off
sd 6:0:0:0: [sdd] Mode Sense: 53 00 10 08
sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports
DPO and FUA
...
sd 6:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
sd 6:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current]
sd 6:0:0:0: [sdd] tag#0 Add. Sense: Invalid field in cdb
sd 6:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 08 00 00 10 80 00 00 08 00
blk_update_request: critical target error, dev sdd, sector 4224
BTRFS: lost page write due to I/O error on /dev/sdd1
BTRFS: bdev /dev/sdd1 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0

I believe that according to patches [4], [5] I should see something like
"Disabling FUA" in logs.

Any information about how to fix the problem is appreciated.

> [1] http://permalink.gmane.org/gmane.linux.scsi/91997
> [2] http://permalink.gmane.org/gmane.linux.usb.general/120430
> [3] http://unix.stackexchange.com/questions/237204/
> [4] 
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/scsi/sd.c#2446
> [5] 
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/usb/storage/unusual_devs.h#1990

-- 
With best regards,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

aacraid and rotational 1 even for ssd disks

[Arkadiusz Miskiewicz]

Hi.

I wonder if aacraid shouldn't properly inform kernel about sdd disk via 
/sys/devices/../queue/rotational flag?

Using 3.18.22 kernel and aacraid driver tells linux that all drives are 
rotational:

raid:
# cat 
/sys/devices/pci:80/:80:03.0/:81:00.0/host10/target10:0:0/10:0:0:0/block/sda/queue/rotational
1

lvm on top of that raid:
# cat /sys/devices/virtual/block/dm-*/queue/rotational
1
1
1

while this system has raid array of SSD drives only (INTEL SSDSC2BB30). No 
rotational disks.

Adaptec ASR8405 7.8-0 (32730) firmware.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND RFC PATCH 00/32] separate operations from flags in the bio/request structs

[Christoph Hellwig]

On Wed, Nov 04, 2015 at 04:07:57PM -0600, mchri...@redhat.com wrote:
> Known issues:
> - REQ_FLUSH is still a flag, but should probably be a operation.
>  For lower level drivers like SCSI where we only get a flush, it makes
> more sense to be a operation. However, upper layers like filesystems
> can send down flushes with writes, so it is more of a flag for them.
> I am still working on this.

Actually it should be both.  REQ_OP_FLUSH for a real flush operation,
and a REQ_PREFLUSH bio flag that the request layer will sequence into
an actual write an a flush operation.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 32/32] block: remove __REQ op defs and reduce bi_op/bi_rw sizes

[Christoph Hellwig]

I love this series!

Also I think it's very good that we finally split the ioprio out to it's
own field.

Thanks a lot for doing this work.

> I was not sure if or how much or where people wanted to stick things.
> There also appears to be room in the bi_flags field. If bi_flags is
> only using 13 bits and there are only 16 REQ_XYZs bits related bios,
> I could put them all in one variable if we wanted to go wild with trying
> to shrink the bio while I am at it..

This sounds interesting, but I'd rather do it as a separate project
later.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [PATCH 19/32] block: add helper to get data dir from op

[Christoph Hellwig]

On Thu, Nov 05, 2015 at 11:34:07AM -0600, Mike Christie wrote:
> I can do that. You are right in how they are used. I just did the above,
> to follow the other *_data_dir calls.

I think the *_data_dir calls are horrible interfaces.  But your series
already is huge, so if it makes your life easier I'd say keep it as-is
for now.  But in the long run we should have the interfaces that Bart
suggested, and one that gives you a dma_data_direction from a request,
as that's what a lot of the driver ultimatively want.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs

[Christoph Hellwig]

On Wed, Nov 04, 2015 at 10:53:39AM -0600, Mike Christie wrote:
> > If you have to touch submit_bio() and submit_bio_wait(), how about
> > requiring the callers of these functions to set the cmd and flags
> > arguments in the bio structure and to leave out the cmd and flags
> > arguments from the submit_bio() and submit_bio_wait() functions ? A
> > (compile tested only) patch that implements this idea is available at
> > https://lkml.org/lkml/2014/6/2/173.
> > 
> 
> Yeah, I can do that.

I think this would be useful to do at the beginning of the series.
While this will have a huge trickle effect through the series it should
make thing a bit simpler overall.  By leaving op 0 undefined it should
also help to create a nice error trap for unconverted code.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/2] megaraid_sas: missing curly braces in megasas_detach_one()

[Dan Carpenter]

The indenting indicates that there are supposed to be some curly braces
here.  Presumably it means we free something unintentionally leading to
a use after free.

Fixes: 3761cb4cf65e ('megaraid_sas: JBOD sequence number support')
Signed-off-by: Dan Carpenter 
---
Not tested.

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 829e9e9..91e200d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5932,7 +5932,7 @@ static void megasas_detach_one(struct pci_dev *pdev)
  fusion->max_map_sz,
  fusion->ld_map[i],
  fusion->ld_map_phys[i]);
-   if (fusion->ld_drv_map[i])
+   if (fusion->ld_drv_map[i]) {
free_pages((ulong)fusion->ld_drv_map[i],
fusion->drv_map_pages);
if (fusion->pd_seq_sync)
@@ -5940,6 +5940,7 @@ static void megasas_detach_one(struct pci_dev *pdev)
pd_seq_map_sz,
fusion->pd_seq_sync[i],
fusion->pd_seq_phys[i]);
+   }
}
free_pages((ulong)instance->ctrl_context,
instance->ctrl_context_pages);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 1/2] megaraid_sas: remove a stray tab

[Dan Carpenter]

One line was indented more than the others.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index cc95372..829e9e9 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5923,9 +5923,9 @@ static void megasas_detach_one(struct pci_dev *pdev)
 
if (instance->ctrl_context) {
megasas_release_fusion(instance);
-   pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
+   pd_seq_map_sz = sizeof(struct MR_PD_CFG_SEQ_NUM_SYNC) +
(sizeof(struct MR_PD_CFG_SEQ) *
-   (MAX_PHYSICAL_DEVICES - 1));
+   (MAX_PHYSICAL_DEVICES - 1));
for (i = 0; i < 2 ; i++) {
if (fusion->ld_map[i])
dma_free_coherent(>pdev->dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html