Re: [PATCH] scsi: sd_zbc: Disable zoned block devices with scsi-mq

On Thu, Aug 17, 2017 at 11:45:50AM +0900, Damien Le Moal wrote: > blk-mq may not maintain write requests order at dispatch time. So host > managed drives will not reliably work. Worse, potential reordering of > write requests on requeue may cause the zone write locking code to > deadlock command

[PATCH] scsi: sg: off by one in sg_ioctl()

If "val" is SG_MAX_QUEUE then we are one element beyond the end of the "rinfo" array so the > should be >=. Fixes: 109bade9c625 ("scsi: sg: use standard lists for sg_requests") Signed-off-by: Dan Carpenter diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index

Re: No I/O errors reported after SATA link hard reset

[This seems to be libata error handling and not scsi, so I added more CCs] On 08/17/2017 12:27 AM, Gionatan Danti wrote: > Hi list, > some time ago, I had a filesystem corruption on a simple, two disks > RAID1 MD array. On the affected machine, /var/log/messages shown some > "failed command:

smp-induced oops/NULL pointer dereference in mpt3sas, from kernel >= 4.11

Hi All, In testing kernel 4.11.1 and 4.11.6 we've hit an oops/ blown pointer issue in mpt3sas. It is easily reproducible on a system that contains expanders/enclosure connected behind SAS3 HBA. Soon after connecting expander / enclosure we observe below call trace. Jul 12 15:28:27 localhost

Re: [PATCH] scsi: sd_zbc: Disable zoned block devices with scsi-mq

On 8/17/17 16:59, Christoph Hellwig wrote: > On Thu, Aug 17, 2017 at 11:45:50AM +0900, Damien Le Moal wrote: >> blk-mq may not maintain write requests order at dispatch time. So host >> managed drives will not reliably work. Worse, potential reordering of >> write requests on requeue may cause

Re: [PATCH] scsi: sd_zbc: Disable zoned block devices with scsi-mq

On 8/17/17 21:19, Damien Le Moal wrote: > > > On 8/17/17 16:59, Christoph Hellwig wrote: >> On Thu, Aug 17, 2017 at 11:45:50AM +0900, Damien Le Moal wrote: >>> blk-mq may not maintain write requests order at dispatch time. So host >>> managed drives will not reliably work. Worse, potential

Re: No I/O errors reported after SATA link hard reset

Hello, On Thu, Aug 17, 2017 at 11:24:22AM +0200, Bernd Schubert wrote: > > More concerning is the fact that these undetected errors can make their > > way even when the higher application consistently calls sync() and/or > > fsync. In other words, it seems than even acknowledged writes can fail >

Re: [PATCH] scsi: sd_zbc: Disable zoned block devices with scsi-mq

On 8/18/17 00:01, Bart Van Assche wrote: > On Thu, 2017-08-17 at 21:19 +0900, Damien Le Moal wrote: >> On 8/17/17 16:59, Christoph Hellwig wrote: >>> On Thu, Aug 17, 2017 at 11:45:50AM +0900, Damien Le Moal wrote: blk-mq may not maintain write requests order at dispatch time. So host

[PATCH 3/3] scsi: ibmvscsi_tgt: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- 1 file

Re: Spurious DISK_EVENT_MEDIA_CHANGE on USB DVD hotplug?

On 08/14/2017 02:30 PM, Tejun Heo wrote: > Hello, Joe. > > On Thu, Aug 10, 2017 at 10:45:54AM -0400, Joe Lawrence wrote: >> In the case of my USB DVD -> laptop example, there is no media in my >> device, however I still see the DISK_EVENT_MEDIA_CHANGE event. This is >> a bit confusing, and I was

Re: No I/O errors reported after SATA link hard reset

Hi Bernd, Il 17-08-2017 15:18 Bernd Schubert ha scritto: So for Gionatan the root cause was an instable power supply, but in my case there wasn't any power loss, there were just failed sata commands. I tried many times to replicate the error by briefly disconnecting/reconnecting the SATA

Re: [PATCH] scsi: hpsa: fix the device_id in hpsa_update_device_info()

On 08/17/2017 04:44 PM, Dan Carpenter wrote: > The parentheses are in the wrong place so we specify the length as > "sizeof(this_device->device_id) < 0" which is zero. > > Fixes: 988b87edd231 ("scsi: hpsa: Ignore errors for unsupported LV_DEVICE_ID > VPD page") > Signed-off-by: Dan Carpenter

Re: [PATCH] scsi: sd_zbc: Disable zoned block devices with scsi-mq

On Thu, 2017-08-17 at 21:19 +0900, Damien Le Moal wrote: > On 8/17/17 16:59, Christoph Hellwig wrote: > > On Thu, Aug 17, 2017 at 11:45:50AM +0900, Damien Le Moal wrote: > > > blk-mq may not maintain write requests order at dispatch time. So host > > > managed drives will not reliably work. Worse,

Re: No I/O errors reported after SATA link hard reset

Il 17-08-2017 16:46 Tejun Heo ha scritto: Upper layer can request to avoid retrying on errors but it won't help too much. It doesn't have much to do with specific commands. A power event can take place without any command in flight and lose the buffered data. Unless upper layer is tracking

RE: [PATCH 1/7] smartpqi: add pqi reset quiesce support

> -Original Message- > From: James Bottomley [mailto:j...@linux.vnet.ibm.com] > Sent: Wednesday, August 16, 2017 10:44 PM > To: Don Brace ; joseph.szczy...@hpe.com; > Gerry Morong ; John Hall > ; Kevin Barnett >

[PATCH 2/3] scsi: ibmvscsi: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +- 1 file changed, 1

[PATCH 1/3] scsi: ibmvfc: constify vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/scsi/ibmvscsi/ibmvfc.c | 2 +- 1 file changed, 1

[PATCH 0/3] constify scsi vio_device_id

vio_device_id are not supposed to change at runtime. All functions working with vio_device_id provided by work with const vio_device_id. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] scsi: ibmvfc: constify vio_device_id [PATCH 2/3] scsi: ibmvscsi: constify

Re: No I/O errors reported after SATA link hard reset

Hello, On Thu, Aug 17, 2017 at 04:15:35PM +0200, Gionatan Danti wrote: > Ok, so *this* is the root cause of the problem: libata not > identifying spurious link renegotiations vs brief powerloss/powerup > events. Out of curiosity: is this a SATA-specific problem (ie: in > the SATA specification),

Re: No I/O errors reported after SATA link hard reset

Hello Tejun, On 08/17/2017 02:48 PM, Tejun Heo wrote: > Hello, > > On Thu, Aug 17, 2017 at 11:24:22AM +0200, Bernd Schubert wrote: >>> More concerning is the fact that these undetected errors can make their >>> way even when the higher application consistently calls sync() and/or >>> fsync. In

Re: No I/O errors reported after SATA link hard reset

On 08/17/2017 03:25 PM, Tejun Heo wrote: > Hello, > > On Thu, Aug 17, 2017 at 03:18:06PM +0200, Bernd Schubert wrote: >> So for Gionatan the root cause was an instable power supply, but in my >> case there wasn't any power loss, there were just failed sata commands. >> I'm not sure if this was

[PATCH] scsi: hpsa: fix the device_id in hpsa_update_device_info()

The parentheses are in the wrong place so we specify the length as "sizeof(this_device->device_id) < 0" which is zero. Fixes: 988b87edd231 ("scsi: hpsa: Ignore errors for unsupported LV_DEVICE_ID VPD page") Signed-off-by: Dan Carpenter diff --git a/drivers/scsi/hpsa.c

Re: No I/O errors reported after SATA link hard reset

Hi Tejun, Il 17-08-2017 14:48 Tejun Heo ha scritto: Recovered errors aren't reported as IO errors and at least from link state proper there's no way for the driver to tell apart link glitches and buffer-erasing power issues. Ok, so *this* is the root cause of the problem: libata not

Re: [PATCH] sd: read unmap block limits even if lbpme=0

On 17 August 2017 at 10:11, Martin K. Petersen wrote: > > Tom, > > I have to confess I'm wary of interpreting values reported by a device > that messes up setting the single bit flag that enables the feature. > FWIW, this implementation in particular works pretty well

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: > On 08/16/2017 12:21 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > > > As of next-20170809, linux-next on powerpc boot hung with below trace > > > message. > > > > > > [ ... ] > > > > > > A bisection

Re: smp-induced oops/NULL pointer dereference in mpt3sas, from kernel >= 4.11

On Thu, 2017-08-17 at 15:18 +0530, Chaitra Basappa wrote: > We analyzed this issue and could figure out it is not because of driver, > its because the "sense" field of the 'struct scsi_request' is not being > populated properly from the upper layer. > And this "sense" member is being referenced in

Re: [PATCH] scsi: hpsa: fix the device_id in hpsa_update_device_info()

Dan, > The parentheses are in the wrong place so we specify the length as > "sizeof(this_device->device_id) < 0" which is zero. Applied to 4.14/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] Revert "scsi-mq: Always unprepare before requeuing a request"

uot;)). The ipr fix is in today's linux-next but was not in linux-next yesterday (the Australian time zone applies to the linux-next date labels): $ git tag --contains 270065e92c31 next-20170816 $ git tag --contains b0e17a9b0df2 next-20170817 $ git show next-20170816 | head -3 tag next-20170816 Tag

Re: [PATCH] Revert "scsi-mq: Always unprepare before requeuing a request"

Bart, > I think this means that the ipr fix went upstream before it ended up in > linux-next. OK. Brian: Please make sure you test with your ipr change in place as well as Bart's patch. And then report back. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: No I/O errors reported after SATA link hard reset

Hello, On Thu, Aug 17, 2017 at 03:18:06PM +0200, Bernd Schubert wrote: > So for Gionatan the root cause was an instable power supply, but in my > case there wasn't any power loss, there were just failed sata commands. > I'm not sure if this was a port or cable issue - once I changed port and >

Re: [PATCH] Revert "scsi-mq: Always unprepare before requeuing a request"

On 08/17/2017 11:45 AM, Martin K. Petersen wrote: > > Bart, > >> I think this means that the ipr fix went upstream before it ended up in >> linux-next. > > OK. > > Brian: Please make sure you test with your ipr change in place as well > as Bart's patch. And then report back. They are separate

Re: [PATCH] Revert "scsi-mq: Always unprepare before requeuing a request"

Brian, > They are separate issues. The ipr fix that is now upstream is for a > locking issue in ipr. The boot hang issue is a separate issue. I can > reproduce the boot hang on a system with my ipr patch. I've confirmed > it goes away when reverting Bart's patch but it makes no sense as of > yet