First boot has been working fine since your patch this past weekend. It's been subsequent boots that hang.
I added -no-kvm-irqchip to qemu command line and did not add the noapic boot option: it's hung at 'Starting udev' again but this time it's not consuming CPU. kernel stack traces for qemu threads: Nov 13 09:27:51 bldr-ccm89 kernel: process trace for qemu-system-x86(3907) Nov 13 09:27:51 bldr-ccm89 kernel: 00000001 00000282 c0438eb7 00000000 c07972d4 c0439187 00000001 0817a000 Nov 13 09:27:51 bldr-ccm89 kernel: f7aed200 000007c4 0817a7c4 0a9a7fd0 0817a7c4 0817a7c4 c0439d66 fff6c373 Nov 13 09:27:51 bldr-ccm89 kernel: ffffffff 0290e500 f7ae4058 00000001 f5274f18 c042e759 00000000 c30126e0 Nov 13 09:27:51 bldr-ccm89 kernel: Call Trace: Nov 13 09:27:51 bldr-ccm89 kernel: [<c0438eb7>] wake_futex+0x3a/0x44 Nov 13 09:27:51 bldr-ccm89 kernel: [<c0439187>] futex_wake+0xa9/0xb3 Nov 13 09:27:51 bldr-ccm89 kernel: [<c0439d66>] do_futex+0x20d/0xb15 Nov 13 09:27:51 bldr-ccm89 kernel: [<c042e759>] __dequeue_signal+0x151/0x15c Nov 13 09:27:51 bldr-ccm89 kernel: [<c0604884>] schedule_timeout+0x71/0x8c Nov 13 09:27:51 bldr-ccm89 kernel: [<c042d1ab>] process_timeout+0x0/0x5 Nov 13 09:27:51 bldr-ccm89 kernel: [<c0430747>] sys_rt_sigtimedwait+0x1e0/0x2c2 Nov 13 09:27:51 bldr-ccm89 kernel: [<c042cc0e>] getnstimeofday+0x30/0xb6 Nov 13 09:27:51 bldr-ccm89 kernel: [<c04386d6>] ktime_get_ts+0x16/0x44 Nov 13 09:27:51 bldr-ccm89 kernel: [<c04388b6>] ktime_get+0x12/0x34 Nov 13 09:27:51 bldr-ccm89 kernel: [<c04352a6>] common_timer_get+0xee/0x129 Nov 13 09:27:51 bldr-ccm89 kernel: [<c044abd9>] audit_syscall_entry+0x11c/0x14e Nov 13 09:27:51 bldr-ccm89 kernel: [<c0404eff>] syscall_call+0x7/0xb Nov 13 09:27:51 bldr-ccm89 kernel: ======================= Nov 13 09:27:55 bldr-ccm89 kernel: process trace for qemu-system-x86(3909) Nov 13 09:27:55 bldr-ccm89 kernel: f47a6ee4 00000086 c0438eb7 ec1af7ea 00000734 c0439187 00000009 f7c13000 Nov 13 09:27:55 bldr-ccm89 kernel: c066d3c0 ec1b88ca 00000734 000090e0 00000000 f7c1310c c30126e0 c0673b80 Nov 13 09:27:55 bldr-ccm89 kernel: 00000082 00000046 f7ae4058 ffffffff 00000000 00000000 7fffffff 7fffffff Nov 13 09:27:55 bldr-ccm89 kernel: Call Trace: Nov 13 09:27:55 bldr-ccm89 kernel: [<c0438eb7>] wake_futex+0x3a/0x44 Nov 13 09:27:55 bldr-ccm89 kernel: [<c0439187>] futex_wake+0xa9/0xb3 Nov 13 09:27:55 bldr-ccm89 kernel: [<c0604826>] schedule_timeout+0x13/0x8c Nov 13 09:27:55 bldr-ccm89 kernel: [<c042fa99>] dequeue_signal+0x2d/0x9c Nov 13 09:27:55 bldr-ccm89 kernel: [<c0430747>] sys_rt_sigtimedwait+0x1e0/0x2c2 Nov 13 09:27:55 bldr-ccm89 kernel: [<c04202b1>] default_wake_function+0x0/0xc Nov 13 09:27:55 bldr-ccm89 kernel: [<f8c15319>] kvm_vcpu_ioctl+0x0/0x366 [kvm] Nov 13 09:27:55 bldr-ccm89 kernel: [<c044abd9>] audit_syscall_entry+0x11c/0x14e Nov 13 09:27:55 bldr-ccm89 kernel: [<c0404eff>] syscall_call+0x7/0xb Nov 13 09:27:55 bldr-ccm89 kernel: ======================= Nov 13 09:27:59 bldr-ccm89 kernel: process trace for qemu-system-x86(3910) Nov 13 09:27:59 bldr-ccm89 kernel: f4d19ee4 00000086 c0438eb7 04c3e7a7 00000736 c0439187 0000000a f7c0a000 Nov 13 09:27:59 bldr-ccm89 kernel: f7450550 04c48a79 00000736 0000a2d2 00000002 f7c0a10c c30226e0 c0673b80 Nov 13 09:27:59 bldr-ccm89 kernel: 00000082 00000046 f7ae4058 f4d19f18 f4d19f18 c042e759 7fffffff 7fffffff Nov 13 09:27:59 bldr-ccm89 kernel: Call Trace: Nov 13 09:27:59 bldr-ccm89 kernel: [<c0438eb7>] wake_futex+0x3a/0x44 Nov 13 09:27:59 bldr-ccm89 kernel: [<c0439187>] futex_wake+0xa9/0xb3 Nov 13 09:27:59 bldr-ccm89 kernel: [<c042e759>] __dequeue_signal+0x151/0x15c Nov 13 09:27:59 bldr-ccm89 kernel: [<c0604826>] schedule_timeout+0x13/0x8c Nov 13 09:27:59 bldr-ccm89 kernel: [<c042fa99>] dequeue_signal+0x2d/0x9c Nov 13 09:27:59 bldr-ccm89 kernel: [<c0430747>] sys_rt_sigtimedwait+0x1e0/0x2c2 Nov 13 09:27:59 bldr-ccm89 kernel: [<c04202b1>] default_wake_function+0x0/0xc Nov 13 09:27:59 bldr-ccm89 kernel: [<f8c15319>] kvm_vcpu_ioctl+0x0/0x366 [kvm] Nov 13 09:27:59 bldr-ccm89 kernel: [<c044abd9>] audit_syscall_entry+0x11c/0x14e Nov 13 09:27:59 bldr-ccm89 kernel: [<c0404eff>] syscall_call+0x7/0xb Nov 13 09:27:59 bldr-ccm89 kernel: ======================= Nov 13 09:28:02 bldr-ccm89 kernel: process trace for qemu-system-x86(3911) Nov 13 09:28:02 bldr-ccm89 kernel: f4370ee4 00000086 c0438eb7 9b91a394 00000736 c0439187 00000009 f7450550 Nov 13 09:28:02 bldr-ccm89 kernel: c3107000 9b922a3f 00000736 000086ab 00000002 f745065c c30226e0 c0673b80 Nov 13 09:28:02 bldr-ccm89 kernel: 00000082 00000046 f7ae4058 ffffffff 00000000 00000000 7fffffff 7fffffff Nov 13 09:28:02 bldr-ccm89 kernel: Call Trace: Nov 13 09:28:02 bldr-ccm89 kernel: [<c0438eb7>] wake_futex+0x3a/0x44 Nov 13 09:28:02 bldr-ccm89 kernel: [<c0439187>] futex_wake+0xa9/0xb3 Nov 13 09:28:02 bldr-ccm89 kernel: [<c0604826>] schedule_timeout+0x13/0x8c Nov 13 09:28:02 bldr-ccm89 kernel: [<c042fa99>] dequeue_signal+0x2d/0x9c Nov 13 09:28:02 bldr-ccm89 kernel: [<c0430747>] sys_rt_sigtimedwait+0x1e0/0x2c2 Nov 13 09:28:02 bldr-ccm89 kernel: [<c04202b1>] default_wake_function+0x0/0xc Nov 13 09:28:02 bldr-ccm89 kernel: [<c0435bed>] sys_timer_settime+0x243/0x24f Nov 13 09:28:02 bldr-ccm89 kernel: [<f8c15319>] kvm_vcpu_ioctl+0x0/0x366 [kvm] Nov 13 09:28:02 bldr-ccm89 kernel: [<c044abd9>] audit_syscall_entry+0x11c/0x14e Nov 13 09:28:02 bldr-ccm89 kernel: [<c047f473>] vfs_ioctl+0x24a/0x25c Nov 13 09:28:02 bldr-ccm89 kernel: [<c047f4cd>] sys_ioctl+0x48/0x5f Nov 13 09:28:02 bldr-ccm89 kernel: [<c0404eff>] syscall_call+0x7/0xb Nov 13 09:28:02 bldr-ccm89 kernel: ======================= Nov 13 09:28:05 bldr-ccm89 kernel: process trace for qemu-system-x86(3913) Nov 13 09:28:05 bldr-ccm89 kernel: f5442e90 00000086 f5aaa4ac f0aa7e8f 00000715 00000019 0000000a f7c1daa0 Nov 13 09:28:05 bldr-ccm89 kernel: f7c13aa0 f0aaa96f 00000715 00002ae0 00000003 f7c1dbac c302a6e0 c042da86 Nov 13 09:28:05 bldr-ccm89 kernel: f7d20000 f5442e98 00000286 c042db97 00000000 00000286 80728887 80728887 Nov 13 09:28:05 bldr-ccm89 kernel: Call Trace: Nov 13 09:28:05 bldr-ccm89 kernel: [<c042da86>] lock_timer_base+0x15/0x2f Nov 13 09:28:05 bldr-ccm89 kernel: [<c042db97>] __mod_timer+0x99/0xa3 Nov 13 09:28:05 bldr-ccm89 kernel: [<c0604884>] schedule_timeout+0x71/0x8c Nov 13 09:28:05 bldr-ccm89 kernel: [<c042d1ab>] process_timeout+0x0/0x5 Nov 13 09:28:05 bldr-ccm89 kernel: [<c0439cf5>] do_futex+0x19c/0xb15 Nov 13 09:28:05 bldr-ccm89 kernel: [<c042e937>] send_signal+0x47/0xde Nov 13 09:28:05 bldr-ccm89 kernel: [<c042eea4>] __group_send_sig_info+0x74/0x7e Nov 13 09:28:05 bldr-ccm89 kernel: [<c04202b1>] default_wake_function+0x0/0xc Nov 13 09:28:05 bldr-ccm89 kernel: [<c043a777>] sys_futex+0x109/0x11f Nov 13 09:28:05 bldr-ccm89 kernel: [<c0404eff>] syscall_call+0x7/0xb Nov 13 09:28:05 bldr-ccm89 kernel: ======================= david Avi Kivity wrote: > david ahern wrote: >> I let the host stay up for 90 minutes before loading kvm and starting a VM. >> On the first reboot it hangs at 'Starting udev'. >> >> > > First reboot or first boot? > > I thought the problem was cold starting a VM. > >> I added 'noapic' to the kernel boot options, and it boots fine. (Turns out I >> only added that to grub.conf in images that run a particular ap for which I >> am running performance tests.) >> >> I would like to know why I need the noapic option to get around this and the >> networking problem. Are there performance hits as a side effect? >> >> > > Looks like there's a bug in the apic emulation. There probably are > performance implications. Does -no-kvm-irqchip help? > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
