r1iVbvBuLFPhZbsGNNjOHowaH7zUIt5+Qs6v/18 jjZFytJHaMqz6BCurKRuQqIJHiiWtSY9qvCUHP7nW9xRgLF21zrUBxKZXC1RaDdnaemC07 emhtN2y6/r9pEo63v/zHvizv7q7UjHyLEZLN4okxjGJ9IEg+BFiflrIXWAg417HPYg4vSX Q/YWKHqNAn/UYamyvZNl5Ktrtyc3Wg1rfe4AzlAzIXEvqTI4Aiz962IjuEVAZ9DmY/vvIE PBGbKMBEZv1J2lysYcSmvgtwM9XL31Dw/+72lB3SfMGRG+asCcUTEn0kMIw3Vw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4gDPbp5vDyzxvF for ; Mon, 11 May 2026 03:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 64B30MLF067763 for ; Mon, 11 May 2026 03:00:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 64B30MkO067762 for bugs@FreeBSD.org; Mon, 11 May 2026 03:00:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 294406] Dell Inspiron 14 7445 2-in-1 crashing - AMD Ryzen 7 8840HS Date: Mon, 11 May 2026 03:00:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: anthony.katernoza@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294406 --- Comment #11 from Anthony Katernoza --- (In reply to Anthony Katernoza from comment #10) Update: I have drilled down from the high-level panic, to what I think is the exact assembly instruction that was never properly executed, thus causing the pan= ic. I first found a fatal trap 12 to investigate what I think is an instance of poisoned memory: Fatal trap 12: page fault while in kernel mode cpuid =3D 4; apic id =3D 04 fault virtual address =3D 0x8 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff84850049 stack pointer =3D 0x28:0xfffffe00d218fd80 frame pointer =3D 0x28:0xfffffe00d218fdb0 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 (linuxkpi_short_wq_1) I then investigated 0xfffffe00d218fcc0, because it's present in 0xffffffff8107df69 in trap_pfault: (kgdb) p * (struct trapframe *) 0xfffffe00d218fcc0 $1 =3D {tf_rdi =3D -2098838416, tf_rsi =3D -8791749736576, tf_rdx =3D -2195= 498402544, tf_rcx =3D -2135258990, tf_r8 =3D -8791749765248, tf_r9 =3D -8791749765248,= tf_rax =3D -2098838528, tf_rbx =3D -2135267467, tf_rbp =3D -8791749765248, tf_r10 =3D -219855899750= 4, tf_r11 =3D -2118184376, tf_r12 =3D -2195498402272, tf_r13 =3D -2130371229, tf_r14 = =3D -2135267467, tf_r15 =3D 2433629222020119783, tf_trapno =3D 4294950911, tf_fs =3D 65535, = tf_gs =3D 65535, tf_addr =3D -1, tf_flags =3D 4294967295, tf_es =3D 65535, tf_ds =3D = 65535, tf_err =3D -1, tf_rip =3D -1, tf_cs =3D -1, tf_rflags =3D -1, tf_rsp =3D -1, tf_ss =3D -1} (kgdb) p/x * (struct trapframe *) 0xfffffe00d218fcc0 $2 =3D {tf_rdi =3D 0xffffffff82e64470, tf_rsi =3D 0xfffff80102e14780, tf_rd= x =3D 0xfffffe00d218fd10, tf_rcx =3D 0xffffffff80ba8892, tf_r8 =3D 0xfffff80102e0= d780, tf_r9 =3D 0xfffff80102e0d780, tf_rax =3D 0xffffffff82e64400, tf_rbx =3D 0xffffffff80ba6775, tf_rbp =3D 0xfffff80102e0d780, tf_r10 =3D 0xfffffe001bac0400, tf_r11 =3D 0xffffffff81b= f1248, tf_r12 =3D 0xfffffe00d218fe20, tf_r13 =3D 0xffffffff81051d63, tf_r14 =3D 0xffffffff80ba6775, tf_r15 =3D 0x21c5fce22d84fce7, tf_trapno =3D 0xffffbfff, tf_fs =3D 0xffff, tf_gs =3D 0= xffff, tf_addr =3D 0xffffffffffffffff, tf_flags =3D 0xffffffff, tf_es =3D 0xffff, tf_ds =3D 0xffff, tf_err =3D 0xffffffffffffffff, tf_rip =3D 0xffffffffffffffff, tf_cs =3D 0xffffffffffff= ffff, tf_rflags =3D 0xffffffffffffffff, tf_rsp =3D 0xffffffffffffffff, tf_ss =3D 0xffffffffffffffff} These results correlate with another address I investigated ((kgdb) x/10i 0xffffffff84850049 - 20), where I got: 0xffffffff84850045 : mov 0x8(%r14),%rcx 0xffffffff84850049 : mov %rcx,0x8(%rax) 0xffffffff8485004d : mov %rax,(%rcx) 0xffffffff84850050 : movq $0x0,(%r14) 0xffffffff84850057 : movq $0x0,0x8(%r14) Due to the possibility of a corruption issue due to a double-fault, I did an investigation of the memory dump ((kgdb) x/64gx 0xfffffe00d218fd80) and fou= nd: 0xfffffe00d218fd80: 0xffffffffffffffff 0xffffffffffffffff 0xfffffe00d218fd90: 0xffffffffffffffff 0xffffffffffffffff 0xfffffe00d218fda0: 0xffffffffffffffff 0xffffffffffffffff 0xfffffe00d218fdb0: 0xffffffffffffffff 0xfffffe00d218fd38 0xfffffe00d218ff10: 0xffffffff80bd98b0 0x0000000000000000 0xfffffe00d218ff20: 0x0000000000000000 0x0000000000000000 0xfffffe00d218ff30: 0x0000000000000000 0xffffffff81054f7e To me, this looks like data corruption, so I investigated one of the KVM addresses ((kgdb) info symbol 0xffffffff81054f7e) and found: fork_trampoline + 14 in section .text of /boot/kernel/kernel I proceeded to investigate that code in the context of a device ((kgdb) p *(struct device*) 0xffffffff81054f7e) and found this: $1 =3D {parent =3D 0xf2e660000195de9, irqents =3D {next =3D 0xf000000000084= 1f, prev =3D 0xe8ae0ff8010f001f}, bsddev =3D 0x1a8253c834865, bsddev_attached_here =3D false, driver =3D 0xf000001a025048b, type =3D 0xb825048b4865d822, devt =3D 5204165019972927489, class =3D 0x8b4810894824148b, release =3D 0x4808508948082454, kobj =3D { parent =3D 0x105089481024548b, name =3D 0x5089481824548b48 , kref =3D {refcount =3D {counter =3D 1418414104}}, ktype =3D 0x482824548b482050, entry =3D {next =3D 0x3024548b48285089, prev =3D 0x5ac4894830508948}, oidp =3D 0x841f0f2e6612eb58, kset =3D 0x441f0f0000000000}, dma_priv =3D 0x48026af8010f0000, driver_data =3D 0x894800000090ec81, irq =3D 1214587964, irq_start =3D 53931= 1243, irq_end =3D 2197815296, groups =3D 0x6c8c7c24648cfe00, fwnode =3D 0x8c24848= c7e24, backlight_dev =3D 0x8e249c8c00, bd =3D 0x5489483024448948, devres_lock =3D { lock_object =3D { lo_name =3D 0xe818244c89481024 , lo_flags =3D 157654, lo_data =3D 1955154171, lo_witness =3D 0x4c202444894c0824}, mtx_lock =3D 2620120026226904201}, devres_head =3D {next =3D 0x894c40246c894838, prev =3D 0x50245c894c482454}, power =3D {usage_count =3D {counter =3D 610568524}}} In short, the ACPI tables cannot communicate with realtek hardware. This se= ems to me that this conflict is causing nonsense data to be fed back to ACPI, w= hich then spreads to other components and causes problems of keyboard, mousepad = and wifi issues, along with crashes. --=20 You are receiving this mail because: You are the assignee for the bug.=