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