Re: git: 477c594d9063 - main - kobj: allow multiple inheritance with per-class softc

On 18.09.2026 11:32, Kristof Provost wrote:
> On 18 Sep 2026, at 9:11, Michal Meloun wrote:
> 
>     On 18.09.2026 0:15, Kristof Provost wrote:
> 
>         On 11 Sep 2026, at 16:09, Michal Meloun wrote:
> 
>         |The branch main has been updated by mmel: URL: https://
>         cgit.FreeBSD.org/src/commit/?
>         id=477c594d906328e210c30cf2c21d983152f21de3 <https://
>         cgit.FreeBSD.org/src/commit/?
>         id=477c594d906328e210c30cf2c21d983152f21de3> commit
>         477c594d906328e210c30cf2c21d983152f21de3 Author: Michal Meloun
>         mmel@FreeBSD.org <mailto:mmel@FreeBSD.org> AuthorDate:
>         2026-09-11 11:47:30 +0000 Commit: Michal Meloun mmel@FreeBSD.org
>         <mailto:mmel@FreeBSD.org> CommitDate: 2026-09-11 14:09:36 +0000
>         |kobj: allow multiple inheritance with per-class softc Add
>         support for hierarchical softc layout so that a leaf class and
>         each of its base classes owns a private softc region inside a
>         single allocation. device_get_softc_class(dev, cls) returns a
>         pointer to the softc that belongs to the requested class. The
>         classic device_get_softc() still returns the leaf softc and
>         remains fully compatible with existing drivers. Existing drivers
>         are unaffected; they simply obtain a slightly larger softc block
>         when they inherit from base classes. | |
> 
>         For some reason this commit causes my machine (Dell T640) to
>         fail to boot.
> 
>         It doesn’t panic, but it seems to be very slow during boot, and
>         seems to remain stuck around when it’d start userspace.
>         (Freezing just before | Trying to mount root from zfs:zroot/
>         ROOT/16.0-CURRENT-20260917.222603|)
> 
>         I don’t even begin to understand how that’d be related to this
>         commit, but it’s very reproducible.
> 
>         Do you have any suggestions for how to begin to debug this?
> 
>         Thanks,
>         Kristof
> 
>     I also don't see how this change could have directly caused the
>     described failure.
>     Could you generate a backtrace from the hung state? Ideally,
>     generate more than one to see where the kernel is livelocked.
> 
> I’ve not had any luck getting a backtrace out, I’m afraid. While in the 
> hung state the system doesn’t seem to be processing anything any more.
> (That is, I can get it to break to debugging when it’s working fine, but 
> not in this state.)
> 
> However, I added some debug output and spotted this:
> 
> |KP: device_set_driver() smartpqi 2579896 != 2579904 KP: 
> device_set_driver() nic_uio 184 != 4294967297 |
> 
> And that last one does seem like it’s maybe a bit more than it ought to be.
> That one’s installed by net/dpdk, so could it be an ABI mismatch?
> (Presumably the kernel ought to be a bit more robust about 4294967297 
> sized allocations, or at least panic here.)
> 
>     Also, can you, for test, replace
>     "size = kobj_total_data_size(driver);"
>     with
>     "size = driver->size;"
>     at
>     https://cgit.freebsd.org/src/tree/sys/kern/subr_bus.c#n2503
>     <https://cgit.freebsd.org/src/tree/sys/kern/subr_bus.c#n2503> ?
> 
> That lets it boot.
> 
> Best regards,
> Kristof
> 

Thanks.
Yes, nic_uio is clearly the winner.
The struct kobj was changed, meaning that all external drivers must be 
recompiled. But this should always be done after any update.

Michal