"Invalid module format"

"Invalid module format"

[Theodore Kilgore]

Hi,

I just upgraded to the stock 2.6.33 kernel in Slackware-current. Also 
after having the troubles described below I cloned a completely new copy 
of the gspca tree from http://linuxtv.org/hg/~hgoede/gspca, intending to 
get some work done on a project recently started.

I did make menuconfig (preceded on the first occasion by make distclean, 
of course) and chose my options. Then I did make and make install. When I 
plugged in a camera, nothing. So I tried modprobe gspca_main and here is 
what happens

root@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# modprobe 
gspca_main
WARNING: Error inserting v4l1_compat 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): 
Invalid module format
WARNING: Error inserting videodev 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid 
module format
FATAL: Error inserting gspca_main 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): 
Invalid module format
root@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca#

Any suggestions?

Theodore Kilgore

Re: "Invalid module format"

[Theodore Kilgore]

On Thu, 4 Mar 2010, Theodore Kilgore wrote:

>
> Hi,
>
> I just upgraded to the stock 2.6.33 kernel in Slackware-current. Also after 
> having the troubles described below I cloned a completely new copy of the 
> gspca tree from http://linuxtv.org/hg/~hgoede/gspca, intending to get some 
> work done on a project recently started.
>
> I did make menuconfig (preceded on the first occasion by make distclean, of 
> course) and chose my options. Then I did make and make install. When I 
> plugged in a camera, nothing. So I tried modprobe gspca_main and here is what 
> happens
>
> root@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# modprobe 
> gspca_main
> WARNING: Error inserting v4l1_compat 
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid 
> module format
> WARNING: Error inserting videodev 
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid 
> module format
> FATAL: Error inserting gspca_main 
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): 
> Invalid module format
> root@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca#
>
> Any suggestions?
>
> Theodore Kilgore

I posted about this problem on this list because I have been reading that 
there are recent problems with Mercurial trees, also supposing that one 
possible cause of the problem could lie in the compatibility layer which 
directs one to the right kernel, also in the reasonable suspicion that the 
problem could originate from the new kernel 2.6.33.

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.

Theodore Kilgore

Re: "Invalid module format"

[VDR User]

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.

Re: "Invalid module format"

[Randy Dunlap]

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.

-- 
~Randy

Re: "Invalid module format"

[Mauro Carvalho Chehab]

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

Re: "Invalid module format"

[Theodore Kilgore]

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.

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

Re: "Invalid module format"

[Randy Dunlap]

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

Re: "Invalid module format"

[Theodore Kilgore]

On Sun, 7 Mar 2010, Randy Dunlap wrote:

> 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.

In the failing kernel,

CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set

In my locally compiled working kernel,

CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set

In other words, I did not touch those settings. They looked just fine to 
me. So I would guess the problem is somewhere else.

Theodore Kilgore

Re: "Invalid module format"

[Theodore Kilgore]

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,

I do not know where this leads, but here is a second answer with another 
piece of information.

I mentioned yesterday that I have at this point two kernels, called 
2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current 
kernel, and the 2.6.33-my is locally compiled, with somewhat different 
config parameters. Each of these has its module tree, independent of the 
other. By which I mean that I have a module tree

lib/modules/2.6.33-smp associated with kernel 2.6.33-smp

and another module tree

lib/modules/2/6/33-my associated with kernel 2.6.33-my

I started out, of course, by installing the gspca modules in 
lib/modules/2.6.33-smp and thereby I presumably over-wrote things in
lib/modules/2.6.33-smp/kernel/drivers/media which were present 
in the 2.6.33-smp module package from the distro.

Now, today I did a reinstallation of the 2.6.33-smp modules tree and 
booted with 2.6.33-smp. I did *not* do anything to change the what was 
there. For example, I did not install anything from any gspca mercurial 
tree. No, only what comes with the distro kernel's modules is there.

Now, here is what happens under these circumstances:

root@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main
WARNING: Error inserting v4l1_compat 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): 
Invalid module format
WARNING: Error inserting videodev 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid 
module format
FATAL: Error inserting gspca_main 
(/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): 
Invalid module format
root@khayyam:/lib/modules/2.6.33-smp/kernel#

In other words, the same error message as yesterday. But this time the 
module I was trying to load up was not created by me, but instead it was 
the one obtained from the distro kernel's modules.

Strangely, though, some of the other modules which came with the distro 
kernel _do_ work. Some of them are essential for running the machine, and 
they are doing just fine.


Theodore Kilgore

Re: "Invalid module format"

[Mauro Carvalho Chehab]

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,
> 
> I do not know where this leads, but here is a second answer with another
> piece of information.
> 
> I mentioned yesterday that I have at this point two kernels, called
> 2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current
> kernel, and the 2.6.33-my is locally compiled, with somewhat different
> config parameters. Each of these has its module tree, independent of the
> other. By which I mean that I have a module tree
> 
> lib/modules/2.6.33-smp associated with kernel 2.6.33-smp
> 
> and another module tree
> 
> lib/modules/2/6/33-my associated with kernel 2.6.33-my
> 
> I started out, of course, by installing the gspca modules in
> lib/modules/2.6.33-smp and thereby I presumably over-wrote things in
> lib/modules/2.6.33-smp/kernel/drivers/media which were present in the
> 2.6.33-smp module package from the distro.
> 
> Now, today I did a reinstallation of the 2.6.33-smp modules tree and
> booted with 2.6.33-smp. I did *not* do anything to change the what was
> there. For example, I did not install anything from any gspca mercurial
> tree. No, only what comes with the distro kernel's modules is there.
> 
> Now, here is what happens under these circumstances:
> 
> root@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main
> WARNING: Error inserting v4l1_compat
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko):
> Invalid module format
> WARNING: Error inserting videodev
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko):
> Invalid module format
> FATAL: Error inserting gspca_main
> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko):
> Invalid module format
> root@khayyam:/lib/modules/2.6.33-smp/kernel#
> 
> In other words, the same error message as yesterday. But this time the
> module I was trying to load up was not created by me, but instead it was
> the one obtained from the distro kernel's modules.
> 
> Strangely, though, some of the other modules which came with the distro
> kernel _do_ work. Some of them are essential for running the machine,
> and they are doing just fine.

Interesting. Are you sure you didn't mixed distro kernels with the ones you've compiled
on your re-installation? In other words, had you removed the old /lib/modules/2.6.33-smp/
directory before re-installing it from your distro? If so, then it seems that distro is
providing some broken modules.

-- 

Cheers,
Mauro

Re: "Invalid module format"

[Theodore Kilgore]

On Sun, 7 Mar 2010, Mauro Carvalho Chehab wrote:

> 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,
>>
>> I do not know where this leads, but here is a second answer with another
>> piece of information.
>>
>> I mentioned yesterday that I have at this point two kernels, called
>> 2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current
>> kernel, and the 2.6.33-my is locally compiled, with somewhat different
>> config parameters. Each of these has its module tree, independent of the
>> other. By which I mean that I have a module tree
>>
>> lib/modules/2.6.33-smp associated with kernel 2.6.33-smp
>>
>> and another module tree
>>
>> lib/modules/2/6/33-my associated with kernel 2.6.33-my
>>
>> I started out, of course, by installing the gspca modules in
>> lib/modules/2.6.33-smp and thereby I presumably over-wrote things in
>> lib/modules/2.6.33-smp/kernel/drivers/media which were present in the
>> 2.6.33-smp module package from the distro.
>>
>> Now, today I did a reinstallation of the 2.6.33-smp modules tree and
>> booted with 2.6.33-smp. I did *not* do anything to change the what was
>> there. For example, I did not install anything from any gspca mercurial
>> tree. No, only what comes with the distro kernel's modules is there.
>>
>> Now, here is what happens under these circumstances:
>>
>> root@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main
>> WARNING: Error inserting v4l1_compat
>> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko):
>> Invalid module format
>> WARNING: Error inserting videodev
>> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko):
>> Invalid module format
>> FATAL: Error inserting gspca_main
>> (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko):
>> Invalid module format
>> root@khayyam:/lib/modules/2.6.33-smp/kernel#
>>
>> In other words, the same error message as yesterday. But this time the
>> module I was trying to load up was not created by me, but instead it was
>> the one obtained from the distro kernel's modules.
>>
>> Strangely, though, some of the other modules which came with the distro
>> kernel _do_ work. Some of them are essential for running the machine,
>> and they are doing just fine.
>
> Interesting. Are you sure you didn't mixed distro kernels with the ones you've compiled
> on your re-installation?

Yes.

In other words, had you removed the old /lib/modules/2.6.33-smp/
> directory before re-installing it from your distro?

Yes.

If so, then it seems that distro is
> providing some broken modules.

It appears so. Yes.

However, in fairness to the distro, which I am not about to quit using, I 
am running the "-current" version, which is distributed with the explicit 
warning that stuff might occasionally be broken. And even with this 
warning this is the first time that I have any serious problem in several 
years. One does need to take things like this in perspective.

For two reasons I continue to pursue the problem here, though.

First, it is exactly the case that there are "some" broken modules and not 
others. And those which appear to be broken are exactly those connected 
with drivers/media, no matter whether these modules came from the distro 
kernel or came from a local compile off of a gspca development tree.

Second, it is reported here a couple of days ago, in response to my 
original message, that someone else has had the same or similar problem 
with 2.6.33 on Debian.

Because of the above two reasons, it appears to me that there might 
possibly be some deeper problem which needs to be looked into. I do not 
claim to know exactly which way to look, but it seems that there might be 
something to look for.

Theodore Kilgore

Re: "Invalid module format"

[VDR User]

On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> 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

I had forgot to reply to this but while I do have a 64bit capable cpu,
I compile & use only 32bit.

Re: "Invalid module format"

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1171 bytes --]



On Sun, 7 Mar 2010, VDR User wrote:

> On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> 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
>
> I had forgot to reply to this but while I do have a 64bit capable cpu,
> I compile & use only 32bit.
>

Same here. Let us hope it is the same problem, and it will be possible to 
track it down once and fix it.

Theodore Kilgore

Re: "Invalid module format"

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1515 bytes --]



On Sun, 7 Mar 2010, VDR User wrote:

> On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> 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
>
> I had forgot to reply to this but while I do have a 64bit capable cpu,
> I compile & use only 32bit.
>

Hi,

It seems that the problem is solved by a local re-compile of the kernel 
plus its modules, using the original distro .config settings in order to 
do this. What I suspect has happened is that there was a simultaneous 
minor upgrade of gcc at the same time, and it is possible that this 
interfered. I would further speculate that a similar problem happened with 
you, in your Debian installation.

Hoping that we have finally tracked this down.

Theodore Kilgore

Re: "Invalid module format"

[VDR User]

On Sun, Mar 7, 2010 at 2:03 PM, Theodore Kilgore
<kilgota@banach.math.auburn.edu> wrote:
> It seems that the problem is solved by a local re-compile of the kernel plus
> its modules, using the original distro .config settings in order to do this.
> What I suspect has happened is that there was a simultaneous minor upgrade
> of gcc at the same time, and it is possible that this interfered. I would
> further speculate that a similar problem happened with you, in your Debian
> installation.
>
> Hoping that we have finally tracked this down.

It's a good theory.  However, when I did my "update", I had compiled
the kernel, installed it, rebooted into it and then proceeded to grab
a fresh v4l tree and go from there.  There wern't any package updates
or anything else involved between the kernel compile and v4l compile.
(except for the reboot into 2.6.33 of course.)

Re: "Invalid module format"

[Mauro Carvalho Chehab]

VDR User wrote:
> On Sun, Mar 7, 2010 at 2:03 PM, Theodore Kilgore
> <kilgota@banach.math.auburn.edu> wrote:
>> It seems that the problem is solved by a local re-compile of the kernel plus
>> its modules, using the original distro .config settings in order to do this.
>> What I suspect has happened is that there was a simultaneous minor upgrade
>> of gcc at the same time, and it is possible that this interfered. I would
>> further speculate that a similar problem happened with you, in your Debian
>> installation.
>>
>> Hoping that we have finally tracked this down.
> 
> It's a good theory.  However, when I did my "update", I had compiled
> the kernel, installed it, rebooted into it and then proceeded to grab
> a fresh v4l tree and go from there.  There wern't any package updates
> or anything else involved between the kernel compile and v4l compile.
> (except for the reboot into 2.6.33 of course.)

You may try to check if both the kernel files and the out of tree files are compiled
using the same file format, with something like:

$ objdump v4l/cx23885.ko /lib/modules/`uname -r`/kernel/drivers/ata/ahci.ko -a

v4l/cx23885.ko:     file format elf64-x86-64
v4l/cx23885.ko


/lib/modules/2.6.33/kernel/drivers/ata/ahci.ko:     file format elf64-x86-64
/lib/modules/2.6.33/kernel/drivers/ata/ahci.ko

(assuming that debian has ahci.ko compiled as module and at the right place - you may
need to find another module there, it this one doesn't exist).

Cheers,
Mauro

---

PS.: if you're using kernel 2.6.33, plus the latest v4l-dvb hg tree, you could 
alternatively use the latest git tree, as it is just 2.6.33 + drivers/media
(and media staging) updates.

I intend to keep v4l-dvb.git and fixes.git trees with 2.6.33 during all 2.6.34 rc cycle,
in order to help people to test the drivers, if we don't have any mandatory reason to
update to -rc1