Kernel panic nach pkg autoremove

Macke1979

Macke1979

FreeBSD-User
Ich habe heute morgen ein
Code: 
pkg autoremove
ausgeführt, wobei etliche Firmware-Dateien gelöscht wurden. Allerdings löste dies nach einem Neustart einen Kernel-Panic aus... Gut, dass ich noch ein altes Bootenvironment hatte, somit konnte ich auf einen alten Stand zurückgehen. Dort habe ich in einer Test-BE zunächst in der /etc/rc.conf den Eintrag lightdm_enable="YES" mit einer vorangestellten # auskommentiert und
Code: 
pkg autoremove
erneut ausgeführt und danach drm-61-kmod komplett neu gebaut. Dies jedoch löste das Problem nicht. Ich leitete mit
Code: 
pkg autoremove > ausgabe
zunächst die Bildschirmausgabe in eine Datei um, zwecks der Möglichkeit die betroffenen Pakete in Ruhe studieren zu können. Das erstbeste Paket:
Code: 
shinji@freebsd:~ $ pkg info gpu-firmware-amd-kmod-aldebaran
gpu-firmware-amd-kmod-aldebaran-20230625_2
Name           : gpu-firmware-amd-kmod-aldebaran
Version        : 20230625_2
Installed on   : Tue Jun 18 14:24:06 2024 CEST
Origin         : graphics/gpu-firmware-amd-kmod
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : kld graphics
Licenses       : AMD
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod-firmware
Comment        : Firmware modules for aldebaran AMD GPUs
Annotations    :
    FreeBSD_version: 1400097
    build_timestamp: 2024-04-09T01:07:02+0000
    built_by       : poudriere-git-3.4.1-1-g1e9f97d6
    flavor         : aldebaran
    port_checkout_unclean: no
    port_git_hash  : b3aa1ea86
    ports_top_checkout_unclean: no
    ports_top_git_hash: c5cd82114
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 2.41MiB
Description    :
Firmware modules for the drm-kmod drivers.

Firmware files for AMD GPUs supported by the amdgpu driver.
shinji@freebsd:~ $
Ganz offensichtlich handelt es sich hier jedoch um die alte Firmware für drm-515-kmod die ich bis vor ein paar Tagen (vor etwa 3 Tagen habe ich mir drm-61-kmod aus den Ports gebaut) noch genutzt habe, demzufolge wäre ein pkg autoremove ja auch eigentlich korrekt, da ich ja auch drm-515-kmod deinstalliert habe, bevor ich mir den neuen Treiber gebaut habe. Deshalb verstehe ich jetzt den Grund für den Kernel-Panic nicht so ganz. Ich habe jetzt erst einmal die Firmware-Pakete von 515-kmod provisorisch mit pkg set -A0 auf nichtautomatisch gesetzt, um mir bei einem weiteren möglichen pkg autoremove weiteren Ärger zu ersparen, aber das kann doch nicht die Dauerlösung sein, oder?
 
mr44er schrieb:
Mach das mal auch mit der Zeile für amdgpu, dann solltest du stressfrei booten können und den Treiber wieder draufpacken.
Zum Vergrößern anklicken....
Habe ich soeben in einer Test-BE getan. Nachdem ich den Treiber erneut gebaut habe, kam es dennoch wieder zu dem Crash. Demzufolge werde ich die Einstellung pkg set -A0 zunächst beibehalten, bis es eine befriedegendere Lösung gibt. Dennoch frage ich mich, woran das liegt... Irgendwie sieht es so aus, als ob der Kernel beim Systemstart hartnäckig darauf beharrt, auch auf die alten Firmware-Dateien zugreifen zu wollen und da er diese nicht findet, nun ja... Merkwürdig ist das schon.
 
Ich hab mich mit den BEs noch noch großartig auseinandergesetzt, ich hab snapshots einen Layer drüber für gewöhnlich und daher sind die Fragen wahrscheinlich jetzt eher facepalmig:
Aber direkt würde ich sagen...welcher Kernel wird gebootet? Ist der alte, dazu passende noch vorhanden oder nicht?

Ist vielleicht amdgpu auch in /boot/loader.conf eingetragen? Wenn ja, dann auch dort raus. Generell ist der lazy/spätere load (rc.conf) für die Module zu empfehlen.
 
mr44er schrieb:
Aber direkt würde ich sagen...welcher Kernel wird gebootet? Ist der alte, dazu passende noch vorhanden oder nicht?
Zum Vergrößern anklicken....
Ich denke schon, es existiert jedenfalls ein Verzeichnis /boot/kernel.old während /boot/kernel gebootet wird, da bin ich mir ziemlich sicher.
Code: 
shinji@freebsd:~ $ ls -l /boot/kernel/kernel
-r-xr-xr-x  1 root wheel 29116080 19 Sep. 19:49 /boot/kernel/kernel
shinji@freebsd:~ $ ls -l /boot/kernel.old/kernel
-r-xr-xr-x  1 root wheel 29116080  5 Sep. 10:50 /boot/kernel.old/kernel
shinji@freebsd:~ $
mr44er schrieb:
Ist vielleicht amdgpu auch in /boot/loader.conf eingetragen?
Zum Vergrößern anklicken....
Nein, das ist nicht der Fall.
Code: 
shinji@freebsd:~ $ cat /boot/loader.conf
security.bsd.allow_destructive_dtrace=0
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
cryptodev_load="YES"
zfs_load="YES"
shinji@freebsd:~ $
 
Verstehe ich jetzt auch nicht.
Instinktiv würde ich jetzt nochmal vorwärts updaten, also alles, dann sources refreshen und den drm nochmal rekursiv durchbauen. Eventuell zeigt das schon was.

Noch ne abgefahrene Idee: kannst du im BIOS fastboot deaktivieren und alles nochmal mit einem Kaltstart durchtesten? Möglicherweise hängt die GPU trotz (Warm)reboot weiterhin auf Halbmast nach einem Crash für den highres/UEFI-part, wegen des fastboots.

Ich bin kein Freund von fastboot, bisher mehr Probleme damit gehabt/gesehen, als es die paar Sekunden eingespart rechtfertigen könnte.
 
klimaschreck schrieb:
Ich habe ein Rechner mit i915kms noch auf 14.0 Release. Jetzt habe ich Sorge, dass mir bei einem Update auf 14.1 Release Ähnliches passiert wie im Bugreport beschrieben. Eine Lösung habe ich nicht entdeckt. Oder habe ich etwas übersehen?
Zum Vergrößern anklicken....
Ich hab da jetzt auch keine Lösung entdeckt und ich weiß nicht, ob der Kernel per Default mit den dort angegebenen Optionen compiliert wird. Notfalls würde ich einfach drm-515-kmod nehmen und so lange es geht da drauf bleiben.
 
Gerade frisch gebaut.
Code: 
...
vgapci0@pci0:9:0:0:    class=0x030000 rev=0xc1 hdr=0x00 vendor=0x1002 device=0x164e subvendor=0x1043 subdevice=0x8877
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Raphael'
    class      = display
    subclass   = VGA
...

root@7950x:/home/mr44er # id mr44er
uid=1001(mr44er) gid=1001(mr44er) groups=1001(mr44er),0(wheel),44(video)
root@7950x:/home/mr44er # pkg info drm-61-kmod
drm-61-kmod-6.1.92
Name           : drm-61-kmod
Version        : 6.1.92
Installed on   : Tue Sep 24 22:53:29 2024 CEST
Origin         : graphics/drm-61-kmod
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : kld graphics
Licenses       : MIT and GPLv2 and BSD2CLAUSE
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod/
Comment        : DRM drivers modules
Annotations    :
    FreeBSD_version: 1401000
Flat size      : 17.0MiB
Description    :
amdgpu, i915, and radeon DRM drivers modules.
Currently corresponding to Linux 6.1 DRM.
This version is for FreeBSD 14-STABLE 1400508
and above.

root@7950x:/home/mr44er # freebsd-version -kru
14.1-RELEASE-p5
14.1-RELEASE-p5
14.1-RELEASE-p5

Kein Crash bisher, aber nach dem Laden von amdgpu und Änderung der Auflösung spammt es massiv damit:
Code: 
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_cmd_queue] Error queuing DMUB command: status=2
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_cmd_queue] Error queuing DMUB command: status=2
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_cmd_queue] Error queuing DMUB command: status=2

Ideen?

Edit:
Mit Adapter DP->HDMI spamt es. Ohne Adapter direkt HDMI crasht die Maschine.
Resize BAR deaktiviert macht keinen Unterschied.
 
Zuletzt bearbeitet:
Auch kein Unterschied, wenn ich den Framebuffer fest auf 512MB setze.
Hier noch ein komplettes Log:
Code: 
iic0: <I2C generic I/O> on iicbus0
[drm] amdgpu kernel modesetting enabled.
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x164E 0x1043:0x8877 0xC1).
[drm] register mmio base: 0xF6B00000
[drm] register mmio size: 524288
[drm] add ip block number 0 <nv_common>
[drm] add ip block number 1 <gmc_v10_0>
[drm] add ip block number 2 <navi10_ih>
[drm] add ip block number 3 <psp>
[drm] add ip block number 4 <smu>
[drm] add ip block number 5 <dm>
[drm] add ip block number 6 <gfx_v10_0>
[drm] add ip block number 7 <sdma_v5_2>
[drm] add ip block number 8 <vcn_v3_0>
[drm] add ip block number 9 <jpeg_v3_0>
drmn0: Fetched VBIOS from VFCT
amdgpu: ATOM BIOS: 102-RAPHAEL-008
[drm] VCN(0) decode is enabled in VM mode
[drm] VCN(0) encode is enabled in VM mode
[drm] JPEG decode is enabled in VM mode
drmn0: Trusted Memory Zone (TMZ) feature not supported
drmn0: PCIE atomic ops is not supported
[drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
drmn0: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
drmn0: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
[drm] Detected VRAM RAM=512M, BAR=512M
[drm] RAM width 128bits DDR5
[drm] amdgpu: 512M of VRAM memory ready
[drm] amdgpu: 65078M of GTT memory ready.
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] PCIE GART of 1024M enabled (table at 0x000000F41FC00000).
drmn0: successfully loaded firmware image 'amdgpu/psp_13_0_5_toc.bin'
drmn0: successfully loaded firmware image 'amdgpu/psp_13_0_5_ta.bin'
drmn0: PSP runtime database doesn't exist
drmn0: PSP runtime database doesn't exist
drmn0: successfully loaded firmware image 'amdgpu/dcn_3_1_5_dmcub.bin'
[drm] Loading DMUB firmware via PSP: version=0x08001B00
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_pfp.bin'
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_me.bin'
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_ce.bin'
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_rlc.bin'
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_mec.bin'
drmn0: successfully loaded firmware image 'amdgpu/gc_10_3_6_mec2.bin'
drmn0: successfully loaded firmware image 'amdgpu/sdma_5_2_6.bin'
[drm] use_doorbell being set to: [true]
drmn0: successfully loaded firmware image 'amdgpu/vcn_3_1_2.bin'
[drm] Found VCN firmware Version ENC: 1.27 DEC: 2 VEP: 0 Revision: 0
drmn0: Will use PSP to load VCN firmware
[drm] reserve 0xa00000 from 0xf41e000000 for PSP TMR
drmn0: RAS: optional ras ta ucode is not available
drmn0: RAP: optional rap ta ucode is not available
drmn0: SECUREDISPLAY: securedisplay ta ucode is not available
drmn0: smu driver if version = 0x00000004, smu fw if version = 0x00000005, smu fw program = 0, smu fw version = 0x00544fe1 (84.79.225)
drmn0: SMU driver if version not matched
drmn0: SMU is initialized successfully!
[drm] Display Core initialized with v3.2.207!
[drm] DMUB hardware initialized: version=0x08001B00
lkpi_iic0: <LinuxKPI I2C> on drmn0
iicbus1: <Philips I2C bus> on lkpi_iic0
iic1: <I2C generic I/O> on iicbus1
lkpi_iic1: <LinuxKPI I2C> on drmn0
iicbus2: <Philips I2C bus> on lkpi_iic1
iic2: <I2C generic I/O> on iicbus2
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm] kiq ring mec 2 pipe 1 q 0
[drm] VCN decode and encode initialized successfully(under DPG Mode).
[drm] JPEG decode initialized successfully.
drmn0: SE 1, SH per SE 1, CU per SH 2, active_cu_number 2
drmn0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
drmn0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
drmn0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
drmn0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
drmn0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
drmn0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
drmn0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
drmn0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
drmn0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
drmn0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
drmn0: ring sdma0 uses VM inv eng 12 on hub 0
drmn0: ring vcn_dec_0 uses VM inv eng 0 on hub 1
drmn0: ring vcn_enc_0.0 uses VM inv eng 1 on hub 1
drmn0: ring vcn_enc_0.1 uses VM inv eng 4 on hub 1
drmn0: ring jpeg_dec uses VM inv eng 5 on hub 1
vgapci0: child drmn0 requested pci_get_powerstate
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
lkpi_iic2: <LinuxKPI I2C> on drm2
iicbus3: <Philips I2C bus> on lkpi_iic2
iic3: <I2C generic I/O> on iicbus3
[drm] Initialized amdgpu 3.49.0 20150101 for drmn0 on minor 0
VT: Replacing driver "efifb" with new "drmfb".
[drm] DSC precompute is not needed.
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
 
@mr44er Das sieht ja echt übel aus. Es dürfte nicht leicht sein, die genaue Ursache zu finden, laut deines geposteten Logs werden die Firmware-Module offenbar erfolgreich geladen... Treten dieselben Fehlermeldungen auch unter drm-515-kmod auf?
 
Das werde ich noch testen, aber erst nach hinten schieben. Auf der Kiste habe/brauche ich keinen Desktop, bisher siehts aber so aus, als würde es trotz des Fehlerspams funktionieren.
BIOS-Update habe ich eben gemacht, trotz neuer AGESA und Boardreset keine Veränderung.
 
An anderer Stelle fand ich noch den Tip mit hw.dri.vblankoffdelay: 0(der auch gleichzeitig hw.dri.vblank_offdelay setzt), ändert aber nichts.

Ich ignoriere das jetzt mal gekonnt und bleibe auf drm-61-kmod, da es ja grundsätzlich funktioniert.
 
mr44er schrieb:
drm-515-kmod funktioniert gar nicht, das ist RDNA2, vermutlich zu neu?
Zum Vergrößern anklicken....
Wie neu ist zu neu? Diese Architekur kam, wenn ich mich nicht irre, bei den AMD-RX 600 Grafikkarten zum Einsatz und davon gab es meines Wissens nach die ersten Modelle schon seit 2020, also schon vor vier Jahren. Wenn es sich allerdings wirklich um brandneue Hardware handelt, dann bin ich geneigt zu glauben, dass das Problem nicht an einem Bug in drm-61-kmod liegt, sondern an der zu neuen Hardware, die eventuell nur teilweise unterstützt wird.
mr44er schrieb:
[drm ERROR :dc_dmub_srv_wait_idle] Error waiting for DMUB idle: status=3
Zum Vergrößern anklicken....
Was genau sagt diese Fehlermeldung aus? Da ich nicht wirklich mit der Materie Treiberprogrammierung vertraut bin, vermag ich leider nicht zu sagen, was diese Fehlermeldung im Detail bedeutet. (Hier sind aber mit hoher Wahrscheinlichkeit einige routinierte Coder/Entwickler an Board, die weit mehr dazu sagen können als ich.)
 
Macke1979 schrieb:
Diese Architekur kam, wenn ich mich nicht irre, bei den AMD-RX 600 Grafikkarten zum Einsatz und davon gab es meines Wissens nach die ersten Modelle schon seit 2020, also schon vor vier Jahren.
Zum Vergrößern anklicken....
Genau. Der 7950X wurde übermorgen vor exakt zwei Jahren released. Das ist eine APU, ich weiß daher nicht, ob es vielleicht daran liegt und was nicht schön mitspielt.
Brandneu ist es also nicht mehr, jedoch dürfte gpu-firmware-amd-kmod-dcn-3-1-5-20230625_2 Firmware modules for dcn_3_1_5 AMD GPUsdas Datum auch nicht zu vernachlässigen sein.

Macke1979 schrieb:
Was genau sagt diese Fehlermeldung aus?
Zum Vergrößern anklicken....
Das ist der Part, der für Panel Self Refresh und Adaptive Backlight Management zuständig ist. Letzteres betrifft nur Laptops und wegen Erstem habe ich hw.dri.vblankoffdelay getestet. Ich vermute, dass es irgendwas mit dem EDID Kram zu tun hat, normal verfummeln Adapter gerne mal was, aber hier gehts entgegen der Erwartung nur mit Adapter. Ich weiß aber, dass der ok ist. Zum einen habe ich ihn mehrfach und in der Vergangenheit hing der schon erfolgreich an unterschiedlichen Monitoren, Radeons und Nvidias.
Das muss einfach ein Bug in diesem Teil der Firmware sein, den kann ich aussitzen. An dem Ding brauche ich keine Ausgabe, sondern nur die Vulkan-Beschleunigung.

Laut https://bodhi.fedoraproject.org/updates/FEDORA-2023-d15f5a186a soll das dann mit firmware-20230804 gefixt sein.

Edit:
An und abstöpseln funktioniert, es dauert nur ungewöhnlich lange bis es flackert und Bild wieder da ist. Dann floodet es das Log aber erneut.

Edit2:
hw.amdgpu.sg_display=0in /boot/loader.conf war es leider auch nicht.

AMD Re-Enables Scatter/Gather Support For All APUs On Linux - Phoronix

www.phoronix.com www.phoronix.com
 
Zuletzt bearbeitet:
mr44er schrieb:
Das muss einfach ein Bug in diesem Teil der Firmware sein, den kann ich aussitzen. An dem Ding brauche ich keine Ausgabe, sondern nur die Vulkan-Beschleunigung.
Zum Vergrößern anklicken....
Vermutlich würde auch die Bildschirmausgabe, trotz Fehlermeldung, irgendwie funktionieren.
mr44er schrieb:
hw.amdgpu.sg_display=0in /boot/loader.conf war es leider auch nicht.
Zum Vergrößern anklicken....
Irgendwann hast du alle Variablen durch, die dir in dem Zusammenhang durch sysctl geboten werden. Tjoa, und dann... Dann bleibt dir noch die Möglichkeit, tief in den Sourcecodes der Kernelmodule rumzugraben (eine IT-Landschaft, in die ich aus Bammel, etwas kaputt zu machen, nicht einmal meine Zehen eintauchen würde XD.)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben