Re: -stable from today dumps core with drm-510-kmod and some graphical clients
- In reply to: Marek Zarychta : "Re: -stable from today dumps core with drm-510-kmod and some graphical clients"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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