Let's agree on one thing: This isn't my theory of what is happening. This *is* what is happening. I can single step the cpu with the BDI2000 and see the writes taking place.
So when you say hash_page simply returns, well it isn't that way in actuality. Where is it supposed to be patched? What isn't working correctly to have hash_page just return? How can I fix this? There is no message about allocating the hashtable. -Dave >David Ashley wrote: > >> I've traced the problem down to arch/ppc/mm/hashtable.S. When >> there is a page fault, the function hash_page gets called. > >In the case of a 603 core, hash_page is called for DSI (Data Access) >faults. However, if the feature indicates there is no HPTE, the >hash_page function is patched to simply return. You can't look at >the code in hashtable.S and know how it is going to work for a particular >implementation because it is patched at initialization to change >it's behavior. > >> .....This does >> some hashing and writes the hash values into a table located at >> 0xc0180000. > >When your kernel boots, does it print a message to indicate it has allocated >a hash table? > >> In arch/ppc/mm/ppc_mmu.c the function MMU_init_hw is called, but >> since the 8260 doesn't have the CPU_FTR_HPTE_TABLE feature, the >> hash table is never allocated and the hash_page_patch_* never get updated. > > >Oh, I just looked at a variety of different versions back to 2.4.11, and it >is patched just as I described above. > > > -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
