On Wednesday 21 April 2010 05:49:11 Bonenkamp, Ralf wrote: > Hi Marcelo, > > Thanks for the patch. > I put it into my kernel source tree and tested the freshly build kernel in > my testing environment. The problem is now - almost - gone. The only > suspicious message (ONE occurrence immediate after starting the Server > 2008 R2 VM) in syslog is now: > > BUG: scheduling while atomic: qemu/3674/0x00000002 > Modules linked in: tun bridge stp llc ext3 jbd uhci_hcd > snd_hda_codec_realtek snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc i915 > drm_kms_helper drm i2c_algo_bit video output i2c_i801 i2c_core > ide_pci_generic ide_core button intel_agp ehci_hcd thermal e1000e iTCO_wdt > iTCO_vendor_support processor usbcore kvm_intel evdev sg psmouse pcspkr > serio_raw kvm rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 dm_mod > sr_mod cdrom sd_mod ata_generic pata_acpi ahci libata scsi_mod Pid: 3674, > comm: qemu Not tainted 2.6.33.2-KVM_patch #4 > Call Trace: > [<ffffffff8133d414>] ? schedule+0x544/0xa60 > [<ffffffffa01839ad>] ? mmu_zap_unsync_children+0x17d/0x200 [kvm] > [<ffffffff8133e612>] ? __mutex_lock_slowpath+0x162/0x350 > [<ffffffff8133e809>] ? mutex_lock+0x9/0x20 > [<ffffffffa016cc87>] ? kvm_ioapic_set_irq+0x47/0x160 [kvm] > [<ffffffffa016d914>] ? kvm_set_irq+0xf4/0x190 [kvm] > [<ffffffffa016d9b0>] ? kvm_set_ioapic_irq+0x0/0x50 [kvm] > [<ffffffffa016da00>] ? kvm_set_pic_irq+0x0/0x50 [kvm] > [<ffffffffa018587f>] ? paging64_walk_addr+0x25f/0x750 [kvm] > [<ffffffff8133e70d>] ? __mutex_lock_slowpath+0x25d/0x350 > [<ffffffffa016e905>] ? kvm_assigned_dev_ack_irq+0x35/0x90 [kvm] > [<ffffffffa016d771>] ? kvm_notify_acked_irq+0x71/0x120 [kvm] Seems this time is kvm_notify_acked_irq() with RCU. -- regards Yang, Sheng > [<ffffffffa016ce13>] ? kvm_ioapic_update_eoi+0x73/0xd0 [kvm] > [<ffffffffa0192689>] ? apic_reg_write+0x569/0x700 [kvm] > [<ffffffffa0192939>] ? apic_mmio_write+0x69/0x70 [kvm] > [<ffffffffa0178fec>] ? emulator_write_emulated_onepage+0xac/0x1b0 [kvm] > [<ffffffffa018d9c5>] ? x86_emulate_insn+0x1d25/0x4d20 [kvm] > [<ffffffffa018b98e>] ? x86_decode_insn+0x96e/0xba0 [kvm] > [<ffffffffa018442c>] ? kvm_mmu_unprotect_page_virt+0xec/0x100 [kvm] > [<ffffffffa0178c13>] ? emulate_instruction+0xd3/0x380 [kvm] > [<ffffffff8133fe3e>] ? __down_read+0xce/0xd0 > [<ffffffffa0191c69>] ? apic_update_ppr+0x29/0x70 [kvm] > [<ffffffffa01fcc08>] ? handle_apic_access+0x18/0x40 [kvm_intel] > [<ffffffffa017ba7d>] ? kvm_arch_vcpu_ioctl_run+0x3ad/0xcf0 [kvm] > [<ffffffff81081af7>] ? wake_futex+0x37/0x70 > [<ffffffffa0168d5c>] ? kvm_vcpu_ioctl+0x53c/0x910 [kvm] > [<ffffffff81013ab3>] ? __switch_to_xtra+0x163/0x1a0 > [<ffffffff810088b1>] ? __switch_to+0x271/0x340 > [<ffffffff81121405>] ? vfs_ioctl+0x35/0xd0 > [<ffffffff811215c8>] ? do_vfs_ioctl+0x88/0x570 > [<ffffffff8133d1c9>] ? schedule+0x2f9/0xa60 > [<ffffffff81121b30>] ? sys_ioctl+0x80/0xa0 > [<ffffffff810cf4ea>] ? fire_user_return_notifiers+0x3a/0x70 > [<ffffffff8100a042>] ? system_call_fastpath+0x16/0x1b > kvm: emulating exchange as write > > Honestly my knowledge of the kvm internals is not sufficient to decide if > this bug report still belongs to my problem or is something different. So > if you need more information or additional testing please let me know.. > > Best regards > Ralf Bonenkamp > > -----Ursprüngliche Nachricht----- > Von: Marcelo Tosatti [mailto:mtosatti@xxxxxxxxxx] > Gesendet: Dienstag, 20. April 2010 17:54 > An: kvm > Cc: Ralf Bonenkamp; Chris Wright; Yang, Sheng > Betreff: *** GMX Spamverdacht *** [UNTESTED] KVM: do not call kvm_set_irq > from irq disabled section > > > The assigned device interrupt work handler calls kvm_set_irq, which > can sleep, for example, waiting for the ioapic mutex, from irq disabled > section. > > https://bugzilla.kernel.org/show_bug.cgi?id=15725 > > Fix by dropping assigned_dev_lock (and re-enabling interrupts) > before invoking kvm_set_irq for the KVM_DEV_IRQ_HOST_MSIX case. Other > cases do not require the lock or interrupts disabled (a new work > instance will be queued in case of concurrent interrupt). > > KVM-Stable-Tag. > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
