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

[Alok Kataria]

On Thu, 2009-08-27 at 01:56 -0700, Stefan Bader wrote:
> Alok Kataria wrote:
> > 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
> 
> Hi Alok,
> 
> the patch is now applied with slight modifications. Just a friendly reminder, 
> that it helps to test-build proposed patches. In which case you might have 
> noticed, that you forgot Ingo's fix to your fix (include delay.h for tsc_32). 
> This would help me to ease my mind about possible other things that might be 
> forgotten. ;-)

Oops, sorry for that. 

>  I booted 32 and 64 bit kernels including that patch on a machine 
> and this came up without noticeable problems. So far so good...
> 
> I subscribed you to bug 418154, so you get notified when there is a proposed 
> kernel with that fix. If you could then verify that those kernels work for you 
> and report this back into the bug, this will help to get things from proposed 
> into updates.

Thanks a lot, I will look forward to get the kernel with the fix and
will update back on the bug. 

Alok
> 
> -Stefan
> 
> >>
> >> -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
> >>
> 
>