Raymond Burns wrote:
> Hi
> 
> Working with a June 29th pull of davem's tree I found a sequence of
> events which poses a problem causing BUG and then Oops.
> 
> This impacts platforms with the mostek clock 
> 
> kernel/main.c calls out time_init() which ultimatly leads to a call
> of clock_init() which calls of_register_driver() for the mostek clock.
> 
> This occurs prior to the kobject, klist and friends being initialized
> which occurs as postcore_initcall(of_bus_driver_init), This leads to
> the BUGs and oops.
> 
> The clock initialization is needed prior to local_irq_enable
> 
> I have not found reasons for the postcore_initcall calls timing but
> assume they're concrete for other platforms.
> 
> I have not found a work around.

I'm seeing the same thing.

Based on sparc64, it should be possible to defer the initialization of
the mostek clock until later.

The attached patch gets me past the clock driver, but it ends up with a
watchdog reset after switching to malloc:

  io scheduler cfq registered (default)
  ioremap: done with statics, switching to malloc

  Watchdog Reset
  Type  help  for more information
  <#0> ok

Bob