gd->minors has been set when call alloc_disk() in sd_probe.
Signed-off-by: weiping zhang
---
drivers/scsi/sd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index bea36ad..c18ca7a 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3223,7 +3223,6
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
man
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
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
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
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
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
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 r
sue")). 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-20170
> -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
> ; Mahesh Rajashekhara
> ; Bader Ali - Saleh
> ; h...@infradead.org; Scott Teel
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 as far as I
can tell. The va
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,
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 all
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
>
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), o
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 b/drivers/scsi/hpsa.c
inde
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 cab
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 identifyin
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
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 vio_device_i
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 insertion(+), 1 deletion(-)
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 changed, 1 insertion(+), 1 del
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 insertion(+), 1 deletion(-)
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 a
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
> sat
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 ot
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
>
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 reor
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 th
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 kern
[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: WRITE
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 di
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 d7ff71e0c85c..84e782d8e7c3 100644
33 matches
Mail list logo