[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.