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.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
--
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
