On Fri, Dec 19, 2008 at 11:36:33AM -0500, Carlos O'Donell wrote: > On Fri, Dec 19, 2008 at 11:35 AM, Carlos O'Donell > <carlos@xxxxxxxxxxxxxxxx> wrote: > > On Fri, Dec 19, 2008 at 11:28 AM, Kyle McMartin <kyle@xxxxxxxxxxxxx> wrote: > >> On Fri, Dec 19, 2008 at 11:23:39AM -0500, Carlos O'Donell wrote: > >>> On Fri, Dec 19, 2008 at 11:13 AM, John David Anglin > >>> <dave@xxxxxxxxxxxxxxxxxx> wrote: > >>> >> > For future reference, in mmu_context.h. Bloody tricky mtctl() macro > >>> >> > doesn't take a prefix, just the numeric cr #. > >>> >> > >>> >> Evil. > >>> > > >>> > If this is a problem with the WD bit, the problem is likely here: > >>> > > >>> > mtctl(context >> (SPACEID_SHIFT - 1),8); > >>> > > >>> > It's possible this might set the WD bit depending on the alignment > >>> > of context and the value of SPACEID_SHIFT on your machine. If you > >>> > can duplicate, maybe add a BUG_ON. On hppa64, all structs are passed > >>> > by value, so the alignment of context may only be BIGGEST_ALIGNMENT. > >>> > >>> The value of context is a space id (the value returned by alloc_sid()) > >>> and is not related to any alignment? > >> > >> It's a typedef to an unsigned long. I'm not sure we've seen this on a > >> 64-bit kernel (which is the SPACEID_SHIFT one.) > >> > >> On a 32-bit kernel (where I've been able to reproduce this) we do a > >> leftshift by one, so the WD bit is guaranteed to be 0. > > > > John has a good point though, we might as well assert that? > > In alloc_sid() when we allocate the space id? > Meh. > >>> > mtctl(context >> (SPACEID_SHIFT - 1),8); SPACEID_SHIFT is the number of spaceid bits, which is 32 on 64-bit. I suspect what this is trying to do, is put it in the rightmost half of the register, so as long as context is shifted left already, (which it is.) When you cancel out the SPACEID_SHIFT in alloc_sid, and here in load_context, you end up with the same mtctl(context << 1, 8) as on 32-bit. re, Kyle -- 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
