On Thu, 5 Aug 2010 00:23:17 -0700 Shawn Jin <shawnx...@gmail.com> wrote:
> >> The flat tree located at 0xbe4300 as the kerne message showed. Why > >> cannot the kernel access this area? No TLB set for this area? > >> > >> <1>Unable to handle kernel paging request for data at address 0xc0be4308 > >> <1>Faulting instruction address: 0xc01fdabc > >> <4>Oops: Kernel access of bad area, sig: 11 [#1] > > > > Before the flat tree was accessed, I checked the DTLB and didn't find > > any entry related to 0xc0be4300. After the exception, I found the > > following DTLBs. > > > > 30 : 02 c0be4000 4KB ------ -> 00000000 > > 31 : 00 fa000000 8MB VI-S-M -> fa000000 > > > > The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this > > should be something like 00be4000? Note that the valid bit is clear -- it's not mapping to anything. > When the early_debug is enabled, the kernel can boot successfully. I > checked the TLB settings and found the following. > > 28 : 00 c0000000 8MB V--S-M -> 00000000 > 29 : 00 fa000000 8MB VI-S-M -> fa000000 > 30 : 00 c0800000 8MB V--S-M -> 00800000 > 31 : 14 04919000 ?KB V---WM -> 00e45000 That last entry looks weird... might want to look into that. > So the kernel can access the dtb at 0xbe4300 because of the pinned down > DTLB#30. > > I think the cause is clear now. But how to fix it? Two questions: > 1. Should this DTLB miss exception properly set a new TLB entry for > the new dtb address 0xbe4300? Not if it doesn't find an entry in the page tables. > 2. If the DTLB miss exception handler is not the right guy to load a > proper TLB entry, how can I set one entry based on the link_address > and the address of the flat dt blob? Given how early in the boot process it is, it's probably going to need to be handled specially. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev