On Thu 21-02-19 01:23:50, Meelis Roos wrote:
> > > First, I found out that both the problematic alphas had memory compaction
> > > and
> > > page migration and bounce buffers turned on, and working alphas had them
> > > off.
> > >
> > > Next, turing off these options makes the problematic
First, I found out that both the problematic alphas had memory compaction and
page migration and bounce buffers turned on, and working alphas had them off.
Next, turing off these options makes the problematic alphas work.
OK, thanks for testing! Can you narrow down whether the problem is due
On Wed 20-02-19 08:31:05, Meelis Roos wrote:
> > Could
> > https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
> > be relevant?
>
> Tried it, still broken.
OK, I didn't put too much hope into this patch as you see filesystem
metadata corruption so icache/dcache coherency
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, 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 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
Hum, weird. I have hard time understanding how that change could be causing
fs corruption on Aplha but OTOH it is not completely unthinkable. With this
commit we may migrate some block device pages we were not able to migrate
previously and that could be causing some unexpected issue. I'll look
On Sun 17-02-19 00:29:40, 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 bisecting
> > > between 4.20.0 and
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
On Fri, Feb 15, 2019 at 06:59:48PM +0200, 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 bisecting
> between 4.20.0 and the so far
I have noticed ext4 filesystem corruption on two of my test alphas with
4.20.0-09062-gd8372ba8ce28.
Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge
--sync just fail with nothing in dmesg.
Finished second round of bisecting, first round did not get me far
02.01.19 17:52 I wrote:
I have noticed ext4 filesystem corruption on two of my test alphas with
4.20.0-09062-gd8372ba8ce28.
Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge
--sync just fail with nothing in dmesg.
On AlphaServer DS10:
[10749.664418] EXT4-fs
13 matches
Mail list logo
