* Leonardo Soares Müller (leozinho29...@hotmail.com) wrote:
> I can confirm this, KDE Neon using the command line similar to yours
> crashes QEMU to me too. I will test with Mageia 7 later to see if it
> behaves differently.
>
> But this is a completely different crash. This crash is happening
> e
Thank you for testing this, the last update greatly improved the
situation. libspice-server1 updated, so I rebuilt QEMU. The
libspice-server1 0.14.0-1ubuntu2.4 change log is:
* SECURITY UPDATE: off-by-one error in memslot_get_virt
- debian/patches/CVE-2019-3813.patch: fix checks in server/me
* Leonardo Soares Müller (leozinho29...@hotmail.com) wrote:
> I can confirm this, KDE Neon using the command line similar to yours
> crashes QEMU to me too. I will test with Mageia 7 later to see if it
> behaves differently.
>
> But this is a completely different crash. This crash is happening
> e
Mageia 7 guest is crashing too. The command line:
qemu-system-x86_64 \
-name "Mageia 7" -k pt-br -nodefaults -accel kvm -cpu host -smp
cores=2,threads=1 -m 1G \
-device qxl-vga,xres=1366,yres=768 \
-device qemu-xhci,id=xhcihub -device usb-audio,id=usbaudio,buffer=6144 \
-device usb-tablet,id=usbt
I can confirm this, KDE Neon using the command line similar to yours
crashes QEMU to me too. I will test with Mageia 7 later to see if it
behaves differently.
But this is a completely different crash. This crash is happening
earlier, what I reported first is a crash when the login screen should
lo
* Leonardo Soares Müller (leozinho29...@hotmail.com) wrote:
> libspice-server1 on host: 0.14.0-1ubuntu2.2
> spice-vdagent (the only package) on guest: 0.17.0-1ubuntu2
> Guest kernel version: 4.15.0-44-generic
Hmm, I'm also getting a crash, but I think it's very different from
yours:
./x86_64-soft
libspice-server1 on host: 0.14.0-1ubuntu2.2
spice-vdagent (the only package) on guest: 0.17.0-1ubuntu2
Guest kernel version: 4.15.0-44-generic
>
> OK, great; can can you confirm the version of the spice packages
> on both the guest and host, and the kernel on the guest.
>
> Dave
>
> --
> Dr. D
* Leonardo Soares Müller (leozinho29...@hotmail.com) wrote:
> Here is the backtrace with the debug symbols added:
OK, great; can can you confirm the version of the spice packages
on both the guest and host, and the kernel on the guest.
Dave
> (gdb) bt
> #0 0x70373e97 in __GI_raise (sig
Here is the backtrace with the debug symbols added:
(gdb) bt
#0 0x70373e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1 0x70375801 in __GI_abort () at abort.c:79
#2 0x71171cc9 in spice_logv (log_domain=0x711dc9f5 "Spice",
args=0x7fff360
* Leonardo Soares Müller (leozinho29...@hotmail.com) wrote:
> With QEMU version 3.1.50 (v3.1.0-1218-gad7a21e812-dirty) (commit
> ad7a21e81231ae64540310384fb0f87ac8758b02) on Xubuntu 18.04 host, a KDE
> Neon guest is crashing on boot. The QEMU command line is:
>
> gdb -q -ex "set pagination off" -e
With QEMU version 3.1.50 (v3.1.0-1218-gad7a21e812-dirty) (commit
ad7a21e81231ae64540310384fb0f87ac8758b02) on Xubuntu 18.04 host, a KDE
Neon guest is crashing on boot. The QEMU command line is:
gdb -q -ex "set pagination off" -ex "set print thread-events off" -ex
"handle SIGUSR1 nostop nopass nopr
Here's how to reproduce the crash:
{ "execute": "qmp_capabilities" }
{ "execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name":
"hd0"}}
{ "execute": "object-add", "arguments": {"qom-type": "iothread", "id":
"iothread0"}}
{ "execute": "x-blockdev-set-iothread", "arguments": {"no
Following is the gdb details :
##
ajay@debian:~/rumprun-arm32$ gdb --args qemu-system-arm -machine virt
-nographic -kernel helloer.bin
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Founda
Thanks Alex for the reply ..
>
> Can you run under -s -S and gdb step the *guest* and see where it ends
> up. The above error is usually indicative of the guest going off into
> the weeds somewhere because the hardware isn't what it expects.
>
So, after your reply that it might be because of the
Ajay Garg writes:
>>
>> qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
>> qemu-system-arm. More importantly you need to specify a -M machine type
>> that matches whatever rumprun is expecting.
>>
>
> Oops, sorry my bad.
> Here is the updated status :
>
> ajay@latitude-3480
>
> qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
> qemu-system-arm. More importantly you need to specify a -M machine type
> that matches whatever rumprun is expecting.
>
Oops, sorry my bad.
Here is the updated status :
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$ qemu-sy
Ajay Garg writes:
> Hi All.
>
> We did the following :
>
> a)
> Cross-compile rumprun for ARM on a linux x86_64 :
>
> ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
> CC=arm-linux-gnueabihf-gcc ./build-rr.sh hw
>
> c)
> Tried running on x86_64, via qemu, but got the crash :
>
> ##
Hi All.
We did the following :
a)
Cross-compile rumprun for ARM on a linux x86_64 :
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
CC=arm-linux-gnueabihf-gcc ./build-rr.sh hw
b)
Compile and bake the hello-world binary
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
arm-rumprun-netbsdelf-eabihf-gcc
On Thu, 2 Nov 2017 17:59:58 +0300
Aleksandr Bezzubikov wrote:
> 2017-11-02 17:42 GMT+03:00 Marcel Apfelbaum :
> > On 02/11/2017 16:19, Thomas Huth wrote:
> >>
> >> Hi,
> >>
> >
> > Hi Thomas,
> >
>
> Hi Thomas, Marcel,
>
> >> seems like there's a new way to crash QEMU with the pcie-pci-
2017-11-02 17:42 GMT+03:00 Marcel Apfelbaum :
> On 02/11/2017 16:19, Thomas Huth wrote:
>>
>> Hi,
>>
>
> Hi Thomas,
>
Hi Thomas, Marcel,
>> seems like there's a new way to crash QEMU with the pcie-pci-bridge
>> device (using QEMU master branch of today):
>> > $ s390x-softmmu/qemu-system-s390x
On 02/11/2017 16:19, Thomas Huth wrote:
Hi,
Hi Thomas,
seems like there's a new way to crash QEMU with the pcie-pci-bridge
device (using QEMU master branch of today):
> $ s390x-softmmu/qemu-system-s390x -nographic -S
QEMU 2.10.50 monitor - type 'help' for more information
(qemu) device_ad
Hi,
seems like there's a new way to crash QEMU with the pcie-pci-bridge
device (using QEMU master branch of today):
$ s390x-softmmu/qemu-system-s390x -nographic -S
QEMU 2.10.50 monitor - type 'help' for more information
(qemu) device_add pcie-pci-bridge,id=x
Segmentation fault (core dumped)
Doe
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Wed, Oct 25, 2017 at 07:00:14PM +0100, Dr. David Alan Gilbert wrote:
> > > Hi Dan,
> > > I've got a crash in head (and 2.10) which is a bit of a heisenbug;
> > > I can trigger it with:
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Oct 25, 2017 at 07:00:14PM +0100, Dr. David Alan Gilbert wrote:
> > Hi Dan,
> > I've got a crash in head (and 2.10) which is a bit of a heisenbug;
> > I can trigger it with:
> >
> > ./qemu-system-x86_64 -netdev tap,id=hostnet0,vhost=on,
On Wed, Oct 25, 2017 at 07:00:14PM +0100, Dr. David Alan Gilbert wrote:
> Hi Dan,
> I've got a crash in head (and 2.10) which is a bit of a heisenbug;
> I can trigger it with:
>
> ./qemu-system-x86_64 -netdev tap,id=hostnet0,vhost=on,fd=10 -chardev
> socket,id=charchannel0,path=/tmp/org.qemu.
Hi Dan,
I've got a crash in head (and 2.10) which is a bit of a heisenbug;
I can trigger it with:
./qemu-system-x86_64 -netdev tap,id=hostnet0,vhost=on,fd=10 -chardev
socket,id=charchannel0,path=/tmp/org.qemu.guest_agent.0,server,nowait -monitor
stdio -vnc :0
and then 'q' to quit.
Note I'
On Wed, 16 Aug 2017 15:36:42 +0200
Thomas Huth wrote:
> On 16.08.2017 11:23, Cornelia Huck wrote:
> > On Wed, 16 Aug 2017 07:05:37 +0200
> > Thomas Huth wrote:
> >
> >> Hi,
> >>
> >> I recently noticed that QEMU abort()s if you try to remove the diag288
> >> watchdog. For example:
> >>
> >>
On 16.08.2017 11:23, Cornelia Huck wrote:
> On Wed, 16 Aug 2017 07:05:37 +0200
> Thomas Huth wrote:
>
>> Hi,
>>
>> I recently noticed that QEMU abort()s if you try to remove the diag288
>> watchdog. For example:
>>
>> $ qemu-system-s390x -nographic -nodefaults -S -monitor stdio
>> QEMU 2.9.92 mo
On Wed, 16 Aug 2017 07:05:37 +0200
Thomas Huth wrote:
> Hi,
>
> I recently noticed that QEMU abort()s if you try to remove the diag288
> watchdog. For example:
>
> $ qemu-system-s390x -nographic -nodefaults -S -monitor stdio
> QEMU 2.9.92 monitor - type 'help' for more information
> (qemu) dev
Hi,
I recently noticed that QEMU abort()s if you try to remove the diag288
watchdog. For example:
$ qemu-system-s390x -nographic -nodefaults -S -monitor stdio
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) device_add diag288,id=x
(qemu) device_del x
**
ERROR:/home/thuth/devel/qemu
Hi
On Tue, May 2, 2017 at 11:17 PM Dr. David Alan Gilbert
wrote:
> Hi,
> I've started playing with vhost-user-bridge and have it
> basically up and going, but I've just tried migration and
> I've got a reliable crash for it; I'm not that sure I've
> got it set up right, so suggestions please:
Hi,
I've started playing with vhost-user-bridge and have it
basically up and going, but I've just tried migration and
I've got a reliable crash for it; I'm not that sure I've
got it set up right, so suggestions please:
This is with qemu head, on an f26 host running an f25-ish
guest.
Program rec
On Mon, Feb 15, 2016 at 10:26:17AM +0100, Paolo Bonzini wrote:
>
>
> On 15/02/2016 10:12, Kevin Wolf wrote:
> > Am 14.02.2016 um 17:12 hat Paolo Bonzini geschrieben:
> >> On 14/02/2016 16:52, Paolo Bonzini wrote:
> >>> Reproducer:
> >>>
> >>> x86_64-softmmu/qemu-system-x86_64 \
> >>>-incoming
On 15/02/2016 10:12, Kevin Wolf wrote:
> Am 14.02.2016 um 17:12 hat Paolo Bonzini geschrieben:
>> On 14/02/2016 16:52, Paolo Bonzini wrote:
>>> Reproducer:
>>>
>>> x86_64-softmmu/qemu-system-x86_64 \
>>>-incoming tcp:localhost:12345 -snapshot \
>>>/vm/virt_test/images/jeos-21-64-base.qcow
On 14/02/2016 16:52, Paolo Bonzini wrote:
> Reproducer:
>
> x86_64-softmmu/qemu-system-x86_64 \
>-incoming tcp:localhost:12345 -snapshot \
>/vm/virt_test/images/jeos-21-64-base.qcow2
>
>
> Weird as it may seem, this actually makes some sense for testing
> migration with non-shared stor
Reproducer:
x86_64-softmmu/qemu-system-x86_64 \
-incoming tcp:localhost:12345 -snapshot \
/vm/virt_test/images/jeos-21-64-base.qcow2
Weird as it may seem, this actually makes some sense for testing
migration with non-shared storage...
Paolo
Seen a few of these now, any pointers ?
[243732.348662] INFO: task qemu-system-x86:3546 blocked for more than 120
seconds.
[243732.362227] Not tainted 4.4.0-rc6 #1
[243732.375979] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[243732.389977] qemu-system-x86 D
On Wed, Jul 15, 2015 at 4:28 PM, Peter Maydell
wrote:
> Googling suggests "qsim" is "a project which aims, as part of the
> Manifold simulation effort at Georgia Tech, to create a thread safe
> multicore emulation library based on the QEMU emulator".
>
> My immediate guess is that this is buggy a
On 15 July 2015 at 20:17, Pranith Kumar wrote:
> Hi,
>
> I occasionally get the following crash while running an AArch64 softmmu on
> an x86-64 system. I am using version 2.2 and cannot update to the latest
> version. Did anyone else see this happening? If this is fixed, I would love
> to get the
Hi,
I occasionally get the following crash while running an AArch64 softmmu on
an x86-64 system. I am using version 2.2 and cannot update to the latest
version. Did anyone else see this happening? If this is fixed, I would love
to get the patch backported.
Thanks!
Program received signal SIGSEGV
On 09/03/2015 22:34, Christian Borntraeger wrote:
> I think it is.
> Paolo has posted a quick fix in the thread of "vl: take iothread lock very
> early".
>
> Can you verify?
>
> Paolo, what is the status of this fix?
>
Sending a pull request today with the proper fix.
Paolo
On 03/09/2015 05:34 PM, Christian Borntraeger wrote:
Am 09.03.2015 um 22:03 schrieb Stefan Berger:
Since an upgrade to Fedora 21, I get crashes with QEMU when using -daemonize. I
noticed this since libvirt could not QMP probe QEMU.
This is the command line used:
x86_64-softmmu/qemu-system-x86
Am 09.03.2015 um 22:03 schrieb Stefan Berger:
> Since an upgrade to Fedora 21, I get crashes with QEMU when using -daemonize.
> I noticed this since libvirt could not QMP probe QEMU.
>
> This is the command line used:
>
> x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographi
Since an upgrade to Fedora 21, I get crashes with QEMU when using
-daemonize. I noticed this since libvirt could not QMP probe QEMU.
This is the command line used:
x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults
-nographic -M none -pidfile /tmp/foo -daemonize
Here's the back
On Fri, Nov 21, 2014 at 11:26:23AM -0800, Pawan Uberoy wrote:
> Hello,
>
> We are running a couple of VMs using the qemu command on ubuntu 14.04. It
> seems like there is a corruption on the socket. It crashes on its on after a
> day or so of light activity.
>
> Is this a known issue?
>
> Ple
Hello,
We are running a couple of VMs using the qemu command on ubuntu 14.04. It seems
like there is a corruption on the socket. It crashes on its on after a day or
so of light activity.
Is this a known issue?
Please let me know if this is the right place to post this or if you can help.
th
- Original Message -
> > Can you fetch that in "crash"? If you can, then there's nothing to do on
> > the qemu side (and I'll have to apologize for spamming a bunch of lists
> > :/).
Well, let's be clear -- I was the one who put you up to it...
But no apology is required -- and in fact
I can post the target code and the code generated by TCG - not sure
how helpful that would be. There also seems to be a diff between what
is logged by "-d out_asm" and what I see in gdb with disass, and the
segv occurs in one of the diff blocks.
On Fri, Nov 9, 2012 at 1:42 PM, Catalin Patulea wro
SIGSEGV is in target code:
(gdb) bt
#0 0x402fd349 in code_gen_buffer ()
#1 0x0056113b in cpu_x86_exec (env=0x19489f0)
at /usr/local/google/home/catalinp/src/qemu/cpu-exec.c:599
#2 0x005625f9 in tcg_cpu_exec (env=0x19489f0)
at /usr/local/google/home/catalinp/src/q
Hello,
I bisected down a Windows XP startup crash to the following commit:
0b57e287138728f72d88b06e69b970c5d745c44a is the first bad commit
commit 0b57e287138728f72d88b06e69b970c5d745c44a
Author: David Gibson
Date: Mon Sep 10 12:30:57 2012 +1000
Reproduceable on qemu HEAD and by commenting o
On 7/19/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
Regarding the user's point of view described above, I concur that a
switch would be a good compromise. However given that someone using
CVS head is likely to read the mailing list and all other users
upgrading should read the release notes,
Am 19.07.2007 um 09:25 schrieb Adam Bolte:
>From a usability perspective, I also would expect this to be the
correct
behaviour. Non-technical users using, say, Windows (in full-screen
mode)
on a GNU/Linux desktop need to know that their HDD is full and they
must
free up space - not have th
>From a usability perspective, I also would expect this to be the correct
behaviour. Non-technical users using, say, Windows (in full-screen mode)
on a GNU/Linux desktop need to know that their HDD is full and they must
free up space - not have the guest complain about cryptic HDD errors and
failed
Pause VMs is the only realistic option. This is the correct option,
because it ensures that guest is still alive.
Other options might crash the guest, like Windows BSOD. Worse yet is
that guest may think that it's hard disk is bad, and will start
marking it's sectors as bad-blocks.
When the VM is
On 12/07/07, Daniel P. Berrange <[EMAIL PROTECTED]> wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
> Mike Swanson wrote:
> >On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> >
> >>Problem 1:
> >>When Host HDD is full, all guests simply crash. Tried with dynamically
>
Paul Brook wrote:
Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
second or wait for user input on the monitor.
Better would IMHO be to report an IO error to the guest and allow that to
decide what to do. If you're bothered about robustness and reliability
then ar
> >> Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
> >> second or wait for user input on the monitor.
> >
> > Better would IMHO be to report an IO error to the guest and allow that to
> > decide what to do. If you're bothered about robustness and reliability
> > then arbitr
Daniel P. Berrange wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It sh
Paul Brook wrote:
Besides, most
filesystems reserve some space for the superuser, now unless there's a
cross-platform way to figure out just how much space that is, you'd still
be getting errors despite having 5~10% of the filesystem technically
free.
Qemu might freeze the guest when it g
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
> Mike Swanson wrote:
> >On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> >
> >>Problem 1:
> >>When Host HDD is full, all guests simply crash. Tried with dynamically
> >>growing .VMDK hard disk.
> >>
> >>It shouldn't happen. F
> > Besides, most
> > filesystems reserve some space for the superuser, now unless there's a
> > cross-platform way to figure out just how much space that is, you'd still
> > be getting errors despite having 5~10% of the filesystem technically
> > free.
>
> Qemu might freeze the guest when it gets
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays when
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> Problem 1:
> When Host HDD is full, all guests simply crash. Tried with dynamically
> growing .VMDK hard disk.
>
> It shouldn't happen. For example, both VirtualPC and VirtualBox pause
> all VMs, and gray their displays when something like
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays when something like that happens.
Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron.
Prob
ahq$ ./qemu -nographic -snapshot -fda serflp.fs
Segmentation fault (core dumped)
[...]
(gdb) bt
#0 console_putchar (s=0x8ae43000, ch=112)
at /scrap/ahq/build/qemu/console.c:809
#1 0x1c01258a in console_puts (chr=0x0,
buf=0xcfbd1e20 "parallel0 console\r\n", len=19)
at /scrap/ahq/build/
Hi,
I'm using the QEMU 0.8.2 Ubuntu package. I've mounted fda as an image I
created with `dd if=/dev/zero of=floppy.img bs=512 count=2880`. However, when
I try to format it with the format tool in WIndows 98SE, QEMU crashes with
the following error:
FLOPPY ERROR: fdctrl_start_transfer: dma_mode
On Sun, Oct 29, 2006 at 08:25:00PM -0300, Alejandro Pulver wrote:
> Hello.
>
> I am using qemu-0.82 with kqemu-kmod-1.3.0.p9 in a FreeBSD
> 6.1-RELEASE-p1 host OS (I have tried with and without optimization
> hacks, and also the 20061026 snapshot).
>
> I have created a disk image and installed Wi
On Fri, 3 Nov 2006 21:29:25 -0800
Russell Jackson <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 29, 2006 at 08:25:00PM -0300, Alejandro Pulver wrote:
> > Hello.
> >
> > I am using qemu-0.82 with kqemu-kmod-1.3.0.p9 in a FreeBSD
> > 6.1-RELEASE-p1 host OS (I have tried with and without optimization
> >
Hello.
I am using qemu-0.82 with kqemu-kmod-1.3.0.p9 in a FreeBSD
6.1-RELEASE-p1 host OS (I have tried with and without optimization
hacks, and also the 20061026 snapshot).
I have created a disk image and installed Windows XP Professional SP1
EN (with kqemu disabled) as the guest OS.
When I star
> Unsupported return value: 0x
This is a kqemu bug.
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi !
I'm permit to send you a report for a crash using qemu with kqemu
acceleration.
When i right-click on a drive in the drive manager, the system crach.
Here is the message :
EAX=bfc8890c EBX=bfc88aa0 ECX=7ffde2d0 EDX=7ffde318
ESI=7ffde2fc EDI= EBP=bfc88a14 ESP=bfc887a8
EIP=a000357a E
52...but some days I feel much older :-)
On 2/7/06, wangji <[EMAIL PROTECTED]> wrote:
> On Monday 06 February 2006 23:34, Michael Fisher wrote:
> > My apologies...I was sure I had checked 0.8.0 when it came out and
> > verifed the crashing at full-screen but apparently old age is catching
> > up w
On Monday 06 February 2006 23:34, Michael Fisher wrote:
> My apologies...I was sure I had checked 0.8.0 when it came out and
> verifed the crashing at full-screen but apparently old age is catching
> up with me. I booted it up with DSL and it worked perfectly.
how old are you,sir?
>
> Again, my apo
My apologies...I was sure I had checked 0.8.0 when it came out and
verifed the crashing at full-screen but apparently old age is catching
up with me. I booted it up with DSL and it worked perfectly.
Again, my apologies,
desNotes
On 2/6/06, malc <[EMAIL PROTECTED]> wrote:
> On Mon, 6 Feb 2006, Mi
On Mon, 6 Feb 2006, Michael Fisher wrote:
I am using Qemu to boot various Linux distro's on Windows & Linux hosts. I
am noticing that the last two released versions (0.7.2 & 0.8.0) crash when
pressing Ctrl-Alt-F for fullscreen. Version 0.7.0 appears to not have this
problem.
Is anyone else seei
I am using Qemu to boot various Linux distro's on Windows & Linux hosts. I am noticing that the last two released versions (0.7.2 & 0.8.0) crash when pressing Ctrl-Alt-F for fullscreen. Version 0.7.0 appears to not have this problem.
Is anyone else seeing this? am I missing something?thanks,desNot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a reproducable bug, but involving a rather complex setup, before
attempting to track this down, I would like to know if this is already
known.
Versions note for the host system:
> uname -a
Linux 2.4.21-37.EL.cernsmp #1 SMP i686 i686 i386 G
Hello,
having just experimented with the -monitor option to get the monitor to
stdio, I got a mysterious segmentation fault.
This is tested with a freshly checked out version (but it also crashes with
older versions).
Command line: qemu -hda win98/win98-new.img -cdrom /dev/cdrom0 -boot c
-snapshot
78 matches
Mail list logo
