From eab1708c9e23f9596e5b75ebbe92f45fef5815a6 Mon Sep 17 00:00:00 2001 From: Marius Strobl Date: Thu, 17 Feb 2005 00:13:49 +0000 Subject: [PATCH] UltraSparc II[e,i] based systems come up with the tick compare register loaded, the tick interrupt enabled and a handler that resets the tick counter on every tick interrupt. While this isn't documented this can cause DELAY() to wait for a value the tick counter will not reach when used in early boot, i.e. before cpu_initclocks() is called, depending on when in the cycle DELAY() is called, the delay value and the value the tick compare register is set to. The excessive use of DELAY() in uart(4) when probing Sun keyboards seems to always manage to trigger this, resulting in a hang during boot. Disable the tick interrupt in tick_init(), which is called early in sparc64_init(), until the interrupt is enabled again in tick_start(), called by cpu_initclocks(), with our own handler. This fixes the hang during probing Sun keyboards on AXi boards and Ultra 10, with other machines like Ultra 5 probably being affected but not tested. Additional testing by: Matthias Muthmann MFC after: 1 week --- sys/sparc64/sparc64/tick.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sys/sparc64/sparc64/tick.c b/sys/sparc64/sparc64/tick.c index 6189653c129c..1ec4b78625ee 100644 --- a/sys/sparc64/sparc64/tick.c +++ b/sys/sparc64/sparc64/tick.c @@ -110,6 +110,12 @@ tick_init(u_long clock) tick_freq = clock; tick_MHz = clock / 1000000; tick_increment = clock / hz; + /* + * UltraSparc II[e,i] based systems come up with the tick interrupt + * enabled and a handler that resets the tick counter, causing DELAY() + * to not work properly when used early in boot. + */ + wr(asr23, 1L << 63, 0); } void