Re: amd64 boot crash for lack of being set up to use of rtw89; linuxkpi calls on the stack, 0xdeadc0dedeadc13e and such involved, devfs_ioctl with dsw=0xdeadc0dedeadc0de
Ryan Libby <[email protected]> Sat, 25 Jul 2026 11:48:09 -0700
| Newsgroups | gmane.os.freebsd.current |
|---|---|
| Message-ID | <CAHgpiFzM3kjdLon6Qn02cSR+SBugJ-LkCqUwTqLCzOU1BvFzuA@mail.gmail.com> |
On Sat, Jul 25, 2026 at 10:54=E2=80=AFAM Mark Millard <[email protected]> w= rote: > > On 7/25/26 09:51, Bjoern A. Zeeb wrote: > > On Sat, 25 Jul 2026, Mark Millard wrote: > > > > Sorry, > > > > is the tail of your dmesg going along the lines of: > > > > devmatch trying to load rtw89 > > rtw89 trying to laod firmware > > that fails > > device attach fails > > panic? > > Unfortutely, the core.text.* files end with: > > QUOTE > ddb capture buffer > > ddb: ddb_capture: kvm_nlist > END QUOTE > > The screen display is mostly the backtrace. What does show are messages > about: > > . . . could not load firmware image, error 2 > Trying to load binary firmware from . . . > . . . could not load binary firmware . . . either > . . . could not load firmware image, error 2 > Trying to load binary firmware from . . . > . . . could not load binary firmware . . . either > . . . could not load fimrware image . . . > . . . failed to wait firmware completion > . . . failed to setup chip information > > Fatal trap 9 . . . > . . . > > For reference (from an earlier screen shot from a debug kernel test): > > rax shows: deadc0dedeadc0de > rsi shows: deadc0dedeadc13e > > (So such shows up both at #35 and at the fatal trap 9 point.) > > current thread resports: (devctl/devctl) > > I'll also note in the backtrace it shows 0xdeadc0dedeadc13e > as involved in the atomic_fetchadd_int falure: > > . . . > #12 0xffffffff811a065f in trap_fatal (frame=3D0xfffffe02a599e880, > #13 <signal handler called> > #14 0xffffffff80ef1845 in atomic_fetchadd_int (p=3D0xdeadc0dedeadc13e, > . . . > > > > > > > More below. > > > > > >> On 7/25/26 04:31, Bjoern A. Zeeb wrote: > >>> On Fri, 24 Jul 2026, Mark Millard wrote: > >>> > >>> > >>> .... > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/include/ > >>>> linux/device.h:376 > >>>> No locals. > >>>> #20 pci_dev_put (pdev=3D0xdeadc0dedeadc0de) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/include/ > >>>> linux/pci.h:474 > >>>> No locals. > >>>> #21 lkpi_pci_dev_release (dev=3D0xfffff8014e842a00) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/src/ > >>>> linux_pci.c:374 > >>> > >>> That would be my recent change I assume. > >>> > >>> > >>> Can you test this? > >>> > >>> % git diff > >>> diff --git sys/compat/linuxkpi/common/src/linux_pci.c sys/compat/ > >>> linuxkpi/common/src/linux_pci.c > >>> index a49254425b5d..b1c28a188b94 100644 > >>> --- sys/compat/linuxkpi/common/src/linux_pci.c > >>> +++ sys/compat/linuxkpi/common/src/linux_pci.c > >>> @@ -370,7 +370,7 @@ lkpi_pci_dev_release(struct device *dev) > >>> */ > >>> > >>> /* Clear the hierarchy recursively to root. */ > >>> - if (pdev->bus->self !=3D pdev) { > >>> + if (pdev->bus->self !=3D pdev && pdev->bus->self !=3D NULL) { > >>> pci_dev_put(pdev->bus->self); > >>> pdev->bus->self =3D NULL; > >>> } > >>> > >> > >> See later below. > >> > >>> > >>> > >>>> pdev =3D 0xfffff8014e842a00 > >>>> #22 0xffffffff80eed1c8 in linux_kobject_release (kref=3D<optimized o= ut>) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/src/ > >>>> linux_kobject.c:186 > >>>> kobj =3D 0xfffff8014e842a50 > >>>> name =3D 0xfffff80107bcd670 "rtw890" > >>>> #23 0xffffffff80ef11ea in kref_put (kref=3D0xdeadc0dedeadc13e, > >>>> rel=3D<optimized out>) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/include/ > >>>> linux/kref.h:73 > >>>> No locals. > >>>> #24 kobject_put (kobj=3D0xfffff8014e842a50) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/include/ > >>>> linux/kobject.h:113 > >>>> No locals. > >>>> #25 put_device (dev=3D0xfffff8014e842a00) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/include/ > >>>> linux/device.h:376 > >>>> No locals. > >>>> #26 linux_pci_attach_device (dev=3D<optimized out>, pdrv=3D<optimize= d out>, > >>>> id=3D<optimized out>, pdev=3D0xfffff8014e842a00) > >>>> at > >>>> /home/pkgbuild/worktrees/main/sys/compat/linuxkpi/common/src/ > >>>> linux_pci.c:744 > >>>> rid =3D 2304 > >>>> parent =3D <optimized out> > >>>> isdrm =3D <optimized out> > >>>> error =3D <optimized out> > >>>> rle =3D <optimized out> > >>>> pbus =3D <optimized out> > >>>> ppbus =3D <optimized out> > >>>> #27 0xffffffff80c536c6 in DEVICE_ATTACH (dev=3D0xfffff8010799a800) > >>>> at ./device_if.h:195 > >>>> _m =3D <optimized out> > >>>> rc =3D <optimized out> > >>>> #28 device_attach (dev=3D0xfffff8010799a800) > >>>> at /home/pkgbuild/worktrees/main/sys/kern/subr_bus.c:2630 > >>>> attachentropy =3D 32965 > >>>> saved_vnet =3D 0x0 > >>>> attachtime =3D 1943114510 > >>>> error =3D <optimized out> > >>>> #29 0xffffffff80c53255 in device_probe_and_attach > >>>> (dev=3D0xfffff8014e842a00, > >>>> dev@entry=3D0xfffff8010799a800) > >>>> at /home/pkgbuild/worktrees/main/sys/kern/subr_bus.c:2579 > >>> ... > >>> > >> > >> I built a new kernel pair (debug and non-debug) based on updating the > >> pkgbase /usr/src/ the system is based on. > >> > >> Booting the debug build still failed. The deadc0de based value that is > >> assocaited with the longest lasting stack frame from with such a value > >> is reported is still in the dsw for: > >> > >> #35 0xffffffff80a7ac9c in devfs_ioctl (ap=3D0xfffffe02a599ec40) > >> at /usr/src/sys/fs/devfs/devfs_vnops.c:964 > >> dev =3D 0xfffff801072a1800 > >> ref =3D 0 > >> vp =3D 0xfffff8014c11a6e0 > >> com =3D 2157462540 > >> td =3D 0xfffff80149a31780 > >> dsw =3D 0xdeadc0dedeadc0de > >> error =3D <optimized out> > >> fgn =3D <optimized out> > >> p =3D <optimized out> > >> i =3D <optimized out> > >> sess =3D <optimized out> > >> vpold =3D <optimized out> > >> > >> So I would expect #0 .. #34 to all be after that specific problem. > > > > I would assume that's an uninitialized value but I haven't looked at > > that ioctl code. > > Values based on 0xdeadc0dedeadc0de show up in rax and rsi in the > register dump, in the atomic_fetchadd_int failure, and in #35. > > > > > If there's a problem already then different story. > > Seems suggestive of the fatal trap 9 being dependent on the odd value in > #35, not that I've analyzed the code involved between those two points. > > > > > > >> The new gdb report follows . . . > >> > >> Reading symbols from /boot/kernel.amd64-usr_src-DEBUG/kernel... > >> Reading symbols from > >> /usr/lib/debug//boot/kernel.amd64-usr_src-DEBUG/kernel.debug... > >> . . . > >> Reading symbols from /boot/kernel.amd64-usr_src-DEBUG/smbus.ko... > >> Reading symbols from > >> /usr/lib/debug//boot/kernel.amd64-usr_src-DEBUG/smbus.ko.debug... > >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > >> 57 __asm("movq %%gs:%c1,%0" : "=3Dr" (td) > >> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 > >> td =3D <optimized out> > >> #1 doadump (textdump=3Dtextdump@entry=3D0) > >> at /usr/src/sys/kern/kern_shutdown.c:399 > >> error =3D 0 > >> coredump =3D <optimized out> > >> #2 0xffffffff804c77da in db_dump (dummy=3D<optimized out>, > >> dummy2=3D<optimized out>, dummy3=3D<optimized out>, dummy4=3D<optim= ized > >> out>) > >> at /usr/src/sys/ddb/db_command.c:596 > >> error =3D <optimized out> > >> #3 0xffffffff804c768a in db_command (last_cmdp=3D<optimized out>, > >> cmd_table=3D<optimized out>, dopager=3Dtrue) > >> at /usr/src/sys/ddb/db_command.c:508 > >> modif =3D "\000B=DA=81\377\377\377\377\n", '\000' <repeats 15 t= imes>, > >> "x\000\000\000\000\000\000\000\b\000\000\0000\000\000\000\340=E2=99=A5= \002\376\377\377`=E2=99=A5\002\376\377\377\375(\321f\355\177)[ > >> =E3=99=A5\002\376\377\377D\236L\200\377\377\377\377\017", '\000' <repe= ats 15 > >> times>, > >> "\020\220\275\201\377\377\377\377\000\000\000\000\000\000\000\000\200\= 027\243I\001\370\377\377" > >> addr =3D -2134482909 > >> count =3D -1 > >> cmd =3D 0xffffffff81a16ff8 <db_cmds+616> > >> have_addr =3D <optimized out> > >> t =3D <optimized out> > >> result =3D <optimized out> > >> #4 0xffffffff804c72ad in db_command_loop () > >> at /usr/src/sys/ddb/db_command.c:555 > >> No locals. > >> #5 0xffffffff804caee0 in db_trap (type=3D<optimized out>, code=3D<opt= imized > >> out>) > >> at /usr/src/sys/ddb/db_main.c:267 > >> jb =3D {{_jb =3D {0, -2187654995128, -2187654994976, -879056262= 9760, > >> -2120123568, -2187654995104, -2187654994432, -2142458264, > >> -2187654995008, -2136782033, -2116402656, 3}}} > >> bkpt =3D false > >> watchpt =3D false > >> prev_jb =3D 0x0 > >> why =3D <optimized out> > >> #6 0xffffffff80c66b1f in kdb_trap (type=3Dtype@entry=3D3, code=3Dcode= @entry=3D0, > >> tf=3Dtf@entry=3D0xfffffe02a599e600) at /usr/src/sys/kern/subr_kdb.c= :790 > >> __pc =3D 0x0 > >> __pc =3D 0x0 > >> other_cpus =3D {__bits =3D {18446744071583149600, > >> 18446741886054557328, > >> 4294967282, 5, 2778326384, 0, 3545567873046937600, > >> 18446744071575110192, 18446744071582117664, > >> 18446744071582540027, > >> 0, 12, 18446741886054557056, 0, 18446741886054559552, > >> 11100633178600}} > >> be =3D 0xffffffff81a17b50 <ddb_dbbe> > >> intr =3D 70 > >> did_stop_cpus =3D <optimized out> > >> handled =3D <optimized out> > >> #7 0xffffffff811a0335 in trap (frame=3D<optimized out>) > >> at /usr/src/sys/amd64/amd64/trap.c:702 > >> __pc =3D 0x0 > >> __pc =3D 0x0 > >> __pc =3D 0x0 > >> ksi =3D {ksi_link =3D {tqe_next =3D 0x1, tqe_prev =3D 0xfffff82= ae17f6f00}, > >> ksi_info =3D {si_signo =3D 5, si_errno =3D 0, si_code =3D -1,= si_pid > >> =3D 0, > >> si_uid =3D 2778326608, si_status =3D -510, > >> si_addr =3D 0xffffffff80c708ab <_vprintf+139>, si_value =3D= { > >> sival_int =3D 5, sival_ptr =3D 0xffffffff00000005, sigval= _int > >> =3D 5, > >> sigval_ptr =3D 0xffffffff00000005}, _reason =3D {_fault = =3D { > >> _trapno =3D 0}, _timer =3D {_timerid =3D 0, _overrun = =3D 0}, > >> _mesgq =3D { > >> _mqd =3D 0}, _poll =3D {_band =3D 0}, _capsicum =3D {_s= yscall =3D > >> 0}, > >> __spare__ =3D {__spare1__ =3D 0, __spare2__ =3D {-1516640= 848, > >> -510, > >> 128, 0, -1516640848, -510, 128}}}}, ksi_flags =3D > >> 977421312, > >> ksi_sigq =3D 0x696e6170203a7265} > >> signo =3D 0 > >> ucode =3D 256 > >> td =3D <optimized out> > >> p =3D 0xfffffe0366641040 > >> dr6 =3D 0 > >> type =3D 3 > >> addr =3D <optimized out> > >> pf =3D <optimized out> > >> i =3D <optimized out> > >> #8 <signal handler called> > >> No locals. > >> #9 kdb_enter (why=3D<optimized out>, msg=3D<optimized out>) > >> at /usr/src/sys/kern/subr_kdb.c:556 > >> No locals. > >> #10 0xffffffff80c10dc9 in vpanic (fmt=3D<optimized out>, > >> ap=3Dap@entry=3D0xfffffe02a599e830) at /usr/src/sys/kern/ > >> kern_shutdown.c:962 > >> buf =3D "general protection fault", '\000' <repeats 231 times> > >> __pc =3D 0x0 > >> __pc =3D 0x0 > >> __pc =3D 0x0 > >> other_cpus =3D {__bits =3D {4294934527, 0 <repeats 15 times>}} > >> td =3D 0xfffff80149a31780 > >> bootopt =3D <optimized out> > >> newpanic =3D <optimized out> > >> #11 0xffffffff80c10c43 in panic ( > >> fmt=3D0xffffffff81da4260 <cnputs_mtx> "\241@)\201\377\377\377\377") > >> at /usr/src/sys/kern/kern_shutdown.c:887 > >> ap =3D {{gp_offset =3D 16, fp_offset =3D 48, > >> overflow_arg_area =3D 0xfffffe02a599e860, > >> reg_save_area =3D 0xfffffe02a599e800}} > >> #12 0xffffffff811a065f in trap_fatal (frame=3D0xfffffe02a599e880, > >> eva=3D<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1031 > >> type =3D <optimized out> > >> #13 <signal handler called> > >> No locals. > >> #14 0xffffffff80ef1845 in atomic_fetchadd_int (p=3D0xdeadc0dedeadc13e, > >> v=3D4294967295) at /usr/src/sys/amd64/include/atomic.h:194 > >> No locals. > >> #15 refcount_releasen (count=3D0xdeadc0dedeadc13e, n=3D1) > >> at /usr/src/sys/sys/refcount.h:149 > >> old =3D <optimized out> > >> #16 refcount_release (count=3D0xdeadc0dedeadc13e) > >> at /usr/src/sys/sys/refcount.h:171 > >> No locals. > >> #17 kref_put (kref=3D0xdeadc0dedeadc13e, rel=3D<optimized out>) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/kref.h:72 > >> No locals. > >> #18 kobject_put (kobj=3D0xdeadc0dedeadc12e) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/kobject.h:113 > >> No locals. > >> #19 put_device (dev=3D0xdeadc0dedeadc0de) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:376 > >> No locals. > >> #20 pci_dev_put (pdev=3D0xdeadc0dedeadc0de) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:474 > >> No locals. > > > > The above has changed if I am not wrong... > > > >> #21 lkpi_pci_dev_release (dev=3D0xfffff8015a144a00) > >> at /usr/src/sys/compat/linuxkpi/common/src/linux_pci.c:374 > >> pdev =3D 0xfffff8015a144a00 > >> #22 0xffffffff80eed308 in linux_kobject_release (kref=3D<optimized out= >) > >> at /usr/src/sys/compat/linuxkpi/common/src/linux_kobject.c:186 > >> kobj =3D 0xfffff8015a144a50 > >> name =3D 0xfffff82ae1802610 "rtw890" > >> #23 0xffffffff80ef132a in kref_put (kref=3D0xdeadc0dedeadc13e, > >> rel=3D<optimized out>) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/kref.h:73 > >> No locals. > >> #24 kobject_put (kobj=3D0xfffff8015a144a50) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/kobject.h:113 > >> No locals. > >> #25 put_device (dev=3D0xfffff8015a144a00) > >> at /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:376 > >> No locals. > > > > And I misread this before. > > > > This is the error case in linux_pci_attach_device(): > > > > You may notice my comment there: > > > > 734 > > 735 /* XXX the cleanup does not match the allocation up there. */ > > 736 out_probe: > > 737 free(pdev->bus, M_DEVBUF); > > 738 spin_lock_destroy(&pdev->pcie_cap_lock); > > 739 linux_pdev_dma_uninit(pdev); > > 740 out_dma_init: > > 741 spin_lock(&pci_lock); > > 742 list_del(&pdev->links); > > 743 spin_unlock(&pci_lock); > > 744 put_device(&pdev->dev); // <<<<<<<<< here > > 745 return (-error); > > 746 } > > > > > > There's D57430 and D57431 still open that no one has reviewed so far. > > You could try to apply them. > > I expect I'll take a look at doing such later. > > > > > The earlieE change I'll just commit anyway as it is needed as well. > > Sounds good. > > > > > /bz > > > > > >> #26 linux_pci_attach_device (dev=3D<optimized out>, pdrv=3D<optimized = out>, > >> id=3D<optimized out>, pdev=3D0xfffff8015a144a00) > >> at /usr/src/sys/compat/linuxkpi/common/src/linux_pci.c:744 > >> rid =3D 2304 > >> parent =3D <optimized out> > >> isdrm =3D <optimized out> > >> error =3D <optimized out> > >> rle =3D <optimized out> > >> pbus =3D <optimized out> > >> ppbus =3D <optimized out> > > > > Just to make it easier to see where deadc0de occurs in the backtrace: > > #1 doadump (textdump=3Dtextdump@entry=3D0) > #2 0xffffffff804c77da in db_dump (dummy=3D<optimized out>, > #3 0xffffffff804c768a in db_command (last_cmdp=3D<optimized out>, > #4 0xffffffff804c72ad in db_command_loop () > #5 0xffffffff804caee0 in db_trap (type=3D<optimized out>, code=3D<optimi= zed > out>) > #6 0xffffffff80c66b1f in kdb_trap (type=3Dtype@entry=3D3, code=3Dcode@en= try=3D0, > #7 0xffffffff811a0335 in trap (frame=3D<optimized out>) > #8 <signal handler called> > #9 kdb_enter (why=3D<optimized out>, msg=3D<optimized out>) > #10 0xffffffff80c10dc9 in vpanic (fmt=3D<optimized out>, > #11 0xffffffff80c10c43 in panic ( > #12 0xffffffff811a065f in trap_fatal (frame=3D0xfffffe02a599e880, > #13 <signal handler called> > #14 0xffffffff80ef1845 in atomic_fetchadd_int (p=3D0xdeadc0dedeadc13e, > #15 refcount_releasen (count=3D0xdeadc0dedeadc13e, n=3D1) > #16 refcount_release (count=3D0xdeadc0dedeadc13e) > #17 kref_put (kref=3D0xdeadc0dedeadc13e, rel=3D<optimized out>) > #18 kobject_put (kobj=3D0xdeadc0dedeadc12e) > #19 put_device (dev=3D0xdeadc0dedeadc0de) > #20 pci_dev_put (pdev=3D0xdeadc0dedeadc0de) > #21 lkpi_pci_dev_release (dev=3D0xfffff8015a144a00) > #22 0xffffffff80eed308 in linux_kobject_release (kref=3D<optimized out>) > #23 0xffffffff80ef132a in kref_put (kref=3D0xdeadc0dedeadc13e, > #24 kobject_put (kobj=3D0xfffff8015a144a50) > #25 put_device (dev=3D0xfffff8015a144a00) > #26 linux_pci_attach_device (dev=3D<optimized out>, pdrv=3D<optimized out= >, > #27 0xffffffff80c536c6 in DEVICE_ATTACH (dev=3D0xfffff801079af800) > #28 device_attach (dev=3D0xfffff801079af800) at > /usr/src/sys/kern/subr_bus.c:2630 > #29 0xffffffff80c53255 in device_probe_and_attach (dev=3D0xfffff8015a144a= 00, > #30 0xffffffff80892e32 in pci_driver_added (dev=3D0xfffff801079af900, > #31 0xffffffff80c50b19 in BUS_DRIVER_ADDED (_dev=3D0xfffff801079af900, > #32 devclass_driver_added (dc=3Ddc@entry=3D0xfffff8010198e500, > #33 0xffffffff80c59cab in device_do_deferred_actions () > #34 0xffffffff80c595f6 in devctl2_ioctl (cdev=3D<optimized out>, > cmd=3D2157462540, > #35 0xffffffff80a7ac9c in devfs_ioctl (ap=3D0xfffffe02a599ec40) > dsw =3D 0xdeadc0dedeadc0de > #36 0xffffffff81278951 in VOP_IOCTL_APV ( > #37 0xffffffff80d3ea0f in VOP_IOCTL (vp=3D<optimized out>, > #38 0xffffffff80d3ea0f in vn_ioctl (fp=3D<optimized out>, com=3D<optimize= d > out>, > #39 0xffffffff80a7b3be in devfs_ioctl_f (fp=3D0xfffff8015a144a00, > #40 0xffffffff80c95dbd in fo_ioctl (fp=3D0xfffff8014d5e3a50, com=3D215746= 2540, > #41 kern_ioctl (td=3Dtd@entry=3D0xfffff80149a31780, fd=3D<optimized out>, > #42 0xffffffff80c95a9f in sys_ioctl (td=3D0xfffff80149a31780, > #43 0xffffffff811a13ec in syscallenter (td=3D0xfffff80149a31780) > #44 amd64_syscall (td=3D0xfffff80149a31780, traced=3D0) > #45 <signal handler called> > #46 0x00000a1894a4148a in ?? () > > > -- > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > Drive-by comment, I don't know this code. It seems to suggest pdev->bus in lkpi_pci_dev_release points to a freed object. Back in linux_pci_attach_device (frame #26), in the probe failure path that does goto out_probe, we free(pdev->bus, M_DEVBUF), and then call put_device(&pdev->dev) (frame #25), and then in lkpi_pci_dev_release (frame #21) we try to use the freed pdev->bus. You could try assigning pdev->bus to a distinct junk value after the free in linux_pci_attach_device to confirm this. Ryan