Re: [bisected] ext4 corruption on parisc since 6.12

[John David Anglin]

On 2024-12-02 1:30 a.m., Magnus Lindholm wrote:
> On Mon, Dec 2, 2024 at 5:55 AM matoro
> <matoro_mailinglist_kernel@xxxxxxxxx> wrote:
> > Hmm, this is my config, also on an rp3440:
> >
> > #
> > # Timers subsystem
> > #
> > CONFIG_HZ_PERIODIC=y
> > # CONFIG_NO_HZ_IDLE is not set
> > # CONFIG_NO_HZ is not set
> > # CONFIG_HIGH_RES_TIMERS is not set
> > # end of Timers subsystem
> >
> > lindholm can confirm on their hardware/config.  Maybe you can try that and
> > see if you can reproduce?  I will try your config as well.
> Hi, I'm on a HPC8000 "parisc64 PA8800 (Mako) 9000/785/C8000". I can confirm
> that building a kernel CONFIG_SMP=n will mitigate this problem.
> I haven't messed around with the config in the Timer subsystem so in my case the
> parameters suggested are unset. (my config looks like matoros)
The clockevent driver was tested on both rp3440 and c8000, and some other SMP machines.
Helge knows details.  I have used it on rp3440 and c8000.

I would try my settings.  The primary reason in switching to the clockevent drivers was to
improve clock resolution.  The best resolution with the old drivers was 1 ms at 1000 HZ.
This caused problems with various package tests.  If config is the issue, probably
CONFIG_HIGH_RES_TIMERS needs to be forced when clockevent drivers are used.

Almost every other system uses the clockevent drivers.  So, there was a risk that parisc would
become unsupported.

I wonder if this could be caused by dead RTC battery.  Did you check output of date command?
Maybe a dead RTC battery interacts badly with clockevent drivers.

I run ntp on all my machines.

What files have bad dates (i.e., is this really a ext4 file system issue) or is it just that system has
a bad clock?

Dave

--
John David Anglin  dave.anglin@xxxxxxxx