On Thu, Oct 01, 2015 at 04:38:45AM +, Junichi Nomura wrote:
> But another workload using dm-multipath still caues the same crash.
> I think a patch like the following is needed.
> What do you think?
Thanks Junichi,
I suspected that we should defer the release until we tear down
the sdev inste
Ping!
On Fri, Jul 17, 2015 at 11:16 AM, Vaishali Thakkar
wrote:
> Macro DEFINE_PCI_DEVICE_TABLE is deprecated. So, here use
> struct pci_device_id instead of DEFINE_PCI_DEVICE_TABLE with
> the goal of getting rid of this macro completely.
>
> The Coccinelle semantic patch that performs this trans
On 10/01/15 09:56, Junichi Nomura wrote:
> With 4.2 kernel, scsi_dh->detach() was not called until the last
> reference has gone. With 4.3-rc3, scsi_dh->detach() is directly called
> from the context of scsi_remove_device(). That's the point.
For my test script in the original post, I can't repro
HI Rob,
Thanks for your time.
On 09/21/2015 08:03 PM, Rob Herring wrote:
On 09/17/2015 04:45 AM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's behavior.
Si
Hi Kishon,
On 09/18/2015 11:05 AM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 21 August 2015 02:57 PM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's beha
On Wed, Sep 30, 2015 at 05:14:49PM +0200, Christoph Hellwig wrote:
>
> Paul, can you try the trivial one liner below?
>
> diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
> index edb044a..fbc9502 100644
> --- a/drivers/scsi/scsi_dh.c
> +++ b/drivers/scsi/scsi_dh.c
> @@ -391,7 +391,7 @
IS_ERR_OR_NULL already contain an unlikely compiler flag. Drop it.
Signed-off-by: Geliang Tang
---
drivers/scsi/cxlflash/superpipe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxlflash/superpipe.c
b/drivers/scsi/cxlflash/superpipe.c
index f1b62ce..eb1b0
On 10/01/15 00:18, Christoph Hellwig wrote:
> On Wed, Sep 30, 2015 at 12:35:50AM +, Junichi Nomura wrote:
>> With v4.3-rc3, stress testing of SCSI device addition/removal quickly
>> trigger random crash in memory allocator (e.g. __kmalloc). I found that
>> a commit 086b91d052eb ("scsi_dh: inte
"Matthew R. Ochs" writes:
>>> The process_sense() routine can perform a read capacity which
>>> can take some time to complete. If an EEH occurs while waiting
>>> on the read capacity, the EEH handler is unable to obtain the
>>> context's mutex in order to put the context in an error state.
>>> T
>>> Following an adapter reset, the AFU RRQ that resides in host memory
>>> holds stale data. This can lead to a condition where the RRQ interrupt
>>> handler tries to process stale entries and/or endlessly loops due to an
>>> out of sync generation bit.
>>>
>>> To fix, the AFU RRQ in host memory
(resending to the list this time, apologies!)
>> I'm not sure I fully understand the flow of this function, but it looks
>> like you set rc=0 regardless of how things actually go: is this ever
>> going to print a return value other than zero?
>
> Correct, this function behaves more like a void fo
On Wed, 2015-09-30 at 17:53 -0400, Tejun Heo wrote:
> Hello, Christoph.
>
> On Wed, Sep 30, 2015 at 05:14:49PM +0200, Christoph Hellwig wrote:
> > The problem is that async probing deadlocks vs a synchronous
> > request_module, as Tejun figured out based on the thrad in
> > http://thread.gmane.org
Hello, Christoph.
On Wed, Sep 30, 2015 at 05:14:49PM +0200, Christoph Hellwig wrote:
> The problem is that async probing deadlocks vs a synchronous
> request_module, as Tejun figured out based on the thrad in
> http://thread.gmane.org/gmane.linux.kernel/1420814
>
> Tejun, if I understand the thre
On 09/30/2015 06:21 AM, Hannes Reinecke wrote:
> On 09/29/2015 08:29 PM, Bart Van Assche wrote:
>> On 09/29/2015 03:47 AM, Hannes Reinecke wrote:
>>> here the next round of my update to the ALUA device handler.
>>
>> Sorry but this with this version I see an initiator kernel lockup
>> shortly after
2015.Szeptember 30.(Sze) 18:44 időpontban Christoph Hellwig ezt írta:
> On Wed, Sep 30, 2015 at 09:43:28AM -0700, James Bottomley wrote:
>> OK, post a compilable version of the patch and lets get the reporter to
>> try it out. Not resurrecting esoteric flags suits me.
No WARNINGs upon reboot usin
struct error_info has 6 bytes of padding on x86_64 (and I assume also
other 64 bit platforms). This currently amounts to about 4k of wasted
space (and presumably a third of that on 32 bit).
We can avoid that by keeping the codes and the strings in separate
arrays. Keeping those in sync should be e
On Thu, 2015-03-19 at 21:50 -0500, Tom Tucker wrote:
> Hi Andy,
>
> On 3/19/15 12:54 PM, Andy Shevchenko wrote:
> > On Tue, 2014-04-29 at 17:45 +0300, Andy Shevchenko wrote:
> > > Instead of supplying each byte through stack let's use %pM
> > > specifier.
> > Anyone to comment or apply this patch
From: Oleksandr Khoshaba
In the kernel we have nice specifier to print MAC by given pointer to the
address in binary form.
Signed-off-by: Oleksandr Khoshaba
Acked-by: Vikas Chaudhary
Signed-off-by: Andy Shevchenko
---
drivers/scsi/qla4xxx/ql4_mbx.c | 5 +
drivers/scsi/qla4xxx/ql4_nx.c
My coworkers and I were setting some enclosure states on our storage devices,
and then reading the states back using sysfs, and came across the 'fault' field
being set to 2. When we investigated into the ses.c file, we found this
wonderful comment:
/* For device slot and array device slot ele
On Wed, Sep 30, 2015 at 09:43:28AM -0700, James Bottomley wrote:
> OK, post a compilable version of the patch and lets get the reporter to
> try it out. Not resurrecting esoteric flags suits me.
Right here:
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index add419d..a56a7b2 10064
On Wed, 2015-09-30 at 09:41 -0700, Christoph Hellwig wrote:
> On Wed, Sep 30, 2015 at 09:36:24AM -0700, James Bottomley wrote:
> > Are you sure? The init trace that kicked all this off still has
> > twa_init in it. I was figuring the most likely suspect is
> > twa_get_param().
>
> That one doesn
On Wed, Sep 30, 2015 at 09:36:24AM -0700, James Bottomley wrote:
> Are you sure? The init trace that kicked all this off still has
> twa_init in it. I was figuring the most likely suspect is
> twa_get_param().
That one doesnt set ->srb at all, but given that it's called before
any SCSI commands
On Wed, 2015-09-30 at 09:31 -0700, Christoph Hellwig wrote:
> On Wed, Sep 30, 2015 at 09:15:30AM -0700, James Bottomley wrote:
> > I already thought of this. Unfortunately, it fails if the internally
> > posted command is a single sector (the size of TW_MIN_SGL_LENGTH), which
> > is true for most
On Wed, Sep 30, 2015 at 09:15:30AM -0700, James Bottomley wrote:
> I already thought of this. Unfortunately, it fails if the internally
> posted command is a single sector (the size of TW_MIN_SGL_LENGTH), which
> is true for most of them.
Which internally posted command? All the usual suspects s
Hi Christoph,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
config: x86_64-allmodconfig (attached as .config)
reproduce:
git checkout 6e392493504e88ec3b44596c22f08acf4eed11ee
# save the attached .config to linux build tree
make ARCH=x86_64
All error/w
On Wed, 2015-09-30 at 09:08 -0700, Christoph Hellwig wrote:
> Hi all,
>
> I'd like to propose the following patch intead. It uses a helper
> to check the conditions for the copied commands, and also fixes another
> place to use it which uses a different and I think buggy check:
>
> This avoids t
Hi all,
I'd like to propose the following patch intead. It uses a helper
to check the conditions for the copied commands, and also fixes another
place to use it which uses a different and I think buggy check:
This avoids the usage of scsi_cmnd.SCp which I'd like to get rid of
mid-term.
diff --g
1. Added mpt2sas driver related macro's in mpt3sas header files
2. Made scsi host's, raid class's, pci's, ioctl's call back functions
as a gobal API's, so that both the drivers can use these
call back functions.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 8 +-
dr
Currently there is a logging level option provided for user for each of our
drivers in the kernel configuration utility. They can enable this option to
get more verbose information. By default this is enabled.
When this option is enabled then those functions which displays the
required information
Gen2 HBA's uses MPI Scatter Gather Lists where as Gen3 HBA's uses
IEEE Scatter Gather Lists. So modify the common code part in such
a way that it will build IEEE SGL table for Gen3 HBA's and it will
build MPI SGL table for Gen2 HBA's.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3s
Don't send PHYDISK_HIDDEN Raid Action request for SAS2 HBA's.
Since these HBA's doesn't support this Raid Action.
Also enable fast_path only for SAS3 HBA's.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 19 +--
1 file changed, 17 insertions(+), 2 dele
1. Created a mpt3sas_module.c files for mpt3sas driver module,
where it can register SAS3 HBA devices with PCI, SML, IOCTL
subsystems. Also removed the correspanding API's from
mpt3sas_scsih.c file.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/Makefile | 3 +-
drivers/scsi/m
1. Don't enable MSI-X vector for SAS2008 B0 controller,
2. Enable only single MSI-X vectors for below HBA's
a. SAS2004
b. SAS2008
c. SAS2008_1
d. SAS2008_2
e. SAS2008_3
f. SAS2116_1
g. SAS2116_2
3. Enable Combined Reply Post Queue Support (i.e. 96 MSI-X vector)
for only Gen3
1. Create a mpt2sas_module.c file for mpt2sas driver module
where GEN2 HBA devices registers with PCI, SML, IOCTL subsytems.
2. Updated the Makefile to use the object files from mpt3sas folder
3. Defined a compilation defination flag SCSI_MPT2SAS which can be used to
not include those sections of
Ported below list of Warp drive specific patches
1. 'commit 0bdccdb0a090ad8dc5f851cad5e843244c410ee8
("mpt2sas: WarpDrive New product SSS6200 support added")',
2. 'commit 82a452581230b3ffc9d6475dffdb2568497b5fec
("mpt2sas: WarpDrive Infinite command retries due to wrong scsi command
entry
This patch stops the driver to invoke kthread (which remove the dead ioc)
for some time while EEH recovery has started.
This changes are ported from below mpt2sas driver patch
'commit b4730fb6e54a634a145c9c71c5cf856f00beb5cd
("mpt2sas: fix for driver fails EEH, recovery from injected pci bus error
1. Use 'hba_mpi_version_belonged' IOC varable to uniquely
identify each individual generation driver functionality at
runtime.
2. Declared global variable 'driver_name' and used
this variable while reserving PCI regions and while
allocating the IRQ's.
Signed-off-by: Sreekanth Reddy
---
drivers/
A new sysfs shost attribute called "BMR_status" is implemented to
report Backup Rail Monitor status.
This attribute is located in the path
/sys/class/scsi_host/host#/BMR_status
when reading this adapter attribute, then driver will output the state
of GPIO[24]. It returns "0" if BMR is hea
The fw_event_work struct is concurrently referenced at shutdown, so
add a refcount to protect it, and refactor the code to use it.
Additionally, refactor _scsih_fw_event_cleanup_queue() such that it
no longer iterates over the list without holding the lock, since
_firmware_event_work() concurrentl
These objects can be referenced concurrently throughout the driver, we
need a way to make sure threads can't delete them out from under each
other. This patch adds the refcount, and refactors the code to use it.
Additionally, we cannot iterate over the sas_device_list without
holding the lock, or
Added OEMs Gen2 PnP ID Branding names from mpt2sas driver.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 326
drivers/scsi/mpt3sas/mpt3sas_base.h | 93 +-
2 files changed, 305 insertions(+), 114 deletions(-)
diff --git a/d
setpci reset on nytro warpdrive card along with sysfs access and
cli ioctl access resulted in kernel oops
1. pci_access_mutex lock added to provide synchronization between IOCTL,
sysfs, PCI resource handling path
2. gioc_lock spinlock to protect list operations over multiple
controllers
This
Bump the mpt2sas driver version to 20.102.00.00 and
Bump the mpt3sas driver version to 9.101.00.00.
Signed-off-by: Sreekanth Reddy
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/d
Combined mpt2sas and mpt3sas driver code base in such a way that
still we can generate the two driver modules
(i.e. mpt2sas.ko for SAS2 HBA's & mpt3sas.ko for SAS3 HBA's) individualy.
Sreekanth Reddy (18):
mpt2sas: Use mpi headers from mpt3sas
mpt3sas : Added mpt2sas driver definitions
mpt3s
On Wed, Sep 30, 2015 at 12:35:50AM +, Junichi Nomura wrote:
> With v4.3-rc3, stress testing of SCSI device addition/removal quickly
> trigger random crash in memory allocator (e.g. __kmalloc). I found that
> a commit 086b91d052eb ("scsi_dh: integrate into the core SCSI code")
> moved the call
On Fri, Sep 25, 2015 at 10:31:18AM -0700, James Bottomley wrote:
> So the warning seems to be because scsi_dh_find_driver() is not quite
> consistent. For everything except alua, it scans the dh driver list to
> see what might attach to the device. It returns "alua" if the TPGS
> field is anythin
Looks good,
Reviewed-by: Christoph Hellwig
--
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
On 09/30/2015 12:35 PM, Boaz Harrosh wrote:
> On 09/30/2015 12:28 PM, Hannes Reinecke wrote:
> <>
>> Pushing things into the background is typically not the best of
>> ideas; actually I've been running into issues with udev not being
>> complete by the time the next round is started. So more often
I reported this a little while ago:
http://marc.info/?l=linux-kernel&m=144284810906949&w=2
It did clear up between rc1 and rc3.
Not sure what changes were applied in-between.
On 09/30/2015 02:40 AM, Hannes Reinecke wrote:
Hi all,
trying to boot 4.3.0-rc1 on a system with hpsa results in a sw
Hi James,
the following patch for bnx2fc has been acked by QLogic but has never been
included
into the scsi branch.
Can you please merge it?
http://marc.info/?l=linux-scsi&m=140207797017410&w=2
Thanks,
Maurizio Lombardi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" i
On 09/29/2015 08:29 PM, Bart Van Assche wrote:
> On 09/29/2015 03:47 AM, Hannes Reinecke wrote:
>> here the next round of my update to the ALUA device handler.
>
> Hello Hannes,
>
> Sorry but this with this version I see an initiator kernel lockup
> shortly after the initiator system had been boo
On 09/30/2015 12:28 PM, Hannes Reinecke wrote:
<>
> Pushing things into the background is typically not the best of
> ideas; actually I've been running into issues with udev not being
> complete by the time the next round is started. So more often than
> not I would be greeted with messages:
>
> '
On 09/30/2015 02:35 AM, Junichi Nomura wrote:
> With v4.3-rc3, stress testing of SCSI device addition/removal quickly
> trigger random crash in memory allocator (e.g. __kmalloc). I found that
> a commit 086b91d052eb ("scsi_dh: integrate into the core SCSI code")
> moved the call of scsi_dh->detach
On Wed, Sep 30, 2015 at 09:40:50AM +0200, Hannes Reinecke wrote:
> Hi all,
>
> trying to boot 4.3.0-rc1 on a system with hpsa results in a swiotlb
> failure:
>
> hpsa :22:00.0: Logical aborts not supported
> hpsa :22:00.0: HP SSD Smart Path aborts not supported
> hpsa :22:00.0: swiotl
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
--
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
On 09/30/2015 12:21 AM, Don Brace wrote:
> From: Kevin Barnett
>
> customers want lsscsi -t to show sas addresses when
> enumerating sas devices. The sas addresses are used
> mainly to light drive LEDs for location.
>
> Signed-off-by: Don Brace
> ---
> drivers/scsi/hpsa.c | 704
> +++
Hi all,
trying to boot 4.3.0-rc1 on a system with hpsa results in a swiotlb
failure:
hpsa :22:00.0: Logical aborts not supported
hpsa :22:00.0: HP SSD Smart Path aborts not supported
hpsa :22:00.0: swiotlb buffer is full (sz: 786432 bytes)
swiotlb: coherent allocation failed for devic
57 matches
Mail list logo
