external gpl kernel module build problem on 2.6.26.8-rt16

I get the following while trying to build this driver. What does it mean.

Building modules, stage 2.
MODPOST 1 modules
WARNING: "__bad_func_type" [/local/work/markh/pci5565-linux/driver/rfm2g.ko] undefined!

Then obviously the module doesn't load for the same reason.

When I grep the kernel for bad_func_type all I see is

include/linux/rt_lock.h:192:extern int __bad_func_type(void); include/linux/pickop.h:8:extern int __bad_func_type(void);

include/linux/pickop.h:16:      else __bad_func_type();
                \

include/linux/pickop.h:27: else __ret = __bad_func_type();

Any help or hints would be appreciated

Thanks in advance
Mark

Quoted 13 lines · Mark Hounschell

I get the following while trying to build this driver. What does it mean.

Building modules, stage 2.
MODPOST 1 modules
WARNING: "__bad_func_type" [/local/work/markh/pci5565-linux/driver/rfm2g.ko] undefined!

Then obviously the module doesn't load for the same reason.

When I grep the kernel for bad_func_type all I see is

include/linux/rt_lock.h:192:extern int __bad_func_type(void); include/linux/pickop.h:8:extern int __bad_func_type(void);

Quoted 8 lines

include/linux/pickop.h:16:      else __bad_func_type();
                \

include/linux/pickop.h:27: else __ret = __bad_func_type();

Any help or hints would be appreciated

Thanks in advance
Mark

#define PICK_FUNCTION(type1, type2, func1, func2, arg0, ...)            \
do {                                                                    \
        if (PICK_TYPE_EQUAL((arg0), type1))                             \
                func1((type1)(arg0), ##__VA_ARGS__);                    \
        else if (PICK_TYPE_EQUAL((arg0), type2))                        \
                func2((type2)(arg0), ##__VA_ARGS__);                    \
        else __bad_func_type();                                         \

} while (0)

And PICK_FUNCTION_RET() uses the same technique.

Something that invokes PICK_FUNCTION() or PICK_FUNCTION_RET() is passing in an arg0 that is not type1 and is not type2.

One easy way to figure out what is invoking PICK_FUNCTION()/PICK_FUNCTION_RET() is to look at the output from the cpp of your driver. The method I usually use is to add the flags "-C -E" to my compile command (and remove "-c"). Then search the cpp output for __bad_func_type.

Quoted 34 lines · Frank Rowand

Quoted 13 lines · Mark Hounschell

I get the following while trying to build this driver. What does it mean.

Building modules, stage 2.
MODPOST 1 modules
WARNING: "__bad_func_type" [/local/work/markh/pci5565-linux/driver/rfm2g.ko] undefined!

Then obviously the module doesn't load for the same reason.

When I grep the kernel for bad_func_type all I see is

include/linux/rt_lock.h:192:extern int __bad_func_type(void); include/linux/pickop.h:8:extern int __bad_func_type(void);

Quoted 8 lines

include/linux/pickop.h:16:      else __bad_func_type();
                \

include/linux/pickop.h:27: else __ret = __bad_func_type();

Any help or hints would be appreciated

Thanks in advance
Mark

#define PICK_FUNCTION(type1, type2, func1, func2, arg0, ...)            \
do {                                                                    \
        if (PICK_TYPE_EQUAL((arg0), type1))                             \
                func1((type1)(arg0), ##__VA_ARGS__);                    \
        else if (PICK_TYPE_EQUAL((arg0), type2))                        \
                func2((type2)(arg0), ##__VA_ARGS__);                    \
        else __bad_func_type();                                         \

} while (0)

And PICK_FUNCTION_RET() uses the same technique.

Quoted 8 lines

Something that invokes PICK_FUNCTION() or PICK_FUNCTION_RET() is passing in an arg0 that is not type1 and is not type2.

One easy way to figure out what is invoking PICK_FUNCTION()/PICK_FUNCTION_RET() is to look at the output from the cpp of your driver. The method I usually use is to add the flags "-C -E" to my compile command (and remove "-c"). Then search the cpp output for __bad_func_type.

Thanks for the pointer. How might one do this using the kernel build system though? Isn't the compile command used actually the kernels compile command? Can I assume this would entail modifying the kernels top Makefile in some way?

Hello,

Quoted 37 lines · Mark Hounschell

Quoted 36 lines · Frank Rowand

Quoted 13 lines · Mark Hounschell

I get the following while trying to build this driver. What does it mean.

Building modules, stage 2.
MODPOST 1 modules
WARNING: "__bad_func_type" [/local/work/markh/pci5565-linux/driver/rfm2g.ko] undefined!

Then obviously the module doesn't load for the same reason.

When I grep the kernel for bad_func_type all I see is

include/linux/rt_lock.h:192:extern int __bad_func_type(void); include/linux/pickop.h:8:extern int __bad_func_type(void);

Quoted 8 lines

include/linux/pickop.h:16:      else __bad_func_type();
                \

include/linux/pickop.h:27: else __ret = __bad_func_type();

Any help or hints would be appreciated

Thanks in advance
Mark

#define PICK_FUNCTION(type1, type2, func1, func2, arg0, ...)            \
do {                                                                    \
        if (PICK_TYPE_EQUAL((arg0), type1))                             \
                func1((type1)(arg0), ##__VA_ARGS__);                    \
        else if (PICK_TYPE_EQUAL((arg0), type2))                        \
                func2((type2)(arg0), ##__VA_ARGS__);                    \
        else __bad_func_type();                                         \

} while (0)

And PICK_FUNCTION_RET() uses the same technique.

Something that invokes PICK_FUNCTION() or PICK_FUNCTION_RET() is passing in an arg0 that is not type1 and is not type2.

Quoted 8 lines

Quoted 5 lines

One easy way to figure out what is invoking PICK_FUNCTION()/PICK_FUNCTION_RET() is to look at the output from the cpp of your driver. The method I usually use is to add the flags "-C -E" to my compile command (and remove "-c"). Then search the cpp output for __bad_func_type.

Thanks for the pointer. How might one do this using the kernel build system though? Isn't the compile command used actually the kernels compile command? Can I assume this would entail modifying the kernels top Makefile in some way?

You can compile using

make V=1

With that you can see the complete commands. Then just take the last command (i.e. the failing one) and do s/-c/-C -E/.

BTW, my guess is that it has to do with spinlocks and you do something like:

	spinlock_t lock;

	....

	spin_lock_irqsave(lock, flags);

instead of

	spin_lock_irqsave(&lock, flags);

Best regards
Uwe