Hello people,
I'm trying to use compat-wireless-2009-09-14 for kernel 2.6.25.20.
It all compiles fine but inserting cfg80211 fails complaining about
symbols exported from rfkill_backport not being found, and inserting
rfkill_backport first also fails complaining about symbols exported
from cfg80211, kind of circular dependancy:
cfg80211.ko:
0001b570 T dev_set_name
.....
.....
U backport_rfkill_blocked
rfkill_backport.ko:
U dev_set_name
.........
......
000010a8 T backport_rfkill_blocked
How is this supposed to work?
I'm compiling for openwrt 8.09.1, mips platform, if it matters, and the
box for building openwrt is opensuse 10.3.
Thank you!
Nikolai ZHUBR
(Please CC me, I'm not subscribed)
Wednesday, September 16, 2009, 2:49:04 AM, Luis R. Rodriguez wrote:
> Check if the symbols you had issues with were indeed exported via
> EXPORT_SYMBOL() on the compat code (compat/*.c) or if whether they
> were defined via a header as an inline (compat/*.h).
As far as I can see, the symbols in question are not defined as inline:
compat/compat-2.6.26.c:
EXPORT_SYMBOL_GPL(dev_set_name);
compat/compat-2.6.26.h:
extern int dev_set_name(struct device *dev, const char *name, ...)
__attribute__((format(printf, 2, 3)));
net/rfkill/core.c:
EXPORT_SYMBOL(rfkill_blocked);
include/linux/rfkill-backport.h:
#if defined(CONFIG_RFKILL_BACKPORT) || defined(CONFIG_RFKILL_MODULE_BACKPORT)
.......
bool rfkill_blocked(struct rfkill *rfkill);
#else /* !RFKILL */
.......
static inline bool rfkill_blocked(struct rfkill *rfkill)
{
return false;
}
#endif /* RFKILL || RFKILL_MODULE */
config.mk:
ifdef CONFIG_COMPAT_WIRELESS_31
CONFIG_RFKILL_BACKPORT=m
......
Maybe module loader is supposed to do some magic with symbols, which openwrt
is missing? However, other modules work just as usual, there are no problems
with lib80211* for instance.
Nikolai
Hello Luis!
Wednesday, September 16, 2009, 4:17:40 AM, Luis R. Rodriguez wrote:
> They don't have to be exported and inlined, its one or the other. So
Yes, that's what I supposed.
> just ensure you your symbols you have conflicts with as
> EXPORT_SYMBOL() or defined in a header file as inline. You will
> obviously also need the header declaration if defined as an
> EXPORT_SYMBOL.
>From what I checked it all looks fine to me, except that there is
a circular dependency between cfg80211 and rfkill_backport (which
is confirmed by nm output I suppose). Is this circular dependency
intentional? Or, could it be avoided? (My understanding was that
as module loader loads one file at a time, it just have no way
to resolve such symbols, maybe I'm wrong on this)
Nikolai
> Luis
Hello Luis,
I've solved (kind of) symbol issues by simply commenting out
the CONFIG_RFKILL_BACKPORT=m (because I don't actually need
the rfkill thing yet). Finally mac80211 loads fine.
Now I'm getting an error when loading the RT61 driver:
PCI: Unable to reserve mem region #1:8000@40000000 for device 0000:00:02.0
rt2x00pci -> rt2x00pci_probe: Error - PCI request regions failed.
rt61pci: probe of 0000:00:02.0 failed with error -16
Any hints?
Wednesday, September 16, 2009, 4:17:40 AM, Luis R. Rodriguez wrote:
> On Tue, Sep 15, 2009 at 7:02 PM, Nikolai ZHUBR <[email protected]> wrote:
>> Wednesday, September 16, 2009, 2:49:04 AM, Luis R. Rodriguez wrote:
>>> Check if the symbols you had issues with were indeed exported via
>>> EXPORT_SYMBOL() on the compat code (compat/*.c) or if whether they
>>> were defined via a header as an inline (compat/*.h).
>> As far as I can see, the symbols in question are not defined as inline:
> They don't have to be exported and inlined, its one or the other. So
> just ensure you your symbols you have conflicts with as
> EXPORT_SYMBOL() or defined in a header file as inline. You will
> obviously also need the header declaration if defined as an
> EXPORT_SYMBOL.
> Luis
On Wed, Sep 16, 2009 at 10:14 AM, Nikolai ZHUBR <[email protected]> wrote:
> Hello Luis!
>
> Wednesday, September 16, 2009, 4:17:40 AM, Luis R. Rodriguez wrote:
>> They don't have to be exported and inlined, its one or the other. So
> Yes, that's what I supposed.
>> just ensure you your symbols you have conflicts with as
>> EXPORT_SYMBOL() or defined in a header file as inline. You will
>> obviously also need the header declaration if defined as an
>> EXPORT_SYMBOL.
> From what I checked it all looks fine to me, except that there is
> a circular dependency between cfg80211 and rfkill_backport (which
> is confirmed by nm output I suppose). Is this circular dependency
> intentional? Or, could it be avoided? (My understanding was that
> as module loader loads one file at a time, it just have no way
> to resolve such symbols, maybe I'm wrong on this)
Hmm, yes and no... insmod loads modules one at a time; but as long as
you run depmod, modprobe loads dependent modules automatically. I
don't know if modprobe works for circular dependency, but it probably
works correctly (since AFAIK, it reference-counts)?
On Tue, Sep 15, 2009 at 5:09 PM, Nikolai ZHUBR <[email protected]> wrote:
> Hello people,
>
> I'm trying to use compat-wireless-2009-09-14 for kernel 2.6.25.20.
Ah nice, finally some tester on 2.6.25 :D
So we never tested 2.6.25 on compat-wireless, I just got it to
compile, that's all. So what I think you need is to make sure the
symbols you are having issues with are either exported or included
inline on a header. Can you check that?
Luis
Wednesday, September 16, 2009, 6:24:11 PM, Hin-Tak Leung wrote:
>> From what I checked it all looks fine to me, except that there is
>> a circular dependency between cfg80211 and rfkill_backport (which
>> is confirmed by nm output I suppose). Is this circular dependency
>> intentional? Or, could it be avoided? (My understanding was that
>> as module loader loads one file at a time, it just have no way
>> to resolve such symbols, maybe I'm wrong on this)
> Hmm, yes and no... insmod loads modules one at a time; but as long as
> you run depmod, modprobe loads dependent modules automatically. I
> don't know if modprobe works for circular dependency, but it probably
> works correctly (since AFAIK, it reference-counts)?
Well, maybe modprobe is smart enough these days already, but openwrt
doesn't have it.
Anyway.
Circular dependency issue is now gone together with rfkill_backport
as I don't need rfkill at this point.
"Unable to reserve mem region" error was probably MIPS-related or
PCI-related and gone after cold reboot.
Now here is another:
in function wiphy_register (net/wireless/core.c):
device_add returns an error (-22)
Looks like some problem in mac80211<-->kernel_2.6.25 communication?
regards,
Nikolai
On Tue, Sep 15, 2009 at 5:46 PM, Nikolai ZHUBR <[email protected]> wrote:
> Hello Luis,
>
> Wednesday, September 16, 2009, 2:14:21 AM, Luis R. Rodriguez wrote:
>> Ah nice, finally some tester on 2.6.25 :D
>
>> So we never tested 2.6.25 on compat-wireless, I just got it to
>> compile, that's all. So what I think you need is to make sure the
>> symbols you are having issues with are either exported or included
>> inline on a header. Can you check that?
> Ok, could you be more specific? What should I do exactly? I'm not a
> great kernel expert actually. :/
Check if the symbols you had issues with were indeed exported via
EXPORT_SYMBOL() on the compat code (compat/*.c) or if whether they
were defined via a header as an inline (compat/*.h).
Luis
Hello Luis,
Wednesday, September 16, 2009, 2:14:21 AM, Luis R. Rodriguez wrote:
> Ah nice, finally some tester on 2.6.25 :D
> So we never tested 2.6.25 on compat-wireless, I just got it to
> compile, that's all. So what I think you need is to make sure the
> symbols you are having issues with are either exported or included
> inline on a header. Can you check that?
Ok, could you be more specific? What should I do exactly? I'm not a
great kernel expert actually. :/
> Luis
On Tue, Sep 15, 2009 at 7:02 PM, Nikolai ZHUBR <[email protected]> wrote:
> Wednesday, September 16, 2009, 2:49:04 AM, Luis R. Rodriguez wrote:
>> Check if the symbols you had issues with were indeed exported via
>> EXPORT_SYMBOL() on the compat code (compat/*.c) or if whether they
>> were defined via a header as an inline (compat/*.h).
> As far as I can see, the symbols in question are not defined as inline:
They don't have to be exported and inlined, its one or the other. So
just ensure you your symbols you have conflicts with as
EXPORT_SYMBOL() or defined in a header file as inline. You will
obviously also need the header declaration if defined as an
EXPORT_SYMBOL.
Luis