Re: system gets stuck in a lock during boot

[Justin P. Mattock]

Ingo Molnar wrote:
> * Justin P. Mattock<justinmattock@xxxxxxxxx>  wrote:
>
>    
> > Ingo Molnar wrote:
> >      
> > > * Justin Mattock<justinmattock@xxxxxxxxx>   wrote:
> > >
> > >
> > >        
> > > > O.K. I feel better, deleted
> > > > my system, and threw in a minimal built system
> > > > with only the bare essentials to boot.
> > > > (just to make sure things are correct).
> > > >
> > > > unfortunately after building rc6 I'm still hitting
> > > > this. really am not sure why this is happening.
> > > >
> > > >          
> > > Could you please double-check the bisection result by doing this:
> > >
> > >    git revert af6af30c0f
> > >
> > > on the latest kernel and seeing whether that fixes the lockup?
> > >
> > > Bisections are very efficient and hence very sensitive as well to
> > > minimal errors. Just one small mistake near the end of a bisection
> > > can blame the wrong commit.
> > >
> > > So the best way to double-check such 100%-triggerable crashes is to
> > > do the revert. I tried the revert and it can be done fine here.
> > >
> > > [ _If_ that does not fix the bug then to save time you can
> > >      'backtrack' the bisection, instead of re-doing it completely.
> > >      I.e. you have your bisection log, re-check the final steps going
> > >      backwards. Once you find a discrepancy (i.e. a 'bad' point that
> > >      is 'good' or the other way around), redo the bisection log
> > >      commands up to that point and continue it up to the end. ]
> > >
> > > 	Ingo
> > >
> > >
> > >        
> > shoot, I did not see your post here. when looking at my bisect
> > log, I guess after a git bisect reset it clears?
> >
> > Anyways after git bisect had finished I looked manually at the
> > commits that it had generated the one which I had sent in a post
> > previously, and this one:
> >
> >   9424edc2da097c8589fcc24a72552d33e54be161
> >      
>
> (this commit has no effect on your kernel image, at all.)
>
>    
yep. but it was worth a try.
> > at the time looking at the commit, I see this to be more of the
> > cause because of it being related to elf as so forth, but as soon
> > as I reverted this on rc6 made no difference.(the previous commit
> > fixes this for me, on a regular tar.ball as well as in git.
> >
> > I think at this point since this system is a fresh from scratch
> > build, I think something might be wrong that I'm doing (all the
> > CFLAGS, and such are in a previous post).
> >
> > At the moment I don't have a problem applying a patch to the
> > kernel for this. especially since I'm the only one that seems to
> > be hitting this, then if more and more reports of this happen then
> > we can go from there.
> >      
>
> What would be nice is to verify your bisection end result, i.e. do
> what i suggested:
>
>    
yeah I've done this on both kernels three to be exact, and all boot 
after reverting
Fix perf-tracepoint OOPS.

As for my system, I'm still convinced that I might be doing something 
wrong over here.

> > > Could you please double-check the bisection result by doing this:
> > >
> > >    git revert af6af30c0f
> > >
> > > on the latest kernel and seeing whether that fixes the lockup?
> > >        
>
> if this doesnt fix it on latest -git then this commit is not the
> cause of the lockup.
>
> 	Ingo
>
>    
This commit(Fix perf-tracepoint OOPS.)does fix my stuckage, but I'm 
left, as well as others asking
the question of why.
In any case I still think I'm setting something wrong with either gcc, 
or something
that might be causing this from userland.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/