Re: Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock

[Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>]

(2013/09/03 21:44), Eric W. Biederman wrote:
> Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> writes:
> 
>> (2013/09/03 9:12), Eric W. Biederman wrote:
>>>>>> Then again looking at the output of the latest dmesg, it seems the IO APIC
>>>>>> is initialized way before the tsc is calibrated.  So I am not sure what
>>>>>> needed to get done or what interrupts are needed before the IO APIC gets
>>>>>> initialized.
>>>>>
>>>>> The practical issue is that jiffies was calibrated off of the PIT timer
>>>>> if I recall.  But that is all old news.
>>>>
>>>> Are the jiffies calibration codes calibrate_delay()?
>>>> It seems that the jiffies calibration have not used PIT in 2005
>>>> according to 8a9e1b0.
>>>
>>> Exactly.  That was the original reason why we put in the code to
>>> disable the IOAPIC and the local apic.  There might have been other
>>> reasons but that was the primary.
>>
>> Thanks, but I have still a question for jiffies calibration.
>>
>> When kernel boots, calibrate_delay_direct() will be called in
>> calibrate_delay() for calculating loops_per_jiffy.  Then,
>> calibrate_delay_direct() waits until jiffies is incremented.
>> I think this means PIT or HPET is still used for the calibration.
>> Is there something wrong with my understanding?
>> If wrong, how is jiffies incremented?
> 
> Things have definitely changed, and I believe part of what you are
> seeing is the path when things are not calibrated by an arch specific
> means.
> 
> Ulimately the issue was not that we waited (or possibly still wait) for
> a timer interrupt to calibrate the delay loop.  The problem was that we
> had initialized the interrupt controller in PIC mode (when the kernel
> did not later use the interrupt controller in PIC mode) to receive the
> interrupt.
> 
> The actual impetus for getting the last of the bugs shaken out is that
> we have subarchitectures on x86 that do no support interrupt controllers
> in PIC mode at all.

Is one of the subarchitectures Moorestown?

I found the Moorestown patch(05ddafb) which defined
pre_init_apic_IRQ0(). If this function will enable IOAPIC before using
timer(i.e. the function is called before calibrate_delay()), we will
be able to remove disable_IO_APIC. However, this function is a
Moorestown specific code, and normal PCs don't execute it.

I haven't find the generic cord which operates like pre_init_apic_IRQ0()
yet. Please tell me if you remember something.

Thanks,
Yoshihiro YUNOMAE

-- 
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@hitachi.com