lkml.org 
[lkml]   [2001]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] 2.4.16 kernel/printk.c (per processorinitializationcheck)
>>>>> On Fri, 7 Dec 2001 19:09:03 -0200 (BRST), Marcelo Tosatti <marcelo@conectiva.com.br> said:

>> I'm not entirely sure whether this particular problem is
>> architecture specific. Perhaps it is and, if so, I'm certainly
>> happy to fix it in the ia64 specific code. However, are you
>> really 100% certain that on x86 there are no console drivers
>> which in some fashion depend on cpu_init() having completed
>> execution? Note that the x86 version of cpu_init() also has
>> printk()s. If you're not certain of this, the AP startup problem
>> could occur on x86, too. I haven't looked at all the other
>> platforms, but I suspect similar things will be true, there.

Marcelo> Prove, please. If you show me it can also happen on other
Marcelo> architectures, I'll be glad to apply the patch.

I'm no x86 expert, but I have the impression that
current_cpu_data.loops_per_jiffy will be invalid (probably 0) until
smp_store_cpu_info() is called in smp_callin(). If so, a console
driver using udelay() might not work properly. I suspect there are
other issues, but this is just based on looking at the x86 source code
for 5 minutes.

--david
-
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: 2005-03-22 13:13    [W:0.076 / U:0.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site