Hmmm, that comes form the sysmon stuff (sysmon_envsys_events.c).
It would appear that we've queued up some events for the coretemp sensor, but those events have not been"worked". Events are queued in sme_events_check() and dequeued by the sme_events_worker() thread.
Have you established alarm levels for the coretemp0 sensor? (You can show the levels using envstat(8) utility.)
I have coretemp[0-3] sensors on my system, and I've never seen any similar problem during shutdown.
A backtrace would definitely be useful. It would also be useful to determine if the sme_events_worker() thread is still running.
On Tue, 23 Jun 2015, John D. Baker wrote:
Last night upon updating my file server from 7.0_BETA to 7.0_RC1 (amd64), the message in the Subject: line appeared during the shutdown/reboot sequence and the machine was stuck there. I dropped to DDB and issued the "reboot" command. While the filesystem on the raidframe RAID (RAID-R) was unmounted, the RAID itself had not yet been detached/un-configured. The forcible shutdown required a parity rebuild upon reboot. Has anyone experienced a similar hang on shutdown/reboot? I didn't bother recording the backtrace in DDB as I just wanted my file server back up and running... -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
------------------------------------------------------------------------- | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -------------------------------------------------------------------------
