Hi Paolo and others,
thanks a lot for explanation. I'll just add some things I've noticed
(and also few another questions ;):
My setup is dualcore opteron machine, running SMP 2.6.18, patched with
skasv9-pre9 with fremap support.
guests:
vanilla 2.6.18-x86_64 SKAS
- crashes trying to access /proc/mm
vanilla 2.6.18-x86_64 noprocmm OR skas0
- works equally well, even performance is pretty much the same
(measured on kernel compilation), there's just this problem with
/sbin/halt hang
vanilla 2.6.18-x86 - doesn't matter which arguments are passed
- hangs, strace shows following:
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7f40000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7f3f000
clone(child_stack=0xf7f3ffd4, flags=|SIGCHLD) = 8120
waitpid(8120, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}],
WSTOPPED) = 8120
--- SIGCHLD (Child exited) @ 0 (0) ---
and child process dies this way:
getppid() = 8119
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation
not permitted)
dup(2) = 4
fcntl64(4, F_GETFL) = 0x8002 (flags
O_RDWR|O_LARGEFILE)
fstat64(0x4, 0xf7f3fa44) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7f3e000
_llseek(4, 0, 0xf7f3faa4, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "ptrace: Operation not permitted\n", 32) = 32
close(4) = 0
munmap(0xf7f3e000, 4096) = 0
kill(8120, SIGKILL) = 0
+++ killed by SIGKILL +++
2.6.18-x86_64 with bb1 patch
- SKAS crashes as expected
- noprocmm or skas0 is weird:
if run, panics with:
[42949373.500000] VFS: Mounted root (ext2 filesystem) readonly.
Usage: init 0123456SsQqAaBbCcUu
[42949373.500000] Kernel panic - not syncing: Attempted to
kill init!
- aparentrly init is being executed in some strange way?
- given init=/bin/sh hangs, tracing shows following loop:
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(1381, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}],
WSTOPPED, NULL) = 1381
ptrace(PTRACE_GETREGS, 1381, 0, 0x60aec330) = 0
ptrace(PTRACE_GETFPREGS, 1381, 0, 0x60aec408) = 0
ptrace(PTRACE_CONT, 1381, 0, SIGSEGV) = 0
- round and round
I hope it helps in some way.
I'm going to try mm patches now, to see if something behaves different
(better if possible :)
nik.
PS: your setarch patch works, thanks!
Blaisorblade wrote:
> On Sunday 01 October 2006 01:57, Jeff Dike wrote:
>
>> On Sun, Oct 01, 2006 at 01:11:37AM +0300, Nikola Ciprich wrote:
>>
>>> You have an idea where
>>> could be problem with shutting down? (this Virtual timer expired
>>> cycling?)
>>>
>> Oops, missed that in your previous message.
>>
>> Where in the shutdown process is this? There have been some previous
>> reports of hangs during swapoff which I have been unable to reproduce.
>> I spent part of a day last week pushing UMLs deeply into swap and
>> shutting them down, always successfully.
>>
>> The SIGVTALRM is normal - that's just the timer. That strace you sent
>> looks like the idle loop, so as far as the kernel is concerned,
>> everything is fine.
>>
>>
>>> and regarding /proc/mm, shouldn't this mm64 file be used? or what's it
>>> used for?
>>>
>> /proc/mm64? What would it do that /proc/mm doesn't?
>>
>
> Well, I'll explain everything (even to Jeff, since I never documented
> anything
> of this).
>
> The SKAS patch V8 supports well i386 host and i386 guest. That's all.
> SKAS patch V9-preX tries to support x86_64 host, with both 32 and 64 bit
> guests:
>
> * 32 bit guests: a bug prevents using full SKAS3, you must pass noprocmm and
> you'll get most performance advantages (because faultinfo works). When I
> worked on the SKAS port to x86_64 I did not discover that something worked,
> and I never tested support for 64bit guests.
> I latter discovered the bug is in a different portion of code - Bodo
> Stroesser
> unveiled it, and I think this is the same bug that hit even Jeff's 1st
> attempt to write SKAS4 (all I know can be found in
> http://user-mode-linux.sourceforge.net/diary.html -> grep skas4 and you'll
> find what I'm talking about on 23 Sep 2004).
>
> * 64bit guests: they do not support SKAS3, but the host patch gives the
> needed
> support - to do that, the 1st thing to do would be to use /proc/mm64 as you
> point out (and it could even suffice, even if I doubt that), but guest
> kernels still try to use /proc/mm and it does not work. So you must pass
> skas0 on the cmdline (I do not remember whether noprocmm works for this
> case).
>
> -EINVAL is given on purpose: the request struct UML writes on /proc/mm has a
> different layout for 32 and 64bit requests, or better a different size since
> pointers are larger (and there's an explicit check for that - IIRC it has
> always been there). I chose to have a separate /proc/mm64, I did not think to
> try autodetection. And frankly my first impression is that I'd still do it
> this way.
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
