ubuntuusers.de

ACPI Problem (acpi-bug) mit NoteBook Compal EL80

Status: Ungelöst | Ubuntu-Version: Ubuntu 10.04 (Lucid Lynx)
Antworten |

SilverMoon

Anmeldungsdatum:
30. Juni 2009

Beiträge: 56

Hallo Experten,

vielleicht könnt Ihr mich bei der Suche nach einer Lösung eines von mir vermuteten ACPI-Bugs unterstützen.

Problem: Rechner bootet nicht ohne Zusatz acpi=off bzw. acpi=ht, d.h. der Rechner friert ohne diese System-Boot-Paramter sporadisch und somit leider nicht reproduzierbar ein. Manchmal kann ich mich noch anmelden, oftmals ist es aber bereits in der Boot-Phase vorbei.

Die unter http://www.lesswatts.org/projects/acpi/debug.php dargestellten Boot-Optionen habe ich getestet und lediglich mit acpi=off und acpi=ht finden dauerhaft keine freezes statt. Nur mit diesen Parametern muss ich auf einige Dinge verzichten, die gerade bei einem Notebook ganz hilfreich sind (Akku-Stand, automatisches Suspend, bei kritischem Akku-Stand u.ä.), so dass ich dieses Problem gerne gelöst bekäme.

Nach langem googeln war mein nächster Versuch nun (ob nützlich oder nicht ... keine Ahnung), ob ich über Informationen hinsichtlich der DSDT Tabelle mit dem Problem weitekomme. Somit habe ich das unter acpi-fix dargestellte Procedere

sudo acpidump -t DSDT -o dsdt.dat -b
iasl -d dsdt.dat
iasl -sa dsdt.dsl

durchgeführt (ja - das "Achtung!" ganz oben habe ich gelesen - mir gings ja nur um die folgende Ausgabe), mit dem Ergebnis:

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 33 Optimizations

Tja - und nun weiss ich nicht mehr weiter - wenn hier ein Fehler oder eine Warnung gekommen wäre, dann hätte man vielleicht einen weiteren Anhaltspunkt, aber so ...?

Nun bin ich mit meinem Latein am Ende und hoffe auf Eure Hilfe!

Vielen Dank im Voraus für alle hilfreichen Antworten, viele Grüße

SilverMoon

P.S.: Vielleicht bringt dem ein oder anderen von Euch der Original Table Header der DSDT noch brauchbare Infos:

 * Original Table Header:
 *     Signature        "DSDT"
 *     Length           0x00004C92 (19602)
 *     Revision         0x01 **** ACPI 1.0, no 64-bit math support
 *     Checksum         0xA7
 *     OEM ID           "Compal"
 *     OEM Table ID     "CALISTGA"
 *     OEM Revision     0x06040000 (100925440)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20050624 (537200164)

agaida

Avatar von agaida

Anmeldungsdatum:
24. Februar 2010

Beiträge: 3348

Wohnort: Bielefeld

Hi, eine Lösung hab ich nicht, aber eine kleine Reihe weiterer Optionen. Dass Du ganz ohne acpi oder nur mit Hyperthreading nicht ganz glücklich bist, kann ich nachvollziehen, grade auf einem NB. Versuch doch einfach mal die Option nolapic_timer als einzige Option, wenn das Teil damit beim Booten nicht hängen bleibt, hat Du eigentlich schon gewonnen. Ab dem Punkt könnte man noch feiner schrauben.

SilverMoon

(Themenstarter)

Anmeldungsdatum:
30. Juni 2009

Beiträge: 56

Hallo agaida!

Vielen Dank für Deinen Vorschlag! Das sieht in der Tat echt gut aus: 👍 Im Moment bin ich mit diesem Parameter bei einer Uptime von über 2 Stunden - sonst nur mit den benannten Parametern möglich. Was genau bewirkt nolapic_timer und was meinst Du mit "feiner" schrauben?

In jedem Fall gefällt mir, was da gerade passiert ... 😉

Besten Dank für Deine Hilfe und viele Grüße

SilverMoon

agaida

Avatar von agaida

Anmeldungsdatum:
24. Februar 2010

Beiträge: 3348

Wohnort: Bielefeld

Google ist dein Freund. So nur in aller Kürze:

* lapic - http://linux.about.com/cs/linux101/g/lapic.htm // http://en.wikipedia.org/wiki/Intel_APIC_Architecture * nolapic_timer - eben das, was da steht. Der Timer wird aus dem lapic rausgenommen. Funktionierte in 90% aller Fälle für mich 😊 4 Rechner @home, 4x schwarzer Schirm, nolapic_timer hat gewirkt. Bei insgesamt 15 moderneren Maschinen mit Problemen eingesetzt, 2x hat es nicht gefunkt. Deshalb immer, bevor ich bei den von Dir beschriebenen Problemen anfange, wirklich nachzudenken, dieser Versuch. Das grenzt die Anzahl weiterer möglicher Fehler drastisch ein. Eine wirkliche Lösung kann das meiner Meinung nach nicht sein, denn dann bräuchte ich ja keinen optionalen Parameter. Bis dahin...

Bis ich mich zu diesem Punkt durchgekämpft hatte, waren aber schon einige Tage vergangen. Der "Scheiss" hat irgendwie für mich im Januar oder Februar mit einem neuen Kernel angefangen, ich weiss die Version nicht mehr. Irgenwann habe ich auf Google dann die selbigen Probleme und die erst mal einfache Lösung gefunden. Meine Kernel-line bei Ubuntu sieh jetzt ungefähr so aus:

Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-22-generic root=/dev/disk/by-label/ub64_root ro pci=use_crs nopat lapic nolapic_timer nomodeset elevator=deadline

Ob das alles so sein muss, sei dahingestellt, auf jeden Fall läuft die Kiste stabil und responsiv. Das Beste aber ist, dass die restlichen APIC-Funktionalitäten ohne Murren funktionieren. Der Ansatz von Dir, wärst Du weitergegangen, wäre das Problem aus der anderen Richtung angegangen. Wir schalten erst einmal alles aus und schalten Funktionalitäten der Reihe nach wieder ein. So find ich das irgendwie geiler.

Antworten |