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

Cy Schubert <Cy.Schubert@cschubert.com> writes:

> 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.

Finally I found the time for a kernel crash dump.
This is what kgdb says

mathiasp:amd64.amd64/sys/GENERIC% sudo kgdb kernel 
/var/crash/vmcore.2 
GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from kernel...
Reading symbols from 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel.debug...

Unread portion of the kernel message buffer:


__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" 
(offsetof(struct pcpu,
(kgdb) backtrace
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=<optimized out>) at 
 /usr/src/sys/kern/kern_shutdown.c:396
#2  0xffffffff80c07c2a in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:484
#3  0xffffffff80c080ce in vpanic (fmt=<optimized out>, 
 ap=ap@entry=0xfffffe01341fab50) at 
 /usr/src/sys/kern/kern_shutdown.c:923
#4  0xffffffff80c07f03 in panic (fmt=<unavailable>) at 
 /usr/src/sys/kern/kern_shutdown.c:847
#5  0xffffffff810c1fa7 in trap_fatal (frame=0xfffffe01341fac40, 
 eva=0) at /usr/src/sys/amd64/amd64/trap.c:942
#6  0xffffffff810c1fff in trap_pfault (frame=0xfffffe01341fac40, 
 usermode=false, signo=<optimized out>, ucode=<optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:761
#7  <signal handler called>
#8  0xffffffff84a07067 in shmem_get_pages () from 
 /boot/modules/i915kms.ko
#9  0x0000000300000015 in ?? ()
#10 0x0000000000000060 in ?? ()
#11 0x0000000000000060 in ?? ()
#12 0x0000000000060000 in ?? ()
#13 0xfffffe00dc365a80 in ?? ()
#14 0xfffff00100000060 in ?? ()
#15 0xfffff8003e270c00 in ?? ()
#16 0x00000000fffff000 in ?? ()
#17 0xfffff8002138fc20 in ?? ()
#18 0xfffffe00dc365a80 in ?? ()
#19 0x0000000000000060 in ?? ()
#20 0xfffff8003e270c00 in ?? ()
#21 0x0000000000000060 in ?? ()
#22 0xfffffe0131e0fc80 in ?? ()
#23 0xfffffe01341fade0 in ?? ()
#24 0xffffffff84a07596 in shmem_pwrite () from 
 /boot/modules/i915kms.ko
#25 0x0000000000000000 in ?? ()
(kgdb) 


Anything else I can do to help?

I’m now building drm-515-kmod, let’s see how that works in 
-stable.

/Mathias



-- 
Mathias Picker                        
Geschäftsführer
Mathias.Picker@virtual-earth.de

virtual earth Gesellschaft für Wissens re/prä sentation mbH
http://www.virtual-earth.de/           HRB126870
support@virtual-earth.de               Westendstr. 142
089 / 1250 3943