Udalrich
Anmeldungsdatum: 15. Mai 2019
Beiträge: 525
|
Grüß' Euch zusammen. Mein zehn Jahre alter PC mit aktiviertem Legacy-BIOS-Schalter und daher Bootvorgang ohne UEFI, hat Xubuntu „20.04 LTS“ mit HWE-Kernel drauf. Bootvorgang mit den Parametern "quiet splash" in /etc/default/grub , damit beim Starten keine Meldungen ausgegeben werden, sondern nur das Xubuntu-Logo angezeigt wird. Bis zum Kernel 5.13 gab Linux beim Bootvorgang daher auch keine Meldungen aus. Doch gestern gab es eine (HWE-) Kernel-Aktualisierung auf 5.15 und seither wird folgendes beim Bootvorgang angezeigt – es war auch schon früher im Kernel-Logbuch (dmesg) drin, wurde aber beim Bootvorgang nicht gemeldet, doch jetzt schon, und das irritiert etwas:
[ 0.903439] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.903552] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.903937] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.903947] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.904007] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.904017] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.905541] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.905552] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.906117] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.906127] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT2._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.906981] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT2._GTF.DSSP], AE_NOT_FOUND (20210730/psargs-330)
[ 0.906990] ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT2._GTF due to previous error (AE_NOT_FOUND) (20210730/psparse-529) Im Kernel-Logbuch steht ein paar Takte davor noch dieses bezüglich ACPI drin, was aber auch schon bei den vorigen Kerneln drinstand und nichts mit obigem „ACPI BIOS Error (Bug)“ zu tun haben muß: [ 0.545440] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20210730/utaddress-204)
[ 0.545450] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 0.545462] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 0.545468] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 0.545474] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 0.545480] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[ 0.545491] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000051F (\LED) (20210730/utaddress-204)
[ 0.545497] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20210730/utaddress-204)
[ 0.545503] ACPI: OSL: Resource conflict; ACPI support missing from driver? a) Muß ich etwas unternehmen? Oder b) kann ich die neuerdings ausgebenen ACPI-BIOS-Fehlermeldungen (zitiert im ersten Code-Block) ignorieren? Falls b): kann man verhindern, daß beim stillen "quiet splash"-Bootvorgang diese Fehler ausgegeben werden?
|
towo2099
Anmeldungsdatum: 3. Dezember 2015
Beiträge: 315
|
a) Muß ich etwas unternehmen?
Nein. Falls b): kann man verhindern, daß beim stillen "quiet splash"-Bootvorgang diese Fehler ausgegeben werden?
loglevel=3 udev.log_level=3 in die Grub-Config malen, nach splash.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9563
|
Auf diesen "quiet splash"-Unfug gehe ich nicht ein. In einem Terminal ausführen und komplett in einem Codeblock copypasten: | sudo apt install inxi
inxi -M
|
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9563
|
towo2099 schrieb: a) Muß ich etwas unternehmen?
Nein.
Errors ignoriert man nicht.
|
towo2099
Anmeldungsdatum: 3. Dezember 2015
Beiträge: 315
|
Errors ignoriert man nicht.
Na dann, wie wäre es einfach mal eine Suchmaschine zu füttern?
Dann würdest Du sehen, dass bei diesen "Errors" nur ignorieren bleibt.
Aber naja, Du wirst es sicher lösen.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
towo2099 schrieb: Dann würdest Du sehen, dass bei diesen "Errors" nur ignorieren bleibt.
Das wäre ne noch traurigere Welt. Solche Bugs sollte man melden oder sich an entsprechende Bugreports dranhängen. Zumindest, wenn man das letzte UEFI geflasht und die proprietären microcodes des Herstellers bereits geladen hat. Warnungen hingegen kann man oftmals ignorieren, wenn einen die gar nicht effektiv betreffen. Aber auch da sollte jeder genau hingucken.
|
towo2099
Anmeldungsdatum: 3. Dezember 2015
Beiträge: 315
|
Ein Blick in den Kernel Bugtracker hätte Dir längst verraten, dass diese Errors wohl bekannt sind und die Kernel Devs daran nichts ändern können.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
towo2099 schrieb: Ein Blick in den Kernel Bugtracker hätte Dir längst verraten, dass diese Errors wohl bekannt sind und die Kernel Devs daran nichts ändern können.
Hast du nen Link?
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9563
|
towo2099 schrieb: Errors ignoriert man nicht.
Na dann, wie wäre es einfach mal eine Suchmaschine zu füttern?
Ich kenne Deine abfälligen Bemerkungen á la "Du bist nicht der einzigeste Mensch auf Erden mit diesen Meldungen." (inkl. grammatikalischem Unsinn) und nicht erst seit heute.
Aber naja, Du wirst es sicher lösen.
Ich werfe nicht nur ein "Nein." ohne jede Erklärung entgegen. Du solltest wirklich wissen, daß man Errors nicht ignoriert. Wenn es auch nach Jahren immer noch keine Lösung geben sollte, hättest Du das dem Threadstarter sagen können. Wenn es so sein sollte - aber Du kennst nicht seine Hardware, niemand hier bislang. Bei ACPI-Errors fragt man mindestens Mainboard und UEFI ab, möglicherweise gibt es eine fixende neuere Version. Vielleicht ist das Problem nicht lösbar - aber so, wie Du das machst, ist das kein Support.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Naja, eine Lösung gibt es vermutlich schon (Bootoption libata.noacpi=1, erspart auch random-freezes auf manchen Systemen). Manche Meldungen kann man getrost ignorieren, aber die enthalten normalerweise nicht PCI und ATA. Deswegen wäre es schon interessant zu verfolgen und auszumachen, ob diese Bootoption sinnvoll ist. Und ich konnte dazu auch keinen Bugreport finden, weswegen ich nach nem Link fragte.
|
Udalrich
(Themenstarter)
Anmeldungsdatum: 15. Mai 2019
Beiträge: 525
|
Danke für Eure Antworten. Wie gesagt, die Meldung wird hier erst seit Kernel 5.15 beim Starten ausgeben. Zuvor war sie zwar im Kernel-Logbuch drin, zuletzt noch unter Kernel 5.13, wurde aber nicht ausgegeben beim Starten. ~$ inxi -M
Machine: Type: Desktop Mobo: Gigabyte model: Z77X-UD3H serial: N/A BIOS: American Megatrends
v: F18 MX date: 11/01/2012 Ein neueres BIOS gibts für meinen PC seit Jahren nicht mehr, weil es ein vom PC-Hersteller verändertes „Custom“-BIOS ist und er kein neueres anbot. Der PC läuft seit zehn Jahren 100% stabil (seit ungefähr acht Jahren unter Linux), auch mit dem neuesten Kernel, der so heißt: Linux rechner 5.15.0-41-generic #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Udalrich schrieb: …Zuvor war sie zwar im Kernel-Logbuch drin…
Dann dürftest du ja mit den Gegebenheiten leben können, wenn das „schon immer“ so ist. Wenn du kein sleep verwendest und deine Platten nicht vorschnell sterben 😉 Was angezeigt wird, lässt sich auch im Kernel einstellen, zumindest wenn man diesen selbst kompiliert. Du könntest die Bootoption ausprobieren, die deaktiviert dann acpi für diesen Teil des Systems. Wenn du nur die Meldungen unterdrücken willst, geht das über das loglevel des Kernels. Aber da würde ich nur für die Optik nicht dran rumschrauben, außer ihn zum Debuggen höher setzen.
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9563
|
Udalrich schrieb:
Ein neueres BIOS gibts für meinen PC seit Jahren nicht mehr, weil es ein vom PC-Hersteller verändertes „Custom“-BIOS ist und er kein neueres anbot.
Sprich ein OEM-Mainboard. Sowas ist immer schlecht, wie Du siehst. Kann wirklich kein originales ROM geflasht werden (bspw. habe ich schon ein Asus-MB in einem MBO-Rechner eines Kd. gehabt, das EEPROM nur halbe Kapazität, da sieht man's zumindest gleich), ist da Ende. Aber man checkt das zumindest, statt alles sofort auszuschließen.
auch mit dem neuesten Kernel
...unter Jammy bzw. als HWE unter Focal. Sonst nicht. 😉
|
Udalrich
(Themenstarter)
Anmeldungsdatum: 15. Mai 2019
Beiträge: 525
|
ChickenLipsRfun2eat schrieb: Wenn du nur die Meldungen unterdrücken willst, geht das über das loglevel des Kernels.
Die genauen Loglevel zitierte Towo2099 freundlicherweise.
Aber da würde ich nur für die Optik nicht dran rumschrauben, außer ihn zum Debuggen höher setzen.
Ganz einer Meinung! Dann belasse ich das so. von.wert schrieb: [Rechner läuft stabil] auch mit dem neuesten Kernel
...unter Jammy bzw. als HWE unter Focal.
Genau. Momentan Focal-HWE; und Jammmy testete ich vom Live-Medium, lief auch gut, ist ja auch (fast) der gleiche Kernel.
Sonst nicht. 😉
Wie ist das gemeint? Würden andere, neuerere Kernel, wegen meines ACPI-BIOS-Dingens nicht stabil laufen auf meinem bewährten PC? ☺
|
von.wert
Anmeldungsdatum: 23. Dezember 2020
Beiträge: 9563
|
Udalrich schrieb:
Sonst nicht. 😉
Wie ist das gemeint?
Woanders ist 5.15 kein "neuester Kernel".
|