Altivec on 2.4.xx?
Anyone out there using Altivec with a 2.4.0 kernel? Maybe this is the wrong list to ask....suggestions welcome.
There is a bug in the Instruction fault handler that interprets the Altivec enabled flag in the MSR as a write attempt to a protected instruction page. It is because we commonly use the DSISR and SRR1, and call it 'error_code' in do_page_fault. The 0x02000000 is the Altivec enabled flag in SRR1.
This should also break 2.2.xx (unless Altivec enabled is managed differently and I don't know that).
Right now, I am just removing this as part of the exception handler, so this function never finds this bit set for instruction faults. Anyone else?
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Dan Malek
Right now, I am just removing this as part of the exception handler, so this function never finds this bit set for instruction faults. Anyone else?
Well, I don't use Altivec, but the exception handlers's behaviour wrt to do_page_fault makes me feel uncomfortable too. It would be nice to have something like do_page_fault(regs, addr, code, srr1) instead of do_page_fault(regs, addr, code) without knowing if code comes from DSISR or SRR1. And simply pass code=0 if DSISR is not valid for a given exception.
If my understanding of Motorola's docs is correct, the only MPC8xx exception that has a valid DSISR setting is the implementation specific data TLB error interrupt (apart of course from Machine Check and Alignment, but those do not call do_page_fault).
As both TLB miss and TLB error handlers can jump to DataAccess, there is a risk that we call do_page_fault with a previous value of DSISR from there. So the TLB handlers should pass the code parameter to DataAccess, too.
Daniel Marmier
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Daniel Marmier
If my understanding of Motorola's docs is correct, the only MPC8xx exception that has a valid DSISR setting is the implementation specific data TLB error interrupt
This is a PowerPC architecture definition. It isn't unique to the MPC8xx, as I am obviously using a 7400 with Altivec here.
Having the common page fault handler is a good thing, we just have to make sure we extract the information properly from the appropriate register.
I thought there was more (than none :-) development happening with Altivec on PowerPC Linux. Maybe tiny test applications will work, but my MPEG-2 decoder won't.
I'm just adding one instruction to the Instruction Exception handler to mask the bit, so I will just check it in.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 2 lines · Dan Malek
This is a PowerPC architecture definition. It isn't unique to the MPC8xx, as I am obviously using a 7400 with Altivec here.
The exception I was talking about is _implementation specific_, which makes it MPC8xx unique. I do not use Altivec, but I am afraid there could be problems even without it. I could not find out whether the Data TLB Miss exception sets the DSISR, but DataStoreTLBMiss can branch to DataAccess, wich passes the DSISR to do_page_fault. Phew, hope I was clearer :-) Anyway, I will look at this exception with care before telling more.
Quoted 3 lines
Having the common page fault handler is a good thing, we just have to make sure we extract the information properly from the appropriate register.
Of course it is a good thing. I was just suggesting a way of retrieving this information properly from do_page_fault.
Quoted 3 lines
I thought there was more (than none :-) development happening with Altivec on PowerPC Linux. Maybe tiny test applications will work, but my MPEG-2 decoder won't.
Sorry, only 8xx here :-(
Daniel Marmier
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/