I use a self-compiled 2.6.33.2 (plain NO additional patches) kernel with DMA and IRQ remapping avtivated (as suggested at http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM) on top of ArchLinux. The mobo is a Gigabyte EQ45M-S2 with C2D 8400 with latest bios. If starting a windows server 2008R2 VM with RHel virtio drivers and PCI device assigned to VM (commandline: qemu -hda /dev/mapper/vg_virthostdev-srv2008R2 -boot c -net nic,model=virtio,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup -m 1024 -localtime -daemonize -vnc :1 -pcidevice host=02:00.0) The system runs smooth and stable despite the fact that the syslog shows following output every few minutes: BUG: scheduling while atomic: events/1/10/0x00000002 Modules linked in: kvm_intel kvm tun bridge stp llc ext3 jbd snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_hda_codec_realtek snd_pcm_oss snd_mixer_oss i915 drm_kms_helper thermal processor drm i2c_algo_bit button video output snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc e1000e i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support pcspkr uhci_hcd sg evdev ehci_hcd usbcore intel_agp ide_pci_generic ide_core psmouse serio_raw rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 dm_mod sr_mod sd_mod cdrom ata_generic pata_acpi ahci libata scsi_mod Pid: 10, comm: events/1 Not tainted 2.6.33.2-ARCH #1 Call Trace: [<ffffffff8133d414>] ? schedule+0x544/0xa60 [<ffffffff81070c39>] ? autoremove_wake_function+0x9/0x30 [<ffffffff81040003>] ? __wake_up+0x43/0x70 [<ffffffff8133e612>] ? __mutex_lock_slowpath+0x162/0x350 [<ffffffff8133e809>] ? mutex_lock+0x9/0x20 [<ffffffffa045cc87>] ? kvm_ioapic_set_irq+0x47/0x160 [kvm] [<ffffffffa045d914>] ? kvm_set_irq+0xf4/0x190 [kvm] [<ffffffffa045d9b0>] ? kvm_set_ioapic_irq+0x0/0x50 [kvm] [<ffffffffa045da00>] ? kvm_set_pic_irq+0x0/0x50 [kvm] [<ffffffffa045e7c0>] ? kvm_assigned_dev_interrupt_work_handler+0x0/0xc0 [kvm] [<ffffffffa045e872>] ? kvm_assigned_dev_interrupt_work_handler+0xb2/0xc0 [kvm] [<ffffffffa045e7c0>] ? kvm_assigned_dev_interrupt_work_handler+0x0/0xc0 [kvm] [<ffffffff8106bdc9>] ? worker_thread+0x189/0x2e0 [<ffffffff81070c30>] ? autoremove_wake_function+0x0/0x30 [<ffffffff8106bc40>] ? worker_thread+0x0/0x2e0 [<ffffffff810706ce>] ? kthread+0x8e/0xa0 [<ffffffff8100ae64>] ? kernel_thread_helper+0x4/0x10 [<ffffffff81070640>] ? kthread+0x0/0xa0 [<ffffffff8100ae60>] ? kernel_thread_helper+0x0/0x10 Any help is appreciated on this topic :-) Best regards Ralf
Thanks for the report. I've not seen this before, will see if I can recreate in your environment (2.6.33.2). Just to be clear, "smooth and stable" includes the assigned device working fine in the guest?
Hi Chris, yes indeed - the attached device in the windows VM is working without glitches. The device itself is an ISDN board and raises an IRQ every 125usec. I've u need any kind of additional information (e.g. the kernel config or traces) please let me know. In addition I will try some other PCI devices to check if this issue is somehow related to the specific behavior of the ISDN board... Ralf
(In reply to comment #2) > yes indeed - the attached device in the windows VM is working without > glitches. > The device itself is an ISDN board and raises an IRQ every 125usec. > > I've u need any kind of additional information (e.g. the kernel config or > traces) please let me know. In addition I will try some other PCI devices to > check if this issue is somehow related to the specific behavior of the ISDN > board... Great, thanks.
* bugzilla-daemon@bugzilla.kernel.org (bugzilla-daemon@bugzilla.kernel.org) wrote: > yes indeed - the attached device in the windows VM is working without > glitches. > The device itself is an ISDN board and raises an IRQ every 125usec. > > I've u need any kind of additional information (e.g. the kernel config or > traces) please let me know. In addition I will try some other PCI devices to > check if this issue is somehow related to the specific behavior of the ISDN > board... Great, thanks.
Hi Chris, it took some time, but now I can confirm that the same bug will occur on a win XP x86 VM with a soundcard (CreativeLabs SBlive! 5.1) attached. The sound output from the VM is fine but frequently the usual bug report is printed to the syslog. Therefore I assume that you should be able to reproduce this problem without the need for special hardware like my ISDN board:-) Best regards ralf
Should be fixed by commit 46a47b1ed118cd in 2.6.34.