From nobody Tue Apr 11 14:17:13 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pwnwk5X5Qz44wXM; Tue, 11 Apr 2023 14:17:26 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pwnwj5yLJz4Wc1; Tue, 11 Apr 2023 14:17:25 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of uspoerlein@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=uspoerlein@gmail.com; dmarc=none Received: by mail-pg1-f177.google.com with SMTP id r17so4184777pgr.1; Tue, 11 Apr 2023 07:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681222644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=te0x3jETnqK23pIdXHpqZkXp92iQkFKHzdZSz5Vp+YQ=; b=ir/4UuVknOXbn4xJILjMucDlN4wkbrmqmBc0K6WDQwSK4gMtfrLyVhPbuLTLeRKgNU 93I9KhsiP5dLiMS6O0I9VM99zmlvyD4HOx+EULMT4BI533Sh+pKS54bV1Aw1SE6W4MA5 gcHBbrsdK10TxiK1bMbNxYsaHqklg3cn3VbhkkoGY6Du9akXphaX0G+0tsp2P3a7K3Ea PM83S4kOIZ1Uwu8NK1DlU37NQkGjbOlzJj4jpP9gEegEjh304e3dCOvLvxYDSLfIT599 Dpqp40N2yd3a4i8YZtyn+qeg5h9DVttl5VFZig0Seq7OmpTKDjNgSe8cgCbxpO2wKo4s AOFg== X-Gm-Message-State: AAQBX9d9fsob5+6KhYgjMTHP7M9ZftLzsXLPk7R8+spsHRyygsfw7TWY zdchJFeaDyt0wmxyfsrTGA94g4w0UKN2Fh27wM67wUR/82Ymtg== X-Google-Smtp-Source: AKy350ZkE3yqJAfzUov8zwd+Yn2Z5rJUDhQtuowD6+sol6zsbe3yFkwF3ZgHVSg93oRVIXu+YT7ukry1H9U9h/O29BY= X-Received: by 2002:a63:4e51:0:b0:50c:a45:1f99 with SMTP id o17-20020a634e51000000b0050c0a451f99mr2875511pgl.8.1681222644303; Tue, 11 Apr 2023 07:17:24 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <86o7og27eh.fsf@virtual-earth.de> <8b47d0a4-a8f1-1841-ee59-3949fe69cbd7@ShaneWare.Biz> <20230327210535.9ED5A1D7@slippy.cwsent.com> <044587F7-4BA9-4585-A789-F4B53E8D02A2@virtual-earth.de> <20230327145629.3b55eed8@slippy> <86o7oa1i6t.fsf@virtual-earth.de> In-Reply-To: <86o7oa1i6t.fsf@virtual-earth.de> From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Tue, 11 Apr 2023 16:17:13 +0200 Message-ID: Subject: Re: -stable from today dumps core with drm-510-kmod and some graphical clients To: Mathias Picker Cc: Cy Schubert , Shane Ambler , FreeBSD-STABLE , stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000808d8905f91026c2" X-Spamd-Result: default: False [0.34 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.97)[0.967]; NEURAL_SPAM_MEDIUM(0.48)[0.476]; FORGED_SENDER(0.30)[uqs@freebsd.org,uspoerlein@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.215.177:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.215.177:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org,stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_FIVE(0.00)[5]; FROM_NEQ_ENVFROM(0.00)[uqs@freebsd.org,uspoerlein@gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Pwnwj5yLJz4Wc1 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --000000000000808d8905f91026c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 30, 2023 at 3:29=E2=80=AFPM Mathias Picker < Mathias.Picker@virtual-earth.de> wrote: > > Cy Schubert writes: > > > On Mon, 27 Mar 2023 23:43:35 +0200 > > Mathias Picker wrote: > > > >> Am 27. M=C3=A4rz 2023 23:05:35 MESZ schrieb Cy Schubert > >> : > >> >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. > >> >> > > >> >> > =C3=A2=E2=82=AC=C5=93Demanding=C3=A2=E2=82=AC means even simple = things like > >> >> > qterminal. I tried firefox an > >> >> d > >> >> > blender and then I had it with the reboots and > >> >> > didn=C3=A2=E2=82=AC=E2=84=A2t 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=3D"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 > > 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: > . > Find the GDB manual and other documentation resources online at: > . > > 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" : "=3Dr" (td) : "n" > (offsetof(struct pcpu, > (kgdb) backtrace > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=3D) at > /usr/src/sys/kern/kern_shutdown.c:396 > #2 0xffffffff80c07c2a in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:484 > #3 0xffffffff80c080ce in vpanic (fmt=3D, > ap=3Dap@entry=3D0xfffffe01341fab50) at > /usr/src/sys/kern/kern_shutdown.c:923 > #4 0xffffffff80c07f03 in panic (fmt=3D) at > /usr/src/sys/kern/kern_shutdown.c:847 > #5 0xffffffff810c1fa7 in trap_fatal (frame=3D0xfffffe01341fac40, > eva=3D0) at /usr/src/sys/amd64/amd64/trap.c:942 > #6 0xffffffff810c1fff in trap_pfault (frame=3D0xfffffe01341fac40, > usermode=3Dfalse, signo=3D, ucode=3D) > at /usr/src/sys/amd64/amd64/trap.c:761 > #7 > #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=E2=80=99m now building drm-515-kmod, let=E2=80=99s see how that works i= n > -stable. > > /Mathias > > Any updates here? I just ran into this myself and am very close to just installing Linux on my laptop, tbh. I've rebuilt stable/13 today, then rebuilt the 510-kmod (because the 515-kmod doesn't even build) and pretty much anything that's not an XTerm will panic/reboot the machine (a Thinkpad T490 with Intel GPU). dmesg got this to say: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 02 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff84430626 stack pointer =3D 0x28:0xfffffe0140c83cf0 frame pointer =3D 0x28:0xfffffe0140c83d70 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (i915-userptr-acquir) trap number =3D 12 panic: page fault cpuid =3D 1 time =3D 1681221523 KDB: stack backtrace: #0 0xffffffff80c5fc15 at kdb_backtrace+0x65 #1 0xffffffff80c12e02 at vpanic+0x152 #2 0xffffffff80c12ca3 at panic+0x43 #3 0xffffffff810d1577 at trap_fatal+0x387 #4 0xffffffff810d15cf at trap_pfault+0x4f #5 0xffffffff810a8568 at calltrap+0x8 #6 0xffffffff84430c02 at __i915_gem_userptr_get_pages_worker+0x1f2 #7 0xffffffff80e80883 at linux_work_fn+0xe3 #8 0xffffffff80c746f1 at taskqueue_run_locked+0x181 #9 0xffffffff80c759b3 at taskqueue_thread_loop+0xc3 #10 0xffffffff80bcf55d at fork_exit+0x7d #11 0xffffffff810a95de at fork_trampoline+0xe It apparently dumps core, will have to reacquaint myself with how to poke at this some more... --000000000000808d8905f91026c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 30, 2023 at 3:29=E2=80=AFPM M= athias Picker <Mathia= s.Picker@virtual-earth.de> wrote:

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=C3=A4rz 2023 23:05:35 MESZ schrieb Cy Schubert
>> <Cy.Schubert@cschubert.com>:
>> >In message
>> ><8b47d0a4-a8f1-1841-ee59-3949fe69cbd7@ShaneWare.Biz>, Sh= ane
>> >Ambler w
>> >rites:=C2=A0
>> >> On 26/3/23 01:37, Mathias Picker wrote:=C2=A0
>> >> >
>> >> > 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.
>> >> >
>> >> > =C3=A2=E2=82=AC=C5=93Demanding=C3=A2=E2=82=AC=C2=A0 = means even simple things like
>> >> > qterminal. I tried firefox an=C2=A0
>> >> d=C2=A0
>> >> > blender and then I had it with the reboots and
>> >> > didn=C3=A2=E2=82=AC=E2=84=A2t 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.=C2=A0 >> >>
>> >>
>> >> FreeBSD Developers Handbook Chapter 10: Kernel Debugging<= br> >> >>
>> >> https://docs.fre= ebsd.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=3D"= ;AUTO" in
>> >> rc.conf) the
>> >> kernel core is saved to swap space, then on reboot gets <= br> >> >> 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.=C2=A0 >> >
>> >drm-*-kmod probably needs a rebuild. Likely a data structure <= br> >> >changed. In my
>> >experience a simple rebuild of the port solves 90% of
>> >drm-*-kmod crash
>> >problems.
>> >=C2=A0
>> 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 <= br> >> 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:
=C2=A0 =C2=A0 <http://www.gnu.org/software/gdb/docu= mentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word&= quot;...
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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __asm("movq %%gs:%P= 1,%0" : "=3Dr" (td) : "n"
(offsetof(struct pcpu,
(kgdb) backtrace
#0=C2=A0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1=C2=A0 doadump (textdump=3D<optimized out>) at
=C2=A0/usr/src/sys/kern/kern_shutdown.c:396
#2=C2=A0 0xffffffff80c07c2a in kern_reboot (howto=3D260) at
=C2=A0/usr/src/sys/kern/kern_shutdown.c:484
#3=C2=A0 0xffffffff80c080ce in vpanic (fmt=3D<optimized out>,
=C2=A0ap=3Dap@entry=3D0xfffffe01341fab50) at
=C2=A0/usr/src/sys/kern/kern_shutdown.c:923
#4=C2=A0 0xffffffff80c07f03 in panic (fmt=3D<unavailable>) at
=C2=A0/usr/src/sys/kern/kern_shutdown.c:847
#5=C2=A0 0xffffffff810c1fa7 in trap_fatal (frame=3D0xfffffe01341fac40,
=C2=A0eva=3D0) at /usr/src/sys/amd64/amd64/trap.c:942
#6=C2=A0 0xffffffff810c1fff in trap_pfault (frame=3D0xfffffe01341fac40, =C2=A0usermode=3Dfalse, signo=3D<optimized out>, ucode=3D<optimize= d out>)
=C2=A0 =C2=A0 at /usr/src/sys/amd64/amd64/trap.c:761
#7=C2=A0 <signal handler called>
#8=C2=A0 0xffffffff84a07067 in shmem_get_pages () from
=C2=A0/boot/modules/i915kms.ko
#9=C2=A0 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
=C2=A0/boot/modules/i915kms.ko
#25 0x0000000000000000 in ?? ()
(kgdb)


Anything else I can do to help?

I=E2=80=99m now building drm-515-kmod, let=E2=80=99s see how that works in =
-stable.

/Mathias


Any updates here? I just r= an into this myself and am very close to just installing Linux on my laptop= , tbh.

I've rebuilt stable/13 today, then rebu= ilt the 510-kmod (because the 515-kmod doesn't even build) and pretty m= uch anything that's not an XTerm will panic/reboot the machine (a Think= pad T490 with Intel GPU).=C2=A0

dmesg got this to = say:

Fatal trap 12: page fault while in kernel mod= e
cpuid =3D 1; apic id =3D 02
fault virtual address =C2=A0 =3D 0x0fault code =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D supervisor = read data, page not present
instruction pointer =C2=A0 =C2=A0 =3D 0x20:0= xffffffff84430626
stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0= x28:0xfffffe0140c83cf0
frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =3D 0x28:0xfffffe0140c83d70
code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=3D base 0x0, limit 0xfffff, type 0x1b
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D DPL 0, p= res 1, long 1, def32 0, gran 1
processor eflags =C2=A0 =C2=A0 =C2=A0 =C2= =A0=3D interrupt enabled, resume, IOPL =3D 0
current process =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =3D 0 (i915-userptr-acquir)
trap number =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 12
panic: page fault
cpuid =3D 1
t= ime =3D 1681221523
KDB: stack backtrace:
#0 0xffffffff80c5fc15 at kdb= _backtrace+0x65
#1 0xffffffff80c12e02 at vpanic+0x152
#2 0xffffffff80= c12ca3 at panic+0x43
#3 0xffffffff810d1577 at trap_fatal+0x387
#4 0xf= fffffff810d15cf at trap_pfault+0x4f
#5 0xffffffff810a8568 at calltrap+0x= 8
#6 0xffffffff84430c02 at __i915_gem_userptr_get_pages_worker+0x1f2
= #7 0xffffffff80e80883 at linux_work_fn+0xe3
#8 0xffffffff80c746f1 at tas= kqueue_run_locked+0x181
#9 0xffffffff80c759b3 at taskqueue_thread_loop+0= xc3
#10 0xffffffff80bcf55d at fork_exit+0x7d
#11 0xffffffff810a95de a= t fork_trampoline+0xe

It apparently dumps core= , will have to reacquaint myself with how to poke at this some more...
--000000000000808d8905f91026c2--