/var/log/messages: Firmware Error (ACPI): Could not resolve symbol ...

testit

Well-Known Member
Guten Abend!

Mehr oder weniger zufällig stellte ich heute Abend im "messages-log" meines frisch aufgesetzen FreeBSD 12.3 fest, dass dort fortlaufend folgende Fehlermeldungen auftauchen:

Dec 26 20:42:59 domain kernel: Firmware Error (ACPI): Could not resolve symbol [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20200430/psargs-503)
Dec 26 20:42:59 domain kernel: ACPI Error: Aborting method \_TZ.TZ00._TMP due to previous error (AE_NOT_FOUND) (20200430/psparse-689)
Dec 26 20:42:59 domain kernel: Firmware Error (ACPI): Could not resolve symbol [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20200430/psargs-503)
Dec 26 20:42:59 domain kernel: ACPI Error: Aborting method \_TZ.TZ01._TMP due to previous error (AE_NOT_FOUND) (20200430/psparse-689)

Hat von Euch jemand eine Idee, was die Ursache für diese Fehler sein könnte und wie ich diese abstellen kann?


Vielen Dank im voraus und nette Grüße
testit
 
Hallo :)

Wenn auf deinem System alles läuft, kannst du die Meldungen getrost ignorieren.
ACPI ist die Schnittstelle der Bios-Firmware zur Energieverwaltung zum Betriebssystem und
ist, einfach ausgedrückt, "Windows-Optimiert. Linux/BSD "kümmert sich darum und sorgt
dafür, das trotzdem alles funktioniert.
Ok, das ist meine sehr freie Interpretation, von einigen technischen Dokumentationen, die
ich gelesen habe.
Also, wenn alle Energiesparoptionen, die du benötigst, funktionieren, ist alles ok,
falls nicht, würde ich nach einem aktuellen Bios-Update Ausschau halten.

Viele Grüsse
blackbox
 
Hallo,

vielen Dank für Deine Antwort!

Ob die Energiesparoptionen wie gewünscht funktionieren, kann ich nicht beurteilen, da es sich um einen dedicated-Server handellt, der nicht vor mir steht.

Offen gesagt, bin ich auch nicht so glücklich damit, dass mir das "messages"-Log dadurch fortlaufend vollgemüllt wird.

Viele Grüße
testit
 
Guten Abend!

Mehr oder weniger zufällig stellte ich heute Abend im "messages-log" meines frisch aufgesetzen FreeBSD 12.3 fest, dass dort fortlaufend folgende Fehlermeldungen auftauchen:
Hallo,

vielen Dank für Deine Antwort!

Ob die Energiesparoptionen wie gewünscht funktionieren, kann ich nicht beurteilen, da es sich um einen dedicated-Server handellt, der nicht vor mir steht.

Offen gesagt, bin ich auch nicht so glücklich damit, dass mir das "messages"-Log dadurch fortlaufend vollgemüllt wird.

Viele Grüße
testit
Moin,

gibt es einen Grund, warum du bei einer Neuinstallation 12.3 nimmst und nicht 13.0? In den RELEASE-NOTES steht zwar nicht sehr viel zu ACPI, dennoch sind die Chancen bei einem älteren RELEASE wohl kaum besser, dass Dinge "besser" funktionieren. Unabhängig davon sagt ACPI(4):

ACPI(4) schrieb:
To disable the acpi driver completely, set the kernel environment
variable hint.acpi.0.disabled to 1.

Evtl. wird dadurch auch das Logging deaktviert. Vermutlich gibt es noch weitere Möglichkeiten, das Protokollieren zu beeinflussen.

HTH
 
Moin,

gibt es einen Grund, warum du bei einer Neuinstallation 12.3 nimmst und nicht 13.0? In den RELEASE-NOTES steht zwar nicht sehr viel zu ACPI, dennoch sind die Chancen bei einem älteren RELEASE wohl kaum besser, dass Dinge "besser" funktionieren.

ÄLTER?
12.3 erschien vor wenigen Tagen!

Ich habe in VMs FreeBSD 12.X als Guests laufen und taste in diesen stets erst einmal vor, wie sich Upgrades usw. auswirken, bevor ich den Host damit beglücke. Daher halte ich die Versionen auf dem gleichen Stand.

Unabhängig davon sagt ACPI(4):
variable hint.acpi.0.disabled to 1

Evtl. wird dadurch auch das Logging deaktviert. Vermutlich gibt es noch weitere Möglichkeiten, das Protokollieren zu beeinflussen.

Tja, das hatte ich eben auch schon bei meiner Recherche gefunden und in die loader.conf eingetragen.
Ergebnis: Rechner nach dem Booten nicht mehr beim Provider erreichbar!

Viele Grüße
testit
 
ÄLTER?
12.3 erschien vor wenigen Tagen!

Ich habe in VMs FreeBSD 12.X als Guests laufen und taste in diesen stets erst einmal vor, wie sich Upgrades usw. auswirken, bevor ich den Host damit beglücke. Daher halte ich die Versionen auf dem gleichen Stand.
Das Erscheinungsdatum hat damit nichts zu tun. 13.0 ist imho aktuell das RELEASE, das du bei einer Neuinstallation verwenden solltest. Zu viele Änderungen fließen nicht nach 12.x zurück. Da es ohnehin eine Neuinstallation ist, würde ich erst einmal testen, ob das Problem damit immer noch auftritt. Immerhin war 13.0 eines der (wenn nicht sogar das) Release(s), mit den meisten Änderungen.

Bezüglich des Bootproblems drücke ich die Daumen. Prüfe mal, ob du nicht einen Schreibfehler eingebaut hast. Mir ist da schon einfach zu oft das System hängen geblieben, weil ich ein " vergessen oder zu viel hatte. :)
 
Hallo!

Vielen Dank für Deine Hinweise!

Einen Schreibfehler habe ich nicht "verbockt", aber die Nutzung von
hint.acpi.0.disabled=1
scheint eine riskante "Nummer" zu sein:


Mal schauen, was ein BIOS-Update bringt.

Viele Grüße
testit
 
Das Erscheinungsdatum hat damit nichts zu tun. 13.0 ist imho aktuell das RELEASE, das du bei einer Neuinstallation verwenden solltest. Zu viele Änderungen fließen nicht nach 12.x zurück. Da es ohnehin eine Neuinstallation ist, würde ich erst einmal testen, ob das Problem damit immer noch auftritt. Immerhin war 13.0 eines der (wenn nicht sogar das) Release(s), mit den meisten Änderungen.

Bezüglich des Bootproblems drücke ich die Daumen. Prüfe mal, ob du nicht einen Schreibfehler eingebaut hast. Mir ist da schon einfach zu oft das System hängen geblieben, weil ich ein " vergessen oder zu viel hatte. :)

Hallo!

Ein BIOS-Update ist wohl nicht möglich, da es sich wohl um die letzte Version handelt.

Ich habe daher FreeBSD erneut installiert, dieses Mal die 13er!
Leider wird dadurch das eingangs beschriebene Problem mit den Fehlermeldungen
Could not resolve symbol [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND
nicht gelöst.

Viele Grüße
testit
 
NACHTRAG:
Es handelt sich um ein Problem, das vorwiegend bei bestimmten BIOS/Fujitsu-Mainboardkombinationen auftaucht!
Interessanterweise offenbart sich das Problem auch i. d. R. bei Unix-Derivaten, nicht bei Systemen mit MS OS.

Erklärung:
12.17.5 Fixing Your ASL

In the long run, the goal of FreeBSD is for almost everyone to have working ACPI without any user intervention. At this point, workarounds are still being developed for common mistakes made by the BIOS vendors. The Microsoft® interpreter (acpi.sys and acpiec.sys) does not strictly check for adherence to the standard, and thus many BIOS vendors who only test ACPI under Windows® never fix their ASL. FreeBSD developers continue to identify and document exactly what non-standard behavior is allowed by Microsoft's interpreter and replicate it so FreeBSD can work without forcing users to fix the ASL. As a workaround, and to help identify behavior, fix the ASL manually. If this works, send a diff(1) of the old and new ASL so developers can possibly work around the buggy behavior in ACPI-CA and thus make the unnecessary fix.

Here is a list of common error messages, their cause, and how to fix them:
...

Quelle: https://people.freebsd.org/~blackend/en_US.ISO8859-1/books/handbook/ACPI-debug.html

Die fortlaufenden Error-Meldungen unter /var/log/messages konnte ich durch folgenden Eintrag in der loader.conf abstellen:

debug.acpi.disabled="thermal"

Die Frage ist allerdings, wie sich das debug.acpi.disabled="thermal" nun auswirkt?
Laufen die Lüfter nun permanent unter Vollast? Oder zu wenig?

Wie alt das Problem ist, lässt sich u. a. folgendem Beitrag aus dem Jahr 2012 entnehmen, der sich damit beschäftigt, wie man bei BSD ACPI am besten gleich komplett deaktiviert (Server).

Allerdings wird in diesem Beitrag u. a. auch das von mir o. a.
hint.acpi.0.disabled=1
genutzt, das bei mir dazu führte, dass ich den Server nicht mehr booten konnte.

Viele Grüße
testit
 
Zurück
Oben