*** This bug is a duplicate of bug 739785 ***
https://bugs.launchpad.net/bugs/739785
** This bug has been marked a duplicate of bug 739785
qemu-i386 user mode can't fork (bash: fork: Invalid argument)
--
You received this bug notification because you are a member of qemu-
devel-ml, which
Hi,
I just compiled the testclone.c with Suse Linux 9.0.
It has a Kernel 2.4.21, so never heard anything in its life about NPTL.
On this 2.4.21 Linux, the testclone program with direct calling of clone()
works.
Then I make a try with this testclone on Raspberry Pi and qemu-i386 with
-strace.
The
Hi,
here are the next steps what I am doing. I get the oldest qemu-0.41 version,
that I can get,
from June 2003:-).
Very interesting, the syscall.c today in Qemu 1.2.0 is build exact like that
from 2003.
And the testclone.c programm comes together with Qemu 0.41 and compiled also.
So, not so
Yeeaah,
the first version of qemu-0.4.1 is the ONLY version of Qemu,
that runs the testclone programm without any error.
This is nice, because the structure of calling clone() in syscall.c is today
the same as in 0.4.1.
This means, the error can be fixed,
Dietmar
--
You received this bug
Thanks for doing this testing but I'm afraid it really isn't giving us
any new information. We already know clone is broken for i386 targets;
see my comment #9 in this bug.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
didi2@linux:~ strace -f qemu testclonenonptl
execve(/usr/local/bin/qemu, [qemu, testclonenonptl], [/* 67 vars */]) = 0
uname({sys=Linux, node=linux, ...}) = 0
brk(0) = 0x80463540
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
On 14 August 2012 02:01, Dietmar Stölting dietmar.stoelt...@t-online.de wrote:
with this new syscall.c content above things are going in the right
direction:-).
I make a test with strace from the program testthread of the Qemu testsuite.
When I understand the result right,
threading works
I just compare the source code for testthread.c and testclone.c.
The only difference I see is, HOW the function clone() is called.
In testthread via pthread_create()
in testclone via clone() direct.
So, the problem for qemu-i386 must be in the settings of the flags in clone().
Works:
void
Hi,
with this new syscall.c content above things are going in the right
direction:-).
I make a test with strace from the program testthread of the Qemu testsuite.
When I understand the result right,
threading works now with this new compiled qemu-i386.
The child and the parents tidptr NOW have
Yes, threading does not work for i386 guests; this is a long-standing
issue. (See also bug 739785.)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug in Qemu User Mode
Status in
Hi,
thanks for answer. Do you know, where the real problem in threading for i386
guests is?
Some kind of NPTL is implemented in Qemu and it could be necessary tested for
host arm - guest arm
and also host i386 - guest arm with qemu-arm testclone in commandline.
I saw the attemps in past by David
Hi,
I just make a test if my thoughts are right. On a Wheezy debian i386 I type in
comandline
qemu-i386 -strace clonemi
(clonemi is the program testclone but with the endless loops in waitpid at its
end put out.)
The result is exact like on Raspberry Pi with ARM 1176 processor.
So you can see,
I did some more tests:
In the newest version of Qemu Linaro I put in folder Linux-User
in the file syscall.c the following
target_ldt_info-base_addr = tswapal(base_addr);
target_ldt_info-limit = tswap32(limit);
target_ldt_info-flags = tswap32(flags);
I mean of course, that the tidptr from child and parent are different,
parent_tidptr=0x43076590 child_tidptr=0x42fcb788
Dietmar
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1035572
Title:
Bug
I just compiled the testclone new on debian Wheezy,
for to understand what is going on and name it clonemi.
Before I have always an endless loop on Raspberry Pi
because waitpid was never fullfilled.
So I commened the two waitpid lines out.
Also I enlarged the STACK_SIZE to 262144.
Enlarging of the
After studying the source code of testclone intensive,
I see only one possibility:
The implementation of the function [b]clone() [/b]in
Qemu User Mode must be wrong.
This would indeed affect any configuration,
means it is NOT CPU depending,
Dietmar
--
You received this bug notification because
16 matches
Mail list logo
