linux-mips
[Top] [All Lists]

Re: unaligned load in branch delay slot

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: unaligned load in branch delay slot
From: Brad Parker <brad@parker.boston.ma.us>
Date: Tue, 28 Jan 2003 20:39:03 -0500
Cc: Ralf Baechle <ralf@linux-mips.org>, Mike Uhler <uhler@mips.com>, Linux/MIPS Development <linux-mips@linux-mips.org>
In-reply-to: Message from Geert Uytterhoeven <geert@linux-m68k.org> of "Tue, 28 Jan 2003 13:27:42 +0100." <Pine.GSO.4.21.0301281315380.9269-100000@vervain.sonytel.be>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Geert Uytterhoeven wrote:
>On Tue, 28 Jan 2003, Ralf Baechle wrote:
>> On Tue, Jan 28, 2003 at 10:30:20AM +0100, Geert Uytterhoeven wrote:
>> > If it happens, I should get a SIGILL, right?
>> 
>> Right.
>> 
>> Hmm...  If you can't reproduce this anymore I guess we should pull this
>> patch again?  Despite Mike basically acknowledging that such behaviour
>
>I cannot reproduce it in user space. I can still reproduce it in kernel space
>when an incoming TCP connection is accepted:
>
>| 8034d568 <tcp_v4_conn_request>:

I had a problem in tcp_rcv_established() where this "if" would trigger
even though "th->syn" was zero:

...
        if (th->syn && !before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
...

It turned out the tcp header was 'misaligned' after coming across a
usb link.  I never figured out why it was failing, but it was clearly
the emulation code which was doing the wrong thing.  This was on an
alchemy au1000 (MIPS32).

also in the kernel...

-brad

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