Re: Kernel panic on earm

So, we've got a 64-bit write in ifconfig according to Nick.

I updated the sources yesterday, and had a poke around.

Rebuilt the MARVELL_NAS kernel, and used sysinst to install the latest -current userland from nyftp.

On the NAS (MARVELL_NAS): everything in the userland I've tried works, but just running "ifconfig 
-a" results in the same panic.

I've also used the userland as chroot from my raspberry pi 1b (earmv6hf), and running ifconfig there works (to the extent it should work in a chroot), no panic of any kind.

Couple of questions:

1. Martin, can you manually confirm that this works on your Guruplug? I see that most automated tests have passed a few days ago, which implies it does. Seems there is no problem with the userland as that is identical to what I'm using, which brings us back to the kernel.

2. Should I raise a PR for that - Nick, what info do you think I should include?

Thanks

Michael

On Fri, 26 Oct 2018 at 12:06, Michael Blatt <michael.blatt%gmail.com@localhost> wrote:

I can confirm that with a different kernel build, same panic, different addresses but same error line in the same place:

addr2line -e netbsd/src/sys/arch/evbarm/compile/obj/NSA320s/netbsd.gdb -f c04cce88
ifioctl_common
/home/michael/netbsd/src/sys/net/if.c:2988

in function ifioctl_common()

2986     case SIOCGIFCAP:
2987         ifcr = data;
2988         ifcr->ifcr_capabilities = ifp->if_capabilities;
2989         ifcr->ifcr_capenable = ifp->if_capenable;
2990         break;

Michael

On Thu, 25 Oct 2018 at 22:50, Michael Blatt <michael.blatt%gmail.com@localhost> wrote:
Right, here we go...

the panic happens when setting up the loopback interface as I initially suspected. I've added the addr2line info next to the backtrace addresses below.
The key seems to be in ifioctl_common() at src/sys/net/if.c:2988

Starting network.
[ 32.8299972] Fatal kernel mode data abort: 'Alignment Fault 1'
[ 32.8299972] trapframe: 0xcc7d1bc8
[ 32.8299972] FSR=00000001, FAR=cc7d1ddc, spsr=60000013
[ 32.8299972] r0 =c29b23c0, r1 =cc7d1dcc, r2 =00000000, r3 =00000000
[ 32.8299972] r4 =c04f1e5c, r5 =00022078, r6 =bfffdfd0, r7 =00000010
[ 32.8299972] r8 =bbc0d180, r9 =bfffe0a8, r10=bbc17b65, r11=cc7d1c44
[ 32.8299972] r12=cc7d1c48, ssp=cc7d1c18, slr=c04f9798, pc =c04f1a2c

Stopped in pid 95.1 (ifconfig) at c04f1a2c: strd r2, [r1, #0x10]
db> bt
0xcc7d1c44: c04f14e4 ifioctl_common /home/michael/netbsd/src/sys/net/if.c:2888
0xcc7d1c74: c04f9798 loioctl /home/michael/netbsd/src/sys/net/if_loop.c:523
0xcc7d1d74: c04f2350 doifioctl /home/michael/netbsd/src/sys/net/if.c:3248
0xcc7d1da4: c045d68c soo_ioctl /home/michael/netbsd/src/sys/kern/sys_socket.c:212
0xcc7d1e84: c044dd48 sys_ioctl /home/michael/netbsd/src/sys/kern/sys_generic.c:671
0xcc7d1eac: c001aa28 sy_call /home/michael/netbsd/src/sys/sys/syscallvar.h:65
0xcc7d1edc: c001ab10 sy_invoke /home/michael/netbsd/src/sys/sys/syscallvar.h:94
0xcc7d1f8c: c001b058 syscall /home/michael/netbsd/src/sys/arch/arm/arm/syscall.c:250
0xcc7d1fac: c001ad34 swi_handler /home/michael/netbsd/src/sys/arch/arm/arm/syscall.c:172

addr2line -e sys/arch/evbarm/compile/obj/NSA320s/netbsd.gdb -f c04f1a2c
ifioctl_common
/home/michael/netbsd/src/sys/net/if.c:2988
I noticed that the addresses vary slightly for each kernel build (I should probably enable MKREPRO and all that), so will re-run the same tests tomorrow and check whether the bt is any different.

Michael

On Thu, 25 Oct 2018 at 18:47, Nick Hudson <nick.hudson%gmx.co.uk@localhost> wrote:

On 25/10/2018 17:49, Michael Blatt wrote:
> OK, so...
> I inserted boothowto |= AB_DEBUG to
> sys/arch/evbarm/marvell/marvell_machdep.c under initarm() as that made
> sense, is this correct?
>
> the panic is
> Starting network.
> [ 32.7799960] Fatal kernel mode data abort: 'Alignment Fault 1'
> [ 32.7799960] trapframe: 0xcc7d1bc8
> [ 32.7799960] FSR=00000001, FAR=cc7d1ddc, spsr=60000013
> [ 32.7799960] r0 =c29b33c0, r1 =cc7d1dcc, r2 =00000000, r3 =00000000
> [ 32.7799960] r4 =c04f060c, r5 =00022078, r6 =bfffdfd0, r7 =00000010
> [ 32.7799960] r8 =bbc0d180, r9 =bfffe0a8, r10=bbc17b65, r11=cc7d1c44
> [ 32.7799960] r12=cc7d1c48, ssp=cc7d1c18, slr=c04f7f48, pc =c04f01dc
>
> Stopped in pid 95.1 (ifconfig) at c04f01dc: strd r2, [r1, #0x10]
> db>
>
> db> bt
> 0xcc7d1c44: c04efc94
> 0xcc7d1c74: c04f7f48
> 0xcc7d1d74: c04f0b00
> 0xcc7d1da4: c045be3c
> 0xcc7d1e84: c044c4f8
> 0xcc7d1eac: c001a568
> 0xcc7d1edc: c001a650
> 0xcc7d1f8c: c001ab98
> 0xcc7d1fac: c001a874

Left hand number is stack (or frame pointer, I forget which) and right
is the PC values that need to run through addr2line

Doesn't look like stack is ever aligned :S

>
> On another NetBSD machine (armv6) I looked at the kernel used:
> addr2line -e netbsd -f 0xc04f01dc

You need to use a netbsd.gdb

./build.sh -m evbearmv5-el -O ../obj.evbearmv5-el tools

on your fastest unix-like machine will give you a cross addr2line

Nick