Xen Interrupt Probleme mit ACPI und PCI Hardware in der DomU

[Pierre Bernhardt]

Michael Westermann wrote:
> Hallo,
> 
> ich habe ein System etch mit Xen 3.03 amd64 aufgesetzt, läuft soweit
> ganz gut.
> 
> Ich habe fogendes Problem, wenn ich die beiden Netzwerk-karten von der
> Dom0 in die DumU via PCI Direktzugriff ansprechen crasht die Kiste mit
> sda scsi fehler.
> 
> Jetzt habe ich festgestellt dass die Interrupst für die Sata Treiber
> und die der Netzwerk-karten geschared sind. Also
> 
> cat /proc/interrupts
> 
> 16:       3038          0        Phys-irq  libata
> 17:        481          0        Phys-irq  libata, ehci_hcd:usb1
> 18:          0          0        Phys-irq  libata, ohci_hcd:usb2
> 19:        137          0        Phys-irq  HDA Intel

Jo, damit wirst Du aber wenig anfangen können. Warum habe ich mir nicht
weiter angesehen, aber welche Interrups für das Xen eine Rolle Spielen
kann man eher mit lspci heraus bekommen oder man schaut mit dmesg nach.

Beispiel bei mir:
xen:~# cat /proc/interrupts |grep Phys
  1:        483          0        Phys-irq  i8042
  4:      44416          0        Phys-irq  serial
  8:          1          0        Phys-irq  rtc
  9:          0          0        Phys-irq  acpi
 19:      11148          0        Phys-irq  aic7xxx
 20:    8444199          0        Phys-irq  aic7xxx
 21:     100303          0        Phys-irq  ohci_hcd:usb1
 22:   13337459          0        Phys-irq  libata

Normalerweise werden
Das Problem ist eher, dass ein PCI-Bus immer nur 4 physikalische
IRQ-Leitungen hat. Wenn man dann alles an einem Bus betreibt, dann
werden da mal schnell sehr viele einzelne IRQ's doppelt und dreifach
vergeben. Abhilfe ist da wenig möglich ausser abschalten was abzuschalten
geht oder man hat mehr als einen PCI-Bus was aber nur bei Server-Boards
wie meinem Tyan, der Fall sein dürfte. Das blöde ist, dass heute viele
Karten auf dem Markt sind, die gleich mehrere IRQ-Leitungen benötigen,
was die Sache auch nicht einfacher macht. Ich hatte ziemliche Probleme
mit einer USB2 Karte und habe dieser erst mal wieder raus genommen.
Erst im Anschluss habe ich dann eine mögliche Lösung im Netz gefunden:

Versuch in der Zeile mal den Parameter _noirqdebug_ mit anzugeben. Das
macht das Sharing der IRQ's etwas einfacher und es gehen dann keine
bzw. nicht so viele IRQs verloren.

Den von mir gefundenen Artikel kann ich Dir leider nicht geben.
Ich habe seit dem keine Probleme mehr, aber auch aus Zeitgründen seit
dem keine großen weiteren Tests mehr durchgeführt (Bei mir ist eine
SCSI-Karte einer DomU für ein Backuproboter zugeordnet, da aber
bacula unter Debian derzeit kein ssl spricht (ist angelblich nicht
GPL3 konform) habe ich dort nicht weiter getestet.
Schreib mal zurück, wie das Ergebnis aussieht. Ich bin da auch
neugierig.

MfG...
Pierre Bernhardt