Re: "Invalid module format"
VDR User wrote: > On Sun, Mar 7, 2010 at 2:03 PM, Theodore Kilgore > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
On Sun, Mar 7, 2010 at 2:03 PM, Theodore Kilgore 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.) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
On Sun, 7 Mar 2010, VDR User wrote: On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab 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"
On Sun, 7 Mar 2010, VDR User wrote: On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab 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"
On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
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 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
Re: "Invalid module format"
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 >>>> 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_O
Re: "Invalid module format"
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 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: r...@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 r...@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" ve
Re: "Invalid module format"
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 >>>> 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: > > r...@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 modul
Re: "Invalid module format"
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 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: r...@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 r...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
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 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_FORMA
Re: "Invalid module format"
Randy Dunlap wrote: > On 03/05/10 16:51, VDR User wrote: >> On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
On 03/05/10 16:51, VDR User wrote: > On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Invalid module format"
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 r...@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 r...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Invalid module format"
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 r...@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 r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# Any suggestions? Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 9:09 PM, Devin Heitmueller wrote: > On Wed, Sep 9, 2009 at 3:02 PM, Markus Rechberger > wrote: >> this is not true my old driver which is not available anymore did not >> ship any other modules aside the em28xx driver itself. >> This is a video4linux issue and has nothing to do with it. >> >> Best Regards, >> Markus >> > > Hello Marks, > > While it is true that your driver did not include anything other than > em28xx, I assume it is compiled against a certain set of v4l2 headers, > and if those headers change (such as changes to data structures), then > the em28xx modules you distributed would not work with that version of > the v4l2 modules. I stopped the work at around Oct last year, 2.6.27 is the latest kernel which is supposed to be supported with it. Although since there are some bad bugs in it which I've been told by the manufacturer afterwards I do not recommend to use it either it shortens the lifetime of most devices... Best is to stick with windows unless the manufacturer and chipdesigners support a driver. WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format this is something that cannot be caused by the em28xx work, it's any other messy issue with the v4l2 kernel API. Markus > If he wants to use your driver, I would assume he would need to > reinstall the stock kernel (overwriting whatever locally built version > of v4l-dvb he previously installed). > > Cheers, > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 3:02 PM, Markus Rechberger wrote: > this is not true my old driver which is not available anymore did not > ship any other modules aside the em28xx driver itself. > This is a video4linux issue and has nothing to do with it. > > Best Regards, > Markus > Hello Marks, While it is true that your driver did not include anything other than em28xx, I assume it is compiled against a certain set of v4l2 headers, and if those headers change (such as changes to data structures), then the em28xx modules you distributed would not work with that version of the v4l2 modules. If he wants to use your driver, I would assume he would need to reinstall the stock kernel (overwriting whatever locally built version of v4l-dvb he previously installed). Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 9:02 PM, Markus Rechberger wrote: > On Wed, Sep 9, 2009 at 6:19 PM, Devin > Heitmueller wrote: >> On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquez >> wrote: >>> Hello, >>> >>> I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. >>> The compilation of v4l-dvb works well (the kernel which is chosen is the >>> right), but when I try to modprobe em28xx, I get this : >>> >>> WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format >>> WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format >>> WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format >>> WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format >>> WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/videodev.ko): Invalid module format >>> WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format >>> WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/common/ir-common.ko): Invalid module format >>> FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- >>> r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format >>> >>> I have this error in my dmesg : >>> >>> [ 3903.465920] tveeprom: disagrees about version of symbol module_layout >>> >>> I join my .config file. >>> >>> What do I need to do ? >>> Thanks! >>> >> >> Usually this occurs when people are using the mrechberger version of >> the em28xx driver, and the symbols are in conflict with the rest of >> the v4l-dvb tree. >> > > this is not true my old driver which is not available anymore did not > ship any other modules aside the em28xx driver itself. > This is a video4linux issue and has nothing to do with it. > Just a note aside of that it is not recommended to use any non manufacturer certified driver. The linux driver will decrease the lifetime of nearly any em28xx based device or damage it permanently (as seen with the ATSC devices recently). This is more or less the outcome of static reverse engineered values from the windows driver which are not correct for all devices and device modes. Although the GPL takes over that no involved developer has any responsibility. Best Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 6:19 PM, Devin Heitmueller wrote: > On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquez wrote: >> Hello, >> >> I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. >> The compilation of v4l-dvb works well (the kernel which is chosen is the >> right), but when I try to modprobe em28xx, I get this : >> >> WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format >> WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format >> WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format >> WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format >> WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/videodev.ko): Invalid module format >> WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format >> WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/common/ir-common.ko): Invalid module format >> FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- >> r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format >> >> I have this error in my dmesg : >> >> [ 3903.465920] tveeprom: disagrees about version of symbol module_layout >> >> I join my .config file. >> >> What do I need to do ? >> Thanks! >> > > Usually this occurs when people are using the mrechberger version of > the em28xx driver, and the symbols are in conflict with the rest of > the v4l-dvb tree. > this is not true my old driver which is not available anymore did not ship any other modules aside the em28xx driver itself. This is a video4linux issue and has nothing to do with it. Best Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 2:34 PM, animatri...@gmail.com wrote: > > I have this error, when I load the module : > [ 2122.708062] em28xx: Unknown symbol v4l2_i2c_new_probed_subdev > [ 2122.708402] em28xx: disagrees about version of symbol v4l2_i2c_subdev_addr > [ 2122.708404] em28xx: Unknown symbol v4l2_i2c_subdev_addr > [ 2122.708680] em28xx: disagrees about version of symbol video_devdata > [ 2122.708682] em28xx: Unknown symbol video_devdata > [ 2122.708889] em28xx: Unknown symbol v4l_bound_align_image > [ 2122.709594] em28xx: disagrees about version of symbol > video_unregister_device > [ 2122.709597] em28xx: Unknown symbol video_unregister_device > [ 2122.709810] em28xx: disagrees about version of symbol video_device_alloc > [ 2122.709813] em28xx: Unknown symbol video_device_alloc > [ 2122.709886] em28xx: disagrees about version of symbol > v4l2_device_disconnect > [ 2122.709888] em28xx: Unknown symbol v4l2_device_disconnect > [ 2122.709982] em28xx: disagrees about version of symbol video_register_device > [ 2122.709985] em28xx: Unknown symbol video_register_device > [ 2122.710090] em28xx: disagrees about version of symbol v4l2_device_register > [ 2122.710093] em28xx: Unknown symbol v4l2_device_register > [ 2122.710416] em28xx: Unknown symbol ir_codes_evga_indtube > [ 2122.711104] em28xx: disagrees about version of symbol > v4l2_device_unregister > [ 2122.711106] em28xx: Unknown symbol v4l2_device_unregister > [ 2122.711332] em28xx: disagrees about version of symbol video_device_release > [ 2122.711335] em28xx: Unknown symbol video_device_release > [ 2122.711406] em28xx: disagrees about version of symbol v4l2_i2c_new_subdev > [ 2122.711408] em28xx: Unknown symbol v4l2_i2c_new_subdev > > Is it because of my (wrong) configuration or your code (debug) ? > Thanks ! > > (It seems that the mailing list is not working ) Please stop top posting. Did you build mrec's driver from source? Or are you using a binary package? If you built it from source, then your problem has to do with his code not finding the proper headers. If you are using his binary package, then you need to understand that the binary package only works with whatever kernel he built against. Either way, this is a problem with your environment and not with the v4l-dvb code. I'm not really in a position to help you debug problems getting mrec's driver to work. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 2:13 PM, animatri...@gmail.com wrote: > Without mrechberger version, I can't find support for my Pinnacle PCTV Usb > stick. > If I had it, (after having installed the mrec driver), I have this error : > > [ 909.128197] em28xx v4l2 driver version 0.0.1 loaded > [ 909.128518] em28xx: new video device (eb1a:2870): interface 0, class 255 > [ 909.128521] em28xx: device is attached to a USB 2.0 bus > [ 909.128525] em28xx #0: Alternate settings: 8 > [ 909.128527] em28xx #0: Alternate setting 0, max size= 0 > [ 909.128530] em28xx #0: Alternate setting 1, max size= 0 > [ 909.128532] em28xx #0: Alternate setting 2, max size= 1448 > [ 909.128535] em28xx #0: Alternate setting 3, max size= 2048 > [ 909.128537] em28xx #0: Alternate setting 4, max size= 2304 > [ 909.128540] em28xx #0: Alternate setting 5, max size= 2580 > [ 909.128543] em28xx #0: Alternate setting 6, max size= 2892 > [ 909.128545] em28xx #0: Alternate setting 7, max size= 3072 > [ 909.545514] input: em2880/em2870 remote control as /class/input/input12 > [ 909.545548] em28xx-input.c: remote control handler attached > [ 909.545551] em28xx #0: Found Pinnacle PCTV DVB-T > [ 909.545571] usbcore: registered new interface driver em28xx > [ 909.595321] em28xx_dvb: Unknown symbol em28xx_set_mode > [ 909.595461] em28xx_dvb: Unknown symbol em28xx_uninit_isoc > [ 909.595547] em28xx_dvb: Unknown symbol em28xx_init_isoc > [ 909.595678] em28xx_dvb: disagrees about version of symbol > em28xx_unregister_extension > [ 909.595681] em28xx_dvb: Unknown symbol em28xx_unregister_extension > [ 909.596137] em28xx_dvb: disagrees about version of symbol > em28xx_register_extension > [ 909.596140] em28xx_dvb: Unknown symbol em28xx_register_extension > [ 909.596355] em28xx_dvb: Unknown symbol em28xx_tuner_callback > > > What should I do ? > > Thanks! If you built mrec's driver from source, it may not have picked up the latest v4l headers. If you are trying to use his binary package, then you have to use whatever kernel he compiled it against (and you cannot install the latest v4l-dvb tree). Assuming you're talking about the model 70e, I have a tree setup for that device, but it's not yet fully debugged: http://www.kernellabs.com/hg/~dheitmueller/pctv-70e Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquez wrote: > Hello, > > I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. > The compilation of v4l-dvb works well (the kernel which is chosen is the > right), but when I try to modprobe em28xx, I get this : > > WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format > WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format > WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format > WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format > WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/videodev.ko): Invalid module format > WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format > WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/common/ir-common.ko): Invalid module format > FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- > r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format > > I have this error in my dmesg : > > [ 3903.465920] tveeprom: disagrees about version of symbol module_layout > > I join my .config file. > > What do I need to do ? > Thanks! > Usually this occurs when people are using the mrechberger version of the em28xx driver, and the symbols are in conflict with the rest of the v4l-dvb tree. You need to either switch to the v4l-dvb version of the driver (removing the .ko files for the mrec driver), or recompile and reinstall the mrec driver *after* you've installed the latest v4l-dvb code. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
