Gerben, as per
http://www.asus.com/Motherboards/SABERTOOTH_990FX/#support_Download_8 an
update is available for your BIOS (1604). If you update to this, does it
change anything?
If not, could you please both specify what happened, and provide the output of
the following terminal command:
sudo
The way to check upstream qemu's git HEAD is:
sudo apt-get build-dep qemu-kvm
sudo apt-get install git
git clone git://git.qemu.org/qemu.git
cd qemu
./configure --target-list=x86_64-softmmu
make
then run it as
cd x86_64-softmmu
./qemu-system-x86_64 --enable-kvm
Probably apparmor is blocking the executable.
in /var/log/apport.log I can see the line:
ERROR: apport (pid 4224) Fri Oct 26 22:29:35 2012: executable does not belong
to a package, ignoring
When copying qemu-system-x86_64 into /usr/bin
and executing within that directory ( ./qemu-system-x86_64
I hadn't noticed this before:
[ 761.143056] [ cut here ]
[ 761.143064] WARNING: at /build/buildd/linux-3.5.0/kernel/irq/manage.c:436
__enable_irq+0x3b/0xd0()
[ 761.143066] Hardware name: To be filled by O.E.M.
[ 761.143067] Unbalanced enable for IRQ 41
[ 761.143068]
Thanks, Gerben. If it were possible for you to run it by hand that
would be easier. But to do it through libvirt without a package becomes
more complicated. To undo your changes (in particular copying the qemu-
system-x86_64 into /usr/bin), please do
sudo apt-get install --reinstall qemu-kvm
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/1071011
Title:
specific device not available in client (passthrough)
Thanks for reporting this bug. Would it be possible for you to test
this with the upstream qemu?
Did this used to work consistently with older versions of qemu (say in
precise)?
Is there any pattern - for instance a full shutdown followed by power-on
of the host results in the sound card being
Hi Serge,
I cannot see any pattern on boot or reboot of the host. One cold boot
(the first after not using the pci device for a long time) of the host
resulted into the device working properly on the client, but then
shutting down the client again reverted to problem described. I should
have
