Re: -stable from today dumps core with drm-510-kmod and some graphical clients

From: Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
Date: Tue, 28 Mar 2023 19:01:07 UTC
W dniu 28.03.2023 o 19:57, Marek Zarychta pisze:
> W dniu 27.03.2023 o 23:56, Cy Schubert pisze:
>> On Mon, 27 Mar 2023 23:43:35 +0200
>> Mathias Picker <Mathias.Picker@virtual-earth.de> wrote:
>>
>>> Am 27. März 2023 23:05:35 MESZ schrieb Cy Schubert 
>>> <Cy.Schubert@cschubert.com>:
>>>> In message <8b47d0a4-a8f1-1841-ee59-3949fe69cbd7@ShaneWare.Biz>, Shane
>>>> Ambler w
>>>> rites:
>>>>> On 26/3/23 01:37, Mathias Picker wrote:
>>>>>> Starting sddm works fine, starting my normal session crashes or 
>>>>>> freezes
>>>>>> FreeBSD.
>>>>>>
>>>>>> I can find no error messages after a reboot.
>>>>>>
>>>>>> I found out, that I can start xterm or emacs (exwm) without 
>>>>>> problems,
>>>>>> xrandr works with external screen, but once I start anything more
>>>>>> demanding (I guess demanding of the GPU) everything freezes or 
>>>>>> FreeBSD
>>>>>> even reboots.
>>>>>>
>>>>>> “Demanding” means even simple things like qterminal. I tried 
>>>>>> firefox an
>>>>> d
>>>>>> blender and then I had it with the reboots and didn’t try 
>>>>>> anything else.
>>>>>> xedit works fine :)
>>>>>>
>>>>>> I have nothing in the logs, I have no idea where to look or how 
>>>>>> to debug
>>>>>> this.
>>>>>>
>>>>>> Any ideas, tipps, help greatly apreciated.
>>>>>
>>>>> FreeBSD Developers Handbook Chapter 10: Kernel Debugging
>>>>>
>>>>> https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/
>>>>>
>>>>> Running stable, kernel dumps may already be enabled, look in 
>>>>> /var/crash
>>>>>
>>>>> By enabling a kernel dump when it panics (dumpdev="AUTO" in 
>>>>> rc.conf) the
>>>>> kernel core is saved to swap space, then on reboot gets copied to
>>>>> dumpdir (/var/crash) where you can then use kgdb (from devel/gdb) 
>>>>> to get
>>>>> a stack trace to find where the panic happened.
>>>> drm-*-kmod probably needs a rebuild. Likely a data structure 
>>>> changed. In my
>>>> experience a simple rebuild of the port solves 90% of drm-*-kmod crash
>>>> problems.
>>> Hi Cy,
>>>
>>> sorry I didn't mention that, but I did rebuild drm-kmod, I actually 
>>> do it after every new kernel build, just to be on the safe side.
>>>
>>> I switched my swap to non-encrypted and will look if I can get any 
>>> information from the kernel dump tomorrow.
>>>
>>> Oh, and it's on a Thinkpad X1 Yoga 3rd gen, I just noticed I didn't 
>>> mention this.
>> It may be worth trying drm-515-kmod as some MFC that works with 515 and
>> not 510 may have been committed. Linux-KPI commits are the usual
>> suspects.
>>
>> I use drm-515 with 14-CURRENT.
>
> drm-515 with 14-CURRENT works fine, but there is a breakage in drm-510 
> on stable/13. I built it after kernel update today, but it doesn't 
> load: linker_load_file: /boot/modules/radeonkms.ko - unsupported file 
> type. Loading old module of course leads to immediate panic. I am 
> investigating it.

  I have to admit that the fresh build of drm-510-kmod works flawlessly 
on the most recent stable/13. Too many options and environments to mess 
with, I am sorry for the noise on the list.

-- 
Marek Zarychta