Bug 15725 - BUG: scheduling while atomic: events/1/10/0x00000002
Summary: BUG: scheduling while atomic: events/1/10/0x00000002
Status: RESOLVED CODE_FIX
Alias: None
Product: Virtualization
Classification: Unclassified
Component: kvm (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Avi Kivity
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-08 14:51 UTC by Ralf
Modified: 2010-06-15 18:19 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.33.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Ralf 2010-04-08 14:51:40 UTC
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
Comment 1 Chris Wright 2010-04-08 17:04:59 UTC
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?
Comment 2 Ralf 2010-04-08 18:20:28 UTC
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
Comment 3 Chris Wright 2010-04-08 19:29:22 UTC
(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.
Comment 4 Chris Wright 2010-04-08 20:12:24 UTC
* 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.
Comment 5 Ralf 2010-04-09 23:32:43 UTC
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
Comment 6 Avi Kivity 2010-06-15 18:19:15 UTC
Should be fixed by commit 46a47b1ed118cd in 2.6.34.

Note You need to log in before you can comment on or make changes to this bug.