Page 1 of 1
gkrellm and powering-off
Posted: Tue Jul 17, 2007 3:40 pm
by l.butler
Has anyone noticed something similar to the following? Any suggestions to fix it?
If I run gkrellm--monitoring temp.s, cpu, hdd, eth0--then when I power-off my t22, the power-off sequence proceeds up to the final step, but ibm-acpi does not actually turn off the machine. That final step must be done manually.
If gkrellm is not run, then power-off is completed as it should.
Posted: Fri Jul 20, 2007 2:58 pm
by louieb
For what its worth I'm running Ubuntu Feisty on a T30. I too use the gkrellm monitor and I have not had a problem with shutdown.
Posted: Sat Jul 21, 2007 6:19 am
by l.butler
What do you monitor with gkrellm?
Do you use the Gnome desktop with Ubuntu? I use KDE or fluxbox (the problem occurs in either case); I wonder if it is related in some way to the desktop/window manager.
I have been meaning to try Ubuntu. You response has persuaded me that I ought to try it.
Posted: Sat Jul 21, 2007 1:53 pm
by bradius
Hmmm, that seems kind of strange. I used to run it the same way on my 600e without any problem. That was Suse 9.3 with fluxbox.
I'm really not sure about it, but I know I can't hibernate if anything is using my Windows' NTFS partition. Did you try it with different combinations of things being monitored as it could be related to one of them?
Posted: Sat Jul 21, 2007 5:11 pm
by louieb
I use GNOME. GKrellm displays CPU, processes and users, temperatures for battery, cpu, hdd, and pci. disk and network usage, memory and swap usage, and have the plugin for led states (caps, num, scroll)
Posted: Sun Jul 29, 2007 5:47 am
by lightweight
Temp monitor may be calling ibm-acpi. Since GKrellM shuts down, I'd guess the problem is ibm-acpi. Any oddness in /var/log/messages?
Posted: Wed Aug 01, 2007 2:31 pm
by l.butler
No, I haven't been able to find anything in /var/log/messages.
Originally, I thought that the problem might be related to either the temperature monitor (as you suggested), or the fact that gkrellm is designed for use with the Gnome desktop not KDE.
However, by stripping out all but the temp.s for gkrellm to monitor, I can now power-off successfully after running gkrellm for the whole session.
Posted: Sat Aug 04, 2007 11:23 pm
by lightweight
However, by stripping out all but the temp.s for gkrellm to monitor, I can now power-off successfully after running gkrellm for the whole session.
Which monitor stops powering off from completing?
Posted: Fri Aug 10, 2007 2:18 am
by l.butler
I stopped all monitoring activities by gkrellm and then incrementally added new ones, beginning with temperatures, then cpu, procs, hda, eth0/ath0. With each addition, acpi_power_off was successfully called to power off the machine at shutdown. Then, I added "battery" to the list of things gkrellm monitors, and the old problem has reappeared. Since I am running the KDE desktop with its KLaptop utility that also monitors the battery's state, I suspect that the problem lies here.
This probably means that the problem is academic, since one probably does not need to use both gkrellm and klaptop to monitor the battery's state. Still, it is odd that there should be any conflict here.
Any edifying comments?
Posted: Sat Aug 11, 2007 6:20 pm
by lightweight
KLaptop and GKrellM should both read /proc/acpi/battery (and /proc/acpi/ac_adapter when plugged in). ACPI and X all shut down cleanly when only running KLaptop or GKrellM?
I suggest looking for events whenever GKrellM polls battery state. You can do this by opening three terminals and executing one of the following in each:
Post output -- you're looking for events calling ACPI. Perhaps isolate if this is a problem when GKrellM is monitoring battery when plugged in or running on battery to see which ACPI status is borking it.
Posted: Sun Aug 12, 2007 6:12 am
by l.butler
Dumb question, lightweight: how do I turn on the log for the acpid daemon? Also, the daemon running is kacpid, but I don't suppose this changes things.
LB
Posted: Mon Aug 27, 2007 3:51 am
by lightweight
Hey, sorry for forgetting this. Not a dumb question. acpi should log to /var/log/acpid by default, but per the man page you can change the log location with the -l flag. Debian by default doesn't give regular users root's group and so /var/log/acpid is not readable, by the way. If you get a permission denied try invoking root.
If you have no log, I would first see how the command is invoked, kill it, then add the -l flag to some file to test. For example, on my Debian box:
Code: Select all
io@lightweight: ~ $ ps aux | grep acpi
root 25 0.0 0.0 0 0 ? S< Aug26 0:00 [kacpid]
root 3219 0.0 0.3 2080 968 ? Ss Aug26 0:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket
io 3221 0.0 0.2 1752 520 pts/0 R+ 01:51 0:00 grep acpi
io@lightweight: ~ $ sudo kill 3219
io@lightweight: ~ $ ps aux | grep acpi
root 25 0.0 0.0 0 0 ? S< Aug26 0:00 [kacpid]
io 3229 0.0 0.2 1752 520 pts/0 R+ 01:51 0:00 grep acpi
io@lightweight: ~ $ sudo /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket -l /var/log/acpi_now
io@lightweight: ~ $ ll !$
ll /var/log/acpi_now
-rw-r----- 1 root root 637 Aug 27 01:51 /var/log/acpi_now
io@lightweight: ~ $ sudo tail -f !$
sudo tail -f /var/log/acpi_now
[Mon Aug 27 01:52:02 2007] starting up
[Mon Aug 27 01:52:02 2007] 55 rules loaded
[Mon Aug 27 01:52:03 2007] client connected from 2915[0:0]
[Mon Aug 27 01:52:03 2007] 1 client rule loaded
I do not see anything in /etc/acpi that controls logging.
Posted: Mon Aug 27, 2007 12:27 pm
by l.butler
There does not appear to be any connection between the power-off problem and the plugged-in status of the machine: monitoring the battery in both cases results in failure to complete the power off.
I installed the acpi daemon and logged the following output.
Code: Select all
lbutler@t22:/media/hda5/lbutler$ gkrellm -d 0x80
--- GKrellM 2.2.10 ---
hddtemp_daemon_read: can't connect to 127.0.0.1:7634.
libsensors support is not compiled in.
load_sensors_config: <sensor_config_version> <1>
load_sensors_config: <sensor_sysdep_private> <0>
load_sensors_config: <sensor_float_factor> <10000>
load_sensors_config: <gkrellm_float_factor> <1000>
load_sensors_config: <"BAT1"> <"IBM ACPI Battery 1" 10000 0 1 0>
load_sensors_config: <"BAT2"> <"IBM ACPI Battery 2" 10000 0 1 0>
load_sensors_config: <"CPU"> <"IBM ACPI CPU" 10000 0 1 0>
load_sensors_config: <"GPU"> <"IBM ACPI GPU" 10000 0 0 0>
load_sensors_config: <"HDD"> <"IBM ACPI HDD" 10000 0 0 0>
load_sensors_config: <"PCI"> <"IBM ACPI Mini PCI Module" 10000 0 0 0>
load_sensors_config: <"THM0"> <"thermal_zone/THM0" 10000 0 1 0>
load_sensors_config: <units_fahrenheit> <0>
load_sensors_config: <volt_display_mode> <0>
sensor_temp: BAT1 /proc/acpi/ibm/thermal t=45.00
sensor_temp: BAT2 /proc/acpi/ibm/thermal t=23.00
sensor_temp: CPU /proc/acpi/ibm/thermal t=48.00
sensor_temp: THM0 /proc/acpi/thermal_zone/THM0/temperature t=48.00
root@t22:~# cat /var/log/acpid_1.log
[Mon Aug 27 17:53:20 2007] starting up
[Mon Aug 27 17:53:20 2007] 1 rule loaded
[Mon Aug 27 18:00:49 2007] exiting
[Mon Aug 27 18:02:33 2007] starting up
[Mon Aug 27 18:02:33 2007] 1 rule loaded
[Mon Aug 27 18:04:03 2007] received event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:03 2007] completed event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:12 2007] received event "battery BAT0 00000080 00000001"
[Mon Aug 27 18:04:12 2007] completed event "battery BAT0 00000080 00000001"
root@t22:~# cat /var/log/messages | grep -i acpi | grep 'Aug 2[67]'
(extracts...)
Aug 27 18:02:33 t22 kernel: ACPI wakeup devices:
Aug 27 18:02:33 t22 kernel: ACPI: (supports S0 S1 S3 S4 S5)
Aug 27 18:02:33 t22 kernel: ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
Aug 27 18:02:33 t22 kernel: ACPI: Processor [CPU] (supports 8 throttling states)
Aug 27 18:02:33 t22 kernel: ACPI: Thermal Zone [THM0] (47 C)
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:03.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Aug 27 18:02:33 t22 kernel: ACPI: AC Adapter [AC] (on-line)
Aug 27 18:02:33 t22 kernel: ACPI: Battery Slot [BAT0] (battery present)
Aug 27 18:02:33 t22 kernel: ACPI: Power Button (FF) [PWRF]
Aug 27 18:02:33 t22 kernel: ACPI: Lid Switch [LID]
Aug 27 18:02:33 t22 kernel: ACPI: Sleep Button (CM) [SLPB]
Aug 27 18:02:33 t22 kernel: ibm_acpi: IBM ThinkPad ACPI Extras v0.12a
Aug 27 18:02:33 t22 kernel: ibm_acpi: http://ibm-acpi.sf.net/
Aug 27 18:02:33 t22 kernel: ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
Aug 27 18:02:33 t22 kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Posted: Wed Aug 29, 2007 11:58 pm
by lightweight
I do not see oddness, so I am still no help. Can you grep out the logs to data before shutdown attempt? (Can redirect gkrellm's 2&1 to a file.) In rereading the description I am hoping to see something call or fail on some wakeup for X.
Posted: Wed Sep 05, 2007 6:23 pm
by mdtaylor69
louieb wrote:I use GNOME. GKrellm displays CPU, processes and users, temperatures for battery, cpu, hdd, and pci. disk and network usage, memory and swap usage, and have the plugin for led states (caps, num, scroll)
So question for Lou is how to get the transparent charts? That is pretty slick.
Pic inside
Posted: Wed Sep 05, 2007 7:03 pm
by Harryc
You can make the whole thing transparent if you want to, just install the 'invisible' theme in /home/youruser/.gkrellm2/themes
http://www.muhri.net/gkrellm/invisible.tar.gz
Restart gkrellm, then switch to the invisible theme in gkrellm config/themes.