lkml.org 
[lkml]   [2006]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-05-05 08:57    [W:0.048 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site