linux > amnesie schrieb am 9. Juli 2007 10:41
> >
> > Wo hat Microsoft denn die Hersteller-Fehler ausgebügelt?
>
> Wie man hört, hat deren ACPI-Interpreter auch Dinge akzeptiert, die
> eigentlich gegen die Spezifikation waren.
Und das war die Folge schlechter ACPI-Implementierungen? Oder doch
die Ursache für schlechte ACPI-Implementierungen? Vielleicht hat das
auch überhaupt nichts miteinander zu tun und es lag mehr am
ACPI-Compiler, z.B. dem von Microsoft?
> > Die
> > Hersteller haben “ACPI”-Treiber” zusammen mit den Chipsatz-Treibern
> > ausgeliefert (natürlich nur für die halbwegs aktuellen
> > Windows-Versionen), wenn die nicht installiert wurden und es mit dem
> > Standard-Windows-Treiber auch nicht funktionierte, gab’s halt gar
> > keine ACPI-Funktion unter Windows.
>
> Zum Booten verlässt sich das OS erstmal auf ACPI, um gewisse Dinge zu
> regeln (Interrupt-Routing usw). Wenn da ein Bug drin ist, kannst es
> auch kaum mehr noch per ACPI-Patch überbügeln. Daher musste Windows
> ziemlich tolerant arbeiten, um auch noch ein kaputtes ACPI (im BIOS)
> so zu interpretieren, daß die Kiste hochkam.
Das es zumindest reichen muss, um unter Windows die Chipsatz-Treiber
installieren zu können, ist klar, soweit musst Windows tolerant sein.
Wenn Du dann aber noch Powersafe-Modi haben willst, ist ohne
Chipsatz-Treiber Schluss. Dass man per Treiber noch so einige
Probleme im BIOS verbaute ACPI-Probleme umgehen kann, hat die
Linux-Gemeinde bewiesen, die z.B. durch Nachladen gepatchter DSDTs
kaputte ACPI-Implementierungen doch noch gangbar gemacht haben.