npf panic - need some clues
John Klos <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.network,gmane.os.netbsd.ports.arm |
|---|---|
| Message-ID | <[email protected]> |
Hi, I have a colocated aarch64 machine (Raspberry Pi 4) running NetBSD 10.0_BETA from 9-September-2023. It has a very simple npf setup that blocks from lpm file with 69 (so far) addresses / networks. It routes a public class C in to several subnets over tinc, but has no special rules - just straight routing. It has panicked like this before, running NetBSD 9.99.99 from about a year ago, so I updated it and hoped the issue was fixed, but it panicked again. Does anyone have any clue about what's happening here, and what to check / try in the future? Thanks, John [ 2828128.148194] panic: Trap: Data Abort (EL1): Translation Fault L0 with write access for 0000000000000000: pc ffffc00000595da4: stp x27, x19, [x0] [ 2828128.168580] cpu0: Begin traceback... [ 2828128.168580] trace fp ffffc00255d372a0 [ 2828128.168580] fp ffffc00255d372d0 vpanic() at ffffc000005929a8 netbsd:vpanic+0x178 [ 2828128.182376] fp ffffc00255d37330 panic() at ffffc00000592ab4 netbsd:panic+0x44 [ 2828128.190012] fp ffffc00255d373c0 data_abort_handler() at ffffc000000b599c netbsd:data_abort_handler+0x1ec [ 2828128.200772] tf ffffc00255d37430 el1_trap() at ffffc000000b6f84 netbsd:el1_vectors+0x784 [ 2828128.200772] ---- Data Abort (EL1): trapframe 0xffffc00255d37430 (304 bytes) ---- [ 2828128.217518] pc=ffffc00000595da4, spsr=0000000040000005 [ 2828128.223504] esr=0000000096000044, far=0000000000000000 [ 2828128.223504] x0=0000000000000000, x1=ffffc00000d53010 [ 2828128.235478] x2=0000000000000000, x3=0000000000000001 [ 2828128.235478] x4=0000000000000001, x5=0000000000000003 [ 2828128.247452] x6=0000000000000006, x7=00000000000fdf9a [ 2828128.247452] x8=00000000000045a2, x9=0000000005ac3845 [ 2828128.259427] x10=0000000000000004, x11=ffffc00000fbdb00 [ 2828128.259427] x12=ffffff0009574dcc, x13=ffffff0009574dd1 [ 2828128.271401] x14=0000000000000020, x15=ffffc00255d37450 [ 2828128.271401] x16=ffffc00000004520, x17=0000000024db2221 [ 2828128.283376] x18=000000007d79aa6f, x19=0000000000000018 [ 2828128.283376] x20=0000000000000000, x21=ffff0001fd164680 [ 2828128.295349] x22=0000000000000000, x23=ffff0001fd1646a0 [ 2828128.295349] x24=ffffc0000090f848, x25=ffffc000009be548 [ 2828128.307323] x26=ffffc0000090e000, x27=ffff000172449fe0 [ 2828128.307323] x28=ffff0000f87b8b81, fp=x29=ffffc00255d37760 [ 2828128.319297] lr=x30=ffffc00000595d9c, sp=ffffc00255d37760 [ 2828128.319297] ------------------------------------------------ [ 2828128.331272] fp ffffc00255d37760 stage_mem_gc() at ffffc00000595da4 netbsd:stage_mem_gc+0x54 [ 2828128.339342] fp ffffc00255d377d0 thmap_del() at ffffc000005976b0 netbsd:thmap_del+0x530 [ 2828128.339342] fp ffffc00255d378d0 npf_conndb_remove() at ffffc00000344f34 netbsd:npf_conndb_remove+0x40 [ 2828128.355048] fp ffffc00255d37900 npf_conn_establish() at ffffc00000342a8c netbsd:npf_conn_establish+0x28c [ 2828128.364679] fp ffffc00255d37990 npfk_packet_handler() at ffffc0000033a5c4 netbsd:npfk_packet_handler+0x4d4 [ 2828128.374970] fp ffffc00255d37aa0 pfil_run_hooks() at ffffc0000066c4e0 netbsd:pfil_run_hooks+0x110 [ 2828128.384681] fp ffffc00255d37b50 ipintr() at ffffc000002cd87c netbsd:ipintr+0x318 [ 2828128.394683] fp ffffc00255d37d00 softint_dispatch() at ffffc000005589a8 netbsd:softint_dispatch+0xf4 [ 2828128.394683] fp ffffc00255d27c60 cpu_switchto_softint() at ffffc000000b07cc netbsd:cpu_switchto_softint+0x7c [ 2828128.410840] fp ffffc00255d27c90 mutex_spin_enter() at ffffc0000053dc34 netbsd:mutex_spin_enter+0x270 [ 2828128.420558] fp ffffc00255d27d20 pmap_tlb_pai_check.constprop.0() at ffffc000000bd8f4 netbsd:pmap_tlb_pai_check.constprop.0+0x184 [ 2828128.431231] fp ffffc000009b22f0 cpu_info_store() at ffffc00000c6f92c ffffc00000c6f92c [ 2828128.441730] cpu0: End traceback... [ 2828128.441730] dumping to dev 168,6 offset 302703 [ 2828128.441730] dump i/o error [ 2828128.457021] rebooting...