RE: [PATCH 1/3] scsi: aacraid: Check for PCI state of device in a generic way

> Commit 16ae9dd35d37 ("scsi: aacraid: Fix for excessive prints on EEH") > introduced checks about the state of device before any PCI operations > in the driver. Basically, this prevents it to perform PCI accesses > when device is in the process of recover from a PCI error. In PowerPC, > such

Re: Seagate External SMR drive USB resets (XHCI transfer error, not timeout)

Hi, On Thu, 16 Nov 2017 14:42:51 -0500 (EST) Alan Stern wrote: > On Wed, 15 Nov 2017, Jérôme Carretero wrote: > > > I performed an usbmon capture extract, centered around the event > > (there was a few hundred MBs written for this to happen): > > > > Nov 15

RE: [PATCH 2/3] scsi: aacraid: Perform initialization reset only once

> -Original Message- > From: Guilherme G. Piccoli [mailto:gpicc...@linux.vnet.ibm.com] > Sent: Friday, November 17, 2017 1:15 PM > To: dl-esc-Aacraid Linux Driver ; linux- > s...@vger.kernel.org > Cc: gpicc...@linux.vnet.ibm.com; Dave Carroll >

RE: [PATCH 3/3] scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path

> -Original Message- > From: Guilherme G. Piccoli [mailto:gpicc...@linux.vnet.ibm.com] > Sent: Friday, November 17, 2017 1:15 PM > To: dl-esc-Aacraid Linux Driver ; linux- > s...@vger.kernel.org > Cc: gpicc...@linux.vnet.ibm.com; Dave Carroll >

[PATCH 0/3] Some fixes to aacraid

This series presents 3 small fixes for aacraid driver. The most important is the crash prevention, IMHO. Tested them against v4.14. Guilherme G. Piccoli (3): scsi: aacraid: Check for PCI state of device in a generic way scsi: aacraid: Perform initialization reset only once scsi: aacraid:

[PATCH 2/3] scsi: aacraid: Perform initialization reset only once

Currently the driver accepts two ways of requesting an initialization reset on the adapter: by passing aac_reset_devices module parameter, or the generic kernel parameter reset_devices. It's working as intended...but if we end up reaching a scsi hang and the scsi EH mechanism takes place, aacraid

[PATCH 3/3] scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path

As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on

[PATCH 1/3] scsi: aacraid: Check for PCI state of device in a generic way

Commit 16ae9dd35d37 ("scsi: aacraid: Fix for excessive prints on EEH") introduced checks about the state of device before any PCI operations in the driver. Basically, this prevents it to perform PCI accesses when device is in the process of recover from a PCI error. In PowerPC, such mechanism is

[PATCH] scsi_dh: add new rdac devices

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500. Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280. Add STK BladeCtlr family, arrays: B210, B220, B240 and B280. These changes were done in multipath-tools time ago. Cc: NetApp RDAC team

[PATCH try #2] scsi_devinfo: apply to HP-rebranded the same flags as Hitachi

627511e3e modified some Hitachi entries: Four models, OPEN-/DF400/DF500/DISK-SUBSYSTEM, can handle REPORT_LUN, and the BLIST_REPORTLUN2 flag needs to be set. And DF600 doesn't require any flags because it returns ANSI 03h (SPC). ~~~ The same should have been done also for HP

[PATCH] scsi_devinfo: apply to HP XP the same flags as Hitachi VSP

56f3d383f modified some Hitachi entries: HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only. ~~~ The same should have been done also for HP-rebranded. Cc: Hannes Reinecke Cc: Takahiro Yasui Cc: Matthias

[Bug 197877] arcmsr fails to initialize Areca ARC-1110/ARC-1120 on some systems

https://bugzilla.kernel.org/show_bug.cgi?id=197877 --- Comment #4 from k...@sognnes.no --- Building the latest Areca driver (1.40.00.02 from http://www.areca.us/support/s_linux/driver/Source%20Code/arcmsr-1.40.00.02-source-only.dkms.tar.gz) against kernel 3.17.8 introduces the bug, so it's

Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal

On Fri, 2017-11-17 at 18:10 +0100, Jack Wang wrote: > It's production server, I was too late to gather more information. > kernel is 4.4.36/4.4.50 > Request mode for both multipath and scsi, no multiqueue involvement. Hello Jack, I haven't seen any lockups with the multipath + SRP and the legacy

Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal

2017-11-17 18:01 GMT+01:00 Bart Van Assche : > On Fri, 2017-11-17 at 16:14 +0100, Jack Wang wrote: >> I suspect could be missing run queue or lost IO, IMHO it's unlikely >> below disk probing fix the bug. > > If the system is still in this state or if you can reproduce this

Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal

On Fri, 2017-11-17 at 16:14 +0100, Jack Wang wrote: > I suspect could be missing run queue or lost IO, IMHO it's unlikely > below disk probing fix the bug. If the system is still in this state or if you can reproduce this issue, please collect and analyze the information under

Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal

2017-11-14 18:33 GMT+01:00 Bart Van Assche : > On Tue, 2017-11-14 at 18:01 +0100, Jack Wang wrote: >> I suspect we run into same bug you were trying to fix in this patch >> set. we're running in v4.4.50 >> >> I was trying to reproduce it, but no lucky yet, do you still have

Re: [PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

On Fri, Nov 17, 2017 at 3:21 PM, Greg Kroah-Hartman wrote: > There is no need to #define the license of the driver, just put it in > the MODULE_LICENSE() line directly as a text string. > > This allows tools that check that the module license matches the source > code

[PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

There is no need to #define the license of the driver, just put it in the MODULE_LICENSE() line directly as a text string. This allows tools that check that the module license matches the source code license to work properly, as there is no need to unwind the unneeded dereference, especially when

Re: [REGRESSION][v4.13.y][v4.14.y] scsi: libsas: allow async aborts

On 11/16/2017 11:08 PM, Joseph Salisbury wrote: > Hi Christoph, > > A kernel bug report was opened against Ubuntu [0].  After a kernel > bisect, it was found that reverting the following commit resolved this bug: > > 909657615d9b ("scsi: libsas: allow async aborts") > >   > The regression

Re: mvsas sata drives with high ioerr_cnt and long stalls

On Thu, Nov 16, 2017 at 08:55:07PM -0500, Larkin Lowrey wrote: > It just got worse, under heavy sequential write load, all of the drives in > the array where thrown out of the array and I got a stack trace. > > I know I've been able to stress this array without issue but the last time I > did