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/
Dan Malek wrote:
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/
Daniel Marmier wrote:
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/
Dan Malek wrote:
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.
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.
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/