Bug verursacht Kernel-Panic und Neustart

Macke1979

Macke1979

FreeBSD-User
Vor einigen Tagen stolperte ich das erste Mal über einen Kernel-Panic, der einen Neustart verursachte. Die Meldung lautete: panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe015cdd0000 Diese trat auf, wenn ich ein paar meiner Games mittels wine (welches ich mittels lock auf Hold gesetzt habe) zu zocken wünschte. Da ich aber länger nicht gezockt habe, hatte ich inzwischen den relevaten ZFS-Schnappschuss vor dem fraglichen Upgrade gelöscht, weshalb ich nicht mehr zurückkonnte (das war mir eine Lehre, in Zukunft probiere ich die wichtigste Software zunächst in dem entsprechenden Boot-Environment ausführlich aus). Mir kam der Verdacht, dass es sich um einen Hardwarefehler handelte (was ja bei einem Kernel-Panic nicht selten der Fall ist)... Also überprüfte ich mein RAM mittels memtest86 wobei kein Fehler gefunden wurde und überprüfte den Status meines Zpools mit zpool scrub und anschließendem zpool status -v wobei ebenfalls kein Fehler gefunden wurde. Einen Defekt von CPU und GPU wollte ich zunächst ausschließen (PC schließlich erst Anfang des Jahres gekauft, wäre aber halt noch Garantie drauf gewesen und ich hätte von meinem Händler auf jeden Fall Ersatz bekommen). Also beschloss ich (bevor ich hier im Forum frage) eine Neuinstallation meines Systems. Ich spielte mit meinem Stick FreeBSD-14.0 drauf und machte anschließend das Upgrade auf 14.1 wobei alles reibungslos verlief. Ich installierte meine sämtliche Software, die ich für den Alltagsbetrieb benötige und wine sowie meine über GOG bezogenen Games zuletzt. Der Fehler trat nicht wieder auf... So lange, bis ich von quartelry auf latest umstellte, da war haargenau dasselbe Problem wieder da. Dieses Mal hatte ich natürlich noch ein altes Boot-Environment, welches ich zurückspielte und somit wieder auf quarterly wechselte... Ihr ahnt es schon... Das Problem ist keins mehr, die Software läuft wie eh und je, ohne Neustart und Kernel-Panic... Also gehe ich mal davon aus, dass es sich um einen Bug in einem der Pakete handelt, die mit der Umstellung auf latest aktualisiert wurden (277 Pakete, wenn ich mich recht erinnere)... Ich bin mal gespannt, ob das Problem im nächsten Quartal gefixt wird (und ich wieder auf latest zurückgehen werde, dann werde ich jedoch definitiv den alten Schanppschuss samt Boot-Environment zunächst behalten). Hat jemand ähnliches erlebt? Mich würde mal interessieren, welches Paket diesen Fehler verursacht.
 
Evtl. müsste man da mal einen näheren Blick aufs "Panic" werden. Evtl. gibt ein Blick in den Crash-Dump verwertbare Infos.
Ein spontane Idee wäre, das der Grafiktreiber aus latest den Kernel-Panic provoziert.
 
Code: 
root@freebsd:~ # cat /var/crash/info.0
Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 1358856192
  Blocksize: 512
  Compression: none
  Dumptime: 2024-06-19 11:49:59 +0200
  Hostname: freebsd
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC
  Panic String: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe017ba36000
  Dump Parity: 2415340624
  Bounds: 0
  Dump Status: good
root@freebsd:~ #
Zumindest sind die Dateien in /var noch vorhanden. Ich vermag allerdings nicht wirklich etwas damit anzufangen und da ich keinen Debugger für den Kernel installiert habe, dürfte es schwierig sein, die Fehlerquelle zuverlässig zu lokalisieren. Ich bin echt mal gespannt, was im nächsten Quartal passiert. Sollte da der Grafiktreiber (ich verwende amdgpu) oder drm-kmod ein Update bekommen, werde ich die zunächst vorsichtshalber auf Hold setzen und sehen, was geschieht.
 
Macke1979 schrieb:
und da ich keinen Debugger für den Kernel installiert habe, dürfte es schwierig sein, die Fehlerquelle zuverlässig zu lokalisieren.
Zum Vergrößern anklicken....
Gut. Den könnte man ja nachinstallieren.
Muss man halt entscheiden, wie wichtig es einem ist, dem Fehler auf den Grund zu gehen. Und möglicherweise gibts ja tatsächlich irgendwo ein ernsthaften Bug den man ggf. auch melden könnte.

Macke1979 schrieb:
Sollte da der Grafiktreiber
Zum Vergrößern anklicken....
Was man natürlich zur Eingrenzung machen könnte ist, nur den Grafiktreiber auf lastest zu aktualisieren bzw. alles andere außer den Grafiktreiber auf lastest anzuheben und gucken, wie sich das dann mit dem Crash verhält.
 
Gleich vorweg: Ich konnte denselben Bug seltsamerweise nicht noch einmal repoduzieren. Dennoch...
Andy_m4 schrieb:
Was man natürlich zur Eingrenzung machen könnte ist, nur den Grafiktreiber auf lastest zu aktualisieren bzw. alles andere außer den Grafiktreiber auf lastest anzuheben und gucken, wie sich das dann mit dem Crash verhält.
Zum Vergrößern anklicken....
Ich habe mir ein Boot-Environment zum Testen eingerichtet und dort von quarterly auf latest gewechselt. Ich habe mich zunächst vergewissert, welche Pakete aktualisiert werden und bin zu dem Schluss gekommen, dass ich zunächst die Pakete drm-515-kmod sowie mesa-dri und mesa-libs auf Hold setzen sollte und diese dann nacheinander mit unlock wieder entriegeln. Meine Erwartung war, dass eines dieser Pakete den Kernel-Panic auslösen wird. Dies war jedoch nicht der Fall, trotzdem verursachen die beiden Pakete mesa-dri und mesa-libs (auch wenn eines von beiden auf Hold gesetzt wurde) plötzlich extreme Performance-Probleme, mit dem Ergebnis, dass sich selbst XFCE nicht mehr vernünftig bedienen lässt. Zugleich gibt es keinen Unterschied, wenn drm-515-kmod aktualisiert wird. Auch wenn pkg upgrade ganz normal ohne lock ausgeführt wird, kommt es nicht mehr zu dem Kernel-Panic. Dennoch stimmt mit den Mesa-Paketen offensichtlich etwas nicht, während mit quarterly alles ganz normal funktioniert wie eh und je. Weiß auch nicht, was das war.
 
Schaue mal, ob in /var/crash eine panic.txt liegt. Das ist der extrahierte Crashdump und würde einiges mehr an Informationen geben. Ich sage aber schon vorweg, dass man wahrscheinlich nicht allzu viel erkennen wird. Denn 'vm_fault_lookup: fault on nofault entry' ist ein Hinweis auf Speicherkorruption. Tatsächlich sind der absolute Großteil aller Panics Formen von Speicherkorruption und solche ist immer sehr schwer zu debuggen, da sich oft kaum mehr herausfinden lässt, was exakt sie herbeigeführt hat. Unabhängig vom Betriebssystem. Einer der Gründe, warum die Zukunft eher bei speichersicheren Sprachen wie Rust als beim Klassiker C liegen dürfte.

Wenn man das wirklich debuggen will, wäre das Vorgehen grob:

1. Sicherstellen, dass die Hardware okay ist. Das hast du mit memtest86 schon gemacht.
2. Schauen, ob man im Crashdump Hinweise auf den Verursacher findet.
3. Mit dem Wissen einen sicheren Weg zum Reproduzieren sichen. Den hast du glücklicherweise schon.
4. Das in einen Bugreport auf bugs.freebsd.org gießen.
5. Wenn es keine Reaktion gibt, nach 7 bis 14 Tagen auf der jeweiligen Mailingliste oder dem Teilprojekt (hier eventuell DRM) nachhaken.
 
Yamagi schrieb:
Schaue mal, ob in /var/crash eine panic.txt liegt.
Zum Vergrößern anklicken....
Ist nicht vorhanden und es ist auch kein Debugger installiert. Jetzt bekomme ich allerdings keine Kernel-Panic mehr, stattdessen verlangsamen die Mesa-Pakete mein System enorm.
Yamagi schrieb:
4. Das in einen Bugreport auf bugs.freebsd.org gießen.
Zum Vergrößern anklicken....
Meinst du, ich sollte das Problem mit mesa-dri und mesa-libs als Bugreport melden?
 
So, das Quartal ist um. Und ich musste feststellen, dass nach dem großen Upgrade besagter Bug doch wieder auftritt, allerdings nicht jedes Mal, sondern nur sporadisch. Schuld ist offensichtlich der Grafiktreiber, also drm-515-kmod den ich demzufolgen erneut auf Hold gesetzt habe. Bevor ich gedachte, den Bugreport zu melden, schaute ich mir zunächst bereits vorhandene Reports im Bezug auf den Grafiktreiber an... Und wurde fündig. Klick mich Dies scheint der Bug zu sein, der bei mir aufgetreten ist, das Problem ist offenbar noch nicht gelöst. Ich habe nun wieder auf latest gewechselt, weil es leichter sein dürfte, etwaige Bugs nach einem Update einzugrenzen, wenn man diese allmählich bekommt und nicht wie bei quarterly mehrere hundert Pakete auf einmal.
 
Hast du mal drm-5.10 probiert. Da habe ich mit meiner rx570 keine Probleme. Oder ab FreeBSD 14.1 drm-61 . Das habe ich aber nur mit Intel Grafik am laufen
 
Macke1979 schrieb:
Der Fehler trat nicht wieder auf... So lange, bis ich von quartelry auf latest umstellte, da war haargenau dasselbe Problem wieder da.
Zum Vergrößern anklicken....
Auch, wenn Dir das nicht wirklich weiterhilft, warum hälst Du Dein System nicht auf quarterly, um derartige Probleme zu vermeiden?

Nur deswegen?
Macke1979 schrieb:
wenn man diese allmählich bekommt und nicht wie bei quarterly mehrere hundert Pakete auf einmal.
Zum Vergrößern anklicken....
Ich zocke auch gerne mal Spiele mit wine. Deshalb würde ich gerne mal fragen, welche von GOG bei Dir funktionieren? Welche Version von wine hast Du aktuell?
 
serie300 schrieb:
Hast du mal drm-5.10 probiert.
Zum Vergrößern anklicken....
drm-510-kmod funktioniert zwar, führt aber bei mir zu einer offenbar höheren GPU-Auslastung und läuft einen Tacken langsamer, das gefällt mir nicht. Und drm-61-kmod ist derzeit weder in den Packages noch in den Ports verfügbar. Ich finde es aber auch nicht schlimm drm-515-kmod per lock auf Hold zu setzen. Die Welt geht deshalb ja nicht unter.
cabriofahrer schrieb:
Auch, wenn Dir das nicht wirklich weiterhilft, warum hälst Du Dein System nicht auf quarterly, um derartige Probleme zu vermeiden?
Zum Vergrößern anklicken....
Hatte ich ja, in der Hoffnung dass der Fehler behoben wird (um dann wieder auf latest zurückzukehren) aber nachdem das Groß-Upgrade für quarterly kam war trotzdem auch der Bug wieder da. Also wäre das Problem damit eben nicht vermieden. Mit latest fühle ich mich insofern wohler, weil wenn tatsächlich mal etwas schiefgeht, wäre es damit viel leichter das betreffende Paket zu lokalisieren, als wenn ich jedes Quartal ein Groß-Upgrade mit mehreren hundert Paketen eingespielt bekomme. Ich nutze bei jedem Upgrade die ZSF-Snapshots zusammen mit den Boot-Environments, so dass ich wenn es mal irgendwo hakt auf einen früheren Stand zurückgehen kann. ;)
cabriofahrer schrieb:
Ich zocke auch gerne mal Spiele mit wine. Deshalb würde ich gerne mal fragen, welche von GOG bei Dir funktionieren? Welche Version von wine hast Du aktuell?
Zum Vergrößern anklicken....
Ich bin eher der Gelegenheits-Zocker der hin und wieder mal zur Entspannung (und aus Nostalgie-Gründen) ein Spiel zockt, welches mich an gute alte Zeiten erinnert, als die Welt noch in Ordnung war. Derzeit sind das die (ziemlich alten) D&D-Titel Neverwinter Nights, Neverwinter Nights II und Icewind Dale II. Bei mir kommt Wine 8 zum Einsatz, den ich ebenfalls mittels lock auf Hold gesetzt habe, weil ich mir ziemlich sicher bin, dass ein Upgrade auf eine neue Wine-Version dazu führen wird, dass ich die ganzen Spiele erneut installieren müsste.
Andy_m4 schrieb:
Das kann man im Prinzip probieren. Soweit ich weiß, ist das aber noch nicht in den Packages.
Man muss dann also über die Ports gehen (und falls man die noch nicht hat, auf den Rechner ziehen).
Da das ein Kernel-Modul ist, wird man zum bauen die (Kernel-)Sources brauchen.
Zum Vergrößern anklicken....
Das Paket drm-61-kmod ist derzeit nicht einmal in den Ports verfügbar, ist aber auch kein Drama. Mit den Ports bin ich sehr vorsichtig (mag die ungern mit Paketen mischen, wegen der Gefahr von Inkonsistenzen im System), die habe ich bislang nur für libdvdcss benutzt, weil ich diese Library nun einmal brauche (nutze den PC als Alltagsgerät und mag auch gern hin und wieder mal DVDs schauen) und es davon aus rechtlichen Gründen kein Package gibt.
 
Nur um Begriffsverwirrung vorzubeugen - mit Ports meinst du die Packages oder /usr/ports/graphics/drm-61-kmod ? Ich hab's am 04. Juni mit make in den Ports gebaut. Wie gesagt für 14.1. und laufen tut's auf diesem aLaptop mit Intel Iris Grafik.
Nachdem zu 5.15 diverse Probleme gemeldet wurden bin ich bei meinem Desktop mit FreeBSD 14.0 und Radeon bei 5.10 geblieben.
 
serie300 schrieb:
Nur um Begriffsverwirrung vorzubeugen - mit Ports meinst du die Packages oder /usr/ports/graphics/drm-61-kmod ?
Zum Vergrößern anklicken....
Jap.
serie300 schrieb:
Ich hab's am 04. Juni mit make in den Ports gebaut. Wie gesagt für 14.1. und laufen tut's auf diesem aLaptop mit Intel Iris Grafik.
Zum Vergrößern anklicken....
Also bei mir:
Code: 
shinji@freebsd:~ $ cd /usr/ports/graphics/drm-61-kmod/
cd: /usr/ports/graphics/drm-61-kmod/: No such file or directory
shinji@freebsd:~ $
 
serie300 schrieb:
Hast du das Ports Verzeichnis upgedated ?
Zum Vergrößern anklicken....
Ach maaan, ich bin manchmal echt ein Trottel. :D Nee, natürlich nicht, ich brauche ja nur die libdvdcss welche ja schon nach der Installation von FreeBSD-14.0 verfügbar war. Daran habe ich gar nicht gedacht, portsnap gibt es ja jetzt auch nicht mehr, das geht ja jetzt mit Git. Ist aber auch nicht weiter schlimm, da ich nicht vorhabe mir drm-61-kmod aus den Ports zu bauen, da ich eben diese vermeide, wenn es möglich ist. Sobald es jedoch ein Paket gibt, werde ich dieses natürlich ausprobieren.
 
Macke1979 schrieb:
da ich eben diese vermeide, wenn es möglich ist.
Zum Vergrößern anklicken....
Im Prinzip passiert dabei nix Schlimmes. Zumal Du ja Ports wie Packages installieren kannst. Letztlich macht es dann in dem Fall für das System kein Unterschied und es erscheint dann auch wie alle anderen Packages unter pkg.

Macke1979 schrieb:
Sobald es jedoch ein Paket gibt, werde ich dieses natürlich ausprobieren.
Zum Vergrößern anklicken....
Theoretisch kann ich Dir das Paket zur Verfügung stellen für FreeBSD 14.1/AMD64
Würde ich aber nur ungern tun, weil ich immer propagiere, das man sich nicht irgendwelchen Kram von irgendwo her und von irgendwelchen Hansels herunterladen soll.
 
Macke1979 schrieb:
portsnap gibt es ja jetzt auch nicht mehr, das geht ja jetzt mit Git.
Zum Vergrößern anklicken....
Wie? Gibt es nicht mehr? Ich habe gerade ein portsnap fetch updatedurchgeführt und es hat funktioniert, wie immer. Mir ist aber aufgefallen, dass es im Handbook tatsächlich nicht mehr erwähnt wird. Andererseits gibt es aber die Manpage, auf der Version 14.1 zu sehen ist:

portsnap

man.freebsd.org man.freebsd.org

Könnte mich jemand bitte mal bezüglich portsnapaufklären?
 
cabriofahrer schrieb:
Könnte mich jemand bitte mal bezüglich portsnapaufklären?
Zum Vergrößern anklicken....
Siehe /usr/ports/port-mgmt/portsnap/Makefile (Zeile 13/14):
Code: 
DEPRECATED=    portsnap infrastructure will be removed after the EOL of 13.x
EXPIRATION_DATE=2026-04-30

Wenn Du Dir nicht den normalen git-Client reinziehen willst (der auch ein paar Abhängigkeiten hat) kannst Du auch das leichtgewichtigere gitup nehmen.
Siehe dazu auch: https://www.bsdforen.de/threads/freebsd-svn-git-umstellung-beginnt.35917/#post-324586
 
Andy_m4 schrieb:
Theoretisch kann ich Dir das Paket zur Verfügung stellen für FreeBSD 14.1/AMD64
Würde ich aber nur ungern tun, weil ich immer propagiere, das man sich nicht irgendwelchen Kram von irgendwo her und von irgendwelchen Hansels herunterladen soll.
Zum Vergrößern anklicken....
Alles gut, ich habe ja eine befriedigende Lösung gefunden, indem ich weiterhin drm-515-kmod nutze und dieses halt provisorisch mittels lock (den Hinweis auf diese Option habe ich übrigens von dir, ja ich erinnere mich noch XD) verriegelt.^^
Andy_m4 schrieb:
Im Prinzip passiert dabei nix Schlimmes. Zumal Du ja Ports wie Packages installieren kannst. Letztlich macht es dann in dem Fall für das System kein Unterschied und es erscheint dann auch wie alle anderen Packages unter pkg.
Zum Vergrößern anklicken....
Klar, ein einzelner Grafiktreiber hat nicht sehr viele Abhängigkeiten, würde ich allerdings größere Software über die Ports bauen, so könnte es durchaus passieren, dass dadurch wegen etwaiger Abhängigkeiten das halbe System umgebaut wird und da habe ich nicht wirklich Lust drauf. Deshalb greife ich nur dann auf die Ports zurück, wenn es wirklich nicht anders geht.
 
Macke1979 schrieb:
Klar, ein einzelner Grafiktreiber hat nicht sehr viele Abhängigkeiten
Zum Vergrößern anklicken....
Der hat gar keine Abhängigkeiten. Außer dem Kernel halt.
Das ist deshalb auch eine Sache, worauf man dann achten müsste. Das nach einem freebsd-update man auch immer den Treiber nachzieht.
Ich sage das nur vorsichtshalber, falls Du Dich doch noch irgendwann anders entscheidest. :-)

Macke1979 schrieb:
würde ich allerdings größere Software über die Ports bauen
Zum Vergrößern anklicken....
Sollst Du ja nicht und musst Du ja auch nicht.
Es ging ja rein um den Grafiktreiber.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben