Re: git: 477c594d9063 - main - kobj: allow multiple inheritance with per-class softc
Date: Fri, 18 Sep 2026 09:32:13 UTC
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 ? > That lets it boot. Best regards, Kristof