ac adapter is not detected

[Colin Taylor]

The latest version of jaunty generates errors when trying to load the acpi ac adapter state on boot. The resultant behavior is that the system is unaware of the ac adapter state (nothing gets populated in /proc/acpi/ac_adapter or its equivalent sys directory). The error can be seen via 'dmesg | grep ACPI' after booting:

[ 1.679140] ACPI Error (psargs-0358): [\_PR_.CPU0._PSS] Namespace lookup fail
ure, AE_NOT_FOUND
[ 1.679167] ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.A
C__.ADJP] (Node ffff88013f81a660), AE_NOT_FOUND
[ 1.679215] ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.A
C__._PSR] (Node ffff88013f81a620), AE_NOT_FOUND
[ 1.679264] ACPI Exception (ac-0135): AE_NOT_FOUND, Error reading AC Adapter state [20080926]
[ 1.769339] ACPI: Battery Slot [BAT0] (battery present)

This is most problematic on the kubuntu distribution, as it relies on this information to determine the ac adapter state for powerdevil. On gnome there is some sort of fall back and the correct state is determined (possibly by interpreting /proc/acpi/battery/*)? After investigating this further, I recompiled the stock ubuntu kernel from source with acpi_ac as a module instead of into the kernel and the ac adapter state is detected correctly. ACPI no longer generates errors and outputs the following:

[ 1.824127] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
[ 1.824141] processor ACPI_CPU:01: registered as cooling_device1
[ 1.824143] ACPI: Processor [CPU1] (supports 8 throttling states)
[ 1.858123] ACPI: Thermal Zone [TZ0] (57 C)
[ 12.273114] ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no)
[ 12.302021] ACPI: AC Adapter [AC] (on-line)

Is this the correct method to solve this problem? I've checked this solution against several other distributions that report the ac adapter state correctly (namely ArchLinux and openSUSE) and from what I can tell this is the solution that is used in each case.

lsb_release -rd
--
Description: Ubuntu 9.04
Release: 9.04

uname -a
--
Linux kronos 2.6.28-14-generic #47 SMP Wed Aug 12 07:37:17 EDT 2009 x86_64 GNU/Linux

apt-cache policy linux-image-2.6.28-14-generic
--
linux-image-2.6.28-14-generic:
  Installed: 2.6.28-14.47
  Candidate: 2.6.28-14.47
  Version table:
     2.6.28-14.47 0
        500 http://us.archive.ubuntu.com jaunty-updates/main Packages
        500 http://security.ubuntu.com jaunty-security/main Packages
 *** 2.6.28-14.47 0
        100 /var/lib/dpkg/status

[Colin Taylor (cjntaylor)]

Architecture: amd64
Dependencies:

DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: linux None [modified: /var/lib/dpkg/info/linux.list]
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-14-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Colin Taylor (cjntaylor)]

Architecture: amd64
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=29f9b89f-99b9-4e74-92ee-8dbf1ecb335b
MachineType: CLEVO CO. M860TU
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-14-generic 2.6.28-14.47
PackageArchitecture: amd64
ProcCmdLine: root=/dev/mapper/dpool-root ro quiet splash crashkernel=384M-2G:64M@16M,2G-:128M@16M
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-14.47-generic
Uname: Linux 2.6.28-14-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Zatara214 (zatara214)]

Confirmed this issue from the latest Karmic, as well as Jaunty, Fedora 11 and Sabayon 4.2 with the Clevo M860TU. I'm thinking this is either a kernel issue, or, more likely, an Nvidia issue. Either that, or our specific laptop isn't working for some reason.

  0.700032] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND
[ 0.700039] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.AC__.ADJP] (Node ffff88013ba34620), AE_NOT_FOUND
[ 0.700059] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.AC__._PSR] (Node ffff88013ba345e0), AE_NOT_FOUND
[ 0.700082] ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state 20090521 ac-138

[Colin Taylor (cjntaylor)]

I don't think its nvidia or M860TU specific because I have had plenty of distributions (openSUSE, ArchLinux, etc) detect the AC adapter correctly. It seems highly dependent on weather or not the AC adapter module is built into the kernel or is modular. Also, it seems to be related to timing - for example, on the latest release of ArchLinux (2009.08 x86_64), the same problem arises even with the AC adapter compiled as a module (default in ArchLinux). However if I blacklist the ac adapter on startup and load it using modprobe in rc.local (roughly init 5), there are no problems whatsoever - the entire ACPI system functions correctly (no errors or warnings).

So far this seems to point to the problem being mainly kernel based, but I'm not sure what needs to be changed in terms of the timing issue...

[Zatara214 (zatara214)]

Believe it or not, this is actually good news to me. Many people believe this bug to be BIOS related (bias towards Microsoft products by default). I have emailed Sager, and hopefully I will be sent a newer version of the BIOS for the laptop (I haven't updated it since August of last year). I'm going to try that, as well as openSUSE as per your experience with it. I tried Mandriva 2009.1 One x64 this morning, it's also a victim of this bug. I may also try screwing around with KernelCheck under Ubuntu, as it's much easier to change different options and variables (at least for me).

Personally, I don't really care if the laptop detects AC or Battery properly, but this bug, along with Nvidia's powermizer feature, is absolutely crippling my performance. As long as I can get the 9800 GT to work at full speed, I'll settle for a partial fix, even if it means sacrificing the detection of the battery in favor of the AC adaptor. Have you, by any chance, found a way to force your card to AC power mode?

[Colin Taylor (cjntaylor)]

Dont bother updating your bios unless you really want to. On my sager np8662 i went to all of the trouble of compiling and running my own DSDT, only to find that it had only two warnings and no errors. Basically like your suggesting (and unlike everyone else with this problem), the BIOS has very little to do with it. I run windows XP / windows 7 on my sager and it hasnt corrupted DSDT at all.

As for your fix, I havent tried using powermizer (or I'm just not realizing it), so I'm not sure what to tell you. So far (see above), I have been able to fix this problem by recompiling the stock kernel with ACPI_AC set to modular. This takes about an hour, so give yourself some time if you want to do it (I can post directions if you want, just let me know cause its pretty long winded). This causes the system to correctly report if the AC adapter is connected at the kernel level, so I would think this would solve your problem with the nvidia driver (since its at kernel level too).

The only problem this creates is that if you recompile the kernel from the stock distribution (I grab the kernel conf from the ubuntu repo, change the flag and then recompile), the version number is the same. Update manager is going to nag you inscessantly to update your kernel since it doesnt match the newest kernel version. So far I use package holds as a workaround to stop the insanity (and believe you me its VERY annoying), but the correct way to do this would be to recompile the kernel with a new version number. Only problem is, I cant seem to find a way to do that (if you use the debian rules method included in the stock distro kernel, its supposed to do this automagically, but It never seems to work for me).

Oh and also, I would stay away from openSUSE unless you want a boatload of video card problems. The distro is great, but for the life of me I couldn't get it to detect my nvidia 260M (a relative of your 9800). Who knows, you may have better luck, just a warning (ironically enough the AC module loads with the fewest edits on openSUSE, namely 0 - I think this has something to do with the init system they use, but it only causes different problems so its not much of a solution. Hope you like the nv driver... ^_^).

[Zatara214 (zatara214)]

Yeah, sounds like you've been working on this at LEAST as much as I have lol. First off, you're definitely using Powermizer, it's built into the driver. What it does is adaptively underclock your video card to save power when on battery. In our case, it limits the video card's core and memory clocks to less than half of their potential by force. If you run nvidia-settings, you can actually see that your clocks are at 200/100 instead of 799/500 (which is retardedly slow). You can get a significant boost of performance if you upgrade from the 185 series of drivers to the new 190 beta series (which I'm using and have no issues with). These have an option to go from 'Adaptive' clocking to 'Maximum Performance', allowing us 'battery users' to get from 200/100 clocks to 275/301 (Yay, half power!). Stuff should be smoother for you, at least.

As for an easier way to compile the kernel, under Ubuntu I'd recommend KernelCheck. It's a GUI program that will download the latest version of the kernel, compile it for you, and even let you set the options. The only thing is that it isn't the default Ubuntu kernel, it's the raw source. However, it will also allow you to choose what kernel version you want to use. So you can compile, say 2.26.29 or 2.26.30 (or even an older version of 2.26.31) with ACPI as modular, and still keep the newest 2.26.31-rc so that Ubuntu won't nag you about it.

The only trouble that this produces is that it isn't compatible with DKMS, at least not from what I've seen. So once you install the video driver in that kernel, you'll need to uninstall either that driver or the kernel in order to install a newer kernel (which occurs quite often if you're using Karmic, otherwise it shouldn't be an issue).

Also, I'm shocked to learn that DSDT had nothing to do with it. Everywhere else I've looked (http://www.nvnews.net/vbulletin/showthread.php?p=2050621) lists DSDT as a possible problem, but no one was brave enough to tackle it. Nice job on that. I guess this is just a kernel issue, then. And only in certain distributions. Weird.

If you can't compile the kernel correctly with KernelCheck, I might need you to post that tutorial. I've only ever used KernelCheck once before, and it wasn't really even needed (I set a few options to optimize my CPU usage, that's about it).

And yeah, the last time I tried openSUSE, the 'One Click' driver install kept 404ing. I was hoping I'd have better luck this time, but I think I'll try your solution first, so long as I know how.

[Zatara214 (zatara214)]

Alright, yeah, I'll need you to post that tutorial for me after all. I have no idea what I'm doing, since I've never really had to work at kernel level before.

[Colin Taylor (cjntaylor)]

Ok well like you suggested, I used KernelCheck to compile my latest kernel, so the process has gotten significantly easier (and Update Manager no longer nags me all the time to update ^_^).

Proposed Fix Directions:

1. Make sure your system is fully up to date, either by running Update Manager, or "sudo apt-get -y update && sudo apt-get -y upgrade && sudo apt-get -y dist-upgrade" Be sure to reboot your system when finished.

2. Install the KernelCheck debian from http://kcheck.sourceforge.net/download.html if you havent already (make sure your running the latest version if you have).

3. Use typical installation to build your kernel. You could use custom if you like, but I find that none of the options (including nvidia options) were required.

4. When the graphical version of the kernel config displays (towards the end, takes a while because it has to download a bunch of packages to prep your system for building the kernel, as well as download and extract the linux sources for the new kernel), search for or find "AC Adapter" (the related kernel config key you are looking for is ACPI_AC, but I didnt check if that was searchable). Make sure to select it such that the checkbox next to it is a DOT not a CHECK (this based on the help instructions tells the system to compile ACPI_AC as a module, which is the whole reason to recompile the kernel). Once you are done hit SAVE (very important otherwise your changes are lost), and exit the graphical config.

5. From here the kernel will compile and be packaged as a deb for you, as well as installed automatically. Like it says, it really does take 2-4 hours, so come back in a bit.

6. Reboot your system and thats it. From now on it should detect the ac adapter correctly, and it shouldnt throw out any ACPI errors in the startup log. You can check that it worked by looking at "dmesg | grep ACPI | less" and looking for "ACPI: AC Adapter [AC] (on-line)" (towards the bottom)

--

Also, since you use an nvidia chipset, I would also suggest the following steps. By doing the above plus the set below, my system now runs at full clock speed AND adjusts when I'm running on battery (basically powermizer works as its supposed to):

1. Download the nvidia 190.32 official driver package from their site:

[32-bit] http://www.nvidia.com/object/linux_display_ia32_190.32.html
[64-bit] http://www.nvidia.com/object/linux_display_amd64_190.32.html

2. Remove all ubuntu/other debian nvidia packages with: "sudo apt-get -y purge nvidia*"

Now your going to want to memorize or write down the following steps, because your going to have to close X down in order to continue:

3. Switch to another tty such as tty2 (virtual terminal 2) via Ctrl+alt+F2 (or F? if that terminal is not free, ex F4, F5). Login with your normal username and password.

4. Run the following to shutdown X: "sudo /etc/init.d/gdm stop"

5. Now this seems counter intuitive, but trust me (my system broke for a while until I figured this out). Run the following to UNINSTALL any lingering nvidia drivers you might have: "sudo nvidia-uninstall"

6. Change to your desktop directory or wherever you put the downloaded nvidia drivers via: "cd ~/Desktop" or "cd <download...

[Zatara214 (zatara214)]

Worked perfectly. I realized while I was starting up KernelCheck that by default (as of today), it will install kernel version 2.6.30.5. This is actually older than the Karmic kernel, and is not the newest version. If you go to 'Custom Install', select 'Install older prepatch' and select 2.6.31, you will actually be using a newer release than what is currently default for Karmic (but expected to be used by default by the time it is released). I guess it really doesn't make that much of a difference, though, as both versions work and are newer than the Jaunty kernel.

I'll post this tutorial everywhere where I saw people with the same issues. Hopefully this will be fixed within the kernel by default soon enough, because this was not a fun process to have to go through.

[zeronine (zeronine)]

Just to confirm here:

I have an Sager 8662, which uses a Clevo M860TU

I recompiled the 2.6.28.10 kernel with ACPI_AC as a module. The AC Adapter is now functioning correctly. This seems to fix the issue for me. The AC adapter is now detected and works.

[Zatara214 (zatara214)]

Hahaha oh wow. This fix no longer works in 2.6.32. I compiled the kernel with AC Adapter as a module, but have yet to try it as a part of the kernel. I'll have to play around with the new kernel a bit more.

[Zatara214 (zatara214)]

That was fast. Fixed after uninstalling the older kernel (I was using 2.6.28-14) and rebooting. Seems to work now.

[Colin Taylor (cjntaylor)]

You probably didnt have the new kernel loaded before you uninstalled it. Ubuntu defaults to the standard kernel unless you reorder your entries in grub (there is some way to edit the comments in /boot/grub/menu.lst to do this automagically via update-grub, but i dont remember how). Glad that it still works. Can't figure out why this hasn't been included in recent kernel updates - ive stopped using ubuntu and switched to a distro that does this by default. Changing the default to module should work for a majority of people, and solve this problem for us without requiring a kernel recompile.

[Zatara214 (zatara214)]

I've started using Jolicloud, which is a Jaunty-based distro. I'll keep you updated on when a fix for this is added. In the meantime, still nothing.

[Colin Taylor (cjntaylor)]

Thanks. If they fix it I will probably come back to Ubuntu, but for now im enjoying ArchLinux. It takes a lot of getting used to (setting up from scratch that is), but its very rewarding once you get the hang of it.

[Zatara214 (zatara214)]

Quick question: What kernel version are you currently using under Arch? Because after messing around with this one for a few hours, I've come to realize that my power button no longer works. I had to use the GUI to put my computer to sleep, and once it was suspended it wouldn't wake up. Had to manually restart it.

[Colin Taylor (cjntaylor)]

2.6.31

It takes some configuration to get it to work in arch. By default it loads as a module, but i've always had to load it apart from the other modules (disable it by default, and load it at the end of rc.sysinit). Let me know if you want specific instructions, I can try to dig up the exact process I used (was a while ago, dont quite remember).

[Zatara214 (zatara214)]

No no, I'm saying it doesn't work under Ubuntu. I'm actually installing Arch on my desktop right now to try it out, I'll take your word for the payoff. As for the power button not working on my laptop, I'm going to see if it still doesn't work when the Jolicloud generic kernel 2.6.32 is released on Thursday. If it still doesn't work, it must be a kernel issue and I may have to go back to 2.6.28 (2.6.31 has major issues for me), but if it works, it must have been something I did in the configuration I did earlier today.

[Colin Taylor (cjntaylor)]

Oh geez. Get ready for no config. Its roughly equivalent to Gentoo, but with binary packages. The archlinux wiki is very helpful for configuring things, and its very open ended. If you have any questions, feel free to ask.

(Sorry, I didn't wish arch upon you. Its a bit hard to get used to, but very rewarding. You'll have a fantastic understanding of the linux subsystem if you get the hang of it).

[Zatara214 (zatara214)]

Well I've used Sabayon before, so being that it's a bit like Gentoo (but pre-configured from the start), I think I'll have an easier time than you'd think. Sure, Ubuntu has a great packaging system, but thank the lord it's not the only thing I know of in the Linux world.

Apparently Arch has some issues with the latest version of VirtualBox, at least for me. I'm going to have to try it native on my desktop if I want to use it.

[Colin Taylor (cjntaylor)]

Good to hear. As for the virtualbox, really? Im running a copy in virtualbox right now, and although the vbox drivers were a bit hairy to get setup, it works great now, mouse and autoresizing included. Now, granted, this is using fluxbox as opposed to gnome, but that should make things more complicated, would'nt you think? Their wiki doesnt seem to suggest any issues either, but i dont know if its up to date.

Just my 2 cents.

[Zatara214 (zatara214)]

I'm fairly certain that the vbox issues I'm having are also an effect of the new kernel. Never had these issues with 2.6.28. I'll probably switch back if the generic kernel doesn't turn out to be anything good. Apparently there was a new bug introduced in 2.6.31 that required the real-time kernel to be installed or vbox wouldn't work as it should (which I experienced before, but I was hoping it was fixed). I'm surprised you haven't had this issue, as well. Guest pausing/stuttering every 15 or so seconds.

[Colin Taylor (cjntaylor)]

What version of virtualbox are you using? I'm curious now, I have version
3.1.0 for reference. Also, what do you mean by stuttering/pausing? Is there
a reference for these kernel bugs?

Just curious...want to know what to expect if this starts happening / how to
tell. Thanks.

On Wed, Dec 9, 2009 at 1:54 AM, Zatara214 <email address hidden> wrote:

> I'm fairly certain that the vbox issues I'm having are also an effect of
> the new kernel. Never had these issues with 2.6.28. I'll probably
> switch back if the generic kernel doesn't turn out to be anything good.
> Apparently there was a new bug introduced in 2.6.31 that required the
> real-time kernel to be installed or vbox wouldn't work as it should
> (which I experienced before, but I was hoping it was fixed). I'm
> surprised you haven't had this issue, as well. Guest pausing/stuttering
> every 15 or so seconds.
>
> --
> ac adapter is not detected
> https://bugs.launchpad.net/bugs/412499
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” package in Ubuntu: Triaged
>
> Bug description:
> The latest version of jaunty generates errors when trying to load the acpi
> ac adapter state on boot. The resultant behavior is that the system is
> unaware of the ac adapter state (nothing gets populated in
> /proc/acpi/ac_adapter or its equivalent sys directory). The error can be
> seen via 'dmesg | grep ACPI' after booting:
>
> [ 1.679140] ACPI Error (psargs-0358): [\_PR_.CPU0._PSS] Namespace lookup
> fail
> ure, AE_NOT_FOUND
> [ 1.679167] ACPI Error (psparse-0524): Method parse/execution failed
> [\_SB_.A
> C__.ADJP] (Node ffff88013f81a660), AE_NOT_FOUND
> [ 1.679215] ACPI Error (psparse-0524): Method parse/execution failed
> [\_SB_.A
> C__._PSR] (Node ffff88013f81a620), AE_NOT_FOUND
> [ 1.679264] ACPI Exception (ac-0135): AE_NOT_FOUND, Error reading AC
> Adapter state [20080926]
> [ 1.769339] ACPI: Battery Slot [BAT0] (battery present)
>
> This is most problematic on the kubuntu distribution, as it relies on this
> information to determine the ac adapter state for powerdevil. On gnome there
> is some sort of fall back and the correct state is determined (possibly by
> interpreting /proc/acpi/battery/*)? After investigating this further, I
> recompiled the stock ubuntu kernel from source with acpi_ac as a module
> instead of into the kernel and the ac adapter state is detected correctly.
> ACPI no longer generates errors and outputs the following:
>
> [ 1.824127] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
> [ 1.824141] processor ACPI_CPU:01: registered as cooling_device1
> [ 1.824143] ACPI: Processor [CPU1] (supports 8 throttling states)
> [ 1.858123] ACPI: Thermal Zone [TZ0] (57 C)
> [ 12.273114] ACPI: Video Device [PEGP] (multi-head: yes rom: no post:
> no)
> [ 12.302021] ACPI: AC Adapter [AC] (on-line)
>
> Is this the correct method to solve this problem? I've checked this
> solution against several other distributions that report the ac adapter
> state correctly (namely ArchLinux and openSUSE) and from what I can tell
> this is the solution that is used in each case.
>
> lsb_release -rd
> --
> Descrip...

[Zatara214 (zatara214)]

There's a big thing about it here

http://marcosaruj.com/archives/382

Although this didn't work for me, since I'm using the Jolicoud kernel, not the Ubuntu one. I had to revert back to 2.6.28 from 2.6.31, which solved the issue.

I'm using 2.6.32 right now, which I built to be a real-time kernel, but I'm still having this issue (though it's gotten better since 2.6.31). Must be a regression somewhere... again...

[Zatara214 (zatara214)]

Alright, confirmed that the power button no longer works with the generic version of 2.6.32. Any idea what KernelCheck option is linked to the power button state?

[Harrison Chapman (hchaps)]

Just as a heads-up, this bug is still affecting me in the newest Lucid alpha release. (I have the same model of clevo as the others here, the serval professional).

Here's a really stupid question though -- is there anyway whatsoever to make a false directory structure under /proc/acpi/ac_adapter? (is this where I should be looking? or should it be somewhere in sys?), as unlike /proc/acpi/battery which contains a BAT0 directory and everyone else (without this bug) appears to have at least a /proc/acpi/ac_adapter/AC/ directory (or the like), I was just wondering if there were some way to create a dummy structure (so other programs would think I'm plugged in... as I am). Not really a newbie here, just never really messed with kernel-level stuff.

In summary: the power adapter hasn't worked since Jaunty (At least) all the way through to Lucid. Why not just change ACPI_AC to a module again?

[Zatara214 (zatara214)]

Have you tried out the new 2.6.33 release candidates? Because I haven't. You can get them here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/

[3ntix (francesco-3ntini)]

I don't know why, but I've compiled the ubuntu kernel for karmic
(2.6.31-17) with the acpi module (battery, ac, etc) loadable
externally and so the ac adapter finally works.
I'm a newbie with kernel compiling, but if someone want it to try, I
can share my kernel packages.

[Zatara214 (zatara214)]

We've already gotten to that point here. We've been using KernelCheck to compile the kernel from source with the ac_adapter module loadable externally. What we'd prefer is a solution that doesn't involve compiling the kernel every time a new one is released. Prferably a full blown fix for the issue.

[Colin Taylor (cjntaylor)]

At this point, all that needs to be changed is the ACPI_AC adapter flag in
the default kernel configuration needs to be changed. Its getting annoying
at this point, because every other linux distro I use has done it this way
for years and its not a problem. Anyone got any ideas on how we can escalate
this issue?

[Zatara214 (zatara214)]

Not really. Truthfully, I don't know of a more popular bug reporting system than Launchpad.

And yeah, this is extremely annoying already. Having to compile my own kernel isn't exactly convenient.

[Zatara214 (zatara214)]

Problem persists in 2.6.33.

[RenZO (laurent-novatux)]

Same problem on Clevo M570 and W760. With AC Adapter as module, it's ok. Please change the flag, like it was on Hardy.

[Stian Knudsen (disabled-ag0ny)]

I too have this problem related to nvidia powermizer on Karmic with a M860TU. Gnome powermanager seems to detect AC/Battery status fine however, how is that?

[Colin Taylor (cjntaylor)]

From what I can gather, Gnome powermanager partially displays the status correctly. If you look closely, it will be sort of correct, but it still isn't really working. I believe this has something to do with how it gets its information, which includes the BATT entries in /proc/acpi. These file(s) can be used to partially determine the state of the battery but its not accurate as to when it is plugged in or not. Furthermore, it is the only program that gains its information this way, so things like powermanager (for suspend/hibernate) and Nvidia powermizer (discussed above) still do not detect mode switches correctly. It is still crucial that the flag be changed in the standard kernel configuration, as it correctly adjusts the system to generate a /proc/acpi/adapter/AC/state file, which will allow other programs to work, as well as increase the accuracy of powermanager.

Regardless, its seems as though this kernel request is being ignored, seeing as I put in the error in 9.04 far before 9.10 came out and 10.04 is already in its second beta. Oh well, until this is fixed I wont be using ubuntu - it surprises me to see how inactive the dev community is on these bug reports. *annoyed glare*

[3ntix (francesco-3ntini)]

How is possible that lucid have the same problem. I use Kubuntu and I've to compile the kernel manually to detect the ac adapter. If I don't do thank, KDE put the system to "extreme powersave" with the ac adapter in!!!
When this bus is solved?
I too annoying...

[Zatara214 (zatara214)]

Fixed in the latest Maverick kernel builds! I'm so happy. Grab the latest kernel from the mainline kernel PPA and set Powermizer to Maximum Performance and it'll go all the way up! :D

[Armin (armin-kazmi)]

I' also have the problem on lucid with a Clevo M570RU - but the fix is simple:

Compile the ac part of the kernel as module and the issue is fixed. I assume there is some kind of race condition in the detection code of the ac adapter. As far as I know, many distibutions already do it this way and don't have side effects for not affected systems. Therefore, simple as that, make a default kernel config which has "ac" compiled as module.

[Jeremy Foshee (jeremyfoshee)]

Declining the Maverick specific nomination for now and leaving this open against the actively developed Ubuntu kernel (which happens to be Maverick at this time). Will re-open the nomination should a fix be narrowed down which we can confirm specifically resolves this issue in Maverick.

~JFo

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.