> Joakim Tjernlund wrote: > > > Every now and then my kernel gets stuck after printing "Calibrating delay > > loop ..." > > and I have to press the reset button to recover. > > > Someone else has experienced this on a 8260 board. This board did not have > > a RTC > > and the fix was to add a set_tb(0,0) early in > > arch/ppc/kernel/time.c/time_init > > The RTC is only used to keep track of time of day. It plays no role in > calibrating or timing anything. The time_init function makes an attempt > to synchronize the RTC second boundary with the decrementer. > > > Our board has a RTC but it gets initialized very late(after the Calibrating > > delay loop stuff). > > Then you are likely to simply see the "Warning: real time clock seems stuck!" > message early in setup.
Nope, I set the ppc_md.get_rtc_time to NULL. > > > Either one of us can't understand why this would fix the problem and since > > I can't > > repeat the problem at will I can't verify if a set_tb(0,0) will fix > > anything. > > We also do this on 4xx. > > > Can anybody explain why(or why not) a set_tb(0,0) will make a difference? > > I think the problem is the function tb_delta() returns an 'int', while > the rest of the arithmetic is unsigned. If you happen to get the tbl to > wrap before you get the first decrementer interrupt, I suspect the arithmetic > in these functions goes awry. The 'set_tb()' ensures the tbl doesn't wrap > around. OK, thanks for the explanation. I guess this could happen to anyone then(regardless if RTC is there or not)? Me thinks it's a good idea to do a set_tb(0,0) for 8xx also. > > > -- Dan > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
