I'm using a debugged dsdt on my default gentoo instalation and the main reason why I (and those who helped) started messing with the dsdt was the lack of battery status. No info on current charge status.

Today I tried a liveCD of the latest kubuntu series, and I was surprised to see that the battery display was working just fine there... Same goes for slax (another liveCD). So it kinda hit me... How did they do it? I think that including custom dsdt's in the kernel would be impossible so how did they managed to make it work just like that?

Anyone has any ideas?

Newer kernel perhaps?_________________"I cannot support a movement that exploded spending and borrowing and blames its successor for the debt."
-Andrew Sullivan

It seems that the custom laptop support in the kernel addresses some of the battery status I mentioned before.
I'm not sure which module does the job, but when booting the liveCDs there are several acpi modules loaded. These correspond to asus acpi, toshiba acpi, and others... all of them included in the vanilla kernel.

Thanks to all that helped. I've uploaded a working dsdt for the Toshiba Satellite P105-S6177 to acpi.sourceforge.net. My system is dualbooted with both Gentoo and openSUSE, and sound now works in both._________________"I cannot support a movement that exploded spending and borrowing and blames its successor for the debt."
-Andrew Sullivan

That option actually IS there.. But you have to look for the options that have to do with firmware. If I recall correctly (can't get to a gentoo machine right now), you have to disable something called 'don't build drivers that require firmware' plus the option right underneath or above that. This is 'hidden' in the drivers section, not in the acpi one. When you've done that, the items you were looking for will appear in the acpi section.

For the 'Use of reserved word' errors, just rename all ocurrances of it with something else. I think I renamed all my '_T_0' to 'T_0'. I'm not sure about the access width. For the 'Not all control paths return a value', you need to stick a return in there. But I dont remember what it should be returning. You should be able to find what to return by searching around._________________Adopt an unanswered post!
God rocks

This of course makes absolutely no sense... Has anyone figured out a way to figure out what this statement was initially trying to accomplish? Or what to do to fix something like this?

(This showed up on my Abit IS7 and Foxconn G9657MA motherboards, eerily similar errors. Both use Award BIOS I think.)

My Foxconn's WOL doesn't work (there seems to be another warning related to that) as well as hangs randomly on boot while detecting ACPI... wonderring if this is related..._________________Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSDWhat am I supposed to be advocating?

I'm giving up on this ... Commenting out the notification code!
No lid events but at least no high CPU loads nor huge logs.

Hi! Maybe I'm posting a little late but I didn't pay attention to the A6T lid problem until recently.

I've read the whole discussion about A6T lid events and came to conclusion that the approach of modifying \SB.LID._LID() method was completely wrong. The real source of problem with events flood is straightforward approach to notification in \_GPE._L12 method. So, I've changed

and voila! - it works as expected generating only one event per lid opening/closing respectively.
Maybe Sleep() argument needs adjusment though.

And for other Asus A6T users experiencing the same problem when the the CPU fan keeps running all the time if CPU temperature doesn't reach the threshold of about 50C I have working solution too: there's a need to add a call to \_GPE._L02 method (may be \_TZ.STRP will suffice - it's called from \_GPE._L02) to some code which is executed during either OS start and resume fom suspend/hibernation. So I've decided to put it in \_TZ._TMP before Return() statement: