Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2003 10:51:05 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Joel M. Baldwin" <qumqats@outel.org>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: bad ACPL asl's on motherboards
Message-ID:  <3E26FF19.77C7600E@mindspring.com>
References:  <98766849.1042697265@[192.168.1.20]>

next in thread | previous in thread | raw e-mail | index | archive | help
"Joel M. Baldwin" wrote:
> I gather that there are quite a few Motherboards with bad ACPI asl's
> on them.  I know that my Abit BP6 sure has problems.  As a result I
> can't run ACPI.
> 
> What are those of us with these motherboards supposed to to?
> 
> I realize that we can use acpidump to get the asl, correct it,
> and then recompile it using iasl from the acpicatools port, to
> generate the aml that can be used during boot.

There are several things you can do, one of which is what you
have suggested, though you do not go far enough:

1)	Correct the ASL, make a file modification so that
	FreeBSD can run on the system with the incorrect
	ASL, and then *notify the motherboard and BIOS
	vendors of the correction, and the reason for it*.

2)	The ASL works *fine* with the Windows ACPI code;
	*correct* the FreeBSD code so that it *also* works
	fine for FreeBSD (i.e. if the FreeBSD code were a
	line-for-line duplicate of the Windows code, then
	FreeBSD would not be having these problems, where
	Windows does not, would it...).

3)	Find a way to detect these failure modes and, if
	they are detected, fall back to the pre-ACPI code
	that FreeBSD used to use; it's in the source tree,
	after all.

But all of these require that you *do* something.  Personally,
I've been following option #1; there's also a "1(B)" that you
could add, which is to inform the project of the modified ASL,
which would also require:

i)	providing some method of identifying the motherboard
	and BIOS revisions, and therefore the need for the
	code (the same identification required in #3

ii)	donate this code to the FreeBSD project

IMO, this approach is counter-productive, and undermines #2,
which is, I think, the correct approach ("Be strict in the
data you create, and liberal in the data you accept").

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E26FF19.77C7600E>