public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* [ACPI-sppt] summary of ASUS M2N strangeness
@ 2003-09-21 17:51 Robert Vollmert
  0 siblings, 0 replies; only message in thread
From: Robert Vollmert @ 2003-09-21 17:51 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
  Cc: acpi-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Hello,

here's a summary of what's been found out about the ASUS M2N and
related models. I'm posting here hoping that the experts have some
advice. Sorry for posting to both lists, but I thought there might be
people only on -support that are interested.

There's two somewhat different cases: (1) when the computer has been
off for a while (>5min) after having used Windows, and (2) when not.

Some relevant excerpts from the original DSDT are:

OperationRegion (BIOS, SystemMemory, 0x1F750064, 0xFF)
Field (BIOS, ByteAcc, NoLock, Preserve)
{
    SS1,    1,
    SS2,    1,
...
}

OperationRegion (\ECMS, SystemIO, 0x72, 0x02)
Field (\ECMS, ByteAcc, Lock, Preserve)
{
    EIND,   8,
    EDAT,   8
}

IndexField (EIND, EDAT, ByteAcc, NoLock, Preserve)
{
    Offset (0x10),
    IKFG,   8,
    FRPN,   16,
    RAMB,   32,
...
}

OperationRegion (\RAMW, SystemMemory, RAMB, 0xFF)
Field (\RAMW, ByteAcc, NoLock, Preserve)
{
    Offset (0xB0),
...
    TSAD,   8,
...
} 
 
In cases (1) and (2), the DSDTs are identical, except for the above
first line, where in case (2), 0x1F750064 is replaced by 0x0F750064.

In case (1), the computer boots successfully, but ACPI only works
partially due to RAMB having been evaluated to 0x64646464, while the
correct value (as read via 0x72 after booting and verified by a
correct value for TSAD) is 0x0F750064.

In case (2), the computer hangs during ACPI initialization (executing
all _STA and _INI).

I haven't verified what RAMB evaluates to in case (2). However,
hardcoding the correct value doesn't make a difference, so I assume
it's correct.

I don't need help debugging the hanging in case two yet. What I was
wondering is whether it's common for the BIOS to provide different
DSDTs in different circumstances, i.e. that the 0x1F750064 is there on
purpose, or is this likely to be a bug? 

Secondly, in case it is indeed a bug, is it likely that the fact that
RAMB evaluates to 0x64646464 is caused by this, or is this a separate
issue?

Thanks for any input.

Cheers
Robert


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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-09-21 17:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-21 17:51 [ACPI-sppt] summary of ASUS M2N strangeness Robert Vollmert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox