[OLPC-devel] Re: Problem after installing to NAND

Tom Sylla tsylla at gmail.com
Sun Aug 27 20:53:48 EDT 2006


Ronald G Minnich wrote:
> Jordan Crouse wrote:
> 
>> Its been established that he wasn't as thorough as he should have 
>> been. We're not 100% sure that we can boot reliably from a warm boot. 
>> Personally,
>> I've been about 95% successful - with the other 5% being infrequent as to
>> not be able to determine a pattern.
> 
> True, I guess.
> 
> Well, what I'd like to do: (I did this years ago for another purpose)
> 
> I will run a program that on my linuxbios box searches the 2^32 MSRs and 
> prints the good ones. Then we do the same on insyde. This usually runs 
> overnight. Then we can start hunting down the diffs.

This is a noble goal, but really not worth it. You will find a huge 
amount of registers that are different, but don't matter. You will waste 
lots of time going down ratholes of registers like that.

The PRS exists, it has been worked on, and it contains the registers 
that matter. Use that if you want to compare register settings. If you 
don't trust the PRS, look at the specs, and make sure that everything 
you think is relevant is included. Has anyone even re-run the PRS check 
since Steve? Jim, Mitch: someone should do that at regular intervals, 
certainly at every LB version. The point of the PRS is that you put a 
lot of work into it up-front, and then it goes into maintenance mode. 
The utility of it relies on it being run after everything new code 
change that might affect the registers it is checking. The PRS was 
designed to combat the "lets check every register" plans that end up 
taking a long time, and not always getting to the answer.



The above is sort of tangential to the "jumping to..." issue. The better 
path to debug that issue is to *make it fail*. Then, hook up an FS2 and 
debug it. Jordan, Mitch, Samat, and Jim have experienced this. Set up 
your machines to continuously reboot overnight. They will fail at some 
point if it is truly reproducable. Debug it at that point. Monstrously 
powerful tools are available to debug this. "Theorizing" about possible 
failure points is a waste of time if you have tools that can be used to 
debug it.

If someone gets this to fail, and can plug in an FS2, I will be happy to 
show you how to drive it over VNC or otherwise.

Tom





More information about the Devel mailing list