Messages in this thread | | | Date | Thu, 4 May 2006 23:54:58 -0700 | From | Tony Lindgren <> | Subject | Re: [PATCH] Fix CONFIG_PRINTK_TIME hangs on some systems |
| |
* Luck, Tony <tony.luck@intel.com> [060504 09:14]: > > This issue has been discussed earlier on LKML, but AFAIK > > there has not been any better solution available: > > > > http://lkml.org/lkml/2005/8/18/173 > > I thought that this had been fixed: > > ia64 now has a "printk_clock()" defined in arch/ia64/kernel/time.c > which overrides the "weak" symbol defined in kernel/printk.c. This > calls ia64_printk_clock() ... which defaults to a jiffie based > routine, but might be an ITC based routine if running on a system > where the clocks do not drift on different cpus. Platform code > can also override this function pointer (which SGI does in their > sn_setup() routine). > > The ITC based routine still uses sched_clock(), but tries to avoid > the original problems by not calling sched_clock() until the MMU > has been set up to map the per-cpu areas (checks whether one of the > AR.K registers has been set). Most of this in commit: > > http://tinyurl.com/ltexa
Thanks, I had missed that patch.
I still think the current printk_clock() approach is broken by default on an unknown number of platforms.
Probably the best way to fix it would be to make it use jiffies unless the platform registers a proper printk_clock() function.
> Do you still see a problem on some platform?
Yes, on various OMAP boards when 32KHz timer is being used. The 32KHz timer is not enabled until in timer_init().
Regards,
Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |