linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: matoro <matoro_mailinglist_kernel@matoro.tk>
To: Jan Kara <jack@suse.cz>
Cc: Meelis Roos <mroos@linux.ee>,
	Matthew Wilcox <willy@infradead.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	linux-alpha@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-block@vger.kernel.org, linux-mm@kvack.org
Subject: Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28
Date: Thu, 25 Aug 2022 11:05:48 -0400	[thread overview]
Message-ID: <97dbffaefa65a83b36e1ec134fd53a66@matoro.tk> (raw)
In-Reply-To: <20190221132916.GA22886@quack2.suse.cz>

Hello all, I know this is quite an old thread.  I recently acquired some 
alpha hardware and have run into this exact same problem on the latest 
stable kernel (5.18 and 5.19).  CONFIG_COMPACTION seems to be totally 
broken and causes userspace to be extremely unstable - random segfaults, 
corruption of glibc data structures, gcc ICEs etc etc - seems most 
noticable during tasks with heavy I/O load.

My hardware is a DS15 (Titan), so only slightly newer than the Tsunamis 
mentioned earlier.  The problem is greatly exacerbated when using a 
machine-optimized kernel (CONFIG_ALPHA_TITAN) over one with 
CONFIG_ALPHA_GENERIC.  But it still doesn't go away on a generic kernel, 
just pops up less often, usually very I/O heavy tasks like checking out 
a tag in the kernel repo.

However all of this seems to be dependent on CONFIG_COMPACTION.  With 
this toggled off all problems disappear, regardless of other options.  I 
tried reverting the commit 88dbcbb3a4847f5e6dfeae952d3105497700c128 
mentioned earlier in the thread (the structure has moved to a different 
file but was otherwise the same), but it unfortunately did not make a 
difference.

Since this doesn't seem to have a known cause or an easy fix, would it 
be reasonable to just add a Kconfig dep to disable it automatically on 
alpha?

Thank you!

-------- Original Message --------
Subject: Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28
Date: 2019-02-21 08:29
 From: Jan Kara <jack@suse.cz>
To: Meelis Roos <mroos@linux.ee>

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 alphas work.
> >
> > OK, thanks for testing! Can you narrow down whether the problem is due to
> > CONFIG_BOUNCE or CONFIG_MIGRATION + CONFIG_COMPACTION? These are two
> > completely different things so knowing where to look will help. Thanks!
> 
> Tested both.
> 
> Just CONFIG_MIGRATION + CONFIG_COMPACTION breaks the alpha.
> Just CONFIG_BOUNCE has no effect in 5 tries.

OK, so page migration is problematic. Thanks for confirmation!

								Honza

  reply	other threads:[~2022-08-25 15:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fb63a4d0-d124-21c8-7395-90b34b57c85a@linux.ee>
2019-02-10 20:27 ` ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28 Meelis Roos
2019-02-15 16:59   ` Meelis Roos
2019-02-16 17:45     ` Theodore Y. Ts'o
2019-02-16 22:29       ` Meelis Roos
2019-02-18 12:02         ` Jan Kara
2019-02-18 12:37           ` Meelis Roos
2019-02-19 12:17           ` Meelis Roos
2019-02-19 13:20             ` Jan Kara
2019-02-19 13:49               ` Meelis Roos
2019-02-19 14:44               ` Matthew Wilcox
2019-02-20  6:31                 ` Meelis Roos
2019-02-20  9:48                   ` Jan Kara
2019-02-20 23:23                     ` Meelis Roos
2019-02-21 13:29                       ` Jan Kara
2022-08-25 15:05                         ` matoro [this message]
2022-08-26 10:55                           ` Jan Kara
2022-08-26 11:04                             ` Vlastimil Babka
2022-08-26 16:16                               ` matoro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=97dbffaefa65a83b36e1ec134fd53a66@matoro.tk \
    --to=matoro_mailinglist_kernel@matoro.tk \
    --cc=jack@suse.cz \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mroos@linux.ee \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).