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