Description: I am running on a toshiba satellite. A while ago I updated the kernel to version 3.9.2-1, and when I rebooted, I noticed that XFCE no longer displayed battery information (only the AC adapter) even when I'm not plugged in to the wall. running 'acpi -V' shows no information about batteries, only an error message where it normally would ("No support for device type: power_supply"). Prior to the update, the battery was detected without issue. A further upgrade in the kernel (currently I'm running 3.9.4-1) did not see a fix. Additional info: * Kernel version 3.9.2-1 and up appear to be at issue. * There is a forum post with many more details at https://bbs.archlinux.org/viewtopic.php?id=163223 * More information can be provided on request.
Please provide the output of acpidump, dmesg and `grep . /sys/class/power_supply/*/*`. What is the latest good kernel version?
acpi dump attached. dmesg attached. The directory /sys/class/power_supply is empty. Nothing exists in it. The latest kernel to work was 3.8.11-1
Created attachment 103631 [details] Output of acpidump
Created attachment 103641 [details] Output of dmesg
Please attach the kernel config file. I don't find the battery and AC driver log in the dmesg.
Created attachment 103671 [details] Config file for the kernel I hope this is what you were looking for.
Please check whether the issue takes place v3.10-rc4. If yes, please try following patch and check whether get the debug log during bootup. --------------- diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index e710045..5bed05e 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -706,6 +706,7 @@ static int acpi_battery_update(struct acpi_battery *battery) if (result) return result; if (!acpi_battery_present(battery)) { + pr_info("%s: battery is not present\n", __func__); sysfs_remove_battery(battery); battery->update_time = 0; return 0; ------------------ From your previous discussion, it seems a regression between v3.8.10-v3.9.2. Please do a bisect to find which commit cause this issue. --------- Another bit of information: /sys/class/power_supply is empty or populated for me as follows: newish Toshiba, 3.9.2-1-ARCH, x86_64 : empty newish Toshiba, 3.8.10-1-ARCH, x86_64 : populated older Toshiba, 3.9.2-1-ARCH, i686 : populated ---------
Still an issue on 3.10.0-rc4. This is going to sound stupid but here goes. Couldn't get the patch to work (I just copied and pasted it to a file and ran patch on it, but it failed to apply no matter what I tried. I don't really know how to apply that particular patch, to be honest.) All that happened was that I got: patching file drivers/acpi/battery.c Hunk #1 FAILED at 706. 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/battery.c.rej I did go in to the C source file and add the line by hand, though, and then recompiled the kernel and booted. Did not see any message it when I grepped dmesg for it, nor did it show up on screen during boot. Though I would add that it's not just the battery that stopped working. On this laptop there are many fn keys that ACPI is supposed to detect. Many of them stopped working too at the same time as the battery issue. To whit: the switch-video-output device button (don't remember its name), the wifi on-off button, the brightness up/down buttons... and so on. About the only ones of those that still work are the volume, the suspend to ram, and the hibernate buttons. The point of all that was to say that I don't think it's directly related to battery per-se. Or at least not limited to it. I will start working on the bisect tomorrow. Thanks
Ok.Thanks for test. (In reply to comment #8) > > Though I would add that it's not just the battery that stopped working. On > this > laptop there are many fn keys that ACPI is supposed to detect. Many of them > stopped working too at the same time as the battery issue. To whit: the > switch-video-output device button (don't remember its name), the wifi on-off > button, the brightness up/down buttons... and so on. About the only ones of > those that still work are the volume, the suspend to ram, and the hibernate > buttons. Ok. I first get these info. Fn + key events are produced by toshiba_acpi driver. Please attach the output of "lsmod". > > The point of all that was to say that I don't think it's directly related to > battery per-se. Or at least not limited to it. > > I will start working on the bisect tomorrow. That will be very helpful. Thanks. > > Thanks
Created attachment 103891 [details] output of lsmod
toshiba_acpi was not loaded. I tried "modprobe toshiba_acpi". It loaded, but a subsequent acpi command line showed no change. After that I put a config file in /etc/modules.d to load toshiba_acpi, and it loaded, but again no change in behavior.
I meant to say "/etc/modules-load.d/"
I also don't see battery and ac driver were loaded. Please make them(including toshiba_acpi driver) built in kernel and try again with my previous patch.
I have made the ACPI battery and ac built in, but the config seems to only allow acpi_toshiba to be done in module form. Booted it but no effect. Also, with the patch, again no mention of it in dmesg or on screen during boot.
Ok. Please attach the dmesg.
Created attachment 103911 [details] dmesg with acpi_(ac|battery) built-in toshiba acpi compiled but did not appear to load.
Sorry. There is no clue. Please do a bisect.
Which branch am I supposed to be bisecting? linux-stable? Mainline (aka "linux")? In both of those, I see only versions like "v3.8" and "v3.8-rc3". Which release candidate corresponds to the actual releases (for instance, v3.8.10) I'm not familiar with git at all.
it's better to do bisect in the Mainline(linux upstream tree.)and beteen v3.8 and v3.9
So... Still working on the bisect. It takes a long time to compile so it's slow going. Just don't want you to think I lost interest.
Yes, bisect is slow but effective to locate the cause and I am here :). Thanks for your patient and support.
Created attachment 104631 [details] config of working kernel The only change here was to enable "smart battery driver" or whatever it's called in ACPI settings.
I grew suspicious when I was compiling kernels with versions older than the "bad" one in the bisect with no results, so I compiled kernel 3.7, and it too failed to show ACPI. So I tried one last time to change settings in the config. The only change that I made to THIS kernel that I hadn't made before was to enable "smart battery system." I'm running the latest kernel compiled that way and it works fine. I think the problem may have resulted from (or at least continued to hide because of) using "make localmodconfig" for all of the kernels that I was compiling, and the one I'm running didn't have that checked off. So now I'm using the defaults and seeing if that's going to work (which I doubt because I've tried it before by just agreeing to everything "make config" offered.) But anyway It's not a kernel bug, per se. I will post on here when I find out whether "make defconfig" works, or if I can get it to work with a simple change.
(In reply to comment #23) > I grew suspicious when I was compiling kernels with versions older than the > "bad" one in the bisect with no results, so I compiled kernel 3.7, and it too > failed to show ACPI. > > So I tried one last time to change settings in the config. The only change > that > I made to THIS kernel that I hadn't made before was to enable "smart battery > system." I'm running the latest kernel compiled that way and it works fine. From the acpidump, this machine should have no Smart battery. > > I think the problem may have resulted from (or at least continued to hide > because of) using "make localmodconfig" for all of the kernels that I was > compiling, and the one I'm running didn't have that checked off. So now I'm > using the defaults and seeing if that's going to work (which I doubt because > I've tried it before by just agreeing to everything "make config" offered.) This looks like a kernel config issue rather than a kernel bug just like you said. Following are from kernel's README. It shows "localmodconfig" runs "lsmod" to find all the modules loaded on the current running system. So it's related with the system configure you are running. "make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loaded modules. > > But anyway It's not a kernel bug, per se. I will post on here when I find out > whether "make defconfig" works, or if I can get it to work with a simple > change. Since this is not a kernel bug, close this as invalid.