Bugs item #2778112, was opened at 2009-04-22 00:05 Message generated for change (Comment added) made by bschmidt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2778112&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernhard Schmidt (bschmidt) Assigned to: Nobody/Anonymous (nobody) Summary: Guest hangs on restart with directly loaded kernel Initial Comment: I have this issue on two hosts (one AMD, one Intel) since I've started using KVM. I'm using KVM like I was using Xen before, which means I'm not running a bootloader on the disk but specify the kernelimage and kerneloptions directly on the kvm commandline like this. /usr/bin/kvm -name stefan -pidfile /var/run/kvm/stefan.pid -daemonize -m 512 -drive "file=/dev/mapper/cryptolvm-stefan,if=virtio,boot=on,cache=writeback" -net nic,model=virtio,macaddr=00:aa:00:00:02:01 -net tap,ifname=vm.stefan,script=no -monitor unix:/var/run/kvm/stefan.mon,server,nowait -kernel /root/bzImage-2.6.28.2 -append "root=/dev/vda console=ttyS0,57600n1 3" -nographic -serial telnet:127.0.0.1:3021,server,nowait The hosts are Debian Lenny. The AMD one is using the distribution 2.6.26-1 kernel and, at the moment, kvm-84 from Debian experimental. The Intel host uses vanilla 2.6.28.7 and kvm-85. The guests are mostly Debian Lenny boxes in amd64 mode. I've done the latest tests on the Intel host. When I reboot the VM (/sbin/reboot inside it) the guest hangs after * Will now restart [ 1754.900190] Restarting system. The following is spewed out on dmesg on the host [4052067.990269] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052071.309086] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052074.651953] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052077.995148] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052081.313575] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052084.655952] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052088.004836] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052091.334656] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052094.678884] kvm: 17221: cpu0 unhandled wrmsr: 0xc0010117 data 0 [4052097.995322] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.062881] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.131800] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.200903] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.269925] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.338805] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.408413] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.476851] emulation failed (pagetable) rip a109e 00 00 00 00 [4052098.545779] emulation failed (pagetable) rip a109e 00 00 00 00 [4052102.996254] __ratelimit: 1889681 callbacks suppressed etc, continously. The kvm process of this VM is using 100% CPU. When I strace the PID the following messages are repeated all over read(18, 0x7fffdbbd7a00, 128) = -1 EAGAIN (Resource temporarily unavailable) select(19, [7 11 13 14 16 18], [], [], {1, 0}) = 1 (in [7], left {0, 999998}) read(7, "\0"..., 512) = 1 read(7, 0x7fffdbbd7890, 512) = -1 EAGAIN (Resource temporarily unavailable) timer_gettime(0x4, {it_interval={0, 0}, it_value={0, 0}}) = 0 timer_settime(0x4, 0, {it_interval={0, 0}, it_value={0, 30000000}}, NULL) = 0 select(19, [7 11 13 14 16 18], [], [], {1, 0}) = 1 (in [18], left {0, 970018}) read(18, "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0"..., 128) = 128 rt_sigaction(SIGALRM, NULL, {0x409670, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7fd6d2961a80}, 8) = 0 svr02:~# ls -la /proc/17221/fd/ total 0 dr-x------ 2 root root 0 2009-04-22 00:02 . dr-xr-xr-x 7 kvm kvm 0 2009-04-21 23:31 .. lrwx------ 1 root root 64 2009-04-22 00:02 0 -> /dev/null lrwx------ 1 root root 64 2009-04-22 00:02 1 -> /dev/null lrwx------ 1 root root 64 2009-04-22 00:02 10 -> anon_inode:kvm-vm lrwx------ 1 root root 64 2009-04-22 00:02 11 -> anon_inode:[signalfd] lrwx------ 1 root root 64 2009-04-22 00:02 12 -> /dev/mapper/cryptolvm-stefan lrwx------ 1 root root 64 2009-04-22 00:02 13 -> socket:[13742471] lrwx------ 1 root root 64 2009-04-22 00:02 14 -> socket:[13742474] lrwx------ 1 root root 64 2009-04-22 00:02 15 -> anon_inode:kvm-vcpu lrwx------ 1 root root 64 2009-04-22 00:02 16 -> anon_inode:[eventfd] lrwx------ 1 root root 64 2009-04-22 00:02 17 -> anon_inode:[eventfd] lrwx------ 1 root root 64 2009-04-22 00:02 18 -> anon_inode:[signalfd] lrwx------ 1 root root 64 2009-04-22 00:02 2 -> /dev/null lr-x------ 1 root root 64 2009-04-22 00:02 3 -> pipe:[13742468] l-wx------ 1 root root 64 2009-04-22 00:02 4 -> pipe:[13742468] lrwx------ 1 root root 64 2009-04-22 00:02 5 -> /dev/kvm lrwx------ 1 root root 64 2009-04-22 00:02 6 -> /var/run/kvm/stefan.pid lr-x------ 1 root root 64 2009-04-22 00:02 7 -> pipe:[13742470] l-wx------ 1 root root 64 2009-04-22 00:02 8 -> pipe:[13742470] lrwx------ 1 root root 64 2009-04-22 00:02 9 -> /dev/net/tun I can kill the process regularly with SIGTERM. Regular shutdowns from inside the VM (/sbin/shutdown) work fine, only rebooting is giving me issues. I had a thread about this six months ago that didn't go anywhere (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/22641). Someone on IRC suggested to replace the extboot.bin with one from an older release, but that didn't help either. ---------------------------------------------------------------------- >Comment By: Bernhard Schmidt (bschmidt) Date: 2009-05-16 20:29 Message: This problem persists with the host upgraded to 2.6.30-rc5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2778112&group_id=180599 -- 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
