Date: Mon, 12 Feb 2024 09:36:46 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Michael Butler <imb@protected-networks.net>, Mark Millard <marklmi@yahoo.com>, FreeBSD ARM List <freebsd-arm@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Bakul Shah <bakul@iitbombay.org> Subject: Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: <pcib1 memory window> request" leads to panic Message-ID: <b060f465-57ef-47cf-9a4f-30f6f39fbf62@FreeBSD.org> In-Reply-To: <b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net> References: <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5.ref@yahoo.com> <76AB969F-5BC5-4116-8AF4-3ED2CABEBBA5@yahoo.com> <2FE8FA48-180B-4F0D-BCD8-F7F33053B0F7@iitbombay.org> <986D2CD6-6241-4EBE-8BD2-9821AB693BA7@yahoo.com> <b0416b04-68a1-4aa5-9e9c-4d8a82279ac8@protected-networks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/10/24 2:09 PM, Michael Butler wrote: > I have stability problems with anything at or after this commit > (b377ff8) on an amd64 laptop. While I see the following panic logged, no > crash dump is preserved :-( It happens after ~5-6 minutes running in KDE > (X). > > Reverting to 36efc64 seems to work reliably (after ACPI changes but > before the problematic PCI one) > > kernel: Fatal trap 12: page fault while in kernel mode > kernel: cpuid = 2; apic id = 02 > kernel: fault virtual address = 0x48 > kernel: fault code = supervisor read data, page not present > kernel: instruction pointer = 0x20:0xffffffff80acb962 > kernel: stack pointer = 0x28:0xfffffe00c4318d80 > kernel: frame pointer = 0x28:0xfffffe00c4318d80 > kernel: code segment = base 0x0, limit 0xfffff, type 0x1b > kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > kernel: processor eflags = interrupt enabled, resume, IOPL = 0 > kernel: current process = 2 (clock (0)) > kernel: rdi: fffff802e460c000 rsi: 0000000000000000 rdx: 0000000000000002 > kernel: rcx: 0000000000000000 r8: 000000000000001e r9: fffffe00c4319000 > kernel: rax: 0000000000000002 rbx: fffff802e460c000 rbp: fffffe00c4318d80 > kernel: r10: 0000000000001388 r11: 000000007ffc765d r12: 000f000000000000 > kernel: r13: 0002000000000000 r14: fffff8000193e740 r15: 0000000000000000 > kernel: trap number = 12 > kernel: panic: page fault > kernel: cpuid = 2 > kernel: time = 1707573802 > kernel: Uptime: 6m19s > kernel: Dumping 942 out of 16242 > MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..92% > kernel: Dump complete > kernel: Automatic reboot in 15 seconds - press a key on the console to abort Without a stack trace it is pretty much impossible to debug a panic like this. Do you have KDB_TRACE enabled in your kernel config? I'm also not sure how the PCI changes can result in a panic post-boot. If you were going to have problems they would be during device attach, not after you are booted and running X. Short of a stack trace, you can at least use lldb or gdb to lookup the source line associated with the faulting instruction pointer (as long as it isn't in a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' and then 'l *<instruction pointer address>', e.g. from above: 'l *0xffffffff80acb962' -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b060f465-57ef-47cf-9a4f-30f6f39fbf62>