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

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

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

>>> The kernel startup path has been fixed for years, and disable_IO_APIC in
>>> crash_kexec has always been a bug work-around for deficiencies in the
>>> kernel's start up path (not part of the guaranteed interface).
>>> Furthermore every real system configuration I have encountered used the
>>> same kernel version for the crashdump kernel and the production kernel.
>>> So we should be good.
>>
>> We also will be use the kdump(crashdump) kernel as the production
>> kernel. Should I only care for the current kernel?
> 
> For this particular issue yes.
> 
> In general it is important for there to be a stable interface between
> the two kernels just so you are not required to use the same kernel
> version, and so there is the possibility of using something besides a
> linux kernel.

OK. In order to judge whether a kernel version as crashdump kernel is
usable or not, I want to understand why we can remove disable_IO_APIC
in detail.

> At the same time it has always been the targets kernel's responsibility
> to sort out the hardware devices unless it can't possibily do it.  And
> apics for the longest time were very very hard to reset in the target
> kernel, but now that they are not.  It makes sense for time permitting
> to remove the now unnecessary code in the crashing kernel.  Because
> ultimately the less code we have the fewer possible ways we can fail
> in a known broken kernel.

Yes, I agree with you.

Thanks,
Yoshihiro YUNOMAE

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