[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 27 Dec 2024 19:55:38 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028

--- Comment #315 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
Created attachment 256204
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256204&action=edit
patch attempting automatic hwatchpoint assignment

I added validation of lack of matching expected tqe_next
that should point to the newly added node to the
found_modules list. (This panic has as new message.)

If that passes, then if it is one of the 3 expected failure
nodes (based on name), it tries enabling a HW watch point
on the potentially problematical tqe_next field.

The hope here is to get a backtrace showing what code
incorrectly modified the tqe_next field. It may well
be code that does not have debug information or other
such.

I'm not sure if a dump will be automatic vs. your
having to use the command at the ddb> prompt. (Presuming
this works.)

There is the possibility that drm-510-kmod with more than
normal symbols and/or with debug information could end up
being requested, if such can be set up. It likely would
depend on where the bad modification is shown to be from
(if this works).



There is no attempt to cleanup the hardware watch points.
The patches are only intended to be for boot evidence
gathering, not for any general operation. Potentially
keep separate kernel directories under differing names
in /boot/ so you can switch it to something more
appropriate for general operation if you also need such.
But be sure that the investigative kernel is using
/boot/kernel/ .



(I've not done these sorts of things with ddb since back
in my powerpc64 / powerpc (32-bit) days.)

-- 
You are receiving this mail because:
You are the assignee for the bug.