Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Nov 2021 13:29:14 +0100
From:      tuexen@freebsd.org
To:        Mark Millard <marklmi@yahoo.com>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."?
Message-ID:  <3A646420-0FB9-4C58-BA97-EE1040958B6E@freebsd.org>
In-Reply-To: <E76BD6F5-2170-4E98-B407-7646CF456828@yahoo.com>
References:  <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> <E76BD6F5-2170-4E98-B407-7646CF456828@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 19. Nov 2021, at 00:11, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2021-Nov-18, at 12:31, tuexen@freebsd.org <tuexen@FreeBSD.org> =
wrote:
>>=20
>>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current =
<freebsd-current@freebsd.org> wrote:
>>>=20
>>> I've not noticed the ertt message before in:
>>>=20
>>> . . .
>>> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to =
stop... done
>>> All buffers synced.
>>> Uptime: 1d9h57m18s
>>> Khelp module "ertt" can't unload until its refcount drops from 1 to =
0.
>> Hi Mark,
>>=20
>> what kernel configuration are you using? What kernel modules are =
loaded?
>=20
> The shutdown was of my ZFS boot media but the machine is
> currently doing builds on the UFS media. (The ZFS media is
> present but not mounted). For now I provide information
> from the booted UFS system. The UFS context is intended
> to be nearly a copy of the brctl selection for main [so: 14]
> from the ZFS media. Both systems have been doing the same
> poudriere builds for various comparison/contrast purposes.
> The current build activity will likely take 16+ hrs.
Hi Mark,

thanks a lot for the information. I was contemplating whether this =
message
was related to a recent change in the TCP congestion module handling, =
but
since it was already there in February, this is not the case. Will try =
to
reproduce this, but wasn't able up to now.

Best regards
Michael
>=20
> For reference for now (from UFS context):
>=20
> # uname -apKU
> FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 =
main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400042 1400042
>=20
> This environment was built with -mcpu=3Dcortex-a72 in use and the
> system is a 16 core Cortex-A72 system. (I've caught a FreeBSD
> weak memory model error in the past with such -mcpu=3Dcortext-a72
> use on a Cortext-A72 system, not that I have evidence of such
> here.)
>=20
> # kldstat
> Id Refs Address                Size Name
> 1   18 0xffff000000000000  12b1660 kernel
> 2    1 0xffff0000012b2000   41e070 zfs.ko
> 3    1 0xffff0000016d1000    26af8 cryptodev.ko
> 4    1 0xffff00019a400000    27000 nullfs.ko
> 5    1 0xffff00019a427000    25000 fdescfs.ko
>=20
> # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72
> include "GENERIC-NODBG"
>=20
> ident   GENERIC-NODBG-CA72
>=20
> makeoptions     CONF_CFLAGS=3D"-mcpu=3Dcortex-a72"
>=20
> # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG
> #
> # GENERIC -- Custom configuration for the arm64/aarch64
> #
>=20
> include "GENERIC"
>=20
> ident   GENERIC-NODBG
>=20
> makeoptions     DEBUG=3D-g                # Build kernel with gdb(1) =
debug symbols
>=20
> options         ALT_BREAK_TO_DEBUGGER
>=20
> options         KDB                     # Enable kernel debugger =
support
>=20
> # For minimum debugger support (stable branch) use:
> #options        KDB_TRACE               # Print a stack trace for a =
panic
> options         DDB                     # Enable the kernel debugger
>=20
> # Extra stuff:
> #options        VERBOSE_SYSINIT=3D0       # Enable verbose sysinit =
messages
> #options        BOOTVERBOSE=3D1
> #options        BOOTHOWTO=3DRB_VERBOSE
> #options        KTR
> #options        KTR_MASK=3DKTR_TRAP
> ##options       KTR_CPUMASK=3D0xF
> #options        KTR_VERBOSE
>=20
> # Disable any extra checking for. . .
> nooptions       DEADLKRES               # Enable the deadlock resolver
> nooptions       INVARIANTS              # Enable calls of extra sanity =
checking
> nooptions       INVARIANT_SUPPORT       # Extra sanity checks of =
internal structures, required by INVARIANTS
> nooptions       WITNESS                 # Enable checks to detect =
deadlocks and cycles
> nooptions       WITNESS_SKIPSPIN        # Don't run witness on =
spinlocks for speed
> nooptions       DIAGNOSTIC
> nooptions       MALLOC_DEBUG_MAXZONES   # Separate malloc(9) zones
> nooptions       BUF_TRACKING
> nooptions       FULL_BUF_TRACKING
>=20
>=20
> The builds do include a bulk for targeting armv7
> (so 32-bit compatibility) but that bulk has not
> started yet in the UFS context.
>=20
> # poudriere jail -jmain-CA7 -i
> Jail name:         main-CA7
> Jail version:      14.0-CURRENT
> Jail arch:         arm.armv7
> Jail method:       null
> Jail mount:        /usr/obj/DESTDIRs/main-CA7-poud
> Jail fs:          =20
> Jail updated:      2021-11-16 02:24:57
> Jail pkgbase:      disabled
>=20
> My networking context is simple context does not provide
> services outside the local network. The services are normal
> ones, such as nfs, ssh, and whatever default things. ntpd
> is in use. distfiles are downloaded during builds. It is not
> a desktop environment, not even a video card.
>=20
> I've noticed a 2021-Feb-22 report in:
>=20
> =
https://forums.freebsd.org/threads/whats-the-error-khelp-module-ertt-unloa=
d.79009/
>=20
> so getting the message does not appear to be unique to my
> context.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A646420-0FB9-4C58-BA97-EE1040958B6E>