Gentoo 3.7.1 kernel
[ebuild R ] x11-drivers/nvidia-drivers-310.19 USE="X acpi (multilib) tools -pax_kernel" 0 kB
[ebuild R ] app-emulation/xen-4.2.0 USE="-custom-cflags -debug -flask -pae -xsm" 0 kB
Ha simán bebootolom a kernelt, akkor minden működik. Szeretném a rendszert xen domain0 ként használni, hogy kísérletezni tudjak a xennel. Bebootol, és minden jónak tűnik, nvidia driver betölt, hiba nélkül, ám X indulásakor:
[ 49.252] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[ 52.254] (EE) NVIDIA(0): Failed to initialize DMA.
[ 52.254] (EE) NVIDIA(0): *** Aborting ***
[ 52.254]
Fatal server error:
[ 52.254] AddScreen/ScreenInit failed for driver 0
Ez egy Nvidia GT240 512 megás kártya. Az alaplapra van integrálva egy ati kártya is, ami sosem működött megfelelő driver, vagy beállítás híján, és amennyire lehet biosban is ki van kapcsolva. ATI chipsetes alaplap.
A gépben 12 giga memória van, és természetesen 64 bites minden.
Google nem találtam használható választ, még a kérdést sem nagyon, ezért kérem, hátha tud valaki segíteni.
Dual monitor egyébként, nem tudom ez számít-e, de Xen nélkül hibátlan minden.
Hozzászólások
Ha "loglvl=all guest_loglvl=all"-t teszel a xen.gz parancssorba, akkor mi szerepel az "xm dmesg"-ben (vagy "xl dmesg"-ben...), miután a fenti hiba jelenik meg az X naplójában? Ill. dom0 dmesg mit mond ("ignore_loglevel" a dom0 kernel cmdline-ba)?
DMA-hoz valamilyen "alacsonyan" fekvő (alacsony gépi címeken levő), folytonos memóriaterület kell a kártyának. A bare metal kernel ténylegesen a "gépi cím" fogalommal operál. A dom0 kernelben ennek helyére a "pszeudo-fizikai cím" fogalma lép, amely egy leképezéssel a "gépi cím" felett van. A "gépi cím" a Xen hypervisor hatásköre. Így egy DMA-t igénylő dom0 driver-nek a hypervisortól kell a fenti kritériumokat kielégítő (DMA-capable) memóriaterület kérnie.
Ezt az egyes driver persze nem maga teszi -- az csak simán meghívja azokat a "stabil" kernel API-kat, amelyek DMA-alkalmas memóriát szolgáltatnak. Ezek az API-k viselkednek máshogy a bare metal kernelben ill. a dom0-ban futó PV guest kernelben.
Valószínűleg az a baj, hogy az nvidia kártya DMA igényét a bare metal kernel (teljes hatalommal bírva a gépi címek felett) ki tudja elégíteni, a hypervisor (a dom0-beli driver esetén) azonban nem. (Ill. az is lehet, hogy a dom0 kernel eleve máshogyan zónázza/particionálja a pszeudo-fizikai memóriát, mint a bare metal kernel a gépi memóriát -- pl. a DMA32 zóna már a dom0 kernelben kimerülhet (ami mondjuk egy kernel bug lenne, mert "DMA32 zónának" nincs sok értelme egy PV guest-ben), így a kérés esetleg el sem jut a hypervisor-ig.)
Legjobb volna a kérdést a xen-devel listán feltenni (természetesen angolul), pontos Xen, dom0 kernel és nvidia driver verzióval, ill. kártyatípussal.
http://wiki.xen.org/wiki/Paravirtualized_DRM
Konkrét megoldási javaslatot itt nem találtam, de az előző kimerítő hszed alapján bekapcsolom a debugokat, és meglátom, hátha arra találok valamit. A kernel beállításokban is lehet valami, ami változtatna, de egyelőre teljesen ész nélkül tudnám csak ki be kapcsolgatni... :)
A probléma elvi okát nagyvonalakban értem, arra számítottam, hátha valaki más már látott hasonlót, és beírja a megoldást :) Ez a nopat kernel paraméter tűnik eddig a legígéretesebbnek... Utálok rebootolgatni, de mindjárt csinálok pár próbát :)
Örülnék, ha konstruktívabb tudnék lenni, de a Xen architektúrájából adódóan (= a "host kernel" valójában dom0 guest kernel, az igazi host kernel pedig "csak" egy VMM) időnként a hypervisor-t is hozzá kell reszelni az adott hardverhez.
Ha jól tudom, emiatt szokták a Xen-t inkább géptermi virtualizációra ajánlani; a dom0-ban igazi workload-ot (pl. desktop környezetet, interaktív munkát) nem javasolnak, annak a domU-k adminisztrálása a dolga. Azt írod,
Szeretném a rendszert xen domain0 ként használni, hogy kísérletezni tudjak a xennel.
Én inkább egy külön gépet ajánlanék erre a célra. (Nem igazán konstruktívan, bocsánat.)
Nagyon értékelem, hogy érdemi választ kaptam, még akkor is, ha nem sikerült (egyelőre) megoldani, köszi!
Az xl dmesg ben sok hasznos log üzenetet nem találok, de lehet, hogy nem is jól kapcsoltam be a logot.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000000001000000 to 0xc008000001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000bef7f9fefd9a to 0x0000bef7f9fe0265.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000000001000000 to 0xc008000001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000000001000000 to 0xc008000001000000.
(XEN) traps.c:2584:d0 Domain attempted WRMSR 00000000c0000408 from 0xc000000001000000 to 0xc008000001000000.
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:0a.0
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:12.0
(XEN) PCI add device 0000:00:12.1
(XEN) PCI add device 0000:00:12.2
(XEN) PCI add device 0000:00:13.0
(XEN) PCI add device 0000:00:13.1
(XEN) PCI add device 0000:00:13.2
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:14.4
(XEN) PCI add device 0000:00:14.5
(XEN) PCI add device 0000:00:18.0
(XEN) PCI add device 0000:00:18.1
(XEN) PCI add device 0000:00:18.2
(XEN) PCI add device 0000:00:18.3
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:01:00.1
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:03:00.0
(XEN) PCI add device 0000:04:00.0
(XEN) PCI add device 0000:05:06.0
(XEN) PCI add device 0000:05:06.1
A PCI sorokat a loglvl=all nélkül nem írta, viszont teljesen midnegy, se így, se úgy az xl dmesg be az x indulásakor új sor nem kerül.
ezeket írtam be:
" debug drm.debug=255 loglvl=all guest_loglvl=all"
a kernel után, és az utóbbi 2t a xen.gz után IS. Semmi nem változott. Vissza fogok még térni a problémára, most pihentetem néhány napot.
A xent szervereken szeretném (és fogom is) használni. Virtualboxban sikerült is működésre bírnom, a virtuualboxban futó dom0 gentoo alatt futott egy domU Debian 6. :D Inception...
A célom az lett volna, hogy a saját gépemen minden hátrány nélkül (100 mega ram lenne oda elvileg) tudnám a domU kat tesztelni, és nem kéne virtualboxban kinlodni. Itthon erre a célra nem tudok egy külön gépet dedikálni, ahol pedig végső helyén lesz, ott meg nem fog számítani az X... Egyelőre erről ennyit, pont az ilyen hibák sokszor megoldódnak egy következő frissítéssel, úgyhogy egyelőre várok. Ha lesz időm, föliratkozok a xen levlistára, és ott kérek tanácsot. Az az igazság, hogy nem extra hardvert akarok életre kelteni, mert ugye hardver virtualizaciot tudja a proci, a GT240 nem túl régi kártya, de nem is túl új, szóval nem egy extrém felállásról van szó, 4 pci-e vgaval, meg pci passthrough val :)
Kösz mégegyszer. Ha meglesz a megoldás, ide fogom írni ebbe a témába :)
esetleg Xen PCI Passthrough-van meg lehet oldani, dom0 megy-e azt nem tudom,
iommu támogatás is kell hozzá ha jól tudom
A processzorom tudja a hw virtualizációt, de az IOMMUt az alaplap nem. Bár hogy ezt hogy tudom kideríteni, az még nem világos, de egy támogatott listában az enyémnél újabb (és drágább) alaplapok szerepelnek csak. Ez egy Asrock 880GMH/U3S3.
Ha a Dom0 ban nem megy, elég esélytelennek látszik, hogy DomU ban menne, az valószínűleg tovább nehezítené a helyzetet. Igazából nem túl sokmindenre hasnzálom a GPUt, de azért nem szívesen mondanék le még a lehetőségről is, hogy használjam.
ftp://download.nvidia.com/XFree86/Linux-x86/260.19.12/README/dma_issues…
Itt ír érdekes dolgokat, de nem sok hasznát vettem egyelőre.
DomU teljesen át kell adni a kártyát, persze akkor a Dom0ban le kell mondani róla
http://www.youtube.com/watch?v=3SaYO0ERW44
51 másodpercnél van valami okosság :)
Dom0 ban szeretném használni, és annak eleve mennie kéne szerintem. :) Hol van a DomU... Pont ezt mondom én is.
próbáld ki a xen.gz cmdline-ban ezt az opciót:
Ha így sem megy, akkor mit mond az
?
Na úgy néz ki a kísérletezéssel összefüggésben brutális filerendszer hibáim keletkeztek... Több, mint valószínű, hogy az egyik (vagy mindegyik) kísérletezésnél teljesen szétcsúsztak a lemezre írások, minden mountolt filerendszeren helyrehozhatatlan sérülések keletkeztek. Legalább láttam a btrfsck t működés közben, de nem volt triviális a recovery, szerencsére az adataim egy részéről, főleg a fontosakról van pár napos backupom, így az azóta nem változott adatokat még ellenőrizni is tudom... :)
Fogok még ezzel kísérletezni, de egy teljesen külön lemezzel, mert ezt nem kockáztathatom mégegyszer. Mindenkit óvatosságra intek!