Re: NSLU2 running 5.0_RC not stable

[Donald T Hayford <don%donhayford.com@localhost>]

Donald T Hayford wrote:
> Donald T Hayford wrote:
> > Luazi wrote:
> > > On Sat, Mar 7, 2009 at 7:16 PM, Donald T Hayford 
> > > <don%donhayford.com@localhost> wrote:
> > >  
> > > > When I boot a version I built in August 2008, but using the same world
> > > > (i.e., boot up a different kernel but use the same hard drive as 
> > > > root, thus
> > > > the same md5 program), I get the right answer.  Or at least the 
> > > > same answer
> > > > consistently.
> > > >     
> > >
> > > Interesting. I have just finished rebuilding my 4.99.70 tree and it 
> > > is broken.
> > >
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = a1f8849ef4548c2982b15935fbdd3f37
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = 72e0f6214aa74040d3e53f2b51b9e08f
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = bf4a4904e1b1a03e1bb21cb4be542274
> > > slug# md5 pkgsrc.tar.bz2
> > > MD5 (pkgsrc.tar.bz2) = f503e04aa9b1ded9d602f319da688e5c
> > >
> > >   
> > I don't particularly like this test, since it isn't very definitive, 
> > but unfortunately I don't have a better one.  Does anybody know if 
> > there is something in the new ATF that might help here?
> >
> > I dug back through some old kernels.  My build of 4.99.72 (about 
> > 8/20/2008) failed a test similar to that above twice in 27 attempts.
> > My build of 4.99.55 (about 5/5/2008) failed zero times out of 50.  
> > But, again, this isn't a very good test.
Apparently this problem dates back to the late May/early June 2008 
timeframe.  A kernel built using "cvs co -D 20080512-UTC src" seems to 
run correctly.  A kernel built using "cvs co -D 20080601-UTC src" does not.

Is there an easy way to find all of the files that have changed in the 
time period from 5/12/2008 to 6/1/2008.  My cvs skills are pretty woeful.

Thanks - Don