From nobody Wed Jul 28 01:43:50 2021 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 21E3C12BFC72 for ; Wed, 28 Jul 2021 01:44:00 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GZGfR0nHBz3RK8 for ; Wed, 28 Jul 2021 01:43:59 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 16S1hqkI074875 for ; Tue, 27 Jul 2021 20:43:52 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 7F04C19B0B9 for ; Tue, 27 Jul 2021 20:43:47 -0500 (CDT) Subject: Re: aarch64 and kqueue timer events To: freebsd-stable@freebsd.org References: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net> From: Matthew Grooms Message-ID: Date: Tue, 27 Jul 2021 20:43:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 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 In-Reply-To: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Tue, 27 Jul 2021 20:43:52 -0500 (CDT) X-Rspamd-Queue-Id: 4GZGfR0nHBz3RK8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_SPAM_SHORT(1.00)[0.999]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable] X-ThisMailContainsUnwantedMimeParts: N On 7/24/2021 8:18 PM, Matthew Grooms wrote: > Hi all, > > I'm seeing some strange behavior with kqueue timers on my aarch64 > host. Here is a simple test program that I've compiled on both amd64 > and aarch64. It just sets up a simple kqueue timer with a loop that > waits for the event to fire every 3 seconds ... > > #include > #include > #include > #include > #include > > int main( int argc, char *argv[] ) > { >     int kq = kqueue(); >     if( kq < 0 ) >         err( 1, "failed to obtain kqueue handle" ); > >     struct kevent ke; >     EV_SET( &ke, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 3000, 0 ); >     if( kevent( kq, &ke, 1, NULL, 0, NULL ) < 0 ) >         err( 1, "failed to add kevent timer filter" ); > >     printf( "started at %i\n", (int)time(NULL) ); > >     while( true ) >     { >         int r = kevent( kq, NULL, 0, &ke, 1, NULL ); >         if( r < 0 ) >             err( 1, "failed to read kevent list" ); > >         printf( "timer fired %i times at %i\n", r, (int)time(NULL) ); >     } > >     return 0; > } > > When I compile and run the code on an amd64 host, everything works as > expected. The event timer expires once every 3 seconds ... > > mgrooms@amd64:~/devel$ cc test.cpp -o test && ./test > started at 1627175311 > timer fired 1 times at 1627175314 > timer fired 1 times at 1627175317 > timer fired 1 times at 1627175320 > > However, when I compile and run the same code on an aarch64 host ( > rpi4b ), something very different happens. The event timer expires > after 3 seconds the first time. But each subsequent expiration is for > exactly twice the defined interval, 6 seconds ... > > mgrooms@aarch64:~/devel$ cc test.cpp -o test && ./test > started at 1625789207 > timer fired 1 times at 1625789210 > timer fired 1 times at 1625789216 > timer fired 1 times at 1625789222 > > Any idea what's going on here? Seems like a bug somewhere on the arm > side. > > Thanks in advance, > Hi Everyone, Sorry for the cross post. I started by asking this question in freebsd-arm but didn't get a response. I figured, since aarch64 is Tier1 now, asking wrt stable is fair game. Another user ( José Pérez ) confirmed that this issue was also present on current but my testing was on 13 ... FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #8 stable/13-n246015-ade8b810b02-dirty: Tue Jun 15 21:04:38 CDT 202 Any help would be greatly appreciated. Thanks in advance, -Matthew From nobody Wed Jul 28 02:16:14 2021 X-Original-To: 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 C3B2612D24B1 for ; Wed, 28 Jul 2021 02:16:28 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4GZHMv2y1Wz3kb2 for ; Wed, 28 Jul 2021 02:16:27 +0000 (UTC) (envelope-from mike@karels.net) Received: from mjklap.karels.net ([10.0.1.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id 16S2GKNI011747 for ; Tue, 27 Jul 2021 21:16:20 -0500 (CDT) (envelope-from mike@karels.net) Subject: Re: aarch64 and kqueue timer events To: stable@freebsd.org References: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net> From: Mike Karels Message-ID: Date: Tue, 27 Jul 2021 21:16:14 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 16S2GKNI011747 X-Rspamd-Queue-Id: 4GZHMv2y1Wz3kb2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [0.80 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[karels.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: N On 7/27/21 8:43 PM, Matthew Grooms wrote: > On 7/24/2021 8:18 PM, Matthew Grooms wrote: >> Hi all, >> >> I'm seeing some strange behavior with kqueue timers on my aarch64=20 >> host. Here is a simple test program that I've compiled on both amd64=20 >> and aarch64. It just sets up a simple kqueue timer with a loop that=20 >> waits for the event to fire every 3 seconds ... >> >> #include >> #include >> #include >> #include >> #include >> >> int main( int argc, char *argv[] ) >> { >> =C2=A0=C2=A0=C2=A0 int kq =3D kqueue(); >> =C2=A0=C2=A0=C2=A0 if( kq < 0 ) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 err( 1, "failed to obtain k= queue handle" ); >> >> =C2=A0=C2=A0=C2=A0 struct kevent ke; >> =C2=A0=C2=A0=C2=A0 EV_SET( &ke, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0= , 3000, 0 ); >> =C2=A0=C2=A0=C2=A0 if( kevent( kq, &ke, 1, NULL, 0, NULL ) < 0 ) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 err( 1, "failed to add keve= nt timer filter" ); >> >> =C2=A0=C2=A0=C2=A0 printf( "started at %i\n", (int)time(NULL) ); >> >> =C2=A0=C2=A0=C2=A0 while( true ) >> =C2=A0=C2=A0=C2=A0 { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int r =3D kevent( kq, NULL,= 0, &ke, 1, NULL ); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if( r < 0 ) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 err= ( 1, "failed to read kevent list" ); >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 printf( "timer fired %i tim= es at %i\n", r, (int)time(NULL) ); >> =C2=A0=C2=A0=C2=A0 } >> >> =C2=A0=C2=A0=C2=A0 return 0; >> } >> >> When I compile and run the code on an amd64 host, everything works as=20 >> expected. The event timer expires once every 3 seconds ... >> >> mgrooms@amd64:~/devel$ cc test.cpp -o test && ./test >> started at 1627175311 >> timer fired 1 times at 1627175314 >> timer fired 1 times at 1627175317 >> timer fired 1 times at 1627175320 >> Thanks in advance, >> >> -Matthew >> >> >> >> However, when I compile and run the same code on an aarch64 host (=20 >> rpi4b ), something very different happens. The event timer expires=20 >> after 3 seconds the first time. But each subsequent expiration is for=20 >> exactly twice the defined interval, 6 seconds ... >> >> mgrooms@aarch64:~/devel$ cc test.cpp -o test && ./test >> started at 1625789207 >> timer fired 1 times at 1625789210 >> timer fired 1 times at 1625789216 >> timer fired 1 times at 1625789222 >> >> Any idea what's going on here? Seems like a bug somewhere on the arm=20 >> side. >> >> Thanks in advance, >> > Hi Everyone, > > Sorry for the cross post. I started by asking this question in=20 > freebsd-arm but didn't get a response. I figured, since aarch64 is=20 > Tier1 now, asking wrt stable is fair game. Another user ( Jos=C3=A9 P=C3= =A9rez )=20 > confirmed that this issue was also present on current but my testing=20 > was on 13 ... > > FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #8=20 > stable/13-n246015-ade8b810b02-dirty: Tue Jun 15 21:04:38 CDT 202 > > Any help would be greatly appreciated. Another data point: the program runs correctly on 13.0-RELEASE-p3 on rpi4= b. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Mike From nobody Wed Jul 28 15:50:28 2021 X-Original-To: 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 6389412D4544 for ; Wed, 28 Jul 2021 15:48:46 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GZdP84823z3Mgr for ; Wed, 28 Jul 2021 15:48:44 +0000 (UTC) (envelope-from pj@smo.de) Received: from localhost (localhost [127.0.0.1]) by mail.adebahr.de (Postfix) with ESMTP id EAA466190520B for ; Wed, 28 Jul 2021 17:48:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=smo.de; h= content-transfer-encoding:content-language:content-type :content-type:mime-version:user-agent:date:date:message-id :subject:subject:from:from; s=mail; t=1627487322; x=1629301723; bh=0Vszm2ggU6wTRurACDXW469nh9Vj2q918pfGpAQTTwg=; b=2cal2R0dLnbX rojeMqdAS/4OpI+ccpTIYkVUw7lFQaA2qJutOW0BsbAiGf3UhubLnRl+WMmmREUr rboGrxtifsGCzvc8a1ITpCEutBAEWoYGP/5B7IC5sK63WcjBXzaWWAn0jNuo7ZLx 1J4MxuRydn3aFiNAUEYZZDE1r901eLA= Received: from mail.adebahr.de ([127.0.0.1]) by localhost (mail.adebahr.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id h6Y5iFsJRt9W for ; Wed, 28 Jul 2021 17:48:42 +0200 (CEST) Received: from skjaldbreidur.intern.smo.de (p5b239a2d.dip0.t-ipconnect.de [91.35.154.45]) by mail.adebahr.de (Postfix) with ESMTPSA id C15956190520D for ; Wed, 28 Jul 2021 17:48:42 +0200 (CEST) To: stable@freebsd.org From: Philipp Ost Subject: Reproducible page faults with drm-kmod on 12-Stable/amd64 Message-ID: <9eec8065-4075-c1f6-059d-9a4901b8b050@smo.de> Date: Wed, 28 Jul 2021 17:50:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GZdP84823z3Mgr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=2cal2R0d; dmarc=none; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de X-Spamd-Result: default: False [-2.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[smo.de]; DKIM_TRACE(0.00)[smo.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:198930, ipnet:185.66.176.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: N Hi stable@! Since switching back to my Radeon HD 5450, I get reproducible page faults and the occasional panic. I am running FreeBSD 12.2-STABLE stable/12-n233459-0f97f2a1857 amd64; I am running a stripped down GENERIC kernel with DEBUG=-g. I have installed these DRM modules: drm-fbsd12.0-kmod-4.16.g20201016_2 drm-kmod-g20190710_1 gpu-firmware-kmod-g20210330 I built these after I updated my machine to the above mentioned revision. Since then, I rebuilt drm-fbsd12.0-kmod with DEBUG=on. The radeonkms module gets loaded via /etc/rc.conf: kld_list="/boot/modules/radeonkms.ko" The graphics card gets identified as follows: vgapci0@pci0:1:0:0: class=0x030000 card=0xe164174b chip=0x68f91002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Cedar [Radeon HD 5000/6000/7350/8350 Series]' class = display subclass = VGA Most page faults are DRM related: 1. Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 12 fault virtual address = 0xfffff803a38c9180 fault code = supervisor read instruction, protection violation instruction pointer = 0x20:0xfffff803a38c9180 stack pointer = 0x28:0xfffffe00a89036a8 frame pointer = 0x28:0xfffffe00a89036a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current proces = 951 (Renderer) trap number = 12 panic: page fault cpuid = 2 time = 1627412707 KDB: stack backtrace: #0 0xffffffff8076af45 at kdb_backtrace+0x65 #1 0xffffffff8071f21b at vpanic+0x17b #2 0xffffffff8071f093 at panic+0x43 #3 0xffffffff80a7e9a1 at trap_fatal+0x391 #4 0xffffffff80a7e9ff at trap_pfault+0x4f #5 0xffffffff80a7e046 at trap+0x286 #6 0xffffffff80a56a08 at calltrap+0x8 #7 0xffffffff81cf681c at reservation_object_test_signaled_rcu+0x1dc #8 0xffffffff81bc2350 at radeon_gem_busy_ioctl+0x30 #9 0xffffffff81cad2e1 at drm_ioctl_kernel+0xf1 #10 0xffffffff81cad589 at drm_ioctl+0x289 #11 0xffffffff809788b0 at linux_file_ioctl+0x330 #12 0xffffffff80788e47 at kern_ioctl+0x2b7 #13 0xffffffff80788aea at sys_ioctl+0xfa #14 0xffffffff80a7f557 at amd64_syscall+0x387 #15 0xffffffff80a5732e at fast_syscall_common+0xf8 Uptime: 12m19s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. 2. This one happend during `make index`: Fatal trap 12: page fault while in kernel-mode cpuid = 3; apic id = 13 fault virtual address = 0x60045dabb18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8163b2a7 stack pointer = 0x28:0xfffffe00a7fb7380 frame pointer = 0x28:0xfffffe00a7fb73b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 85505 (sh) trap number = 12 panic: page fault cpuid = 3 time = 1627414262 KDB: stack backtrace: #0 0xffffffff8076af45 at kdb_backtrace+0x65 #1 0xffffffff8071f21b at vpanic+0x17b #2 0xffffffff8071f093 at panic+0x43 #3 0xffffffff80a7e9a1 at trap_fatal+0x391 #4 0xffffffff80a7e9ff at trap_pfault+0x4f #5 0xffffffff80a7e046 at trap+0x286 #6 0xffffffff80a56a08 at calltrap+0x8 #7 0xffffffff816f75b2 at zfs_freebsd_write+0xb72 #8 0xffffffff80b2039b at VOP_WRITE_APV+0xeb #9 0xffffffff80801961 at vn_write+0x261 #10 0xffffffff80801433 at vn_io_fault_doio+0x43 #11 0xffffffff807fee0c at vn_io_fault1+0x15c #12 0xffffffff807fce05 at vn_io_fault+0x185 #13 0xffffffff80788750 at dofilewrite+0xb0 #14 0xffffffff807882d0 at sys_write+0xc0 #15 0xffffffff80a7f557 at amd64_syscall+0x387 #16 0xffffffff80a5732e at fast_syscall_common+0xf8 Uptime: 7m48s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. 3. The lone kernel panic: panic: BUG ON!list_empty(&fence->cb_list) failed at /usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-8843e1fc5/linuxkpi/gplv2/include/linux/dma-fence.h:91 cpuid = 1 time = 1627415383 KDB: stack backtrace: #0 0xffffffff8076af45 at kdb_backtrace+0x65 #1 0xffffffff8071f21b at vpanic+0x17b #2 0xffffffff8071f093 at panic+0x43 #3 0xffffffff81cf5c84 at reservation_object_add_shared_fence+0x274 #4 0xffffffff81d0b289 at ttm_eu_fence_buffer_objects+0x69 #5 0xffffffff81bb2b72 at radeon_cs_parser_fini+0x52 #6 0xffffffff81bb26eb at radeon_cs_ioctl+0x8fb #7 0xffffffff81cad2e1 at drm_ioctl_kernel+0xf1 #8 0xffffffff81cad589 at drm_ioctl+0x289 #9 0xffffffff809788b0 at linux_file_ioctl+0x330 #10 0xffffffff80788e47 at kern_ioctl+0x2b7 #11 0xffffffff80788aea at sys_ioctl+0xfa #12 0xffffffff80a7f557 at amd64_syscall+0x387 #13 0xffffffff80a5732e at fast_syscall_common+0xf8 Uptime: 1m58s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. 4. The most recent one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 14 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff81d0e43f stack pointer = 0x0:0xfffffe00a8908750 frame pointer = 0x0:0xfffffe00a89087e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor flags = interrupt enabled, resume, IOPL = 0 current process = 1120 (Renderer) trap number = 12 panic: page fault cpuid = 4 time = 1627484091 KDB: stack backtrace: #0 0xffffffff8076af45 at kdb_backtrace+0x65 #1 0xffffffff8071f21b at vpanic+0x17b #2 0xffffffff8071f093 at panic+0x43 #3 0xffffffff80a7e9a1 at trap_fatal+0x391 #4 0xffffffff80a7e9ff at trap_pfault+0x4f #5 0xffffffff80a7e046 at trap+0x286 #6 0xffffffff80a56a08 at calltrap+0x8 #7 0xffffffff81bd8dac at radeon_ttm_fault+0x4c #8 0xffffffff8097b685 at linux_cdev_pager_populate+0x125 #9 0xffffffff80a21fee at vm_fault+0x53e #10 0xffffffff80a21990 at vm_fault_trap+0x60 #11 0xffffffff80a7eb4c at trap_pfault+0x19c #12 0xffffffff80a7e1d0 at trap+0x410 #13 0xffffffff80a56a08 at calltrap+0x8 Uptime: 1h32m55s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. These are all I could capture till now (transcribed by hand, any typos are my fault...). Unfortunately, I was not able to get any sort of crash dump. I have dumpdev=AUTO dumpdir=/var/crash savecore_enable=YES in my /etc/rc.conf, but /var/crash is empty save for a file named minfree. As I said, this is 100% reproducible. The time for something to go haywire ranges from pretty much immediatly to around two hours. Any advice on how to fix this? I'm happy to provide more information if needed. Thanks in advance! Philipp