Es ist fast sicher ein HW-Problem. Das Board ist selten und war nicht billig. Die Infos vom Handler sind verfügbar. Die Website des Herstellers ist offline, deshalb suche ich nach einer möglichst eleganten Lösung das Problem zu umgehen. Das aktuelle System ist fuss12.
Folgende Fehlerfälle können nach dem Einschalten auftreten:
Der Bildschirm bleibt schwarz
Es meldet sich das Bios und dann grub, dann schwarzer Bildschirm
Es meldet sich das Bios und dann grub, dann Startmeldungen in großer Bios-Schrift, dann schwarzer Bildschirm.
Es meldet sich das Bios und dann grub, dann Startmeldungen in großer Bios-Schrift, dann Startmeldungen in normaler Schrift, dann schwarzer Bildschirm.
Früher trat der Fehler selten auf, es reichte einfach neu zu starten. Ich stellte fest, dass das System normal ohne Grafikmodus hochfährt. Weil man nichts sieht, nimmt man an, dass es nicht bedienbar ist. Es ist über ssh erreichbar und mit ctrl-alt-fx im Konsolenmodus bedienbar. Ich war allerdings nicht in der Lage so in den Grafikmodus zu kommen.
Aktuell muss ich das System oft bis zu 4 mal starten, was lästig ist. Meine aktuelle Abkürzung ist alt+sysrec+r e i s u b (sysrec muss nur am Anfang gedrückt werden, dann alt+ r,e,i,s,u.b hintereinander. möglicherweise ist e,i nicht mal notwendig), dann startet das System neu.
Ein Problem ist, dass man die 4 Fehlerfälle nur dann unterscheiden kann, wenn man genau aufpasst, denn sie enden alle mit dem schwarzen Schirm. Ich habe Log-Daten im shared-Ordner eingestellt, die betreffen den Fehlertyp 1 und 3, sowie den funktionierenden Fall ‘ok’. Die mit amdgpu im Namen enthalten nur Zeilen mit ‘amdgpu’ und sind ohne den Zeitstempel, um die Unterschiede einfacher zu erkennen.
Entscheidend scheint kernel: amdgpu 0000:05:00.0: [drm] Cannot find any crtc or sizes zu sein, hilft mir aber nicht weiter.
Ich suche nach Ideen, wie man den Grafikmodus nachträglich starten kann und bin für jede Anregung dankbar. Beim Hochfahren 3-4 mal starten ist machbar, ich fürchte, dass sich die Situation weiter verschlechtert.
Wie ist dein Monitor am Udoo angeschlossen. Kann es sein, dass der Monitor nicht seine EDID-Daten über sein internes EEPROM preisgibt? Das würde erklären wieso der Display Controller von der AMD GPU den CRTC-Fehler ausgibt (CRTC = Cathode Ray Tube Controller).
Ich hatte zum Beispiel einen alten VGA-Monitor dessen EEPROM durch einen Blitzeinschlag gelöscht wurde, und ich musste das EEPROM neu schreiben, um wieder ein BIld zu bekommen, ohne manuell die Parameter einszustellen.
Danke Julian,
Der Monitor ist über DVI an HDMI beim Udoo angeschlossen.
Es ist ein Timing-Problem, das sich verschlechtert. Ich habe einen Hauptschalter, der Bildschirm, Netzteil für Udoo und Switch einschaltet. Wenn ich Udoo leicht verzögert aber immer noch vor dem Stromsparmodus des Bildschirms einschalte, kommt das System fast immer das erste Mal hoch.
Ich experimentiere noch in dieser Richtung, um auch herauszufinden, was ganz schlecht ist.
Con Ctrl+Alt+F1 (o F2…F5) arrivi ad un Terminal-Login?
da qui, dopo login con root (o da una sessione ssh), che processi vedi attivi con ps -ef ?
A parte le indicazioni sul monitor di Julian (cambialo per queste prove), è da verificare se il sistema grafico/display manager si lascia avviare manualmente; se si, un workaround potrebbe essere di inserire un ritardo nella sua partenza al boot (da capire come farlo).
Grazie Diego,
sì, nessun problema. Al momento non posso darti il risultato di ps -ef perché il problema non si presenta più dopo aver spento il sistema per un po’.
Posso selezionare tutti e 6 i terminali Alpha e accedere, anche come root. Ctrl+Alt+F7 mostra lo schermo nero.
Non ho idea di come riavviare la grafica con uno sforzo ragionevole, ad esempio con start x, perché cambiare il runlevel o usare systemctrl isolate è molto più complicato che effettuare il login come root e poi un reboot, o la mia scorciatoia attuale alt+sysrec+r,e,i,s,u,b.
CRTC, lang ist es her. Lange Zeit hatte ich noch einen großen und sehr teuren Monitor eines Architekturbüros im Keller stehen mit vga und BNC-Anschlüssen.
Ich interpretiere die Meldung Cannot find any crtc or sizes so:
Da der Anschluss VGA nicht belegt ist, also auch kein CRTC vorhanden ist, ist dies die Nachricht, dass die letzte untersuchte Quelle auch nicht vorhanden ist. Wobei nicht vorhanden nur bedeutet, dass innerhalb einer vordefinierten Zeitspanne sich kein Bildschirm gemeldet hat.
Während schlafende Monitore meist aufwachen, wenn sie an eine Quelle anschlossen werden, scheint der der amdgpu-Driver nicht mehrfach nach vorhandenen Monitoren zu suchen.
Ich werde die Monitordoku des Dell U2412M studieren, ob ich das Schlafengehen verzögern kann.
Bei meinen Deskmini A300 mit Ryzen 3400G APU habe ich am VGA-Anschluss auch nichts angeschlossen, sondern nur beim HDMI (einen DELL 2415), und bekomme von dem DRM-Subsystem keine Meldung wegen fehlenden Auflösungen.
Bei mir startet das DRM direkt mit aktivierten Kernel-Modesetting d.h. die Monitor-Auflösung übernimmt der Kernel schon vom UEFI-BIOS.
# dmesg | grep -e amdgpu -e drm
[ 0.431795] ACPI: bus type drm_connector registered
[ 0.450729] simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
[ 0.450732] [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0
[ 0.454392] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[ 4.235524] [drm] amdgpu kernel modesetting enabled.
[ 4.248554] amdgpu: Virtual CRAT table created for CPU
[ 4.248573] amdgpu: Topology: Add CPU node
[ 4.248698] amdgpu 0000:04:00.0: enabling device (0006 -> 0007)
[ 4.248745] [drm] initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x1002:0x15D8 0xC8).
[ 4.248756] [drm] register mmio base: 0xFCB00000
[ 4.248758] [drm] register mmio size: 524288
[ 4.250491] amdgpu 0000:04:00.0: amdgpu: detected ip block number 0 <soc15_common>
[ 4.250498] amdgpu 0000:04:00.0: amdgpu: detected ip block number 1 <gmc_v9_0>
[ 4.250500] amdgpu 0000:04:00.0: amdgpu: detected ip block number 2 <vega10_ih>
[ 4.250503] amdgpu 0000:04:00.0: amdgpu: detected ip block number 3 <psp>
[ 4.250506] amdgpu 0000:04:00.0: amdgpu: detected ip block number 4 <powerplay>
[ 4.250508] amdgpu 0000:04:00.0: amdgpu: detected ip block number 5 <dm>
[ 4.250511] amdgpu 0000:04:00.0: amdgpu: detected ip block number 6 <gfx_v9_0>
[ 4.250513] amdgpu 0000:04:00.0: amdgpu: detected ip block number 7 <sdma_v4_0>
[ 4.250516] amdgpu 0000:04:00.0: amdgpu: detected ip block number 8 <vcn_v1_0>
[ 4.251568] amdgpu 0000:04:00.0: amdgpu: Fetched VBIOS from VFCT
[ 4.251575] amdgpu: ATOM BIOS: 113-PICASSO-114
[ 4.315068] amdgpu 0000:04:00.0: vgaarb: deactivate vga console
[ 4.315075] amdgpu 0000:04:00.0: amdgpu: Trusted Memory Zone (TMZ) feature enabled
[ 4.315120] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
[ 4.315130] amdgpu 0000:04:00.0: amdgpu: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
[ 4.315135] amdgpu 0000:04:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
[ 4.315147] [drm] Detected VRAM RAM=2048M, BAR=2048M
[ 4.315149] [drm] RAM width 128bits DDR4
[ 4.315384] [drm] amdgpu: 2048M of VRAM memory ready
[ 4.315389] [drm] amdgpu: 6950M of GTT memory ready.
[ 4.315414] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 4.315661] [drm] PCIE GART of 1024M enabled.
[ 4.315663] [drm] PTB located at 0x000000F47FC00000
[ 4.316301] amdgpu: hwmgr_sw_init smu backed is smu10_smu
[ 4.319849] amdgpu 0000:04:00.0: amdgpu: Found VCN firmware Version ENC: 1.15 DEC: 3 VEP: 0 Revision: 0
[ 4.340864] amdgpu 0000:04:00.0: amdgpu: reserve 0x400000 from 0xf47f800000 for PSP TMR
[ 4.407322] amdgpu 0000:04:00.0: amdgpu: RAS: optional ras ta ucode is not available
[ 4.412427] amdgpu 0000:04:00.0: amdgpu: RAP: optional rap ta ucode is not available
[ 4.415739] amdgpu 0000:04:00.0: amdgpu: psp gfx command LOAD_TA(0x1) failed and response status is (0x7)
[ 4.415851] amdgpu 0000:04:00.0: amdgpu: psp gfx command INVOKE_CMD(0x3) failed and response status is (0x117)
[ 4.415855] amdgpu 0000:04:00.0: amdgpu: Secure display: Generic Failure.
[ 4.415858] amdgpu 0000:04:00.0: amdgpu: SECUREDISPLAY: query securedisplay TA failed. ret 0x0
[ 4.416701] [drm] DM_PPLIB: values for F clock
[ 4.416705] [drm] DM_PPLIB: 400000 in kHz, 3099 in mV
[ 4.416708] [drm] DM_PPLIB: 933000 in kHz, 3574 in mV
[ 4.416710] [drm] DM_PPLIB: 1200000 in kHz, 4399 in mV
[ 4.416712] [drm] DM_PPLIB: 1333000 in kHz, 4399 in mV
[ 4.416715] [drm] DM_PPLIB: values for DCF clock
[ 4.416717] [drm] DM_PPLIB: 300000 in kHz, 3099 in mV
[ 4.416719] [drm] DM_PPLIB: 600000 in kHz, 3574 in mV
[ 4.416721] [drm] DM_PPLIB: 626000 in kHz, 4250 in mV
[ 4.416723] [drm] DM_PPLIB: 654000 in kHz, 4399 in mV
[ 4.417829] amdgpu 0000:04:00.0: amdgpu: [drm] Display Core v3.2.334 initialized on DCN 1.0
[ 4.495087] [drm] kiq ring mec 2 pipe 1 q 0
[ 4.511433] kfd kfd: amdgpu: Allocated 3969056 bytes on gart
[ 4.511453] kfd kfd: amdgpu: Total number of KFD nodes to be created: 1
[ 4.511663] amdgpu: Virtual CRAT table created for GPU
[ 4.511778] amdgpu: Topology: Add dGPU node [0x15d8:0x1002]
[ 4.511782] kfd kfd: amdgpu: added device 1002:15d8
[ 4.511799] amdgpu 0000:04:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 11, active_cu_number 11
[ 4.511805] amdgpu 0000:04:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[ 4.511809] amdgpu 0000:04:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[ 4.511812] amdgpu 0000:04:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[ 4.511815] amdgpu 0000:04:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0
[ 4.511818] amdgpu 0000:04:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0
[ 4.511821] amdgpu 0000:04:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0
[ 4.511823] amdgpu 0000:04:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0
[ 4.511826] amdgpu 0000:04:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0
[ 4.511829] amdgpu 0000:04:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0
[ 4.511832] amdgpu 0000:04:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0
[ 4.511835] amdgpu 0000:04:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8
[ 4.511838] amdgpu 0000:04:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8
[ 4.511841] amdgpu 0000:04:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8
[ 4.511843] amdgpu 0000:04:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8
[ 4.511846] amdgpu 0000:04:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8
[ 4.518133] amdgpu: pp_dpm_get_sclk_od was not implemented.
[ 4.518136] amdgpu: pp_dpm_get_mclk_od was not implemented.
[ 4.518307] amdgpu 0000:04:00.0: amdgpu: Runtime PM not available
[ 4.518887] amdgpu 0000:04:00.0: [drm] Registered 4 planes with drm panic
[ 4.518890] [drm] Initialized amdgpu 3.64.0 for 0000:04:00.0 on minor 1
[ 4.524872] amdgpu 0000:04:00.0: amdgpu: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
[ 4.528501] fbcon: amdgpudrmfb (fb0) is primary device
[ 4.528510] amdgpu 0000:04:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[ 5.230121] systemd[1]: Starting Load Kernel Module drm...
[ 5.250078] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 5.250358] systemd[1]: Finished Load Kernel Module drm.
[ 6.089715] snd_hda_intel 0000:04:00.1: bound 0000:04:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
An sich selber benutzen DVI und HDMI Ports noch viele Analogien aus der VGA-Zeit, z.B. gibt es dort noch immer den I2C-Bus zur Kommunikation der Monitor-Parameter (genannt DDC-Bus) wo eben die EDID-Daten von einem im Monitor verbauten EEPROM über Grafiktreiber zur Autokonfiguration abgefragt werden.
D.h. es konnte bei dir wirklich sein, dass der Monitor nicht die EDID -Daten ausspuckt, und der AMDGPU-Treiber eben mal die Auflösung zufällig auswählt.
Hast du bei laufenden System schon probiert das von mir oben verlinkte EDID-Tool zu benutzen?
Du musst dir die Abhängigkeiten python3-smbus edid-decode i2c-tools installieren und das Tool vom Github holen und per sudo ./edid-rw den richtigen I2C-Bus des DVI-Ports abfragen.
Die EDID-Daten in Hex-Form können auch von einen Online-Dekoder verifiziert werden. Z.B. https://www.edidreader.com/
Bei meinen Monitor kommt z.B.:
# ./edid-rw
Listing available I2C buses via `i2cdetect -l`:
i2c-0 i2c AMDGPU DM i2c hw bus 0 I2C adapter
i2c-1 i2c AMDGPU DM i2c hw bus 1 I2C adapter
i2c-2 i2c AMDGPU DM i2c hw bus 2 I2C adapter
i2c-3 i2c AMDGPU DM i2c hw bus 3 I2C adapter
i2c-4 i2c AMDGPU DM aux hw bus 0 I2C adapter
i2c-5 i2c AMDGPU DM aux hw bus 2 I2C adapter
i2c-6 i2c AMDGPU DM aux hw bus 3 I2C adapter
i2c-7 smbus SMBus PIIX4 adapter port 0 at 0b00 SMBus adapter
i2c-8 smbus SMBus PIIX4 adapter port 2 at 0b00 SMBus adapter
i2c-9 smbus SMBus PIIX4 adapter port 1 at 0b20 SMBus adapter
i2c-10 i2c SMI-I2C0 I2C adapter
i2c-11 i2c SMI-I2C1 I2C adapter
i2c-12 i2c i2c-10-mux (chan_id 0) I2C adapter
i2c-13 i2c i2c-11-mux (chan_id 0) I2C adapter
You have to carefully select correct bus
and pass the number X from the i2c-X bus name as command line "i2c_bus_index" argument
usage: edid-rw [-h] [-w] [-t] [-f] [-s SLEEP] i2c_bus_index
edid-rw: error: the following arguments are required: i2c_bus_index
Danke Julian,
mit deiner genauen Beschreibung werde ich das EDID-Tool installieren und ausprobieren.
Meine Überlegungen:
Es ist ein transienter Fehler. Keine Ahnung, welche Einflüsse eine Rolle spielen. Wenn ich morgens das System starten will, musste ich zuletzt bis zu 4 mal starten, um in den Grafikmodus zu kommen. Wenn ich weiß, dass ich das System für mindestens 1 h nicht benötige, schalte ich das System komplett ab und habe gute Chancen beim nächsten Start am Tag gleich in den Grafikmodus zu gelangen oder allenfalls nach einem weiteren Versuch.
Wenn das System im Grafikmodus hochfährt ist auch der Fehler Cannot find any crtc or sizes nicht vorhanden.
Im laufenden System müsste mir das Tool immer die EDID-Daten ausgeben. Oder verstehe ich was falsch?
Wenn ich deine Startmeldungen mit meinen Logs vergleiche, so sehen sie sehr ähnlich aus. In deinem Ausschnitt kommt “iommu” nicht vor, während das bei mir in Fehlermeldungen aufscheint, allerdings unabhängig, ob der Start im Grafikmodus gelingt oder nicht.
kernel: kfd kfd: amdgpu: error getting iommu info. is the iommu enabled?
kernel: kfd kfd: amdgpu: Error initializing iommuv2
kernel: kfd kfd: amdgpu: device 1002:15dd NOT added due to errors
Hi Julian,
die Erweiterung von Murphys Law ist da. Heute morgen gleich das erst Mal im Grafikmodus hochgefahren. Ausgeschaltet, nach dem Frühstück noch mal probiert und wieder tritt der Fehler nicht auf.
Um einen Vergleich zu haben, wenn die Grafik nicht da ist:
root@udoo:/home/fli# systemctl status lightdm
● lightdm.service - Light Display Manager
Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; preset: enabled)
Active: active (running) since Wed 2025-11-12 08:45:50 CET; 20min ago
Docs: man:lightdm(1)
Main PID: 1116 (lightdm)
Tasks: 12 (limit: 37129)
Memory: 146.5M
CPU: 34.100s
CGroup: /system.slice/lightdm.service
├─1116 /usr/sbin/lightdm
└─1133 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Nov 12 08:45:50 udoo systemd[1]: Started lightdm.service - Light Display Manager.
Nov 12 08:45:51 udoo lightdm[1528]: rm: cannot remove '/var/lib/AccountsService/users/*': No such file or directory
Nov 12 08:45:51 udoo lightdm[1530]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts>
Nov 12 08:45:51 udoo lightdm[1535]: rm: cannot remove '/var/lib/AccountsService/users/*': No such file or directory
Nov 12 08:45:51 udoo lightdm[1530]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=111) by (uid=0)
Nov 12 08:46:03 udoo lightdm[1706]: gkr-pam: unable to locate daemon control file
Nov 12 08:46:03 udoo lightdm[1706]: gkr-pam: stashed password to try later in open session
Nov 12 08:46:03 udoo lightdm[1706]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts>
Nov 12 08:46:03 udoo lightdm[1706]: pam_unix(lightdm:session): session opened for user flineu(uid=1002) by (uid=0)
Nov 12 08:46:04 udoo lightdm[1706]: gkr-pam: unlocked login keyring
Seit 11.11. ist das System jedes mal in den Grafikmodus hochgefahren. Eigentlich genau das, was ich haben wollte.
Ich weiß, was ich jetzt alles im Fehlerfall prüfen kann und bin zuversichtlich dann durch einen Neustart des lightdm in den Grafikmodus zu kommen. Und ich werde darüber berichten, auch wenn es länger dauern sollte.
Update:
Bei der Überlegung, welche Änderung für das richtige Verhalten verantwortlich sein könnte:
keine Einstellungen am fuss12 geändert
nur das Programm lt. Vorschlag von @j54n1n installiert
keine Änderungen an den Anschlüssen und Kabel des Monitors
aber das Monitormenü aufgerufen, um zu prüfen ob ich beim Timing was ändern kann. Dabei festgestellt, dass die Eingänge automatisch abgesucht werden. Dann fix auf DVI umgestellt und die Umstellung wieder rückgängig gemacht, um diese Änderung erst dann umzustellen, wenn das System nicht in den Grafikmodus startet. Da ich die Einstellungen die letzten 10 Jahre sicher nicht geändert habe, jetzt aber die Einstellungen gespeichert wurden, könnte das die Ursache sein.