On Thu, Jul 09, 2009 at 08:15:04PM -0400, John David Anglin wrote: ... > > > The DEPI instruction on a 64-bit machine sets bit 44=32+12, > > > whereas we use the value as the argument to IDTLBT, which expects bit 12 > > > to be used instead. > > > > > > Does it mean that the U-bit is never set and the > > > authorization id gets corrupted??? > > > > U-bit will get set only if _PAGE_NO_CACHE_BIT+32 is also set. ... > To me, it looks like the instruction should be a depdi. See the preceding > deposit of PAGE_USER. According to the IDTLBT description, the U bit is > bit 12 in r2, not bit 44. Yes - I see it now too. Excellent catch. But I'm still wondering what the effect of this bug will be. The first order (not setting U-bit) should only affect ZX1 (pa8800/pa8900) machines. Those have uncacheable IO space between 2GB-4GB physical address. My guess is the machines should HPMC since the CPU would attempt to access those ranges as a cacheline read/write instead of sub-cacheline transactions. It's not clear from the arch manual what happens if bit 44 is set in R2. I didn't look far enough to see where the auth ID gets corrupted. thanks, grant > > rp3440 boots with the depdi change. Building gcc... > > Dave > -- > J. David Anglin dave.anglin@xxxxxxxxxxxxxx > National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
