[PATCH] Fix CONFIG_PRINTK_TIME hangs on some systems

[PATCH] Fix CONFIG_PRINTK_TIME hangs on some systems

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

Hi all,

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

Regards,

Tony

[-- Attachment #2: patch-printk-time-hangs --]
[-- Type: text/plain, Size: 919 bytes --]

Fix CONFIG_PRINTK_TIME hangs on systems where sched_clock() does
not work before timer is initialized.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -431,11 +431,23 @@ static void zap_locks(void)
 	init_MUTEX(&console_sem);
 }
 
-#if defined(CONFIG_PRINTK_TIME)
-static int printk_time = 1;
-#else
 static int printk_time = 0;
-#endif
+
+#ifdef CONFIG_PRINTK_TIME
+
+/*
+ * Initialize printk time. Note that on some systems sched_clock()
+ * does not work until timer is initialized.
+ */
+static int __init printk_time_init(void)
+{
+	printk_time = 1;
+
+	return 0;
+}
+subsys_initcall(printk_time_init);
+
+#else
 
 static int __init printk_time_setup(char *str)
 {
@@ -447,6 +459,8 @@ static int __init printk_time_setup(char
 
 __setup("time", printk_time_setup);
 
+#endif
+
 __attribute__((weak)) unsigned long long printk_clock(void)
 {
 	return sched_clock();

RE: [PATCH] Fix CONFIG_PRINTK_TIME hangs on some systems

[Luck, Tony]

> 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


Do you still see a problem on some platform?

-Tony

Re: [PATCH] Fix CONFIG_PRINTK_TIME hangs on some systems

[Tony Lindgren]

* 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