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@xxxxxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
