Question regarding the DTLB Miss exceptions

[Bruce_Leonard at selinc.com]

> > 
> > It's checking to see if the following bits of DSISR are set:
> > 0 - set by DTLB miss if no hash table entry group is found
> 
> No. 0 means we hit a direct store segment. This is a historical feature
> of the architecture which we don't use, so should not happen.
> 

Sorry, would have helped if I had specified the processor; we're using an 
MPC8347, so it's an e300c1 core.  Also, my fat-fingering of the keyboard 
got me on this one - bit 0 on the e300 should be cleared.  I put in bit 
1's definition by mistake in my last email.

> > 2 - an invalid bit
> 
> Not sure what 2 is about.

Yeah, and that's the one I'm trying to figure out why the DTLB Miss on 
Store exception code is setting before calling the DSI exception code :).

> > are set and calling it a "weird error".  What the heck does that mean, 
a 
> > "weird error"?
> 
> Nah. It's a bad name. It means it's an error that is either something we
> don't support (like direct store) or something that doesn't need to go
> through hash_page, such as a breakpoint match.
> 

Thanks, that actually helps, knowing that what's being done is determining 
reasons to call hash_page or not.  Also knowing (which I suppose I should 
have figured out earlier) that some of the bits in DSISR are not defined 
for the e300c1 core but that the code is designed to support 
implementations that DO define those bits helps make sense of what I'm 
looking at.

> 
> I missed the earlier discussion, what is your problem ?
> 

Well, the problem I'm having is really irrelevant to the question at hand. 
 My original question to the list was "why is the DTLB Store Miss 
exception setting bit two of the DSISR (an invalid bit according to the 
architecture) before calling the DSI exception?".

Thanks for the explanations!

Bruce