inconsistent results from modprobe

nyloc · 08-08-2007, 08:17 PM

during my testing to find the problem with eth0 I came across this.
from /etc/.../blacklist

Quote:

# Alternate Intel EtherExpress Pro/100 support driver. List it
# here so it won't conflict with an already-loaded eepro100 module.
blacklist e100

# Ethernet over IEEE1394 module. In too many cases this will load
# when there's no eth1394 device present (just an IEEE1394 port)
blacklist eth1394

I ran this code

Code:

>modprobe e100
>modprobe eth1394
WARNING: Error inserting ieee1394 (/lib/modules/2.6.21.5-smp/kernel/drivers/ieee1394/ieee1394.ko): Invalid module format

does anyone know why the results from modprobe are different
(and yes I know I dont need those modules, but they were mention in forums covering eth0 and a drowning man will clutch at anything)

tobyl · 08-09-2007, 12:07 PM

I would say that the e100 driver found a device to bind to (and so it loaded), but the ieee1394 did not.
The output of dmesg can sometimes help -(read last entries after your modprobe attempt)
If you give the output of /sbin/lspci we may be able to help with the correct driver

tobyl

onebuck · 08-09-2007, 03:57 PM

Quote:

Originally Posted by nyloc

during my testing to find the problem with eth0 I came across this.
from /etc/.../blacklist

I ran this code

Code:

>modprobe e100
>modprobe eth1394
WARNING: Error inserting ieee1394 (/lib/modules/2.6.21.5-smp/kernel/drivers/ieee1394/ieee1394.ko): Invalid module format

does anyone know why the results from modprobe are different
(and yes I know I dont need those modules, but they were mention in forums covering eth0 and a drowning man will clutch at anything)

Hi,

Did you read the Slackware 12.0 CHANGES_AND_HINTS.TXT, UPGRADE.TXT and RELEASE_NOTES?

If you read the CHANGES_AND_HINTS.TXT;

Quote:

excerpt from CHANGES_AND_HINTS.TXT;

As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernel is primarily intended as
an "installer" and "emergency" kernel in case you forget to make an initrd.
However, if you do use one of the huge kernels, you will likely encounter
errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to register
These occur because the respective drivers are compiled statically into the
huge kernels but udev tries to load them anyway. These errors should be safe
to ignore, but if you really don't want them to appear, you can blacklist the
modules that try to load in /etc/modprobe.d/blacklist. However, make sure you
remove them from the blacklist if you ever decide to use the (recommended)
generic kernels.

This is also relative to the 'invalid format error'. Note the 'last' sentence' in case you wish to use the module at some future time.

tobyl · 08-09-2007, 04:44 PM

Onebuck - correct me if I am wrong, but the OP's kernel is 2.6.21.5-smp.
Although 'invalid format error' is symptomatic of trying to load modules that are statically compiled in, the kernel shown has the relevant options compiled as modules. Also the error that you quote is different to the one received. So I think you may be a little unfair here.

tobyl

onebuck · 08-09-2007, 08:40 PM

Quote:

Originally Posted by tobyl

Onebuck - correct me if I am wrong, but the OP's kernel is 2.6.21.5-smp.
Although 'invalid format error' is symptomatic of trying to load modules that are statically compiled in, the kernel shown has the relevant options compiled as modules. Also the error that you quote is different to the one received. So I think you may be a little unfair here.

tobyl

Hi,

We had a duscussion about this very thing some time ago. I think the thread was with rworkman. I'll do a search and get back.

I did have the same errors using the 2.6.21.5-smp kernel. You generally get rid of the problem with a new compile. I don't think fairness has anything to do with the error.

This thread was one of the discussions.

This was another thread 'Slackware 12 boot error revisited'.

This was the one with rworkman 'Slackware 12.0 'Invalid module format''. And indeed it was a symbol problem with the attempt to load again. I remembered this after reading the post(s) again.