Re: Shutdown -r under -current hangs on RPi3

On Sep 23, 2023, at 12:41, Mark Millard <[email protected]> wrote:

> On Sep 23, 2023, at 12:16, bob prohaska <[email protected]> wrote:
> 
>> On Sat, Sep 23, 2023 at 11:34:41AM -0700, Mark Millard wrote:
>>> On Sep 23, 2023, at 11:26, Mark Millard <[email protected]> wrote:
>>> 
>>>> On Sep 23, 2023, at 08:52, bob prohaska <[email protected]> wrote:
>>>> 
>>>>> From 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.
>>>>> 
>>>>> The console reports
>>>>> 
>>>>> 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
>>>>> 
>>>>> 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.
>>>> 
>>>> 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.)
>>>> 
>>>> There is a recent: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271677
>>>> 
>>>> It is not just your context with the issue.
>>>> 
>>>>> Resetting system ...
>>>>> 
>>>>> 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.
>>>> 
>>> 
>>> The system might produce more messages about the
>>> shutdown activity if it has been booted via:
>>> 
>>> boot -v
>>> 
>>> 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.
>> 
>> 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?
> 
> boot -v can add messages both to boot-time and to the
> later reboot/shutdown-time.
> 
> 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.
> 
> I've had to force poweroff after some of the messages.
> 
> 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.)
> 
> 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.)
> 
>> Maybe the ertt error is related, but the
>> association isn't consistent 
> 
> Are you saying that in recent times you have had hangups
> that did not first show the 'Khelp module "ertt" can't
> unload' message?
> 
> 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.)
> 
>> Unfortunately the hang does not seem easily reproducible.
> 
> Consistent with my "rare".
> 
>> Several consecutive shutdown -r reboots were successful.
> 
> To my knowledge/memory, I've never gotten the message after
> being booted for only a short time (little activity).
> 
>> The hangs seen so far have all followed OS build/install
>> sessions.
> 
> So a "boot -v" before such sessions might, eventually, prove
> useful.
> 



===
Mark Millard
marklmi at yahoo.com