> 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 mecha
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 22:16:33 Bidule kernel: usb 6-4.3.2
> -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
> ; Raghava Aditya Renukunta
> ; gpicc...@prot
> -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
> ; Raghava Aditya Renukunta
> ; gpicc...@prot
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: Pr
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
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 ke
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 ca
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
Cc: Hannes Reinecke
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 counterpa
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 Rudolph
Cc: Martin K. Petersen
Cc: J
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 definit
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
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 issue,
> please collect
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 /sys/kernel/debug/bl
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 your
>> reproducer?
>
>
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 license to work properly, as
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
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 wa
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 that
20 matches
Mail list logo
