[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220726141458.GY25951@gate.crashing.org>
Date: Tue, 26 Jul 2022 09:14:58 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Pali Rohár <pali@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regression: Linux v5.15+ does not boot on Freescale P2020
On Tue, Jul 26, 2022 at 04:01:00PM +0200, Pali Rohár wrote:
> On Tuesday 26 July 2022 08:44:05 Segher Boessenkool wrote:
> > And the architecture says
> > Programming Note
> > Warning: On some processors that comply with versions of the
> > architecture that precede Version 2.00
>
> But e500v2 is 2.03 and not older than 2.00...
Yes. And it does not implement reserved fields in instructions (*any*
reserved fields in instructions, apparently!) correctly at all.
> > e500v1/v2 based chips will treat any reserved field being set in an
> > opcode as illegal.
> >
> > while the architecture says
> >
> > Reserved fields in instructions are ignored by the processor.
> >
> > Whoops :-) We need fixes for processor implementation bugs all the
> > time of course, but this is a massive *design* bug.
>
> I looked also in e500v2 and P2020 errata documents there is nothing
> mentioned about eh flag. But it looks like a bug.
The bug is if it does this for any reserved field (and it apparently
does it for all even).
> > Also people using an SMP kernel on older cores should see the problem,
> > no?
>
> Probably yes.
>
> But most people on these machines are using stable LTS kernels and do
> not upgrade too often.
Yeah.
> So you need to wait longer time to see people starting reporting such
> bugs. Need to wait at least when v4.14 and v4.19 LTS versions stops
> receiving updates. v4.19 is used in Debian 10 (oldstable) and v5.4 is
> used by current OpenWRT. Both distributions are still supported, so
> users have not migrated to new v5.15 problematic kernel yet.
That's not a reasonable timeline for kernel development of course.
We see the same thing with the compiler... Although GCC has a much
slower release cadence (one new major version every year), it often
takes two or three or more years before we get bug reports that
something was broken. If stuff isn't tested, we cannot really support
it at all.
Segher
Powered by blists - more mailing lists