On 07/31/2012 08:37 PM, Stefan Priebe wrote:
> Now i got it working - sorry used old gdb.
>
> This is the backtrace:
>
> Core was generated by `/usr/bin/qemu-system-x86_64 -id 103 -chardev
> socket,id=qmp,path=/var/run/qemu-s'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f6ca10faed8 in ?? () from /lib/libc.so.6
> (gdb) where
> #0 0x00007f6ca10faed8 in ?? () from /lib/libc.so.6
> #1 0x00007f6ca54e0098 in virtio_notify_vector (vdev=0x7f6ca10fae98,
> vector=32620)
> at /root/src/pve-qemu-kvm/qemu-kvm/hw/virtio.c:493
> #2 0x00007f6ca54e0e25 in virtio_notify (vdev=0x7f6ca10fae98,
> vq=0x7f6ca10faf18) at /root/src/pve-qemu-kvm/qemu-kvm/hw/virtio.c:739
> #3 0x00007f6ca54d5bb0 in virtio_blk_req_complete (req=0x7f6ca6fe4440,
> status=0)
I notice the ip is different from the first trace. Please run this a few
more times and see if it always fails in the same place, or in random
places (and post the traces please).
--
error compiling committee.c: too many arguments to function
Hi,
ok i found a faster way to trigger this. Just boot the ubuntu rescue system.
So here are 3 backtraces from booting the rescue system:
http://pastebin.com/raw.php?i=xCy2pEcP
To me they all look the same.
Thanks!
Stefan
Am 01.08.2012 10:44, schrieb Avi Kivity:
> On 07/31/2012 08:37 PM, Stefan Priebe wrote:
>> Now i got it working - sorry used old gdb.
>>
>> This is the backtrace:
>>
>> Core was generated by `/usr/bin/qemu-system-x86_64 -id 103 -chardev
>> socket,id=qmp,path=/var/run/qemu-s'.
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x00007f6ca10faed8 in ?? () from /lib/libc.so.6
>> (gdb) where
>> #0 0x00007f6ca10faed8 in ?? () from /lib/libc.so.6
>> #1 0x00007f6ca54e0098 in virtio_notify_vector (vdev=0x7f6ca10fae98,
>> vector=32620)
>> at /root/src/pve-qemu-kvm/qemu-kvm/hw/virtio.c:493
>> #2 0x00007f6ca54e0e25 in virtio_notify (vdev=0x7f6ca10fae98,
>> vq=0x7f6ca10faf18) at /root/src/pve-qemu-kvm/qemu-kvm/hw/virtio.c:739
>> #3 0x00007f6ca54d5bb0 in virtio_blk_req_complete (req=0x7f6ca6fe4440,
>> status=0)
>
> I notice the ip is different from the first trace. Please run this a few
> more times and see if it always fails in the same place, or in random
> places (and post the traces please).
>
>
On 08/01/2012 12:24 PM, Stefan Priebe - Profihost AG wrote:
> Hi,
>
> ok i found a faster way to trigger this. Just boot the ubuntu rescue
> system.
>
> So here are 3 backtraces from booting the rescue system:
> http://pastebin.com/raw.php?i=xCy2pEcP
>
> To me they all look the same.
They are. What version of qemu are you using?
--
error compiling committee.c: too many arguments to function
Am 01.08.2012 11:33, schrieb Avi Kivity:
>> So here are 3 backtraces from booting the rescue system:
>> http://pastebin.com/raw.php?i=xCy2pEcP
>>
>> To me they all look the same.
>
> They are. What version of qemu are you using?
latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
kernel.
Stefan
On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>> So here are 3 backtraces from booting the rescue system:
>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>
>>> To me they all look the same.
>>
>> They are. What version of qemu are you using?
>
> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
> kernel.
This could be due to a kernel bug, or due to a different code path taken
in qemu because of differing features exposed to kvm.
Please try qemu-kvm.git master and report.
--
error compiling committee.c: too many arguments to function
Am 01.08.2012 11:53, schrieb Avi Kivity:
> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>> So here are 3 backtraces from booting the rescue system:
>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>
>>>> To me they all look the same.
>>>
>>> They are. What version of qemu are you using?
>>
>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>> kernel.
>
> This could be due to a kernel bug, or due to a different code path taken
> in qemu because of differing features exposed to kvm.
>
> Please try qemu-kvm.git master and report.
Can't get the latest version running. 1st it doesn't know the -id
parameter. 2nd parameter -vnc
unix:/var/run/qemu-server/103.vnc,x509,password does not work too => No
certificate path provided
Stefan
On 08/01/2012 02:29 PM, Stefan Priebe - Profihost AG wrote:
>> Please try qemu-kvm.git master and report.
>
> Can't get the latest version running. 1st it doesn't know the -id
> parameter.
I don't know it either, what is it?
> 2nd parameter -vnc
> unix:/var/run/qemu-server/103.vnc,x509,password does not work too => No
> certificate path provided
@item x509-dir=<dir>
Set the x509 file directory. Expects same filenames as -vnc
$display,x509=$dir
@item x509-key-file=<file>
@item x509-key-password=<file>
@item x509-cert-file=<file>
@item x509-cacert-file=<file>
@item x509-dh-key-file=<file>
The x509 file names can also be configured individually.
These also exist in 1.1. I wonder how it worked without the certificates.
--
error compiling committee.c: too many arguments to function
Am 01.08.2012 11:53, schrieb Avi Kivity:
> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>> So here are 3 backtraces from booting the rescue system:
>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>
>>>> To me they all look the same.
>>>
>>> They are. What version of qemu are you using?
>>
>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>> kernel.
>
> This could be due to a kernel bug, or due to a different code path taken
> in qemu because of differing features exposed to kvm.
>
> Please try qemu-kvm.git master and report.
qemu-kvm.git master just hangs after the 2nd screen with using 100% CPU
and doing nothing... so i can't test with qemu-kvm.master
Stefan
On 08/05/2012 01:08 PM, Stefan Priebe wrote:
> Am 01.08.2012 11:53, schrieb Avi Kivity:
>> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>>> So here are 3 backtraces from booting the rescue system:
>>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>>
>>>>> To me they all look the same.
>>>>
>>>> They are. What version of qemu are you using?
>>>
>>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>>> kernel.
>>
>> This could be due to a kernel bug, or due to a different code path taken
>> in qemu because of differing features exposed to kvm.
>>
>> Please try qemu-kvm.git master and report.
>
> qemu-kvm.git master just hangs after the 2nd screen with using 100% CPU
> and doing nothing... so i can't test with qemu-kvm.master
Please provide your command line and I will try to reproduce.
Which iso image are you running?
--
error compiling committee.c: too many arguments to function
Am 05.08.2012 12:29, schrieb Avi Kivity:
> On 08/05/2012 01:08 PM, Stefan Priebe wrote:
>> Am 01.08.2012 11:53, schrieb Avi Kivity:
>>> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>>>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>>>> So here are 3 backtraces from booting the rescue system:
>>>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>>>
>>>>>> To me they all look the same.
>>>>>
>>>>> They are. What version of qemu are you using?
>>>>
>>>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>>>> kernel.
>>>
>>> This could be due to a kernel bug, or due to a different code path taken
>>> in qemu because of differing features exposed to kvm.
>>>
>>> Please try qemu-kvm.git master and report.
>>
>> qemu-kvm.git master just hangs after the 2nd screen with using 100% CPU
>> and doing nothing... so i can't test with qemu-kvm.master
>
> Please provide your command line and I will try to reproduce.
ulimit -c unlimited; /usr/bin/qemu-x86_64 -chardev
socket,id=qmp,path=/var/run/qemu-server/103.qmp,server,nowait -mon
chardev=qmp,mode=control -pidfile /var/run/qemu-server/103.pid
-daemonize -usbdevice tablet -name kvmcrash -smp sockets=1,cores=8
-nodefaults -boot menu=on -vga cirrus -k de -drive
file=/dev/VGiSCSItarget0/vm-103-disk-1,if=none,id=drive-virtio0,aio=native,cache=none
-device
virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100
-drive
file=/var/lib/vz/template/iso/ubuntu-12.04-server-amd64.iso,if=none,id=drive-ide0,media=cdrom,aio=native
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=200
-m 4096 -netdev
type=tap,id=net0,ifname=tap103i0,script=/var/lib/qemu-server/pve-bridge,vhost=on
-device
virtio-net-pci,mac=BA:5B:86:AD:14:3A,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300
> Which iso image are you running?
ubuntu-12.04-server-amd64.iso
Am 05.08.2012 17:52, schrieb Stefan Priebe:
> Am 05.08.2012 12:29, schrieb Avi Kivity:
>> On 08/05/2012 01:08 PM, Stefan Priebe wrote:
>>> Am 01.08.2012 11:53, schrieb Avi Kivity:
>>>> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>>>>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>>>>> So here are 3 backtraces from booting the rescue system:
>>>>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>>>>
>>>>>>> To me they all look the same.
>>>>>>
>>>>>> They are. What version of qemu are you using?
>>>>>
>>>>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>>>>> kernel.
>>>>
>>>> This could be due to a kernel bug, or due to a different code path
>>>> taken
>>>> in qemu because of differing features exposed to kvm.
>>>>
>>>> Please try qemu-kvm.git master and report.
OK got it running it's just awfully slow and i was too impatient. It
crashes at the part as 1.1.1 stable.
Stefan
On 08/05/2012 10:00 PM, Stefan Priebe wrote:
> Am 05.08.2012 17:52, schrieb Stefan Priebe:
>> Am 05.08.2012 12:29, schrieb Avi Kivity:
>>> On 08/05/2012 01:08 PM, Stefan Priebe wrote:
>>>> Am 01.08.2012 11:53, schrieb Avi Kivity:
>>>>> On 08/01/2012 12:42 PM, Stefan Priebe - Profihost AG wrote:
>>>>>> Am 01.08.2012 11:33, schrieb Avi Kivity:
>>>>>>>> So here are 3 backtraces from booting the rescue system:
>>>>>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>>>>>
>>>>>>>> To me they all look the same.
>>>>>>>
>>>>>>> They are. What version of qemu are you using?
>>>>>>
>>>>>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>>>>>> kernel.
>>>>>
>>>>> This could be due to a kernel bug, or due to a different code path
>>>>> taken
>>>>> in qemu because of differing features exposed to kvm.
>>>>>
>>>>> Please try qemu-kvm.git master and report.
>
> OK got it running it's just awfully slow and i was too impatient. It
> crashes at the part as 1.1.1 stable.
>
Slow? what does 'info kvm' say?
I got master running and it wasn't particularly slow. I'll try 1.1.1 too.
--
error compiling committee.c: too many arguments to function
>Am 06.08.2012 10:36, schrieb Avi Kivity:
> On 08/05/2012 10:00 PM, Stefan Priebe wrote:
>>>>>>>>> So here are 3 backtraces from booting the rescue system:
>>>>>>>>> http://pastebin.com/raw.php?i=xCy2pEcP
>>>>>>>>>
>>>>>>>>> To me they all look the same.
>>>>>>>>
>>>>>>>> They are. What version of qemu are you using?
>>>>>>>
>>>>>>> latest stable-1.1 branch (1.1.1) - which works fine with latest RHEL6
>>>>>>> kernel.
>>>>>>
>>>>>> This could be due to a kernel bug, or due to a different code path
>>>>>> taken
>>>>>> in qemu because of differing features exposed to kvm.
>>>>>>
>>>>>> Please try qemu-kvm.git master and report.
>>
>> OK got it running it's just awfully slow and i was too impatient. It
>> crashes at the part as 1.1.1 stable.
>>
>
> Slow? what does 'info kvm' say?
Will recheck right now i'm running 1.1.1 again.
> I got master running and it wasn't particularly slow. I'll try 1.1.1 too.
But still i got the segfault and core dump - this is my main problem? I
mean qemu-kvm master isn't declared as stable. So i don't care about the
slowness here.
What can we do about the core dump and crash?
Stefan
On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
> But still i got the segfault and core dump - this is my main problem? I
> mean qemu-kvm master isn't declared as stable. So i don't care about the
> slowness here.
>
> What can we do about the core dump and crash?
Okay, I reproduced it; it seems aio=native is the culprit. You can try
aio=threads as a workaround.
Copying some relevant people (context: aio=native on qemu-kvm-1.1.1
segfaults pretty early during guest install)
--
error compiling committee.c: too many arguments to function
On 08/06/2012 03:12 PM, Avi Kivity wrote:
> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>
>> But still i got the segfault and core dump - this is my main problem? I
>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>> slowness here.
>>
>> What can we do about the core dump and crash?
>
> Okay, I reproduced it; it seems aio=native is the culprit. You can try
> aio=threads as a workaround.
>
> Copying some relevant people (context: aio=native on qemu-kvm-1.1.1
> segfaults pretty early during guest install)
>
The following ought to fix it:
From: Avi Kivity <[email protected]>
Date: Mon, 6 Aug 2012 15:35:02 +0300
Subject: [PATCH] virtio-mlk: fix use-after-free while handling scsi commands
The scsi passthrough handler falls through after completing a
request into the failure path, resulting in a use after free.
Reprducible by running a guest with aio=native on a block device.
Reported-by: Stefan Priebe <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index f21757e..552b3b6 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -254,6 +254,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
virtio_blk_req_complete(req, status);
g_free(req);
+ return;
#else
abort();
#endif
--
error compiling committee.c: too many arguments to function
On 08/06/2012 03:37 PM, Avi Kivity wrote:
> On 08/06/2012 03:12 PM, Avi Kivity wrote:
>> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>>
>>> But still i got the segfault and core dump - this is my main problem? I
>>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>>> slowness here.
>>>
>>> What can we do about the core dump and crash?
>>
>> Okay, I reproduced it; it seems aio=native is the culprit. You can try
>> aio=threads as a workaround.
>>
>> Copying some relevant people (context: aio=native on qemu-kvm-1.1.1
>> segfaults pretty early during guest install)
>>
>
> The following ought to fix it:
It does.
Kevin: despite aio=native, I get iothreads and pwrites, something is broken.
--
error compiling committee.c: too many arguments to function
can confirm - this fixed it!
Am 06.08.2012 14:37, schrieb Avi Kivity:
> On 08/06/2012 03:12 PM, Avi Kivity wrote:
>> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>>
>>> But still i got the segfault and core dump - this is my main problem? I
>>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>>> slowness here.
>>>
>>> What can we do about the core dump and crash?
>>
>> Okay, I reproduced it; it seems aio=native is the culprit. You can try
>> aio=threads as a workaround.
>>
>> Copying some relevant people (context: aio=native on qemu-kvm-1.1.1
>> segfaults pretty early during guest install)
>>
>
> The following ought to fix it:
>
>
> From: Avi Kivity <[email protected]>
> Date: Mon, 6 Aug 2012 15:35:02 +0300
> Subject: [PATCH] virtio-mlk: fix use-after-free while handling scsi commands
>
> The scsi passthrough handler falls through after completing a
> request into the failure path, resulting in a use after free.
>
> Reprducible by running a guest with aio=native on a block device.
>
> Reported-by: Stefan Priebe <[email protected]>
> Signed-off-by: Avi Kivity <[email protected]>
>
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index f21757e..552b3b6 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -254,6 +254,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
>
> virtio_blk_req_complete(req, status);
> g_free(req);
> + return;
> #else
> abort();
> #endif
>
>
Any news? Was this applied upstream?
Am 06.08.2012 14:37, schrieb Avi Kivity:
> On 08/06/2012 03:12 PM, Avi Kivity wrote:
>> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>>
>>> But still i got the segfault and core dump - this is my main problem? I
>>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>>> slowness here.
>>>
>>> What can we do about the core dump and crash?
>>
>> Okay, I reproduced it; it seems aio=native is the culprit. You can try
>> aio=threads as a workaround.
>>
>> Copying some relevant people (context: aio=native on qemu-kvm-1.1.1
>> segfaults pretty early during guest install)
>>
>
> The following ought to fix it:
>
>
> From: Avi Kivity <[email protected]>
> Date: Mon, 6 Aug 2012 15:35:02 +0300
> Subject: [PATCH] virtio-mlk: fix use-after-free while handling scsi commands
>
> The scsi passthrough handler falls through after completing a
> request into the failure path, resulting in a use after free.
>
> Reprducible by running a guest with aio=native on a block device.
>
> Reported-by: Stefan Priebe <[email protected]>
> Signed-off-by: Avi Kivity <[email protected]>
>
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index f21757e..552b3b6 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -254,6 +254,7 @@ static void virtio_blk_handle_scsi(VirtIOBlockReq *req)
>
> virtio_blk_req_complete(req, status);
> g_free(req);
> + return;
> #else
> abort();
> #endif
>
>
On Wed, Aug 08, 2012 at 07:51:07AM +0200, Stefan Priebe wrote:
> Any news? Was this applied upstream?
Kevin is ill. He has asked me to review and test patches in his
absence. When he gets back later this week this will get picked up (and
included in QEMU 1.2).
Here is the tree, it includes this patch:
https://github.com/stefanha/qemu/commits/for-kevin
Stefan
ah OK - thanks. Will there be a fixed 1.1.2 as well?
Stefan
Am 08.08.2012 10:06, schrieb Stefan Hajnoczi:
> On Wed, Aug 08, 2012 at 07:51:07AM +0200, Stefan Priebe wrote:
>> Any news? Was this applied upstream?
>
> Kevin is ill. He has asked me to review and test patches in his
> absence. When he gets back later this week this will get picked up (and
> included in QEMU 1.2).
>
> Here is the tree, it includes this patch:
>
> https://github.com/stefanha/qemu/commits/for-kevin
>
> Stefan
>
On Wed, Aug 8, 2012 at 9:29 AM, Stefan Priebe <[email protected]> wrote:
> ah OK - thanks. Will there be a fixed 1.1.2 as well?
mdroth: Kevin has the fix in his block branch, which means qemu.git
will get it soon. Here's the commit:
http://repo.or.cz/w/qemu/kevin.git/commit/730a9c53b4e52681fcfe31cf38854cbf91e132c7
>
> Am 08.08.2012 10:06, schrieb Stefan Hajnoczi:
>
>> On Wed, Aug 08, 2012 at 07:51:07AM +0200, Stefan Priebe wrote:
>>>
>>> Any news? Was this applied upstream?
>>
>>
>> Kevin is ill. He has asked me to review and test patches in his
>> absence. When he gets back later this week this will get picked up (and
>> included in QEMU 1.2).
>>
>> Here is the tree, it includes this patch:
>>
>> https://github.com/stefanha/qemu/commits/for-kevin
>>
>> Stefan
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html