Could
https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
be relevant?
Tried it, still broken.
I wrote:
But my kernel config had memory compaction (that turned on page migration) and
bounce buffers. I do not remember why I found them necessary but I will try
without
On Tue, 19 Feb 2019, Mikulas Patocka wrote:
> > As I say, shouldn't the barrier be in `iowriteX' instead? I don't
> > suppose these are allowed to be weakly ordered.
> >
> > Maciej
>
> iowriteX is for memory-mapped I/O, out[bwl] is for I/O ports.
Well, actually `iowriteX' is generic and
On Tue, 19 Feb 2019, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 2:44 PM Mikulas Patocka wrote:
> > On Tue, 19 Feb 2019, Mikulas Patocka wrote:
> >
> > > The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
> > > 92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where
On Tue, 19 Feb 2019, Maciej W. Rozycki wrote:
> On Tue, 19 Feb 2019, Arnd Bergmann wrote:
>
> > We clearly need this patch, but I assumed the alpha maintainers would pick
> > it up, not me. I merged the original changes since they were
> > cross-architecture,
> > but I don't normally take
On Tue, 19 Feb 2019, Arnd Bergmann wrote:
> We clearly need this patch, but I assumed the alpha maintainers would pick
> it up, not me. I merged the original changes since they were
> cross-architecture,
> but I don't normally take patches for a particular architecture through the
> asm-generic
On Tue, Feb 19, 2019 at 02:20:26PM +0100, Jan Kara wrote:
> Thanks for information. Yeah, that makes somewhat more sense. Can you ever
> see the failure if you disable CONFIG_TRANSPARENT_HUGEPAGE? Because your
> findings still seem to indicate that there' some problem with page
> migration and
On Tue, Feb 19, 2019 at 2:44 PM Mikulas Patocka wrote:
> On Tue, 19 Feb 2019, Mikulas Patocka wrote:
>
> > The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
> > 92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where the
> > code didn't follow the specification.
The patches cd0e00c106722eca40b38ebf11cf134c01901086 and
92d7223a74235054f2aa7227d207d9c57f84dca0 fix a theoretical issue where the
code didn't follow the specification. Unfortunatelly, they also reduce
timing when port write is followed by a port read.
These reduced timing cause hang on boot on
On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka wrote:
> > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> >
> > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka
> > > wrote:
> > > > On Sun, 19 Aug 2018, ok...@codeaurora.org wrote:
> > > >
> > > > >
On Tue 19-02-19 14:17:09, Meelis Roos wrote:
> > > > > The result of the bisection is
> > > > > [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration
> > > > > stalls for blkdev pages
> > > > >
> > > > > Is that result relevant for the problem or should I continue
> > > > >
The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
blkdev pages
Is that result relevant for the problem or should I continue bisecting between
4.20.0 and the so far first bad commit?
Can you try reverting the commit and see if it
11 matches
Mail list logo
