[Top] [All Lists]

Re: insmod on mips

To: "Vladimir A. Roganov" <>
Subject: Re: insmod on mips
From: Ralf Baechle <>
Date: Tue, 17 Aug 1999 00:42:39 +0200
In-reply-to: <>; from Vladimir A. Roganov on Mon, Aug 16, 1999 at 08:33:15PM +0400
References: <>
On Mon, Aug 16, 1999 at 08:33:15PM +0400, Vladimir A. Roganov wrote:

> We have some problems with modules loading in our Linux/R3k.
> The picture is following:
>   1. For modutils-2.1.121 rebuilt for linux-2.2.1/r3k any
>      attempt to insmod something lead to insmod segfault.
>      The line where it dies is obj/obj_mips.c:184:
>                    assert(v == l->value);
>      The value of 'l' here is a (struct mips_hi16 *) 0x41

Not good :-)

>   2. For modutils placed in HardHat instimage the command
>     'insmod <object>' takes infinite time (locking kernel
>      somewhere), but kernel looks alive (console input keys).     

That one was definately buggy ...

> The modules we are testing is mtd physmem device: they works
> well for Intel and looks very platform-independent
> (I don't think that the problem located inside them).
> The behaviour is same for cross-compiled and native-compiled
> objects.

Yep.  Btw, the modutils code has #ident ops which will be missompiled
by older compilers.  Make shure you've got one of my patches for egcs 1.0.3.
They'll build this correctly.  Alternatively just remove the #idents.

> Due it looks just like a some mismatch in our kernel, modutils
> and compiler versions, we are very interesting to get info
> about working combination for all above 
> (or about new versions with more fresh and actual bugs :-) 

Try to get the current modutils via anon-cvs from vger as described in the
FAQ, does it help?


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