On Tue, 13 Mar 2007 01:02:52 +0000
Ralf Baechle <firstname.lastname@example.org> wrote:
> On Fri, Mar 09, 2007 at 07:13:54PM +0100, Attila Kinali wrote:
> > I'm using a 126.96.36.199 (an old snapshot from about last august,
> > when we started development of another board) that has slight
> > adjustments in various drivers to accomodate for our platform
> > specific stuff.
> You may want to update anyway. between the linux-188.8.131.52 tag of the
> linux-mips.org and the top of the linux-2.6.16-stable branch there are
> almost 58,000 lines of patch. Even more if your compare the MIPS -stable
> branch to kernel.org's 184.108.40.206. Iow a few metric buttloads.
That's already planned. But if first have to get past those
dead lines. After that i can look into makeing the whole
build system upgradeable and managable-
> > 0xffffffff80266134 <vsnprintf+76>: beqz v0,0x80266144 <vsnprintf+92>
> > 0xffffffff80266138 <vsnprintf+80>: bltz a0,0x802461c0
> > <jffs2_remount_fs+144>
> A branch in the delay slot of another branch is forbidden by the MIPS
> architecture. All processors I every tried this on missbehave in very
> unobvious ways when this is attempted.
> You may want to compare that against your vmlinux file. If the vmlinux
> binary also contains this bug, try building the affected source file with
> -S to find if the bug is cause by compiler or assembler.
It turned out to be a ground bounce problem. Interestingly the
"bug" was 100% reproducable, while normale ground problems are
totaly random. Thus i thought it has to be something in the
> In single stepping mode your debugger probably executes branches by
> software emulation. Chances are the emulation does something different
> for this illegal code sequence than actual hardware.
Oh.. nice to know. Thanks.
Thanks a lot for your answer and help,
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred