Re: [ACPI] DSDT problem with Acer Aspire 3002NLC

[Thomas R. <tr...@su...>]

Ramkumar R wrote:
> thanx a lot...that worked ! .... just curious as to what it changed in
> the dsdt ... coz out of curiosity i also tried the one with the errors
> (just realised that even when there are errors, it still outputs a hex
> file) ... atleast /proc/acpi didn't show any changes...

Don't know whether the .hex file of a DSDT compiled with errors is valid.
> 
> secondly, is this a big enough change for me to create a new dsdt
> entry in the dsdt database ?

Adding the External (...) statements?
No this doesn't fix anything.
It's just a hint for the compiler that these objects are in a separate
table.
You can do:
acpidmp > /tmp/acpidmp
acpixtract ssdt /tmp/acpidmp > /tmp/ssdt
(be careful there could be more than one, maybe you have to split
the /tmp/acpidmp outputfile (it's a text file, you can just copy away
several SSDT.... parts) to e.g. /tmp/ssdt1 /tmp/ssdt2).
iasl -d /tmp/ssdtX
There should somewhere exist the \PR.CPU0._PDC object the compiler complained
about.

However your dsdt/ssdt(s) seem to work well.
I expect your battery to be a smart battery system, for which an instruction
exists to get it going. It includes patching your DSDT with some additional
instructions.

If you grep the archives you should find a step by step instruction.
IIRC Rich Townsend posted it, at least he did this smart battery stuff.

> and a bit off topic, what exactly can i do with the
> embedded_controller entry i have in my /proc/acpi ? it just shows up
> an info file ?

That's OK, AFAIK the embedded controller does not provide any interface
to userspace you could play around with.

     Thomas

P.S.: you should CC the list again, so that others with similar problems
grepping the archives or googling know what to do.