Fix, IO-APIC + timer doesn't work with hardy under VMware.

[Alok Kataria]

On Mon, 2009-08-24 at 07:35 -0700, Stefan Bader wrote:
> Alok Kataria wrote:
> > Hi Stefan,
> > 
> > While testing Ubuntu 8.04.3 under VMware. We have seen situations when
> > we hit this panic in the guest, during bootup. 
> > " Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using
> > the 'noapic' kernel parameter" 
> > 
> > I had fixed this problem for mainline some time back but I guess I
> > forgot to ask you guys to pick this patch.
> > The direct port of the mainline commit
> > (3da757daf86e498872855f0b5e101f763ba79499) gave a couple of trivial
> > merge conflicts for hardy. The backport (lpj_tsc.patch) of the patch
> > which applies to hardy-git is attached. 
> > 
> > Many user's might hit this when they start running 8.04.3 guests, so it
> > would be great if you could apply the fix at your earliest. Please note
> > that, with VMware hypervisor specific changes which went in the 8.04.3
> > kernel (tsc improvements) the likelihood of anybody hitting this on AMD
> > systems is slightly increased.
> > Other Newer Ubuntu releases already have the fix from mainline.
> 
> So we could say for anything more recent the loops per jiffies value for the 
> boot CPU is generally set from the TSC calculated value if that is available? 
> Or IOW, this has been well tested not to cause regressions?
> 

Yep, this has been in mainline from 2.6.26 cycle. There were couple of
oddities reported, but turned out to be platform bugs. 
For instance this was reported against qemu, but turned out to be a qemu
emulation bug.
http://bugzilla.kernel.org/show_bug.cgi?id=11904


> > While I am at it, I also noticed that for 64bit AMD systems the cpu
> > frequency can differ from tsc frequency, and their are no print messages
> > which tell the user about the TSC frequency on such systems. So I wrote
> > up a simple patch which prints this value for x86-64
> > (print_hypervisor_tsc_freq.patch). Please consider this too for hardy.
> 
> Should be ok as it only affects formatting for some info. Probably could be 
> handled with the same bug.
Okay will fold it in this patch then.
> 
> > Let me know if you have question about either patch. 
> 
> Yes, one thing. In the tsc_32 code you temporarily use lpc and then assign it 
> to lpc_tsc. However, lpc is defined as an int while calculations look like they 
> are supposed to handle long values. Is this what you intended?

You are right it should be u64. Seems my merge conflict missed it.

Attached is the updated patch.

Thanks,
Alok
> 
> 
> -Stefan
> 
> > Thanks,
> > Alok
> > 
> > 
> > P.S. : I tried to file a BUG for this issue, but I must say that I
> > haven't found the launchpad-bugzilla to be too helpful. My attempt to
> > file a bug failed with some timeout error (Error ID: OOPS-1330D61). 
> > 
> > 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418154
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpj_tsc.patch
Type: text/x-patch
Size: 6564 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20090824/e93d6627/attachment.bin>