Re: "Invalid module format"

[Randy Dunlap <rdunlap@xenotime.net>]

On 03/05/10 22:48, Theodore Kilgore wrote:
> 
> 
> On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote:
> 
>> Randy Dunlap wrote:
>>> On 03/05/10 16:51, VDR User wrote:
>>>> On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore
>>>> <kilgota@banach.math.auburn.edu> wrote:
>>>>> This is to report the good news that none of the above suspicions have
>>>>> panned out. I still do not know the exact cause of the problem, but
>>>>> a local
>>>>> compile and install of the 2.6.33 kernel did solve the problem.
>>>>> Hence, it
>>>>> does seem that the most likely origin of the problem is somewhere
>>>>> in the
>>>>> Slackware-current tree and the solution does not otherwise concern
>>>>> anyone on
>>>>> this list and does not need to be pursued here.
>>>> I experienced the same problem and posted a new thread about it with
>>>> the subject "Problem with v4l tree and kernel 2.6.33".  I'm a debian
>>>> user as well so apparently whatever is causing this is not specific to
>>>> debian or slackware.  Even though you've got it working now, the
>>>> source of the problem should be investigated.
>>>> -- 
>>>
>>> It's been several years since I last saw this error and I don't recall
>>> what caused it then.
>>>
>>> The message "Invalid module format" comes from either of modprobe and/or
>>> insmod when the kernel returns ENOEXEC to a module (load) syscall.
>>> Sometimes the kernel produces more explanatory messages  & sometimes
>>> not.
>>>
>>> If there are no more explanatory messages, then kernel/module.c can be
>>> built with DEBUGP producing more output (and then that new kernel would
>>> have to be loaded).
>>>
>>> Can one of you provide a kernel config file for a kernel/modprobe
>>> combination
>>> that produces this message?  Some of the CONFIG_MODULE* config
>>> symbols could
>>> have relevance here also.
>>>
>>
>>
>> I suspect that it may be related to this:
>>
>> # Select 32 or 64 bit
>> config 64BIT
>>        bool "64-bit kernel" if ARCH = "x86"
>>        default ARCH = "x86_64"
>>        ---help---
>>          Say yes to build a 64-bit kernel - formerly known as x86_64
>>          Say no to build a 32-bit kernel - formerly known as i386
>>
>> With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits
>> machine without needing to pass make ARCH=i386 or to use
>> cross-compilation.
>>
>> Maybe you're running a 32bits kernel, and you've compiled the out-of-tree
>> modules with 64bits or vice-versa.
>>
>> My suggestion is that you should try to force the compilation wit the
>> proper
>> ARCH with something like:
>>     make distclean
>>     make ARCH=`uname -i`
>>     make ARCH=`uname -i` install
>>
>> -- 
>>
>> Cheers,
>> Mauro
> 
> Mauro,
> 
> After I did a re-compile of the kernel and modules, all the gspca stuff
> (at least, what I tested which is two or three cameras) all worked just
> fine. All I needed to do was make distclean and then make menuconfig
> again and the gspca setup "saw" my new kernel. I made sure to know this
> by putting up a slightly different name for it, using
> CONFIG_LOCALVERSION= option. So I guess to this extent I used force, but
> I did not need to do more than that.
> 
> 
> Now, seeing if I can help further in tracking this thing down, here are
> some more details.
> 
> 1. As I said, the problem is fixed now, by a local re-compile of the
> kernel (I did change a few things in the configuration and also cleared
> out a lot of junk which has nothing to do with my hardware, of course).
> So there might be some things of interest in the two config files.
> Naturally, I can send them to anyone who would like to see them. But I
> think that I cover the important differences below.
> 
> 
> Additional comment: I probably could have taken the option of running
> Slackware64 if I wanted to do that, because I suspect that my hardware
> would support it. But I used regular Slackware. So the kernel, the
> modules, and everything else are 32-bit, or supposed to be, though the
> machine could run 64-bit.
> 
> 2. According to what you are saying, here from my current config file is
> what might be relevant
> 
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> # CONFIG_X86_64 is not set
> CONFIG_X86=y
> CONFIG_OUTPUT_FORMAT="elf32-i386"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
> 
> and also it might possibly be important, too, that the processor type I
> chose was
> 
> CONFIG_MK8=y
> 
> for the very good reason that this is what is in the machine. Also I cut
> the choice for support of parallel CPUs down to 2 CPUs from 8 CPUs,
> again because that is what is actually present.
> 
> And furthermore my kernel config says
> 
> CONFIG_LOCALVERSION="-my"
> 
> and the original one says
> 
> CONFIG_LOCALVERSION="-smp"
> 
> so that I have two distinct sets of modules, 2.6.33-my and 2.6.33-smp
> and I can go back and boot from the Slackware kernel to a functioning
> machine, too.
> 
> The kernel which I used from Slackware-current is one of the standard
> ones, the one called vmlinuz-huge-smp-2.6.33-smp which comes in the
> Slackware package called kernel-huge-smp-2.6.33_smp-i686-1.txz. Its
> config file is in the package, too, so here are the similar parts of it:
> 
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> # CONFIG_X86_64 is not set
> CONFIG_X86=y
> CONFIG_OUTPUT_FORMAT="elf32-i386"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
> 
> The above looks the same to me as my choices. But the CPU type was quite
> different, of course, because it was a distro kernel.
> 
> CONFIG_M686=y
> 
> And the Slackware kernel also chose
> 
> CONFIG_X86_GENERIC=y
> 
> but when re-compiling I turned that off.

Hey,
How are these kconfig symbols set?

CONFIG_MODULES
CONFIG_MODULE_FORCE_LOAD
CONFIG_MODULE_UNLOAD
CONFIG_MODULE_FORCE_UNLOAD
CONFIG_MODVERSIONS
CONFIG_MODULE_SRCVERSION_ALL

in both a working (distro?) kernel and in the failing kernel, please.

> Also, as mentioned previously, the choice in the Slackware kernel was to
> support up to 8 parallel CPUs.
> 
> If there is anything else of interest in comparing the two config files,
> someone should let me know. The only thing I can put my finger on is the
> different choice of CPU and possibly the "GENERIC" option can cause
> occasional problems?
> 
> I seem to recall that I have had trouble with this kind of thing
> sometimes in the long-ago past, as someone else has mentioned. On a
> couple of occasions way back when, some of the "stock" distro modules
> would not initialize properly and the cure was to do a local
> kernel-and-modules compile. Not that compiling the kernel bothered me
> terribly back then, or now. But a problem like this one is in a way an
> accident, and of course accidents are not supposed to happen.
> 
> Trying to look backward, It seems to me that one factor in the long-ago
> problems and also in this one might be the difference between the
> default CPU choice in a distro kernel and what is actually in the
> machine. Especially, the difference between having "M686" in the kernel
> and modules, as opposed to something else (especially something like K8)
> being in the machine might sometimes cause interference. And then
> modprobe sees the real hardware and sees an apparent conflict in the
> choice of M686 in the module. But this is only semi-informed speculation
> on my part. Someone else may know a lot more.
> 
> Hoping that the above helps in tracking down the problem.
> 
> Theodore Kilgore
> 


-- 
~Randy