Public bug reported:
This is a bug that i have noticed in qemu 1.7.50 as well as 1.1.50. It
was the latter that forced me to clone the repository to check if this
is the case with the resent version as well . The latest commit on which
the bug is found is f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 o
** Description changed:
This is a bug that i have noticed in qemu 1.7.50 as well as 1.1.50. It
was the latter that forced me to clone the repository to check if this
is the case with the resent version as well . The latest commit on which
the bug is found is f53f3d0a00b6df39ce8dfca942608e5
*** This bug is a security vulnerability ***
Public security bug reported:
Commit: f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git
Solaris image: Solaris 10 x86 (32 bit)
command: ./i386-softmmu/qemu-system-i386 -hda -m 2G -icount
1 -monitor stdio
Crashes saying:
qemu: Fatal: Raised inter
** Information type changed from Public Security to Public
** Description changed:
** Information type changed from Public to Public Security
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of qemu-
devel-ml, which is su
I tested on the commit f53f3d0a00b6df39ce8df
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1290370
Title:
FreeBSD 9.2 shell crashes when run with -smp 4 option
Status in QEMU:
New
Bug descripti
** Description changed:
Commit: f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git
Solaris image: Solaris 10 x86 (32 bit)
command: ./i386-softmmu/qemu-system-i386 -hda -m 2G -icount
1 -monitor stdio
Crashes saying:
qemu: Fatal: Raised interrupt while not in I/O function
Hi,
I am getting this error if i try to build qemu.
libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc':
/util/oslib-posix.c:141: undefined reference to `trace_qemu_anon_ram_alloc'
libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free':
/util/oslib-posix.c:153: undefined refere
Thanks. Out-of-tree build worked (with make distclean before checking out
new commit).
On Tue, Jun 10, 2014 at 5:53 PM, Peter Maydell
wrote:
> On 10 June 2014 13:03, Sai Prajeeth wrote:
> > Hi,
> > I am getting this error if i try to build qemu.
> >
> > libqe
Hi
I am booting an OpenIndiana image on qemu by using the -smp 4 option. I
seem to be running into this known bug
http://docs.oracle.com/cd/E19253-01/820-5245/ggmsj/index.html
Can someone tell me how can i go about doing workaround 2 on qemu??
Workaround 3,4 are not an option for me. I already tr
Färber wrote:
>
>> Hi,
>>
>> Am 02.04.2014 09:32, schrieb Sai Prajeeth:
>> > I am booting an OpenIndiana image on qemu by using the -smp 4 option. I
>> > seem to be running into this known
>> > bug http://docs.oracle.com/cd/E19253-01/820-5245/g
Hi list,
I am unable to boot the solaris 10 x86 (32-bit) operating system on qemu
when i use the -icount 1 option. I get the error
"qemu: Fatal: Raised an Interrupt while not in I/O function"
I tried different values for icount but still i am not able to get it
working.
I compiled qemu from sourc
Hi list,
Many services timeout in OpenIndiana (151a8 Server Build 32 bit x86) during
boot when i use the tcg accelerator. This is pushing the boot time of the
OS to more than 45 mins depending on the number of CPUs activated.
I did the tests with qemu-system-i386 -smp sockets=4,cores=1,threads=1
Git bisection tells that 5b6fb069378e61c45c577bbec3d7ef60367f7e4c is the
first bad commit that breaks support for Solaris/OpenIndiana 32-bit x86
guest with icount 1. Seems like the option rom (kvmvapic.bin) is causing
problems. Currently the workaround is to not load the option rom.
Command:
qemu-
Hi list,
I have done experiments and it seems that FreeBSD's libc function
clock_gettime() results in a system call when running on QEMU whereas on
hardware it does not. Does anybody know why? For those interested , you can
find the clock_gettime libc call in freebsd source here:
https://github.co
Hi list,
When running OpenBSD on QEMU without KVM, I see an increase in the number
of sched_yield() system calls in certain multi-threaded benchmarks
(sysbench). However while using KVM accelerator, the number of this system
calls is minimal. Does any have any insight why this is happening? The
ex
15 matches
Mail list logo