upowerd and xen

[wch-tech at house-grp.net]

Hello all,

I hope this is the appropriate place to pose this question.

I am trying to get the battery plasmoid on the kde desktop to function when
running under the xen kernel.

It works well enough when running under the standard kernel.

Not knowing much about the process, I began trying to discover the communication
paths from the kernel and experimenting with various commands under each.

I discovered was that the command

    upower --monitor

would work under the standard kernel, but not xen.  (The output below results
from disconnecting the AC adaptor and then reconnecting it).

std output:

# upower --monitor
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[17:39:48.233]  daemon changed:
[17:39:48.234]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:48.234]  device changed:
    /org/freedesktop/UPower/devices/line_power_ADP1
[17:39:48.969]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:49.406]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:50.335]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:51.403]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:52.334]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:53.409]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:56.158]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:57.595]  daemon changed:
[17:39:57.595]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:39:57.595]  device changed:
    /org/freedesktop/UPower/devices/line_power_ADP1
[17:39:59.423]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:40:00.334]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:40:01.422]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:40:02.334]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[17:40:03.426]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
^C

xen output (with the same action regarding the AC adaptor):

# upower --monitor
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
^C

Another command with a difference is this query:

Standard kernel:

# dbus-send --print-reply \
             --system \
             --dest=org.freedesktop.UPower \
             /org/freedesktop/UPower \
             org.freedesktop.UPower.EnumerateDevices

method return sender=:1.16 -> dest=:1.44 reply_serial=2
   array [
      object path "/org/freedesktop/UPower/devices/line_power_ADP1"
      object path "/org/freedesktop/UPower/devices/battery_BAT0"
   ]


xen kernel:

# dbus-send --print-reply \
>              --system \
>              --dest=org.freedesktop.UPower \
>              /org/freedesktop/UPower \
>              org.freedesktop.UPower.EnumerateDevices
method return sender=:1.14 -> dest=:1.33 reply_serial=2
   array [
   ]

This command produces identical results in both kernels:

# upower -w
Total wakeups per minute: 0

What would cause the dbus query of  the xen kernel to not supply the necessary
power information?

I theorize that some necessary module is not compiled into the xen kernel, but
if so, I don't know what it is.

I have read that power monitoring in the xen kernel has been disabled, but other
reading tells me that it is now functioning, but version numbers are often
absent in these discussions.

I am running openSuSE 12.3 64 bit on a laptop, hp envy dv7 (intel i7-3630QM) w/
8GB ram.

The standard and xen kernel versions are 3.7.10-1.16.1

The xen hypervisor version is 4.2.2_06-1.16.1

I will continue studying, I guess next step is comparing the compilation
settings in the two kernels to see if I spot differences I think would have in
impact on this issue but if any of you guys can give me some direction, I would
appreciate it.

TKA

Bill









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20131222/ed9f55c3/attachment.html>