On Thu, 2010-04-08 at 12:33 -0700, bruce_leon...@selinc.com wrote: (CC'ing Paulus who wrote that code ages ago)
> > 616 DataAddressInvalid: > > 617 mfspr r3,SPRN_SRR1 > > 618 rlwinm r1,r3,9,6,6 /* Get load/store bit */ > > 619 addis r1,r1,0x2000 > > 620 mtspr SPRN_DSISR,r1 > > > > Is it trying to set DSISR_ISSTORE? > > > > #define DSISR_ISSTORE 0x02000000 /* access was a store */ > > > > Michael, > > Thanks for the reply. > > I mean line 619 above. It's setting 0x20000000 (bit 2) in the DSISR. > 0x02000000 (bit 6 or DSISR_ISSTORE) is already set because it's a DTLB > Data Store Miss Exception. But 0x20000000 is meaningless for the DSI > Exception about to be called. According to the data sheet, it's supposed > to be cleared. Someone wrote code to explicitly set a bit in the DSISR > that has no meaning in the PPC architecture. I agree that setting a bit in DSISR is very very fishy... however it works and it's not like there was going to be loads of new 603's so I assume it's no big deal. As to the meaning of the bits, see below... > So I assume it's being > overloaded for some purpose, but I can't glean that purpose from the code. > Equally perplexing to me is the following line of code from the DSI > Exception code: > > andis. r0,r10,0xa470 /* weird error? */ > > 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. > 2 - an invalid bit Not sure what 2 is about. > 5 - an invalid bit Nah, that is set on some processors such as 604 when doing a lwarx/stwcx with W=1 or such forbidden settings, though I don't remember if it was architected back then. > 9 - set if breakpoint match > 10 - invalid bit Nah, that is set when missing on segments. > 11 - set if the instruction is an ecwix or ecowx and EAR[E] = 0 > > So it's checking to see if three bits not defined by the PPC architecture > 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. I suppose we should probably also test for bit 6 (protection violation) since that will always land into do page fault. That would mean removing the code to set DIRTY in the hash code and rely on the C code to do it, and thus speeding up page faults a bit, but I don't see that as being a big deal. > Obviously overloaded bits used for some totally > undocumented purpose that I can't figure out from the code and I'm just > trying to understand what they're used for to see if it's related to my > problem. I missed the earlier discussion, what is your problem ? Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
