Hi Tom,
On 27-Dec-98 Thomas Riemer wrote:
>
> arch/mips/kernel/unaligned.c has a snippet of code in
> emulate_load_storen_insn:
>
>>case sw_op:
>> check_axs(pc,addr,4)
>> value=regs->regs[insn.i_format.rt];
>> __asm__ (
>
> The bug I've been tracking for several days now is a stumper.
> The line "value=regs->regs[insn.i_format.rt]" generates a call to
> do_page_fault in arch/mips/kernel/mm.c
>
> So here are some things that I've found out about this code:
> (confirmed with console prints)
> 1. regs is not null
> 2. regs->regs is not null.
> 3. insn.i_format.rt seems to be 5 every time.
> 4. I can print out regs->regs[insn.i_format.rt] = its value is "0x000d"
> 5. Yet, the very next __asm__ code never gets hit.
> 6. value is an unsigned long.
> 7. emulate_load_store_insn is called by do_ade (emulate_load_store_insn
> is an inline function - and so I'm assuming that it gets stuffed
> into the address space of do_ade (i.e. epc value will map
> to System.map function do_ade)
>
> This code isn't behaving the way that I would expect it to behave.
> And I can't come up with anything that would explain the behavior.
> This is what is causing my sii driver to crash the machine.
>
> Any ideas?
Well, relying on the ade handler is a bad idea IMHO. The ade exception
(ADdress Error) is triggered by, for example, trying to load a word (4
bytes) from a not word aligned address, i.e. the two least signifcant bits
of the address not zero. I'd consider this as a bug.
IMHO you should try to find out, *why* the ade exception is triggered.
Happy hacking.
---
Regards,
Harald
|