This kind of message is typically seen when Solaris is running inside a virtual machine (like VirtualBox or VMware guest).
In order to prevent that message filling up your /var/adm/messages or slowing down the console, I suggest to not capture kern.notice messages via syslog.
You can change /etc/syslog.conf like:--- syslog.conf.orig+++ syslog.conf@@ -9,8 +9,8 @@# that match m4 reserved words. Also, within ifdef's, arguments# containing commas must be quoted.#-*.err;kern.notice;auth.notice /dev/sysmsg-*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages+*.err;kern.warning;auth.notice /dev/sysmsg+*.err;kern.debug;daemon.warning;mail.crit /var/adm/messages*.alert;kern.err;daemon.err operator*.alert rootand then restart syslog:svcadm restart svc:/system/system-log:defaultRegardsThorsten
Ok, if those are production systems, I would recommend to open a case with Oracle support.
Yes, if you change syslog.conf as suggested, it will no longer report any kernel.notice/daemon.notice messages.
In case this is an x86 system with Intel Xeon processors (Nehalem/Westmere CPU's which have ACPI Power Management feature), this feature allows the operating system to place the processor in low power state (deep C-state) when not in use. This can appear as very long latency on I/O and appear as a hung system.
There can be two options to disable entering the deep C-state:
1) disable it within the BIOS
- or -
set idle_cpu_prefer_mwait=0 set idle_cpu_no_deep_c=1
b) If Solaris 10 x86 with kernel patch 144489-16 or higher then set one value in /etc/system
And if Solaris 10 x86 with kernel patch 147441-06 or higher is used, then the issue is fixed.
But this is really just a shot in the blue, hence my suggestion to open a case. And certainly test that before applying in production.