XEN VDR domU - Probleme beim Hardwarezugriff

sk8ter · 21. Februar 2010

1. Ich werde den Titel des Thread anpassen sobald ich einkreisen kann um was sich mein Problem überhaupt handelt.

2. Da es sich hier um ein XEN Problem handelt bitte keine sicherlich gutgemeinten Ratschläge zu KVM, ESX und XEN ist tot, ausser es kann mir jemand aus eigener Erfahrung, sprich laufendes System, bestätigen dass VDR in dieser Konstellation, inkl. durchreichen von mehr als 2 PCI-Karten problemlos läuft .

3. Da ich Momentan ziemlich im dunkeln tappe und mein technisches Verständnis was Hardware, IRQ's und dergleichen angeht ziemlich dünn ist fehlen hier evtl. wichtige Informationen. Ich werde selbstverständlich alles nachliefern wenn mich jemand auf die Richtige Spur bringt.

4. Nach ettlichen Fehlschlägen habe ich mir mein (nachwievor bescheidenes VDR Wissen) Schritt für Schritt erarbeitet, zuerst yaVDR "Standard" = läuft, yaVDR Streamdev-Client = läuft und nun VDR XEN domU Server = läuft theoretisch.

Nun aber zum Problem:
Wenn ich die VDR domU als einziges System starte, so läuft VDR zu ca. 95% in Ordnung, sobald aber andere domU's dazu kommen kommt es zu pixeligem Bild, Tonzischer, Tonaussetzern, und dergleichen.

Meine Vermutung geht in die Richtung dass da etwas mit dem HW Zugriff krumm läuft, aber genau bei diesem Punkt verlässt sich mein Wissen.

Zur Konfiguration:
HW:
Dell GX620, Pentium D (kein VT), Gbit LAN onboard, 2GB RAM, div. ATA und SATA Platten, 2x Terratec Cinergy PCI HD

dom0:
Debian Lenny
2.6.26-2-xen-686
xen-hypervisor-3.2-1-i386

menu.lst

Code

title           Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686
root            (hd0,0)
kernel          /xen-3.2-1-i386.gz
module          /vmlinuz-2.6.26-2-xen-686 root=/dev/mapper/vg1-root xencons=off  pciback.hide=(04:00.0)(04:02.0) noirqdebug ro
module          /initrd.img-2.6.26-2-xen-686
savedefault

domU:
Debian Lenny
2.6.26-2-xen-686
vdr-1.7.10
vdr-plugin-streamdev-server
vdr-plugin-live

config

Code

kernel      = '/boot/vmlinuz-2.6.26-2-xen-686'
ramdisk     = '/boot/initrd.img-2.6.26-2-xen-686'
memory      = '512'
pci = ['04:00.0', '04:02.0']
extra = 'xencons=tty swiotlb=force noirqdebug'
root        = '/dev/sda2 ro'
disk        = [
                  'phy:/dev/vg2/vdr-hd-disk,sda2,w',
                  'phy:/dev/vg2/vdr-hd-swap,sda1,w',
              ]


name        = 'vdr-hd'
vif         = [ 'ip=192.168.9.210,mac=00:16:3E:74:74:93' ]


on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Alles anzeigen

"swiotlb=force noirqdebug" habe ich aus einem anderen Thread, seit dem ich dies gesetzt habe hat sich das Problem aber eher verschlechert.

So, wo muss ich ansetzen, oder muss ich das ganze vergessen? Neue Hardware? Neue Installation? Oder gar nur eine kleine Konfigurationsänderung?

Ich denke dass ist mein letzter Versuch für lange, danach werde ich mich wohl oder übel mit einem "normalen" VDR Zufrieden geben müssen.

Gruss
Sk8ter

tecfreak · 21. Februar 2010

Führe bitte folgendes Script aus und poste die Ausgabe hier:

Bash

#!/bin/bash
for dev_id in $( lspci | cut -d\  -f1 ) ; do
    irq=$( dmesg | grep GSI | grep $dev_id | awk '{print $12}' | head -n 1 )
    device=$( lspci | grep $dev_id | cut -d\  -f2- )
    [ -n "$irq" ] && echo "$irq: $dev_id - $device"
done

...dazu noch ein "cat /proc/interrupts" und ein "lspci -v | grep IRQ" .
Das alles in der dom0.

Gibt es irgendwelche Meldungen in den logs in der vdr domU?

sk8ter · 21. Februar 2010

Hallo tecfreak,
Erstmal danke dass du Dich meinem Problem annimmst. Der Script gibt mir leider gar nichts aus, weder auf der Konsole noch in einem log. Mach ich da was falsch?

Während dem zusammentragen der Daten stelle ich grad fest dass auch der Befehl "dmesg | grep GSI | sort -u" keine Ausgabe mehr bringt. Also Neustart, wieder nichts. Ich seh grad ich hab der dom0 noch die Kerneloption "pci=noacpi" hinzugefügt, die wieder raus, nochmal Neustart und jetzt bringt auch dein Skript eine Ausgabe.

Code

->: 00:00.0 - Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
->: 00:01.0 - PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
->: 00:02.0 - VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
->: 00:1c.0 - PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
->: 00:1c.1 - PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
->: 00:1f.1 - IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
->: 00:1f.2 - IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
->: 00:1f.3 - SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
->: 02:00.0 - Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
->: 04:00.0 - Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)
->: 04:02.0 - Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01)

Alles anzeigen

Ansonsten hab ich

Code

# cat /proc/interrupts 
           CPU0       CPU1       
  1:          2          0  Phys-irq-level     i8042
  8:          2          0  Phys-irq-level     rtc0
  9:          0          0  Phys-irq-level     acpi
 12:          4          0  Phys-irq-level     i8042
 16:       2639          0  Phys-irq-level     peth0
 20:       9139          0  Phys-irq-level     ata_piix
256:      16360          0  Dynamic-irq-level     timer0
257:       1433          0  Dynamic-irq-level     resched0
258:         46          0  Dynamic-irq-level     callfunc0
259:         12          0  Dynamic-irq-level     spinlock0
260:          0       1598  Dynamic-irq-level     resched1
261:          0        407  Dynamic-irq-level     callfunc1
262:          0          5  Dynamic-irq-level     spinlock1
263:          0      18598  Dynamic-irq-level     timer1
264:        145          0  Dynamic-irq-level     xenbus
265:          0          0  Dynamic-irq-level     suspend
NMI:          0          0   Non-maskable interrupts
RES:       1433       1598   Rescheduling interrupts
CAL:         46        407   function call interrupts

Alles anzeigen

Code

# lspci -v | grep IRQ
	Flags: fast devsel, IRQ 11
	Flags: bus master, medium devsel, latency 0, IRQ 16
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
	Flags: medium devsel, IRQ 17
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Flags: medium devsel, IRQ 16
	Flags: medium devsel, IRQ 18

In den logs finde ich auch ncihts relevantes, weiss aber natürlich auch nicht nach was ich suchen müsste. Ich häng Dir da mal was an.

Ansonsten war ich natürlich auch nicht untätig und bin mal diesem Beitrag gefolgt.
http://www.neobiker.de/wiki/index.php?title=XEN-PCI
Nachdem ich alles im BIOS deaktiviert habe was irgendwie geht bekomme ich noch das folgende (ist auch der Stand der Logs die ich oben gepostet habe)

Code

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port [8086:2771] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
00:02.1 Display controller [0380]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2776] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01)
02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express [14e4:1677] (rev 01)
04:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01)
04:02.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01)

Alles anzeigen

und

Code

# dmesg | grep GSI | sort -u
[    0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[    1.743422] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
[    1.743799] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
[    1.744178] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
[    1.838417] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[    1.838417] ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 (level, low) -> IRQ 18
[    2.617630] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[    2.721870] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 16
[    2.791490] ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) -> IRQ 20
[    9.212222] ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 17

Alles anzeigen

Daraus habe ich mit meinem Unwissen abgeleitet dass IRQ 16 dass Problem sein könnte, und habe versucht nur '04:02.0' an die domU weiterzureichen. Leider mit dem selben Ergebnis.

Gefühlt macht es den Anschein dass das Problem entweder von Disk oder Netzwerkaktivität herrührt. So entsteht zum Beispiel wenn ich eine weitere domU starte ein Hallen teilweise "fast" Echo bei der Fernsehausgabe. Und wie gesagt, damit es zu keinem Missverständniss kommt, Der VDR Server hat als Ausgabedevice nur den streamdev-server. Geschaut wird an einem Client.

So, ich hoffe Du kannst mit dem schon mal was anfangen.

Gruss
Pascal

Razorblade · 22. Februar 2010

Ich würde die Speicher-Zuweisung statisch einstellen anstatt (default) Memory Ballooning zu betreiben.
Falls der Pentium ein Dual-Core Prozessor ist, könnte auch die statische Zuweisung der CPU-Cores helfen (einen eigenen für vdr, dom0 und die restlichen domU teilen sich einen)

Siehe dazu die (v)CPU und dom0_mem Parameter in den Beispiel xm's sowie xend-config.sxp

karlson · 22. Februar 2010

Moin,

ja, das Sharing von IRQ16 mit der NIC ist bestimmt ein Problem. In
mehrfacher Hinsicht, da die NIC die ist, über die der Client angeschlossen
zu sein scheint.

Anderseits ist es echt merkwürding, dass es zu Problemen kommt, wenn
Du die nicht verwendest.

Welches Xen? Willst Du Dir nicht mal selber eines übersetzen und einen
schönen alten Kernel nehmen?

Ist MSI mit im Spiel? Probier mal pci=nomsi in der DomU, ggf. in der Dom0.

GrK.

don-baba · 22. Februar 2010

Ich hatte mal Probleme mit einem IRQ Konflikt der Firewire Schnittstelle mit einem PCI Steckplatz mit einer DVB-Karte. Musste die Firewire Schnittstelle im BIOS aktivieren (obwohl ich die nie genutzt habe). Erst dann klappte es mit der DomU.

sk8ter · 22. Februar 2010

Um das ganze ein wenig zu entflechten, habe ich alles was nicht wirklich Auswirkungen gezeigt hat, aus den Konfigurationen entfernt, um nicht irgendwo einem Phantom hinterher zu rennen. Zur Zeit teste ich mal nur mit zwei domU's. Solange das nicht geht macht es IMHO keinen Sinn noch mehr ran zu hängen.
Rein subjektiv habe ich den Eindruck dass das festlegen des dom0 Memory den grössten Effekt gezeigt hat, ich bin aber noch weit entfernt von "es funktioniert wie es sollte".

Ich bin mir am überlegen einen neuen Server aufzubauen, da Dies ohnehin noch geschehen würde, dazu hätte ich Momentan ein Asus Board (siehe Signatur) frei. Meint Ihr dass macht Sinn und welches ist denn in Euren Augen momentan die idealste Distribution für XEN? Ich hab da gesehen dass es fertige Debian liveCD's gibt (was mir als Disti ohnehin am sympatischten ist), wenn ich aber so lese scheint OpenSuse (was mir nicht so passt) recht gut am Ball zu sein.

Des weiteren würde sich die Frage nach Hypervisor und Kernelversion stellen.

Selbstverständlich können wir natürlich auch auf der bestehenden Hardware weiterfahren, wenn ich aber so lese, jetzt haben mir hier schon drei Leute geantwortet und es scheint bei allen zu laufen, dann zweifle ich schon langsam etwas an dieser Dell Gurke.

Gruss
Sk8ter

P.S.: Seit irgendeiner Änderung (leider finde ich nicht heraus welche) kann ich die domU's nicht mehr sauber herunter fahren. Diese bleiben bei "system halt" stehen.

menu.lst

Code

title           Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686
root            (hd0,0)
kernel          /xen-3.2-1-i386.gz dom0_mem=512M
module          /vmlinuz-2.6.26-2-xen-686 root=/dev/mapper/vg1-root xencons=off  pciback.hide=(04:00.0)(04:02.0) noirqdebug ro
module          /initrd.img-2.6.26-2-xen-686
savedefault

/etc/xen/xend-config.sxp

Code

(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 512)
(dom0-cpus 1)

domU - 1

Code

kernel      = '/boot/vmlinuz-2.6.26-2-xen-686'
ramdisk     = '/boot/initrd.img-2.6.26-2-xen-686'
cpus = '0'
vcpus = '1'
memory      = '512'
pci = ['04:00.0', '04:02.0']
extra = 'xencons=tty'
root        = '/dev/sda2 ro'
disk        = [
                  'phy:/dev/vg2/vdr-hd-disk,sda2,w',
                  'phy:/dev/vg2/vdr-hd-swap,sda1,w',
              ]
name        = 'vdr-hd'
vif         = [ 'ip=192.168.9.210,mac=00:16:3E:74:74:93' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Alles anzeigen

domU - 2

Code

kernel      = '/boot/vmlinuz-2.6.26-1-xen-686'
ramdisk     = '/boot/initrd.img-2.6.26-1-xen-686'
memory      = '256'
cpu = '1'
vcpus = '1'
extra = 'xencons=tty'
root        = '/dev/sda2 ro'
disk        = [
                  'phy:/dev/vg2/nas-swap,sda1,w',
                  'phy:/dev/vg2/nas-disk,sda2,w',
                  'phy:/dev/vg2/nas-data,sda3,w',
              ]
name        = 'nas'
vif         = [ 'ip=192.168.9.7,mac=00:16:3E:D0:48:93' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Alles anzeigen

tecfreak · 22. Februar 2010

Zitat

Original von sk8ter
P.S.: Seit irgendeiner Änderung (leider finde ich nicht heraus welche) kann ich die domU's nicht mehr sauber herunter fahren. Diese bleiben bei "system halt" stehen.

Das Problem wird wahrscheinlich die Option "dom0-cpus 1" in der xend-config.sxp sein.

Ansonsten sieht es mit dem Dell Board schlecht aus, da es nur 2 PCI/PCI-X Slots und ein PCIe hat. Da hast du keine Möglichkeit mehr eine der Karten umzustecken um IRQ-Sharing zu vermeiden. Ein Test mit dem Asus-Board wäre sicher einen Versuch wert. Im Bios vorher natürlich alles worauf du später auch verzichten kannst (firewire, sound, usb? usw.) deaktivieren.
Dann reicht es erstmal der dom0 die beiden PCI Karten zu entreissen und nach den IRQs zu schauen.

Zitat

Original von karlson
Ist MSI mit im Spiel? Probier mal pci=nomsi in der DomU, ggf. in der Dom0.

Ohne diesen Parameter startet bei mir der dom0 2.6.26er xen kernel erst garnicht.

sk8ter · 22. Februar 2010

Zitat

Ohne diesen Parameter startet bei mir der dom0 2.6.26er xen kernel erst garnicht.

Könntest Du mir bitte mal deine Kernelparameter für dom0 und domU posten.

Zitat

Ansonsten sieht es mit dem Dell Board schlecht aus,

Ja da hast du natürlich absolut recht.Ich wollte mich natürlcih nicht in Unkosten stürzen bevor ich nicht weiss ob ich dass so wie ich will zum laufen bekomme und dass Asus Board fliegt noch nicht lange hier rum. Stellt sich natürlcih die Fragewas denn ein ideales Board wäre. Mein Plan, wenn dass ganze mal tut, wären 4-5 Karten PCI/PCIe DVB-C/DVB-S(2). Wird das überhaupt gehen?

Was verwendest du für deine dom0, Distribution Versionen Kernel und Hypervisor? Ich hab mir ein wenig Citrix angeschaut dass jetzt kostenfrei ist. Aber es sind relativ wenig Informationen vorhanden und die Community ist denke ich auch nicht so stark.

Gruss

karlson · 22. Februar 2010

Ich nehme Lenny mit selbstkompiliertem Xen 3.4.1 (in einem Punkt auf
3.4.2 gepatcht) und Kernel 2.6.18.8.

menu.lst:

Zitat

title Xen 3.4.1 / Xen 2.6.18.8-xen-3.4.1-amd64 / multi / with cpufreq mgmt
root (hd0,0)
kernel /xen-3.4.1.gz vga=text-80x25 dom0_mem=256M cpuidle cpufreq=dom0-kernel
module /vmlinuz-2.6.18.8-xen-3.4.1-amd64 root=/dev/mapper/space-data_lv_root ro BOOT console=tty0 pciback.hide=(00:02.0)(00:02.1)(00:06.0)(01:07.0
)(01:08.0)(01:09.0) noirqdebug xencons=off
module /initrd.img-2.6.18.8-xen-3.4.1-amd64
savedefault

Alles anzeigen

00:02.0 und 00:02.1 USB
00:06.0 onboard NIC
01:07.0, 08.0, 09.0 sind drei DVB-C Karten.

Beispiel vdr 1.6 DomU:

Zitat

kernel='/boot/domus/vmlinuz-2.6.18.8-xen-3.4.1-686'
ramdisk='/boot/domus/initrd.img-2.6.18.8-xen-3.4.1-686'
extra='pci=nomsi swiotlb=32,force xencons=tty clocksource=jiffies'

name='worf'
memory='256'
root='/dev/xvda1 ro'
vcpus='1'
cpu_weight='512'

disk = [
'phy:/dev/space/worf_lv_root,xvda1,w',
'phy:/dev/space/worf_lv_swap,xvda2,w',
'phy:/dev/sdc1,xvdb1,w'
]

pci = [
'00:06.0',
'01:08.0'
]

Alles anzeigen

IRQ-Verteilung:

Zitat

ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [AUBA] -> GSI 21 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [AUB2] -> GSI 22 (level, low) -> IRQ 20
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APSI] -> GSI 20 (level, low) -> IRQ 23
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:01:09.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC5] -> GSI 16 (level, low) -> IRQ 22
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [APC7] -> GSI 16 (level, low) -> IRQ 22

Alles anzeigen

Interruptverteilung Dom0 (die Nics 02:00.0 und 03:00.0 sind MSI):

Zitat

data:~# cat /proc/interrupts
CPU0 CPU1
1: 8 0 Phys-irq i8042
8: 0 0 Phys-irq rtc
9: 0 0 Phys-irq acpi
14: 50839 0 Phys-irq ide0
251: 2673693 0 Phys-irq libata
252: 869003 0 Phys-irq eth1
253: 282064 0 Phys-irq eth0
256: 8577078 0 Dynamic-irq timer0
257: 150847 0 Dynamic-irq resched0
258: 28 0 Dynamic-irq callfunc0
259: 0 152070 Dynamic-irq resched1

Alles anzeigen

Das selbe in der DomU worf:

Zitat

17: 23251360 Phys-irq saa7146 (0)
19: 20595800 Phys-irq eth0
1280: 24079668 Dynamic-irq timer0
1281: 0 Dynamic-irq resched0
1282: 0 Dynamic-irq callfunc0
1283: 508 Dynamic-irq xenbus
1284: 0 Dynamic-irq suspend
1285: 0 Dynamic-irq pcifront
1286: 162 Dynamic-irq xencons
1287: 124112 Dynamic-irq blkif
1288: 30 Dynamic-irq blkif
1289: 228390 Dynamic-irq blkif
NMI: 0
LOC: 0
ERR: 0
MIS: 0

Alles anzeigen

Der forcedeth Treiber der nvidia onboard NIV kann kein MSI, obwohl
er es behauptet.

Theoretisch sollte allerdings IRQ Sharing gehen, praktisch ist es mir auch
noch nicht gelungen.

Dein Xen ist allerdings sehr alt und der Lenny Xen Kernel gefrickelt.

Gruß,
Karlson.

tecfreak · 22. Februar 2010

Bei mir läuft Distro ct-server 4.01 mit xen 3.4.1 hypervisor und dom0 2.6.26-2-xen kernel @64bit. DomU ebenfalls auf lennys xen kernel @32bit.

Werde wohl aber demnächst den dom0 kernel durch waldis 2.6.18er ersetzen.
Ansonsten warte ich auf den release von xen4 und hoffe, dass da mal ein halbwegs aktueller xen kernel mitgeliefert wird wo auch powernow standardmäßig mit meiner 4850e CPU funkt.

karlson · 22. Februar 2010

sk8ter, mal kurz ge-hijackt, sorry...

Moin tecfreak, das kannst Du vergessen. Du wirst mit dem cpufreq
des Dom0-Kernels vorlieb nehmen müssen. Das ist kein Kernelproblem,
der powernow-k8 ist der Treiber der Wahl, da es sich um eine K8
CPU handelt. Bei dem ist eben der TSC nicht invariant bei Frequenz-
und Spannungswechseln. Allerdings sind die TSC Delta Meldungen beim
Umschalten nur kosmetischer Natur, also kein Grund auf Xen 4.0 zu
warten.

Xen 4.0 macht bei mir im Moment Ärger mit dem forcedeth Treiber,
sonst scheint es zu laufen. Habe aber nicht groß getestet. Als Kernel
weiterhin 2.6.18.8 oder ein 2.6.32er pv_ops Dom0. Das ändert
aber am cpufreq-Handling nix. Kann nur für Treiber neuerer DVB
Karten nötig sein. Aber m.E.n. kann man ale wichtigen Treiber auch
unter 2.6.18 noch übersetzen.

Nimm den 2.6.18er aus dem Xen, der läuft gut. Für die Endian kannst
Du den ipfire Kernel nehmen.

Gruß,
Karlson.

sk8ter · 22. Februar 2010

karlson
Kein Problem, ist interessant mitzulesen wenn auch 3 Nummern zu hoch für mich. Wenn ich Euch jetzt richtig verstehe dann macht auch Squeeze keinen Sinn? Auf den neuen Rechner kommt also wieder Lenny, XEN 3.4.2 (von wo?), und ein "uralt" Kernel 2.6.18? Sehe ich das so richtig?
Aber wie macht Ihr dass wenn Ihr ein aktuelles Ubuntu installieren wollt? Das geht IMHO nicht mal mit meinem 2.6.26.

Gruss
sk8ter

Razorblade · 22. Februar 2010

Hier ist eine ganz gute (hoffe ich jedenfalls, ich habe Sie geschrieben ;-)) Übersicht über die verfügbaren Xen Kernel und die Features:
http://wiki.xensource.com/xenwiki/XenDom0Kernels (Feature Overview)

Grundsätzlich kann man dom0 und domU Kernel mischen und als domU einen beliebigen aktuellen Vanilla-Kernel (mit Xen Guest Support) benutzen, ist also nicht auf den "uralt" 2.6.18 angewiesen. Leider funktioniert mit dem Vanilla-Xen Support kein PCI-Passthrough, das brauchst Du aber natürlich, also scheidet das aus. Ich würde ebenfalls davon abraten, bei PCI-Passthrough pvops-Kernel und 2.6.18 bzw rebased Kernel zu mischen: Wenn pvops, dann in dom0 und domU, wenn 2.6.18 oder rebased dann ebenfalls in dom0 und domU (innerhalb 2.6.18 und rebased habe ich jedoch noch keine Probleme feststellen können)

Wäre da noch die erwähnten pvops Kernel. Dort sind die meisten Features drin und das wird auch ab Xen 4.0 der Standard Kernel sein, aber im Moment gibt es für pvops noch keinen echten "stable" Tree. Meiner Meinung nach für produktive Nutzung (noch) nicht geeignet.

Bleiben eigentlich nur die Forward-Ports/rebased Xen Kernel.
Für Debian gibt es den afaik bis 2.6.26, aber den würde ich bei einer Neuinstallation weder für dom0 noch domU wirklich empfehlen.
Am aktivsten ist hier in der Tat SuSE, die bis 2.6.31 einen aktuellen rebased-Kernel pflegen. Aus diesen Sourcen (adaptiert für Gentoo) läuft bei mir seit Mai 2009 der 2.6.29-r4 als dom0 (mit verschiedenen nicht-pvops domUs) auf einem Gentoo-System ohne Murren.
Ich habe auch die aktuelleren Kernel (2.6.30 und 2.6.31) in den verschiedenen Releases immer wieder probiert, aber nie die gleiche Stabilität wie mit dem 2.6.29-r4 erreicht. Insofern wäre meine Empfehlung vom Xen-Kernel-Support OpenSuSE oder (mein Favorit) Gentoo.

Ich betreibe seit über einem Jahr meinen "VDR-Server" (headless, nur für Aufnahmen und Streamdev) in einer Xen domU und plane auch nicht dies zu ändern. Auf dem Host laufen noch unterschiedlichste andere domU's (allerdings alle ohne weiteres PCI-Passthrough) und ich hatte noch nie irgendwelche "Wechselwirkungen" beim Start/Betrieb dieser...

sk8ter · 23. Februar 2010

Danke Euch allen, Ihr macht mir wieder Mut. Leider wird es in nächster Zeit etwas dünn mit derKapazität für mein VDR- Projekt .Mit den gewonnenen Erkenntnissen ziehe ich mich mal ins Stille Kämmerlein zurück.
Vielen Dank für all die ausführlichen Beschreibungen. Ich werde wohl noch einen inneren Kampf ausführen müssen. Gentoo sehe ich nicht als Option weil ich es noch nie angefasst hatte, (da vermute ich eine zu steile Lernkurve wenn ich das als Erstlingsprojekt mit XEN einsetzen will) und SuSE da muss ich wohl noch mal stark über die Bücher gehen. Oder kann man dort jetzt auch apt-get update && apt-get upgrade ausführen???
Ich werde mich hier melden soblad ich neue Erkenntnisse habe.

Gruss
sk8ter

karlson · 23. Februar 2010

Moin,

Razorblade, gibt es einen einfachen Weg an den Sourcetree des von Dir
verwendeten Kernels mit Xen zu kommen? Den würde ich ja glatt mal
probieren...

GrK.

Razorblade · 23. Februar 2010

Hier gibts immer die aktuellen Gentoo ebuilds aber auch Patches als tar.gz:
http://code.google.com/p/gentoo-xen-kernel/downloads/list?can=1&q=&colspec=Filename+Summary+Uploaded+Size+DownloadCount

2.6.29-r4 ist inzwischen als "deprecated" markiert, den 2.6.31-r11 von gestern habe ich noch nicht probiert, aber der der 2.6.31-r10 von Anfang Januar hatte Probleme mit Passthrough und IRQ-Sharing.

tecfreak · 23. Februar 2010

Die würde ich auch mal ausprobieren wollen. Optimal wäre ja wenn man die gentoo spezifischen patches dann auch weglassen könnte.

karlson

Welches Mainboard hast du in deinem Server und was sind da alles für Erweiterungskarten drin? Die IRQ Verteilung sieht bei dir nämlich garnicht so schlecht aus.

Mir bereitet z.Zt. eine Dualport GBit Intel NIC (PCIe x4) die im PCIe x16 Slot steckt Kopfzerbrechen. Laut Bios teilen sich beide Controller der Dualport NIC den Interrupt mit den ersten beiden PCI Slots.
Wie gesagt muste ich MSI abschalten, da es wohl in lennys 2.6.26er nen bug gibt. Mit aktivem msi würde das wahrscheinlich wieder ganz anders aussehen.
Lieder ist z.Zt. http://kernel-archive.buildserver.net down, wo u.a. waldis 2.6.18er liegt/lag.

tecfreak · 23. Februar 2010

Razorblade

Entspricht das "xen-sources-2.6.29-r4.ebuild" der Kombi aus "linux-2.6.29.6" + "xen-patches-2.6.29-6" ?

karlson

Falls du Zeit hast das mal zu testen, ich hab hier eine komfortable Lösung gefunden den kernel mit den xen-patches zu versehen. (Quelle: http://old.nabble.com/Installa…l-failure-td24367936.html )

Code

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.6.tar.bz2
wget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2
mkdir xen-linux
cd  xen-linux
tar jxf ../xen-patches-2.6.29-6.tar.bz2
tar jxf ../linux-2.6.29.6.tar.bz2
cd linux-2.6.29.6/
ls ../6*.patch1 | sort | while read line ; do patch -p1 -s -i $line ; done

Razorblade · 23. Februar 2010

Die ebuild Datei (kannst Du ja mal reingucken ist nur Text) ist bei Gentoo nur eine Art "Anleitung" was gemacht werden soll, enthält also selbst keinen Code.
Aber ja, die sorgt dafür das zusätzlich zum Standard-Kernel genau die Patches aus dem tgz angewendet werden. (Im Prinzip das gleiche wir die Anleitung die Du gefunden hast, nur halt kompatibel zur Gentoo-Paketverwaltung)

XEN VDR domU - Probleme beim Hardwarezugriff

Jetzt mitmachen!

Teilen