(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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
