On zo, 2007-02-18 at 18:33 +0100, Roman Zippel wrote: > That's weird. map_node() in arch/m68k/mm/motorola.c directly works with > the size value, so it can't be some pointer problem, which might have > wrapped. Could you add a print to check the m68k_memory values?
Please look below, I've added a print of m68k_memory[0].addr, m68k_memory[0].size and max_addr. I think Andreas was on track with his multiple of page size suggestion (which my size wasn't). However, if I add 1 to the size in the bootloader, it seems that max_addr wraps. On zo, 2007-02-18 at 19:25 +0100, Andreas Schwab wrote: > Kars de Jong <[EMAIL PROTECTED]> writes: > > > The bootloader says: > > > > Found 1 block of memory: > > Block 0: 0xFC000000 to 0x0xFFFFFFFE (65535K). > > Please check that the size passed in by the bootloader is a multiple of > the page size. The end address looks suspicious. Actually I did that on purpose (1 byte less) because the "real" size didn't work with older kernels, and this size worked fine. With this kernel it doesn't work either way: ABCGHIJK Linux version 2.6.20-m68k-hp300 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #8 Sun Feb 18 20:03:35 CET 2007 Detected HP9000 model 425t HP300: early console registered start of paging_init (00001000, fc252000) block 0: 0xfc000000:0x4000000 (max_addr=0x0) Unable to handle kernel access at virtual address 00400000 Oops: 00000000 Kind regards, Kars. - To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
