Intel Z790 Chipsatz mit Linux...

[Zeiss]

Moin zusammen,

ich habe in meinem Rechter ein Z790 Board drin (AsRock Z790 PG Lightining) und habe das Problem, dass ich die Kiste unter Linux (Debian Stable) nicht stabil zum Laufen bekomme.

Nicht stabil bedeutet:
-> Freezies bei der Arbeit, einfach so, zack eingefrohren, auch die Maus bewegt sich nicht
-> Freezies auch beim Booten
-> weder in dmesg noch in /var/log/messages ist irgendwas brauchbares drin.
-> Reboot..... also die Kiste fährt runter und findet dann plötzlich keine Boot-Devices mehr, egal ob Windows oder Linux, er sieht einfach keine.
-> nach so einem Reboot PowerOff und PowerOn und schon sind die PLatten wieder da.....
-> dmesg voll mit Meldungen vom PowerManagement von den USB-Ports
-> ...

Die BIOS Version ist schon die aktuellste drauf...

Kennt jemand die Problematik? Unter Windows (W10 22h2) läuft die Kiste absolut einwandfrei.

 

[DOcean]

debian stable ist ja immer gut gealterte Software, mal mit testing probiert? oder mit einem anderen (Debian) Linux?

Reboot..... also die Kiste fährt runter und findet dann plötzlich keine Boot-Devices mehr, egal ob Windows oder Linux, er sieht einfach keine.

das klingt nach einem allgemeinen Problem, dafür das keine Geräte mehr gefunden werden kann das OS ja nix, das ist reine Baustelle vom BIOS

 

[Ellina]

Würde ich pase nicht sagen, Ich würde mal eher die Ganzen bios settings herum gehen ob da nicht ne instabieler Ram ist oder die cpu duch OC einfach instabil ist.

Die software kann auch sein aber das klingt für mich eher nach hardware OC das nicht stabil bekommen wurde das ändert nichts dran das wo möglich kein chipsatz treiber unter linux zur verfügung steht.
Rest wird alles über den Kernel geladen.

Systemconfiguration mal posten,
Und was OC hat.

Und dann schauen wir mal wo die Reise hin geht.

Deiban stabel welche version ist das? Dass ist die viel entscheidernde Frage.

Weil kann ja sein dass du stable 11 oder 10 genommen hast dann ist klar dass debian das nicht kennt und probleme macht.

 

[Stryke7]

Moin zusammen,

ich habe in meinem Rechter ein Z790 Board drin (AsRock Z790 PG Lightining) und habe das Problem, dass ich die Kiste unter Linux (Debian Stable) nicht stabil zum Laufen bekomme.

Wie von DOcean schon geschrieben: Debian stable ist sehr stabil aber halt auch immer sehr alt, weil man Stabilität nunmal mit viel Testzeit erkauft. Der Chipsatz ist anderthalb Jahre alt. Es wäre möglich dass da noch Kleinigkeiten fehlen.

Hast du es mal mit einer anderen Distribution versucht? Irgendwas auf Arch Basis zum Beispiel? Die sind meist sehr viel aktueller und für private Rechner normalerweise auch stabil genug.

Nicht stabil bedeutet:
-> Freezies bei der Arbeit, einfach so, zack eingefrohren, auch die Maus bewegt sich nicht

Hast du mal versucht die Shell zu wechseln? Mit Ctrl+Alt+F2 oder einer anderen F-Taste kannst du in eine ander Shell wechseln, die GUI läuft üblicherweise in der ersten Shell.

-> Freezies auch beim Booten
-> weder in dmesg noch in /var/log/messages ist irgendwas brauchbares drin.
-> Reboot..... also die Kiste fährt runter und findet dann plötzlich keine Boot-Devices mehr, egal ob Windows oder Linux, er sieht einfach keine.

Das klingt für mich nach einem sehr hardwarenahen Problem. Machst du den Reboot über den Reset-Knopf oder wie?

-> nach so einem Reboot PowerOff und PowerOn und schon sind die PLatten wieder da.....
-> dmesg voll mit Meldungen vom PowerManagement von den USB-Ports

Also entweder ist der USB-Treiber nicht in Ordnung oder du hast einen Hardwaredefekt. Kannst du uns mal so eine Meldung zeigen?

 

[Ellina]

Hast du mal versucht die Shell zu wechseln? Mit Ctrl+Alt+F2 oder einer anderen F-Taste kannst du in eine ander Shell wechseln, die GUI läuft üblicherweise in der ersten Shell.

da ziehe ich die konsolle vor. Aus dem grund weil man da das auf der Grafischen oberfläche hat sprich kopieren deine metode ist zwar nett aber leider erst dann hilfreich wenn es Freezt so lange das nicht der fall ist da kann man schneller dinge hinaus kopieren.

Aber dann müßte man wissen was los ist und da sollten wir Recharsche betreiben. Weil ich gehe mal davon aus das die hardware duch den kernel nicht optimal supportet wird daher wäre die debian version relvant und entsprechent dann zu schauen was man dann tuhen kann.

 

[Stryke7]

da ziehe ich die konsolle vor. Aus dem grund weil man da das auf der Grafischen oberfläche hat sprich kopieren deine metode ist zwar nett aber leider erst dann hilfreich wenn es Freezt so lange das nicht der fall ist da kann man schneller dinge hinaus kopieren.

Ich verstehe nicht was du in diesem Absatz sagen willst

 

[Ellina]

Ich verstehe nicht was du in diesem Absatz sagen willst

Wenn du mit Strg+f1 auf die virtuelle Konsole wechselst hast du keine grafische oberfläche sprich copy paste klappt dann nicht und die die du schon mal genutzt hast kannst du ein geben b.z.w Feil nach oben. Auser History heraus suchen.

Wenn du das Terminal / Konsole nutzt kannst du fehler berichte copy paste in ne text datei kopieren. Wahlweise kannst du auch dinge direkt in ne Text datei schreiben lassen.

Was ich meine ist das man das unterschiedlich sehen kann und arbeiten kann aber man sollte schon irgend wie wissen was die befehle bezwecken. Bei nvidia muss man z.b. treiber ohne grafische oberfläche installieren dass macht die fehleranfälligkeit deutlich höher weil man den display dienst dekativieren muss.
In so fern weist du was jetzt ist. Und wie gesagt chipsatz sollte in kernel sein den kannst du aber nachträglich installieren.

Wenn der TE sich dazu mal melden würde.

 

[Zeiss]

Moin zusammen,

erstmal sorry für die späte Rückmeldung, hatte sehr viel um die Ohren.

Zum PC: die Kiste läuft mit Standardtakt, kein OC, keine Hardcore-Einstellungen. System-Konfig in der Signatur.

@Stryke7 Mit Freeze meine ich wirklich tot, nichts geht, die Maus ist eingefroren, nicht geht mehr. Ich kann auf der Tastatur rumtackern, bis ich grün werde, passiert nichts. Habe dann kurz mit einem Debian von USB gebootet und in messages und dmesg geschaut, da ist nichts von wegen Kernelpanik oder sowas, also einfach stehen geblieben ohne weitere Meldungen.

Nun zum Problem, es geht weiter. Ich habe mir in der Zwischenzeit ein Debiaan Live! System 12.2 runtergeladen und auf einen USB-Stick gebrannt und gebootet, erstmal in dem "Ausgangszustand", kein BIOS-Reset oder irgendwelche Anpassungen, nichts. Nur eben ein neueres Debian.

Und natürlich hat dmesg einen Sack voll Fehler, ist klar...

Erstmal USB:

[ 1074.188621] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[ 1074.188692] usb 2-8: Enable of device-initiated U2 failed.
[ 1074.188960] hub 2-8:1.0: USB hub found
[ 1074.188973] hub 2-8:1.0: config failed, can't read hub descriptor (err -22)
[ 1074.189030] usb 2-8: Failed to suspend device, error -19
[ 1074.508491] usb 2-8: USB disconnect, device number 69
[ 1074.780663] usb 2-8: new SuperSpeed USB device number 70 using xhci_hcd
[ 1074.801164] usb 2-8: New USB device found, idVendor=0451, idProduct=8046, bcdDevice= 1.00
[ 1074.801176] usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Okay, 0451:8046 ist ein TI Controller, taucht im lsusb zwei mal auf:

[ 1074.188621] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[ 1074.188692] usb 2-8: Enable of device-initiated U2 failed.
[ 1074.188960] hub 2-8:1.0: USB hub found
[ 1074.188973] hub 2-8:1.0: config failed, can't read hub descriptor (err -22)
[ 1074.189030] usb 2-8: Failed to suspend device, error -19
[ 1074.508491] usb 2-8: USB disconnect, device number 69
[ 1074.780663] usb 2-8: new SuperSpeed USB device number 70 using xhci_hcd
[ 1074.801164] usb 2-8: New USB device found, idVendor=0451, idProduct=8046, bcdDevice= 1.00
[ 1074.801176] usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Hier ist genau mein Problem beschrieben, also erstmal die beiden Bildschirme abstecken und ignorieren, ich habe genau dieselben.

Dann ein Sack voll Meldungen im Bezug auf DMAR / DRHD:

root@debian:~# dmesg |grep -e DMAR -e IOMMU -e AMD-Vi
[    0.007425] ACPI: DMAR 0x000000006486F000 000050 (v02 INTEL  EDK2     00000002      01000013)
[    0.007460] ACPI: Reserving DMAR table memory at [mem 0x6486f000-0x6486f04f]
[    0.014793] DMAR: IOMMU enabled
[    0.049191] DMAR: Host address width 39
[    0.049193] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.049199] DMAR: dmar0: reg_base_addr fed91000 ver 5:0 cap d2008c40660462 ecap f050da
[    0.049203] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 0
[    0.049205] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.049207] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.049998] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.398663] DMAR: No RMRR found
[    0.398664] DMAR: No ATSR found
[    0.398665] DMAR: No SATC found
[    0.398666] DMAR: dmar0: Using Queued invalidation
[    0.400515] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.854962] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug.
[    1.716369] DMAR: DRHD: handling fault status reg 2
[    1.716373] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set
[  122.060698] DMAR: DRHD: handling fault status reg 3
[  122.060702] DMAR: [DMA Write NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x05] PTE Write access is not set
[  122.060773] DMAR: DRHD: handling fault status reg 3
[  122.060775] DMAR: [DMA Read NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x06] PTE Read access is not set
[  122.060828] DMAR: DRHD: handling fault status reg 3
[  122.060830] DMAR: [DMA Read NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x06] PTE Read access is not set
[  122.060835] DMAR: DRHD: handling fault status reg 3
[  183.155089] snd_emu10k1 0000:07:00.0: non-passthrough IOMMU detected, widening DMA allocations
[  188.152302] DMAR: DRHD: handling fault status reg 3
[  188.152306] DMAR: [DMA Read NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x06] PTE Read access is not set
[  188.152426] DMAR: DRHD: handling fault status reg 3
[  188.152429] DMAR: [DMA Read NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x06] PTE Read access is not set
[  188.154331] DMAR: DRHD: handling fault status reg 3
[  188.154334] DMAR: [DMA Read NO_PASID] Request device [08:00.0] fault addr 0xffd97000 [fault reason 0x06] PTE Read access is not set
[  188.154413] DMAR: DRHD: handling fault status reg 3
root@debian:~#

Nach googeln und suchen habe ich was dazu gefunden... Die Meldungen oben sind nachdem ich den Boot-Parameter "intel_iommu=on" hinzugefügt habe. Der zweite Parameter "iommu=pt" ist da noch nicht drin, werde es mal testen, ob das was bringt. Die Anmerkung mit "Thunderbold deaktivieren" hört sich auch interessant an, wäre auf jeden Fall einen Versuch wert.

Insgesamt verhält sich das System aber angenehm... Bin jetzt seit ca 40 Minuten damit unterwegs und es läuft...

Ich teste heute Abend noch weiter und melde mich.

NACHTRAG: Ein Reboot (vom Debian Live in Windows) hat ohne Probleme funktioniert, er hat die Boot-Devices gefunden und Windows 10 gestartet. Okay, das ist doch schon mal was.

 

[Zeiss]

So, weiter gehts...

Ich habe nun Grub vom Debian Live so angepasst, dass er den Kernel mit "intel_iommu=on iommu=pt" startet. Und siehe da:

root@debian:~# dmesg |grep -e DMAR -e IOMMU -e AMD-Vi
[    0.007792] ACPI: DMAR 0x000000006486F000 000050 (v02 INTEL  EDK2     00000002      01000013)
[    0.007828] ACPI: Reserving DMAR table memory at [mem 0x6486f000-0x6486f04f]
[    0.016091] DMAR: IOMMU enabled
[    0.050315] DMAR: Host address width 39
[    0.050317] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.050323] DMAR: dmar0: reg_base_addr fed91000 ver 5:0 cap d2008c40660462 ecap f050da
[    0.050327] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 0
[    0.050329] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[    0.050330] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.051127] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.399929] DMAR: No RMRR found
[    0.399930] DMAR: No ATSR found
[    0.399931] DMAR: No SATC found
[    0.399932] DMAR: dmar0: Using Queued invalidation
[    0.400171] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.762359] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug.
root@debian:~#

bzw.:

root@debian:~# dmesg | grep -i iommu
[    0.000000] Command line: BOOT_IMAGE=/live/vmlinuz-6.1.0-13-amd64 boot=live components intel_iommu=on iommu=pt splash findiso=
[    0.016051] Kernel command line: BOOT_IMAGE=/live/vmlinuz-6.1.0-13-amd64 boot=live components intel_iommu=on iommu=pt splash findiso=
[    0.016091] DMAR: IOMMU enabled
[    0.050327] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 0
[    0.374983] iommu: Default domain type: Passthrough (set via kernel command line)
[    0.399962] pci 0000:00:00.0: Adding to iommu group 0
[    0.399969] pci 0000:00:01.0: Adding to iommu group 1
[    0.399975] pci 0000:00:06.0: Adding to iommu group 2
[    0.399985] pci 0000:00:14.0: Adding to iommu group 3
[    0.399991] pci 0000:00:14.2: Adding to iommu group 3
[    0.399996] pci 0000:00:14.3: Adding to iommu group 4
[    0.400003] pci 0000:00:15.0: Adding to iommu group 5
[    0.400011] pci 0000:00:16.0: Adding to iommu group 6
[    0.400017] pci 0000:00:17.0: Adding to iommu group 7
[    0.400031] pci 0000:00:1b.0: Adding to iommu group 8
[    0.400039] pci 0000:00:1c.0: Adding to iommu group 9
[    0.400047] pci 0000:00:1c.3: Adding to iommu group 10
[    0.400055] pci 0000:00:1c.5: Adding to iommu group 11
[    0.400062] pci 0000:00:1d.0: Adding to iommu group 12
[    0.400075] pci 0000:00:1f.0: Adding to iommu group 13
[    0.400081] pci 0000:00:1f.3: Adding to iommu group 13
[    0.400087] pci 0000:00:1f.4: Adding to iommu group 13
[    0.400093] pci 0000:00:1f.5: Adding to iommu group 13
[    0.400104] pci 0000:01:00.0: Adding to iommu group 14
[    0.400110] pci 0000:01:00.1: Adding to iommu group 14
[    0.400116] pci 0000:02:00.0: Adding to iommu group 15
[    0.400130] pci 0000:04:00.0: Adding to iommu group 16
[    0.400137] pci 0000:06:00.0: Adding to iommu group 17
[    0.400140] pci 0000:07:00.0: Adding to iommu group 17
[    0.400147] pci 0000:08:00.0: Adding to iommu group 18
[    0.762359] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug.

Es sind keine Meldungen mehr wegen "DMAR: DRHD: handling fault status reg BLAH" zu sehen, das sieht doch mal sehr gut aus, täte ich sagen...

Nun will ich mal kurz Debian Live mit dem "Calamares" auf die SSD installieren und schauen, was er dann dazu sagt, ich bin gespannt und werde berichten.

 

[Ellina]

sonst probiere mit F10 in den Boot menü Folgendes ein zu geben.

nomorset

Dazu verlinke ich dir ein bild. Weis nicht mehr 100%tig wo das stehen zu haben muss.

https://supportkb.dell.com/img/ka02R000000i0LDQAY/ka02R000000i0LDQAY_en_US_6.jpeg

Damit kannst du zu mindestens Vermeiden dass da ne Treiber geladen wird und ne anderer Geladen wird. Das hilft um heraus zu finden wiso es Freezt.

Mache ich auch immer wieder weil es sehr praktisch ist es zu haben und dann Probleme oder andere dinge zu beheben wie Treiber zu installieren etc..

Nun will ich mal kurz Debian Live mit dem "Calamares" auf die SSD installieren und schauen, was er dann dazu sagt, ich bin gespannt und werde berichten.

Da wird nichts passieren das müßtest du sonst übers Live System in Grub händisch eintragen und jedes mal wenn Grub sich aktuallisiert beim Kernel musst du das händisch nach arbeiten. Ob das die lösung ist....

 

[Zeiss]

Da wird nichts passieren das müßtest du sonst übers Live System in Grub händisch eintragen und jedes mal wenn Grub sich aktuallisiert beim Kernel musst du das händisch nach arbeiten. Ob das die lösung ist....

Hmm? Wie meinen?

Ich kann die Argumente doch einfach im /etc/default/grub reinhacken, als "GRUB_CMD_LINE_LINUX_DEFAULT" und fertig. Da wird auch nichts überbügelt, wenn Grub upgegraded wird, zumindest hat es bis dato nicht. Man muss es halt einmalig machen, quasi direkt nach der Installation.

 

[Ellina]

Ich meine es folgender maßen.

Grub wird duch den Kernel Aktuallsieirt. Und dann werden die Ganzen Cfg Datein neu geschrieben / Generiert. Und wenn du da Nomoset einträgst musst du das sonst immer manuelle machen.
Ich mache das schon länger, Aber genau der Ortner wird beim Kernel Update aktuallsiert und die Datei neu geschrieben.
Glaub mir, Das wirst du beim nächsten Kernel update dann passieren.
Da wirst du nicht lange erfolg haben. Grub wird seltener Geupdatet. Aber die Kernels Schon.

 

[DOcean]

Und dann werden die Ganzen Cfg Datein neu geschrieben / Generiert.

genau deswegen ändert man nicht mehr manuell an den Werten sondern nimmt die passende Stellen /etc/default/grub ist aber so eine

 

[Ellina]

Danke, docdent Dafür.
Deswegen Nomoset. Damit man da halt erstmal safe ist und dann anders Lösen dass es nicht Generiert wird und man es manuell einstellen kann.

 

[Zeiss]

Ich meine es folgender maßen.

Grub wird duch den Kernel Aktuallsieirt. Und dann werden die Ganzen Cfg Datein neu geschrieben / Generiert. Und wenn du da Nomoset einträgst musst du das sonst immer manuelle machen.
Ich mache das schon länger, Aber genau der Ortner wird beim Kernel Update aktuallsiert und die Datei neu geschrieben.
Glaub mir, Das wirst du beim nächsten Kernel update dann passieren.
Da wirst du nicht lange erfolg haben. Grub wird seltener Geupdatet. Aber die Kernels Schon.

Es wird genau gar nichts passieren... Die /etc/default/grub ist die zentrale Konfig vom Grub. Diese wird jedes Mal herangezogen, wenn ich ein "update-grub" ausführe, das sagt er auch oben im Header der Datei:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

Das, was in /etc/default/grub drin ist, überlebt jeden Upgrade und wird immer in die grub.cfg reingemerged, immer immer.

@DOcean Ja, eben

@Topic: Also, die vom Live System installierte 12.2 rennt wie die Sau... geil, gefällt mir.

 

[DOcean]

Deswegen Nomoset.

das Ding heißt "nomodeset" das schaltet aber nur den Grafik Modus wieder auf altbacken, hat hier nix zu suchen...

 

[Zeiss]

Nein, wirklich nicht...

Habe gerade die aktuellen NVidia (von www.nvidia.com) draufgebügelt, tut, passt.

Jetzt noch das Problem mit dem USB-Hub in den Griff kriegen und fertig ist die Sache, schöne Sache das.

 

[Schnitzelnator]

das Ding heißt "nomodeset" das schaltet aber nur den Grafik Modus wieder auf altbacken, hat hier nix zu suchen...

Es verhindert genau genommen, dass der Kernel beim Starten den Anzeigemodus einrichten kann. Und führt dazu, dass Treiber, die auf Kernel Mode Setting (KMS) angewiesen sind, nicht geladen werden können. (Das ist nur ein Seiteneffekt, der gerne genutzt wird, um KMS-Grafiktreiber zu deaktivieren)

@Zeiss
USB-Geräte können evtl. selbst verbuggt sein und dadurch Warnungen, Fehlermeldungen oder andere Probleme auslösen. Tendenziell ist eher das Gerät verbuggt als der Kernel, aber der Kernel könnte eventuell besser auf verbuggte Geräte eingestellt sein/werden. (Allerdings will man auch nicht unbedingt in geteiltem Code viele Ausnahmen für verschiedene verbuggte USB-Geräte haben)
Im von Dir verlinkten Thread oben hat der TE einen Hub zwischen sein Gerät und den PC geschaltet. Das deutet darauf hin, dass das Gerät auf eine verbuggte Weise kommuniziert, die evtl. auf Windows nicht auffällt.

 

[Zeiss]

Der 0x451:8046 ist ein USB3 Hub Chip von TI, einer der ersten, wenn nicht so gar der erste... und das Ding ist in der Tat buggy, hier ist ein Thema dazu im E2E von TI. Auch Windows ist davon betroffen, wie man da sehen kann.

Das "Problem" an der Stelle ist halt, dass Linux einen "generischen" Hub-Treiber hat, das wäre dann in der Tat so, dass man ihn anpassen müsste...

Ich habe jetzt einfach die Bildschirme abgeklemmt und Ruhe ist. Auch der Start ist dadurch wesentlich schneller.