S From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dqk3R588Mz3Zkn On 1/12/26 09:49, Michał Purzyński wrote: > Em seg., 12 de jan. de 2026 às 18:40, Mark Millard > escreveu: > > On 1/12/26 08:46, Michał Purzyński wrote: > > Hi everyone, > > > > I am encountering a consistent kernel panic on boot with my > Raspberry Pi > > 2 running FreeBSD 15 release. > > It would be good to provide the output from: > > # uname -apKU > > > Can't do - machine won't boot. >   Can you stop the boot at the loader prompt (so: before the FreeBSD kernel is started)? If yes, at the loader prompt a "boot -s" (single user mode boot) command would likely boot without enabling pf (and more). You likely could make sure that / is mounted rw and adjust the configuration to avoid pf --or avoid specific pf rules that lead to the problem. "exit" should then try to continue to the normal login prompt. > > > RPi2B v1.1? v1.2? v1.1 is armv7 (just 32-bit), not arm64/aarch64. > > For RPi2B v1.2, there could also be the question of armv7 vs. aarch64 > FreeBSD being used: > > FreeBSD-15.0-RELEASE-arm-armv7-GENERICSD.img.xz > vs. some equivalent of: > FreeBSD-15.0-RELEASE-arm64-aarch64-RPI.img.xz > > > It's ARMv7 i.e. 32 bit. >   Okay. I've added " [really armv7]" to the subject in my reply. > > > > > > The panic is an "Alignment Fault" that appears to trigger within | > > pf_state_insert| during IPv6 output*.* > > > > Fatal kernel mode data abort: 'Alignment Fault' on read > > trapframe: 0xdb38b560 > > FSR=00000001, FAR=c4cec394, spsr=60000013 > > r0 =c4cec394, r1 =c09a48e4, r2 =00000001, r3 =00000000 > > r4 =00000000, r5 =dc6eccc0, r6 =c097293c, r7 =dc6f0f80 > > r8 =dc6f1000, r9 =dc6ecd80, r10=dc6f0f80, r11=db38b640 > > r12=dbd9d3f8, ssp=db38b5f0, slr=dbd3fb70, pc =dbd2e290 > > > > panic: Fatal abort > > cpuid = 2 > > time = 1768162360 > > KDB: stack backtrace: > > #0 0xc0385dd8 at kdb_backtrace+0x40 > > #1 0xc032e230 at vpanic+0x140 > > #2 0xc032e0f0 at vpanic+0 > > #3 0xc0684194 at abort_align+0 > > #4 0xc0684204 at abort_align+0x70 > > #5 0xc0683e8c at abort_handler+0x430 > > #6 0xc0662814 at exception_exit+0 > > #7 0xdbd2e290 at pf_state_insert+0xb90 > > #8 0xdbd3fb70 at $a+0x2c8 > > #9 0xdbd3d7b8 at $a+0x224 > > #10 0xdbd5a04c at $a+0x34 > > #11 0xc048b9b4 at pfil_mbuf_out+0x44 > > #12 0xc05182c4 at ip6_output+0x1184 > > #13 0xc05359a0 at udp6_send+0x85c > > #14 0xc03e430c at sosend_dgram+0x4a8 > > #15 0xc03e535c at sousrsend+0x5c > > #16 0xc03ef70c at kern_sendit+0x198 > > #17 0xc03efbd8 at sendit+0x330 > > Uptime: 38s > > > > The panic happens +- every time I boot. I also tried unplugging > for like > > 30 sec with the same effect. The installation was uneventful: I just > > flashed the recent 15 release image, booted and restored my > > configuration files. LMK what other info I could capture. > > > > -- > > > > Michał Purzyński > > > > > > In case the context is actually for an RPi2B v1.1: > > FreeBSD networking has lots of problems with meeting the armv7 > configuration's alignment requirements. Past bugzilla reports include: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966 bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965 bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965> > > But those did not involve "pf" code, as I remember. > > Note: I'm not subscribed to the pf mail list and so removed the > reference. > > > -- > === > Mark Millard > marklmi at yahoo.com > I created an empty /etc/pf.conf and then tried: # service pf onestart # . . . some activity with networking involved . . . # service pf onestop on an armv7 running main and it did not fail. But this likely is not surprising with no rules. It may only be specific types of pf rules that lead to the failure. (I'm not pf literate overall.) To allow folks to try to reproduce the problem may require giving them information about your pf rule set or other pf related configuration information. -- === Mark Millard marklmi at yahoo.com