From nobody Sat Sep 23 19:16:14 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RtJlP33Rbz4v6gf for ; Sat, 23 Sep 2023 19:16:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RtJlN6s8tz3C8N for ; Sat, 23 Sep 2023 19:16:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 38NJGF6s035614 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Sep 2023 12:16:15 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 38NJGFqt035613; Sat, 23 Sep 2023 12:16:15 -0700 (PDT) (envelope-from fbsd) Date: Sat, 23 Sep 2023 12:16:14 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Shutdown -r under -current hangs on RPi3 Message-ID: References: <0AADDACB-ABA3-47FF-B3A7-05B313F5326C@yahoo.com> <9D29DD48-1572-4C04-AD88-8436AC8DDDCC@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D29DD48-1572-4C04-AD88-8436AC8DDDCC@yahoo.com> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4RtJlN6s8tz3C8N On Sat, Sep 23, 2023 at 11:34:41AM -0700, Mark Millard wrote: > On Sep 23, 2023, at 11:26, Mark Millard wrote: > > > On Sep 23, 2023, at 08:52, bob prohaska 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? 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. Maybe the ertt error is related, but the association isn't consistent Unfortunately the hang does not seem easily reproducible. Several consecutive shutdown -r reboots were successful. The hangs seen so far have all followed OS build/install sessions. Thanks for writing! bob prohaska