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

@@ -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