Re: drm panic after new world

On Thu, 5 Jun 2025, Steve Kargl wrote:

> On Thu, Jun 05, 2025 at 08:22:45AM +0000, Bjoern A. Zeeb wrote:
>>
>> 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
>
> Well, my first attempt was at 6c3a4b5fab, which happens to

That's not a valid hash.

> include all of the above commits.  I misread the list as
> oldest to newest.   Boot system, kldload radeonkms.ko,
> and startx laeds to a panic.  The dump_stack() in evergreen.c
> occurs twice.
>
> Just completed rebuilding everything at e1f3f15192c.  This is
> the hash tag for the commit prior to 97f3a1565d88 from above.
> This boots up, I kldload radeonkms.ko, and startx brings up
> the expected desktop.

Do I understand you correctly that the change before 97f3a1565d88 (VM
changes) worked but 97f3a1565d88 fails?

Or only the former is true and the latter we do not know?
We only know with all of the above it's kaputt but before it's fine?


> Looking at dmesg, I see
>
> ...
> drmn0: radeon: MSI limited to 32-bit
> drmn0: radeon: using MSI.
> [drm] radeon: irq initialized.
> #0 0xffffffff808bbcfb at linux_dump_stack+0x1b
> #1 0xffffffff82a67adc at evergreen_startup+0x15ec
> #2 0xffffffff82a67fb6 at evergreen_init+0x276
> #3 0xffffffff82abdc35 at radeon_device_init+0x835
> #4 0xffffffff82aceb4e at radeon_driver_load_kms+0x19e
>
>
> and no other mentions of evergreen.c.  IOW, initialization
> appears to occur once.

That sounds good.  So no resume path.  I almost fear your problem is
outside LinuxKPI but we'll see.

I'd try 28efbf9d2f67 next to see what happens if I got you correctly.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7