I think similar bug has been filed against qemu-kvm debian package
(http://bugs.debian.org/683983). Will try to reproduce/bisect as time
permits. Note the debian bugreport also mentions segfault on usb_del in
monitor.
** Bug watch added: Debian Bug tracker #683983
http://bugs.debian.org/cgi-b
Ok. I tried to bisect this, but it appears to be not so easy. The
problem is that between 1.0 and 1.1, there's a lot of usb breakage, and
bisection leads to segfaults or assertion failures.
(qemu) usb_add host:003.002
usb_create: no bus specified, using "usb.0" for "usb-host"
(qemu) Segmentatio
While dealing with USB issues today I noticed that
usb_del monitor command is broken, attempting to
delete any usb device immediately results in assertion
failure:
(qemu) usb_del 0.1
ERROR:qom/object.c:408:object_delete: assertion failed: (obj->ref == 0)
Aborted
I bisected this issue to commit:
On 08.08.2012 16:18, Michael Tokarev wrote:
> While dealing with USB issues today I noticed that
> usb_del monitor command is broken, attempting to
> delete any usb device immediately results in assertion
> failure:
>
> (qemu) usb_del 0.1
> ERROR:qom/object.c:408:object_del
On 08.08.2012 16:39, Paolo Bonzini wrote:
> Il 08/08/2012 14:22, Michael Tokarev ha scritto:
>> @@ -152,6 +152,16 @@ int qdev_init(DeviceState *dev)
>> +
>> +if (!OBJECT(dev)->parent) {
>> +static int unattached_count = 0;
>> +gcha
On 08.08.2012 17:09, Michael Tokarev wrote:
[]
> Something similar should be applied to 1.1-stable. FWIW, some
> changes are not needed there.
Cherry-pick to stable-1.1 removes the two unneeded hunks.
This is what I plan to include into debian package. It
fixes the original usb_del issue,
On 08.08.2012 18:42, Michael Tokarev wrote:
> Should it go to qemu/stable-1.1 as well?
qemu/stable-1.1 also includes f63e60327b8e239ae97fa71060940ca20a8bf38e.
FWIW.
Which debian package do you mean? The fix is included is current debian
qemu-kvm 1.1.0+dfsg-3 release. qemu package in debian does not have
this fix however.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
On 09.08.2012 17:38, Paolo Bonzini wrote:
> Leaving the aiocb to a non-NULL value leads to an assertion failure when
> rerror/werror are set to stop or enospc, and the operation is retried.
> scsi-disk checks that the aiocb member is NULL before filling it.
>
> This patch correctly resets the aioc
As a follow-up to the patch "tsc: use kvmclock for
calibration".
There's another problem reported by several users.
The sympthom is that grub does not show boot menu,
it boots default entry right away without any pause.
After quite some debugging it turned out to be
TSC issue. Grub uses tsc for
On 10.08.2012 00:47, Marcelo Tosatti wrote:
[]
>>> calibrate_tsc (void)
>>> {
>>> /* First calibrate the TSC rate (relative, not absolute time). */
>>> grub_uint64_t start_tsc;
>>> grub_uint64_t end_tsc;
>>>
>>> start_tsc = grub_get_tsc ();
>>> grub_pit_wait (0x);
>>> end_tsc = grub
On 10.08.2012 11:33, Gleb Natapov wrote:
> On Thu, Aug 09, 2012 at 10:27:43PM +0400, Michael Tokarev wrote:
>> As a follow-up to the patch "tsc: use kvmclock for
>> calibration".
>>
>> There's another problem reported by several users.
>> The symp
On 07.08.2012 12:59, Gerd Hoffmann wrote:
> Commit 59310659073d85745854f2f10c4292555c5a1c51 is incomplete,
> we'll arrive in the scsi command complete callback in CSW state
> and must handle that case correctly.
It appears to be 1.1-stable material, rigt?
What's the outcome of the issue -- guest-t
this thread and this fix
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/95314/focus=1338226
are about the same issue, apparently. Please try it and see if it fixes
you issue too.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1033494
Title:
qemu-system-x86_64 segfaults with kernel 3.5.0
Status in QEMU:
Incomplete
Bug d
On 12.08.2012 01:24, Peter Maydell wrote:
> POSIX allows sendmsg() and recvmsg() to fail EMSGSIZE if passed a zero
> msg.msg_iovlen (in particular the MacOS X implementation will do this).
> Handle the case where iov_send_recv() is passed a zero byte count
> explicitly, to avoid accidentally depen
On 12.08.2012 12:10, Gleb Natapov wrote:
[]
> Any chance to bisect it?
The bisecion leads to this commit:
commit 17ee47418e65b1593defb30edbab33ccd47fc1f8
Merge: 13b0496 5d17c0d
Author: Jan Kiszka
Date: Tue Apr 10 16:26:23 2012 +0200
Merge commit '5d17c0d2df4998598e6002b27b8e47e792899a0f'
On 06.08.2012 18:56, Paolo Bonzini wrote:
> Commit b1f416aa8d870fab71030abc9401cfc77b948e8e breaks vhost_net
> because it always registers the virtio_pci_host_notifier_read() handler
> function on the ioeventfd, even when vhost_net.ko is using the ioeventfd.
> The result is both QEMU and vhost_net.
accidentally depending on the OS to treat zero
> msg_iovlen as a no-op.
>
> Signed-off-by: Peter Maydell
> ---
> This is what was causing 'make check' to fail on MacOS X.
> The other option was to declare that a zero bytecount was illegal, I guess.
Acked-by: Michael Tok
On 13.08.2012 17:07, Jan Kiszka wrote:
[]
>> The bisecion leads to this commit:
>>
>> commit 17ee47418e65b1593defb30edbab33ccd47fc1f8
>> Merge: 13b0496 5d17c0d
>> Author: Jan Kiszka
>> Date: Tue Apr 10 16:26:23 2012 +0200
>>
>> Merge commit '5d17c0d2df4998598e6002b27b8e47e792899a0f' into
>>
On 13.08.2012 22:18, Jan Kiszka wrote:
> 0cdd3d1444 fixed reading back the counter load time from the kernel
> while assuming the kernel would always update its load time on writing
> the state. That is only true for channel 1, and so pit_get_channel_info
> returned wrong output pin states for high
On 15.08.2012 13:10, Evgeny Voevodin wrote:
> Casting of 0x0101010101010101ULL to long will truncate it to 32
> bits on 32bit hosts, and won't truncate on 64bit hosts.
>
> Signed-off-by: Evgeny Voevodin
> ---
> savevm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
On 15.08.2012 13:31, Markus Armbruster wrote:
> There are more, but let's start with these two.
Yes, there are more of the same theme. In particular,
why transparent huge pages support has never been
applied? IIRC it went to nowhere after a question
about memory sizing and alignment popped up --
On 15.08.2012 15:46, Avi Kivity wrote:
> On 08/15/2012 02:44 PM, Michael Tokarev wrote:
>> Yes, there are more of the same theme. In particular,
>> why transparent huge pages support has never been
>> applied? IIRC it went to nowhere after a question
>> about memory
Quite some time ago there was a thread on qemu-devel,
started by Andrea, about modifying qemu to better
use transparent huge pages:
http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01250.html
That thread hasn't reached any conclusion, but some time
after that Avi implemented a similar cha
[Reposting with the right email address of Andrea]
Quite some time ago there was a thread on qemu-devel,
started by Andrea, about modifying qemu to better
use transparent huge pages:
http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01250.html
That thread hasn't reached any conclusion, bu
On 15.08.2012 16:51, Avi Kivity wrote:
> On 08/15/2012 03:45 PM, Michael Tokarev wrote:
>>
>> But apparently, THP does not work still, even with 2Mb
>> alignment: when running a guest, AnonHugePages in
>> /proc/meminfo stays at 0 - either in kvm mode or in tcg
>> m
On 15.08.2012 18:26, Avi Kivity wrote:
> On 08/15/2012 05:22 PM, Michael Tokarev wrote:
>
>>>
>>> Please provide extra info, like the setting of
>>> /sys/kernel/mm/transparent_hugepage/enabled.
>>
>> That was it - sort of. Default value here is enab
On 15.08.2012 19:03, Michael Tokarev wrote:
> +#ifdef MADV_HUGEPAGE
> +#error
Heh. This #error shouldn't be here ofcourse, I were
checking if we really getting there.
> +qemu_madvise(ptr, size, MADV_HUGEPAGE);
> +#endif
Hello.
This issue has been reported several times already,
but I can't reproduce it locally. Gerd, can you
please take a look, maybe you may ask better
question to the OP(s) about what to try.
https://bugs.launchpad.net/qemu/+bug/1033727
http://bugs.debian.org/683983
Gerd, I tried to catch you
On 16.08.2012 12:14, Gerd Hoffmann wrote:
> On 08/16/12 09:45, Michael Tokarev wrote:
>> Hello.
>>
>> This issue has been reported several times already,
>> but I can't reproduce it locally. Gerd, can you
>> please take a look, maybe you may ask better
>
On 16.08.2012 12:23, Peter Maydell wrote:
> On 16 August 2012 09:14, Gerd Hoffmann wrote:
[]
>>> http://bugs.debian.org/683983
>>
>> No idea, must be some QOM thingy.
This was http://bugs.debian.org/684282, unrelated to usb.
> The "crash on usb_del" problem has been discussed on the list
> befor
On 16.08.2012 18:58, Iustin Pop wrote:
> Commit 947995c (block: protect path_has_protocol from filenames with
> colons) introduced a way to handle filenames with colons based on
> whether the path contains a slash or not. IMHO this is not optimal,
> since we shouldn't rely on the contents of the pa
First of all, your kernel panic screenshot is incomplete: it lacks the
most important information which were scrolled off the (virtual) screen.
Please enable serial console and capture whole OOPs in a text form.
Second, it isn't clear whenever this is HOST kernel panic or GUEST
kernel panic. I as
On 17.08.2012 14:56, Jan Kiszka wrote:
> This MMIO area is an entry gate to legacy PC ISA devices, addressed via
> PIO over there. Quite a few of the PIO ports have side effects on access
> like starting/stopping timers that must be executed properly ordered
> /wrt the CPU. So we have to remove the
On 17.08.2012 06:55, Marek Vasut wrote:
> Disallow negative value boundaries of the redraw rectangle.
> This fixes a segfault when using -vga vmware.
>
> Signed-off-by: Marek Vasut
> ---
> hw/vmware_vga.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> NOTE: I tested this by
On 18.08.2012 22:56, Paolo Bonzini wrote:
> Il 12/08/2012 12:08, Michael Tokarev ha scritto:
>>>> Commit b1f416aa8d870fab71030abc9401cfc77b948e8e breaks vhost_net
>>>> because it always registers the virtio_pci_host_notifier_read() handler
>>>> function on t
On 19.08.2012 00:51, Stefan Weil wrote:
> +++ b/qapi/opts-visitor.c
> @@ -416,7 +416,7 @@ opts_visitor_cleanup(OptsVisitor *ov)
> g_hash_table_destroy(ov->unprocessed_opts);
> }
> g_free(ov->fake_id_opt);
> -memset(ov, '\0', sizeof *ov);
> +g_free(ov);
Shouldn't the fu
On 20.08.2012 21:13, Tomas Racek wrote:
[]
Can we trim the old, large and now not-so-relevant discussion please? ;)
> I can provide you with more different traces if it can help. But I thought
> that maybe it will be more useful for you to try it on your own. So I've
> prepared some minimal debi
Thank you!
/mjt
> cpu model: AMD Turion(tm) II Neo N40L Dual-Core Processor
> qemu-kvm version: 1.1.1 (Debian package by Michael Tokarev),
> happened also with 1.1.0
> host: Debian wheezy, 3.2.23, x86_64
> guest: Debian wheezy, 3.2.23, x86_64
>
> /usr/bin
On 27.08.2012 22:56, Blue Swirl wrote:
[]
>> +static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
>> +{
>> +AssignedDevRegion *d = opaque;
>> +uint8_t *in = d->u.r_virtbase + addr;
>
> Don't perform arithmetic with void pointers.
There are a few places in common qemu cod
On 26.01.2012 13:08, Kevin Wolf wrote:
[]
>> -readconfig fd:9
> Magic prefixes like this have one big problem: What if someone has a
> config file called "fd:9"? We have the very same problem with protocols
-readconfig ./fd:9
does the trick.
> in the block layer and while in the general case it
26.01.2012 13:54, ronnie sahlberg wrote:
Ok so what about this
You use a filename starting with "/proc/self/fd/" and you dont have a
proc filesystem mounted? you are on your own!
No you're not:
IF ! STRNCMP (filename, "/proc/self/fd/", 14) THEN
fopen(filename, "r")
ELSE
26.01.2012 18:55, Michael Tokarev wrote:
26.01.2012 13:54, ronnie sahlberg wrote:
Ok so what about this
You use a filename starting with "/proc/self/fd/" and you dont have a
proc filesystem mounted? you are on your own!
BTW, usual idiom (which was implemented in gawk for example)
The amount of spam our wiki.qemu.org collects, is
increasing every day. It was easy several months
ago to manually delete these pages once a week to
keep wiki spam-free, now they sometimes manage to
re-create a page while I delete it!
No, it is not counted in 1000s per day - not yet
anyway. But
This option makes no difference for manpages which contains only
ascii chars. But for manpages with actual UTF8 characters (qemu
docs contains these), this change allows to see real characters
instead of mojibakes or substitutes.
Signed-off-By: Michael Tokarev
---
Makefile |9 +
1
@documentencoding in input and places
it at the beginning of output as =encoding directive.
Signed-Off-By: Michael Tokarev
---
scripts/texi2pod.pl |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
index 9ed056a..94097fb 100755
On 02.02.2012 18:32, Peter Maydell wrote:
> On 2 February 2012 14:16, Michael Tokarev wrote:
>> +POD2MAN = pod2man --utf8
>> qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi
>>$(call quiet-command, \
>> perl -Ww -- $(SRC_PATH)/scri
On 02.02.2012 18:49, Peter Maydell wrote:
> On 2 February 2012 14:46, Michael Tokarev wrote:
>> Besides, this is a task for another patch, since this one "only" thing
>> this patch does is addresses the --utf8 issue. Maybe it is so trivial
>> that adding --releas
On 02.02.2012 15:15, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Anthony Liguori wrote:
>> Otherwise we can write beyond the buffer and corrupt memory. This is tracked
>> as CVE-2012-0029.
>
> The stable-1.0 branch looks vulnerable too, shouldn't this patch be
> backported?
This goes on sin
Replying to an old message...
On 06.08.2008 20:54, Drake Wilson wrote:
> Hello, qemu-devel!
>
> I use QEMU to run virtual machines on a Debian GNU/Linux machine with
> AMD64 PC-class hardware. My X keyboard configuration uses Meta
> instead of Alt; even though I have a PC-style keyboard whose ke
On 14.02.2012 05:42, Reeted wrote:
Hello, subject says it all
The driver for windows 2000 for the -vga std should be the Anapa VBE Vesa VBEMP
if I understand correctly
but I cannot on earth find this executable
http://navozhdeniye.narod.ru/vbemp.htm
all links for download all over the world are
On 15.02.2012 16:35, Dyweni - Qemu-Devel wrote:
Hi List,
This morning I ran across a thread on this list from Oct'11 about slow
booting with large initrd images. Reading through that thread, I didn't
really see any sort of definitive resolution to the problem.
There's been several mentions of
On 12.10.2012 10:49, Mike Lovell wrote:
> /* request a tap device, disable PI, and add vnet header support if
> - * requested and it's available. */
> -prep_ifreq(&ifr, "tap%d");
> + * requested and it's available. use ifname if provided for tap name. */
> +prep_ifreq(&ifr, ifn
On 14.10.2012 09:01, yue-kvm wrote:
> what is the defferences between /usr/libexec/qemu-kvm and
> /usr/bin/qemu-system-x86_64?
> my OS is centos6.2, qemu-kvm is from a rpm package, while
> qemu-system-x86_64 is builded manually from source code.
> 1.
> if i can recognize they are the same th
On 15.10.2012 22:57, Luiz Capitulino wrote:
> On Fri, 5 Oct 2012 16:47:57 -0300
> Luiz Capitulino wrote:
>
>> This makes it possible for QEMU to use transparent huge pages (THP)
>> when transparent_hugepage/enabled=madvise. Otherwise THP is only
>> used when it's enabled system wide.
>>
>> Signed
On 10.10.2012 16:30, Paolo Bonzini wrote:
[]
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -372,6 +372,10 @@ VncInfo *qmp_query_vnc(Error **errp)
> }
> }
>
> +if (vnc_display->lsock == -1) {
FWIW, can't we use "< 0" condition in all cases like this - for
testing whenever a
Hello.
I noticed that "some" versions of linux guests shows quite
bad behavour of mouse cursor: it freezes after some idle
time, and when you move mouse, it jumps after some delay
to rather distant position. So, mouse becomes "freezy/jumpy",
so to say.
Quite some painful debugging pointed to the
On 17.10.2012 12:56, Gerd Hoffmann wrote:
> On 10/17/12 10:41, Michael Tokarev wrote:
>> Hello.
>>
>> I noticed that "some" versions of linux guests shows quite
>
> What is "some"?
I guess it is almost all modern distros. Debian wheezy,
Ubuntu
On 17.10.2012 13:15, Michael Tokarev wrote:
> But the mouse is jumpy anyway. I guess one can get used to this
> behavour, given the tradeoff and that the behavour is not VERY annoying --
> it is annoying, but just for a "bit", it feels like old mechanical
> mouse with ba
On 20.10.2012 00:43, Jason Baron wrote:
> Hi,
>
> Qemu bits for q35 support, I'm posting the seabios changes separately. The
> patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the
Just a small maybe-nitpick: can we ue pc-q35 here instead of pc_q35 (ie,
minus instead of undersc
On 20.10.2012 00:43, Jason Baron wrote:
> From: Jason Baron
>
> If -L is specified, and qemu does not find the bios file in , then
> the search fails. Add infrastructure such that the search will continue in
> the default paths, if not found in the -L path.
>
> Reviewed-by: Paolo Bonzini
> Sig
missed this
case when testing initial change.
And I think this is a wrong approach too.
This should be defined as qemu_helperdir variable instead of
CONFIG_QEMU_HELPERDIR, just like all other qemu_*dirs around,
and scripts/create_config will take care of it by expanding
the variable
FWIW, this is implemented and works in seabios 0.7.1
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/611142
Title:
seabios should have native scsi support
Status in QEMU:
New
Status in “qemu-kvm”
by default images are expected to be open read-write. I'm against too
much "intelligence" here, -- we may be running qemu as wrong user, or
with wrong permissions of the image in question, and qemu should fail to
start if the image can't be open using specified access flags (which is
read-write by
On 22.10.2012 19:37, Anthony Liguori wrote:
[]
> IOW:
>
> q35-next <- bleeding edge version of code. No compatibility guarantee
> q35-0.1 <- if we decide we want to have a "tech preview" of q35 that's
> incomplete but will be supported for compat
> q35-1.0 <- the first "complete" re
Ping?
/mjt
On 19.09.2012 12:08, Michael Tokarev wrote:
> This reverts commit 67c5322d7000fd105a926eec44bc1765b7d70bdd:
>
> I'm not sure if the retry logic has ever worked when not using FIFO mode.
> I
> found this while writing a test case although code inspecti
Ping?
/mjt
On 18.09.2012 18:32, Andreas Färber wrote:
> Am 18.09.2012 14:29, schrieb Michael Tokarev:
>> Has it been applied to anything? I don't think so.
>> Is it still needed?
>
> Not in qemu.git yet, still applicable AFAICT. CC'ing Paolo.
>
> /-F
d-and-tested-by: Michael Tokarev
(but the thing is rather trivial and obvious :)
(this fixes https://bugs.launchpad.net/qemu/+bug/1071236 fwiw --
maybe we should add some references to bugs when the work/patch
is after a bugreport)
This fix is applicable to -stable, at least to 1.2 and 1.1 ver
On 26.09.2012 18:56, Michael Tokarev wrote:
> On 26.09.2012 17:46, Anthony Liguori wrote:
> []
>> This is a good example of where we need improved documentation but I
>> agree 100% with Peter.
>
> So what do we do?
>
> We've a clear bug, I can only fix it i
So closing it with "fix released".
(which had a complication for me: I changed status for ubuntu package
instead of changing it for qemu line, and now I can't restore it back
for ubuntu - since I don't know how/when ubuntu bugs are closed, only
upstream)
** Changed in: qemu-kvm (Ubuntu)
St
On 27.10.2012 15:33, Peter Maydell wrote:
> On 27 October 2012 12:23, Michael Tokarev wrote:
>>
>> I still don't see why
>>
>> -nographic -daemonize
>>
>> makes no sence while
>>
>> -curses -daemonize
>>
>> does?
>
>
On 27.10.2012 16:48, Blue Swirl wrote:
[]
>> I'd rather have -nographic work with -daemonize, since the
>> alternative - shown in the patch comment - is rather long and
>> it is easy to forget to "nullify" some option, while -nographic
>> can do that easy and it is convinient, but if people dislike
On 27.10.2012 16:55, Michael Tokarev wrote:
> On 27.10.2012 16:48, Blue Swirl wrote:
> []
>>> I'd rather have -nographic work with -daemonize, since the
>>> alternative - shown in the patch comment - is rather long and
>>> it is easy to forget to "nullif
ff-by: Michael Tokarev
---
qemu-char.c |4
vl.c| 24 +---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index afe2bfb..21c6a0d 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -772,6 +772,10 @@ static CharDriver
This is fixed by the following patch: http://www.mail-archive.com/qemu-
de...@nongnu.org/msg138606.html
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bu
29.10.2012 13:18, Stefan Hajnoczi wrote:
> On Sat, Oct 27, 2012 at 05:15:15PM +0400, Michael Tokarev wrote:
>> diff --git a/vl.c b/vl.c
>> index 9f99ef4..db48d62 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3413,6 +3413,26 @@ int main(int argc, char **argv, char **env
20.06.2012 16:24, Daniel P. Berrange wrote:
delete mode 100644 ui/vnc-jobs-async.c
delete mode 100644 ui/vnc-jobs-sync.c
create mode 100644 ui/vnc-jobs.c
Is there a reason to rename vnc-jobs-foo.c to vnc-jobs.c ?
I'd leave it alone at this stage, omiting just the rename...
/mjt
On 03.07.2012 15:05, xiaw...@linux.vnet.ibm.com wrote:
> From: Wenchao Xia
>
> Qemu system emulator reports only fails that make people confused
> about why, when it is invoked with nbd block device tring to connect
> qemu-nbd server. In fact qemu will try connect server for several
> times but
On 05.07.2012 10:42, Paolo Bonzini wrote:
> Il 05/07/2012 05:29, Wayne Xia ha scritto:
[]
>> Hi Paolo, should I make a patch to make persistent the default for
>> qemu-nbd?
>
> Yes, why not. However, as mentioned above client mode should still be
> non-persistent.
I don't think this makes sense
On 06.07.2012 06:42, Amos Kong wrote:
> On 30/06/12 10:02, ak...@redhat.com wrote:
>> From: Amos Kong
>>
>> Currently qemu outputs some low-level error in qemu-sockets.c
>> when failed to start vnc server.
>> eg. 'getaddrinfo(127.0.0.1,5902): Name or service not known'
>>
>> Some libvirt users coul
On 06.07.2012 12:09, Amos Kong wrote:
> - Original Message -
>> Michael Tokarev writes:
>>> Gyus, please, pretty PLEASE stop doing things like this.
>>>
>>> Amos, your patch does TWO things. One is to clarify error
>>> message as correctly
I've got a (longish) bugreport about qemu-kvm not
working on an AMD bulldozer CPU. In particular,
winXP guests which worked fine before, after upgrade
of the host CPU stopped working with a BSOD, and no
new winXP install can be completed due to installer
freezing somewhere in process.
I don't hav
On 17.06.2012 17:14, Avi Kivity wrote:
> On 06/17/2012 04:06 PM, Blue Swirl wrote:
>
>>> strtosz() is much too general. We could do it in vl.c without trouble.
>>> However, it takes away our ability to emulate a "640k should be enough
>>> for everyone" machine.
>>
>> Then how about current max o
I come across a patch in ububtu qemu-kvm package, this:
From: Nelson Elhage
Date: Thu, 19 May 2011 13:23:17 -0400
Subject: [PATCH] virtqueue: Sanity-check the length of indirect descriptors.
We were previously allowing arbitrarily-long descriptors, which could lead to a
buffer overflow in the qe
"if x or y < 0, set them to 0 (and decrement with/height accordingly)"
If it is possible in this context to have negative x or y, it is also
possible to have them larger than width and heigth by absolute value, so
that when decrementing width/height accordingly, width/height becomes
negative too.
** Changed in: qemu
Status: Invalid => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
New
Bug description:
qem
This is a bit more interesting. I've got a bugreport in debian about
the same thing, and verified it in debian qemu-kvm package - indeed,
with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without
an extra keypress, but only when kernel_irqchip is enabled. Ie, the
following requires
when the guest is waiting for the keypress, it is sitting in KVM_RUN
ioctl and eating 100% CPU. When enabling Seabios debugging, the last
lines before the stall is this:
Returned 57344 bytes of ZoneHigh
e820 map has 7 items:
0: - 0009dc00 = 1 RAM
1: 0009dc00 -
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Confirmed
Status in “qemu
Please take this to your shell. The queston mark is a metacharacter for
any *nix shell, you should just quote or backslash it. The same
question mark is not special on windows.
Thanks,
/mjt
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you ar
Ping? Another month has passed without any reply...
Thanks,
/mjt
On 11.06.2012 23:19, Michael Tokarev wrote:
> On 11.06.2012 22:31, Anthony Liguori wrote:
> []
>> Doesn't build:
>>
>> LINK qemu-ga
>> cutils.o: In function `qemu_iovec_to_buf'
these two changes.
>
> Signed-off-by: Stefan Weil
Signed-off-by: Michael Tokarev
Granted, I never _ever_ tested or even compiled this
part. Should have been. Thank you Stefan!
/mjt
This is fixed by commit a3548077062dd9dc2701ebffd931ba6eaef40bec which
is included in 1.3 release of qemu.
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.lau
This is a follow-up to a more-or-less trivial commit,
2e84849aa2cc7f220d3b3668f5f7e3c57bb1b590 . I'm adding
some more context - the whole function in question.
commit 2e84849aa2cc7f220d3b3668f5f7e3c57bb1b590
Author: Don Slutz
Date: Fri Sep 21 20:13:13 2012 -0400
target-i386: Allow tsc-fr
This is fixed by qemu commit f0cc4aa8450376ca2aee3ebb09db71f9f2ff333b
which went into qemu-1.3 release.
** Changed in: qemu
Status: New => Fix Committed
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu
On 18.12.2012 13:46, Philipp Hahn wrote:
> I think I found your missing link:
> After filling in "QCowL2Meta *m", that request ist queued:
> QLIST_INSERT_HEAD(&s->cluster_allocs, m, next_in_flight);
> do prevent double allocating the same cluster for overlapping requests, which
> is checked in
Since at least 1.1 version of qemu, I can't run any
mips binary using statically linked qemu-mips on x86_64
host. It immediately fails with SIGSEGV:
# chroot mipsroot /bin/bash
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
mipsroot/bin/bash: ELF 32-bit MSB executable, MIPS,
On 18.12.2012 17:44, Stefan Hajnoczi wrote:
> On Wed, Dec 05, 2012 at 01:31:30PM -0500, Michael Contreras wrote:
>> Discard packets longer than 16384 when !SBP to match the hardware behavior.
>>
>> Signed-off-by: Michael Contreras
>> ---
>> hw/e1000.c | 7 +--
>> 1 file changed, 5 insertions(
On 18.12.2012 20:10, Michael Tokarev wrote:
> Since at least 1.1 version of qemu, I can't run any
> mips binary using statically linked qemu-mips on x86_64
> host. It immediately fails with SIGSEGV:
>
> # chroot mipsroot /bin/bash
> qemu: uncaught target signal 11 (Seg
1 - 100 of 7493 matches
Mail list logo
