abort with wireless HID devices: A handler is already registered for <battery>

Stacktrace:
 #0 <unavailable> in ?? ()
 PC not available
StacktraceSource: #0 <unavailable> in ?? ()
StacktraceTop: <unavailable> in ?? ()
ThreadStacktrace:
 PC not available
 warning: wrong size gregset struct in core file
 Quitting: PC register is not available

Hi Till,

this here is a problem.

apport-retracing was not able to create a stacktrace(usefull one because of ?? are still there) and there is also not a reproducing procedure.

Both are mostly necessary.

Can I ask you to provide a manually created stacktrace?

This may help

https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages

but there is also other stuff arround in the wiki(give it a google/bing/yahoo/whatever).

Also a reproducing procedure would be create.

In meantime I set the status of the report to incomplete.

Please set it back after providing the needed informations.

Thank you.

Unfortunately, I cannot reproduce this bug. Here and there a pop-up comes up, mostly right after login, telling that upowerd has crashed. Most of the times I have simply clicked "Cancel" and now I have sent out the crash report.

By the way, the hardware is the Pandaboard ES.

In this case please install the needed dbg packages (see stacktrace attached on this report)manually and wait until the crash occures again.

Following this:

https://wiki.ubuntu.com/DebuggingProgramCrash

you can examine locally and look if the stacktrace is good enough.

If it is please file a new report and close this here as dublicate.

Hi melchiaros,

This is likely the same crash as in https://bugs.launchpad.net/ubuntu/+source/upower/+bug/929755/comments/2 . As far as I can tell, this happens because upower expects some battery to be there that isn't there. In bug 929755, it's a wiimote, in other cases, it's a bluetooth mouse.

I can reproduce it pretty frequently, let me know if you need more info. One thing I can't figure out is why it raises signal 5 (SIGTRAP). I thought that was only for gdb?

Okay, I've figured out the sigtrap confusion. Apparently, it's what the Gnome devs think is a good signal to tie in to g_error() if you have debugging turned on (we compile glib with debugging turned on?).

I've also managed to find the code that's erroring. Take a look at lines 1706-1711:

http://maemo.org/api_refs/4.0/dbus-glib/dbus-gobject_8c-source.html

http://comments.gmane.org/gmane.comp.gnome.apps.gnucash.user/23290

Hi James,

I have to say sorry.

I do only on bug triaging and not coding(have not done for several years -> you loose what you do not train). So, you do not have to orientate to me.

When you want to work on fixing this, please fell absolutely free.

greetings

melchiaros

Heh, no apology necessary :) I was just trying to get the information that you were looking for.

Now that we do have enough information to reproduce and get core dumps etc, whom do we triage _to_?

Unfortunately I am not a member of Ubuntu Bug Control and with this I have no access to

https://bugs.launchpad.net/bugs/929755

which is still private.

There should be a full stacktrace following the dublicate entries you have brought here.

Can you copie it here?(Or set the report to public?

I have looked through the dublicats and added tags that fits for them.

The crash is not limited to pandaboard.

Insted it occures on different architectures.

I adapt the summary for this.

The first occurence I can see is on precise which has upower 0.9.15

The crasher also occures on quantal with upower 0.9.17

and is still there in raring with upower 0.9.19.

@jm-leddy

o.K,

I have looked a little bit arround.

Looking at:

https://bugs.launchpad.net/ubuntu/+source/upower/+bugs?orderby=-heat&start=0

upower bugs seems to get not so much attention(to say it nice).There lay 60 open reports arround. Even when you use advance search you see that there where at whole life of launchpad only 94 reports and a closing rate (of whatever reason) of 34 is indeed low.

With the dublicates linked here the flame rate has increased to 266, which is the fourth highest one recently there, so there is a chance that this here will get attention.

Anyway, I think that involving the original developers of upower makes sense here, because the crash occures in different versions of upower and on different architectures(see the comments above). So there could be interest by them to handle this problem.

This brings the next problem with it.

There bugtracker at

https://bugs.freedesktop.org/

seems to be used only sporadic.

Following

http://upower.freedesktop.org/

they prefer contacted by mailing list

http://lists.freedesktop.org/mailman/listinfo/devkit-devel

James, because you have a plan what is going on here, could you contact them on the mailing list as they wish it?

When they do not react there I could open a ticket on their bugtracker.

also on
12.10 ubuntu 32-bit
Lenovo V570
hp X4000b mouse

I would like to get this fixed. I've packaged upower 0.9.19 for quantal in my PPA (https://launchpad.net/~plaxx/+archive/random-fixes) and installed it on my system. If it doesn't resolve it (i'll know in a couple of days), I intend to engage with upstream to try to find out exactly what is going on.

Thinkpad T420s w/ battery bay and am using bluetooth keyboard / mouse. Sleeping and swapping screens and inputs twice a day.

Bluetooth keyboard and mouse here too. I need to re-sync the mouse and then re-issue

xinput --set-prop "vila’s mouse" "Device Accel Adaptive Deceleration" 4.0
xinput --set-prop "vila’s mouse" "Device Accel Velocity Scaling" 1.0

each time it occurs (I've put the above in .xprofile but having to do '. ./.xprofile' each time is becoming less fun lately ;)

According to my syslog, upowerd crash always follows a power_supply error, so I thought there must be some connection:

Mar 10 02:59:45 dev kernel: [ 160.051819] power_supply hid-00:12:a1:68:a3:1b-battery: driver failed to report `capacity' property: -5
Mar 10 02:59:45 dev kernel: [ 160.137237] do_trap: 66 callbacks suppressed
Mar 10 02:59:45 dev kernel: [ 160.137248] traps: upowerd[1502] trap int3 ip:7f2c0c1b92b5 sp:7fff26f6c440 error:0

If you look into linux-*/drivers/power/power_supply_sysfs.c, you can easily find the suspect:

        ssize_t ret = 0;
        ...

        if (off == POWER_SUPPLY_PROP_TYPE)
                value.intval = psy->type;
        else
                ret = psy->get_property(psy, off, &value);

        if (ret < 0) {
                if (ret == -ENODATA)
                        dev_dbg(dev, "driver has no data for `%s' property\n",
                                attr->attr.name);
                else if (ret != -ENODEV)
                        dev_err(dev, "driver failed to report `%s' property: %zd\n",
                                attr->attr.name, ret);
                return ret;
        }

Here, "ret" is assigned only once, which means psy->get_property() returns -EIO (-5).

psy->get_property() is actually calls hidinput_get_battery_property() from linux-*/drivers/hid/hid-input.c:

battery->get_property = hidinput_get_battery_property;

And the only place in hidinput_get_battery_property where we can get -EIO is:

          case POWER_SUPPLY_PROP_CAPACITY:
                ret = dev->hid_get_raw_report(dev, dev->battery_report_id,
                                              buf, sizeof(buf),
                                              dev->battery_report_type);
                ...
                break;

... and my knowledge isn't enough to dig a little deeper ;)

So, as a temporary solution I've recompiled kernel with commented out CONFIG_HID_BATTERY_STRENGTH and it works perfectly.

The kernel recompile worked for me. Any chance this'll be patched in as an option for 13.10. I read somewhere (can't remember where) that the capacity warning was being worked on but bringing in a patched kernel is a good temporary fix.

@vvekecki: where is the fix? I can't find it in the upower (ubuntu) code branches..

I'm open to repackage it in my PPA and test if needed.

if it was fixed ... well, sorry but seems that it come back in 13.10... or maybe its another one.

Crash when returning from a lock screen after an inactivity period.

The error message makes this quite clear:

  "A handler is already registered for /org/freedesktop/UPower/devices/battery_hid_00o12oa1o68oa3o1b_battery"

So this seems to happen if you have a wireless mouse or keyboard, which powers down due to inactivity, and then gets repowered and it tries to register the same battery again.

I'm afraid I still don't understand what happens there; it's not just a simple removal and re-adding of these devices when they power down (I just tried that in the test suite, and it works fine). For anyone who can reproduce this, can you please open a terminal, and start

  udevadm monitor -e --udev | tee /tmp/monitor.txt

then wait a bit, or do whatever is necessary to trigger that crash, then go back to the terminal with the udevadm command, press Control-C to stop it, and attach /tmp/monitor.txt here? Thanks!

Martin,

Please find attached monitor.txt as you requested. Here is how I can reproduce
the crash:

- Enable my hp bluetooth mouse, and use it normally with the computer.
- Go away and come back some time later after the mouse has gone to sleep.
- As soon as I try use the mouse (i.e. it wakes up), the crash occurs.

Regards,

Tony.

On September 6, 2013 at 9:12 AM Martin Pitt <email address hidden> wrote:
> I'm afraid I still don't understand what happens there; it's not just a
> simple removal and re-adding of these devices when they power down (I
> just tried that in the test suite, and it works fine). For anyone who
> can reproduce this, can you please open a terminal, and start
>
> udevadm monitor -e --udev | tee /tmp/monitor.txt
>
> then wait a bit, or do whatever is necessary to trigger that crash, then
> go back to the terminal with the udevadm command, press Control-C to
> stop it, and attach /tmp/monitor.txt here? Thanks!
>
> ** Changed in: upower (Ubuntu)
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1112907
>
> Title:
> abort with wireless HID devices: A handler is already registered for
> <battery>
>
> Status in Upower:
> Unknown
> Status in “upower” package in Ubuntu:
> Incomplete
>
> Bug description:
> .
>
> ProblemType: Crash
> DistroRelease: Ubuntu 13.04
> Package: upower 0.9.19-1ubuntu4
> ProcVersionSignature: Ubuntu 3.5.0-216.23-omap4 3.5.7.1
> Uname: Linux 3.5.0-216-omap4 armv7l
> ApportVersion: 2.8-0ubuntu3
> Architecture: armhf
> Date: Fri Feb 1 22:25:19 2013
> ExecutablePath: /usr/lib/upower/upowerd
> InstallationDate: Installed on 2013-01-17 (15 days ago)
> InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha armhf+omap4
> (20130116)
> MarkForUpload: True
> ProcCmdline: /usr/lib/upower/upowerd
> ProcEnviron:
>
> Signal: 5
> SourcePackage: upower
> StacktraceTop:
> dbus_g_connection_register_g_object () from
> /usr/lib/arm-linux-gnueabihf/libdbus-glib-1.so.2
> ?? ()
> ?? ()
> Title: upowerd crashed with signal 5 in dbus_g_connection_register_g_object()
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/upower/+bug/1112907/+subscriptions
"

Monitor.txt is attached.

Steps taken:
1) Connect BT mouse (not used, as this bug also seems to prevent mouse from working - mouse works fine in 12.04).
2) Power down mouse
3) Power mouse back up

Dialog notifying upowerd crash is seen.

Thanks for the two monitor logs. They indeed seem to confirm my suspicion: The device bluetooth mouse battery gets add/change events several times, but it never gets a remove event. On top of that, the add events have different device paths, which causes the already existing "treat add event as change" check to not work.That's a kernel bug, but we need to make upower more robust against that.

Thanks to the logs I was able to complete my test case which now nicely reproduces this crash.

I made two patches which both address this problem.

The first one is a direct workaround for this particular bluetooth HID issue where the kernel creates new native sysfs devices for those after each nap. This would even still be relevant if the kernel gets fixed to actually do send out remove events properly, as we don't really want upower to signal device removals/additions all the time.

Pro: unintrusive as it does not change behaviour for all other kinds of devices, suitable for a stable release update
Con: rather hackish, and does not guard against similar problems with other device types

This second version is a bolder step, but I think it's the right thing to do. It's a little more risky than the first one, but I (and the test suite) are fairly convinced that it's correct.

Pro: addresses this kind of problem for all device types under Linux, and avoids D-BUS signalling device removals/additions from upower where the device itself did not really go away, just the parental USB/bluetooth tree structure changed
Con: More intrusive, could theoretically cause regressions (but I have no idea how, as upower already only uses the device name for building object names)

Both patches have detailled commit messages which explain their rationale.

@Richard: I recommend the second patch, but I posted both to get you a chance to compare.

Reviewed by Richard on IRC, I pushed the second patch upstream.

This bug was fixed in the package upower - 0.9.21-3ubuntu2

---------------
upower (0.9.21-3ubuntu2) saucy; urgency=low

  * Update 00git_updates.patch to today's upstream git:
    - Track power_supply devices by name only instead of full sysfs path.
      Fixes crashes with devices whose USB/bluetooth parental structure
      changes after auto-suspend or similar actions. (LP: #1112907)
    - Don't call obsolete g_type_init() when building with a recent glib.
 -- Martin Pitt <email address hidden> Fri, 27 Sep 2013 09:57:15 +0200