2008-09-26 18:04:19

by Davide Pesavento

[permalink] [raw]
Subject: wireless-testing modpost failure

Hi!

I just pulled from wireless-testing git tree and I'm now hitting this
build error:

Building modules, stage 2.
MODPOST 216 modules
ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

My kernel config:

$ grep CONFIG_MAC80211 .config
CONFIG_MAC80211=m
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUG_MENU=y
# CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
CONFIG_MAC80211_NOINLINE=y
CONFIG_MAC80211_VERBOSE_DEBUG=y
# CONFIG_MAC80211_HT_DEBUG is not set
# CONFIG_MAC80211_TKIP_DEBUG is not set
# CONFIG_MAC80211_IBSS_DEBUG is not set
CONFIG_MAC80211_VERBOSE_PS_DEBUG=y
# CONFIG_MAC80211_VERBOSE_SPECT_MGMT_DEBUG is not set
# CONFIG_MAC80211_HWSIM is not set

Regards,
Davide


2008-09-27 12:34:59

by Davide Pesavento

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

2008/9/27 Johannes Berg <[email protected]>:
> On Sat, 2008-09-27 at 12:54 +0200, Davide Pesavento wrote:
>
>> > Ok... I can't reproduce it. Can you turn off CONFIG_MAC80211_NOINLINE
>> > and see if that helps?
>> >
>>
>> Yes, it works without CONFIG_MAC80211_NOINLINE.
>>
>> I guess that it fails because gcc doesn't optimize out
>> CALL_RXH(ieee80211_rx_h_mesh_fwding) in
>> ieee80211_invoke_rx_handlers(), even if the comparison is always
>> false... (btw, there's an extra semicolon at the end of that line).
>
> Ok, strange. I suggest we simply remove the debug_noinline from
> ieee80211_rx_h_mesh_fwding then, want to do a patch?

Why not putting an #ifdef CONFIG_MAC80211_MESH at the beginning of
ieee80211_rx_h_mesh_fwding instead?

Thanks,
Davide

2008-09-27 08:38:21

by Johannes Berg

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Fri, 2008-09-26 at 22:25 +0200, Davide Pesavento wrote:
> 2008/9/26 Johannes Berg <[email protected]>:
> > On Fri, 2008-09-26 at 15:00 -0400, John W. Linville wrote:
> >
> >> > Building modules, stage 2.
> >> > MODPOST 216 modules
> >> > ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
> >> > ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
> >
> > Davide, can you tell me what file/line it fails in?
> >
>
> How can I tell you that?

Good question. I was thinking the linker would complain at some earlier
point too, but I'll just try to reproduce it myself.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-26 19:00:39

by John W. Linville

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Fri, Sep 26, 2008 at 08:04:18PM +0200, Davide Pesavento wrote:
> Hi!
>
> I just pulled from wireless-testing git tree and I'm now hitting this
> build error:
>
> Building modules, stage 2.
> MODPOST 216 modules
> ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
> ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> My kernel config:
>
> $ grep CONFIG_MAC80211 .config
> CONFIG_MAC80211=m
> CONFIG_MAC80211_RC_PID=y
> CONFIG_MAC80211_RC_DEFAULT_PID=y
> CONFIG_MAC80211_RC_DEFAULT="pid"
> # CONFIG_MAC80211_MESH is not set

Turn this on to make it build again.

I'm not sure what the best long-term solution is. Should we define
empty versions of those functions when that config option is unset?
Or just make the whole block subject to that config option?

John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.

2008-09-26 20:25:13

by Davide Pesavento

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

2008/9/26 Johannes Berg <[email protected]>:
> On Fri, 2008-09-26 at 15:00 -0400, John W. Linville wrote:
>
>> > Building modules, stage 2.
>> > MODPOST 216 modules
>> > ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
>> > ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
>
> Davide, can you tell me what file/line it fails in?
>

How can I tell you that?

>> I'm not sure what the best long-term solution is. Should we define
>> empty versions of those functions when that config option is unset?
>> Or just make the whole block subject to that config option?
>
> The weird thing is that the block in tx.c is already ifdef'ed out and
> the block in rx.c should be optimised out entirely.
>
> johannes
>

Thanks,
Davide

2008-09-27 11:48:15

by Johannes Berg

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Sat, 2008-09-27 at 12:54 +0200, Davide Pesavento wrote:

> > Ok... I can't reproduce it. Can you turn off CONFIG_MAC80211_NOINLINE
> > and see if that helps?
> >
>
> Yes, it works without CONFIG_MAC80211_NOINLINE.
>
> I guess that it fails because gcc doesn't optimize out
> CALL_RXH(ieee80211_rx_h_mesh_fwding) in
> ieee80211_invoke_rx_handlers(), even if the comparison is always
> false... (btw, there's an extra semicolon at the end of that line).

Ok, strange. I suggest we simply remove the debug_noinline from
ieee80211_rx_h_mesh_fwding then, want to do a patch?

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-27 13:17:04

by Johannes Berg

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Sat, 2008-09-27 at 14:34 +0200, Davide Pesavento wrote:

> > Ok, strange. I suggest we simply remove the debug_noinline from
> > ieee80211_rx_h_mesh_fwding then, want to do a patch?
>
> Why not putting an #ifdef CONFIG_MAC80211_MESH at the beginning of
> ieee80211_rx_h_mesh_fwding instead?

I'd like to avoid #ifdefs wherever we can because that way we get to
compile most of the code even when not having all config options on,
which helps when doing patches.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-27 09:20:35

by Johannes Berg

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Sat, 2008-09-27 at 10:38 +0200, Johannes Berg wrote:

> > >> > Building modules, stage 2.
> > >> > MODPOST 216 modules
> > >> > ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
> > >> > ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
> > >
> > > Davide, can you tell me what file/line it fails in?
> > >
> >
> > How can I tell you that?
>
> Good question. I was thinking the linker would complain at some earlier
> point too, but I'll just try to reproduce it myself.

Ok... I can't reproduce it. Can you turn off CONFIG_MAC80211_NOINLINE
and see if that helps?

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part

2008-09-27 10:54:10

by Davide Pesavento

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

2008/9/27 Johannes Berg <[email protected]>:
> On Sat, 2008-09-27 at 10:38 +0200, Johannes Berg wrote:
>
>> > >> > Building modules, stage 2.
>> > >> > MODPOST 216 modules
>> > >> > ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
>> > >> > ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!
>> > >
>> > > Davide, can you tell me what file/line it fails in?
>> > >
>> >
>> > How can I tell you that?
>>
>> Good question. I was thinking the linker would complain at some earlier
>> point too, but I'll just try to reproduce it myself.
>
> Ok... I can't reproduce it. Can you turn off CONFIG_MAC80211_NOINLINE
> and see if that helps?
>

Yes, it works without CONFIG_MAC80211_NOINLINE.

I guess that it fails because gcc doesn't optimize out
CALL_RXH(ieee80211_rx_h_mesh_fwding) in
ieee80211_invoke_rx_handlers(), even if the comparison is always
false... (btw, there's an extra semicolon at the end of that line).

Regards,
Davide

2008-09-26 19:30:22

by Johannes Berg

[permalink] [raw]
Subject: Re: wireless-testing modpost failure

On Fri, 2008-09-26 at 15:00 -0400, John W. Linville wrote:

> > Building modules, stage 2.
> > MODPOST 216 modules
> > ERROR: "mpp_path_lookup" [net/mac80211/mac80211.ko] undefined!
> > ERROR: "mpp_path_add" [net/mac80211/mac80211.ko] undefined!

Davide, can you tell me what file/line it fails in?

> I'm not sure what the best long-term solution is. Should we define
> empty versions of those functions when that config option is unset?
> Or just make the whole block subject to that config option?

The weird thing is that the block in tx.c is already ifdef'ed out and
the block in rx.c should be optimised out entirely.

johannes


Attachments:
signature.asc (836.00 B)
This is a digitally signed message part