Date: Thu, 5 Jun 2025 08:04:16 -0700 From: Steve Kargl <kargls@comcast.net> To: freebsd-current@freebsd.org Subject: Re: drm panic after new world Message-ID: <1b756512-ef7c-4fd0-aaaa-9de5298b57ff@comcast.net> In-Reply-To: <p8040n66-6n6o-404o-s83n-p41994245s8p@SerrOFQ.bet> References: <aDi-PhLtvicg9Bbz@troutmask.apl.washington.edu> <aDjThAnfAfJB4KE7@troutmask.apl.washington.edu> <aD4nRhiexw1m7iUS@troutmask.apl.washington.edu> <c195592a-5734-44c3-85ca-01a05697b21b@FreeBSD.org> <4699f48c-f042-46fe-8f9a-419e86d51f58@comcast.net> <aD-HE849Okg5UXi5@troutmask.apl.washington.edu> <d461b9bf-ad7d-4d68-91d4-93e31bd00c89@comcast.net> <aECofvI79xZHYLYk@troutmask.apl.washington.edu> <8605cb6d-4121-4733-bc5f-c66c6358ea04@comcast.net> <p8040n66-6n6o-404o-s83n-p41994245s8p@SerrOFQ.bet>
index | next in thread | previous in thread | raw e-mail
On 6/5/25 01:22, Bjoern A. Zeeb wrote: > On Wed, 4 Jun 2025, Steve Kargl wrote: > >> On 6/4/25 13:11, Steve Kargl wrote: >>> On Tue, Jun 03, 2025 at 06:45:31PM -0700, Steve Kargl wrote: >>> >>> I was able to rebuild world/kernel for a 2025-04-15 >>> src/ (aka adc33d3288) and rebuilt drm-515-kmod and >>> gpu-firmware. The system boots and I can kldload >>> radeonkmd.ko. startx brings up the expected desktop. >>> >>> Onward to src/ from 2025-05-01 (aka 8d136fb027). >>> >> >> The problem appears between adc33d3288 and >> 8d136fb027. There are a few commits in this >> range that change the linuxkpi. > > Sorting away wireless changes from sys/compat/.. here's what's left: > > % git log --oneline adc33d3288..8d136fb027 sys/compat/ | grep -v 802.11 > | grep -v skbuff | grep -v wsum | grep -v ASMEDIA > 325aa4dbd10d linuxkpi: Introduce a properly typed jiffies << > jiffies changed to proper type > 8b51cd07f69e LinuxKPI: define time64_t << new typedef > 28efbf9d2f67 LinuxKPI: add dummy header file linux/unaligned.h << > empty header file > e29d72ac3ddd LinuxKPI: pci: add pci_info() << new macro > for logging > f94d7319540b LinuxKPI: sysfs: implement sysfs_match_string() << > new macro/func > 6841b9987e83 LinuxKPI: add container_of_const() << new macro > 69880fede78f LinuxKPI: extend struct and enum for leds << LED > additions to struct/enum (unused) > 059136a95aca LinuxKPI: add cleanup.h to mutex.h << > #include added > 15581af7c2d3 exec: Remove parameter 'segflg' from exec_copyin_args() > << linuxolator > 97f3a1565d88 linuxkpi: use iterator in zap_vma_ptes << VM > > > On a known good version, did you go twice through the dump_stack() as > well according to dmesg? Would give another hint if we now hit > that resume path for other reasons maybe? I forgot to check for the dump_stack() output. As I iterate over the above list of hash tags, I make a note. I suspect that one these has uncovered a latent bug in drm. -- stevehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1b756512-ef7c-4fd0-aaaa-9de5298b57ff>