Re: [ACPI-sppt] RAMB values

Mads Paulin <[email protected]> 22 Sep 2003 17:01:24 +0200
Newsgroups gmane.linux.acpi.support
Message-ID <1064242884.1808.2.camel@M2400N>
Hi,

I was just wondering: What if we use the DSDT with the correct trip
points etc, read from bios and then hardcodes thesevalues into the dsdt
with the wrong RAMB.

Can we then have both correct fan, trip points AND display switching ?

If ye, it seems that nothing is missing (personally I don't care if the
correct values are hardcoded into the dsdt or read from bios as long as
they are correct...)

MAds


On Mon, 2003-09-22 at 14:34, Ducrot Bruno wrote:
> On Mon, Sep 22, 2003 at 11:28:53AM +0200, Robert Vollmert wrote:
> > > > As an immediate consequence, you can avoid the hang-on-reboot by
> > > > hardcoding RAMB to 0x64646464 in the DSDT (haven't tested this).
> > > > 
> > > 
> > > Another possibility is that acpi is buggy, and do not handle correctly
> > > a read of a dword from an indexed field.
> > 
> > Yes, that appears to be the case. I reported the bug on -devel. By
> > hardcoding RAMB to 0x0F75064, the thermal zone and fan control work
> > fine without other modifications.
> > 
> > The only problem left is that the computer hangs during ACPI
> > initialization, when executing \_SB.PCI0.VGA._INI. A temporary
> > work-around is to comment out the body of that method.
> > 
> 
> That method use io port 0xb2, which is a way
> to execute an obscur smi handler.  Will be hard to
> debug therefore.
> 
> btw, it is using PADL and CADL, which are fields of \RAMW
> Since now \RAMW have been corrected...



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf