Hide Forgot
Created attachment 500977 [details] serial-vm-log +++ This bug was initially created as a clone of Bug #698842 +++ Description of problem: Boot up a rhel5.6 guest, using kvmclock, guest always panic. ACPI: Core revision 20060707 ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter 1. ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,115200 divider=10 panic 2. ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,115200 successfully 3. ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,115200 divider=10 noapic successfully Version-Release number of selected component (if applicable): guest kernel: kernel-2.6.18-238.9.1.el5 host kernel: 2.6.18-262.el5 kvm-83-232.el5 How reproducible: always Steps to Reproduce: 1. Boot up a rhel5.6 guest, using kvmclock. guest kernel parameters(divider=10) # qemu-kvm -cpu cpu64-rhel6,+sse2,+x2apic -rtc base=utc,clock=host,driftfix=slew ... Actual results: guest panic Expected results: guest can boot up successfully Additional info: # qemu-kvm -name vm1 -chardev socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20110420-105736-3Eig,server,nowait -mon chardev=qmp_monitor_id_qmpmonitor1,mode=control -chardev socket,id=serial_id_20110420-105736-3Eig,path=/tmp/serial-20110420-105736-3Eig,server,nowait -device isa-serial,chardev=serial_id_20110420-105736-3Eig -drive file=/home/devel/autotest-devel/client/tests/kvm/images/RHEL-Server-5.6-64-virtio.qcow2,index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=idS1QAcm,mac=9a:8a:ec:e1:df:1a,id=ndev00idS1QAcm,bus=pci.0,addr=0x3 -netdev tap,id=idS1QAcm,vhost=on,ifname=t0-105736-3Eig,script=/home/devel/autotest-devel/client/tests/kvm/scripts/qemu-ifup-switch,downscript=no -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc :1 -rtc base=utc,clock=host,driftfix=slew -M rhel6.1.0 -boot order=cdn,once=c,menu=off -usbdevice tablet -no-kvm-pit-reinjection -enable-kvm Additional info: cmdline in rhel5.7 host: qemu-kvm -drive file='RHEL-Server-5.6-32.qcow2',index=0,if=ide,media=disk,cache=none,format=qcow2 -net nic,vlan=0,model=rtl8139,macaddr='9a:9c:88:38:6d:60' -net tap,vlan=0,ifname='t0-114207-ba0y',script='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 4096 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -soundhw ac97 -vnc :0 -rtc-td-hack -M rhel5.6.0 -boot c -usbdevice tablet -no-kvm-pit-reinjection I hit this bug in AMD host. Attached the serial log.
*** Bug 706379 has been marked as a duplicate of this bug. ***
First thing to try is removing the +x2apic switch from cmdline.
(In reply to comment #2) > First thing to try is removing the +x2apic switch from cmdline. rhel5 does not support x2apic. Removing +x2apic from cmd will change nothing.
So if I understand you correctly if you add "divider=10" to kernel cmd it panics. If this the case then do not do that and close the bug.
(In reply to comment #4) > So if I understand you correctly if you add "divider=10" to kernel cmd it > panics. If this the case then do not do that and close the bug. no "divider=10" Please refer to serial-vm-log(in attachment): Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0,115200 console=tty0 This bug was cloned from 6.1 bug, so the description is copy from source bug. please ignore the unsuitable 6.1 parameter. sorry for inconvenience.
The following is bug related information: version: guest kernel: kernel-2.6.18-238.9.1.el5 host kernel: 2.6.18-262.el5 kvm-83-232.el5 cmd in rhel5.7 host: qemu-kvm -drive file='RHEL-Server-5.6-32.qcow2',index=0,if=ide,media=disk,cache=none,format=qcow2 -net nic,vlan=0,model=rtl8139,macaddr='9a:9c:88:38:6d:60' -net tap,vlan=0,ifname='t0-114207-ba0y',script='/usr/local/staf/test/RHEV/kvm-new/autotest/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 4096 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -soundhw ac97 -vnc :0 -rtc-td-hack -M rhel5.6.0 -boot c -usbdevice tablet -no-kvm-pit-reinjection guest kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0,115200 console=tty0
Comment #0 says that it fails always. So are you saying rhel5.7 guest does not work at all on rhel6 and rhel5 host? Or is it fails sometimes?
(In reply to comment #7) > Comment #0 says that it fails always. So are you saying rhel5.7 guest does not > work at all on rhel6 and rhel5 host? Or is it fails sometimes? This bug happened in following condition: Host: RHEL5.7 Guest: RHEL5.6 How reproducible: rarely (hit this bug in reboot testing -- reboot 25 times)
(In reply to comment #4) > So if I understand you correctly if you add "divider=10" to kernel cmd it > panics. If this the case then do not do that and close the bug. Why we could not set HZ rate by 'divider=10' when using kvmclock? could you tell me some detail? Thanks
(In reply to comment #9) > (In reply to comment #4) > > So if I understand you correctly if you add "divider=10" to kernel cmd it > > panics. If this the case then do not do that and close the bug. > > Why we could not set HZ rate by 'divider=10' when using kvmclock? could you > tell me some detail? Thanks The bug is absolutely incoherent. It has nothing to do neither with kvmclock nor with 'divider=10' kernel parameter like comment #0 says. It is a pity that I should ask number of followup questions to get absolutely different description of the bug that was provided in initial comment. So after comment #8 there is absolutely different picture of the bug. It fails with 'divider=10' and it fails rarely and in fact it is a well know bug that will not be fixed in rhel5. Next time please make sure comment #0 describes the bug accurately. *** This bug has been marked as a duplicate of bug 481013 ***
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #4) > > > So if I understand you correctly if you add "divider=10" to kernel cmd it > > > panics. If this the case then do not do that and close the bug. > > > > Why we could not set HZ rate by 'divider=10' when using kvmclock? could you > > tell me some detail? Thanks > > The bug is absolutely incoherent. It has nothing to do neither with kvmclock > nor with 'divider=10' kernel parameter like comment #0 says. It is a pity that > I should ask number of followup questions to get absolutely different > description of the bug that was provided in initial comment. So after comment > #8 there is absolutely different picture of the bug. It fails with 'divider=10' It fails without 'divider=10', pls refer to comment #5 > and it fails rarely and in fact it is a well know bug that will not be fixed in > rhel5. Next time please make sure comment #0 describes the bug accurately. > > *** This bug has been marked as a duplicate of bug 481013 ***
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #4) > > > > So if I understand you correctly if you add "divider=10" to kernel cmd it > > > > panics. If this the case then do not do that and close the bug. > > > > > > Why we could not set HZ rate by 'divider=10' when using kvmclock? could you > > > tell me some detail? Thanks > > > > The bug is absolutely incoherent. It has nothing to do neither with kvmclock > > nor with 'divider=10' kernel parameter like comment #0 says. It is a pity that > > I should ask number of followup questions to get absolutely different > > description of the bug that was provided in initial comment. So after comment > > #8 there is absolutely different picture of the bug. It fails with 'divider=10' > > It fails without 'divider=10', pls refer to comment #5 Yes, this is the typo in my comment. Unlike comment #0 says it fails _without_ 'divider=10' and it fails rarely (again unlike what comment #0 says). In short the comment #0 is completely incorrect and misleading. > > > and it fails rarely and in fact it is a well know bug that will not be fixed in > > rhel5. Next time please make sure comment #0 describes the bug accurately. > > > > *** This bug has been marked as a duplicate of bug 481013 ***