On Wed, Oct 7, 2009 at 4:22 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Wed, Oct 7, 2009 at 10:45 AM, John W. Linville
> <[email protected]> wrote:
>> On Wed, Oct 07, 2009 at 01:40:04AM -0400, Luis R. Rodriguez wrote:
>>> On Tue, Oct 6, 2009 at 11:39 PM, Hin-Tak Leung <[email protected]> wrote:
>>> > Between 2.6.30 and 2.6.31, linux/netdevice.h started
>>> > to include linux/ethtool.h (commit b1b67dd45a6b629eb41553856805aaa1614fbb83,
>>> > "net: factor out ethtool invocation of vlan/macvlan drivers"),
>>> > and commit 7508e486965b0af13984bc6d9da62a8d8f0dc5f9,
>>> > "cfg80211: add firmware and hardware version to wiphy", introduces
>>> > dependency of ETHTOOL_BUSINFO_LEN from linux/ethtool.h
>>> > to net/cfg80211.h .
>>>
>>> John's patch titled "cfg80211: fix compile error from missing
>>> ethtool.h" seems to address this upstream. I'll wait until he applies
>>> that to the tree.
>>
>> As Hin-Tak points-out, linux/netdevice.h is alreadying "doing the needful". :-)
>>
>> I'll just drop my patch and let this get sorted in compat-wireless.
>
> Heh ok applied, thanks.
>
> Luis
>
It is probably just a transient problem with recent activities - I had
a NULL pointer deref from loading rtl8187 of compat-wireless
v2.6.32-rc3-39563-g98c2609 -
BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
PGD 61c2b067 PUD 6246f067 PMD 0
Oops: 0000 [#1] SMP
...
Call Trace:
[<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
[<ffffffff813e53a5>] dev_ioctl+0x625/0x662
[<ffffffff813cfa45>] sock_ioctl+0x225/0x248
[<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
[<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
[<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
[<ffffffff81123d44>] sys_ioctl+0x65/0x9c
[<ffffffff81012082>] system_call_fastpath+0x16/0x1b
I'm sure whatever changes made this happen will go away soon, so I'll
just re-try in a few days... but if anybody knows what commit causes
this (and what fixes it!), I'd like to know.
On Thu, Oct 8, 2009 at 2:43 PM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>
>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>> defining is simply too small?
>>
>> That is apparently what is happening since compat-wireless ships
>> iw_handler.h. This is wrong, as wext functionality is built into the
>> kernel image so you can't use a newer header file with it.
>
> Dah, thanks for looking into this! This must've been there this way
> for ages and we hadn't noticed until now. This is now fixed, and a new
> tarball pushed out. I'll fix on the stable stuff as well, although I
> doubt the header has changed much except now.
>
> Luis
>
Thanks everybody! Works alright now, after 'compat-2.6: stop shipping
bleeding edge iw_handler.h' .
There are some harmless warnings from using the old header, but
otherwise it is working as it should:
CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
function ?__cfg80211_connect_result?:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
warning: passing argument 4 of ?wireless_send_event? discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ?char *? but argument is
of type ?const u8 *?
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:376:
warning: passing argument 4 of ?wireless_send_event? discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ?char *? but argument is
of type ?const u8 *?
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
function ?__cfg80211_roamed?:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:520:
warning: passing argument 4 of ?wireless_send_event? discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ?char *? but argument is
of type ?const u8 *?
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:527:
warning: passing argument 4 of ?wireless_send_event? discards
qualifiers from pointer target type
include/net/iw_handler.h:443: note: expected ?char *? but argument is
of type ?const u8 *?
Hin-Tak
On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>
>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>> defining is simply too small?
>
> That is apparently what is happening since compat-wireless ships
> iw_handler.h. This is wrong, as wext functionality is built into the
> kernel image so you can't use a newer header file with it.
Dah, thanks for looking into this! This must've been there this way
for ages and we hadn't noticed until now. This is now fixed, and a new
tarball pushed out. I'll fix on the stable stuff as well, although I
doubt the header has changed much except now.
Luis
On Thu, Oct 8, 2009 at 10:43 AM, John W. Linville
<[email protected]> wrote:
> On Thu, Oct 08, 2009 at 10:28:33AM -0400, Luis R. Rodriguez wrote:
>> On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
>> <[email protected]> wrote:
>> > On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
>> >> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>> >>
>> >>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>> >>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>> >>> defining is simply too small?
>> >>
>> >> That is apparently what is happening since compat-wireless ships
>> >> iw_handler.h. This is wrong, as wext functionality is built into the
>> >> kernel image so you can't use a newer header file with it.
>> >
>> > Dah, thanks for looking into this! This must've been there this way
>> > for ages and we hadn't noticed until now. This is now fixed, and a new
>> > tarball pushed out. I'll fix on the stable stuff as well, although I
>> > doubt the header has changed much except now.
>>
>> OK so iw_handler added the libipw pointer, so libipw and friends are
>> now messed up on compat-wireless. Do we care? I'll disable them for
>> now. Can't think of a way to backport this easily.
>>
>> CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
>> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
>> In function ‘ipw2100_alloc_device’:
>> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
>> error: ‘struct iw_public_data’ has no member named ‘libipw’
>> make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
>> Error 1
>
> - /* Structure managed by the in-kernel IEEE 802.11 layer */
> - struct ieee80211_device * ieee80211;
> + /* Legacy structure managed by the ipw2x00-specific IEEE 802.11 layer */
> + struct libipw_device * libipw;
>
> Really just a name change, FWIW...
oh ok thanks, thought the struct changed too -- then is be easy to backport
Luis
On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <[email protected]> wrote:
> It is probably just a transient problem with recent activities - I had
> a NULL pointer deref from loading rtl8187 of compat-wireless
> v2.6.32-rc3-39563-g98c2609 -
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
> IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
> PGD 61c2b067 PUD 6246f067 PMD 0
> Oops: 0000 [#1] SMP
> ...
> Call Trace:
> [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
> [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
> [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
> [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
> [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
> [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
> [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
> [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
>
> I'm sure whatever changes made this happen will go away soon, so I'll
> just re-try in a few days... but if anybody knows what commit causes
> this (and what fixes it!), I'd like to know.
>
Hiya, It looks like I last used compat-wireless successfully was on
25th (I am not saying it breaks after - I just haven't tried until
yesterday, possibly), and most of the recent changes are per-driver,
but there is a big code drop from Johannes dated 27th on 'wext:
refactor' . Changes from that or dependent changes?
On Thu, 2009-10-08 at 20:14 -0400, Luis R. Rodriguez wrote:
> > There are some harmless warnings from using the old header, but
> > otherwise it is working as it should:
> > CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
> > function ‘__cfg80211_connect_result’:
> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
> > warning: passing argument 4 of ‘wireless_send_event’ discards
> > qualifiers from pointer target type
> > include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> > of type ‘const u8 *’
> The last argument to wireless_send_event() was changed to be const on
> 2.6.32, cant think of a way to avoid this warning.
Yeah, it was never modified though so the warning is harmless.
johannes
On Wed, 2009-10-07 at 20:28 +0100, Hin-Tak Leung wrote:
> On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <[email protected]> wrote:
>
> > It is probably just a transient problem with recent activities - I had
> > a NULL pointer deref from loading rtl8187 of compat-wireless
> > v2.6.32-rc3-39563-g98c2609 -
> >
> > BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
> > IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
> > PGD 61c2b067 PUD 6246f067 PMD 0
> > Oops: 0000 [#1] SMP
> > ...
> > Call Trace:
> > [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
> > [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
> > [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
> > [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
> > [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
> > [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
> > [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
> > [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
> >
> > I'm sure whatever changes made this happen will go away soon, so I'll
> > just re-try in a few days... but if anybody knows what commit causes
> > this (and what fixes it!), I'd like to know.
> >
>
> Hiya, It looks like I last used compat-wireless successfully was on
> 25th (I am not saying it breaks after - I just haven't tried until
> yesterday, possibly), and most of the recent changes are per-driver,
> but there is a big code drop from Johannes dated 27th on 'wext:
> refactor' . Changes from that or dependent changes?
Probably -- but I don't see this problem on stock kernel and I'm not
sure what could be causing it for compat-wireless.
This will be the old copy of wext_ioctl_dispatch. It'd certainly help to
get disassembly/the source line of the oops.
johannes
On Thu, 2009-10-08 at 07:28 +0100, Hin-Tak Leung wrote:
> It looks like it is the 2nd of thes two lines around
> /usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
> which resulted in the null pointer dereference:
>
> if (index < dev->wireless_handlers->num_private)
> return dev->wireless_handlers->private[index];
Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
#ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
defining is simply too small? You can figure that out with debug info,
presumably, but I'm not entirely sure how. Actually maybe nm would tell
you too, if you look for cfg80211_wext_handler.
What I mean is this -- cfg80211 defines cfg80211_wext_handler:
const struct iw_handler_def cfg80211_wext_handler
.num_standard
.standard
.get_wireless_stats
but the core expects
.num_standard
.standard
.num_private
.num_private_args
.private
.private_args
.get_wireless_stats
as such .num_private ends up non-zero because it's shadowed
by .get_wireles_stats.
johannes
On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>
>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>> defining is simply too small?
>>
>> That is apparently what is happening since compat-wireless ships
>> iw_handler.h. This is wrong, as wext functionality is built into the
>> kernel image so you can't use a newer header file with it.
>
> Dah, thanks for looking into this! This must've been there this way
> for ages and we hadn't noticed until now. This is now fixed, and a new
> tarball pushed out. I'll fix on the stable stuff as well, although I
> doubt the header has changed much except now.
OK so iw_handler added the libipw pointer, so libipw and friends are
now messed up on compat-wireless. Do we care? I'll disable them for
now. Can't think of a way to backport this easily.
CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
In function ‘ipw2100_alloc_device’:
/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
error: ‘struct iw_public_data’ has no member named ‘libipw’
make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
Error 1
Luis
On Wed, Oct 7, 2009 at 11:01 PM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2009-10-07 at 20:28 +0100, Hin-Tak Leung wrote:
>> On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <[email protected]> wrote:
>>
>> > It is probably just a transient problem with recent activities - I had
>> > a NULL pointer deref from loading rtl8187 of compat-wireless
>> > v2.6.32-rc3-39563-g98c2609 -
>> >
>> > BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
>> > IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
>> > PGD 61c2b067 PUD 6246f067 PMD 0
>> > Oops: 0000 [#1] SMP
>> > ...
>> > Call Trace:
>> > [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
>> > [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
>> > [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
>> > [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
>> > [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
>> > [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
>> > [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
>> > [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
>> >
>> > I'm sure whatever changes made this happen will go away soon, so I'll
>> > just re-try in a few days... but if anybody knows what commit causes
>> > this (and what fixes it!), I'd like to know.
>> >
>>
>> Hiya, It looks like I last used compat-wireless successfully was on
>> 25th (I am not saying it breaks after - I just haven't tried until
>> yesterday, possibly), and most of the recent changes are per-driver,
>> but there is a big code drop from Johannes dated 27th on 'wext:
>> refactor' . Changes from that or dependent changes?
>
> Probably -- but I don't see this problem on stock kernel and I'm not
> sure what could be causing it for compat-wireless.
>
> This will be the old copy of wext_ioctl_dispatch. It'd certainly help to
> get disassembly/the source line of the oops.
>
> johannes
>
The crash came from the fedora koji kernel 2.6.30.8-67.fc11.x86_64 (+
bleed-edge compat-wireless), so John can probably correct me if I am
doing wrong or he can probably provide a better answer based on the
info.
I installed the debug packages kernel-debuginfo-2.6.30.8-67.fc11 ,
kernel-debuginfo-common-x86_64-2.6.30.8-67.fc11 , then dump the whole
thing to work out the address, before selecting the adress as:
objdump -l -d --start-address=0xffffffff81478153
--stop-address=0xffffffff81478440 -S
/usr/lib/debug/lib/modules/2.6.30.8-67.fc11.x86_64/vmlinux
It looks like it is the 2nd of thes two lines around
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
which resulted in the null pointer dereference:
if (index < dev->wireless_handlers->num_private)
return dev->wireless_handlers->private[index];
Is there a more clever way of working out the addresses? I guess I
should have just subtracted and added a few k off the crash message,
rather than dumping the whole kernel to work out the addresses...
On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
> defining is simply too small?
That is apparently what is happening since compat-wireless ships
iw_handler.h. This is wrong, as wext functionality is built into the
kernel image so you can't use a newer header file with it.
johannes
On Fri, Oct 9, 2009 at 1:05 AM, Johannes Berg <[email protected]> wrote:
> On Thu, 2009-10-08 at 20:14 -0400, Luis R. Rodriguez wrote:
>
>> > There are some harmless warnings from using the old header, but
>> > otherwise it is working as it should:
>> > CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
>> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
>> > function ‘__cfg80211_connect_result’:
>> > /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
>> > warning: passing argument 4 of ‘wireless_send_event’ discards
>> > qualifiers from pointer target type
>> > include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
>> > of type ‘const u8 *’
>
>> The last argument to wireless_send_event() was changed to be const on
>> 2.6.32, cant think of a way to avoid this warning.
>
> Yeah, it was never modified though so the warning is harmless.
OK so casting was enough to avoid these warnings, will use that for
older kernels.
#define wireless_send_event(a, b, c, d) wireless_send_event(a, b, c,
(char * ) d)
Luis
On Thu, Oct 8, 2009 at 7:22 PM, Hin-Tak Leung <[email protected]> wrote:
> On Thu, Oct 8, 2009 at 2:43 PM, Luis R. Rodriguez
> <[email protected]> wrote:
>> On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
>>> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
>>>
>>>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
>>>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
>>>> defining is simply too small?
>>>
>>> That is apparently what is happening since compat-wireless ships
>>> iw_handler.h. This is wrong, as wext functionality is built into the
>>> kernel image so you can't use a newer header file with it.
>>
>> Dah, thanks for looking into this! This must've been there this way
>> for ages and we hadn't noticed until now. This is now fixed, and a new
>> tarball pushed out. I'll fix on the stable stuff as well, although I
>> doubt the header has changed much except now.
>>
>> Luis
>>
>
> Thanks everybody! Works alright now, after 'compat-2.6: stop shipping
> bleeding edge iw_handler.h' .
>
> There are some harmless warnings from using the old header, but
> otherwise it is working as it should:
> CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.o
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
> function ‘__cfg80211_connect_result’:
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:370:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:376:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c: In
> function ‘__cfg80211_roamed’:
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:520:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
> /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/wireless/sme.c:527:
> warning: passing argument 4 of ‘wireless_send_event’ discards
> qualifiers from pointer target type
> include/net/iw_handler.h:443: note: expected ‘char *’ but argument is
> of type ‘const u8 *’
The last argument to wireless_send_event() was changed to be const on
2.6.32, cant think of a way to avoid this warning.
Luis
On Thu, Oct 08, 2009 at 10:28:33AM -0400, Luis R. Rodriguez wrote:
> On Thu, Oct 8, 2009 at 9:43 AM, Luis R. Rodriguez
> <[email protected]> wrote:
> > On Thu, Oct 8, 2009 at 7:50 AM, Johannes Berg <[email protected]> wrote:
> >> On Thu, 2009-10-08 at 11:51 +0200, Johannes Berg wrote:
> >>
> >>> Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
> >>> #ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
> >>> defining is simply too small?
> >>
> >> That is apparently what is happening since compat-wireless ships
> >> iw_handler.h. This is wrong, as wext functionality is built into the
> >> kernel image so you can't use a newer header file with it.
> >
> > Dah, thanks for looking into this! This must've been there this way
> > for ages and we hadn't noticed until now. This is now fixed, and a new
> > tarball pushed out. I'll fix on the stable stuff as well, although I
> > doubt the header has changed much except now.
>
> OK so iw_handler added the libipw pointer, so libipw and friends are
> now messed up on compat-wireless. Do we care? I'll disable them for
> now. Can't think of a way to backport this easily.
>
> CC [M] /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o
> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:
> In function ‘ipw2100_alloc_device’:
> /home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.c:6060:
> error: ‘struct iw_public_data’ has no member named ‘libipw’
> make[4]: *** [/home/mcgrof/devel/compat-wireless-2.6/drivers/net/wireless/ipw2x00/ipw2100.o]
> Error 1
- /* Structure managed by the in-kernel IEEE 802.11 layer */
- struct ieee80211_device * ieee80211;
+ /* Legacy structure managed by the ipw2x00-specific IEEE 802.11 layer */
+ struct libipw_device * libipw;
Really just a name change, FWIW...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.