From nobody Mon Oct 02 02:25:44 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 4RzPvH102Dz4w7Xx for ; Mon, 2 Oct 2023 02:25:47 +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 4RzPvG23drz3GMR for ; Mon, 2 Oct 2023 02:25:45 +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 3922Pj8Z070426 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 1 Oct 2023 19:25:45 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3922PiUd070425; Sun, 1 Oct 2023 19:25:44 -0700 (PDT) (envelope-from fbsd) Date: Sun, 1 Oct 2023 19:25:44 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Shutdown -r under -current hangs on RPi3 Message-ID: References: <88F77A9A-F3BB-4FEA-8330-EC5992D7B36B@yahoo.com> <7B1D2B1C-C580-448B-BEB9-51D07417C62D@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: <7B1D2B1C-C580-448B-BEB9-51D07417C62D@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: 4RzPvG23drz3GMR On Sun, Oct 01, 2023 at 10:09:59AM -0700, Mark Millard wrote: > On Oct 1, 2023, at 09:25, bob prohaska wrote: > > > On Sun, Sep 24, 2023 at 08:17:54AM -0700, bob prohaska wrote: > >> > >> It appears that setting > >> debug.bootverbose=1 > >> suppresses the otherwise-persistent > >> Khelp module "ertt" can't unload until its refcount drops from 1 to 0. > >> message during shutdown. No new output either, apart from the swap > >> removal notice. > >> > >> So far, the few shutdown -r experiments tried have not gotten stuck, > >> even after an OS build/install cycle. > > > > Another shutdown hang has been observed with -current on a Pi3. > > This time bootverbose was on, as was ucom debug. This machine > > has an FTDI usb-serial adaper. > > > > The serial console reported: > > > > *** FINAL System shutdown message from bob@pelorus.zefox.org *** > > > > System going down IMMEDIATELY > > > > > > Oct 1 08:21:26 pelorus shutdown[78571]: 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 > > ucom_inwakeup: tp=0xffffa00021cc1c00 > > ucom_ioctl: cmd = 0x2000740e > > ucom_inwakeup: tp=0xffffa00021cc1c00 > > ucom_inwakeup: tp=0xffffa00021cc1c00 > > ucom_close: tp=0xffffa00021cc1c00 > > ucom_shutdown: > > ucom_dtr: onoff = 0 > > ucom_line_state: on=0x00, off=0x01 > > ucom_rts: onoff = 1 > > ucom_line_state: on=0x02, off=0x00 > > Oct 1 08:21:32 pelorus ucom_cfg_close: > > 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... 0 0 0 done > > All buffers synced. > > Swap device da0s2b removed. > > Uptime: 3d0h14m47s > > Resetting system ... > > > > Both Ethernet LEDs turned off, if that's significant. > > After about half an hour, I pulled the plug. The machine > > came up hands-off. > > > > Was this a debug world/kernel? non-debug? May be > output I was expecting only is generated by the > debug variants? > The kernel was GENERIC, no private modifications > Was there any lights sometimes on anywhere during that > about half hour? Wasn't watching. On a repeat performance all of the on-board LEDs remain off, while the disk light seems stuck on. On a successful boot the disk light comes on at power on, goes off until the disk is probed and then remains on while running. If the probe fails, the disk LED turns off, apparently signifying some sort of sleep or power-save state. > Might it have powered off instead of > rebooting? > No reason to think so. This machine and all its companions are on a UPS. > Is there anything about the above message sequence > (before "Resetting system ...") that is different > from when the reboot works, also with "bootverbose was > on, as was ucom debug"? > Not that I can recognize. Setting debug for ucom on Pi3 (current) generates quite a lot of extra console output, but none of it looks like an error message. I tried to turn on debugging for ucom on the Pi2 running stable/14, but the effort failed: root@generic:~ # sysctl hw.usb.ucom.debug=1 sysctl: unknown oid 'hw.usb.ucom.debug' Apparently the feature isn't enabled on stable/14. Odd, because it's in the man page. > It is an example with no "ertt" message. Yes, and in retrospect I'm slightly surprised. Apparently I set bootverbose interactively. Now it's set in /etc/sysctl.conf. Thanks for writing! bob prohaska