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@xxxxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
