On Sat, Jun 23, 2012 at 7:08 AM, Emmanuel Noobadmin
wrote:
> On 6/22/12, Stefan Hajnoczi wrote:
>> Thanks for investigating and sharing the information you've found.
>> It's archived on the list so anyone who hits it in the future or wants
>> to reproduce it can try.
>
> I decided to give it one
On 6/22/12, Stefan Hajnoczi wrote:
> Thanks for investigating and sharing the information you've found.
> It's archived on the list so anyone who hits it in the future or wants
> to reproduce it can try.
I decided to give it one more try before I formatted that machine and
tried the rpm method. T
On Thu, Jun 21, 2012 at 2:49 PM, Emmanuel Noobadmin
wrote:
> On 6/20/12, Stefan Hajnoczi wrote:
>> Anyway, once you've tried qemu.git/master we'll know whether the bug
>> still exists and with all the info you've shared maybe Gerd (USB
>> maintainer) will know what the issue is.
>
> Sadly, my noo
On 6/20/12, Stefan Hajnoczi wrote:
> Anyway, once you've tried qemu.git/master we'll know whether the bug
> still exists and with all the info you've shared maybe Gerd (USB
> maintainer) will know what the issue is.
Sadly, my noobness meant during the hours I had onsite, I could only
get libvirt
On Wed, Jun 20, 2012 at 10:40 AM, Emmanuel Noobadmin
wrote:
> On 6/18/12, Stefan Hajnoczi wrote:
>> I believe the call is coming from hw/usb/host-linux.c:async_complete()
>> but am not using the same source tree as your qemu-kvm so I could be
>> off. The code suggests that QEMU also logs an erro
On 6/18/12, Stefan Hajnoczi wrote:
> I believe the call is coming from hw/usb/host-linux.c:async_complete()
> but am not using the same source tree as your qemu-kvm so I could be
> off. The code suggests that QEMU also logs an error message
> ("USBDEVFS_REAPURBNDELAY: Inappropriate ioctl for devi
On 6/18/12, Stefan Hajnoczi wrote:
> off. The code suggests that QEMU also logs an error message
> ("USBDEVFS_REAPURBNDELAY: Inappropriate ioctl for device") when this
> happens. If you want, check the libvirt log file for this guest - it
> probably has tons of these messages in it.
I'll check
On Sat, Jun 16, 2012 at 6:16 AM, Emmanuel Noobadmin
wrote:
> On 6/13/12, Stefan Hajnoczi wrote:
>>Since system time is a large chunk you could use strace -f -p $(pgrep
>>qemu-kvm) or other system call tracing tools to see what the qemu-kvm
>>process is doing.
>
> The command you gave didn't work
> Date: Sat, 16 Jun 2012 13:19:53 +0800
> Subject: Re: Bug? 100% load on core after physically removing USB storage
> from host
> From: centos.ad...@gmail.com
> To: verucasal...@hotmail.co.uk
> CC: stefa...@gmail.com; kvm@vg
On 6/14/12, Veruca Salt wrote:
>> >>> qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
>
> We had the same problem with 0.13
> We were using it on Sandy Bridge motherboards when it happened. It was an
> issue then, but we hanged to 1.0 a long time ago.
> Why are you using 0.12 years after it was replaced?
On 6/13/12, Stefan Hajnoczi wrote:
>Since system time is a large chunk you could use strace -f -p $(pgrep
>qemu-kvm) or other system call tracing tools to see what the qemu-kvm
>process is doing.
The command you gave didn't work so I replace $(pgrep) with PID of the
process running the VM after c
> >>> qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
We had the same problem with 0.13
We were using it on Sandy Bridge motherboards when it happened. It was an issue
then, but we hanged to 1.0 a long time ago.
Why are you using 0.12 years after it was replaced?
> More majordomo info at http://vger.k
On Wed, Jun 13, 2012 at 8:23 AM, Emmanuel Noobadmin
wrote:
> On 6/12/12, Stefan Hajnoczi wrote:
>
> Further tests done on the following set only
>>> qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
>>> on SLES 6, 2.6.32-220.7.1.el.x86_64 (Intel 82801JI ICH10)
>
>>> 1. VMM add physical host usb device -> s
On 6/12/12, Stefan Hajnoczi wrote:
Further tests done on the following set only
>> qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
>> on SLES 6, 2.6.32-220.7.1.el.x86_64 (Intel 82801JI ICH10)
>> 1. VMM add physical host usb device -> select storage to guest
>> 2. VMM remove hardware
>> 3. Physically rem
On 6/12/12, Stefan Hajnoczi wrote:
>> After some testing, the only steps needed are
>> 1. VMM add physical host usb device -> select storage to guest
>> 2. VMM remove hardware
>> 3. Physically remove the USB storage from the host, thread/core
>> assigned to guest goes 100%
>
> Two clarifications:
On Tue, Jun 12, 2012 at 6:02 AM, Emmanuel Noobadmin
wrote:
> After removing a USB flash drive using virtual machine manager, I
> notice that the core assigned to the VM guest goes up to 100% load.
> Within the guest itself, there is no significant activity.
>
> This also prompted me to look at the
16 matches
Mail list logo
