* Woodruff, Richard <r-woodru...@ti.com> [110115 15:48]: > > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Friday, January 14, 2011 6:03 PM > > > I've been seeing this on my omap4 panda. While debugging it, I left > > u-boot console only running for a few minutes to see if that stays up. > > It did.. And after doing that somehow now my panda boots all the way > > and stays up. Weird. > > That is a bit weird. U-boot doesn't do much of anything but spin waiting for > characters on serial. The watchdog normally isn't used. > > Thinking back I have experienced goofiness along these lines before. This > had to do with some bad timer initial state assumptions. The timer's count > values and states entering the kernel have caused a trip up. I had fixed > some of these years back. Its possible some could have snuck back with all > the recoding. Many times the simple have some unanticipated twist. > > The watchdog is something which the old kernel used to fall on also. There > were a couple simple trip ups: > -1- people forgot to turn clock on all together > -2- next, it was touched before clock frame work was initialized > -1+2- some code only 'wrote' to watchdog registers. When memory > attribute is device, generally the imprecise abort is ignored by the arm. > But some times weirdness slipped in around memory weak memory attribute > mishandling. > > Sounds like a fun bug/puzzle which good ole Lauterbach would help in.
This happened for a few days both with 2.6.37 and current mainline kernel. After I started debugging it went away with no changes to anything.. So can't debug any further at this point unfortunately. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
