USB in DomU: Unterschied zwischen den Versionen

Aus Neobikers Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''USB Geräte in DomU einbinden'''
=== USB-Drucker in DomU einbinden ===
 
Zuerst die USB Geräte in der Dom0 herausfinden:
Zuerst die USB Geräte in der Dom0 herausfinden:
<pre>
<pre>
xen0:~# lspci | grep -i usb
xen0:~# lspci | grep -i usb
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
Zeile 29: Zeile 29:
xen0:~#
xen0:~#
</pre>
</pre>
Die Devices markiert man in ''/boot/grub/menu.lst'' (pciback.hide=(00:1d.0)), aber da ich jetzt nicht die Dom0 neu booten möchte, mache is das eben online:
<pre>
<pre>
xen0:~# for slot in 0 1 2 7; do
xen0:~# for slot in 0 1 2 7; do
Zeile 41: Zeile 43:
<pre>
<pre>
pci      =[ '00:1d.1','00:1d.2','00:1d.0','00:1d.7' ]
pci      =[ '00:1d.1','00:1d.2','00:1d.0','00:1d.7' ]
usbdevice='host:04a9:1093'
</pre>
</pre>
Der ''usbdevice'' Eintrag ist eigentlich für einen VMX Guest, ich denke der wird evtl. nicht benötigt. Muss das aber erst noch testen, so geht's jedenfalls schonmal :-)
Sollte der USB-Drucker nicht mehr gehen, hat sich bewährt, das ''uhci_hcd / ohci_hcd'' Modul in der DomU neu zu laden (an dem USB-Device hängt der Drucker bei mir), dann wird der USB-Drucker neu erkannt - ''usblp'' wird dann auch geladen.
 
Sollte der USB-Drucker nicht mehr gehen, hat sich eben bewährt, das uhci_hcd Modul neu zu laden, dann wird der USB-Drucker auch wieder neu erkannt.
<pre>
<pre>
rmmod uhci_hcd
rmmod uhci_hcd
modprobe uhci_hcd
modprobe uhci_hcd
</pre>
</pre>
'''Probleme von USB Geräten in DomU'''
USB-Geräte können unter XEN - das zeigen diverse Einträge in den Mailinglisten und meine eigenen Erfahrungen (leider!) - wie insgesamt PCI-Geräte in DomUs durchaus Probleme verursachen.
Meine Analyse führt mich zum Ergebnis, dass zumindest bei meinen alten Rechnern und den PCI-Karten IRQ mehrfach zugeordnet werden, was unweigerlich zu Stabilitätsproblemen führt, wenn man die PCI-Devices nicht in der Dom0 verwendet.
Ein Auszug meiner aktuuellen Konfiguration:
<pre>dmesg | grep GSI | sort -u
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 22
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:02:07.0[A] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:02:08.0[A] -> GSI 20 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:02:0d.0[A] -> GSI 21 (level, low) -> IRQ 18
xen0:~#</pre>
Man sieht, dass z.B. der IRQ 20 mehrfach vergeben ist. Der IRQ 20 wird benutzt von:
<pre>xen0# for dev in 00:1d.2 00:1f.1 02:07.0; do lspci -nn -s $dev; done
00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] (rev 01)
02:07.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller [1095:3112] (rev 02)
</pre>
Man sieht die Katastrophe: Wenn man an diesen(!) USB-Port in einer DomU den USB-Drucker anschliesst, friert der Server ein, da weder die IDE noch die SATA Disk mehr funktionieren. Wenn man einen der anderen beiden USB-Ports (00:1d.0[A] IRQ22 oder 00:1d.1[B] IRQ21) verwendet, hat man dieses Problem nicht (zumindest geht's bei mir).
Wie man diese Probleme lösen kann, beschreibe ich hier: [[XEN-PCI|XEN und PCI]].

Aktuelle Version vom 18. Februar 2007, 09:44 Uhr

USB-Drucker in DomU einbinden

Zuerst die USB Geräte in der Dom0 herausfinden:


xen0:~# lspci | grep -i usb
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
xen0:~#

PCI Devices mittels LateBinding in DomU einbinden:

  • USB Gerät identifizieren
  • Betroffene Module entladen (usb*)
  • Device ins PCI Backend exportieren
xen0:~# cat /proc/bus/usb/devices | grep P: | grep -v "Vendor=0000"
P:  Vendor=04a9 ProdID=1093 Rev= 1.10
xen0:~#
xen0:~# lsmod | grep usb
Module                  Size  Used by
usblp                  12768  0
usbcore               113380  4 usblp,ehci_hcd,uhci_hcd
xen0:~#
xen0:~# rmmod usblp ehci_hcd uhci_hcd
xen0:~#

Die Devices markiert man in /boot/grub/menu.lst (pciback.hide=(00:1d.0)), aber da ich jetzt nicht die Dom0 neu booten möchte, mache is das eben online:

xen0:~# for slot in 0 1 2 7; do
 SLOT=0000:00:1d.$slot
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
 echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
done
xen0:~#

USB Einträge in DomU Konfiguration:

pci      =[ '00:1d.1','00:1d.2','00:1d.0','00:1d.7' ]

Sollte der USB-Drucker nicht mehr gehen, hat sich bewährt, das uhci_hcd / ohci_hcd Modul in der DomU neu zu laden (an dem USB-Device hängt der Drucker bei mir), dann wird der USB-Drucker neu erkannt - usblp wird dann auch geladen.

rmmod uhci_hcd
modprobe uhci_hcd

Probleme von USB Geräten in DomU

USB-Geräte können unter XEN - das zeigen diverse Einträge in den Mailinglisten und meine eigenen Erfahrungen (leider!) - wie insgesamt PCI-Geräte in DomUs durchaus Probleme verursachen.

Meine Analyse führt mich zum Ergebnis, dass zumindest bei meinen alten Rechnern und den PCI-Karten IRQ mehrfach zugeordnet werden, was unweigerlich zu Stabilitätsproblemen führt, wenn man die PCI-Devices nicht in der Dom0 verwendet.

Ein Auszug meiner aktuuellen Konfiguration:

dmesg | grep GSI | sort -u
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 22
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:02:07.0[A] -> GSI 18 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:02:08.0[A] -> GSI 20 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:02:0d.0[A] -> GSI 21 (level, low) -> IRQ 18
xen0:~#

Man sieht, dass z.B. der IRQ 20 mehrfach vergeben ist. Der IRQ 20 wird benutzt von:

xen0# for dev in 00:1d.2 00:1f.1 02:07.0; do lspci -nn -s $dev; done

00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] (rev 01)
02:07.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller [1095:3112] (rev 02)

Man sieht die Katastrophe: Wenn man an diesen(!) USB-Port in einer DomU den USB-Drucker anschliesst, friert der Server ein, da weder die IDE noch die SATA Disk mehr funktionieren. Wenn man einen der anderen beiden USB-Ports (00:1d.0[A] IRQ22 oder 00:1d.1[B] IRQ21) verwendet, hat man dieses Problem nicht (zumindest geht's bei mir).

Wie man diese Probleme lösen kann, beschreibe ich hier: XEN und PCI.