Re: Can't load modules with parameters given

[Benjamin Block <bebl@mageta.org>]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On 12/22/2013 10:16 PM, Lucas De Marchi wrote:
> Hi Benjamin,
> 
> 
> On Thu, Dec 19, 2013 at 4:31 PM, Benjamin Block <bebl@mageta.org> wrote:
>> Hi,
>>
>> I have a rather strange problem currently. I am trying to load a module
> 
> strange indeed
> 
>> with some parameters (bnx2x with disable_tpa=1) and it fails because
>> this parameter is unknown according to dmesg. But modinfo lists this
>> exact paramter and it is also included in the source. And while this is
>> not an in-tree driver, I could also replicate the same behavior with
> 
> are you sure modinfo and modprobe are reading the same module? maybe
> you updated your modules between the operations?
> 

pretty sure. It shows the exact path to the .ko, because this is a
out-of-tree driver that is not located under /lib/modules/..
And in case of the bonding-example, there is no other module anywhere
else with the same name.

> 
>> in-tree device drivers (like bonding with the parameter tx_queues):
>>
>> $ modprobe bonding # works fine
>> $ rmmod bonding
>> $ modprobe bonding tx_queues=32
>> modprobe: ERROR: could not insert 'bonding': Unknown symbol in module,
>> or unknown parameter (see dmesg)
>>
>> and dmesg tells me:
>>         bonding: Unknown parameter `tx_queues'
>> and nothing else (as with bnx2x, this parameter is listed by modinfo).
>>
>> Is there some obvious kernel-config-option I could have messed up or
>> something else like this?
> 
> So... this changed in recent kernels (3.11 -- see the commit message
> that introduced this behavior below)... we don't fail to load a module
> anymore due to unknown option. So if/when you upgrade you won't see
> this problem anymore.
> 
> Anyway, it shouldn't fail for you like it did, but it might as well be
> a problem of the particularly patched kernel you are using... not
> sure.
> 
> 
>>
>> I am using a Gentoo-Userspace kmod (v15) with a Ubuntu-Kernel (3.8.13.13
>> - this is a version with some ubuntu-patches applied) - I know, the
>> combination is rather strange. Any ideas?
> 
> the combination is not a problem and should work just fine.
> 

I am now certain that this is a specific and/or combination of
kernel-configuration-options which is messing this up here. I have a
debug- and a release-configuration with the only difference that the
debug-config contains several kernel-hacking-features enabled that the
release doesn't include (compiled with symbols, lockdep, tracing and
stuff like this). And in the release-config I could load the module with
the parameter given.

When I'm at work again I will figure out which config messes this up
exactly (I don't have access to the machines right now).


- Benjamin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]