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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to