Re: A native armv7 panic during kyua runs: sys/netinet6/exthdr:exthdr -> Fatal kernel mode data abort: 'Alignment Fault' on read

On Aug 5, 2023, at 14:40, Mark Millard <[email protected]> wrote:

> On Aug 5, 2023, at 14:04, Mark Millard <[email protected]> wrote:
> 
>> On Aug 5, 2023, at 11:27, Michal Meloun <[email protected]> wrote:
>> 
>>> Hi Mark,
>>> can you please try a this patch?
>>> https://github.com/strejda/tegra/commit/bd4390c5f6a8b66b2fc83966d4fadb945a19dc23
>> 
>> I'll take a stab at testing it.
>> 
>> But I'll note that description of the patch is somewhat odd:
>> 
>> QUOTE
>> Pack IP structures directly used for access packet data.
>> All structures used to access data in byte buffers shall be marked
>> as packed. Otherwise, this is undefined behavior - formally on
>> every platform.
>> END QUOTE
>> 
>> __packed (and whatever it might be a macro for) is not part of
>> any vintage of the C standard, not even as explicitly
>> implementation defined nor as explicitly undefined. (C23's
>> "attribute specifier sequence" notation use would give an
>> implementation defined status as an understand, but not via
>> explicit identification of the concept of packed in the standard.)
>> As far as the language is concerned, there is no guarantee that
>> a code generator will ensure to break things up into aligned
>> accesses with assembly of the overall value if the members are
>> not aligned in the first place, __packed or not. Nor does the
>> language guarantee pack of padding in the layout for __packed.
>> 
>> Past that, it is toolchain specific if __packed would avoid
>> unaligned accesses for simple member access notation bytes
>> yet also avoid having pad bytes. We will see for this context.
>> (My history suggests a lack of overall uniformity in the
>> interpretations given to declaring struct's as packed --or
>> analogous wording for other languages that are not explicit
>> about it.)
>> 
>>> I'm sorry, but I don't have the time or energy to fully test it... I only hope the actual patch is much easier than the one listed in PR271759.
>> 
> 
> [Older history deleted.]
> 
> No notable change in behavior, I'm afraid . . .
> 
> sys/netinet6/exthdr:exthdr  ->  
> Fatal kernel mode data abort: 'Alignment Fault' on read
> trapframe: 0xc51fbaa0
> FSR=00000001, FAR=daed4476, spsr=60000013
> r0 =daf787c0, r1 =c51fbb34, r2 =00000000, r3 =00000000
> r4 =00000000, r5 =00000000, r6 =daed4476, r7 =daed4466
> r8 =c0965c3c, r9 =00000000, r10=db0e4400, r11=c51fbb60
> r12=00000000, ssp=c51fbb30, slr=c0b524c0, pc =c04e8e78
> 
> panic: Fatal abort
> cpuid = 1
> time = 1691270886
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>         pc = 0xc0661824  lr = 0xc007db80 (db_trace_self_wrapper+0x30)
>         sp = 0xc51fb858  fp = 0xc51fb970
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>         pc = 0xc007db80  lr = 0xc031a834 (vpanic+0x140)
>         sp = 0xc51fb978  fp = 0xc51fb998
>         r4 = 0x00000100  r5 = 0x00000000
>         r6 = 0xc07c5a9a  r7 = 0xc0b36e58
> vpanic() at vpanic+0x140
>         pc = 0xc031a834  lr = 0xc031a6f4 (vpanic)
>         sp = 0xc51fb9a0  fp = 0xc51fb9a4
>         r4 = 0xc51fbaa0  r5 = 0x00000013
>         r6 = 0xdaed4476  r7 = 0x00000001
>         r8 = 0x00000001  r9 = 0xdaf787c0
>        r10 = 0xdaed4476
> vpanic() at vpanic
>         pc = 0xc031a6f4  lr = 0xc0686ddc (abort_align)
>         sp = 0xc51fb9ac  fp = 0xc51fb9d8
>         r4 = 0x00000001  r5 = 0x00000001
>         r6 = 0xdaf787c0  r7 = 0xdaed4476
>         r8 = 0xc51fb9a4  r9 = 0xc031a6f4
>        r10 = 0xc51fb9ac
> abort_align() at abort_align
>         pc = 0xc0686ddc  lr = 0xc0686e50 (abort_align+0x74)
>         sp = 0xc51fb9e0  fp = 0xc51fb9f8
>         r4 = 0x00000013 r10 = 0xdaed4476
> abort_align() at abort_align+0x74
>         pc = 0xc0686e50  lr = 0xc0686aa8 (abort_handler+0x45c)
>         sp = 0xc51fba00  fp = 0xc51fba98
>         r4 = 0x00000000 r10 = 0xdaed4476
> abort_handler() at abort_handler+0x45c
>         pc = 0xc0686aa8  lr = 0xc06640d8 (exception_exit)
>         sp = 0xc51fbaa0  fp = 0xc51fbb60
>         r4 = 0x00000000  r5 = 0x00000000
>         r6 = 0xdaed4476  r7 = 0xdaed4466
>         r8 = 0xc0965c3c  r9 = 0x00000000
>        r10 = 0xdb0e4400
> exception_exit() at exception_exit
>         pc = 0xc06640d8  lr = 0xc0b524c0 (__pcpu+0x200)
>         sp = 0xc51fbb30  fp = 0xc51fbb60
>         r0 = 0xdaf787c0  r1 = 0xc51fbb34
>         r2 = 0x00000000  r3 = 0x00000000
>         r4 = 0x00000000  r5 = 0x00000000
>         r6 = 0xdaed4476  r7 = 0xdaed4466
>         r8 = 0xc0965c3c  r9 = 0x00000000
>        r10 = 0xdb0e4400 r12 = 0x00000000
> in6ifa_ifwithaddr() at in6ifa_ifwithaddr+0x30
>         pc = 0xc04e8e78  lr = 0xc04fb338 (ip6_input+0xd38)
>         sp = 0xc51fbb68  fp = 0xc51fbc28
>         r4 = 0xdaed4476  r5 = 0xdaed445e
>         r6 = 0x00000000  r7 = 0xdaed4466
> ip6_input() at ip6_input+0xd38
>         pc = 0xc04fb338  lr = 0xc046d66c (netisr_dispatch_src+0xf8)
>         sp = 0xc51fbc30  fp = 0xc51fbc58
>         r4 = 0xdaed4400  r5 = 0x00000006
>         r6 = 0x00000001  r7 = 0xc0b4dd50
>         r8 = 0xdaf9d900  r9 = 0xdaed4400
>        r10 = 0x00000086
> netisr_dispatch_src() at netisr_dispatch_src+0xf8
>         pc = 0xc046d66c  lr = 0xc04641b0 (ether_demux+0x18c)
>         sp = 0xc51fbc60  fp = 0xc51fbc78
>         r4 = 0x00000006  r5 = 0x00001201
>         r6 = 0xdb0e4400  r7 = 0x000000ff
>         r8 = 0xdaf9d900  r9 = 0xdaed4400
>        r10 = 0x00000086
> ether_demux() at ether_demux+0x18c
>         pc = 0xc04641b0  lr = 0xc0465880 (ether_nh_input+0x490)
>         sp = 0xc51fbc80  fp = 0xc51fbce0
>         r4 = 0xdb0e4400  r5 = 0xdaed4400
>         r6 = 0xdaed4450 r10 = 0x00000086
> ether_nh_input() at ether_nh_input+0x490
>         pc = 0xc0465880  lr = 0xc046d66c (netisr_dispatch_src+0xf8)
>         sp = 0xc51fbce8  fp = 0xc51fbd10
>         r4 = 0xdaed4400  r5 = 0x00000005
>         r6 = 0x00000003  r7 = 0xc0b4dd30
>         r8 = 0xdaf9d900  r9 = 0xdaed4400
>        r10 = 0xc098f58f
> netisr_dispatch_src() at netisr_dispatch_src+0xf8
>         pc = 0xc046d66c  lr = 0xc04645c4 (ether_input+0x50)
>         sp = 0xc51fbd18  fp = 0xc51fbd48
>         r4 = 0xdaed4400  r5 = 0x00000000
>         r6 = 0x00008803  r7 = 0x00000000
>         r8 = 0xdaf9d900  r9 = 0xdaed4400
>        r10 = 0xc098f58f
> ether_input() at ether_input+0x50
>         pc = 0xc04645c4  lr = 0xdffb3f08 ($a.10+0x108)
>         sp = 0xc51fbd50  fp = 0xc51fbd78
>         r4 = 0xdb0e4400  r5 = 0xdaff4000
>         r6 = 0xdaff4010  r7 = 0x00000000
>         r8 = 0x00000000 r10 = 0xc098f58f
> $a.10() at $a.10+0x108
>         pc = 0xdffb3f08  lr = 0xc038cb2c (taskqueue_run_locked+0x1c4)
>         sp = 0xc51fbd80  fp = 0xc51fbdd8
>         r4 = 0xdaff2100  r5 = 0xdaff402c
>         r6 = 0xdaff2150  r7 = 0x00000001
>         r8 = 0x00000000  r9 = 0xc51fbd90
>        r10 = 0x00000001
> taskqueue_run_locked() at taskqueue_run_locked+0x1c4
>         pc = 0xc038cb2c  lr = 0xc038e4e4 (taskqueue_thread_loop+0x1b0)
>         sp = 0xc51fbde0  fp = 0xc51fbe10
>         r4 = 0xdaff2100  r5 = 0xdaff2140
>         r6 = 0xc07b18c4  r7 = 0x00000000
>         r8 = 0xc098f58f  r9 = 0x00000100
>        r10 = 0xc0b268a0
> taskqueue_thread_loop() at taskqueue_thread_loop+0x1b0
>         pc = 0xc038e4e4  lr = 0xc02cdf0c (fork_exit+0xc0)
>         sp = 0xc51fbe18  fp = 0xc51fbe38
>         r4 = 0xdaf787c0  r5 = 0xc0b264e0
>         r6 = 0xc038e334  r7 = 0xdffc4f54
>         r8 = 0xc51fbe40  r9 = 0xc098f591
> fork_exit() at fork_exit+0xc0
>         pc = 0xc02cdf0c  lr = 0xc066406c (swi_exit)
>         sp = 0xc51fbe40  fp = 0x00000000
>         r4 = 0xc038e334  r5 = 0xdffc4f54
>         r6 = 0xc0b48d84  r7 = 0xd73bd3e0
>         r8 = 0x00000001 r10 = 0xc0b268a0
> swi_exit() at swi_exit
>         pc = 0xc066406c  lr = 0xc066406c (swi_exit)
>         sp = 0xc51fbe40  fp = 0x00000000
> KDB: enter: panic
> [ thread pid 0 tid 100226 ]
> 
> 
> I've just restored the sources involved but still have
> the .diff I that got via github.
> 

By the way, your request lead me to looking at my
material in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271759

some more. I've concluded it is not obvious to me if my
OrangePi+2Ed comments end up being evidence of an
independent issue vs. evidence of there being more than
potential if_ure issues involved. I ended up adding
Comment 35:


Hmm. Getting the problem on the built-in Ethernet did not
involve if_ure from what I can tell, looking at the dmsg -a
output:

. . .
awg0: <Allwinner Gigabit Ethernet> mem 0x1c30000-0x1c3ffff irq 27 on simplebus0
miibus0: <MII bus> on awg0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
. . .
Autoloading module: if_ure
ure0 on uhub6
ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/30.00, addr 2> on usbus7
miibus1: <MII bus> on ure0
rgephy2: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus1
rgephy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
ue0: <USB Ethernet> on ure0

if_ure would only be involved with the dongle (ure0), for which no
Ethernet cable was attached.

So I'm unsure if what I've reported for the OrangePi+2Ed context overall
is:

A) An independent problem.
vs.
B) Evidence that the original problem involves more than just potential
   if_ure issues.


===
Mark Millard
marklmi at yahoo.com