Re: DWL 650+ wireless card with SuSE 8.1

At 10:53 PM 6/8/2003 -0700, you wrote:
>Anybody has any success with above card? I tried with this binary
>                 |
>/lib/modules/2.4.19-4GB/pcmcia/acx100sta.o: kernel-module version mismatch
>         /lib/modules/2.4.19-4GB/pcmcia/acx100sta.o was compiled for kernel
>version 2.4.19-16mdkcustom        while this kernel is version 2.4.19-4GB.
>                 |
>I followed his advice and used the closest match and renamed, but:((((
>Any suggestion how to resolve this kernel mismatch?

The short story: You need to either compile the module, recompile the 
kernel, or bop the author of the module over the head for sloppiness.

The long story (hoping it makes sense):
Every Linux distro names the kernel in a specific way (which you can find 
out by running 'uname -a' and checking the kernel version 
portion).  Somewhere in the kernel config file, there is a parameter, the 
name of which escapes me, which can be set so that all the binaries 
resulting from the compile are "married" to that specific kernel (can 
someone else please identify the flag in question, please?).  This kind of 
dependency has its pros and cons, which should be readily apparent as you 
start relating the problem to this narrative.  But I digress...

You may recall from your kernel-building experience (or if not, then from 
reading the kernel compilation documentation) that before you start the 
build process, you're supposed to go into the kernel's top-level makefile, 
and check/edit a few parameters.  One group of these parameters is used to 
"brand" the kernel, and of this group, you are supposed to modify the one 
called EXTRAVERSION.  By doing this, you can create multiple, differing 
kernels without causing one to overwrite the other (and if something goes 
wrong, not trash your whole system when the result is a dud kernel).

The module you're trying to use was built on a Mandrake system, and you're 
running a SuSE one.  In real terms, this should not be an issue.  However, 
the person who built the module you are trying to use, set the 
aforementioned "marriage" parameter in the kernel config file (.config) to 
YES.  In essence, that means that any modules built with .config will only 
work with the kernel resulting from that build.

Lets put this together in the picture you presented:

You're running SuSE, and the makefile that was used to produce the default 
kernel had "4GB" set as the value of the EXTRAVERSION parameter.  This, 
coupled with the rest of the versioning parameters, is what produces the 
2.4.19-4GB identifier returned by uname -a.

We can tell that the module was built on a Mandrake based system because 
Mandrake's default value for EXTRAVERSION always contains a build number 
plus "mdk" (eg. 16mdk).  The person who built the module you're trying to 
use, changed EXTRAVERSION from 16mdk to 16mdkcustom (ostensibly so that 
s/he can test compile without destroying a 'known-to-work' kernel).

However, in the process of preparing for this test kernel, the person also 
enabled the afforementioned version dependency flag in the kernel's .config 
file (again, ostensibly to test things), thereby forcibly marrying that 
module to work with that specific kernel, and only that kernel.  What the 
person *should* have done is to recompile with that flag turned off, so 
that the module is indeed portable.

If I haven't lost you yet, here's the fix choices:

CHOICE 1: Get and install the source for the module.  ***Make sure the 
kernel version dependency flag is turned off***.  Compile the module and 
install it.

CHOICE 2: Edit the kernel's top-level makefile, and set the EXTRAVERSION 
parameter to "16mdkcustom".  Then build and install this kernel.  Once this 
new kernel is installed, the module should work without a hitch.

CHOICE 3: Contact the module's author and bop the person over the 
head.  Ask the person to build the kernel with that dependency flag turned 
off (tip: wait till you have the new module before you do any bopping <grin>)

FWIW: Enabling that "marriage" flag is good for making sure certain things 
only work with specific kernel builds.  In short, it is great for 
testing.  But it is bad when binaries are released into the wild, because 
anyone who is running a custom kernel will not be able to use the binary, 
even if the base version and/or distro is the same one as was used by the 
author.  Kernel v2.4.19-a is NOT the same as v2.4.19-b despite both being 
kernel version 2.4.19.  That marriage flag causes them to be treated as 
totally different beasts since the ENTIRE string is what is being used for 
checking purposes.


  .-------------------------------------------------------------------------.
  |   George Silberstern - Web, Internet and Systems Solutions Consultant   |
  :=========================================================================:
  | Personal - Web: http://www.netaxs.com/~graf *** eMail: [email protected]  |
  | Business - Web: http://grafs.net/           *** eMail: [email protected]    |
  `-------------------------------------------------------------------------'