[Top] [All Lists]

RE: arch/mips/kernel/unaligned.c

Subject: RE: arch/mips/kernel/unaligned.c
From: Harald Koerfgen <>
Date: Mon, 28 Dec 1998 17:06:59 +0100 (MET)
In-reply-to: <>
Organization: none
Reply-to: "Harald Koerfgen" <>
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 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.

<Prev in Thread] Current Thread [Next in Thread>