* Woodruff, Richard <r-woodruff2@xxxxxx> [110115 15:48]: > > > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
