On Fri, Jun 23, 2017 at 03:16:09AM +, Madhani, Himanshu wrote:
> if this is not *must* i’ll like to post patch for this with other patches
> that I am going to queue up during rc1 phase.
Ok.
[...]
> I saw your response to James that this is okay for FC NVMe code.
>
> > [...]
> >
> >> +
Hi Johannes,
> On Jun 22, 2017, at 2:46 AM, Johannes Thumshirn wrote:
>
> On Wed, Jun 21, 2017 at 01:48:43PM -0700, Madhani, Himanshu wrote:
> [...]
>> +wait_queue_head_t nvme_ls_waitQ;
>
> Can you please lower-case the 'Q' in waitQ IFF you have to re-send the series?
sure.
>
> [...]
>>
在 2017/6/23 9:05, Subhash Jadavani 写道:
On 2017-06-22 04:51, Arnd Bergmann wrote:
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
+Optional properties for board device:
+- ufs-hi3660-use-rate-B
On Thu, 22 Jun 2017, Ondrej Zary wrote:
> Works only with HDD on non-DTC chips. CD-ROM hangs. DTC hangs even with
> HDD. The PDMA code really needs to be fixed.
>
Does this patch help? It should be applied on top of this series of 4.
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5
On 2017-06-22 04:51, Arnd Bergmann wrote:
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-brok
On Thursday 15 June 2017 14:17:56 Finn Thain wrote:
> Ondrej, would you please test this patch series? One of your patches
> has been modified slightly and the two I wrote are untested.
Works only with HDD on non-DTC chips. CD-ROM hangs. DTC hangs even with HDD.
The PDMA code really needs to be fi
> On Jun 21, 2017, at 9:15 PM, Uma Krishnan wrote:
>
> The cxlflash driver currently lacks host management interface. Future
> devices supported by cxlflash will provide a variety of host-wide
> management functions. Examples include LUN provisioning, hardware debug
> support, and firmware downlo
> On Jun 21, 2017, at 9:15 PM, Uma Krishnan wrote:
>
> To date, CXL flash devices do not support a single command abort operation.
> Instead, the SISLite specification provides a context reset operation to
> cleanup all pending commands for a given context.
>
> When a context reset is successful
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> Currently, there is no book keeping of the pending scsi commands in the
> cxlflash driver. This lack of tracking in-flight requests is too
> restrictive and requires a heavy-hammer reset each time an adapter error is
> encountered. Additional
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> When the AFU is reset in an error path, pending scsi commands can be
> silently dropped without completion or a formal abort. This puts the onus
> on the cxlflash driver to notify mid-layer and indicating that the command
> can be retried.
>
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> AFU sync operations are not currently evaluated for failure. This is
> acceptable for paths where there is not a dependency on the AFU being
> consistent with the host. Examples include link reset events and LUN
> cleanup operations. On paths
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> Per the SISLite specification, context_reset() writes 0x1 to the LSB of the
> reset register. When the AFU processes this reset request, it is expected
> to clear the bit after reset is complete. The current implementation simply
> checks tha
> On Jun 21, 2017, at 9:14 PM, Uma Krishnan wrote:
>
> A context reset failure indicates the AFU is in a bad state. At present,
> when such a situation occurs, no further action is taken. This leaves the
> adapter in an unusable state with no recoverable actions.
>
> To avoid this situation, con
> On Jun 21, 2017, at 9:13 PM, Uma Krishnan wrote:
>
> The cxlflash_afu_sync() routine returns a negative one to indicate any kind
> of failure. This makes it impossible to establish why the error occurred.
>
> Update the return codes to clearly indicate the failure cause to the
> caller.
>
> S
> On Jun 21, 2017, at 9:13 PM, Uma Krishnan wrote:
>
> Currently there are separate spin locks for the two supported I/O queueing
> models. This makes it difficult to serialize with paths outside the enqueue
> path.
>
> As a design simplification and to support serialization with enqueue
> opera
Two fixes to remove spurious WARN_ONs from the new(ish) qedi driver.
The driver already prints a warning message, there's no need to panic
users by printing something that looks like an oops as well.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-f
On Thu, Jun 22, 2017 at 10:48:46AM -0700, James Smart wrote:
> He can't move it. the fcport->nvme_remote_port pointer is set by the
> nvme_fc_register_remoteport() routine (if return status is 0).
Gah, that's kind of wired. Literly _all_ of the Kernel's register_xxx()
funtions have a semantic that
On Thu, Jun 22, 2017 at 08:52:14AM -0700, James Smart wrote:
> well, the primary reason is the code that was removed was bogus to begin
> with. Abort of an io/exchange, if its active, needs to occur on the link
> regardless of the ndlp state. This it simply needed to occur. As not checks
> on ndlp
Dear Friend
I am contacting you on a business deal of $9,500,000.00 Million United States
Dollars, ready for transfer into your own personal account and if we make this
claim, we will share it on the ratio of 50% / 50% basis, I would like to assure
you that it be 100% risk free and it will be l
From: Colin Ian King
The function hptiop_iop_request_callback_itl does not need to be in
global scope, so make it static.
Cleans up sparse warning:
"symbol 'hptiop_iop_request_callback_itl' was not declared. Should it
be static?"
Signed-off-by: Colin Ian King
---
drivers/scsi/hptiop.c | 2 +-
On 6/22/2017 12:41 AM, Johannes Thumshirn wrote:
On Wed, Jun 21, 2017 at 10:37:58AM -0700, James Smart wrote:
[...]
- /*
-* Catch race where our node has transitioned, but the
-* transport is still transitioning.
-*/
The patch looks fine but can you please explai
Hello Christoph,
On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq
> I/O
> path now that we had plenty of testing, and have I/O schedulers for
> blk-mq. The module option to disable the blk-mq path is kept around
> for
On 22/06/2017 14:43, Johannes Thumshirn wrote:
In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the
qpair->qp_lock but do access members of the qpair before having the lock.
Re-order the locking sequence to have all read and write access to qpair
members under the qpair->qp_lock.
On Thu, Jun 22, 2017 at 03:19:27PM +0100, John Garry wrote:
> On 22/06/2017 14:43, Johannes Thumshirn wrote:
> >In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the
> >qpair->qp_lock but do access members of the qpair before having the lock.
> >Re-order the locking sequence to have
On 06/22/2017 03:43 PM, Johannes Thumshirn wrote:
> In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the
> qpair->qp_lock but do access members of the qpair before having the lock.
> Re-order the locking sequence to have all read and write access to qpair
> members under the qpair->
In qla2xx_start_scsi_mq() and qla2xx_dif_start_scsi_mq() we grab the
qpair->qp_lock but do access members of the qpair before having the lock.
Re-order the locking sequence to have all read and write access to qpair
members under the qpair->qp_lock.
Signed-off-by: Johannes Thumshirn
---
drivers/
在 2017/6/22 20:15, Arnd Bergmann 写道:
On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao wrote:
在 2017/6/22 19:51, Arnd Bergmann 写道:
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
I do not know wheher other SoC need
On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao wrote:
> 在 2017/6/22 19:51, Arnd Bergmann 写道:
>> On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
>>> 在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
>>>
>>> I do not know wheher other SoC need to use the optional prop
File size before:
textdata bss dec hex filename
409111432 304 42647a697 drivers/block/cciss.o
File size After adding 'const':
textdata bss dec hex filename
410391304 304 42647a697 drivers/block/cciss.o
Signed-off-by: Arvind Yad
在 2017/6/22 19:51, Arnd Bergmann 写道:
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-
在 2017/6/17 5:51, Arnd Bergmann 写道:
On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
add ufs node document for hi3660
Signed-off-by: Bu Tao
---
.../devicetree/bindings/ufs/hi3660-ufs.txt | 58 ++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/d
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao wrote:
> 在 2017/6/17 5:51, Arnd Bergmann 写道:
>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao wrote:
>>> +Optional properties for board device:
>>> +- ufs-hi3660-use-rate-B: specifies UFS rate-B
>>> +- ufs-hi3660-broken-fastauto : specifies no f
Assign rxq to TCP connections in round robin mode
to use all available rxqs.
Signed-off-by: Varun Prakash
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 5 -
drivers/scsi/cxgbi/libcxgbi.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
On Thu, Jun 22, 2017 at 05:58:44PM +0800, Yadan Fan wrote:
> The hpsa firmware will bypass the cache for any request larger
> than 1MB, so we should cap the request size to avoid any
> performance degradation in SLE12-SP2.
Upstream doesn't care too much about SLES.
> References: bsc#1025461
and
The smartpqi firmware will bypass the cache for any request larger
than 1MB, so we should cap the request size to avoid any
performance degradation on SLE12-SP2
This degradation is caused from d2be537c3ba3568acd79cd178327b842e60d035e,
which changed max_sectors_kb to 1280k, but the hardware is able
The hpsa firmware will bypass the cache for any request larger
than 1MB, so we should cap the request size to avoid any
performance degradation in SLE12-SP2.
This degradation is caused from d2be537c3ba3568acd79cd178327b842e60d035e,
which changed max_sectors_kb to 1280k, but the hardware is able to
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Ke
On Wed, Jun 21, 2017 at 01:48:44PM -0700, Madhani, Himanshu wrote:
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnber
On Wed, Jun 21, 2017 at 01:48:43PM -0700, Madhani, Himanshu wrote:
[...]
> + wait_queue_head_t nvme_ls_waitQ;
Can you please lower-case the 'Q' in waitQ IFF you have to re-send the series?
[...]
> + wait_queue_head_t nvme_waitQ;
Ditto
[...]
> + wait_queue_head_t nvme_waitQ;
And her
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
On Wed, Jun 21, 2017 at 10:37:58AM -0700, James Smart wrote:
[...]
> - /*
> - * Catch race where our node has transitioned, but the
> - * transport is still transitioning.
> - */
The patch looks fine but can you please explain why the above race can't
happen anymore?
Thanks,
R
41 matches
Mail list logo
