[PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done

Re: [PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

On 02/16/2017 05:09 PM, Bart Van Assche wrote: > On Thu, 2017-02-16 at 16:12 +0100, Hannes Reinecke wrote: >> +struct scsi_device *scsi_device_from_queue(struct request_queue *q) >> +{ >> +struct scsi_device *sdev = NULL; >> +unsigned long flags; >> + >> +

[PATCH 29/35] drivers/scsi: Convert remaining use of pr_warning to pr_warn

To enable eventual removal of pr_warning This makes pr_warn use consistent for drivers/scsi Prior to this patch, there was 1 use of pr_warning and 96 uses of pr_warn in drivers/scsi Signed-off-by: Joe Perches --- drivers/scsi/a3000.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] cxlflash: Enable PCI device ID for future IBM CXL Flash AFU

From: "Matthew R. Ochs" Add support for a future IBM Coherent Accelerator (CXL) flash AFU with an ID of 0x0624. Signed-off-by: Matthew R. Ochs Signed-off-by: Uma Krishnan --- drivers/scsi/cxlflash/main.c | 4

[PATCH V2 12/15] aacraid: Reorder Adapter status check

The driver currently checks the SELF_TEST_FAILED first and then KERNEL_PANIC next. Under error conditions(boot code failure) both SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time. The driver has the capability to reset the controller on an KERNEL_PANIC, but not on SELF_TEST_FAILED.

[PATCH V2 10/15] aacraid: Decrease adapter health check interval

Currently driver checks the health status of the adapter once every 24 hours. When that happens the driver becomes dependent on the kernel to figure out if the adapter is misbehaving. This might take some time (when the adapter is idle). The driver currently has support to restart/recover the

[PATCH V2 15/15] aacraid: Update driver version

Updated driver version to 50792 Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Reviewed-by: Johannes Thumshirn --- Changes in V2: None drivers/scsi/aacraid/aacraid.h | 2 +- 1 file

[PATCH V2 13/15] aacraid: Save adapter fib log before an IOP reset

Currently the adapter firmware does not save outstanding I/O's log information when an IOP reset is triggered. This is problematic when trying to root cause and debug issues. Fixed by adding sync command to trigger I/O log file save in the adapter firmware before issuing an IOP reset.

[PATCH V2 09/15] aacraid: Reload offlined drives after controller reset

During the IOP reset stress testing, it was found that the drives can be marked offline when the adapter controller crashes and IO's are running in parallel. When the controller does come back from the reset, the drive that is marked offline is not exposed. Fixed by removing and adding drives

[PATCH V2 14/15] aacraid: Fix a potential spinlock double unlock bug

The driver does not unlock the reply queue spin lock after handling SMART adapter events. Instead it might attempt to unlock an already unlocked spin lock. Fixed by making sure the driver locks the spin lock before freeing it. Thank you dan for finding this issue out. Fixes: 6223a39fe6fbbeef

[PATCH V2 11/15] aacraid: Skip IOP reset on controller panic(SMART Family)

When the SMART family of controller panic (KERNEL_PANIC) , they do not honor IOP resets. So better to skip it and directly perform a IWBR reset. Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Reviewed-by:

[PATCH V2 02/15] aacraid: Use correct channel number for raw srb

The channel being used for raw srb commands is retrieved from the utility sent fibs and is converted into physical channel id. The driver does not need to to do this since the management utility sends the correct channel id in the first place and in addition the driver sets inaccurate information

[PATCH V2 04/15] aacraid: Prevent E3 lockup when deleting units

Arrconf management utility at times sends fibs with AdapterProcessed set in its fibs. This causes the controller to panic and lockup. Fixed by failing the commands that have AdapterProcessed set in its flag. Signed-off-by: Raghava Aditya Renukunta

[PATCH V2 05/15] aacraid: Fix memory leak in fib init path

aac_fib_map_free frees misaligned fib dma memory, additionally it does not free up the whole memory. Fixed by changing the code to free up the correct and full memory allocation. Cc: sta...@vger.kernel.org Fixes: e8b12f0fb835223 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC based

[PATCH V2 03/15] aacraid: Fix for excessive prints on EEH

This issue showed up on a kdump debug(single CPU on powerkvm), when EEH errors rendered the adapter unusable. The driver correctly detected the issue and attempted to restart the controller, in doing so the driver attempted to read the status registers of the controller. This triggered additional

[PATCH V2 06/15] aacraid: Added sysfs for driver version

Added support to retrieve driver version from a new sysfs variable called driver_version. It makes it easier for the user to figure out the driver version that is currently running. Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll

[PATCH V2 00/15] aacraid: Fixes and enhancements for arc family

This patch set contains issue fixes, enhancements and other misc changes. The majority of the fixes are a direct outcome of testing and work done on the adapter reset mechanism. Initially it just had IOP reset and then was augmented with IWBR soft hardware resets in the previous patch set. The

[PATCH V2 01/15] aacraid: Fix camel case

Replaced camel case with snake case for init supported options. Suggested-by: Johannes Thumshirn Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Reviewed-by: Johannes Thumshirn

[PATCH V2 07/15] aacraid: Fix sync fibs time out on controller reset

After controller shutdown, all sync fibs time out due to not knowing about the switch to INT-x mode Fixed by replacing aac_src_access_devreg() to aac_set_intx_mode() call. Cc: sta...@vger.kernel.org Fixes: 495c021767bd78c998 (aacraid: MSI-x support) Signed-off-by: Raghava Aditya Renukunta

[PATCH V2 08/15] aacraid: Skip wellness sync on controller failure

aac_command_thread checks on the health of controller periodically, using aac_check_health. If the status is an error state KERNEL_PANIC or anything else. The driver will attempt to restart the adapter, but the response is not checked in aac_command_thread. This allows the periodic sync to go thru

[PATCH 1/2] Support Pegasus 3 product

From: Charles Pegasus series is a RAID support product by using Thunderbolt technology. The newest product, Pegasus 3(P3) is support Thunderbolt 3 technology with another chip. 1.Change driver version. 2.Add P3 VID, DID and define it's device address. 3.P3 use msi

[PATCH 2/2] Add S6 support

From: Charles 1.Add reboot notifier and register it in stex_probe for all supported device. 2.For all supported device in restart flow, we get a callback from notifier and set S6flag for stex_shutdown & stex_hba_stop to send restart command to FW. Signed-off-by:

[PATCH v5] sd: Check for unaligned partial completion

Commit f2e767bb5d6e ("mpt3sas: Force request partial completion alignment") was not considering the case of REQ_TYPE_FS commands not operating on logical block size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned partial replies). This could result is incorrectly retrying (forever) those

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

On Tuesday 31 January 2017 02:31:45 Finn Thain wrote: [...] > Are you trying to figure out which commands are going to disconnect during > a transfer? This is really a function of the firmware in the target; there > are no good heuristics AFAICT, so the PDMA algorithm has to be robust. > mac_scsi

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote: > Then undeprecate them. Decisions like marking a path checker deprecated > were _not_ made with NVMe in mind. They must predate NVMe. > > multipath-tools has tables that specify all the defaults for a given > target backend. NVMe

RE: [PATCH 10/16] aacraid: Terminate kthread on controller fw assert

> -Original Message- > From: Johannes Thumshirn [mailto:jthumsh...@suse.de] > Sent: Thursday, February 16, 2017 1:31 AM > To: Raghava Aditya Renukunta > ; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-scsi@vger.kernel.org > Cc: Dave

RE: [PATCH 06/16] aacraid: Added sysfs for driver version

> -Original Message- > From: Johannes Thumshirn [mailto:jthumsh...@suse.de] > Sent: Wednesday, February 15, 2017 11:43 PM > To: Raghava Aditya Renukunta > ; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-scsi@vger.kernel.org > Cc: Dave

Re: [PATCH v4] sd: Check for unaligned partial completion

On 15/02/2017 05:06, Ram Pai wrote: > On Wed, Feb 15, 2017 at 03:48:52PM +0900, Damien Le Moal wrote: >> Christoph, >> >> On 2/15/17 15:34, Christoph Hellwig wrote: >>> this looks reasonable, but we should ask Guilherme and Ram to confirm >>> it fixes their originally reported issue. I've added

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16 2017 at 1:07pm -0500, Keith Busch wrote: > On Thu, Feb 16, 2017 at 05:37:41PM +, Bart Van Assche wrote: > > On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote: > > > Maybe I'm not seeing the bigger picture. Is there some part to multipath > > > that

Re: [bug report] scsi: ufs-qcom: dump additional testbus registers

On 2017-02-13 23:58, Dan Carpenter wrote: Hello Venkat Gopalakrishnan, The patch 9c46b8676271: "scsi: ufs-qcom: dump additional testbus registers" from Feb 3, 2017, leads to the following static checker warning: drivers/scsi/ufs/ufs-qcom.c:1531 ufs_qcom_testbus_cfg_is_ok()

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

I'm fine with the path selectors getting moved out; maybe it'll encourage new path selectors to be developed. But there will need to be some userspace interface stood up to support your native NVMe multipathing (you may not think it needed but think in time there will be a need to configure

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 05:37:41PM +, Bart Van Assche wrote: > On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote: > > Maybe I'm not seeing the bigger picture. Is there some part to multipath > > that the kernel is not in a better position to handle? > > Does this mean that the code to

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote: > Maybe I'm not seeing the bigger picture. Is there some part to multipath > that the kernel is not in a better position to handle? Does this mean that the code to parse /etc/multipath.conf will be moved into the kernel? Or will we lose the

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote: > On Thu, Feb 16 2017 at 9:26am -0500, > Christoph Hellwig wrote: > > > just a little new code in the block layer, and a move of the path > > selectors from dm to the block layer. I would not call this > >

Re: [PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

On Thu, Feb 16, 2017 at 12:05:19PM -0500, Keith Busch wrote: > On Thu, Feb 16, 2017 at 04:12:23PM +0100, Hannes Reinecke wrote: > > The device handler needs to check if a given queue belongs to > > a scsi device; only then does it make sense to attach a device > > handler. > > > > Signed-off-by:

Re: [PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

On Thu, Feb 16, 2017 at 04:12:23PM +0100, Hannes Reinecke wrote: > The device handler needs to check if a given queue belongs to > a scsi device; only then does it make sense to attach a device > handler. > > Signed-off-by: Hannes Reinecke The thing I don't like is that this

Re: [PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

On Thu, 2017-02-16 at 16:12 +0100, Hannes Reinecke wrote: > +struct scsi_device *scsi_device_from_queue(struct request_queue *q) > +{ > + struct scsi_device *sdev = NULL; > + unsigned long flags; > + > + spin_lock_irqsave(q->queue_lock, flags); > + if (q->mq_ops) { > +

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16 2017 at 9:26am -0500, Christoph Hellwig wrote: > On Wed, Feb 15, 2017 at 09:53:57PM -0500, Mike Snitzer wrote: > > going to LSF/MM?). Yet you're expecting to just drop it into the tree > > without a care in the world about the implications. > > I am planning

[PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

The device handler needs to check if a given queue belongs to a scsi device; only then does it make sense to attach a device handler. Signed-off-by: Hannes Reinecke --- drivers/scsi/scsi_dh.c | 22 -- drivers/scsi/scsi_lib.c| 26

Re: [PATCH] scsi: use 'scsi_device_from_queue()' for scsi_dh

On 02/16/2017 04:07 PM, Hannes Reinecke wrote: > The device handler needs to check if a given queue belongs to > a scsi device; only then does it make sense to attach a device > handler. > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/scsi_dh.c | 22

[PATCH] scsi: use 'scsi_device_from_queue()' for scsi_dh

The device handler needs to check if a given queue belongs to a scsi device; only then does it make sense to attach a device handler. Signed-off-by: Hannes Reinecke --- drivers/scsi/scsi_dh.c | 22 -- drivers/scsi/scsi_lib.c| 24

Re: [PATCH] scsi_dh: only attach to SCSI devices

On 02/16/2017 03:38 PM, h...@lst.de wrote: > On Thu, Feb 16, 2017 at 02:30:34PM +, Bart Van Assche wrote: >>> sdev = q->queuedata; >>> - if (!sdev || !get_device(>sdev_gendev)) >>> + if (!sdev || >>> + !scsi_is_sdev_device(>sdev_gendev) || >>> + !get_device(>sdev_gendev))

Re: [PATCH] scsi_dh: only attach to SCSI devices

On Thu, Feb 16, 2017 at 02:30:34PM +, Bart Van Assche wrote: > > sdev = q->queuedata; > > - if (!sdev || !get_device(>sdev_gendev)) > > + if (!sdev || > > + !scsi_is_sdev_device(>sdev_gendev) || > > + !get_device(>sdev_gendev)) > > sdev = NULL; > >

Re: [PATCH] scsi_dh: only attach to SCSI devices

On Thu, 2017-02-16 at 15:32 +0100, Christoph Hellwig wrote: > On Thu, Feb 16, 2017 at 08:33:14AM +0100, Hannes Reinecke wrote: > > Any device might be setting a queuedata structure, so we need to > > check if the queuedata really belongs to a SCSI device before > > proceeding. > > Can you add a

Re: sense handling improvements

On Wed, Feb 15, 2017 at 10:42:56PM -0500, Martin K. Petersen wrote: > Christoph> The first patch prevents any possibily of reusing stale sense > Christoph> codes in sense headers, and is a bug fix that we should > Christoph> probably get into the block tree ASAP. > > Christoph> The rest cleans up

Re: [PATCH] scsi_dh: only attach to SCSI devices

On Thu, Feb 16, 2017 at 08:33:14AM +0100, Hannes Reinecke wrote: > Any device might be setting a queuedata structure, so we need to > check if the queuedata really belongs to a SCSI device before > proceeding. Can you add a comment next to the scsi_is_sdev_device call explaining it? The thing is

Re: [PATCH] scsi_dh: only attach to SCSI devices

On Thu, 2017-02-16 at 08:33 +0100, Hannes Reinecke wrote: > Any device might be setting a queuedata structure, so we need to > check if the queuedata really belongs to a SCSI device before > proceeding. > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/scsi_dh.c | 4 +++- >

Re: [PATCH RFC] enclosure: fix sysfs symlinks creation when using multipath

Hi James, have you noticed this patch? Dne 7.2.2017 v 15:08 Maurizio Lombardi napsal(a): > With multipath, it may happen that the same device is passed > to enclosure_add_device() multiple times and that the enclosure_add_links() > function fails to create the symlinks because the device's

RE: [PATCH 00/10] mpt3sas: full mq support

> > - Later we can explore if nr_hw_queue more than one really add benefit. > > From current limited testing, I don't see major performance boost if > > we have nr_hw_queue more than one. > > > Well, the _actual_ code to support mq is rather trivial, and really serves > as a > good testbed for

Re: [PATCH 07/10] mpt3sas: use hi-priority queue for TMFs

On 02/16/2017 11:23 AM, Sreekanth Reddy wrote: > On Thu, Feb 16, 2017 at 3:44 PM, Hannes Reinecke wrote: >> On 02/16/2017 11:09 AM, Sreekanth Reddy wrote: >>> On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: When sending a TMF via the ioctl interface we

Re: [PATCH 07/10] mpt3sas: use hi-priority queue for TMFs

On Thu, Feb 16, 2017 at 3:44 PM, Hannes Reinecke wrote: > On 02/16/2017 11:09 AM, Sreekanth Reddy wrote: >> On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: >>> When sending a TMF via the ioctl interface we should be using >>> the hi-priority queue instead of

Re: [PATCH 00/10] mpt3sas: full mq support

On 02/16/2017 10:48 AM, Kashyap Desai wrote: >> -Original Message- >> From: Hannes Reinecke [mailto:h...@suse.de] >> Sent: Wednesday, February 15, 2017 3:35 PM >> To: Kashyap Desai; Sreekanth Reddy >> Cc: Christoph Hellwig; Martin K. Petersen; James Bottomley; linux- >>

Re: [PATCH 07/10] mpt3sas: use hi-priority queue for TMFs

On 02/16/2017 11:09 AM, Sreekanth Reddy wrote: > On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: >> When sending a TMF via the ioctl interface we should be using >> the hi-priority queue instead of the scsi queue to be consistent >> with overall TMF usage. >> >>

Re: [PATCH 07/10] mpt3sas: use hi-priority queue for TMFs

On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: > When sending a TMF via the ioctl interface we should be using > the hi-priority queue instead of the scsi queue to be consistent > with overall TMF usage. > > Signed-off-by: Hannes Reinecke > --- >

Re: [PATCH 05/10] mpt3sas: open-code _scsih_scsi_lookup_get()

On 02/16/2017 10:59 AM, Sreekanth Reddy wrote: > On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: >> Just a wrapper around the scsi lookup array and only used >> in one place, so open-code it. > > I think this whole series of patches created over 14.101.00.00 version >

Re: [PATCH 04/10] mpt3sas: separate out _base_recovery_check()

On 02/16/2017 10:53 AM, Sreekanth Reddy wrote: > On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: >> No functional change. >> >> Signed-off-by: Hannes Reinecke >> --- >> drivers/scsi/mpt3sas/mpt3sas_base.c | 23 ++- >> 1 file changed, 14

Re: [PATCH 05/10] mpt3sas: open-code _scsih_scsi_lookup_get()

On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: > Just a wrapper around the scsi lookup array and only used > in one place, so open-code it. I think this whole series of patches created over 14.101.00.00 version driver not on the latest 15.100.00.00 driver. So this patch

Re: [PATCH 04/10] mpt3sas: separate out _base_recovery_check()

On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: > No functional change. > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/mpt3sas/mpt3sas_base.c | 23 ++- > 1 file changed, 14 insertions(+), 9 deletions(-) > > diff --git

RE: [PATCH 00/10] mpt3sas: full mq support

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Wednesday, February 15, 2017 3:35 PM > To: Kashyap Desai; Sreekanth Reddy > Cc: Christoph Hellwig; Martin K. Petersen; James Bottomley; linux- > s...@vger.kernel.org; Sathya Prakash Veerichetty; PDL-MPT-FUSIONLINUX

Re: [PATCH 01/10] mpt3sas: switch to pci_alloc_irq_vectors

On Tue, Jan 31, 2017 at 2:55 PM, Hannes Reinecke wrote: > Cleanup the MSI-X handling allowing us to use > the PCI-layer provided vector allocation. > > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/mpt3sas/mpt3sas_base.c | 100 >

Re: [PATCH 10/16] aacraid: Terminate kthread on controller fw assert

On 02/15/2017 11:22 PM, Raghava Aditya Renukunta wrote: >> >> This look a bit scary. Can't the kthread be converted to a workqueue so >> we could call cancel_work_sync()? > > Could you please elaborate on the reasons why this fix is scary? > I understand that killing a thread is not standard (for