Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed

On Nov 8, 2024, at 04:49, Michal Meloun <mmel@freebsd.org> wrote:

> On 08.11.2024 4:15, Mark Millard wrote:
>> [I narrowed the artifact kernel range for the change in the type of
>> failure that happens.]
>> On Nov 7, 2024, at 17:43, Mark Millard <marklmi@yahoo.com> wrote:
>>> [The change to LLVM 19 is what leads to the Alignment
>>> Fault' on write failure. Details later below.]
>>> 
>>> On Nov 7, 2024, at 01:42, Mark Millard <marklmi@yahoo.com> wrote:
>>> 
>>>> . . .
> Hi Mark,
> 
> Please see https://reviews.freebsd.org/D47485

Wow. Use of the likes of:

#ifdef ARM_NEW_PMAP
. . .
#define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO /*name is misused by DMA */
. . .
#else
/* Memory attribute configuration. */
#define VM_MEMATTR_DEFAULT 0
#define VM_MEMATTR_UNCACHEABLE 1
+#endif

and later versions of the header realtive to
VM_MEMATTR_UNCACHEABLE goes back to:

QUOTE
author Ian Lepore <ian@FreeBSD.org> 2015-03-26 21:13:53 +0000
committer Ian Lepore <ian@FreeBSD.org> 2015-03-26 21:13:53 +0000
. . .
New pmap code for armv6. Disabled by default, option ARM_NEW_PMAP enables it.

This is pretty much a complete rewrite based on the existing i386 code. The patches have been circulating for a couple years and have been looked at by plenty of people, but I'm not putting anybody on the hook as having reviewed this in any formal sense except myself.

After this has gotten wider testing from the user community, ARM_NEW_PMAP will become the default and various dregs of the old pmap code will be removed.

Submitted by: Svatopluk Kraus <onwahe@gmail.com>,
              Michal Meloun <meloun@miracle.cz>
END QUOTE

So 9+ years, with after late-enough in 2016-May being with
unaligned access being supported.

> Unfortunately, I see 2 problems with llvm 19.
> 
> The first is regression, the compiler generates inline memset() accessing non-aligned data with sub-optimal instructions (with word access). This regression triggers bug in the kernel (which should be fixed in D47485).

If I read the just-above right, the LLVM 19 memset issue is a
sub-optimal issue rather than a its-broken issue: The
VM_MEMATTR_SO use is the aspect that is broken in the area.

(Given the below issue, general testing of the use of
VM_MEMATTR_NOCACHE instead seems problematical.)

> Second, regarding "panic: acquiring blockable sleep lock" is due to an bug in  lld.  It mis-links the ".ARM.exidx" section on the output binary, which is used by the stack unwinder in the kernel.
> I don't have a fix for this for now, so you have to use the linker from llvm18 as a workaround.

If I read the just-above right, the .ARM.exidx issue means that
main [so: 15] after the LLVM 19 update is simply broken for
armv7, at least for kernels, even with a kernel avoiding the
VM_MEMATTR_SO issue.

> I'm not sure if I have enough free cycles to manage both issues on the llvm side...

But you have already taken the analysis far beyond what I was
going to be able to figure out.

The major reason I still have armv7 active in my environment
is to notice when some of these sorts of oddities show up in
my simple context and to report some evidence about them when
they happen: some earlier reporting.

So, my armv7 context is not really broken by being broken. It
is serving its purpose.

I'll just leave the boot media as-is for the world (so:
pre-LLVM19) until I have a (then) modern kernel that again
works. I've got older kernels that work for this context that
I'll keep around for now as well.

[I've dropped Doug and Kyle from the CC based on your analysis.]

Thanks,
Mark

===
Mark Millard
marklmi at yahoo.com