ACPI-Error messages in /var/log insgesamt 104GB

[aktivemma]

Hallo alle zusammen

ich habe vor ein paar Wochen ein ALTES Notebook geschenkt bekommen, damit ich von meinem noch älteren Notebook mit meinem Server umziehen kann.

Allerdings kann ich auf dem Notebook kein System vernünftig einrichten, weil es Probleme mit dem BIOS gibt. Ich habe bereits das BIOS auf dem aktuellsten Stand.

Mein Notebook ist das "Samsung NP-P55"

Ich habe heute Debian-Testing (mit MATE) zum Laufen bekommen. Hab mich riesig gefreut, dass ein System den Bootvorgang überlebt. Die anderen Systeme haben direkt beim Booten mit einer ACPI -Fehlermeldung angehalten.

Allerdings habe ich nach vielleicht 3 Stunden Betrieb die Meldung erhalten, dass meine (120GB) Festplatte nur noch 2GB zur Verfügung hat. Als ich mich auf die Suche machte, habe ich gesehen, dass die Dateien in /var/log
kern.log
messages
syslog
alle (derzeit) genau 36.746.768.384 Bytes groß sind. ..also knapp 37GB.

Wenn ich eingebe

Code: Alles auswählen

journalctl -e

, erhalte ich wiederholt die Zeilen

...
ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L06] (20150818/evgpe-592)
ACPI Error: [\_SB.PCI0.GFX0.GSSE] Namespace lookup failure, AE_NOT_FOUND (20150818/psargs-359)
ACPI Error: Method parse/execution failed GPE [\_GPE._L06] (Node ffff88007c8a0310), AE_NOT_FOUND (20150818/psargs-542)
...

Könnt ihr mir weiter helfen? Ich schreibe Euch alles auf, was ihr dafür wissen müsst.

Ich bin nicht so bewandert in Linux-kernel-Bau und habe mich nur privat mit Linux beschäftigt und zähle daher eher zu den langjährigen Anfängern. Würde mich freuen, wenn ihr mir kleinschrittig helfen könnt. Ich lerne auch gerne dazu

LG
aktivemma

[DeletedUserReAsG]

Die anderen Systeme haben direkt beim Booten mit einer ACPI -Fehlermeldung angehalten.

Anhand von Fehlermeldungen kann man in der Regel auf den Fehler schließen und eine Lösungsmöglichkeit suchen.

Wie auch immer – wenn ACPI (erstmal) nicht zwingend benötigt wird, würde ich nun zunächst mit ›acpi=off‹ booten und schauen, was passiert. Auch würde ich erstmal Stable installieren, Fehler in Testing sind ja nicht zu unwahrscheinlich.

[aktivemma]

Hallo niemand,

vielen Dank, dass Du Dich gemeldet hast

Ich habe jetzt nicht gewusst, wie ich an die Zeilen heran kommen soll, da mir

Code: Alles auswählen

journalctl -b

nur die gleichen Zeilen angezeigt hat, die ich auch vorher schon kannte.

Also habe ich jetzt mehrere Male den Rechner neugestartet, um die beiden Zeilen abzutippen:

ACPI: EC: Fail in evaluating the _REG object of EC device. Broken BIOS is suspected.
tpm_tis … [Firmware Bug]: TPM interrupt not working, polling instead

Ich hatte mit

Code: Alles auswählen

dmesg > kernelboot.txt

auch nur die Zeilen lesen können, die ich bereits oben aufgeschrieben habe. Und es wurde in meiner kernelboot.txt dann immer mal wieder von systemd-journald Bemerkungen gemacht, dass

/dev/kmsg buffer overrun, some messages lost

Ich habe bereits mehrere Installationen ausprobiert (auch andere Distributionen). Bei Debian funktioniert die stable und die oldstable NICHT .. allerdings die oldoldstable. Das fand ich aber unbefriedigend.

Daher hoffe ich jetzt mal, dass die beiden abgeschriebenen Zeilen uns weiter helfen

[letzter3]

niemand meint, du sollst beim booten mal die Parameter acspi=off übergeben

[aktivemma]

Hallo letzter3,

da bin ich noch bei. Ich hab das noch nie gemacht und hab anhand des WWW herum gesucht und jetzt ausprobiert, mit 'e' in den GRUB-Bootloader zu kommen. Darin habe ich dann

Code: Alles auswählen

linux /boot/vmlinuz-4.3.0-1-amd64 root=UUID=... acpi=off ro quiet

stehen gehabt, NACHDEM ich "acpi=off " hinzugefügt habe. Danach habe ich F10 gedrückt. Der Bildschirm wurde schwarz. Und dabei ist es dann geblieben. Ich wollte hier noch nichts schreiben, weil ich erst mal heraus finden wollte, ob ich etwas falsch mache.

Mache ich da etwas falsch?

[aktivemma]

..ich habe im WWW nichts mehr gefunden, dass darauf schliessen lässt, dass ich beim Gebrauch von GRUB2 etwas falsch gemacht habe.

Nachdem acpi=off gesetzt wird, habe ich beim Starten nur einen schwarzen Bildschirm mit einem blinkenden Cursor in der linken, oberen Ecke.
Das System bootet dann nicht weiter.

[pepre]

Leider verwendet Samsung oft ein nicht standard-konformes BIOS. Von daher ist es schwierig bis uU unmöglich, so einen Rechner sauber booten zu lassen.

Allerdings bietet Linux eine breite Auswahl an Bootoptionen, die - ggf in Kombinationen - das booten dennoch ermöglichen. Das Ermitteln kann aber ein gutes Stück Arbeit sein, und eine Garantie kann niemand geben.

[aktivemma]

Hallo pepre,

ich würde das Samsung-Notebook gerne als Herausforderung nehmen, um mehr zu lernen. Ich würde also diese Arbeit gerne auf mich nehmen.

Als ich vor einigen Wochen mit meinen Recherchen zu dieser Fehlermeldung anfing, lief für mich alles darauf hinaus, dass man irgend etwas am kernel (oder den ganzen kernel?) selbst bauen müsste. Und vielleicht muss auch etwas anderes gemacht werden.

Ich bin hier, in der Hoffnung, dass ihr mich durch dieses Gewusel geleitet.

Ich lese auch gerne jeden ReadThisForMore-Link, den ihr mir anbietet (..zumindest innerhalb der nächsten 3 Wochen habe ich diese Zeit..)

Wenn also Du oder ihr oder andere mir sagen was ich machen muss, würde ich mich sehr freuen!

LG
aktivemma

[pepre]

Wenn also Du oder ihr oder andere mir sagen was ich machen muss, würde ich mich sehr freuen!

Den o.g. Link "Bootoptionen" ansehen. Ausprobieren. Genauere Infos zu den Optionen findest du mit jeder Suchmaschine deiner Wahl.

Leider findet sich im Netz nix, aber auch gar nix Relevantes zu deinem Samsung NP-P55. Von daher bist du auf dich allein gestellt.

Für's erste würde ich empfehlen: die Bootoption "quiet" entfernen, da siehst du dann wenigstens, an welcher Stelle der Rechner mit welcher Fehlermeldung stehen bleibt. Von da aus dann weiterhangeln...

Oder (böser Workaround aus den tiefsten Schlünden der Hölle): die Logs nach /dev/null schreiben lassen. Dann müllt es dir deine Platte nicht zu. Wenn der Rechner ansonsten läuft, dann sollte sich damit leben lassen.

[aktivemma]

In Ordnung pepre,

ich habe in den Boot-Optionen von grub2 'quiet' gelöscht und mit Ctrl-X (Strg-X) gebootet. Darauf werden mir dann in „wahnsinniger Geschwindigkeit“ immer wieder die gleichen Fehlermeldunden in (wahllos gewählter integer Wert) 30-facher Ausführung auf dem Bildschirm von den gleichen vorhergehenden bekannten Fehlermeldungen abgelöst.. Das System bootet in diesem Modus allerdings nicht weiter, sondern schmeisst nur diese Meldungen aus..

Ich werde jetzt weiter deinen empfohlenen Einstieg lesen

https://wiki.ubuntuusers.de/Bootoptione ... otoptionen

und schauen, was ich noch erreiche.. und mich dann wieder melden ..

[pepre]

Noch: falls das mit den Boot-Optionen nix hilft, dann wirst du dich damit beschäftigen müssen: https://wiki.archlinux.org/index.php/DSDT.

[aktivemma]

Auf der Seite
https://wiki.ubuntuusers.de/Bootoptionen
hab ich nichts entdecken können, was zu einer Änderung führte.

Solange ich 'quiet' in der Zeile lasse, kann gebootet werden bei verschiedenen Änderungen. Aber im laufenden Betrieb kann ich sehen, dass diese Fehlermeldung weiterhin in den log-files (/var/log/) ouput hineinschreibt.

Ich habe dann versucht, mit

Code: Alles auswählen

dmesg | grep dsdt

heraus zu finden, welche DSDT geladen ist. Aber in der /proc/acpi/ ist gar keine dsdt (!)

Da ich vorher immer innerhalb der Desktop-Umgebung MATE nachgesehen habe, ist mir eine Fehlermeldung nicht aufgefallen, die mir jetzt im Terminal alle paar Minuten geschrieben wird

systemd[1]: Failed to start journal service

Aber noch mal zurück zu dem Thema mit der DSDT. Wie komme ich denn nun an diese DSDT?

[aktivemma]

update:
Ich habe diese Seite gefunden und werde die mal abarbeiten

http://unix.privat.t-online.de/acpi.html

[aktivemma]

unter laufendem Betrieb blähen sich meine log-Datein in /var/log (kern.log, syslog) immer weiter auf, sodass ich sie immer wieder lösche.

Kann mir jemand schreiben, wie ich es einstelle, dass die Fehlermeldungen nach /dev/null geschrieben werden ?

Oder noch besser: Kann man bestimmte -also meine- Fehlermeldungen ausschalten ?

[KBDCALLS]

Eine Seite von 2006 würde ich gerade nicht viel Vertrauen entgegenbringen, schon alleine ob das alles noch so stimmt was ACPI betrifft für aktuelle Kernel. Da würde ich eher die Kerneldoku zu Rate ziehen. Da steht auch wie man den Kernel dazu überedet die DSDT Tabelle ins Ram kopiert ihm eine unterschiebt und auch kompiliert Dann wurde ich mal /proc/sys/kernel/printk ansehen. Syslog müßte man auch dazu übereden können alles nach /dev/null oder Teile dahin zu schicken. Sieh dir mal die Konfig an. Ebenso /etc/sysctl.conf

[pepre]

Kann mir jemand schreiben, wie ich es einstelle, dass die Fehlermeldungen nach /dev/null geschrieben werden?

Das kann man in /etc/rsyslog.conf einstellen. Aber unbedingt die Original-Zeilen behalten, nur auskommentieren!

Eine Seite von 2006 würde ich gerade nicht viel Vertrauen entgegenbringen

Dem kann ich nur zustimmen.

[aktivemma]

LÖSUNG
..ich habe jetzt rsyslog ausgeschaltet und deaktiviert mit

Code: Alles auswählen

systemctl stop rsyslog

und mit

Code: Alles auswählen

systemctl disable rsyslog

Dann habe ich einen Neustart gemacht, damit systemctl-journal das ganze mitbekommt (keine Ahnung, ob mein Gedankengang zu übertrieben war).

Dadurch kann ich jetzt weiterhin die Nachrichten lesen. Allerdings jetzt nicht mehr mit rsyslog, sondern mit

Code: Alles auswählen

journalctl -e

Das Problem mit dem vollschreiben meiner Festplatte ist jetzt erst mal gelöst! journalctl schreibt die Meldungen nicht auf die Platte, wenn man es nicht explizit vorgibt.

Daher würde ich fairerweise diesen Thread als GELÖST markieren.

Ich habe aber weiterhin, noch nicht die anderen Ziele erreicht. Soll ich dafür einen neuen Thread aufmachen?

[meine offenen Fragen:
1. Ich finde nichts vernünftiges, was mir verständlich erklärt, wie ich kernel zu kompilieren habe. Die Anleitungen, die ich bisher gefunden habe, sind über 10 Jahre alt. Allerdings sind es so viele, dass ich glaube, dass es auch neuere Anleitungen gibt. Habt ihr Links?
2. Ich weiß noch nicht, wie ich das DSDT-Problem/acpi-Problem lösen soll. Gibt es da eine aktuelle vollständige Anleitung? Ich suche im www und bin unzufrieden mit den Seiten gewesen, die ich hatte..]


Vielen Dank für alle bisherigen Antworten von Euch! Sie zeigen mir wenigstens schon mal den Weg, den ich einzuschlagen habe

[dirk11]

Äh ... das Problem ist doch nicht "gelöst", nur weil Du es nicht mehr siehst?!? Was ist das denn, man definiert eine Sache einfach als PAL und dann ist gut?

[aktivemma]

so war das nicht gemeint! Für mich ist das ganze noch nicht durch
Ich wollte in diesem Thread vorrangig verhindern, dass meine Festplatte vollgeschrieben wird.
Wenn ihr das auch so seht, dass der Thread weiter laufen kann, dann öffne ich den jetzt mal wieder.

Ich habe bis jetzt Folgendes gemacht:
Ich arbeite diese 4 Punkte von dieser Seite gerade ab: https://wiki.archlinux.org/index.php/DS ... t_yourself

Ich habe drei Fehler entdeckt, als ich die Datei wie in der Anleitung wieder kompilieren wollte. .. Ich muss mich eben an dem Notebook in diesem Forum einloggen und poste dann mal mit NoPaste...

[aktivemma]

alsoo ...

ich habe jetzt mit

Code: Alles auswählen

cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

die DSDT in mein /home-Verzeichnis geschrieben und mit

Code: Alles auswählen

iasl -d dsdt.dat

dekompiliert. Als ich sie dann rekompilieren wollte mit

Code: Alles auswählen

iasl -tc dsdt.dsl

hatte ich folgende Meldungen
39202


Die dekompilierte Datei dsdt.dsl könnt ihr hier sehen
39203

Ich bin ehrlich gesagt kein Programmierer. Ich kann wohl Code lesen und irgendwo auch verstehen. Würde mich freuen, wenn ihr mir sagt, was ich hier korrigieren sollte :-/

LG
aktivemma

[pepre]

Die "acpi_os_name"-Boot-Optionen hast du schon durch? Das würde ich zuerst probieren... Im dsdt findest du folgende Abfrage:

Code: Alles auswählen

If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    LINX = One
                }
 
                If (_OSI ("Windows 2001"))
                {
                    OSYS = 0x07D1
                }
 
                If (_OSI ("Windows 2001 SP1"))
                {
                    OSYS = 0x07D1
                }
 
                If (_OSI ("Windows 2001 SP2"))
                {
                    OSYS = 0x07D2
                }
 
                If (_OSI ("Windows 2006"))
                {
                    OSYS = 0x07D6
                }
            }

Also würde ich es mal mit diesen versuchen.

Zu dsdt: das ist höchst spezifisch. Das hab ich vor 20 Jahren mal gemacht, und hatte damals das Glück, dass ich nicht der Einzige mit genau diesem Mutterbrett war, und deshalb passgenaue Anleitungen fand. Ich würde mich an die Experten wenden, eine Suche nach "dsdt fix" bringt schon ein paar Treffer, und "dsdt fix samsung" auch.

[aktivemma]

Hallo pepre und alle anderen [ guten Morgen ]

ich habe die acpi_osi_name="..." -Einträge, die Du mir geschrieben hast, jetzt AUCH ausprobiert, weil sie sich von denen auf der Seite, die ich als Anleitung benutze https://wiki.archlinux.org/index.php/DSDT größtenteils unterscheiden. Ich habe auch die bereits geprüften trotzdem noch mal eingegeben.

Das ACPI-error Problem wurde damit nicht gelöst

Mit dem kernel-Paramter acpi_osi_name="Windows 2001 SP2" sah die Ausgabe ETWAS anders aus, weil nicht nach jeder ACPI-error-message stand, "Missed xx kernel messages" (xx sind Zahlen). Das eigentliche Problem blieb ansonsten bestehen.

Ich suche mal nach "dsdt fix" und "dsdt fix samsung" ... Danke, pepre.

[pepre]

Ähm, bevor das hier komplett dsdt-technisch ausartet: bei "acpi=off" bootet er ja nicht mehr. Aber du kannst nicht nur komplett ausschalten, sondern nur Teile davon, s. https://wiki.ubuntu.com/DebuggingACPI (ggf in Kombinationen). Hast du das mal probiert?

[KBDCALLS]

Sieht auch danach aus ob der Compiler die richtige Version haben muß. Habe meine mal spaßeshalber dekompiliert. Einmal mit dem Compiler von Lenny und dann dem aktuellen von Testing/unstable. Das hat schon unterschiedliche Dateien ergeben. Und bein anschließenden kompilieren wurden unterschiedliche Fehler gemeldet.

[aktivemma]

ich hatte heute morgen ein seltsames Gefühl im Bauch, weil ich mich erinnert habe, dass eine meiner Aussagen, die ich ganz zu Anfang getätigt habe, eventuell falsch war/ist.

Mir ist eingefallen, dass ich bei diesem Notebook gar nicht die älteren Debian-Versionen ausprobiert habe (sondern bei einem anderen Notebook). Ich habe daher noch mal oldoldstable, oldstable, stable installiert.

Dabei ist mir aufgefallen, dass oldstable auch noch funktioniert. Nicht nur die oldoldstable. Und da oldstable noch LongTermSupport bis 2018 hat, kann ich für einen privaten Server damit leben.

Habe hier in der oldstable (wheezy) 7.9 alles, was ich brauche. Der Lüfter wird reguliert/ausgeschaltet, die systemd-journal läuft NICHT auf beiden CPU-Kernen zu 100%-Auslastung, und ist damit ruhig, wenn er in meinem Zimmer steht - das reicht mir. Da steht natürlich die Frage im Raum, inwieweit es zu Sicherheits-Problemen führt, wenn man dieses ältere System installiert... Damit kenne ich mich nicht aus.

Damit habe ich natürlich weiterhin die Fehlermeldung beim Booten. Allerdings boote ich den Rechner eventuell zwei Jahre lang nicht mehr Das ursprüngliche Problem ist somit nicht gelöst. Ich kann mit diesem Server aber arbeiten.

Dadurch, dass ich jetzt noch durch KBDCALLS letzte Nachricht gelesen habe, dass es da zu verschiedenen Schwierigkeiten beim Kompilieren kommen kann, habe ich nicht das Gefühl, dass es mit einer sauberen DSDT jemals etwas werden könnte bei meinem Wissen. Das Handbuch zu ACPI 5.0 hatte knapp 1000 Seiten als PDF. Das werde ich nicht alles lesen wollen.

Die anderen Boot-Parameter, die pepre mir empfohlen hat (https://wiki.ubuntu.com/DebuggingACPI), werde ich trotzdem alle ausprobieren. Wenn diese mir weiter geholfen haben, werde ich das natürlich mitteilen