Dave,
>>
> Previously we had used sleep to delay until the controller got its
> mind back, but early testing indicated it wasn't needed. I'm good with
> this.
Applied to 4.14/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
>
>
> Guilherme,
>
> > James/Martin, am I expected to send a v2 with some change? Perhaps
> > with Dave's ack? Sorry to annoy, thanks in advance for any advice!
>
> I was just about to mail Dave and ask for confirmation that your
> interpretation
> of the controller behavior is correct.
>
>
Guilherme,
> James/Martin, am I expected to send a v2 with some change? Perhaps
> with Dave's ack? Sorry to annoy, thanks in advance for any advice!
I was just about to mail Dave and ask for confirmation that your
interpretation of the controller behavior is correct.
Dave?
--
Martin K. Peter
On 09/21/2017 01:19 PM, Dave Carroll wrote:
>> [...]
>> ---
> Acked-by: Dave Carroll
>
Thanks Dave!
James/Martin, am I expected to send a v2 with some change? Perhaps with
Dave's ack?
Sorry to annoy, thanks in advance for any advice!
Cheers,
Guilherme
vnet.ibm.com;
> dougm...@linux.vnet.ibm.com; sta...@vger.kernel.org
> Subject: [PATCH] scsi: aacraid: Add a small delay after IOP reset
>
> Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset
> status") changed the way driver checks if a reset succeeded.
On 09/19/2017 02:05 PM, James Bottomley wrote:
> Actually, the whole problem sounds like a posted write. Likely the
> write that causes the reset doesn't get flushed until the read checking
> if the reset has succeeded, which might explain the 100% initial
> failure. Why not throw away that first
On Tue, 2017-09-19 at 08:52 -0700, Christoph Hellwig wrote:
> On Tue, Sep 19, 2017 at 12:49:21PM -0300, Guilherme G. Piccoli wrote:
> >
> > On 09/19/2017 12:37 PM, Christoph Hellwig wrote:
> > >
> > > On Tue, Sep 19, 2017 at 12:11:55PM -0300, Guilherme G. Piccoli
> > > wrote:
> > > >
> > > >
On 09/19/2017 12:52 PM, Christoph Hellwig wrote:
> On Tue, Sep 19, 2017 at 12:49:21PM -0300, Guilherme G. Piccoli wrote:
>> On 09/19/2017 12:37 PM, Christoph Hellwig wrote:
>>> On Tue, Sep 19, 2017 at 12:11:55PM -0300, Guilherme G. Piccoli wrote:
src_writel(dev, MUnit.IDR, IOP_SRC_RESET_MAS
On Tue, Sep 19, 2017 at 12:49:21PM -0300, Guilherme G. Piccoli wrote:
> On 09/19/2017 12:37 PM, Christoph Hellwig wrote:
> > On Tue, Sep 19, 2017 at 12:11:55PM -0300, Guilherme G. Piccoli wrote:
> >>src_writel(dev, MUnit.IDR, IOP_SRC_RESET_MASK);
> >> +
> >> + msleep(5000);
> >
> > src_writel
On 09/19/2017 12:37 PM, Christoph Hellwig wrote:
> On Tue, Sep 19, 2017 at 12:11:55PM -0300, Guilherme G. Piccoli wrote:
>> src_writel(dev, MUnit.IDR, IOP_SRC_RESET_MASK);
>> +
>> +msleep(5000);
>
> src_writel is a writel, and thus a posted MMIO write. You'll need
> to have to a read fir
On Tue, Sep 19, 2017 at 12:11:55PM -0300, Guilherme G. Piccoli wrote:
> src_writel(dev, MUnit.IDR, IOP_SRC_RESET_MASK);
> +
> + msleep(5000);
src_writel is a writel, and thus a posted MMIO write. You'll need
to have to a read first to make it a reliable timing base.
Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset
status") changed the way driver checks if a reset succeeded. Now, after an
IOP reset, aacraid immediately start polling a register to verify the reset
is complete.
This behavior cause regressions on the reset path in PowerPC
12 matches
Mail list logo
