* external gpl kernel module build problem on 2.6.26.8-rt16
@ 2009-04-22 20:55 Mark Hounschell
2009-04-22 22:21 ` Frank Rowand
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hounschell @ 2009-04-22 20:55 UTC (permalink / raw)
To: linux-rt-users
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: external gpl kernel module build problem on 2.6.26.8-rt16
2009-04-22 20:55 external gpl kernel module build problem on 2.6.26.8-rt16 Mark Hounschell
@ 2009-04-22 22:21 ` Frank Rowand
2009-04-23 10:49 ` Mark Hounschell
0 siblings, 1 reply; 5+ messages in thread
From: Frank Rowand @ 2009-04-22 22:21 UTC (permalink / raw)
To: markh; +Cc: linux-rt-users
Mark Hounschell wrote:
> 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
#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.
-Frank Rowand
Sony Corporation of America
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: external gpl kernel module build problem on 2.6.26.8-rt16
2009-04-22 22:21 ` Frank Rowand
@ 2009-04-23 10:49 ` Mark Hounschell
2009-04-23 11:56 ` Uwe Kleine-König
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hounschell @ 2009-04-23 10:49 UTC (permalink / raw)
To: frank.rowand; +Cc: markh, linux-rt-users
Frank Rowand wrote:
> Mark Hounschell wrote:
>> 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
>
> #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.
>
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?
Thanks again
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: external gpl kernel module build problem on 2.6.26.8-rt16
2009-04-23 10:49 ` Mark Hounschell
@ 2009-04-23 11:56 ` Uwe Kleine-König
2009-04-23 15:14 ` Mark Hounschell
0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2009-04-23 11:56 UTC (permalink / raw)
To: Mark Hounschell; +Cc: frank.rowand, markh, linux-rt-users
Hello,
On Thu, Apr 23, 2009 at 06:49:03AM -0400, Mark Hounschell wrote:
> Frank Rowand wrote:
> > Mark Hounschell wrote:
> >> 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
> >
> > #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.
> >
>
> 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
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: external gpl kernel module build problem on 2.6.26.8-rt16
2009-04-23 11:56 ` Uwe Kleine-König
@ 2009-04-23 15:14 ` Mark Hounschell
0 siblings, 0 replies; 5+ messages in thread
From: Mark Hounschell @ 2009-04-23 15:14 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Mark Hounschell, frank.rowand, linux-rt-users
Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Apr 23, 2009 at 06:49:03AM -0400, Mark Hounschell wrote:
>> Frank Rowand wrote:
>>> Mark Hounschell wrote:
>>>> 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
>>> #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.
>>>
>> 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
>
Thanks, it turns out, to get the cpp output I had to modified the kernels
"scripts/Makefile.build" as described above. That got me something to look at.
Not really understanding all I was seeing I found is wasn't the spin_lock stuff
causing it but semaphore related stuff such as init_MUTEX/up/down etc. I think
I've got it worked out. Thanks for the help
Regards
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-04-23 15:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-22 20:55 external gpl kernel module build problem on 2.6.26.8-rt16 Mark Hounschell
2009-04-22 22:21 ` Frank Rowand
2009-04-23 10:49 ` Mark Hounschell
2009-04-23 11:56 ` Uwe Kleine-König
2009-04-23 15:14 ` Mark Hounschell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.