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
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;
>> +
>> +spin_lock_irqsave(q->queue_lock
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 deletion(-)
diff
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
drivers/scsi/cxlflash/main.h | 1 +
2 files changed, 5 insertions(+)
diff --gi
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.
F
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 cont
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 changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/aacraid/aacraid.h b/drive
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.
Signed-of
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 tha
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 (s
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: Johannes Thumshirn
---
Changes in V2:
Removed unnecessary brackets an
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 i
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
Reviewed-by: David Carroll
Reviewed-by: Johanne
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
controlle
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 e
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
---
Changes in V2:
None
drivers/scsi/aacraid
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 res
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
---
Changes in V2:
None
drivers/scsi/aacraid/aachba.c | 53 ---
drivers/sc
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
Review
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
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 interrupt, so stex_request_irq
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: Charles.Chiou
Signed-off-by: Pa
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 command
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 h
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 wi
> -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 Carroll ; Gana Sridaran
> ; Scott Benesh
> -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 Carroll ; Gana Sridaran
> ; Scott Benes
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 th
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 the kernel is not in a be
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()
warn:
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 _so
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 parse
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 abi
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
> > fragmentation.
>
> I'm fine
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: H
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 still has dm-mpath d
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) {
> + i
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 to post it for comme
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 ++
include/scs
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 --
> drivers/
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
include/scsi/
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->sdev_gendev))
>>> + if (!sdev ||
>>> + !scsi_is_sdev_device(&sdev->sdev_gendev) ||
>>> + !get_device(&sdev
On Thu, Feb 16, 2017 at 02:30:34PM +, Bart Van Assche wrote:
> > sdev = q->queuedata;
> > - if (!sdev || !get_device(&sdev->sdev_gendev))
> > + if (!sdev ||
> > + !scsi_is_sdev_device(&sdev->sdev_gendev) ||
> > + !get_device(&sdev->sdev_gendev))
> > sdev = NULL;
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 co
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
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
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 +++-
> 1 file changed,
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 sysfs
> > - 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 scsi
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 should be using
the hi-pri
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 the scsi queue to be consisten
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-
>> s...@vger.kernel.org
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.
>>
>> Signed-off-by: Hannes Reine
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
> ---
> drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +
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
> driver not on the la
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 insertions(+), 9 deletions(-)
>
On 02/16/2017 10:32 AM, Sreekanth Reddy wrote:
> 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
>>
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 will
conflict wit
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 a/drivers/scsi/mpt3sas/mpt3sas_base.c
>
> -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
>
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
> +---
> drivers/scsi/mpt3sas
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
62 matches
Mail list logo
