Pelton, Dave wrote:
The problem I had on my system was that my userspace init would crash
(SIGSEGV). The same userspace code would run fine on an older kernel
(2.6.14). Changing the init call to other things (such as /bin/sh)
would
lead to similar problems. Using a JTAG debugger, I was able to track
things into the copy_user_highpage function, and I found that this
function was calling copy_page with a source address that had incorrect
data. The source address was coming from kmap_coherent (which is only
used if cpu_has_dc_aliases is true). As far as I can tell, the job of
kmap_coherent is to map a user page into kernel virtual memory (kseg2).
Normally kseg2 is in the address range 0xC0000000-0xFFFFFFFF. However,
on the BMIPS3300 (the embedded MIPS32 core used on my SOC), there is a
range of addresses within kseg2 that are reserved
(0xFF200000-0xFFFEFFFF).
This means that the TLB entry that kmap_coherent creates will not work
if it falls within the reserved range. The virtual address space used
by kmap_coherent is controlled by FIXADDR_TOP in
include/asm-mips/fixmap.h.
To fix my issue, I changed FIXADDR_TOP to avoid the reserved address
space.
<snip>
Is your range of addresses reserved on the BMIPS3300 because it is being used as
dseg, i.e. because it is being used for debugging? If I read the documentation on
the processor I am using, the 24Kc, it has a similar issue. I don't need to be
able to use kmap_coherent because the 24K hardware takes care of data coherence
issues, i.e. cpu_has_dc_aliases is false, but I'm sort of thinking we might just
generally want to change FIXADDR_TOP to avoid address in the dseg range for all
MIPS32 processors. As we work our way through some of the cache flushing issues
related to using high memory, I'd like to be able to develop code that works on
processors for which cpu_has_dc_aliases is true. If my kmap_coherent is working I
can check things out for those processors and then simply use kmap_atomic for
processors where cpu_has_dc_aliases is false.
Any comments?
--
David VomLehn, dvomlehn@xxxxxxxxx
The opinions expressed herein are likely mine, but might not be my employer's...
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
