On Tue, Oct 27, 2009 at 10:16:17AM +0100, Joakim Tjernlund wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 27/10/2009 > 01:00:53: > > > > On Mon, 2009-10-26 at 16:26 -0700, Dan Malek wrote: > > > Just be careful the get_user() doesn't regenerate the same > > > translation error you are trying to fix by being here...... > > yes, I had some problems with this initially but managed to work around > that. I noticed another problem though, I got multiple TLB errors for the > same address when I did it in C. Noticed by just printk:ing every hit for > a dcbX insn in do_page_fault. I can't explain it, but it seems like when > moving to C you have to execute a rfi insn and that might somehow restart > the dcbX insn before moving on to the page fault routine(or something > totally different)
The rfi should be to other kernel code -- there is no way that it should be restarting the dcbX (other than when trying to turn a TLB miss into a TLB error). Can you post the C version, maybe we can see what's going wrong? Is the empty TLB entry from the miss getting invalidated in the dcbX fixup case? > > It shouldn't since it will always come up with a proper DAR but > > you may want to double check before hand that your instruction > > address you are loading from is -not- your marker value for bad DAR. > > hmm, I check that the insn really is a dcbX insn, but not that the address is > != 0x00f0. Don't see how it could be as if something is wrong with > the insn address you get ITLB error instead of a DTLB error. I'm guessing he meant the data address you're loading. > Anyhow, things seems stalled as I haven't heard from Scott or Rex for a > while. If this isn't working now, I really don't know what is wrong and > need some debugging help. I'll test the latest version, but I have some scheduling latency. :-) -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
