[haiku-commits] Re: r41402 - haiku/trunk/src/system/kernel/arch/x86
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 09 May 2011 22:27:26 +0200
> 2011/5/9 Michael Lotz <mmlr@xxxxxxxx>:
> > In principle giving it more exposure would be great. I'd like to
> > wait a
> > bit until some "early-adopters" can give it a try with various
> > configurations though. I'm afraid we'll have to implement some kind
> > of
> > ACPI cut-off date, blocking the use of ACPI for BIOSes dated
> > earlier,
> > because from what I've read there definitely are a lot of plain
> > broken
> > ACPI BIOSes around. Also some specific systems may need to be
> > blacklisted. In any case I'm in favor of enabling the IO-APIC by
> > default
> > after a short cool-down phase, let's say one or two weeks from now,
> > depending on how much feedback comes in.
>
> I looked into this a lot before enabling ACPI by default. There are a
> lot of broken ACPI implementations out there. Many problems arise
> because MS and ACPICA's implementations are different.
> Most are simple bugs, returning the wrong type, not returning
> anything
> and similar things.
> ACPI-CA however has countered this by trying to handle most of these
> situations.
> They list a lot of these problems in their changelog:
> http://www.acpica.org/download/changes.txt
>
> Many comments in Linux and FreeBSD are probably from a time when
> ACPICA was not so forgiving.
> Hopefully it won't be that serious for us.
Yes I realize that, but that's not really my point here. My concerns
are regarding setups where the routing tables aren't implemented
properly or don't actually describe what's physically there. If it is
outright broken and doesn't work at all so already the enumeration will
fail that's not so much of a problem, as we'll just fall back to PIC
mode. But if the information contained is incorrect we don't really
have any way to verify that and fall back. Under Windows they can just
supply a driver that masks the problem, but for us it's kinda
problematic. So I'm inclined to just avoid it completely by not using
IO-APICs on such configurations. The FreeBSD cut-off date mechanism
seems easy enough in that regard:
http://fxr.watson.org/fxr/source/i386/acpica/acpi_machdep.c#L90
Regards
Michael
Other related posts:
