On Thursday 23 May 2013 12:39 AM, Marco Pattaro wrote: > Hallo, > I did the test with DEBUG=1, sadly it did not logged the full > output to syslog (attached laptop-mode part), much more is printed on > stderr. I did log a shutdown/boot, then I did some tests which I > report here (lot of text follows). Hmmm!! Yes. You are right. The debug messages are only redirected to the active console.
It does show in the logs that it set the scaling governor to ondemand. + set_sysctl /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor ondemand + log VERBOSE Executing: echo ondemand > /sys/devices/system/cpu/cpu3/cpufreq/scalin g_governor + [ x1 = x1 ] + [ -x /usr/bin/logger -a VERBOSE != STATUS ] + [ VERBOSE = MSG ] + [ VERBOSE = ERR ] + [ VERBOSE = VERBOSE ] + [ x1 = x1 ] + logger -p daemon.debug -t laptop-mode Executing: echo ondemand > /sys/devices/syst em/cpu/cpu3/cpufreq/scaling_governor Intel SATA link power saving set to max_performance for /sys/class/scsi_host/host3/l ink_power_management_policy. I am not sure if that log is from the system boot or during your manual restart of the service. The log messages with a timestamp will help you determine that. Apart from that, there are some items you could try: 1) Disable LMT. After boot is complete, try to manually start LMT. If ondemand is reflected, then something else is interfering. 2) On system boot, LMT will start as soon as the udev subsystem is activated. At that point, if syslog is not available, your logs will not be available in syslog. 3) If you are using systemd as your init, some parts of udev is service now by systemd. Though we have systemd support, there could be a miss of logs there. BTW, on my box, I see ondeamnd to be active. rrs@zan:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand Meanwhile, I will reboot my box and see if I can reproduce the problem. Thanks for spending the time to debug it.
signature.asc
Description: OpenPGP digital signature