On 10/18/2016 08:40 AM, Damien Le Moal wrote:
> From: Damien Le Moal
>
> Add the zoned queue limit to indicate the zoning model of a block device.
> Defined values are 0 (BLK_ZONED_NONE) for regular block devices,
> 1 (BLK_ZONED_HA) for host-aware zone block devices and 2 (BLK_ZONED_HM)
> for hos
From: Shaun Tancheff
Adds the new BLKREPORTZONE and BLKRESETZONE ioctls for respectively
obtaining the zone configuration of a zoned block device and resetting
the write pointer of sequential zones of a zoned block device.
The BLKREPORTZONE ioctl maps directly to a single call of the function
bl
From: Hannes Reinecke
The queue limits already have a 'chunk_sectors' setting, so
we should be presenting it via sysfs.
Signed-off-by: Hannes Reinecke
[Damien: Updated Documentation/ABI/testing/sysfs-block]
Signed-off-by: Damien Le Moal
Reviewed-by: Christoph Hellwig
Reviewed-by: Martin K.
From: Hannes Reinecke
Implement ZBC support functions to setup zoned disks, both
host-managed and host-aware models. Only zoned disks that satisfy
the following conditions are supported:
1) All zones are the same size, with the exception of an eventual
last smaller runt zone.
2) For host-manag
This series introduces support for zoned block devices. It integrates
earlier submissions by Hannes Reinecke and Shaun Tancheff. Compared to the
previous series version, the code was significantly simplified by limiting
support to zoned devices satisfying the following conditions:
1) All zones of t
From: Damien Le Moal
Add the zoned queue limit to indicate the zoning model of a block device.
Defined values are 0 (BLK_ZONED_NONE) for regular block devices,
1 (BLK_ZONED_HA) for host-aware zone block devices and 2 (BLK_ZONED_HM)
for host-managed zone block devices. The standards defined drive
From: Hannes Reinecke
Signed-off-by: Hannes Reinecke
Signed-off-by: Damien Le Moal
Reviewed-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
Reviewed-by: Shaun Tancheff
Tested-by: Shaun Tancheff
---
block/blk-settings.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/blk
From: Hannes Reinecke
Implement zoned block device zone information reporting and reset.
Zone information are reported as struct blk_zone. This implementation
does not differentiate between host-aware and host-managed device
models and is valid for both. Two functions are provided:
blkdev_report_
From: Shaun Tancheff
Define REQ_OP_ZONE_REPORT and REQ_OP_ZONE_RESET for handling zones of
host-managed and host-aware zoned block devices. With with these two
new operations, the total number of operations defined reaches 8 and
still fits with the 3 bits definition of REQ_OP_BITS.
Signed-off-by
Found by 0-day robot.
Fixes: a99ac6e715bc ("scsi: fcoe: set default TC priority")
Signed-off-by: Hannes Reinecke
---
drivers/scsi/fcoe/fcoe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index cf4adaa..59150ca 100644
---
Hello Johannes,
Apologies for the extended delayed follow-up on this bug report.
On Fri, 2016-09-02 at 16:14 +0200, Johannes Thumshirn wrote:
> Hi Nick et al,
>
> I'm having a "interesting" problem with the kernel's iSCSI target and
> could use a debug hint.
>
> My target uses an iblock backsto
From: Nicholas Bellinger
This reverts commit c1ccbfe0311e2380a6d2dcb0714b36904f5d586f.
Reverting this patch, as it incorrectly assumes the additional length
for INQUIRY in target_complete_cmd_with_length() is SCSI allocation
length, which breaks existing user-space code when SCSI allocation
leng
Add phy clock enable code to phy_power_on/off callbacks, and
remove explicit calls to enable these phy clocks from the
ufs-qcom hcd driver.
Signed-off-by: Vivek Gautam
Reviewed-by: Subhash Jadavani
---
drivers/phy/phy-qcom-ufs.c | 12 +++-
drivers/scsi/ufs/ufs-qcom.c | 15 -
This helps us in avoiding any requirement for kfree() operation
to be called exclusively over the allocated string pointer.
Signed-off-by: Vivek Gautam
Reviewed-by: Subhash Jadavani
---
drivers/phy/phy-qcom-ufs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/ph
From: Yaniv Gardi
Since in future UFS Phy's the tx_iface_clk and rx_iface_clk
are no longer exist, we should not fail when their initialization
fail, but rather just report with debug message.
Signed-off-by: Yaniv Gardi
Signed-off-by: Vivek Gautam
---
drivers/phy/phy-qcom-ufs.c | 15 +
Different methods pass around generic phy pointer to
extract device pointer. Instead, pass the device pointer
directly between function calls.
Signed-off-by: Vivek Gautam
Reviewed-by: Subhash Jadavani
---
drivers/phy/phy-qcom-ufs-i.h| 6 +--
drivers/phy/phy-qcom-ufs-qmp-14nm.c | 4 +-
The phy init is meant to do phy initialization rather than
just getting the clock and regulator. Move these clock and
regulator get to probe(), to make room for actual phy
initialization sequence.
Signed-off-by: Vivek Gautam
Reviewed-by: Subhash Jadavani
---
drivers/phy/phy-qcom-ufs-qmp-14nm.c
BUG_ON() are not preferred in the driver, plus the variable
on which BUG_ON is asserted is already checked in the code
before passing.
Signed-off-by: Vivek Gautam
Reviewed-by: Subhash Jadavani
---
drivers/phy/phy-qcom-ufs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/phy/phy-qc
remove() callback does a phy_exit() only and nothing else now.
The phy_exit() over the generic phy is called from the phy
consumer, and phy provider driver should not explicitly need to
call any phy_exit().
So discard the remove callback for qcom-ufs phy platform drivers.
Signed-off-by: Vivek Gaut
These patches cleanup the ufs phy driver to an extent.
Subsequent patches will target to clean the phy_init() of
these qcom-ufs phy drivers in order to get rid of a number of
exported APIs that phy drivers expose for ufs-qcom hcd driver
to use.
These patches are based on linux-phy next branch, and
Sorry I forget that Android has an aversion to plain text emails.
If we can provide any information to help, let us know. We are willing
to patch in more debug statements or whatever you think might help.
Today has been a difficult day. Thanks for looking into it, I tried
looking at it, but it is
Hi Robert,
I think the reason why you can not logout the targets is that iscsi_np
in D status. I think the patches fixed something, but it seems to be
more than one code path can trigger these similar issues. as you can
see, there are several call stacks, I am still working on it. Actually
in
On 2016-10-14 13:47, Martin K. Petersen wrote:
"Subhash" == Subhash Jadavani writes:
Subhash> UFS devfreq clock scaling work may require clocks to be ON if
Subhash> it need to execute some UFS commands hence it may request for
Subhash> clock hold before issuing the command. But if UFS clock ga
When we are resuming the UFS device rails in HPM mode, we are first
powering on the VCC rail while VCCQ and VCCQ2 rails still being in LPM
mode. Some UFS devices may take VCC on event as hint that host wants
UFS device to be resumed and may start drawing more power from the
VCCQ/VCCQ2 rails (while
From: Venkat Gopalakrishnan
The ungate work turns on the clock before it exits hibern8,
if the link was put in hibern8 during clock gating work.
There occurs a race condition when clock scaling work calls
ufshcd_hold() to make sure low power states cannot be entered,
but that returns by checking
From: Venkat Gopalakrishnan
In a case where gate work is called as part of cancel work
from ungate path the clk state would be marked as REQ_CLKS_ON.
There is no point gating the clocks and then end up turning
them ON immediately in ungate work, save time by skipping the
gate work and change the
From: Yaniv Gardi
In this change there are a few fixes of possible NULL pointer access
and possible access to index that exceeds array boundaries.
Signed-off-by: Yaniv Gardi
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufs.h| 3 ++-
drivers/scsi/ufs/ufshcd.c | 25
From: Gilad Broner
Add a write memory barrier to make sure descriptors prepared are actually
written to memory before ringing the doorbell. We have also added the
write memory barrier after ringing the doorbell register so that
controller sees the new request immediately.
Signed-off-by: Gilad Br
Currently clock scaling is suspended only after the host and device
are put in low power mode but we should avoid clock scaling running
after UFS link is put in low power mode (hibern8). This change
suspends clock scaling before putting host/device in low power mode.
Signed-off-by: Subhash Jadavan
From: Dov Levenglick
In case the power configuration fails, skip further processing
of the probing function and return immediately. This has 2 reasons:
1. Don't allow the UFS to continue running in PWM
2. Avoid multiple calls to pm_runtime_put_sync() when not
in error handling or power manage
From: Gilad Broner
According to UFS device specification, sense data can be only 18 bytes
long, this change makes the changes accordingly.
Signed-off-by: Gilad Broner
Signed-off-by: Subhash Jadavani
---
drivers/scsi/ufs/ufshcd.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(
From: Gilad Broner
During runtime resume operation, clock scaling may get indirectly
resumed via call to ufshcd_set_dev_pwr_mode(): Start/Stop Unit command
times out and SCSI error handling ultimately calls the host reset handler
to recover, during which clock scaling is resumed.
Error case exit
If ufshcd pltfrm/pci driver's probe fails for some reason then ensure that
scsi host is released to avoid memory leak but managed memory allocations
(via devm_* calls) need not to be freed explicitly on probe failure as
memory allocated with these functions is automatically freed on driver
detach.
UFS devfreq clock scaling work may require clocks to be ON if it need to
execute some UFS commands hence it may request for clock hold before
issuing the command. But if UFS clock gating work is already running in
parallel, ungate work would end up waiting for the clock gating work to
finish and as
On 2016/10/17 14:42, Johannes Thumshirn wrote:
On Sun, Oct 16, 2016 at 02:33:28PM +, ojab wrote:
Hi Ojab,
Do you have a known good kernel? If yes can you do a git bisect to see which
commit introduces this?
Thanks,
Johannes
The issue is reproducible from the start, i. e. from co
Sorry hit send too soon.
In addition, on the client we see:
# ps -aux | grep D | grep kworker
root 5583 0.0 0.0 0 0 ?D11:55 0:03 [kworker/11:0]
root 7721 0.1 0.0 0 0 ?D12:00 0:04 [kworker/4:25]
root 10877 0.0 0.0 0 0 ?
In addition, on the client we see:
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc wrote:
> Some more info as we hit this this morning. We have volumes mirrored
> between two targets and we had o
This patch checks to see if an ATA device supports NCQ command priorities.
If so and the user has specified an iocontext that indicates
IO_PRIO_CLASS_RT then we build a tf with a high priority command.
This is done to improve the tail latency of commands that are high
priority by passing priority
Add a sysfs entry to turn on priority information being passed
to a ATA device. By default this feature is turned off.
This patch depends on ata: Enabling ATA Command Priorities
Signed-off-by: Adam Manzanares
---
drivers/ata/libahci.c | 1 +
drivers/ata/libata-core.c | 2 +-
drivers/ata/l
Patch adds an association between iocontext ioprio and the ioprio of a
request. This is done to enable request based drivers the ability to
act on priority information stored in the request. An example being
ATA devices that support command priorities. If the ATA driver discovers
that the device su
This patch builds ATA commands with high priority if the iocontext of a process
is set to real time. The goal of the patch is to improve tail latencies of
workloads that use higher queue depths. This requires setting the iocontext
ioprio on the request when it is initialized
This patch has been
> "Finn" == Finn Thain writes:
>> Ondrej Zary (3): scsi: g_NCR5380: Stop using scsi_module.c
Finn> I believe that patch introduces an .init.text section mismatch,
Finn> that I failed to notice when I reviewed it. So you may want Arnd
Finn> Bergmann's fix which is commit 8f087c089dae5 ("scsi:
> "Arnd" == Arnd Bergmann writes:
Arnd> A recent bugfix introduced a harmless warning in the lpfc driver:
Arnd> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
Arnd> drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects
Arnd> argument of type 'long int', but arg
On Mon, 2016-10-17 at 23:06 +0530, Kashyap Desai wrote:
> > -Original Message-
> > From: James Bottomley [mailto:j...@linux.vnet.ibm.com]
> > Sent: Monday, October 17, 2016 10:50 PM
> > To: Ric Wheeler; Hannes Reinecke; Sumit Saxena;
> > linux-scsi@vger.kernel.org
> > Cc: martin.peter...@o
> "Hannes" == Hannes Reinecke writes:
Hannes> Hi all, here's now the second part of my FCoE VN2VN patchset.
Hannes> The key points are:
Hannes> - Configurable R_A_TOV/E_D_TOV
Hannes> - Rework PRLI handling to fix a longstanding bug
Hannes> - Correctly handle timed-out xids
Hannes> Additional
> "Jitendra" == Jitendra Bhivare writes:
Jitendra> These patches are being resent with required changes as per
Jitendra> comments for [PATCH 02/28] be2iscsi: Replace _bh with
Jitendra> _irqsave/irqrestore
Jitendra> In IO handling path, there is no spin_lock taken with IRQs
Jitendra> disabled
> -Original Message-
> From: James Bottomley [mailto:j...@linux.vnet.ibm.com]
> Sent: Monday, October 17, 2016 10:50 PM
> To: Ric Wheeler; Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org
> Cc: martin.peter...@oracle.com; the...@redhat.com;
> kashyap.de...@broadcom.com; Christoph H
On 10/17/2016 10:19 AM, James Bottomley wrote:
On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
From: Shikhar Dogra
Reduce chatter on console for usb hotplug.
KERN_ERR is too high severity for these messages, moving them
to KERN_WARNING
It's an error because we have several USB to ID
On 10/17/2016 01:19 PM, James Bottomley wrote:
That's not what I get from the change log. What it says to me is
> >that the caches are currently firmware managed. Barring firmware
> >bugs, that means that we currently don't have any integrity issues.
>
>Your understanding (or the change log) i
On 10/17/2016 11:17 AM, Gabriel Krisman Bertazi wrote:
> James Bottomley writes:
>
>> On Thu, 2016-10-13 at 15:47 -0300, Gabriel Krisman Bertazi wrote:
>>> @@ -210,6 +219,13 @@ int scsi_execute(struct scsi_device *sdev, const
>>> unsigned char *cmd,
>>> */
>>> blk_execute_rq(req->q, NULL
On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra
>
> Reduce chatter on console for usb hotplug.
> KERN_ERR is too high severity for these messages, moving them
> to KERN_WARNING
Perhaps KERN_NOTICE is more appropriate.
That's the level for most of these sd_first_pr
On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote:
> From: Shikhar Dogra
>
> Reduce chatter on console for usb hotplug.
> KERN_ERR is too high severity for these messages, moving them
> to KERN_WARNING
It's an error because we have several USB to IDE bridges that have
write back cache dri
On Mon, 2016-10-17 at 12:27 -0400, Ric Wheeler wrote:
> On 10/17/2016 12:20 PM, James Bottomley wrote:
> > On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote:
> > > On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
> > > > On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> > > > > megaraid_sas driver ret
From: Iago Abal
The EBA code analyzer (https://github.com/models-team/eba) reported
the following double lock:
1. In function `megaraid_reset_handler' at 2571;
2. take `&adapter->pend_list_lock' for the first time at 2602:
// FIRST
spin_lock_irqsave(PENDING_LIST_LO
From: Shikhar Dogra
Reduce chatter on console for usb hotplug.
KERN_ERR is too high severity for these messages, moving them
to KERN_WARNING
USB devices never have a Caching Mode page, it doesn't make
sense to make it an error when you have tons of USB devices where
the print is useless, and not
--
Geschäftsvorschlag!!!
Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es
ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (First
National Bank von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was
nicht in anspruch genommen worden ist, wo derzei
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Monday, October 17, 2016 9:21 AM
> To: Don Brace
> Cc: Johannes Thumshirn; Christoph Hellwig; martin.peter...@oracle.com;
> ax...@kernel.dk; linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org
> Subject: Re: [P
Some more info as we hit this this morning. We have volumes mirrored
between two targets and we had one target on the kernel with the three
patches mentioned in this thread [0][1][2] and the other was on a
kernel without the patches. We decided that after a week and a half we
wanted to get both tar
On 10/17/2016 12:20 PM, James Bottomley wrote:
We really need to have some ways to validate that our IO stack is
>properly and safely configured.
>
>I would love to see a couple of things:
>
>* having T10 & T13 report the existence of a volatile write cache -
>this is different than WCE set, some
On 10/17/2016 12:20 PM, James Bottomley wrote:
On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote:
On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
megaraid_sas driver returns SYNCHRONIZE_CACHE command back to
SCSI layer without sending it to firmwar
James Bottomley writes:
> On Thu, 2016-10-13 at 15:47 -0300, Gabriel Krisman Bertazi wrote:
>> @@ -210,6 +219,13 @@ int scsi_execute(struct scsi_device *sdev, const
>> unsigned char *cmd,
>> */
>> blk_execute_rq(req->q, NULL, req, 1);
>>
>> +if (scsi_sense_unit_attention(sense) &
On Mon, 2016-10-17 at 12:08 -0400, Ric Wheeler wrote:
> On 10/17/2016 11:55 AM, Christoph Hellwig wrote:
> > On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote:
> >> This must go in - without this fix, there is no data integrity for any
> >> file system.
> > megaraid always had odd ideas
On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote:
> On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
> > On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> > > megaraid_sas driver returns SYNCHRONIZE_CACHE command back to
> > > SCSI layer without sending it to firmware as firmware takes care
> > > o
On 10/14/2016 03:25 PM, Steven Royer wrote:
> On 2016-10-13 11:02, Michael Cyr wrote:
>> Various fixes and cleanups for the ibmvscsis driver.
>> The first is a sort of prequel to the second, which is the primary
>> change (and the biggest). The rest are fairly small fixes.
>>
>> Michael Cyr (6):
>
On 10/17/2016 11:55 AM, Christoph Hellwig wrote:
On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote:
This must go in - without this fix, there is no data integrity for any file
system.
megaraid always had odd ideas on cache flushing, and this might be
a opportunity to write down all t
Thanks
Signed-off-by: James Smart
-- james
On 10/17/2016 5:35 AM, Arnd Bergmann wrote:
A recent bugfix introduced a harmless warning in the lpfc driver:
drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argum
On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote:
> This must go in - without this fix, there is no data integrity for any file
> system.
megaraid always had odd ideas on cache flushing, and this might be
a opportunity to write down all the assumptions and document them.
> In effect,
On Thu, Oct 13, 2016 at 12:08:49PM +0530, Jitendra Bhivare wrote:
> [ 3843.132217] WARNING: CPU: 20 PID: 1227 at kernel/softirq.c:150
> __local_bh_enable_ip+0x6b/0x90
> [ 3843.142815] Modules linked in:
> ...
> [ 3843.294328] CPU: 20 PID: 1227 Comm: kworker/20:1H Tainted: GE
> 4.8.0
On Thu, Oct 13, 2016 at 12:08:48PM +0530, Jitendra Bhivare wrote:
> The code at free_task label in __iscsi_conn_send_pdu can get executed
> from blk_timeout_work which takes queue_lock using spin_lock_irq.
> back_lock taken with spin_unlock_bh will cause WARN_ON_ONCE.
> The code gets executed eithe
On Sun, Oct 16, 2016 at 02:33:28PM +, ojab wrote:
> Oh hai!
>
> I have LSI SAS 9217-8i HBA and `rmmod mpt3sas` leads to multiple backtraces
> if any disks are connected to the HBA.
> Reproducible on vanilla 4.7.5/4.8.1/4.9-rc1 kernels (haven't tested on
> another versions).
>
> Full output (4
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Monday, October 17, 2016 7:27 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE comm
Hi Don,
did you also have a chance to test the patch and verify that the
queues are properly set up with a smartpqi controller?
--
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.
On 17.10.2016 15:28, Sumit Saxena wrote:
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Monday, October 17, 2016 6:44 PM
>> To: Sumit Saxena; linux-scsi@vger.kernel.org
>> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com;
>> kashyap.de...@broadcom.com
> -Original Message-
> From: Johannes Thumshirn [mailto:jthumsh...@suse.de]
> Sent: Monday, October 17, 2016 2:34 AM
> To: Christoph Hellwig
> Cc: martin.peter...@oracle.com; Don Brace; ax...@kernel.dk; linux-
> s...@vger.kernel.org; linux-bl...@vger.kernel.org
> Subject: Re: [PATCH 3/3] s
On Mon, Oct 17, 2016 at 02:35:46PM +0200, Arnd Bergmann wrote:
> A recent bugfix introduced a harmless warning in the lpfc driver:
>
> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
> drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument
> of type 'long in
>-Original Message-
>From: Ric Wheeler [mailto:rwhee...@redhat.com]
>Sent: Monday, October 17, 2016 6:31 PM
>To: Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com; Christoph Hell
>-Original Message-
>From: Tomas Henzl [mailto:the...@redhat.com]
>Sent: Monday, October 17, 2016 6:44 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRON
On 17.10.2016 12:24, Sumit Saxena wrote:
> Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does
> not support JBOD sequence map.
>
> CC: sta...@vger.kernel.org
> Signed-off-by: Sumit Saxena
> Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
Tomas
--
To unsubscribe from
On 17.10.2016 12:24, Sumit Saxena wrote:
> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer
> without sending it to firmware as firmware takes care of flushing cache.
> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling.
> If underlying firmware has su
On 10/17/2016 07:34 AM, Hannes Reinecke wrote:
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer
without sending it to firmware as firmware takes care of flushing cache.
This patch will change the driver behavior wrt SYNCHRONIZE_
On 17.10.2016 12:24, Sumit Saxena wrote:
> This patch fixes the issue of wrong PhysArm was sent to firmware for R1
> VD downgrade.
>
> Signed-off-by: Kiran Kumar Kasturi
> Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
Tomas
--
To unsubscribe from this list: send the line "unsubscribe l
On 17.10.2016 12:24, Sumit Saxena wrote:
> For SRIOV enabled firmware, if there is a OCR(online controller reset)
> possibility driver set the convert flag to 1, which is not happening if
> there are outstanding commands even after 180 seconds.
> As driver does not set convert flag to 1 and still m
A recent bugfix introduced a harmless warning in the lpfc driver:
drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument of
type 'long int', but argument 9 has type 'size_t {aka const unsigned int}'
[-Werror=f
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:05 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 5/7] megaraid_
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:01 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 3/7] megaraid_
>-Original Message-
>From: Hannes Reinecke [mailto:h...@suse.de]
>Sent: Monday, October 17, 2016 5:04 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.peter...@oracle.com; the...@redhat.com;
j...@linux.vnet.ibm.com;
>kashyap.de...@broadcom.com
>Subject: Re: [PATCH 4/7] megaraid_
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does
> not support JBOD sequence map.
>
> CC: sta...@vger.kernel.org
> Signed-off-by: Sumit Saxena
> Signed-off-by: Kashyap Desai
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> Update MEGARAID drivers maintainers list.
>
> Signed-off-by: Sumit Saxena
> ---
> MAINTAINERS | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0ee7a6..8b9117f 100644
> --- a/MAINT
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer
> without sending it to firmware as firmware takes care of flushing cache.
> This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling.
> If underlying firmware has
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> Upgrade driver version.
>
> Signed-off-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megarai
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> This patch addresses the issue of driver firing DCMDs in PCI
> shutdown/detach path irrespective of firmware state.
> Driver will check for whether firmware is operational state or not
> before firing DCMDs. If firmware is in unrecoverbale
> state or do
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> This patch fixes the issue of wrong PhysArm was sent to firmware for R1
> VD downgrade.
>
> Signed-off-by: Kiran Kumar Kasturi
> Signed-off-by: Sumit Saxena
> ---
> drivers/scsi/megaraid/megaraid_sas_fp.c | 6 --
> 1 file changed, 4 insertions(+
On 10/17/2016 12:24 PM, Sumit Saxena wrote:
> For SRIOV enabled firmware, if there is a OCR(online controller reset)
> possibility driver set the convert flag to 1, which is not happening if
> there are outstanding commands even after 180 seconds.
> As driver does not set convert flag to 1 and stil
Upgrade driver version.
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 43fd14f..1d4de90 100644
--- a/drivers/scsi/megar
Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does
not support JBOD sequence map.
CC: sta...@vger.kernel.org
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 8
1 file changed, 4 insertions(+), 4 deletions(-
megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer
without sending it to firmware as firmware takes care of flushing cache.
This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling.
If underlying firmware has support to handle the SYNCHORNIZE_CACHE, driver
wil
Update MEGARAID drivers maintainers list.
Signed-off-by: Sumit Saxena
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f0ee7a6..8b9117f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7612,12 +7612,12 @@ S: Maintai
This patch fixes the issue of wrong PhysArm was sent to firmware for R1
VD downgrade.
Signed-off-by: Kiran Kumar Kasturi
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megara
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds.
As driver does not set convert flag to 1 and still making the OCR to run,
VF(Virtual function) driver
This patch addresses the issue of driver firing DCMDs in PCI
shutdown/detach path irrespective of firmware state.
Driver will check for whether firmware is operational state or not
before firing DCMDs. If firmware is in unrecoverbale
state or does not become operational within specfied time, driver
1 - 100 of 110 matches
Mail list logo
