i've upgraded modutils from 2.3.14 (originally installed by RH7,kernel
2.2.16) to 2.3.22 using "rpm -Fvh modultils2.3.22-1.i386.rpm*" as required
by the kernel 2.4test12 compilation. after upgrading, the network module
refused to load anymore (was working fine with insmod 2.3.14) with kernel
2.2.16/RH7. during boot process, the following error message was shown:
insmod: /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o insmod eth0
failed.
executing "insmod 8139too" at the command prompt shows the following error
message:
using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o
/lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for
parameter debug not found.
pls kindly advise if i've done something wrong during the upgrade or are
there known compatibility issues with modutils 2.3.22?
how can i make insmod load the network module again pls?
thanks.
* Corisen schrieb am Donnerstag, 14.12.2000:
> executing "insmod 8139too" at the command prompt shows the following error
> message:
> using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o
> /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for
> parameter debug not found.
> how can i make insmod load the network module again pls?
I "fixed" the same problem in 2.2.18 by commenting out the line
MODULE_PARM (debug, "i");
near the end of drivers/net/8139too.c. Since I run modutils 2.3.22
as well, it can't be related to the modutils.
--
Christian Ullrich Registrierter Linux-User #125183
"Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"
Christian Ullrich wrote:
>
> * Corisen schrieb am Donnerstag, 14.12.2000:
>
> > executing "insmod 8139too" at the command prompt shows the following error
> > message:
> > using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o
> > /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for
> > parameter debug not found.
>
> > how can i make insmod load the network module again pls?
>
> I "fixed" the same problem in 2.2.18 by commenting out the line
>
> MODULE_PARM (debug, "i");
>
> near the end of drivers/net/8139too.c. Since I run modutils 2.3.22
> as well, it can't be related to the modutils.
Yep, that's the correct fix -- remove that line.
My apologies to Keith Owens for originally saying the opposite (I deal
with so many net drivers they all get jumbled up in my mind)
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
> > how can i make insmod load the network module again pls?
>
> I "fixed" the same problem in 2.2.18 by commenting out the line
>
> MODULE_PARM (debug, "i");
>
> near the end of drivers/net/8139too.c. Since I run modutils 2.3.22
> as well, it can't be related to the modutils.
It is modutils. Their behaviour changed in a non back compatible way. Do not
use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can
make this a warning in 2.3.23
Alan Cox wrote:
>
> > > how can i make insmod load the network module again pls?
> >
> > I "fixed" the same problem in 2.2.18 by commenting out the line
> >
> > MODULE_PARM (debug, "i");
> >
> > near the end of drivers/net/8139too.c. Since I run modutils 2.3.22
> > as well, it can't be related to the modutils.
>
> It is modutils. Their behaviour changed in a non back compatible way. Do not
> use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can
> make this a warning in 2.3.23
That, and/or allow "insmod -f" to load the module. '-f' has become
pretty useless lately... :)
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
On Wed, 13 Dec 2000 21:10:54 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>It is modutils. Their behaviour changed in a non back compatible way. Do not
>use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can
>make this a warning in 2.3.23
Adding persistent module data to modutils meant that insmod had to be a
lot more picky about MODULE_PARM() entries. There were a few modules
that had invalid MODULE_PARM() entries, nobody had spotted them
previously because nobody used those options. Since these are bugs in
the modules and only a few modules are affected (less than 5 reported),
the fix is to correct the modules that have coding errors.
> previously because nobody used those options. Since these are bugs in
> the modules and only a few modules are affected (less than 5 reported),
> the fix is to correct the modules that have coding errors.
That wont be happening in 2.2 until 2.2.19 which probably means 6 months.
If this is your decision please make it abundantly clear that the new
modutils are a 2.4 only package.
On Wed, 13 Dec 2000 22:13:29 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>> previously because nobody used those options. Since these are bugs in
>> the modules and only a few modules are affected (less than 5 reported),
>> the fix is to correct the modules that have coding errors.
>
>That wont be happening in 2.2 until 2.2.19 which probably means 6 months.
>If this is your decision please make it abundantly clear that the new
>modutils are a 2.4 only package.
Well, if it is going to take that long to fix 2.2 ... modutils 2.3.23
will make this a semi-warning. modules with invalid MODULE_PARM for
options that are not used will load, but the module will not support
persistent data. If somebody actually tries to use one of the invalid
options then insmod will fail, it already does this.
> Well, if it is going to take that long to fix 2.2 ... modutils 2.3.23
It may do. 2.2.18 took a long time.
> will make this a semi-warning. modules with invalid MODULE_PARM for
> options that are not used will load, but the module will not support
> persistent data. If somebody actually tries to use one of the invalid
> options then insmod will fail, it already does this.
That sounds fine. Warning is sensible, not supporting persistent data is
obvious enough and 2.2 doesnt do that yet so it isnt a problem.
Alan
Alan Cox <[email protected]> said:
> In-Reply-To: <[email protected]> from "Keith Owens" at Dec 14, 2000 0
> ***9:05:13 AM
> > previously because nobody used those options. Since these are bugs in
> > the modules and only a few modules are affected (less than 5 reported),
> > the fix is to correct the modules that have coding errors.
> That wont be happening in 2.2 until 2.2.19 which probably means 6 months.
> If this is your decision please make it abundantly clear that the new
> modutils are a 2.4 only package.
Why can't you make a fast 2.2.19 with _just_ safe bug fixes (as the fixing
of these module problems certainly is)?
--
Dr. Horst H. von Brand mailto:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
> Why can't you make a fast 2.2.19 with _just_ safe bug fixes (as the fixing
> of these module problems certainly is)?
Shall I do a 2.2 release for every trivia. I think not.
There is plenty to get into 2.2.19 already