Hi!
Is there documentation on how to invoke qemu-system-arm for the highbank
target ? There seem to be some not obvious arguments needed to get it up
and running beside a plain
qemu-system-arm -M highbank -sd foo.img -append 'root=/dev/mmcblk0p1'
So - where is this documented in-tree and how
Am Dienstag, 3. Mai 2011, 11:13:35 schrieb 李柏舉:
arm-2007q3
Try a newer cross-compiler please and then report back.
Best,
Jan-Simon
Am Montag, 18. April 2011, 14:19:26 schrieb Riku Voipio:
On Mon, Apr 18, 2011 at 02:06:02PM +0200, Alexander Graf wrote:
The patch looks OK, but I'd like to have a try with some s390x static
binaries. Such binaries are also useful for me to test that new patches
for linxu-user don't
Am Mittwoch, 1. Dezember 2010, 20:40:37 schrieb Peter Maydell:
On 28 November 2010 11:24, Peter Maydell peter.mayd...@linaro.org wrote:
2010/11/28 Brian Harring ferri...@gmail.com:
Additional note... it *looks* like the deadlock potential is there
already in 0.13, it's just heavily
See linux-user/main.c function start_exclusive.
--
qemu-arm segfaults executing msgmerge (gettext)
https://bugs.launchpad.net/bugs/668799
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
upstream
To me it looks like racy/double lockings. We already lock meantime
before some functions up the code-path of cpu_unlink_tb . IMHO the
spinlock in cpu_unlink_tb is now unnecessary - at least in this code-
path. Maybe we exit the cpu before the previous/upper lock is released.
HTH, have phun!
--
We always see this in :
exec.c1662:
void cpu_exit(CPUState *env)
{
cpu_unlink_tb(env);
env-exit_request = 1;
}
A quick test with the statement cpu_unlink_tb(env) removed passed the test.
--
qemu-arm segfaults executing msgmerge (gettext)
https://bugs.launchpad.net/bugs/668799
You
Alternative testcase:
compile and export OMP_NUM_THREADS=6 before running.
/**
* FILE: omp_mm.c
* DESCRIPTION:
* OpenMp Example - Matrix Multiply - C Version
* Demonstrates a matrix multiply using OpenMP. Threads
Public bug reported:
upstream qemu.git revision b45e9c05dbacba8e992f0bffeca04c6379c3ad45
Starting program: /usr/bin/qemu-arm msgmerge-static ar.po anjuta.pot
[Thread debugging using libthread_db enabled]
[New Thread 0x74bc3ff0 (LWP 26108)]
[New Thread 0x74b8aff0 (LWP 26109)]
[New Thread
Am Mittwoch, 1. September 2010, 14:54:41 schrieb Anitha Boyapati:
[...]
My exact requirement is to test a gcc cross-compiler using DejaGnu for
a given target (AVR32). While the cross-compiler is ready, there is no
simulator. Since there is not much of OS support, I am trying to
evaluate if
Am Dienstag, 27. Juli 2010, 19:25:26 schrieb Richard Henderson:
A re-based and re-tested version of a patch series I
posted back in April and May. These cleanups prepare
elfload.c for loading the VDSO for x86_64.
Do you have a repo where i could pull these from ?
Best,
Jan-Simon
Hi all !
I stumbled over https://computing.llnl.gov/tutorials/pthreads/samples/join.c
and tried to run it with qemu-arm (gcc-arm -lm -lc -lpthread -o join join.c;
qemu-arm ./join ).
qemu-arm from 9f5a1fae7ee1a7c66462e5b8e9d21552d4dc5027 compiled with:
./configure --prefix=/usr \
There're also projects like http://compression.ca/pbzip2/ . We'll be
facing more and more cores per cpu, so we should use these techniques.
--
[Feature request] qemu-img multi-threaded compressed image conversion
https://bugs.launchpad.net/bugs/601946
You received this bug notification because
I had QEMU working on PowerPC and ARM in chroots from the Linux versions:
- Fedora 11 / 12
- Ubuntu 9.04, 9.10, 10.04
- Debian 4, 5 and Sid
for ARM and PowerPC. My host OS is openSUSE 11.2 using a 2.6.31 kernel,
or openSUSE 11.1. All machines are 64 Bit machines.
Now I have the
Am Montag, 15. März 2010 15:48:03 schrieb Riku Voipio:
On Mon, Mar 15, 2010 at 01:46:10PM +0100, Jan-Simon Möller wrote:
We're still investigating the topic. So far, we tracked one failure down
to ldconfig.real which is a static arm binary executed after the chroot
got the basic packages
Hi all!
Running msgmerge with qemu-arm (d616cf1d1510c963fc1876cb10f5f1fa226b54ef) I
get
stuck in an endless loop in exec.c (~line 1294):
code-snippet:
ptb = tb_next-jmp_first;
for(;;) {
tb1 = *ptb;
n1 = (long)tb1 3;
tb1 = (TranslationBlock
Am Mittwoch 02 Dezember 2009 09:54:04 schrieb Alexander Graf:
Experience has shown that it doesn't work like that. It happens the
person writing the patches never provides a fix, and the committer
receives the complains, and in fine fixes the commit.
Then revert the patch. I also think
The attached patch makes this configurable at compile-time.
fwiw in scratchbox we have a wrapper in between binfmt and qemu (called
misc_runner) that sets any
necessary command line parameters for qemu. You might want to consider a
similar approach so we
don't need to add a configure
.
Signed-off-by: Jan-Simon Möller dl...@gmx.de
From 0dc910f5d1b2e1dd7120abf32d25db190cd394e5 Mon Sep 17 00:00:00 2001
From: Juan Quintela quint...@redhat.com
Date: Sun, 25 Oct 2009 22:06:52 +0100
Subject: [PATCH] User mode stacksize implementation
Best,
Jan-Simon
Hi !
We encontered problems with the low default value for the stacksize in usermode
(ok, whats low).
For environments like scratchbox, its hard to use -s as qemu is called by
binfmt mechanism.
The attached patch makes this configurable at compile-time.
Signed-off-by: Jan-Simon Möller dl
Am Sonntag 25 Oktober 2009 16:54:16 schrieb Laurent Desnogues:
Wouldn't it be better to set this earlier only if target_user_only
is set to yes and use cflags?
Something like this:
if test $target_user_only = yes -a $user_mode_stacksize != ; then
cflags=-DUSER_MODE_STACKSIZE $cflags
fi
We encontered problems with the low default value for the stacksize in usermode
(ok, whats low).
For environments like scratchbox, its hard to use -s as qemu is called by
binfmt mechanism.
The attached patch makes this configurable at compile-time.
Signed-off-by: Jan-Simon Möller dl...@gmx.de
This patch fixes the mount call. GUEST_BASE shouldn't be added to a NULL
pointer on arg5 .
failing call:
mount(rootfs, /, 0x47a78, MS_MGC_VAL|MS_REMOUNT, 0x1) = -1 EFAULT (Bad
address)
correct call:
mount(rootfs, /, 0x37ab0, MS_MGC_VAL|MS_REMOUNT, NULL) = 0
Signed-off-by: Jan-Simon
23 matches
Mail list logo
