I'm running a FC20 x86-64 pre-beta with an Ubuntu guest under KVM with spice and can reliably trigger an oops in the guest. The host is running qemu-kvm-1.6.1-1.fc20.x86_64 The oops happens on both Ubuntu's distro kernels (since about 3.10) and anything else recent including current drm-next (212c444ba 7th November) that I've built. The user space is Ubuntu Trusty, and X (with Unity etc) works fine. Note there is also a corrupt text console prior to the oops. To trigger: Boot guest and let it sit at lightdm ssh in send a ctrl-alt-f1 via virt-manager * see a very corrupt text console send a ctrl-alt-f2 (might oops at this point - check with dmesg via the ssh) send a ctrl-alt-f3 send a ctrl-alt-f4 I've never had it get past the 4th one without oopsing, with debug on it does it at the second switch. Here is a log which I turned some drm debug on; It is sitting at lightdm waiting for me to log in, so I ssh in and do: echo 255 > debug and do ctrl-alt-f1 [ 266.165815] [drm:drm_crtc_helper_set_config], [ 266.165817] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:33] #connectors=1 (x y) (0 0) [ 266.165821] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set [ 266.165823] [drm:qxl_best_encoder], [ 266.165823] [drm:drm_crtc_helper_set_config], encoder changed, full mode switch [ 266.165824] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch [ 266.165825] [drm:drm_crtc_helper_set_config], [CONNECTOR:4:Virtual-1] to [CRTC:3] [ 266.165826] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [ 266.165828] [drm:drm_mode_debug_printmodeline], Modeline 32:"1024x768" 60 63500 1024 1072 1176 1328 768 771 775 798 0x8 0x6 [ 266.165830] [drm:qxl_enc_mode_fixup], [ 266.165845] [drm:drm_crtc_helper_set_mode], [CRTC:3] [ 266.165846] [drm:qxl_enc_prepare], [ 266.165847] [drm:qxl_enc_dpms], [ 266.165847] [drm:qxl_enc_dpms], [ 266.165848] [drm:qxl_enc_dpms], [ 266.165849] [drm:qxl_crtc_prepare], current: 1024x768+0+0 (1). [ 266.165850] [drm:qxl_crtc_mode_set], 0x0: not a native mode [ 266.165851] [drm:qxl_crtc_mode_set], +0+0 (1024,768) => (1024,768) We have now got a heavily corrupt text console (nothing readable) I then do a ctrl-alt-f2 here. [ 276.164189] [drm:qxl_monitors_config_set], 0:1024x768+0+0 [ 276.164207] [drm:drm_crtc_helper_set_mode], [ENCODER:5:Virtual-5] set [MODE:32:1024x768] [ 276.164209] [drm:qxl_enc_mode_set], [ 276.164212] [drm:qxl_crtc_commit], [ 276.164215] [drm:qxl_write_monitors_config_for_encoder], setting head 0 to +0+0 1024x768 out of 1 [ 276.164239] ------------[ cut here ]------------ [ 276.164240] Kernel BUG at ffffffffa00c42d6 [verbose debug info unavailable] [ 276.164244] invalid opcode: 0000 [#1] SMP [ 276.164267] Modules linked in: rfcomm bnep bluetooth ppdev(F) nfsd(F) auth_rpcgss(F) nfs_acl(F) nfs(F) lockd(F) sunrpc(F) fscache(F) snd_hda_intel snd_hda_codec snd_hwdep(F) snd_pcm(F) microcode(F) psmouse(F) snd_page_alloc(F) serio_raw(F) snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F) virtio_console snd_seq(F) snd_seq_device(F) snd_timer(F) snd(F) soundcore(F) qxl parport_pc(F) ttm drm_kms_helper drm i2c_piix4 mac_hid lp(F) parport(F) floppy(F) [ 276.164271] CPU: 1 PID: 972 Comm: Xorg Tainted: GF 3.12.0-1-generic #3-Ubuntu [ 276.164273] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 276.164275] task: ffff88006d8017b0 ti: ffff88006e3fe000 task.ti: ffff88006e3fe000 [ 276.164285] RIP: 0010:[] [] qxl_send_monitors_config+0x136/0x140 [qxl] [ 276.164287] RSP: 0018:ffff88006e3ff7a8 EFLAGS: 00010246 [ 276.164288] RAX: ffffc900003b4000 RBX: ffff880036944d68 RCX: 0000000000001e60 [ 276.164290] RDX: 000000001e601e60 RSI: 000000004dc64dc4 RDI: ffff88007c35a000 [ 276.164291] RBP: ffff88006e3ff7b0 R08: 0000000000000092 R09: ffffffff81ebf069 [ 276.164293] R10: 0000000000000002 R11: 0000000000040000 R12: ffff88007c35a000 [ 276.164294] R13: ffffc9000039e004 R14: ffff880079590420 R15: ffff880036945c18 [ 276.164297] FS: 00007fb7227dc980(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000 [ 276.164299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 276.164300] CR2: 00007fb4bff2f000 CR3: 000000006d827000 CR4: 00000000000006e0 [ 276.164313] Stack: [ 276.164317] 0000000000000000 ffff88006e3ff800 ffffffffa00c45da ffff880000000000 [ 276.164320] ffff880000000400 0000000000000300 ffffffff00000001 0000000000000092 [ 276.164323] ffff880036944d68 ffff880036898000 ffff880036945c20 ffff88006e3ffa50 [ 276.164324] Call Trace: [ 276.164333] [] qxl_enc_commit+0x12a/0x220 [qxl] [ 276.164340] [] drm_crtc_helper_set_mode+0x381/0x510 [drm_kms_helper] [ 276.164349] [] drm_crtc_helper_set_config+0x9c5/0xb20 [drm_kms_helper] [ 276.164370] [] drm_mode_set_config_internal+0x5d/0xe0 [drm] [ 276.164376] [] drm_fb_helper_set_par+0x71/0xf0 [drm_kms_helper] [ 276.164382] [] fb_set_var+0x191/0x430 [ 276.164388] [] ? ttwu_do_activate.constprop.75+0x5d/0x70 [ 276.164393] [] fbcon_blank+0x1d1/0x2d0 [ 276.164399] [] do_unblank_screen+0xb4/0x1e0 [ 276.164402] [] complete_change_console+0x5a/0xe0 [ 276.164405] [] vt_ioctl+0xfaa/0x11c0 [ 276.164408] [] ? sched_clock_local+0x1d/0x80 [ 276.164411] [] ? sched_clock_cpu+0xa8/0x100 [ 276.164415] [] tty_ioctl+0x26d/0xbc0 [ 276.164420] [] ? kvm_clock_read+0x1f/0x30 [ 276.164425] [] ? sched_clock+0x9/0x10 [ 276.164427] [] ? sched_clock_local+0x1d/0x80 [ 276.164432] [] do_vfs_ioctl+0x2e5/0x4d0 [ 276.164436] [] ? vtime_account_user+0x54/0x60 [ 276.164439] [] SyS_ioctl+0x81/0xa0 [ 276.164443] [] tracesys+0xe1/0xe6 [ 276.164471] Code: d8 0c a0 31 c0 e8 3b 3f 00 00 c9 c3 45 8b 4a 14 45 8b 42 10 31 d2 41 8b 4a 0c eb a9 45 8b 42 10 41 8b 4a 0c 41 89 c1 31 d2 eb 9a <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 [ 276.164478] RIP [] qxl_send_monitors_config+0x136/0x140 [qxl] [ 276.164479] RSP [ 276.164482] ---[ end trace ca96233a7ea696e9 ]--- It's still happily responsive via the ssh at this point but the console is still toast. The addresses in the trace don't make too much sense to me; the qxl_send_monitors_config+0x136 seems to correspond to a ud2 undefined after the last jmp in qxl_send_monitors_config, and the qxl_enc_commit+0x12a I think corresponds to the jump just before the DRM_DEBUG print at the end of the routine. I have a FC19 guest also on the same host that doesn't seem to exhibit any problems. For reference this corresponds to Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1247906