Dell DSDT corrected

Dell DSDT corrected

[Jan Slezak]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Hi there!

I modified my Dell Latitude C640 DSDT table and values in /proc/acpi what were 
previously constantly zero (or something equivalent) where brought to life. 
This is:

- temperature in thermal zone
- processor frequency in performance in processor (processor consumption is 
still zero, but I belive it is not exposed to ACPI)
- all information in battery (except presence/absence what was already working 
before)

The DSDT patch and original DSDT are enclosed I hope it helps someone.

Patch avoids passing buffers as arguments to functions that modifies it. I 
discovered that such buffers are passed by value and modifications don't 
apply to where it should.

P.S. to Marco: I didn't find any item in my DSDT concerning fans so I think it 
is realy not exposed to ACPI and no items are shown under /proc/acpi/fan 
(WinXP also doesn't show fans in hardware list and I think it doesn't drive 
them, they are likely driven directly by BIOS). But I am able to drive fans 
by i8k module made by Massimo Dal Zotto.


Jan

[-- Attachment #2: dsdt.dsl.dell.gz --]
[-- Type: application/x-gzip, Size: 8204 bytes --]

[-- Attachment #3: dsdt.dsl.dell.patch.gz --]
[-- Type: application/x-gzip, Size: 748 bytes --]

Re: Dell DSDT corrected

[Markus Wiesner]

Jan Slezak schrieb:
> I modified my Dell Latitude C640 DSDT table and values in /proc/acpi what were 
> previously constantly zero (or something equivalent) where brought to life. 
> This is:
> 
> - temperature in thermal zone
> - processor frequency in performance in processor (processor consumption is 
> still zero, but I belive it is not exposed to ACPI)
> - all information in battery (except presence/absence what was already working 
> before)
> 
> The DSDT patch and original DSDT are enclosed I hope it helps someone.

Yes, it does! The patch works without modification for my Inspiron 8200,
too. Great work!

Thanks,
Markus Wiesner
-- 
Never trust a man who can count to 1023 on his fingers.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Is this safe? Re: Dell DSDT corrected

[James D Strandboge]

On Wed, 2003-01-29 at 13:04, Markus Wiesner wrote:
> Jan Slezak schrieb:
> > I modified my Dell Latitude C640 DSDT table and values in /proc/acpi what were 
> > previously constantly zero (or something equivalent) where brought to life. 
> > This is:
> > 
> > - temperature in thermal zone
> > - processor frequency in performance in processor (processor consumption is 
> > still zero, but I belive it is not exposed to ACPI)
> > - all information in battery (except presence/absence what was already working 
> > before)
> > 
> > The DSDT patch and original DSDT are enclosed I hope it helps someone.
> 
> Yes, it does! The patch works without modification for my Inspiron 8200,
> too. Great work!
> 

Well, on my i8200 I had to play with it some.  First I got the dsdt from
/proc/acpi/dsdt:

iasl -d /proc/acpi/dsdt

Then I applied the patch from Jan Slezak.

Then I did:

iasl -tc ./dsdt.dsl

and had errors.  A couple were warning about not returning a value, so I
just had those return (0x0).  What was troubling was I had errors about
a Field accessing outside of the region (don't remember off hand the
exact wording, so I changed:

OperationRegion (FDIS, PCI_Config, 0xF2, 0x02)

to:
OperationRegion (FDIS, PCI_Config, 0xF2, 0x04)

I did this based on info found at:
http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt

Everything compiled without errors, and I am trying it out now, but is
this really safe?  I am the first to admit that I don't know what I am
doing with this code.  I don't want to break anything, but desperately
want acpi to work.

Jamie

PS-- Sorry you got this twice Markus-- didn't reply to list the first
time.

-- 
Email:        jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID:   26384A3A
Fingerprint:  D9FF DF4A 2D46 A353 A289  E8F5 AA75 DCBE 2638 4A3A




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Is this safe?

[James D Strandboge]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

On Thu, 2003-01-30 at 17:03, Markus Wiesner wrote:
> James D Strandboge schrieb:
> > I applied Jan's patches-- I too thought they were reasonable. 
> > Everything that worked before works again here too.  But, I tried my
> > acpi_test.sh script again, and it died at iteration 16299.  Still no joy
> > on polling battery state.  I am using acpi-20021212 since it is what I
> > had lying around.  Can you lock your machine still with my acpi_test.sh?
> 
> Kernel 2.4.20, acpi-20030122, preempt-kernel and low-latency patch:
> tried it twice, both times a lockup (after 15961 and 16293) as i already
> expected.
> 

Those patches are nice-- big improvement for me. 

> But this time the system did not "really" lockup, I suppose because of
> one of the additional patches. I could use Ctrl-c to get my command
> prompt back. "top" showed "100% system" load and grep was still running
> and unkillable (not even with -9). Disregarding the high load the system
> was still usable and i could do a normal reboot instead of using
> SysRq-Key.

That is interesting.  I am not sure what it means-- I can't really
figure out if it is BIOS/dsdt, kernel or both.  Even with debugging
enabled, I don't see any errors.  I looked at the code and battery.c and
utils.c, and it seems ok.

I poked around a bit in _BST in my dsdt (the part that generates the
state), and came across method SX30.  It looks like this:

    Method (SX30, 1, NotSerialized)
    {
        Store (SXX2, Local0) 
        Increment (Local0)
        If (LNot (LGreater (Local0, SizeOf (SXX0))))
        {
            CreateByteField (SXX0, SXX2, SX20)
            Store (Arg0, SX20)
            Store (Local0, SXX2)
        }
    }

I wonder what happens when Local0 is actually bigger than SXX0?  From
this, SXX2 and SX20 stay the same, but I don't know what the
implications of that are since there are no code comments.  Also, other
methods call SX30 without problems (seemingly), and you have seen the
lockup at earlier iterations when pulling the AC.

I am starting to understand the language of the dsdt, but it is still
hard to crack.  Look at SX11-- what does it do?  It calls SXX4, which
calls SXX6, then SXX5 (which itself calls SXX6), and so on.  I
downloaded the acpi specification and started looking at it (over 500
pages).  Maybe I will get to the bottom of it.

Jamie

-- 
Email:        jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID:   26384A3A
Fingerprint:  D9FF DF4A 2D46 A353 A289  E8F5 AA75 DCBE 2638 4A3A


[-- Attachment #2: dsdt-A04.dsl.gz --]
[-- Type: application/x-gzip, Size: 8142 bytes --]