On 18/02/2019 07:21, Hannes Reinecke wrote:
On 2/15/19 10:16 AM, John Garry wrote:
On 15/02/2019 08:08, Christoph Hellwig wrote:
On Fri, Feb 15, 2019 at 08:43:55AM +0100, Christoph Hellwig wrote:
On Fri, Feb 15, 2019 at 07:55:39AM +0100, Hannes Reinecke wrote:
Yeah, there is a few more. And
On 18/02/2019 07:34, Hannes Reinecke wrote:
Hi Hannes,
Thanks for this. I have some comments, below.
The change to use dma_set_mask_and_coherent() incorrectly made a second
call with the 32 bit DMA mask value when the call with the 64 bit DMA
mask value succeeded.
And the second call to dma_
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:20AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:21AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:22AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:23AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded. This resulted in FC connections failing due
> to corrupted data
On Mon, Feb 18, 2019 at 08:34:24AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:26AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask() incorrectly made a second call with the
> 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Feb 18, 2019 at 08:34:25AM +0100, Hannes Reinecke wrote:
> The change to use dma_set_mask_and_coherent() incorrectly made a second
> call with the 32 bit DMA mask value when the call with the 64 bit DMA
> mask value succeeded. This resulted in FC connections failing due
> to corrupted data
On Sat, Feb 16, 2019 at 05:27:16PM +0100, Walter Harms wrote:
> Am 16.02.2019 15:44, schrieb Colin King:
> > From: Colin Ian King
> >
> > Currently m_sg->baseaddr_h (a 32 bit unsigned int) is being shifted by a
> > total of 32 bits; this always produces a 0 result. Fix this by casting
> > it to
Hi Bart,
Sorry to resend this, my previous reply had a stray backslash in the
headers (no idea why) that confused certain MTA, so at least Hannes did
not receive it.
I take benefit of this resend to update with the latest information, so
keep reading.
On Fri, 15 Feb 2019 07:56:11 -0800, Bart Van
Hi Michal,
This issue looks to be same as issue discussed in below URL thread,
https://patchwork.kernel.org/patch/10734933/
This issue happens only when MQ is enabled, can you please try once with
disabling the MQ?
Thanks,
Sreekanth
-Original Message-
From: linux-scsi-ow...@vger.kernel.
On 2/18/19 10:56 AM, Jean Delvare wrote:
Hi Bart,
Sorry to resend this, my previous reply had a stray backslash in the
headers (no idea why) that confused certain MTA, so at least Hannes did
not receive it.
I take benefit of this resend to update with the latest information, so
keep reading.
O
Hi Martin,
On Fri, 2019-02-15 at 22:30 -0500, Martin K. Petersen wrote:
> When evaluating the 'block limits' VPD page we need to check if the
> > 'lbpme' (logical block provisioning management enable) bit is set in
> > the READ CAPACITY (16) output. If it isn't we can safely assume that
> > we ca
On Tue, Sep 11, 2018 at 12:53:54PM +0200, Paul Menzel wrote:
> Dear Ming, dear Raghava, dear Dave,
>
>
> On 08/16/18 19:09, Paul Menzel wrote:
>
> > On 08/13/18 05:32, Ming Lei wrote:
> >> On Sat, Aug 11, 2018 at 03:50:21PM +0200, Greg Kroah-Hartman wrote:
> >>> On Sat, Aug 11, 2018 at 10:14:18A
On Mon, Feb 18, 2019 at 8:58 AM Sedat Dilek wrote:
>
> On Fri, Feb 15, 2019 at 6:35 PM Nathan Chancellor
> wrote:
> >
> > On Fri, Feb 15, 2019 at 01:19:20PM +0100, Hannes Reinecke wrote:
> > > From: Sedat Dilek
> > >
> > > commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate
On 2/18/19 11:09 AM, Sreekanth Reddy wrote:
Hi Michal,
This issue looks to be same as issue discussed in below URL thread,
https://patchwork.kernel.org/patch/10734933/
This issue happens only when MQ is enabled, can you please try once with
disabling the MQ?
Thanks,
Sreekanth
Yes, no issues
On Mon, 2019-02-18 at 12:37 +0300, Dan Carpenter wrote:
> On Sat, Feb 16, 2019 at 05:27:16PM +0100, Walter Harms wrote:
> > Am 16.02.2019 15:44, schrieb Colin King:
> > > From: Colin Ian King
> > >
> > > Currently m_sg->baseaddr_h (a 32 bit unsigned int) is being
> > > shifted by a
> > > total of
On Mon, Feb 18, 2019 at 07:32:05AM -0800, James Bottomley wrote:
> On Mon, 2019-02-18 at 12:37 +0300, Dan Carpenter wrote:
> > On Sat, Feb 16, 2019 at 05:27:16PM +0100, Walter Harms wrote:
> > > Am 16.02.2019 15:44, schrieb Colin King:
> > > > From: Colin Ian King
> > > >
> > > > Currently m_sg->
On Wed, Feb 13, 2019 at 5:01 PM Martin K. Petersen
wrote:
>
> Some devices come online in write protected state and switch to
> read-write once they are ready to process I/O requests. These devices
> broke with commit 20bd1d026aac ("scsi: sd: Keep disk read-only when
> re-reading partition") becau
On Tue, Feb 5, 2019 at 11:30 PM Hannes Reinecke wrote:
>
> Hi all,
>
> this came up during discussion on the mailing list (cf thread "Question
> on handling managed IRQs when hotplugging CPUs").
> The problem is that with managed IRQs and block-mq I/O will be routed to
> individual CPUs, and the r
On Fri, Feb 15, 2019 at 5:22 PM Jason Yan wrote:
>
> when create DMA pool for cmd frames failed, we should return -ENOMEM,
> instead of 0.
> In some case in:
>
> megasas_init_adapter_fusion()
>
> -->megasas_alloc_cmds()
>-->megasas_create_frame_pool
> create DMA pool fail
If we remove the scsi disk when running io with fio, oops occured with
the following condition.
[scsi_eh_0] [fio]
scsi_end_request
->blk_update_request
->end_bio(io returned to userspace)
close
24 matches
Mail list logo
