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

[Stefan Bader]

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. ;-) 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.

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


-- 

When all other means of communication fail, try words!