Messages in this thread | | | Subject | Re: [Bug] 2.6.18-rc6-mm2 i386 trouble finding RSDT in get_memcfg_from_srat | From | keith mannthey <> | Date | Thu, 14 Sep 2006 16:43:33 -0700 |
| |
On Thu, 2006-09-14 at 16:21 -0700, Dave Hansen wrote: > On Thu, 2006-09-14 at 19:04 -0400, Vivek Goyal wrote: > > I think I know what is going on wrong here. boot_ioremap() is assuming > > that only first 8MB of physical memory is being mapped and while > > calculating the index into page table (boot_pte_index) we will truncate > > any higher address bits. > > Vivek, are those pte pages still all contiguous? > > Yeah, that's probably it. Keith, I'm trying to think of reasons why we > need the mask here: > > #define boot_pte_index(address) \ > (((address) >> PAGE_SHIFT) & (BOOT_PTE_PTRS - 1)) > > and I can't think of any other than just masking out the top of the > virtual address. You could do this a bunch of other ways, like __pa(). > > This might just work: > > static unsigned long boot_pte_index(unsigned long vaddr) > { > return __pa(vaddr) >> PAGE_SHIFT; > } With CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 and the above __pa(vaddr) >> PAGE_SHIFT changed things worked for me but I am still confused as to why the pte we set is c1686f6c and we flush and return c13db000.
get_memcfg_from_srat: assigning address to rsdp fdfc0 RSD PTR v0 [IBM ] rsdp->rsdt_address eff9c2c0 boot_ioremap phys_addr = eff9c2c0 long = 44 __boot_ioremap phys_addr = eff9c000 pages = 1 source c13db000 setting pte c1686f6c to eff9c063 just flushed c13db000 boot_ioremap and I return c13db2c0 rsdt = c13db2c0 header is RSDT4 Begin SRAT table scan....
thanks, Keith
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |