On Thu 3 May 2007 07:03, Greg Ungerer pondered: > Robin Getz wrote: > > On Wed 2 May 2007 07:32, Greg Ungerer pondered: > >> Robin Getz wrote: > >>> I was trying to understand why we don't want to do the same checking on > >>> noMMU? > >> > >> The problem is on systems that have RAM mapped at high physical > >> addresses. TASK_SIZE may well be a numerically smaller number > >> than the address range that RAM sits in. So this test fails when > >> it shouldn't. > > > > So, then this is a problem only on one or two architectures, not all > > noMMU platforms? > > Its not an architecture problem. It can effect any board that > has RAM mapped at a large numerical addresses (larger than TASK_SIZE). > So it can effect any non-MMU platform.
Depending on how TASK_SIZE is defined - it looks like everyone else forces it to end of memory, except 68k[nommu]. asm-arm/memory.h:#define TASK_SIZE (CONFIG_DRAM_SIZE) asm-blackfin/processor.h:#define TASK_SIZE (memory_end) asm-frv/mem-layout.h:#define TASK_SIZE __UL(0xFFFFFFFFUL) asm-m68k/processor.h:#define TASK_SIZE (0xF0000000UL) asm-m68k/processor.h:#define TASK_SIZE (0x0E000000) asm-m68k/processor.h:#define TASK_SIZE (0x0E000000UL) asm-m68knommu/processor.h:#define TASK_SIZE (0xF0000000UL) I'm happy to learn we are doing something wrong, but I think that we just copied the arm/frv setup. -Robin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/