Date: Sat, 23 Sep 2023 14:00:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Shutdown -r under -current hangs on RPi3 Message-ID: <F93AD8C4-03B7-41C4-BFD8-91D5365EC8F5@yahoo.com> In-Reply-To: <D384C6AD-4FB0-4130-82E4-B923E1404401@yahoo.com> References: <ZQ8JswF1/LNR899s@www.zefox.net> <0AADDACB-ABA3-47FF-B3A7-05B313F5326C@yahoo.com> <9D29DD48-1572-4C04-AD88-8436AC8DDDCC@yahoo.com> <ZQ85fhHaO3xrfYjK@www.zefox.net> <D384C6AD-4FB0-4130-82E4-B923E1404401@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 23, 2023, at 12:41, Mark Millard <marklmi@yahoo.com> wrote: > On Sep 23, 2023, at 12:16, bob prohaska <fbsd@www.zefox.net> wrote: >=20 >> On Sat, Sep 23, 2023 at 11:34:41AM -0700, Mark Millard wrote: >>> On Sep 23, 2023, at 11:26, Mark Millard <marklmi@yahoo.com> wrote: >>>=20 >>>> On Sep 23, 2023, at 08:52, bob prohaska <fbsd@www.zefox.net> wrote: >>>>=20 >>>>> =46rom time to time, but seemingly more often lately, a Pi3 >>>>> get stuck during shutdown -r. The machine is running -current >>>>> from a mechanical usb hard disk through a powered hub. No micro >>>>> SD card is used. Once up it's quite stable. >>>>>=20 >>>>> The console reports >>>>>=20 >>>>> login: Sep 23 08:20:37 pelorus shutdown[224]: reboot by bob: >>>>> Stopping sshd. >>>>> Waiting for PIDS: 1063. >>>>> Stopping cron. >>>>> Waiting for PIDS: 1073. >>>>> Stopping powerd. >>>>> Waiting for PIDS: 1002. >>>>> Stopping devd. >>>>> Waiting for PIDS: 752. >>>>> Writing entropy file: . >>>>> Writing early boot entropy file: . >>>>> . >>>>> Terminated >>>>> Sep 23 08:20:43 pelorus syslogd: exiting on signal 15 >>>>> Waiting (max 60 seconds) for system process `vnlru' to stop... = done >>>>>=20 >>>>> Waiting (max 60 seconds) for system process `syncer' to stop... = Syncing disks, vnodes remaining... 4 0 0 0 done >>>>> All buffers synced. >>>>> Uptime: 23h31m45s >>>>> Khelp module "ertt" can't unload until its refcount drops from 1 = to 0. >>>>=20 >>>> I've gotten the above message on rare occasions over the years on >>>> the amd64 system (ThreadRipper 1950X). (But reboots and shutdowns >>>> are not frequent for this system normally.) >>>>=20 >>>> There is a recent: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271677 >>>>=20 >>>> It is not just your context with the issue. >>>>=20 >>>>> Resetting system ... >>>>>=20 >>>>> At that point all activity ceases. The only clue I can recognize = is that >>>>> the red power LED remains off, as if FreeBSD never relinquishes = control >>>>> to the Pi firmware, which turns the LED back on at powerup. = Power-cycling >>>>> results in a normal reboot. >>>>=20 >>>=20 >>> The system might produce more messages about the >>> shutdown activity if it has been booted via: >>>=20 >>> boot -v >>>=20 >>> This might narrow down the context some for someone >>> familiar with the messages --if oyu are lucky enough >>> to eventually get an example from a boot -v context. >>=20 >> I'm confused here. Boot is normal, and it doesn't >> seem to even reach the boot stage during reboot. Can >> boot -v affect the _next_ boot? >=20 > boot -v can add messages both to boot-time and to the > later reboot/shutdown-time. >=20 > You would have to keep booting with "boot -v", hoping > that the later reboot/shutdown would report extra > messages but would also include the 'help module "ertt" > can't unload' message in the sequence. Once you had > such a boot, you would report the text around the > 'help module "ertt" can't unload' message to show the > extra context. Actually, the extra messages before the hangup may be useful even if no 'help module "ertt" can't unload' message occurs: it still gives a better idea of the staging. >> It isn't clear to me that the bug report is related. It >> seems to focus on the ertt message, while my problems >> wait until the system claims to be resetting and then >> gets stuck. >=20 > I've had to force poweroff after some of the messages. >=20 > The "can't unload until its refcount drops from 1 to 0" > suggests that it is waiting to unload. (But I've no > low level detail establishing that is actually what > was going on.) >=20 > Have you recently had it get stuck without first having > the 'Khelp module "ertt" can't unload' message? (I've > not had other reboot hangups except for other known > problems that were later fixed. I've not had other > reboot/shutdown hangups in a very long time.) >=20 >> Maybe the ertt error is related, but the >> association isn't consistent=20 >=20 > Are you saying that in recent times you have had hangups > that did not first show the 'Khelp module "ertt" can't > unload' message? >=20 > The message suggests that the refcount decreasing would > lead to it not waiting any longer. (But I've no low > level detail establishing that is actually what was > going on when I did not have to force power off.) >=20 >> Unfortunately the hang does not seem easily reproducible. >=20 > Consistent with my "rare". >=20 >> Several consecutive shutdown -r reboots were successful. >=20 > To my knowledge/memory, I've never gotten the message after > being booted for only a short time (little activity). >=20 >> The hangs seen so far have all followed OS build/install >> sessions. >=20 > So a "boot -v" before such sessions might, eventually, prove > useful. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F93AD8C4-03B7-41C4-BFD8-91D5365EC8F5>