Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 11/07/12 00:12, Jonathan Nieder wrote: Eugen Dedu wrote: No problem for me, I am glad that it works on 3.4! So if you prefer, you can close this bug. I'd rather get it fixed in 3.2.y since we will be maintaining that for a while. Would you be interested in pursuing that (by testing it and contacting upstream and cc-ing us when it next happens)? If not, that's fine and we probably should close it. I would like to, but I really think it will take me too much time, sorry! -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 10/07/12 05:33, Jonathan Nieder wrote: Eugen Dedu wrote: First, note that I have indeed a problem with the battery, since the icon of gnome is not working properly: it shows an empty battery, whice it is fully loaded, or viceversa. Is this more reproducible than the resume failures? This is 100% reproducible. For ex., right now I have 2 horizontal lines instead of 3, and my battery is 87% charged. Moreover, it is charging, but the icon does not show the fire (meaning it is charging). -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 10/07/12 05:31, Jonathan Nieder wrote: Eugen Dedu wrote: Making a git bissect inside these versions will take me ages, especially that the freeze is not easily reproducible and it is difficult during a test to be sure that the freeze does NOT appear. Fair enough. When's the last time it happened? Is the error always kobject_add_internal failed for BAT0 with -EEXIST? It appeared last time two weeks ago, when I was still using 3.3. Since then I have been using 3.4, and no problem so far. There were two errors: - kobject_add_internal failed for BAT0 with -EEXIST and no other message - the error with the recursivity, the acpi function and so on (the image I posted). But probably they are related, since BAT0 (battery 0) is surely to acpi. I tried searching the web for that message but you seem to be the only one getting it in this circumstance. :) Alas. If you can still reproduce it occasionally with some kernel, please report the symptoms to linux-a...@vger.kernel.org, cc-ing either me or this bug log so we can track it. Be sure to mention: - precise steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough) - how reproducible it is - which kernels you have tested and what happened with each - full dmesg output from booting an affected kernel, as an attachment or link - acpidump output, as an attachment or link - any other weird symptoms or workarounds Hopefully someone there can suggest a way to figure out what is happening, for example by applying some patch or enabling some debugging feature to be ready for when it happens next. Thanks again for a clear report, and sorry I have no better advice. No problem for me, I am glad that it works on 3.4! So if you prefer, you can close this bug. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: No problem for me, I am glad that it works on 3.4! So if you prefer, you can close this bug. I'd rather get it fixed in 3.2.y since we will be maintaining that for a while. Would you be interested in pursuing that (by testing it and contacting upstream and cc-ing us when it next happens)? If not, that's fine and we probably should close it. Thanks again. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
clone 677016 -1 retitle -1 Dell Latitude E6500: battery charging state is inaccurate # cosmetic severity -1 minor quit Eugen Dedu wrote: This is 100% reproducible. For ex., right now I have 2 horizontal lines instead of 3, and my battery is 87% charged. Moreover, it is charging, but the icon does not show the fire (meaning it is charging). Ok, cloning since this part seems to still affect 3.4.y. If you get a chance to contact upstream about it, I'd be interested. Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 07/07/12 07:54, Jonathan Nieder wrote: Eugen Dedu wrote: On 07/07/12 04:49, Jonathan Nieder wrote: Does that mean 2.6.38 works fine? (If you'd like to test this, historical precompiled kernels are available from http://snapshot.debian.org/, source package linux-2.6.) I think that it worked fine. Do you want me to test it? I guess there's no need. Unfortunately that range is very wide --- would you be interested in bisecting to find which particular change introduced the bug or fixed it? (If so I'd be happy to provide instructions to guide you through the process.) I upgrade my system often, so I used each of the kernels (.37, .38 etc.) The first kernel which introduced the freeze was either 3.0 or 2.6.39. Making a git bissect inside these versions will take me ages, especially that the freeze is not easily reproducible and it is difficult during a test to be sure that the freeze does NOT appear. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: Making a git bissect inside these versions will take me ages, especially that the freeze is not easily reproducible and it is difficult during a test to be sure that the freeze does NOT appear. Fair enough. When's the last time it happened? Is the error always kobject_add_internal failed for BAT0 with -EEXIST? I tried searching the web for that message but you seem to be the only one getting it in this circumstance. :) Alas. If you can still reproduce it occasionally with some kernel, please report the symptoms to linux-a...@vger.kernel.org, cc-ing either me or this bug log so we can track it. Be sure to mention: - precise steps to reproduce, expected result, actual result, and how the difference indicates a bug (should be simple enough) - how reproducible it is - which kernels you have tested and what happened with each - full dmesg output from booting an affected kernel, as an attachment or link - acpidump output, as an attachment or link - any other weird symptoms or workarounds Hopefully someone there can suggest a way to figure out what is happening, for example by applying some patch or enabling some debugging feature to be ready for when it happens next. Thanks again for a clear report, and sorry I have no better advice. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: First, note that I have indeed a problem with the battery, since the icon of gnome is not working properly: it shows an empty battery, whice it is fully loaded, or viceversa. Is this more reproducible than the resume failures? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 22/06/12 19:27, Eugen Dedu wrote: On 22/06/12 19:10, Jonathan Nieder wrote: Eugen Dedu wrote: On 22/06/12 18:29, Jonathan Nieder wrote: But I suspect this is an ACPI support bug elsewhere (effect of lid switch). Can you easily reproduce it by opening and closing the lid a bunch of times? Well, closing and reopening for about 20 times does not trigger the bug. Drat. It's probably a genuine suspend bug, then. :) The trigger could be something like how much memory is free. If you can find a reliable recipe, that would be great, but otherwise we should just get in contact with upstream (assuming it's not already fixed there). Does 3.4.y from experimental reproduce it? I reboot with 3.4 right now and contact you as soon as I have the freeze. 13 days and still no crash! With the other kernels I remember having had once two weeks of non-freeze. I will come back in a fews days to confirm that 3.4 fixes my crashes. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Hi, Eugen Dedu wrote: In fact, I have been having freezes at suspend since 3.0 or 2.6.39, while before suspend was working perfectly. Does that mean 2.6.38 works fine? (If you'd like to test this, historical precompiled kernels are available from http://snapshot.debian.org/, source package linux-2.6.) Thanks again for your help so far tracking this down. Sincerely, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 07/07/12 04:49, Jonathan Nieder wrote: Hi, Eugen Dedu wrote: In fact, I have been having freezes at suspend since 3.0 or 2.6.39, while before suspend was working perfectly. Does that mean 2.6.38 works fine? (If you'd like to test this, historical precompiled kernels are available from http://snapshot.debian.org/, source package linux-2.6.) I think that it worked fine. Do you want me to test it? -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: On 07/07/12 04:49, Jonathan Nieder wrote: Does that mean 2.6.38 works fine? (If you'd like to test this, historical precompiled kernels are available from http://snapshot.debian.org/, source package linux-2.6.) I think that it worked fine. Do you want me to test it? I guess there's no need. Unfortunately that range is very wide --- would you be interested in bisecting to find which particular change introduced the bug or fixed it? (If so I'd be happy to provide instructions to guide you through the process.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 12/06/12 06:02, Jonathan Nieder wrote: Eugen Dedu wrote: Here it is: another freeze during resume, with kernel 3.3 too. Thanks for the quick feedback. (As a reminder to myself, the message is BUG: unable to handle kernel paging request at fff(lens flare) IP: [810514c7] kthread_data+0x7/0xc PGD 1607067 PUD 1608067 PMD 0 Oops: [#2] SMP CPU 0 [...] Code: 3f 48 c1 e5 03 48 c1 e0 06 48 8d b0 50 54 40 81 29 ee e8 62 c0 00 00 81 4b 14 00 00 00 04 41 59 5b 5d c3 48 8b 87 a0 02 00 0048 8b 40 f8 c8 48 3b 3d 95 43 72 00 75 08 0f bf 87 6a 06 00 00 [...] Fixing recursive fault but reboot is needed! Call trace involves trying to handle a page fault in led_trigger_unregister, called by power_supply_unregister, called by acpi_battery_notify. The first oops looks similar but scrolled off the screen. This is a 3.3.y kernel with virtualbox modules loaded.) Ideas for moving forward: - please attach: - full dmesg output from a normal boot - acpidump output - see Documentation/power/basic-pm-debugging.txt from [1] or the kernel-doc-3.2 package. Does suspend-to-disk work? Do pm_test modes work? Are any warnings shown at suspend time that can be captured using a serial console or netconsole with no_console_suspend? Does unloading the battery module before suspend avoid trouble? (I still do not understand why my previous messages do not appear at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677016.) Here it is: First, note that I have indeed a problem with the battery, since the icon of gnome is not working properly: it shows an empty battery, whice it is fully loaded, or viceversa. However, its tooltip (showing percentage of battery) is correct. snoopy:/home/ededu# echo reboot /sys/power/disk snoopy:/home/ededu# echo disk /sys/power/state [screen got black for ~2 secs, it shows Cannot find swap device, try swapon -a.\nCannot get swap writer - which is normal since I do not have one - and afterwards comes back] bash: echo: write error: No such device snoopy:/home/ededu# I tested it for 20 times in a row and it worked each time. Afterwards, I tested: snoopy:~# echo platform /sys/power/disk snoopy:~# echo disk /sys/power/state bash: echo: write error: No such device snoopy:~# for 15 times in a row and it worked each time too. As a side note, the link http://en.opensuse.org/s2ram at the bottom of http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt is not valid anymore. I tried: snoopy:~# echo freezer /sys/power/pm_test snoopy:~# echo mem /sys/power/state and snoopy:~# s2ram KMS graphics driver is in use, skipping quirks. and they worked 10 times in a row. The same for: snoopy:~# echo devices /sys/power/pm_test snoopy:~# for i in `seq 10`; do echo mem /sys/power/state; done It works too: snoopy:~# echo platform /sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; s2ram; done [s2ram prints: KMS graphics driver is in use, skipping quirks. This works too: snoopy:~# echo processors /sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; s2ram; done This works too: snoopy:~# echo core /sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; sleep 2; s2ram; sleep 2; done This works too: snoopy:~# echo none /sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; sleep 2; s2ram; sleep 2; done As all this worked, I have not tried unloading battery module before suspend2ram. I have not tried either using a serial console either... What should I do? -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: # echo reboot /sys/power/disk # echo disk /sys/power/state [screen got black for ~2 secs, it shows Cannot find swap device, try swapon -a.\nCannot get swap writer - which is normal since I do not have one - and afterwards comes back] bash: echo: write error: No such device Yeah, suspend-to-disk requires swap. [...] This works too: # echo none /sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; sleep 2; s2ram; sleep 2; done Hm. What tool do you normally use to suspend to RAM? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 22/06/12 17:42, Jonathan Nieder wrote: Eugen Dedu wrote: # echo reboot /sys/power/disk # echo disk /sys/power/state [screen got black for ~2 secs, it shows Cannot find swap device, try swapon -a.\nCannot get swap writer - which is normal since I do not have one - and afterwards comes back] bash: echo: write error: No such device Yeah, suspend-to-disk requires swap. [...] This works too: # echo none/sys/power/pm_test ; for i in `seq 10`; do echo mem /sys/power/state; sleep 2; s2ram; sleep 2; done Hm. What tool do you normally use to suspend to RAM? Just closing the monitor lid on the laptop. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: On 22/06/12 17:42, Jonathan Nieder wrote: Hm. What tool do you normally use to suspend to RAM? Just closing the monitor lid on the laptop. If you explicitly run pm-suspend, does it produce the same bad behavior? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 22/06/12 17:48, Jonathan Nieder wrote: Eugen Dedu wrote: On 22/06/12 17:42, Jonathan Nieder wrote: Hm. What tool do you normally use to suspend to RAM? Just closing the monitor lid on the laptop. If you explicitly run pm-suspend, does it produce the same bad behavior? Just tested the following and it worked: snoopy:~# pm-suspend snoopy:~# cat /sys/power/disk platform shutdown [reboot] snoopy:~# cat /sys/power/state mem disk snoopy:~# echo none /sys/power/pm_test ; for i in `seq 20`; do pm-suspend; sleep 2; done As I said in the first e-mail, the freeze appears each 1-20 suspend actions. I wonder if I am not unlucky during these tests. However, I made several dozens of tests until now, more than the maximum number of suspends during normal working on the laptop. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 22/06/12 18:29, Jonathan Nieder wrote: Eugen Dedu wrote: As I said in the first e-mail, the freeze appears each 1-20 suspend actions. I wonder if I am not unlucky during these tests. That's possible. The only way I would know to test is to make a habit of using pm-suspend instead of closing the lid and seeing if it happens again. But I suspect this is an ACPI support bug elsewhere (effect of lid switch). Can you easily reproduce it by opening and closing the lid a bunch of times? Well, closing and reopening for about 20 times does not trigger the bug. I saw one warning on screen about USB (Unable to enumerate USB device...), at about 10th suspend, and some ACPI info in dmesg output, so I attach it after the ~12th suspend and after all the ~20 suspends, hoping this helps. -- Eugen dmesg12.log.gz Description: application/gzip dmesg20.log.gz Description: application/gzip
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: On 22/06/12 18:29, Jonathan Nieder wrote: But I suspect this is an ACPI support bug elsewhere (effect of lid switch). Can you easily reproduce it by opening and closing the lid a bunch of times? Well, closing and reopening for about 20 times does not trigger the bug. Drat. It's probably a genuine suspend bug, then. :) The trigger could be something like how much memory is free. If you can find a reliable recipe, that would be great, but otherwise we should just get in contact with upstream (assuming it's not already fixed there). Does 3.4.y from experimental reproduce it? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 22/06/12 19:10, Jonathan Nieder wrote: Eugen Dedu wrote: On 22/06/12 18:29, Jonathan Nieder wrote: But I suspect this is an ACPI support bug elsewhere (effect of lid switch). Can you easily reproduce it by opening and closing the lid a bunch of times? Well, closing and reopening for about 20 times does not trigger the bug. Drat. It's probably a genuine suspend bug, then. :) The trigger could be something like how much memory is free. If you can find a reliable recipe, that would be great, but otherwise we should just get in contact with upstream (assuming it's not already fixed there). Does 3.4.y from experimental reproduce it? I reboot with 3.4 right now and contact you as soon as I have the freeze. Note that there are two bugs AFAICT: recursive with lid problem, and double file BATO with -EEXIST. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Hi, Eugen Dedu wrote: Very often (each 2-10 times) kernel freezes with an error message upon resuming from suspend to ram. Here is the message: kobject_add_internal failed for BATO with -EEXIST, don't try to register things with the same name in the same directory Please attach a log or photograph of this in context. 3.2 version of the kernel freezes at suspend too, but as far as I noticed with another error message, something like infinite recursion. I can get it if needed. This would be useful, too. 3.1 freezes too. In fact, I have been having freezes at suspend since 3.0 or 2.6.39, while before suspend was working perfectly. Good to know. We don't support kernels other than 2.6.32.y, 3.2.y, and 3.4.y at the moment (and 3.2.y is most interesting since it is what will be part of wheezy), but it's useful to know when the problem first arrived. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
On 11/06/12 13:31, Jonathan Nieder wrote: Hi, Eugen Dedu wrote: Very often (each 2-10 times) kernel freezes with an error message upon resuming from suspend to ram. Here is the message: kobject_add_internal failed for BATO with -EEXIST, don't try to register things with the same name in the same directory Please attach a log or photograph of this in context. All the screen was black, and the above message at the top. 3.2 version of the kernel freezes at suspend too, but as far as I noticed with another error message, something like infinite recursion. I can get it if needed. This would be useful, too. I will give it to you this evening, I have it on my camera at home. 3.1 freezes too. In fact, I have been having freezes at suspend since 3.0 or 2.6.39, while before suspend was working perfectly. Good to know. We don't support kernels other than 2.6.32.y, 3.2.y, and 3.4.y at the moment (and 3.2.y is most interesting since it is what will be part of wheezy), but it's useful to know when the problem first arrived. If you think that the above two informations are not sufficiently informative, I will make tests with older kernels to see which one introduced the problem. Just tell me. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677016: resume failure: kobject_add_internal failed for BAT0 with -EEXIST
Eugen Dedu wrote: Here it is: another freeze during resume, with kernel 3.3 too. Thanks for the quick feedback. (As a reminder to myself, the message is BUG: unable to handle kernel paging request at fff(lens flare) IP: [810514c7] kthread_data+0x7/0xc PGD 1607067 PUD 1608067 PMD 0 Oops: [#2] SMP CPU 0 [...] Code: 3f 48 c1 e5 03 48 c1 e0 06 48 8d b0 50 54 40 81 29 ee e8 62 c0 00 00 81 4b 14 00 00 00 04 41 59 5b 5d c3 48 8b 87 a0 02 00 00 48 8b 40 f8 c8 48 3b 3d 95 43 72 00 75 08 0f bf 87 6a 06 00 00 [...] Fixing recursive fault but reboot is needed! Call trace involves trying to handle a page fault in led_trigger_unregister, called by power_supply_unregister, called by acpi_battery_notify. The first oops looks similar but scrolled off the screen. This is a 3.3.y kernel with virtualbox modules loaded.) Ideas for moving forward: - please attach: - full dmesg output from a normal boot - acpidump output - see Documentation/power/basic-pm-debugging.txt from [1] or the kernel-doc-3.2 package. Does suspend-to-disk work? Do pm_test modes work? Are any warnings shown at suspend time that can be captured using a serial console or netconsole with no_console_suspend? Does unloading the battery module before suspend avoid trouble? Hope that helps, Jonathan [1] http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
