Date: Mon, 11 May 2026 03:00:23 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 294406] Dell Inspiron 14 7445 2-in-1 crashing - AMD Ryzen 7 8840HS Message-ID: <bug-294406-227-EXjYa2WBSV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-294406-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294406 --- Comment #11 from Anthony Katernoza <anthony.katernoza@gmail.com> --- (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 panic. 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 = 4; apic id = 04 fault virtual address = 0x8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff84850049 stack pointer = 0x28:0xfffffe00d218fd80 frame pointer = 0x28:0xfffffe00d218fdb0 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 = 0 (linuxkpi_short_wq_1) I then investigated 0xfffffe00d218fcc0, because it's present in 0xffffffff8107df69 in trap_pfault: (kgdb) p * (struct trapframe *) 0xfffffe00d218fcc0 $1 = {tf_rdi = -2098838416, tf_rsi = -8791749736576, tf_rdx = -2195498402544, tf_rcx = -2135258990, tf_r8 = -8791749765248, tf_r9 = -8791749765248, tf_rax = -2098838528, tf_rbx = -2135267467, tf_rbp = -8791749765248, tf_r10 = -2198558997504, tf_r11 = -2118184376, tf_r12 = -2195498402272, tf_r13 = -2130371229, tf_r14 = -2135267467, tf_r15 = 2433629222020119783, tf_trapno = 4294950911, tf_fs = 65535, tf_gs = 65535, tf_addr = -1, tf_flags = 4294967295, tf_es = 65535, tf_ds = 65535, tf_err = -1, tf_rip = -1, tf_cs = -1, tf_rflags = -1, tf_rsp = -1, tf_ss = -1} (kgdb) p/x * (struct trapframe *) 0xfffffe00d218fcc0 $2 = {tf_rdi = 0xffffffff82e64470, tf_rsi = 0xfffff80102e14780, tf_rdx = 0xfffffe00d218fd10, tf_rcx = 0xffffffff80ba8892, tf_r8 = 0xfffff80102e0d780, tf_r9 = 0xfffff80102e0d780, tf_rax = 0xffffffff82e64400, tf_rbx = 0xffffffff80ba6775, tf_rbp = 0xfffff80102e0d780, tf_r10 = 0xfffffe001bac0400, tf_r11 = 0xffffffff81bf1248, tf_r12 = 0xfffffe00d218fe20, tf_r13 = 0xffffffff81051d63, tf_r14 = 0xffffffff80ba6775, tf_r15 = 0x21c5fce22d84fce7, tf_trapno = 0xffffbfff, tf_fs = 0xffff, tf_gs = 0xffff, tf_addr = 0xffffffffffffffff, tf_flags = 0xffffffff, tf_es = 0xffff, tf_ds = 0xffff, tf_err = 0xffffffffffffffff, tf_rip = 0xffffffffffffffff, tf_cs = 0xffffffffffffffff, tf_rflags = 0xffffffffffffffff, tf_rsp = 0xffffffffffffffff, tf_ss = 0xffffffffffffffff} These results correlate with another address I investigated ((kgdb) x/10i 0xffffffff84850049 - 20), where I got: 0xffffffff84850045 <rtw89_fw_c2h_work+101>: mov 0x8(%r14),%rcx 0xffffffff84850049 <rtw89_fw_c2h_work+105>: mov %rcx,0x8(%rax) 0xffffffff8485004d <rtw89_fw_c2h_work+109>: mov %rax,(%rcx) 0xffffffff84850050 <rtw89_fw_c2h_work+112>: movq $0x0,(%r14) 0xffffffff84850057 <rtw89_fw_c2h_work+119>: 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 found: 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 = {parent = 0xf2e660000195de9, irqents = {next = 0xf0000000000841f, prev = 0xe8ae0ff8010f001f}, bsddev = 0x1a8253c834865, bsddev_attached_here = false, driver = 0xf000001a025048b, type = 0xb825048b4865d822, devt = 5204165019972927489, class = 0x8b4810894824148b, release = 0x4808508948082454, kobj = { parent = 0x105089481024548b, name = 0x5089481824548b48 <error: Cannot access memory at address 0x5089481824548b48>, kref = {refcount = {counter = 1418414104}}, ktype = 0x482824548b482050, entry = {next = 0x3024548b48285089, prev = 0x5ac4894830508948}, oidp = 0x841f0f2e6612eb58, kset = 0x441f0f0000000000}, dma_priv = 0x48026af8010f0000, driver_data = 0x894800000090ec81, irq = 1214587964, irq_start = 539311243, irq_end = 2197815296, groups = 0x6c8c7c24648cfe00, fwnode = 0x8c24848c7e24, backlight_dev = 0x8e249c8c00, bd = 0x5489483024448948, devres_lock = { lock_object = { lo_name = 0xe818244c89481024 <error: Cannot access memory at address 0xe818244c89481024>, lo_flags = 157654, lo_data = 1955154171, lo_witness = 0x4c202444894c0824}, mtx_lock = 2620120026226904201}, devres_head = {next = 0x894c40246c894838, prev = 0x50245c894c482454}, power = {usage_count = {counter = 610568524}}} In short, the ACPI tables cannot communicate with realtek hardware. This seems to me that this conflict is causing nonsense data to be fed back to ACPI, which then spreads to other components and causes problems of keyboard, mousepad and wifi issues, along with crashes. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-294406-227-EXjYa2WBSV>