XEN 3.3: USB ==> domU ??

[Sil3ntWarri0r]

Hi,

da in einer meiner domU's ein paar Serverdienste laufen, unter anderem auch cups würde ich gerne dort auch einen USB Drucker einbinden, leider ist es wohl gar nicht so einfach, den USB-Port in die domU zu bekommen. Habe nun schon viel gegoogelt, aber alles hat bisher nicht so recht geholfen...vielleicht weiss hier jemand Rat.

Danke.

[stefan.becker]

Kannst du den Drucker nicht in der DOM 0 einrichten und freigeben, in DOM 1-n über CUPS als Netzwerkdrucker ansprechen?

[Sil3ntWarri0r]

Wollte dinglichst vermeiden irgendwelche Server in der dom0 laufen zu lassen und dazu gehört auch cups...welchen ich dazu in dem dom0 installieren müsste.

[thounder]

Ich würde auch schauen so wenig wie möglich in die Dom0 zu installieren.
Funktioniert es bei Xen 3.3 nicht auch über den export der USB Schnitstellen an die DomU?
Alla: per lspci die Hardwareadresse aller USB Controller rausfinden z.B. 0000:00:10.0 diese dann alle in der menu.lst in die module-Zeile wie folgt eintragen pciback.hide=(00:10.0)(xxxxxx) usw. dann rebooten und die entesprechende Config der DomU pci= [ '00:10.0', 'xxxxx' ]
eintragen und starten
evtl. musst du noch die module manuell unter der Dom0 entladen

Versuchs mal damit ....

Grüße

thounder

[Sil3ntWarri0r]

Hab ich auch schon ausprobiert, aber in der domU wird der USB Controller nicht erkannt...

Werde mal weiter versuchen, der Sache auf den Grund zu kommen...

[thounder]

was sagt den lspci in der DomU? poste doch mal deine menu.lst, die Ausgabe von lspci in der DomU und Dom0, lsmod |grep usb in der Dom0 und DomU.
Dann würde mich noch interessieren ob du die Kernel Module auch in die DomU kopiert hast. Ich gehe von Para-Virtualisierung aus richtig?

Grüße

thounder

[Sil3ntWarri0r]

dom0:
server ~ # lspci
00:00.0 Host bridge: nVidia Corporation Device 07c3 (rev a2)
00:00.1 RAM memory: nVidia Corporation Device 07cb (rev a2)
00:01.0 RAM memory: nVidia Corporation Device 07cd (rev a1)
00:01.1 RAM memory: nVidia Corporation Device 07ce (rev a1)
00:01.2 RAM memory: nVidia Corporation Device 07cf (rev a1)
00:01.3 RAM memory: nVidia Corporation Device 07d0 (rev a1)
00:01.4 RAM memory: nVidia Corporation Device 07d1 (rev a1)
00:01.5 RAM memory: nVidia Corporation Device 07d2 (rev a1)
00:01.6 RAM memory: nVidia Corporation Device 07d3 (rev a1)
00:02.0 RAM memory: nVidia Corporation Device 07d6 (rev a1)
00:03.0 ISA bridge: nVidia Corporation Device 07d7 (rev a2)
00:03.1 SMBus: nVidia Corporation Device 07d8 (rev a1)
00:03.2 RAM memory: nVidia Corporation Device 07d9 (rev a1)
00:03.4 RAM memory: nVidia Corporation Device 07c8 (rev a1)
00:04.0 USB Controller: nVidia Corporation Device 07fe (rev a1)
00:04.1 USB Controller: nVidia Corporation Device 056a (rev a1)
00:08.0 IDE interface: nVidia Corporation Device 056c (rev a1)
00:0a.0 PCI bridge: nVidia Corporation Device 056d (rev a1)
00:0b.0 PCI bridge: nVidia Corporation Device 056e (rev a1)
00:0c.0 PCI bridge: nVidia Corporation Device 056f (rev a1)
00:0d.0 PCI bridge: nVidia Corporation Device 056f (rev a1)
00:0e.0 IDE interface: nVidia Corporation Device 07f0 (rev a2)
00:0f.0 Ethernet controller: nVidia Corporation Device 07dc (rev a2)
00:10.0 VGA compatible controller: nVidia Corporation Device 07e3 (rev a2)
01:04.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
01:06.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

server ~ # lsmod | grep usb
server ~ #

title Gentoo XEN 64
root (hd0,0)
kernel /boot/x86_64/xen.gz dom0_mem=98M
module /boot/x86_64/kernel-2.6-xen64 root=/dev/sda5 pciback.hide=(00:04.0)(00:04.1)



domU:
netservices ~ # lspci
netservices ~ #

netservices ~ # lsmod | grep usb
netservices ~ #


lsmod wird wohl keine Ergebnisse liefern, da ich keine Module in Verwendung habe, sondern alles fest in den Kernel integriert habe, dies ist meines Wissens auch erforderlich, um pciback.hide verwenden zu können.
Der USB-Controller wird zwar noch in der dom0 angezeigt (lspci), aber mit lsusb werden keine Geräte mehr angezeigt, seitdem ich die Adressen mit der Option pciback.hide verwende.


Einen guten Rutsch ins neue Jahr !

[thounder]

THX für den guten Rutsch, hat bei mir zu gut funktioniert :-) drum war ich krank und hab mich nicht gemeldet. ....

Falls dein Problem noch besteht...

wie sieht den die Config für die DomU aus? vom Prinzip her sieht ja alles gut aus.
Wo ich mir grad noch nicht sicher bin ist ob dein Kernel das pciback auch unterstützt.

Grüße

thounder

[Sil3ntWarri0r]

Hi,
ja das Problem besteht weiterhin.

Meine config:

# general
name = "NET_Services";
memory = 128;

# booting
kernel = "/boot/services/kernel-2.6-xen";

# virtual harddisk
disk = [ 'phy:/dev/server/services,ioemu:sda,w' ];
root = "/dev/sda3 w";

#PCI-Device
pci = [ '04.1' ];

# virtual network
vif = [ 'mac=aa:cc:11:00:00:02, bridge=xenbr1'
, 'mac=aa:cc:11:02:01:02, bridge=xenbr0' ];
dhcp = "none";

extra = 'console=xvc0'

Was ich mittlerweile herausgefunden habe, ist dass wenn ich den anderen USB-Controller mit

#PCI-Device
pci = [ '00:04.0' ];

verwende, dass dann der Kernel der domU beim Boot abstürzt. Prinzipiell benötige ich aber nur einen USB-Controller und da das Gerät gerade am zweiten angeschlossen ist, hatte ich versucht diesen einzubinden. Wenn ich den ersten einbinde bzw. beide erhalte ich folgende Kernelmeldung:

[ 1.290620] ohci_hcd 0000:00:04.0: enabling device (0000 -> 0002)
[ 1.290973] ohci_hcd 0000:00:04.0: OHCI Host Controller
[ 1.291073] ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 1
[ 1.291111] ------------[ cut here ]------------
[ 1.291114] kernel BUG at drivers/xen/core/evtchn.c:808!
[ 1.291116] invalid opcode: 0000 [#1] SMP
[ 1.291120] Modules linked in:
[ 1.291122]
[ 1.291124] Pid: 1, comm: swapper Not tainted (2.6.27-xen-r2-xen-domU #3)
[ 1.291127] EIP: 0061:[<c0380ebb>] EFLAGS: 00010096 CPU: 0
[ 1.291133] EIP is at evtchn_get_xen_pirq+0x19/0x2a
[ 1.291135] EAX: ffffffff EBX: c05ece00 ECX: c05db7e0 EDX: 00000000
[ 1.291138] ESI: 00000014 EDI: 00000000 EBP: c7825db4 ESP: c7825db4
[ 1.291140] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
[ 1.291143] Process swapper (pid: 1, ti=c7824000 task=c7820000 task.ti=c7824000)
[ 1.291146] Stack: c7825de8 c0380eef 39303139 00205d39 c7825de4 c7a46460 c7825e4c 0000000a
[ 1.291155] c7825e20 c0336954 c05ece00 00000014 00000014 c7825e10 c024d957 c05ece30
[ 1.291164] 00000000 00000000 c05ece14 c7a05440 c7a05440 00000014 c03d2f42 c7825e28
[ 1.291173] Call Trace:
[ 1.291175] [<c0380eef>] ? startup_pirq+0x23/0x10b
[ 1.291181] [<c0336954>] ? vsnprintf+0x3ea/0x425
[ 1.291186] [<c024d957>] ? setup_irq+0x10b/0x1ad
[ 1.291191] [<c03d2f42>] ? usb_hcd_irq+0x0/0x8f
[ 1.291196] [<c024db4c>] ? request_irq+0x84/0x9c
[ 1.291200] [<c03d32d3>] ? usb_add_hcd+0x1a1/0x363
[ 1.291205] [<c03dbb0a>] ? usb_hcd_pci_probe+0x23e/0x2b9
[ 1.291209] [<c0342303>] ? pci_call_probe+0xd/0x10
[ 1.291214] [<c0342337>] ? __pci_device_probe+0x31/0x43
[ 1.291219] [<c034236a>] ? pci_device_probe+0x21/0x34
[ 1.291223] [<c0360ad8>] ? really_probe+0x74/0xf2
[ 1.291228] [<c0360ba0>] ? driver_probe_device+0x37/0x40
[ 1.291233] [<c0360c52>] ? __driver_attach+0x3a/0x59
[ 1.291237] [<c035ffa6>] ? bus_for_each_dev+0x35/0x5a
[ 1.291241] [<c0332ec6>] ? kobject_init_and_add+0x20/0x22
[ 1.291247] [<c0360c85>] ? driver_attach+0x14/0x16
[ 1.291251] [<c0360c18>] ? __driver_attach+0x0/0x59
[ 1.291255] [<c0360503>] ? bus_add_driver+0x93/0x143
[ 1.291259] [<c0361043>] ? driver_register+0x69/0x8d
[ 1.291264] [<c034254e>] ? __pci_register_driver+0x3f/0x60
[ 1.291268] [<c061ed37>] ? ohci_hcd_mod_init+0x6a/0x97
[ 1.291274] [<c020203d>] ? _stext+0x3d/0x132
[ 1.291278] [<c061eccd>] ? ohci_hcd_mod_init+0x0/0x97
[ 1.291282] [<c02ab815>]

Dann wars dass mit dem Start der domU. Nun kann ich nicht sagen, ob am Kernel der domU etwas nicht stimmt oder ob der Fehler an Einstellungen in der dom0 liegt...

Hoffe immernoch auf einen entscheidenden Tipp.

[thounder]

Also soweit ich weiß musst du bzw. solltest du beide USB Kontroller an die selbe DomU durchreichen! Bei mir geht es nur so vernünftig ...

Schreib mir doch mal deine ICQ Nr. oder MSN per PM dann können wir uns evtl. leichter und schneller veständigen.

Grüße

thounder

[Razorblade]

Ich habe fast einen identischen Oops in einer DomU bei dem Versuch eine PCIe (mit 4 Serial ports) einzubinden:

------------[ cut here ]------------
kernel BUG at drivers/xen/core/evtchn.c:1148!
invalid opcode: 0000 [#1]
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in: 9900(N+)
Supported: No

Pid: 2857, comm: modprobe Tainted: G (2.6.27.5-hg2a600439ce68 #6)
EIP: 0061:[<c01f7e8e>] EFLAGS: 00010096 CPU: 0
EIP is at evtchn_get_xen_pirq+0x14/0x1f
EAX: ffffffff EBX: 00000002 ECX: c0322d60 EDX: 00000000
ESI: 00000010 EDI: 00000000 EBP: ffffffda ESP: dfaa1da0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0069
Process modprobe (pid: 2857, ti=dfaa0000 task=dfab5580 task.ti=dfaa0000)
Stack: c01f7fa0 00000000 c010c585 f5100000 00000000 f5100000 c0313320 00000380
00000000 ffffffda c0130c03 00000000 dfb72600 00000010 00aa1e14 c0313334
dfb72600 fffffff4 00000010 e10276f3 c0130d44 00000080 df812400 00000000
Call Trace:
[<c01f7fa0>] startup_pirq+0x27/0x105
[<c010c585>] __ioremap_caller+0x2a8/0x2e3
[<c0130c03>] setup_irq+0x185/0x24c
[<e10276f3>] serial9900_interrupt+0x0/0x86c [9900]
[<c0130d44>] request_irq+0x7a/0x96
[<c01f49d6>] __driver_attach+0x0/0x55
[<e1028d37>] serial9900_probe+0x14f/0x178 [9900]
[<c01d5a36>] pci_device_probe+0x36/0x57
[<c01f4960>] driver_probe_device+0xb4/0x12a
[<c01f4a0d>] __driver_attach+0x37/0x55
[<c01f4239>] bus_for_each_dev+0x34/0x56
[<c01f47fc>] driver_attach+0x11/0x13
[<c01f49d6>] __driver_attach+0x0/0x55
[<c01f458f>] bus_add_driver+0x8a/0x1a7
[<c01c9a67>] kset_find_obj+0x18/0x40
[<e102c000>] serial9900_init+0x0/0x66 [9900]
[<c01f4b65>] driver_register+0x6d/0xc1
[<e102c000>] serial9900_init+0x0/0x66 [9900]
[<c01d5bd6>] __pci_register_driver+0x35/0x63
[<e102c051>] serial9900_init+0x51/0x66 [9900]
[<c0102037>] _stext+0x37/0x111
[<c010badc>] do_page_fault+0x60f/0xb5f
[<c012fa61>] sys_init_module+0x87/0x176
[<c0103e96>] syscall_call+0x7/0xb
[<c0280000>] rpc_depopulate+0xef/0xf9
=======================
Code: ff ff 00 00 c1 e0 0c 0d 00 00 00 10 89 04 b5 c0 4b 38 c0 5b 5b 5e c3 83 f8 0f 7e 19 8b 14 85 c0 4b 38 c0 89 d0 c1 e8 1c 48 74 04 <0f> 0b eb fe c1 ea 0c 0f b7 c2 c3 57 56 89 c6 53 83 ec 04 8b 14
EIP: [<c01f7e8e>] evtchn_get_xen_pirq+0x14/0x1f SS:ESP 0069:dfaa1da0
---[ end trace 9d179f97cc6fc995 ]---

[Sil3ntWarri0r]

Also prinzipiell habe ich kein Problem beide Controller durchzureichen, da diese nur in dieser domU verwendet werden, aber das Problem ist, dass der erste USB-Controller seinen IRQ mit der Grafikkarte shared und ich da befürchte, dass das Ärger macht.



server ~ # dmesg |grep GSI | sort -u
[ 0.000000] IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
[ 1.104083] nvidiafb 0000:00:10.0: PCI INT A -> Link[SGRU] -> GSI 23 (level, low) -> IRQ 23
[ 1.140054] e1000 0000:01:04.0: PCI INT A -> Link[LNKA] -> GSI 19 (level, low) -> IRQ 19
[ 1.546857] e1000 0000:01:06.0: PCI INT A -> Link[LNKB] -> GSI 18 (level, low) -> IRQ 18
[ 1.954294] forcedeth 0000:00:0f.0: PCI INT A -> Link[LMAC] -> GSI 22 (level, low) -> IRQ 22
[ 2.477826] pciback 0000:00:04.1: PCI INT B -> Link[LUB2] -> GSI 21 (level, low) -> IRQ 21
[ 2.479017] pciback 0000:00:04.0: PCI INT A -> Link[LUB0] -> GSI 20 (level, low) -> IRQ 20
[ 3.481842] ahci 0000:00:0e.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23


Mhh, sehe gerade, dass ohne die USB-Controller die Liste sehr geschrumpft ist und auch die GraKa einen anderen IRQ als die beiden pciback Geräte...


@Razorblade
Irgendwo scheint da noch der Wurm drin zu sein...

[Razorblade]

Vielleicht ist IRQ-Sharing das Problem? Meine PCIe Karte teilt sich auch mit diversen anderen Geräten den Interrupt (USB, Raid Controller). Werde mal versuchen mit einigen BIOS Einstellungen dedizierte IRQs zu bekommen...

[Sil3ntWarri0r]

Beim IRQ-Sharing tritt das Problem aber meist erst später auf, z.B. du verwendest einen USB-Controller in der domU (domU läuft ohne anfänglichen Kernel-Absturz), der sich mit dem HDD-Controller einen IRQ teilt, dann passiert meist folgendes, man steckt ein USB-Gerät ein, die domU krallt sich den IRQ und der HDD-Controller bekommt keinen IRQ mehr, was dazu führt, dass die HDD nicht mehr angesprochen werden kann, was ziemlich blöd wäre...

Also IRQ-Shareing bei in domU's verwendeten Devices sollte unbedingt vermieden werden, da dies in jedem Fall zu Instabilität des Systems führt.

[Razorblade]

Leider läßt das mein Board (im konkreten Fall) nicht anders zu, nur 2 PCIe, beide mit Systemressourcen die ich brauche (AHCI und PATA) doppelt belegt.
Aber das sollte bei mir sowieso nur ein Test für das richtige Setup sein, da habe ich dann genug PCIe Slots und vielleicht klappt es da auch ohne Doppelbelegung und Oops...

[thounder]

Also ich habe als Kernelparameter im Grub bei den modulen noch stehen: noirqdebug und in der DomU config noch die Parameter: extra="2 noirqdebug swiotlb=force"
damit klappt es bei mir ganz gut.
Ich reiche USB komplett an eine DomU durch, eine Sat Karte an eine weitere DomU und auch diverse Win DomU's laufen. Es laufen bei mir immer 5 Linux DomU's und bisher maximal weitere 6 Win DomU's zur selben Zeit. .... Es geht also ...

[Razorblade]

Werde es mal mit "swiotlb=force" probieren, noirqdebug hatte ich schon.