Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 707820

Summary: kvmclock: MP-BIOS bug: 8254 timer not connected to IO-APIC
Product: Red Hat Enterprise Linux 5 Reporter: Golita Yue <gyue>
Component: kvmAssignee: Gleb Natapov <gleb>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.7CC: akong, gcosta, juzhang, knoel, mkenneth, virt-maint, xwei
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 698842 Environment:
Last Closed: 2011-06-08 10:49:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 698842    
Bug Blocks: 580949    
Attachments:
Description Flags
serial-vm-log none

Description Golita Yue 2011-05-26 04:11:34 UTC 
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.
Comment 1 Gleb Natapov 2011-05-30 11:27:25 UTC 
*** Bug 706379 has been marked as a duplicate of this bug. ***
Comment 2 Glauber Costa 2011-06-01 22:49:53 UTC 
First thing to try is removing the +x2apic switch from cmdline.
Comment 3 Gleb Natapov 2011-06-02 06:20:46 UTC 
(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.
Comment 4 Gleb Natapov 2011-06-02 06:23:31 UTC 
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.
Comment 5 Golita Yue 2011-06-07 06:49:43 UTC 
(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.
Comment 6 Golita Yue 2011-06-07 06:53:35 UTC 
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 7 Gleb Natapov 2011-06-07 07:05:36 UTC 
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?
Comment 8 Golita Yue 2011-06-08 06:52:14 UTC 
(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)
Comment 9 Amos Kong 2011-06-08 10:33:11 UTC 
(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
Comment 10 Gleb Natapov 2011-06-08 10:49:00 UTC 
(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 ***
Comment 11 Golita Yue 2011-06-09 10:43:40 UTC 
(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 ***
Comment 12 Gleb Natapov 2011-06-09 10:52:03 UTC 
(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 ***