> On 9/6/2011 10:00 AM, Kyle McMartin wrote: >> On Tue, Sep 06, 2011 at 09:46:11AM -0400, Kyle McMartin wrote: >>>>>> I suspect bootmem changes have broken somewhere on 32-bit... try >>>>>> inserting a few printk between each of the function calls at the >>>>>> start >>>>>> of paging_init to try to narrow down exactly where it fails. >>>>> It's flush_cache_all_local() that fails. >>>> 2.6.39.4 works. >>>> >>> Well... that's weird. >>> >> 0: 43 ff ff 40 ldb 7fa0(r31),r31 >> >> Is the faulting insn, and %r31 is 00000000... so >> we're looking at 32672, which looks suspiciously like >> a negative offset from 32768. >> >> Looks like it's a null pointer dereference, there shouldn't be anything >> useful at this address, if I remember our address space map correctly. > The fault was code 7. Also, I don't think this instruction is in > flush_cache_all_local > (at least I don't see it in 64-bit kernel). So, I think the problem is > in setting up the address > space map. > > In my testing with 64-bit kernels, I have noticed that the first call to > flush_cache_range > doesn't have a range consistent with our 32-bit user address space. This is a 32 bit kernel. Eike -- 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
