Re: 2.6.13-rc3-mm3

[ebiederm@xmission.com (Eric W. Biederman)]

"Martin J. Bligh" <mbligh@mbligh.org> writes:

>> From: Eric W. Biederman <ebiederm@xmission.com>
>> 
>> sync_tsc was using smp_call_function to ask the boot processor to report
>> it's tsc value.  smp_call_function performs an IPI_send_allbutself which is
>> a broadcast ipi.  There is a window during processor startup during which
>> the target cpu has started and before it has initialized it's interrupt
>> vectors so it can properly process an interrupt.  Receveing an interrupt
>> during that window will triple fault the cpu and do other nasty things.
>
> Wheeeeeeee! that does indeed seem to work. Nice job. 

Welcome.  I hadn't how many people were tracking this.

>> I believe this patch suffers from apicid versus logical cpu number
>> confusion.  I copied the basic logic from smp_send_reschedule and I can't
>> find where that translates from the logical cpuid to apicid.  So it isn't
>> quite correct yet.  It should be close enough that it shouldn't be too hard
>> to finish it up.
>> 
>> More bug fixes after I have slept but I figured I needed to get this
>> one out for review.
>
> Eric, when you have a final version, throw it over to me, and I'll give
> that one a spin-test too ...

With respect to the fix that is final.  The rest of the bug
fixes in my queue are for other problems.    

Mostly my concerns are with respect to apicid vs logical cpu
numbers that I'm not certain are handled properly in the code.
genapic_flat doesn't seem to do any translation.  And I don't
recall if boot_cpu_id is an apic_id or a logical cpu number.
On most hardware it is 0 in either case so it doesn't matter.

Eric