I opened a threat in the kernel forum hoping to get help but it looks like it is just you and me pal. I reported some more unsuccesful experiments there.

Actually, I created a liveUSB with sys-boot/unetbootin (in Windows XP, shame on me) so I don't know if those are the same versions as the CDs this days...

let me know how it goes. No special flags on kernel, just default option in grub menu.

I'm going to have to install a genkernel my head hurts just to think on all those useless modules, but I see no other way out. If it works I'll try to get rid of modules little by little. I'll let you know how that goes._________________SAGER 5793

About that first bug (about existing 2 modes) I've seen it before and I don't think it is a real problem. I tried the suggested kernel option with no improvements (so no need to email anybody ). As for the thermal bug I've also seen it but I haven't noticed any issues with my fans or temperatures so I'm not worried about that either. All I need is AC adapter so I can have a battery mode and have the nvidia card working with ACPI.

Are you moving to ubuntu? It is tempting... I've already done all the compiling here in gentoo (X, kde, gimp, firefox, etc etc) and are more familiar with portage so I'm going to give thi genkernel a chance and see how it goes. But my point remains... there is no such bug in DSDT for it works in the bootCDs so there is no need to patch it. I wonder where can we get help or report this? Nothing seems to be going on here.

I'll report back when I'm done with genkernel._________________SAGER 5793

Well, I don't plan to move to Ubuntu but you never know. I like the way gentoo works. Currently I'm using the Sabayon overlay for the quick binary installs of large packages. So, I would like to get the ACPI working properly in my current setup. It does seem to be a distro specific issue though if your 32bit gentoo live and the ubuntu 64bit work with the issue. I sure would like to figure out the reason though; you know what I mean?

A quick search on the internet about that bios bug error says this

Quote:

As this says, it is a BIOS bug, which means your hardware is broken, not the kernel.

So, it does look like the bios does have issues, however some distros appear to be able to work around it...

*rant on*
It's too bad the smarter people around here don't pipe up though. All I ever see in forums is "just google it." "did you search the forum" "It's in the wiki" But if you ever have a real problem, nobody bothers to offer any help lol. Not only that but we've offered a lot of info and dug into the intertubes for answers. We've been doing a lot of testing of different things as well. You'd think the devs would be interested wouldn't you? Especially if other distros are not having the problem. I'm tempted to check out Suse and redhat and fc and such just to see how they handle it. In which case I might just jump ship to another distro. I've posted in the Sabayon forums as well. Guess what... No reply there either lol. I'm carrying on a thread there by myself with progress reports and no replies yet lol.
*rant off*

Anyway, I'll probably work this issue till I got no more ideas. Then I'll see what I do. I'll keep updating this thread with my progress at any rate. Probably take a break from this problem for a day or so and clear my head. Start fresh with a new persective; ya know?

I wish I could figure out why my machine is not loading that custom dsdt though. Too wierd.

I emerge genkernel, emerge and "old" gentoo source 2.6.24 (because this is the same version as by liveUSB) and simply proceed as the gentoo handbook indicates,

Code:

eselect kernel list
eselect kernel set X (where X is the number of the 2.6.24 kernel version)
genkernel --kerner-config config_from_liveUSB --menuconfig all

The --menuconfig option above is needed in my case because I'm using AHCI in the bios (activated by leaving the robson flag on). So I have to compile AHCI in the kernel, not as a module (the default in liveUSB).

This automatically copies 3 files to the boot directory (or partition) and you have to let grub.conf about them (instruction on the handbook)

I boot up my new genkernel and voila`, I get full support of ACPI. Problem is that the new genkernel directory is 2.2 Gb!!! and boot up is slow (not to mention the pentium-pro processor, read below).

With this kernel as the control experiment (hereafter referred to as genny), I have done the following variations to determine why exactly this is successful and not the customized kernel.

- Disable initrd (hardware autodetection) to see if we still get functional ACPI.
modify grub.conf to create an entry that load the same genny kernel but disabling hardware autodetection (disabling initrd in the kernel option, this is discussed in handbook).

result: same ACPI errors as before genny.

- initrd detects and loads a bunch of modules so try loading all modules detected and loaded by genny's initrd:
Get a copy of all modules loaded by genny: lsmod >modules. Copy those to /etc/modules.autoload/kernel-2.6, and reboot again into the genny-notinitrd grub entry

result: same ACPI errors as before genny. Very puzzling but ** Maybe the order in which modules are loaded is important... I have to test this yet. I took pictures with a digital camera to see the booting process in detail... desperate measures...

- genny uses CPU: Pentium Pro, I want to use Core2. Change this and only this in the config file and reboot.

result: same ACPI errors! I tried this with the initrd on. This could be the main problem... the new DSDT table can only use Pentium Pro and not Core2... this would make sense in the WindowsXP philosophy, one OS for all possible PCs. They have to go after compatibility and not optimization.

My current conclusion is that we need 2 things: the Pentium Pro processor option and a module or initrd that I still need to figure out. This would also imply that the DSDT is not compatible with Core2 and needs to be patched. And the reason why it is still not working (our patched DSDT) is because we also need a module or the initrd that we still have to figure out.

Future work:
-Figure out what exactly initrd is doing for us, in the best of worlds it would be just module so we wouldn't need the autodetection every time.

- Try genkernel on a recent kernel, possibly tuxonice where I have hibernate working.

- come back to the patched DSDT and implement it together with the misterious initrd/module still to be identified.

If this doesn't work, decide if I really want to switch to pentium-pro and recompile everything just to have ac_adapter working. I'm sure a switch script could be used as a replacement of the missing ac_adapter error... after all, the battery directory is populated, that should be enough.

As for your other insights, I agree with you, I also feel kind of lonely here _________________SAGER 5793

I noticed that sometimes even "genny" would show ACPI errors in dmesg. So I traced down that to me sometimes forgetting to clear up the /etc/modules.autoload/kernel-2.6 file.

So my current theory is that... if you compile into the kernel the ACPI modules, they get loaded in the wrong order... specially the AC module seems to be loaded before something in the kernel is "ready".

This didn't happen in the genkernel because 1.- they are compiled as modules and 2.- they seem to be loaded in the right order (by the initrd hardware autodetection). But when I loaded those modules myself in the module.autoload/kernel-2.6 they might be loaded in the wrong order (even in genkernel) and they would generate ACPI errors.

The solution is therefore, to put them as loadable modules in the kernel (what ever version, it doesn't matter (I'm using tuxonice 2.6.28 )). I'm also using core2, so you can forget about my theories in previous messages.

And, if you get error messages, then simply modprobe -r ac, and reload and the /proc/acpi/ac_adapter will be populated.

So I guess we just need to figure out how we can convice the kernel to boot up the modules in the order we want... for instance it bothers me that even if my module.autoload/kernel-2.6 is empty, gentoo still loads some modules!!! I don't know how to disable that automatic feature. Time to google some more.

OK I'll give that a try. It makes sense As the ubuntu live cd that works for me also loads most of the ACPI config as modules. It didn't even occur to me that the order might be screwing things up.

*Off Topic*
As for the nvidia issue. I am having issues with nvidia drivers as well. The only way for me to get it to work was install the binary nvidia drivers via the Sabayon overlay. If I try to install from source I get all kinds of errors. I could post up my xorg.conf for you if your interested. But I'd try adding the Sabayon overlay and installing the binary real quick see if that works for you. if you want a quick command-how-to let me know.

Sorry to hijack this thread. I have an ASUS X51RL series laptop. Over the past few weeks it hangs under elevated cpu usage - particularly when doing a big emerge. I've done a little research and it appears it might be ACPI related. From dmesg, I see that my ACPI is tarnished by being compiled with MS compiler :

OK I changed all ^CPU0._PPC calls to CPU0.PPC and now only get 12 errors. the new list is below.
It looks like kernelhacker is having the same issue I am. Although I'm not suprised. He has the same laptop it looks like lol. Damn Clevo and their buggy DSDT lol.

Yeah, but i'm not sure if i should be happy, that we are two with the same problem now ;=
Well, compiling the ACPI parts as modules worked for some of my problems - especially my nvidia card now detects the powersource correctly and i finally have higher clock frequencies.
But: I'd like to have some more accurate battery information. I only get "current rate: unknown". Is there any way to fix that?

Hi there,
I have an old Compaq Armada 1750 with broken ACPI (or simply written for Wintendo full of OS conditionals). Now, I can find a ? patch ? at
http://acpi.sourceforge.net/dsdt/view.php?id=168
reportedly worth to try but I do not know what to do with it. Patch against what? I have my dsdt caught, disassembled, even minor bugfix I could do, but no way have I been able to find out what to do with this patch.
Unfortunately I need acpi on this box because its apm freezes X occasionally and it has ended up loosing some hours work.
It may also be responsible for some other minor issues, and I want to monitor batteries separately (yes, this old box has 2 battery bays !) to change a spare one, and so on._________________Quis custodiet ipsos, custodes?