Debian UML - Kernel panic - not syncing: Kernel mode signal 7
Hallo zusammen,
lange habe ich nichts mehr von mir hören lassen. An folgendem Problem
hänge ich nun schon seit etlichen Wochen und nach vielen Tests, bleibt
mir nur noch die Hoffnung von Euch Hilfe zu bekommen.
Es geht um einen UML (User Mode Linux) Betrieb. Der Host-Kernel mit dem
dazugehörigen Skas-Patch ist mittlerweile 2.6.19:
Linux fempire 2.6.19-skas3-v9-pre9skas
Debian Sarge ist auf diesem Host-System installiert. Es sind 3 UMLs in
Betrieb. Ein Etch, ein Sarge und ein Gentoo System. Etch und Gentoo
haben jeweils 256M Speicher zugewiesen bekommen und die UMLs werden mit
dem Kommando
su nobody -c "nice -n 1 ./vmlinux ubd0=root_fs ubd1=swap_fs
eth0=tuntap,tap4 mem=256M umid=UML5 uml_dir=/opt/uml5"
gestartet. Die Debian UMLs wurden jeweils mit dd, mkfs, debootstrap,
mkswap eingerichtet. Soweit läuft auch alles. Die UML-Kernel sind alle
2.6.19. Nun zum problematischen:
Speziell bei Befehlen, wie apt-get update oder apt-get upgrade und dem
darauf folgenden Laden und entpacken der Pakete "verreckt" die Etch-UML
(zu diesem Augenblick läuft die Sarge-UML scheinbar problemlos). Es
zeigte sich, dass bei einem Zugriff auf das tmpfs es sofort zu diesem
Fehler kommt:
Kernel panic - not syncing: Kernel mode signal 7
EIP: 0073:[<400007e2>] CPU: 0 Not tainted ESP: 007b:bff001cc EFLAGS:
00200246
Not tainted
EAX: ffffffda EBX: 4014b008 ECX: 0003dd75 EDX: 0804a008
ESI: 00000001 EDI: 00000000 EBP: bff00238 DS: 007b ES: 007b
Auf der Problemlösungsseite des UML-Projekts [1] findet man folgende Lösung:
'Kernel panic - not syncing: Kernel mode signal 7'
The filesystem where UML is keeping its physical memory files is full.
This is normally a tmpfs mount, either /dev/shm or /tmp. A UML's
consumption of this space will asymptotically approach its physical
memory size as it continues to run. This filesystem should be at least
as big as the sum of the physical memory sizes of the UMLs that will be
using it.
Gemacht, getan:
tmpfs 125 0 125 0% /lib/init/rw
tmpfs 125 1 125 1% /dev/shm
Beide mit 'mount -o remount,size=256m /dev/shm' vergrößert. Keine
Besserung. Problem bleibt bestehen. Weitere Ideen hatte ich eigentlich
nicht mehr, außer neue Kernel zu kompilieren (vom Host, als auch von der
UML). Die neuesten Skas Patches ausprobiert. Alles ohne Erfolg.
Bis ich dann mal die Sarge-UML beendet habe. Und dann ging die Etch-UML
auf ein Mal problemlos. Außerdem geht die Etch-UML problemlos, wenn ich
den Speicher auf 64M begrenze (das tmpfs ist hierbei dann 32M groß).
Da diese Problematik meine Nutzer-Kenntnisse weit übersteigt, ich aber
die Vermutung habe, dass es ein Speicherzugriffsproblem ist, frage ich
euch. Kann es seine, dass beide Debian UMLs auf die gleichen
Speicheradressen zugreifen wollen? Normal müsste die Speicherzuweisung
ja vom Host-Kernel übernommen werden.
Da diese Problematik auch nur mit Debian besteht, kann ich nunmehr
vermuten, dass es was mit Debian zu tun hat.
Wenn Ihr noch Informationen braucht, lasst es mich wissen. Ich hoffe
sehr, dass Ihr mir helfen könnt.
Mit freundlichen Grüßen,
Claus
[1] http://user-mode-linux.sourceforge.net/new/problems.html
--
Claus Malter <debian sprayen dot de>
GnuPG-ID: 0x08B86210 http://wwwkeys.de.pgp.net
Reply to: