1 person found this helpful
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
Thanks thorsten for your reply, but in my case solaris is running on the physical box.
If we filter this at the syslog level, it will filter all kern.notice messages right? This is our production box
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.