> > > > 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
