Linux Fehler beim booten (No irq handler for vektor)

[X83]

Hallo Forum,
dies ist mein erster Beitrag, bin aber schon länger stiller mitleser.

Ein Dank möchte ich auch direkt an den @SV3N geben, der immer wieder interressante Artikel zu der Linux Welt schreibt.
Und vlt den ein oder anderen dazu verleitet über den Windows Tellerrand zu schauen.

Auf meinem Laptop läuft schon seit Jahren Linux, angefangen bei Ubuntu, Mint, Manjaro, und mitlerweile sagt mir MX Linux sehr zu.

Da mir aus verschiedenen Gründen Windows immer weniger zusagt, wollte ich nun auch auf meinem (Gaming) Desktop auf Linux wechseln.

Asus Prime X570-P
Ryzen 3700X
RX5700
32GB 3200 RAM

Leider bekomme ich egal bei welcher Distri und Kernel folgende Fehlermeldung beim booten:
common_interrupt: 1.55 No irq handler for vektor
common_interrupt: 2.55 No irq handler for vektor
common_interrupt: 3.55 No irq handler for vektor
common_interrupt: 4.55 No irq handler for vektor
common_interrupt: 5.55 No irq handler for vektor
common_interrupt: 6.55 No irq handler for vektor
common_interrupt: 7.55 No irq handler for vektor
common_interrupt: 8.55 No irq handler for vektor
common_interrupt: 9.55 No irq handler for vektor
common_interrupt: 10.55 No irq handler for vektor

Also habe ich die Suchmaschine angeschmissen, und versucht das Problem zu beheben.
Folgendes wurde in verschiedenen englisch sprachigen Foren vorgeschlagen:

IOMMU zu deaktivieren:
TSME zu deaktivieren:
ACPI zu deaktivieren:
fTPM zu deaktivieren:
PSP zu deaktivieren: das abschalten dieser Funktion scheint das Asus Prime X570-P nicht zu unterstützen

Verschiedene Bios Versionen getestet:
3001, 3202, 3402

Leider alles ohne Erfolg.

Bei manchen half es wohl folgendes im GRUB zu hinterlegen:
(pci=nomsi,noaer)

Wenn ich das richtig verstanden habe löst dies aber nicht das eigentliche Problem, sondern unterdrückt wohl nur die Fehlermeldung.

Was ich mir so angelesen habe liegt das Problem bei den AGESA Updates in verbindung mit neuer Hardware.
laut Aussagen in den verschiedenen Foren schrieb z.B.

ASUS das Problem liegt an Linux
Gigabyte konnte das Problem bestätigen, und verwies an AMD
MSI soll das Problem gefixt haben? Kann das jemand bestätigen?

Dann würde ich auf ein MSI Board wechseln.

Was genau sagt diese Fehlermeldung (common_interrupt: 1.55 No irq handler for vektor) eigentlich aus?
Hat jemand eine Idee wie es behoben werden kann?
Oder müssen wir wirklich darauf hoffen das AMD, die Boardhersteller, oder die Programmierer sich um das Problem kümmern?

Unter dem Problem scheinen ja einige zu leiden, und kann dazu führen das nicht gebootet werden kann, oder es zu einem instabilen System führt.

Würde mich freuen wenn jemand was genaueres dazu Beitragen könnte.

 

[Nico1234]

Hallo X83,
Die Fehler wurde in c't 03/21 im Artikel "Linux auf dem optimalen PC" erwähnt.
Sie sind wohl harmlos und nur ein kosmetisches Problem (bei Ryzen CPUs).
VG

 

[ghecko]

Das Problem dürfte ein zu alter Kernel/Mesastack sein. Vom aktuellen MX müsste es zwei Bootoptionen geben, eine mit AHS (Advanced Hardware Support), die sollte funktionieren.

 

[Forlorn]

Ja, diese habe ich auch immer. Kann man ignorieren. https://bbs.archlinux.org/viewtopic.php?id=256227

Ich habe vergleichbare Meldungen auch auf einem AM2 Sockel, das 8 Jahre alt ist - genauso so lange übrigens. Nie in irgendwelche Probleme damit gelaufen.

 

[X83]

Danke für die schnellen Antworten, ihr seid super.

@Nico1234 und @Forlorn
Hmm, bei einigen scheint das aber doch mehr Probleme zu verursachen, wie das nicht gebootet werden kann, oder zu einem instabilen System führt.

Ich kann booten, erhalte aber immer diese Fehlermeldung.

@ghecko
Genau MX Linux AHS möchte ich als main Distri einsetzen, bekomme aber leider auch bei der die Fehlermeldung.

 

[.Silberfuchs.]

@ghecko Ich bekomme die gleichen Meldungen mit Fedora 33 und Ryzen auch. Daran liegt es nicht. Mich hat es nie gestört weil das System wunderbar funktioniert.

 

[JennyCB]

Hatte ich auch.

Gigabyte B550M AORUS PRO
Ryzen 3700X
Manjaro

BIOS F10 (AGESA 1.0.8.1)
Hier half ein "noapic" zur GRUB hinzuzufügen.

BIOS F11/F12 (AGESA 1.1.0.0 D)
Das Problem ist verschwunden.

 

[X83]

@JennyCB
Das scheint die These zu unterstützen das es ein AGESA Problem ist, und die Boardhersteller doch Einfluss darauf haben.

Ich würde trotzdem gern wissen wo genau das Problem liegt?

Bei meinem Board ASUS Prime X570-P ist mittlerweile AGESA V2 PI 1.2.0.0 in der Beta drauf, aber leider ist die Fehlermeldung dort nicht gefixt.

Deswegen würde es mich interressieren auf welchen X570 Boards und AGESA Versionen das gefixt wurde, dann würde ich mir ein anderes Board zulegen.

Vlt könnte CB ja der Sache mal nach gehen?
Ich denke das würde den ein oder anderen auch interressieren, und weiterhelfen.

 

[.Silberfuchs.]

Kannst du nicht booten, ist das System instabil oder erscheint beim Start einfach nur die Meldungen?

 

[X83]

@.Silberfuchs.

Ich kann booten, erhalte aber immer diese Fehlermeldung.

Ob das System Stabil läuft kann ich derzeit noch nicht genau sagen.

 

[Iapetos]

Ich habe die Fehlermeldung auch auf einem Asrock A520M-ITX. Das System ist dauerhaft stabil. Es ist wirklich nur ein kosmetisches Problem.

 

[.Silberfuchs.]

@X83 Dann würde ich das Mainboard nicht wechseln solange du keine ernsthaften Probleme mit deinem System hattest. Ist natürlich deine Entscheidung.

 

[lokon]

Ich würde trotzdem gern wissen wo genau das Problem liegt?

So "richtig" wird dir das keiner beantworten - weil "im Quelltext nachlesen" für dich bestimmt keine befriedigende Antwort ist.

Anbei mal nur oberflächliches Nachsehen :

grep -R "No irq handler for vektor" -> arch/x86/kernel/irq.c
(an der Stelle kann dann die Kerneldokumentation, git blame, git log ... zur weiteren Recherche benutzt werden)

Der Aufruf dort

pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n",

ist pr_emerg - pr_emerg angeblich "Emergency messages, system is about to crash or is unstable"
[1]

Deine Fehlermeldung hast du abgeschrieben ? - copy/paste oder kompletter Log wäre besser...
(vektor <-> vector)

Die Fehlermeldung kommt wohl in Zusammenhang mit APIC und Interrupt Management.

ack_APIC_irq();

        if (desc == VECTOR_UNUSED) {
            pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n",
                         __func__, smp_processor_id(),
                         vector);
        } else {
            __this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
        }

In-Kernel irqbalance 2008 entfernt worden (deswegen daemon).

Das APIC ist programmierbar

I bet that's on an AMD system with broken AGESA BIOS.... Good luck
debugging it BIOS updates are on the way so I'm told.

Wenn ein erfahrener Kernel-Programmierer (mit wikipedia seite) "good luck" [2] wünscht und auf auf Hersteller verweist - dann sollte ein Einsteiger an der Stelle keine Ressourcen (Zeit, Geld) in das Problem investieren.
Das Bios/APIC ist auch nur begrenzt auslesbar (dmidecode , acpidump) bzw. im Quellcode / Dokumentation verfügbar.
AGESA ist closed source, Firmware genauso, das BIOS & Kernel Programming Guide für Zen (Fam 17h) ist nicht öffentlich - dort würde soetwas vermutlich beschrieben sein.

siehe auch (?)
irqbalance , man irqbalance , irqbalance auf github , irqbalance bei redhat
Kernel Mailinglisten-Diskussion über no irq handler for vector: hier , [2] hier
alles via google

[1] "unstable" muss nicht auffällig sein. Viele Hardwarefehler ("Errata") werden auch in Software gefixt oder spielen für 99,999% des Codes keine Rolle. Eventuell betrifft der Fehler eine Funktionalität, die zB überhaupt nicht auf dem Mainboard verdrahtet ist.

Ergänzung (26. Januar 2021)

The problem is that the buggy BIOS causes vector 55 which is the legacy
X86 interrupt 7 to be sent to the secondary CPUs 1-10 when they come up
the first time during boot. This has been reported to death already and
AMD confirmed that it is an AGESA BIOS bug and that it is fixed with
AGESA BIOS version 1.1.8.0.

 

[X83]

@lokon
Vielen Dank für deinen ausführlichen Beitrag.

Ich werde mir deine Vorschläge gern mal genauer anschauen, und mich weiter allgemein in die Linux Welt einarbeiten.

Wenn man komplett wechseln möchte gibt es doch einige Dinge neu zu lernen, aber das bereitet mir auch eine Menge Spaß

Deine Fehlermeldung hast du abgeschrieben ?

Genau, die habe ich abgeschrieben.

Ich habe jetzt auch von MX AHS wieder zu Manjaro gewechselt, ich kann gar nicht genau sagen warum, aber Manjaro läuft auf meinem Desktop einfach flüssiger.

Habe mir KDE, XFCE, sowie GNOME angeschaut, und bin momentan bei GNOME geblieben.
Läuft bei mir sehr gut, wobei ich XFCE auch gut finde.

Was mir aber noch aufgefallen ist, das ich nach jedem Neustart die Maus ab und wieder rann stecken muss damit sie erkannt wirt.

Das Verhalten habe ich aber bei jeder Distri, USB Legacy ist im Bios aktiviert.
Vlt hat das auch mit dem ACPI zu tun?

 

[lokon]

USB Probleme können an der Hardwareinitialisierung vom Bios/UEFI liegen - da ist ACPI ja ein Teil von oder in der internen Firmware / Schaltungslogik der Controller (die teilw. auch via Bios/UEFI beeinflussbar ist) - "elektrostatische Aufladung" ist zB im Winter wg. trockener Innenraum-Luft potentiell problematischer (USB Ports können sich deswegen abschalten) - kann aber auch etwas anderes sein - siehe B550 ruckeln - mehr als Hardwaretausch, Softwaretausch , "have you tried turning it off and on again" ist da nicht praktikabel.

 

[root@linux]

Ich habe jetzt nicht alles gelesen, aber ich hatte ähnliche Probleme auf meinem AMD Ryzen.
Ein Bug in der IOMMU ist die Ursache.
FIX:
Ich habe die neuest BIOS Firmware installiert (Leider geht das nur mit Windows) und den neusten Linux Kernel. Ab dem Linux-Kernel-5.9.0, ist das Problem behoben; aber nur in Kombination mit neuster BIOS Firmware. So sieht es bei meinem Laptop aus:
BIOS V1.10 - Updates: EC version and boot path for Endless Linux OS.

https://www.acer.com/ac/en/US/content/support-product/8033?b=1

 

[Shader]

Ich bekomme die Meldungen auch mit meinem ASUS B550-F Gaming und dem Ryzen 5600X und habe mir darüber noch keine Gedanken gemacht denn das System läuft 1a stabil (abgesehen von der Macke mit dem Onboard-Sound).

 

[laser5]

Habe ein Gigabyte x570 Aorus Master. BIOS Versionen nach F11 haben bei mir auch den Fehler hervorgerufen. F11 war ohne diesen Fehler.
Gestern habe ich die BIOS Version F33a drauf gemacht, die hat AGESA ComboV2 1.2.0.0. Mit Fedora 33, Kernel 5.10.10-200.fc33.x86_64 ist der Fehler nicht mehr da. Habe direkt nach dem Update BIOS Einstellungen z.B. IOMMU enabled, SVM enabled, CSM disabled vorgenommen, weiß also nicht ob der Fehler weiterhin mit Standardeinstellungen auftreten würde. Falls jemand das gleiche Mainboard und gleiche Fedora Version hat und bei ihm der Fehler weiterhin auftaucht kann ich bei den Einstellungen nochmal genauer nachschauen.

 

[aki]

Ubuntu als Live-System mit Kernel 5.8.0 bringt bei mir auch diese Meldung, mit Gentoo und Kernel 5.10.11 ist davon nichts zu sehen.

X570 Aorus Master mit Bios F32 und 3900X

 

[X83]

Danke für eure Beiträge, das ist für den ein oder anderen denke ich sehr hilfreich zu sehen welche Board Hersteller sich anscheinend der Sache annehmen.

MSI und Gigabyte scheinen so wie ich das jetzt allgemein in den Foren gelesen habe, dem Problem nachgegangen zu sein, in den neueren AGESA Updates.

Zu ASRock habe ich bis jetzt nichts groß gelesen.

ASUS hat da wohl leider kein großes Interesse drann, wenn ich mir da manch E-Mail Antwort ihrerseits so durch lese.
Im Allgemeinen scheinen die ASUS Boards wohl leider öfter dazu zu neigen Probleme unter Linux zu verursachen.

Bei einigen hat sich das Problem wohl spätestens mit dem AGESA Update 1.2.0.0 erledigt zu haben, bei meinem ASUS Prime X570-P mit dem neusten BIOS 3402 Beta Update auf AGESA 1.2.0.0 hat sich leider daran nichts geändert.
Kann man nur hoffen das ASUS bei der Stable Version was daran ändert.

Ich wollte euch aber auch noch kurz eine Allgemeine Rückmeldung da lassen.
Habe die letzten Tage nochmal damit verbracht verschiedene Distris zu testen, und bin bei Manjaro geblieben.

Unter GNOME wollte sich bei mir einfach kein Workflow einstellen.

Also wollte ich mir XFCE noch einmal anschauen, dazu kam es aber nicht, da nach der Fehlermeldung (common_interrupt: 1.55 No irq handler for vektor) der Rechner nicht weiter gebootet hat, der Bildschirm blieb schwarz.

Rückblickend muss ich aber zugeben ganz froh darüber zu sein, da ich mir dann doch nochmal die KDE Plasma Version angeschaut habe, von der ich mich bei ersten rein schnuppern etwas erschlagen gefühlt hatte.

Wenn man sich erst mal mit dem ganzen Funktionsumfang auseinander gesetzt hat, ist die Oberfläche doch recht simpel aufgebaut, und bei mir stellte sich nach ein paar Anpassungen ein super Workflow ein.

Zu der Frage ob mein System trotz der Fehlermeldung stabil läuft?
Die würde ich mittlerweile mit ja beantworten, Kein Absturz oder der gleichen.
GTA5 sowie Cyberpunk habe ich bis jetzt auch getestet, und die Games laufen ohne Abstürze.

Das einzige was mir noch aufgefallen ist das sich zu der (common_interrupt: 1.55 No irq handler for vektor) Fehlermeldung beim herunterfahren noch folgende Fehlermeldung dazu gesellt hat (watchdog: watchdog0: watchdog did not stop!)
Dadurch benötigt er teils eine kleine Bedenkzeit beim herunterfahren.

Aber im großen und ganzen bin echt froh jetzt den kompletten Umstieg vollzogen zu haben, Windows ist vom Rechner verschwunden, und darüber bin ich sehr froh.
Hab mir voller Freude noch eine 970er EVO NVME bestellt, das System läuft Traumhaft flüssig.

@aki Das macht ja Hoffnung das Kernel seitig vlt doch was daran geändert werden könnte, Manjaro läuft bei mir momentan auf Kernel 5.10.7-3

Wenn ihr noch weitere Infos dazu habt wo die Fehlermeldung gefixt wurde, bitte gern hier rein schreiben, um einen kleinen Überblick zu bekommen.