On Tue, Sep 21, 2004 at 01:03:29PM -0400, Dan Malek wrote: > > On Sep 21, 2004, at 7:59 AM, Smith, Craig wrote: > > >Genius. That patch appears to work for me as well. > > The fact this works indicates a subtle memory management > problem elsewhere. I don't know what that is at this > point. This hack is in a piece of generic code that works > properly on all other PowerPC cores, so it isn't going to > ever appear in the public sources. > > I suggested this change to a few people hoping the information > would lead them to finding the real problem, not that it > should be perpetuated as a "fix" to make 8xx work. > I don't personally have time to work on this right now, > so anyone using 8xx should be looking for the real > cause and solution, not using this to create products.
Hi Dan, Does anyone have a clue of what is/can be wrong with the TLB entry for the address being flushed at __flush_dcache_icache()? Can we assume such TLB entry is corrupted in some way? This is v2.6.10 on m8xx - with the TLB invalidate everything works as expected. Oops: kernel access of bad area, sig: 11 [#1] NIP: C00049F8 LR: C000A3E0 SP: C48D1E10 REGS: c48d1d60 TRAP: 0300 Not tainted MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 100113A0, DSISR: C2000000 TASK = c4e1eba0[1230] 'netserver' THREAD: c48d0000 Last syscall: 20 GPR00: C4ED7D60 C48D1E10 C4E1EBA0 10011000 00000100 000954A0 10011000 C01C8090 GPR08: C02E64B8 C4ED7D60 00009032 00000000 00020591 100B46A8 00000000 100CA328 GPR16: 100CA1E8 2FEED1FF F657FFF4 00000000 00000000 00000000 C48D1E28 00000000 GPR24: C1148100 00000000 C1147EA4 C4ED7D60 100113A0 C1229418 04AA5889 C02E64A0 NIP [c00049f8] __flush_dcache_icache+0x14/0x40 LR [c000a3e0] update_mmu_cache+0x64/0x98 Call trace: [c003f3a4] do_no_page+0x2ec/0x364 [c003f588] handle_mm_fault+0xa4/0x17c [c0009968] do_page_fault+0x168/0x394 [c0002c68] handle_page_fault+0xc/0x80
