XEN 3.3: kernel-panic mit 4GB RAM

[Sil3ntWarri0r]

Hi,

da meine domU's etwas speicherhungrig sind habe ich von 2GB auf 4GB aufgerüstet, alles kein Problem dachte ich, Speicher einbauen, booten, den domU's mehr zuweisen, fertig...
Leider erhalte ich nun beim booten des xen-kernels (Linux x86_64 2.6.27-xen-r2) folgenden Fehler:

Press I to enter interactive boot mode

* Mounting proc at /proc ... [ ok ]
* Mounting sysfs at /sys ... [ ok ]
* Mounting /dev ... [ ok ]
* Starting udevd ... [ ok ]
* Populating /dev with existing devices through uevents ... [ ok ]
* Waiting for uevents to be processed ...
INIT: Entering runlevel: 3
[ 10.449773] Kernel panic - not syncing: Out of memory and no killable processes...
[ 10.449776]

Im Bios habe ich Remapping des Speichers aktiviert, wenn ich es abschalte funktioniert zwar der Kernel, aber mir stehen dann nicht die ganzen 4GB RAM zu Verfügung, was ja nich Sinn und Zweck ist.
Wenn ich unter

Processor type and features --->
Subarchitecture Type (PC-compatible) --->
einstelle anstatt:

Processor type and features --->
Subarchitecture Type (Enable Xen compatible kernel) --->
funktioniert alles normal, natürlich ohne XEN, womit ich nicht viel anfange...

Jetzt frage ich mich, ob das Problem direkt mit dem Kernel zusammenhängt, oder ob es an einer anderen Komponente liegt, weshalb der Fehler auftritt, aber scheinbar scheint etwas mit dem IOMMU nicht zu klappen...

Systemdaten:
Core 2 Duo E7300
Elitegroup GF7050VT-M5
4GB RAM
Gentoo 64-Bit (hardened)

Jemand eine Idee, was ich noch ausprobieren könnte ?

Danke.

[MuffiXXL]

Ich würde sagen das riecht nach einem Bug in Xen mit dem Remapping.
Das läuft 32bit bei dir nehme ich mal schwer an. Als 64Bit Nutzer war mir nichtmal bewusst dass es sone BIOS Option gibt. Ich denke mal dass Xen aber gerade im 32bit Bereich aus offensichtlichen Gründen kaum weiterentwickelt wird. Es könnte dir vielleicht helfen die Bug Reports des Xen Kernels deiner Distribution mal durchzuschauen und gegebenenfalls einen zu schreiben.
IOMMU konnte ich bei mir mit Xen 3.3 erst garnicht ans laufen bekommen, daher kann ich dir dazu wenig sagen außer dass das was du hier gepostet hast nicht nach einem IOMMU Fehler ausschaut, aber um das zu wissen bräuchte man den output von "xm dmesg". Und da der Code hier von 3.2 nach 3.3 recht stark verändert wurde möchte ich meine Hand jetzt auch nicht ins Feuer legen :-D

[Sil3ntWarri0r]

Hi,
nein verwende 64-Bit, aber auch da ost teilweise ein remapping notwendig für Hardware, die kein 64-Bit unterstützt, die muss dann auch in den 32-Bit Bereich gemappt werden, damit sie angesprochen werden kann. Wenn ich den Kernel auf XEN umstelle verschwindet auch die Einstellung IOMMU, zumindest kann ich diese nicht mehr anwählen.

xm dmesg:

server ~ # xm dmesg
__ __ _____ _____ ___
\ \/ /___ _ __ |___ / |___ / / _ \
\ // _ \ '_ \ |_ \ |_ \| | | |
/ \ __/ | | | ___) | ___) | |_| |
/_/\_\___|_| |_| |____(_)____(_)___/

(XEN) Xen version 3.3.0 (@(none)) (gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)) Mon Dec 8 19:40:28 GMT 2008
(XEN) Latest ChangeSet: unavailable
(XEN) Command line: dom0_mem=98M
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009fc00 (usable)
(XEN) 000000000009fc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 000000007bfa0000 (usable)
(XEN) 000000007bfa0000 - 000000007bfae000 (ACPI data)
(XEN) 000000007bfae000 - 000000007bfe0000 (ACPI NVS)
(XEN) 000000007bfe0000 - 0000000080100000 (reserved)
(XEN) 00000000fec00000 - 00000000fec01000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000fff00000 - 0000000100000000 (reserved)
(XEN) System RAM: 1983MB (2030844kB)
(XEN) ACPI: RSDP 000FA080, 0014 (r0 ACPIAM)
(XEN) ACPI: RSDT 7BFA0000, 0044 (r1 070708 RSDT1559 20080707 MSFT 97)
(XEN) ACPI: FACP 7BFA0200, 0084 (r1 070708 FACP1559 20080707 MSFT 97)
(XEN) ACPI: DSDT 7BFA04A0, 5633 (r1 1AAAA 1AAAA000 0 INTL 20051117)
(XEN) ACPI: FACS 7BFAE000, 0040
(XEN) ACPI: APIC 7BFA0390, 0080 (r1 070708 APIC1559 20080707 MSFT 97)
(XEN) ACPI: MCFG 7BFA0410, 003C (r1 070708 OEMMCFG 20080707 MSFT 97)
(XEN) ACPI: WDRT 7BFA0450, 0047 (r1 070708 NV-WDRT 20080707 MSFT 97)
(XEN) ACPI: OEMB 7BFAE040, 0071 (r1 070708 OEMB1559 20080707 MSFT 97)
(XEN) ACPI: HPET 7BFA5AE0, 0038 (r1 070708 OEMHPET0 20080707 MSFT 97)
(XEN) ACPI: NVHD 7BFAE0C0, 0554 (r1 070708 NVHDCP 20080707 MSFT 97)
(XEN) ACPI: SSDT 7BFAEBA0, 0A7C (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) Xen heap: 14MB (14720kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2666.732 MHz processor.
(XEN) CPU0: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz stepping 06
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz stepping 06
(XEN) Total of 2 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) checking TSC synchronization across 2 CPUs: passed.
(XEN) Platform timer is 25.000MHz HPET
(XEN) Brought up 2 CPUs
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x8a9960
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000077000000->0000000078000000 (20992 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff80200000->ffffffff808a9960
(XEN) Init. ramdisk: ffffffff808aa000->ffffffff808aa000
(XEN) Phys-Mach map: ffffffff808aa000->ffffffff808db000
(XEN) Start info: ffffffff808db000->ffffffff808db4a4
(XEN) Page tables: ffffffff808dc000->ffffffff808e5000
(XEN) Boot stack: ffffffff808e5000->ffffffff808e6000
(XEN) TOTAL: ffffffff80000000->ffffffff80c00000
(XEN) ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 2 VCPUs
(XEN) Scrubbing Free RAM: ..................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 112kB init memory.


Hier ist aber nun die Remapping Option im Bios abgeschaltet, im Falle des Absturtzes legt er mir leider nichts aktuelles an, zumal dies dann nach einem erfolgreichen boot wieder weg ist.

[MuffiXXL]

Achso, dann verstehe ich das jetzt so, dass du mit der Remapping did IOMMU aktivierst. Bei mir nennt sich das einfach VT-d, da war ich wohl etwas verwirrt mit, dann.
Wenn ich mir deinen Output anschaue hast du die IOMMU aber garnicht aktiviert: (XEN) Command line: dom0_mem=98M
daher kann der Fehler eigentlich nicht wirklich daran liegen. Die müsstest du mit iommu=1 erst noch aktivieren wenn du willst, dass Xen sie nutzt. Im Prinzip bringt sie dir aber unterhalb 4Gig RAM nichts.
Finde das aber auch etwas strange dass du nicht die vollen 4Gig siehst im 64Bit Modus. Selbst bei meiner alten Pentium D Kiste, wo der CHipsatz bei 32Bit ein Gig "versteckt" hat habe ich 64 Bittig zugriff auf die vollen 4 Gigabyte gehabt. Allerdings glaube ich gibt Xen nicht allen Speicher weiter. Bin gerade nicht daheim, aber ich meine, dass Xen mir auch ein paar Hundert MB abzweigt die ich mit dem Default Kernel "sehe".

[Sil3ntWarri0r]

Meine CPU unterstützt leider kein VT-d.
Durch das abgeschaltete Remapping im Bios, wird der Speicher auf 2GB begrenzt, daher sagt der kernel auch er wären nur 2GB, wenn ich auf 4GB gehe, kann ich leider keine dmesg erzeugen, da es unterwegs abstürtzt und ich noch nicht herausgefunden habe, wie ich den Ringpuffer speichern kann.

Mhh, dann werde ich mal bei den kernel-parametern iommu=1 ausprobieren...

[Sil3ntWarri0r]

iommu=1 hat leider nichts bewirkt.

[MuffiXXL]

BIOS auf dem aktuellen stand?

Zufällig Madwiki im Kernel (weil das scheint solche Probleme auch gerne hervorzurufen) und was passiert wenn du das Remapping aktivierst? Weil um das zu aktivierne muss die CPU neu initialisiert werden. Sprich dafür muss das BIOS neu initialisiert werden, wofür ein Reset nötig ist.

[Sil3ntWarri0r]

Joh BIOS ist das neuste, dass der Hersteller anbietet, komischerweise funktioniert ja auch mit einem "normalen" Kernel ohne XEN alles, da stehen mir die 4GB zu Verfügung.
Der Computer wird neu gestartet, wenn ich im BIOS diese Option ändere, auch die RESET Taste musste ich schon oft genug nach der Kernel-panic betätigen... Daran kanns nicht liegen...
Irgendwie muss es sehr in Verbindung mit XEN stehen, entweder XEN selbst oder an den kernel-patches...

[John W]

Bei meinem Selbstversuch, einen eigenen Kernel zu kompilieren (gescheitert, erst Kernelpanik, dann USB vergessen :o), fand ich eine Option, die sich auf den Arbeitsspeicher bezieht, vielleicht musst du einen anderen XEN-Kernel installieren.

[Sil3ntWarri0r]

Hi, glaub nicht, dass es am Kernel selbst liegt, hab mir auch schon verschiedene Versionen angeschaut, aber da nichts gefunden, weisst du zufällig noch, wie die Kerneloption für den Speicher heisst die du meinst ?

[John W]

Hi,
Die Option findet sich (bei mir) unter: Processor type and features -> High Memory Support -> Off/4GB/64GB.

[Sil3ntWarri0r]

Mhh, dann verwendest du wohl ein 32Bit System, bei den 64Bit'ern gibt es diese Option nicht, da sie da unnötig wäre...

Schade...

[John W]

Jau, 32er.
Sind die Speicherriegel eigentlich gleich oder verschieden? Versuche auch mal, die Positionen einfach zu ändern.
Ich hatte mal 1x512MB auf 2x512 aufgerüstet, der neue Riegel auf zweite Position (baugleich), aber einige Programme sind häufiger abgestürzt bis ich die Beiden vertauscht hatte - der alte Speicherriegel hatte einige Fehler, was besonders Yast nicht gerade vertrug...
(Der alte Riegel ist seit einiger Zeit ganz raus, nur noch 512MB, läuft aber stabil)

[Sil3ntWarri0r]

Habe 2x 2GB drin, die Riegel sind zwar von unterschiedlichen Herstellern, aber da ja alles funktioniert, wenn ich einen Kernel ohne XEN nehme und mir da die 4GB auch zu Verfügung stehen, nehme ich nicht an, dass es sich um ein Hardwareproblem handelt. ;)

[John W]

Auch wieder wahr.
Vielleicht trotzdem den alten Riegel erstmal rausnehmen, den neuen auf erste Position und dann testen, schaden kann es nicht und schließt dieses Problem eindeutig aus, mir fällt sonst nix mehr ein - vielleicht Linus fragen :D