Please hold all questions until I am done with this email. Thank you.
We are pleased to announce the availability of a new driver for the
Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
uses the new d80211 subsystem previously only available as part of the
wireless-dev tree.
You can find the new driver, and additional information about it, here:
http://intellinuxwireless.org/iwlwifi.
Within the new driver package are sources which we plan to submit for
kernel inclusion as well as scripts and patches which create a version
of the driver which can be loaded into kernels based on 2.6.18 and newer
(provided you have installed the d80211 subsystem as well) The README
document can walk you through pretty quickly.
Since a lot of our users are not able to move to the latest versions of
the Linux kernel, we have put together a d80211 package allowing the
installation of the d80211 subsystem into an existing kernel image
without the need to migrate to wireless-dev, or upgrade to a newer
kernel at all (assuming you are using 2.6.18 or newer).
You can find that package at:
http://intellinuxwireless.org/d80211
Ok. Now... any questions?
Thanks,
James / Intel Corporation
Hesse, Christian wrote:
> On Saturday 10 February 2007 14:23, Hesse, Christian wrote:
>> On Friday 09 February 2007 22:12, James Ketrenos wrote:
>>> We are pleased to announce the availability of a new driver for the
>>> Intel PRO/Wireless 3945ABG Network Connection adapter.
...
> Oh, I forgot one note: "make patch_kernel" is terribly broken. Any chance to
> get this fixed soon?
I've put up a new version of iwlwifi (0.0.6) with significant changes to
the patch_kernel scripts as well as including Pavel's patch to KSRC.
I performed some build testing with 2.6.18 and wireless-dev @ commit
f66e5aaa88c1c0a7ee6c6427d6535ed8afd35427 (Jan 8).
http://intellinuxwireless.org/?n=downloads
Let me know if it is still breaking.
Thanks,
James
On Sat, 2007-02-10 at 14:23 +0100, Hesse, Christian wrote:
> The driver generates two network devices. The second one is for promicious
> mode? Is there any chance to disable the interface?
The second one is the so-called "master" interface which is used for QoS
stuff. We're working on hiding it until a better solution for QoS
evolves (which has been a plan for a while.)
johannes
BUilding with sparse shows lots of warnings.
$ make C=3D1
Checking kernel compatibility in:
/lib/modules/2.6.20.1/source
* Kernel supports required features for 'tip' version.
Building compatibility version in 'compatible/' directory:
Copying compatible/ from origin/...done
make -C /lib/modules/2.6.20.1/build M=3D/home/shemminger/src/iwlwifi-0.=
0.8=20
modules
make[1]: Entering directory `/home/shemminger/kernel/linux-2.6.20.1'
CHECK /home/shemminger/src/iwlwifi-0.0.8/compatible/base.c
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11115:12: warning:=
=20
function 'ipw_rate_scale_clear_window' with external linkage has defini=
tion
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11352:12: warning:=
=20
function 'ipw_collect_tx_data' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11480:12: warning:=
=20
function 'ipw_convert_to_rate_index' with external linkage has definiti=
on
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11665:12: warning:=
=20
function 'ipw_convert_to_phy_index' with external linkage has definitio=
n
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11677:30: warning:=
=20
function 'ipw_get_lowest_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11692:12: warning:=
=20
function 'ipw_get_adjacent_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:1522:11: warning:=20
Using plain integer as NULL pointer
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10004:16: warning:=
=20
Using plain integer as NULL pointer
CC [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/base.o
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: In function=20
=1B$-1=F2=F8ipw_rx_handle=F2=F9:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8175: warning:=20
unused variable =1B$-1=F2=F8sleep=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8195: warning:=20
unused variable =1B$-1=F2=F8beacon=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8227: warning:=20
unused variable =1B$-1=F2=F8notif=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8259: warning:=20
unused variable =1B$-1=F2=F8notif=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: At top level:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3889: warning:=20
=1B$-1=F2=F8ipw_set_rxon_conf=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2523: warning:=20
=1B$-1=F2=F8ipw_rate_ieee2index=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2577: warning:=20
=1B$-1=F2=F8ipw_check_rx_config_cmd=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3628: warning:=20
=1B$-1=F2=F8ipw_setup_rxon_timing=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:6931: warning:=20
=1B$-1=F2=F8ipw_send_qos_params_command=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:7964: warning:=20
=1B$-1=F2=F8get_tx_fail_reason=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8637: warning:=20
=1B$-1=F2=F8ipw_get_rate_by_rssi=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10371: warning:=20
=1B$-1=F2=F8d_hw_scan=F2=F9 defined but not used
LD [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "ieee80211_rx_irqsafe"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hwmode"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_unregister_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_scan_completed"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_get"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_register"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_netif_oper"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status_irqsafe"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen_from_skb"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_unregister"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_alloc_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_free_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_put"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
CC /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.mod.o8$=
=20
make C=3D1
Checking kernel compatibility in:
/lib/modules/2.6.20.1/source
* Kernel supports required features for 'tip' version.
Building compatibility version in 'compatible/' directory:
Copying compatible/ from origin/...done
make -C /lib/modules/2.6.20.1/build M=3D/home/shemminger/src/iwlwifi-0.=
0.8=20
modules
make[1]: Entering directory `/home/shemminger/kernel/linux-2.6.20.1'
CHECK /home/shemminger/src/iwlwifi-0.0.8/compatible/base.c
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11115:12: warning:=
=20
function 'ipw_rate_scale_clear_window' with external linkage has defini=
tion
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11352:12: warning:=
=20
function 'ipw_collect_tx_data' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11480:12: warning:=
=20
function 'ipw_convert_to_rate_index' with external linkage has definiti=
on
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11665:12: warning:=
=20
function 'ipw_convert_to_phy_index' with external linkage has definitio=
n
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11677:30: warning:=
=20
function 'ipw_get_lowest_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:11692:12: warning:=
=20
function 'ipw_get_adjacent_rate' with external linkage has definition
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:1522:11: warning:=20
Using plain integer as NULL pointer
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10004:16: warning:=
=20
Using plain integer as NULL pointer
CC [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/base.o
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: In function=20
=1B$-1=F2=F8ipw_rx_handle=F2=F9:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8175: warning:=20
unused variable =1B$-1=F2=F8sleep=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8195: warning:=20
unused variable =1B$-1=F2=F8beacon=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8227: warning:=20
unused variable =1B$-1=F2=F8notif=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8259: warning:=20
unused variable =1B$-1=F2=F8notif=F2=F9
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c: At top level:
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3889: warning:=20
=1B$-1=F2=F8ipw_set_rxon_conf=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2523: warning:=20
=1B$-1=F2=F8ipw_rate_ieee2index=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:2577: warning:=20
=1B$-1=F2=F8ipw_check_rx_config_cmd=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:3628: warning:=20
=1B$-1=F2=F8ipw_setup_rxon_timing=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:6931: warning:=20
=1B$-1=F2=F8ipw_send_qos_params_command=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:7964: warning:=20
=1B$-1=F2=F8get_tx_fail_reason=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:8637: warning:=20
=1B$-1=F2=F8ipw_get_rate_by_rssi=F2=F9 defined but not used
/home/shemminger/src/iwlwifi-0.0.8/compatible/base.c:10371: warning:=20
=1B$-1=F2=F8d_hw_scan=F2=F9 defined but not used
LD [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "ieee80211_rx_irqsafe"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hwmode"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_unregister_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_scan_completed"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_get"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_register"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_netif_oper"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_tx_status_irqsafe"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_get_hdrlen_from_skb"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_rate_control_unregister"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_register_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_alloc_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "ieee80211_free_hw"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
WARNING: "sta_info_put"=20
[/home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko] undefined!
CC /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.mod.o
LD [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko
make[1]: Leaving directory `/home/shemminger/kernel/linux-2.6.20.1'
LD [M] /home/shemminger/src/iwlwifi-0.0.8/compatible/iwlwifi.ko
make[1]: Leaving directory `/home/shemminger/kernel/linux-2.6.20.1'
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote:
> On 2/13/07, Ismail D=F6nmez <[email protected]> wrote:
> > Tried this is on a patched 2.6.20 kernel with ipw3945 device and it
> > always puts the card in 802.11a mode instead of 802.11bg mode.
> >
> > Ideas?
>
> Before running "iwconfig wlan0 channel 8", the card is set to
> 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the
> channel, it sets to 802.11b mode, and I can't find a way to change
> from 11Mb/s to 54MB/s.
>
> "iwlist eth0 rate" only show up to 11Mb/s.
>
> So, my problem is the card is always in 802.11b mode.
So I guess there is a common problem with a/bg modes?
Regards,
ismail
Hi!
> Please hold all questions until I am done with this
> email. Thank you.
>
> We are pleased to announce the availability of a new
> driver for the Intel PRO/Wireless 3945ABG Network
> Connection adapter. This new driver uses the new d80211
> subsystem previously only available as part of the
> wireless-dev tree.
>
> You can find the new driver, and additional information
> about it, here:
>
> http://intellinuxwireless.org/iwlwifi.
...
> You can find that package at:
>
> http://intellinuxwireless.org/d80211
>
> Ok. Now... any questions?
Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
but it did not contain d80211 stack. I'm now downloading wireless-dev
git tree...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> BUilding with sparse shows lots of warnings.
You seem to be the lucky one, able to actually compile the
beast. Could you run diff against vanilla and post it somewhere?
"Normal" installation procedure has too many steps in my eyes, and
combined git tree is not available, so I was waiting for merge at
least into -wirelessdev tree.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 2007-02-09 at 14:18 -0800, James Ketrenos wrote:
> Updated and tested 'git clone' and its working now (I use cg-clone)
Thanks. It's working for me too.
> > grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file
> > or directory
> >
> > Apparently it should be looking into /lib/modules/2.6.20/source as well.
> > That was a problem with the official ipw3945 drivers as well.
>
> I'll look into it. Does it work if you explicitly set KSRC to point to
> your kernel sources?
>
> $ make KSRC=/lib/modules/2.6.20/source
That works. At least it doesn't report errors. But it doesn't create a
single object file. Anyway, I'm cheating here - my kernel does include
d80211 support.
"build" is still hardcoded in iwlwifi's Makefile. It's interesting that
D80211_INC is defined twice in Makefile. That must be wrong.
I'm going to try everything on a more traditional build in the tree and
without d80211. And then I'll try to break some assumptions.
--
Regards,
Pavel Roskin
Hello!
[I'm trimming the cc: a little bit]
On Sat, 2007-02-10 at 14:23 +0100, Hesse, Christian wrote:
> On Friday 09 February 2007 22:12, James Ketrenos wrote:
> > We are pleased to announce the availability of a new driver for the
> > Intel PRO/Wireless 3945ABG Network Connection adapter.
>
> Wow, great news on this rainy saturday! ;-)
>
> The driver works perfectly, I'm writing this mail via wireless link. However
> there are two things to note:
>
> The driver generates two network devices. The second one is for promicious
> mode? Is there any chance to disable the interface? ifrename renamed the
> wrong one to wlan0 and I had to tell my system to use eth1 for the wireless
> connection.
I think one of the devices is wmaster0. It's better that you just
ignore it. The effort is already underway to make that interface
hidden.
In the meantime, you can use the "arp" condition in /etc/iftab.
Ethernet is 1 (that includes the original wlan0), IEEE 802.11 is 801
(that's the master devices and devices in monitor mode). For example:
wifi* arp 801
eth* arp 1
> Second problem is that I can't unload the module. I get the message "FATAL:
> Module iwlwifi is in use." even if both interfaces are down.
I cannot reproduce this problem. Please see the output of "lsmod" and
the kernel log for possible oopses.
--
Regards,
Pavel Roskin
Hello!
On Sun, 2007-02-11 at 14:17 +0100, Hesse, Christian wrote:
> lsmod shows a use count of 4294967295 (2^32 - 1), no oopses or the like. This
> is reproducable all the time.
Although I cannot reproduce the problem (I'm on current wireless-dev),
here's my interpretation.
The iwlwifi driver includes both a driver and a rate control algorithm.
It passes THIS_MODULE (i.e. a handle to itself) to the generic rate
control code, which locks the caller i.e. iwlwifi. Therefore, iwlwifi
has locked itself in memory.
To counteract that, the driver "puts" the module, i.e. decreases its use
count after the rate control is registered. Conversely, the module
"gets" itself when the rate control is unregistered.
One thing that is clearly wrong is that try_module_get() comes after
ieee80211_rate_control_unregister(), not before. This means that the
use count would go negative between those calls. If the kernel starts
checking for this, the driver is in trouble.
Further, why do we need this self-locking/unlocking trick? The driver
can just set priv->rate_control.module to NULL and prevent self-locking.
It would only make sense to put THIS_MODULE there is the rate control
were implemented as a separate module, which it probably a good idea in
the long term.
But a simple fix would be just to get rid of all references to
THIS_MODULE and let the kernel do the right thing.
Most likely, your kernel doesn't use the priv->rate_control.module field
to lock the module, so it would help in your case.
Please try this patch:
diff --git a/origin/base.c b/origin/base.c
index 8f97491..62751e5 100644
--- a/origin/base.c
+++ b/origin/base.c
@@ -9771,8 +9771,6 @@ static void ipw_bg_alive_start(struct work_struct *work)
return;
}
- module_put(THIS_MODULE);
-
mutex_lock(&priv->mutex);
priv->netdev_registered = 1;
@@ -11966,7 +11964,7 @@ static struct ieee80211_rate *ipw_get_tx_rate(void *priv_rate,
static char* rate_scale_name = "iwlwifi rate-scale";
void ipw_set_rate_scale_handlers(struct ipw_priv *priv)
{
- priv->rate_control.module = THIS_MODULE;
+ priv->rate_control.module = NULL;
priv->rate_control.name = rate_scale_name;
priv->rate_control.tx_status = ipw_rate_scale_tx_resp_handle;
priv->rate_control.get_rate = ipw_get_tx_rate;
@@ -12338,7 +12336,6 @@ static void ipw_pci_remove(struct pci_dev *pdev)
if (priv->netdev_registered) {
ieee80211_rate_control_unregister(&priv->rate_control);
- try_module_get(THIS_MODULE);
ieee80211_unregister_hw(priv->ieee);
}
--
Regards,
Pavel Roskin
On Sat, Feb 10, 2007 at 12:53:51PM -0500, Pavel Roskin wrote:
> Quoting "John W. Linville" <[email protected]>:
>
> > > Very cool! Is it likely that d80211 and iwlwifi will be pushed into
> > > mainline in time for 2.6.21?
> >
> > Hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems
> > more likely for mainline.
>
> I think we should take this as a goal. Last time I checked, d80211 wasn't in
> -mm. Perhaps it should go there. And by the way, the latest changes from
> netdev->class_dev to netdev->dev break d80211. Perhaps we should rebase
> wireless-dev immediately after 2.6.21-rc1, fix all compile issues and submit
> the patch to -mm.
That is basically the plan. :-)
John
--
John W. Linville
[email protected]
Pavel Roskin wrote:
> On Fri, 2007-02-09 at 14:18 -0800, James Ketrenos wrote:
>>> grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file
>>> or directory
...
>> I'll look into it. Does it work if you explicitly set KSRC to point to
>> your kernel sources?
>>
>> $ make KSRC=/lib/modules/2.6.20/source
>
> That works. At least it doesn't report errors. But it doesn't create a
> single object file.
'make' builds a set of sources compatible with the running kernel (or
the one pointed to via KSRC=).
'make patch_kernel' will then install the sources into your kernel tree.
You then build d80211 as part of your main kernel (either as a module
or static) The changes 'patch_kernel' makes do not require a full
kernel rebuild (you can just build the 80211 modules).
We'll want to add the ability to build as out-of-tree .ko's (similar to
what iwlwifi does) but I wanted to get the project announced.
> "build" is still hardcoded in iwlwifi's Makefile. It's interesting that
> D80211_INC is defined twice in Makefile. That must be wrong.
Now that you point it out, I hadn't tried using KSRC w/ the iwlwifi
build, just d80211. I'll have to fix that :)
Thanks,
James
On Wed, 2007-02-21 at 20:38 +0100, Pavel Machek wrote:
> "Normal" installation procedure has too many steps in my eyes, and
> combined git tree is not available, so I was waiting for merge at
> least into -wirelessdev tree.
"make patch_kernel" would patch the kernel from wireless-dev.git. If
the Linux source tree is not configured, just run "make distclean" after
that (or apply my patch from the previous post in the ipw3945-devel
list).
You can use StGIT for convert the changes made by "make patch_kernel" to
a local patch so that updating from the upstream git repository is still
possible with "stg pull".
No need to wait for anything.
--
Regards,
Pavel Roskin
On Friday 09 February 2007 22:12, James Ketrenos wrote:
> We are pleased to announce the availability of a new driver for the
> Intel PRO/Wireless 3945ABG Network Connection adapter.
Wow, great news on this rainy saturday! ;-)
The driver works perfectly, I'm writing this mail via wireless link. However
there are two things to note:
The driver generates two network devices. The second one is for promicious
mode? Is there any chance to disable the interface? ifrename renamed the
wrong one to wlan0 and I had to tell my system to use eth1 for the wireless
connection.
Second problem is that I can't unload the module. I get the message "FATAL:
Module iwlwifi is in use." even if both interfaces are down.
--
Regards,
Chris
On Sunday 11 February 2007 01:55, Pavel Roskin wrote:
> Hello!
>
> [I'm trimming the cc: a little bit]
>
> On Sat, 2007-02-10 at 14:23 +0100, Hesse, Christian wrote:
> > On Friday 09 February 2007 22:12, James Ketrenos wrote:
> > > We are pleased to announce the availability of a new driver for the
> > > Intel PRO/Wireless 3945ABG Network Connection adapter.
> >
> > Wow, great news on this rainy saturday! ;-)
> >
> > The driver works perfectly, I'm writing this mail via wireless link.
> > However there are two things to note:
> >
> > The driver generates two network devices. The second one is for
> > promicious mode? Is there any chance to disable the interface? ifrename
> > renamed the wrong one to wlan0 and I had to tell my system to use eth1
> > for the wireless connection.
>
> I think one of the devices is wmaster0. It's better that you just
> ignore it. The effort is already underway to make that interface
> hidden.
>
> In the meantime, you can use the "arp" condition in /etc/iftab.
> Ethernet is 1 (that includes the original wlan0), IEEE 802.11 is 801
> (that's the master devices and devices in monitor mode). For example:
>
> wifi* arp 801
> eth* arp 1
I decided to drop the iftab thing and replace it with udev rules. The
following rules do the expected renaming:
KERNEL=="eth*", SYSFS{address}=="00:13:77:04:a7:77", NAME="eth0"
KERNEL=="eth*", SYSFS{address}=="00:00:f0:41:20:07:e8:49", SYSFS{type}=="24",
NAME="fw0"
KERNEL=="eth*", SYSFS{address}=="00:13:02:0f:56:a2", SYSFS{type}=="1",
NAME="wlan0"
> > Second problem is that I can't unload the module. I get the message
> > "FATAL: Module iwlwifi is in use." even if both interfaces are down.
>
> I cannot reproduce this problem. Please see the output of "lsmod" and
> the kernel log for possible oopses.
lsmod shows a use count of 4294967295 (2^32 - 1), no oopses or the like. This
is reproducable all the time.
--
Regards,
Chris
On Tuesday 13 February 2007 07:47, Pavel Roskin wrote:
> Hello!
>
> On Sun, 2007-02-11 at 14:17 +0100, Hesse, Christian wrote:
> > lsmod shows a use count of 4294967295 (2^32 - 1), no oopses or the like.
> > This is reproducable all the time.
>
> Although I cannot reproduce the problem (I'm on current wireless-dev),
> here's my interpretation.
>
> The iwlwifi driver includes both a driver and a rate control algorithm.
> It passes THIS_MODULE (i.e. a handle to itself) to the generic rate
> control code, which locks the caller i.e. iwlwifi. Therefore, iwlwifi
> has locked itself in memory.
>
> To counteract that, the driver "puts" the module, i.e. decreases its use
> count after the rate control is registered. Conversely, the module
> "gets" itself when the rate control is unregistered.
>
> One thing that is clearly wrong is that try_module_get() comes after
> ieee80211_rate_control_unregister(), not before. This means that the
> use count would go negative between those calls. If the kernel starts
> checking for this, the driver is in trouble.
>
> Further, why do we need this self-locking/unlocking trick? The driver
> can just set priv->rate_control.module to NULL and prevent self-locking.
>
> It would only make sense to put THIS_MODULE there is the rate control
> were implemented as a separate module, which it probably a good idea in
> the long term.
>
> But a simple fix would be just to get rid of all references to
> THIS_MODULE and let the kernel do the right thing.
>
> Most likely, your kernel doesn't use the priv->rate_control.module field
> to lock the module, so it would help in your case.
>
> Please try this patch:
>
> [ patch snipped ]
This patch solves the problem. The module's use count is zero and I can unload
and load the module.
However I have processes in status D when restarting the device. Is it
possible that some functions (i.e. escape_essid()) from old and new ieee80211
stack conflict? I will recompile my kernel without the old stack and see if
anything changes.
--
Regards,
Chris
On 2/9/07, James Ketrenos <[email protected]> wrote:
> Ok. Now... any questions?
No... Just that it is great news!
Best Regards,
Alon Bar-Lev.
On Saturday 10 February 2007 14:23, Hesse, Christian wrote:
> On Friday 09 February 2007 22:12, James Ketrenos wrote:
> > We are pleased to announce the availability of a new driver for the
> > Intel PRO/Wireless 3945ABG Network Connection adapter.
>
> Wow, great news on this rainy saturday! ;-)
>
> The driver works perfectly, I'm writing this mail via wireless link.
> However there are two things to note:
>
> The driver generates two network devices. The second one is for promicious
> mode? Is there any chance to disable the interface? ifrename renamed the
> wrong one to wlan0 and I had to tell my system to use eth1 for the wireless
> connection.
>
> Second problem is that I can't unload the module. I get the message "FATAL:
> Module iwlwifi is in use." even if both interfaces are down.
Oh, I forgot one note: "make patch_kernel" is terribly broken. Any chance to
get this fixed soon?
--
Regards,
Chris
On Tue, 20 Feb 2007 22:23:21 -0800 Stephen Hemminger wrote:
> BUilding with sparse shows lots of warnings.
>
>
> $ make C=1
> Checking kernel compatibility in:
> /lib/modules/2.6.20.1/source
> * Kernel supports required features for 'tip' version.
> Building compatibility version in 'compatible/' directory:
> Copying compatible/ from origin/...done
> make -C /lib/modules/2.6.20.1/build M=/home/shemminger/src/iwlwifi-0.0.8
> modules
[snip]
Good point(s). Please try to use Documentation/SubmitChecklist,
as indicated in Andrew's -mm announcements (and copied in my sig below).
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Friday February 9, [email protected] wrote:
>
> Ok. Now... any questions?
>
Yes. Does this require a closed user-space helper like the other
3945ABG driver, or is it completely open (maybe excepting firmware)?
Thanks,
NeilBrown
On Saturday 10 February 2007 17:22, Theodore Tso wrote:
> On Fri, Feb 09, 2007 at 01:12:42PM -0800, James Ketrenos wrote:
> > Please hold all questions until I am done with this email. Thank you.
> >
> > We are pleased to announce the availability of a new driver for the
> > Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
> > uses the new d80211 subsystem previously only available as part of the
> > wireless-dev tree.
>
> Very cool! Is it likely that d80211 and iwlwifi will be pushed into
> mainline in time for 2.6.21?
Not at all.
--
Greetings Michael.
On 2/13/07, Ismail D=F6nmez <[email protected]> wrote:
> Tried this is on a patched 2.6.20 kernel with ipw3945 device and it a=
lways
> puts the card in 802.11a mode instead of 802.11bg mode.
>
> Ideas?
Before running "iwconfig wlan0 channel 8", the card is set to
802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the
channel, it sets to 802.11b mode, and I can't find a way to change
from 11Mb/s to 54MB/s.
"iwlist eth0 rate" only show up to 11Mb/s.
So, my problem is the card is always in 802.11b mode.
Thanks,
Jeff.
On Friday 09 February 2007 23:12:42 James Ketrenos wrote:
> Please hold all questions until I am done with this email. Thank you.
>
> We are pleased to announce the availability of a new driver for the
> Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
> uses the new d80211 subsystem previously only available as part of the
> wireless-dev tree.
>
> You can find the new driver, and additional information about it, here:
>
> http://intellinuxwireless.org/iwlwifi.
Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always
puts the card in 802.11a mode instead of 802.11bg mode.
Ideas?
Regards,
ismail
Hi!
> >>You can find the new driver, and additional information
> >>about it, here:
> >>
> >> http://intellinuxwireless.org/iwlwifi.
> >...
> >>You can find that package at:
> >>
> >> http://intellinuxwireless.org/d80211
> >>
> >>Ok. Now... any questions?
> >
> >Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
> >but it did not contain d80211 stack. I'm now downloading wireless-dev
> >git tree...
>
> There isn't a singular merged iwlwifi + d80211 package tree outside of
> wireless-dev, and iwlwifi isn't there yet (I'm cleaning out some dead
> and duplicated code before we submit)
Ok, I was looking for merged tree. JBenc told me it should be
available "soon", so I guess I'll wait.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoting "John W. Linville" <[email protected]>:
> > Very cool! Is it likely that d80211 and iwlwifi will be pushed into
> > mainline in time for 2.6.21?
>
> Hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems
> more likely for mainline.
I think we should take this as a goal. Last time I checked, d80211 wasn't in
-mm. Perhaps it should go there. And by the way, the latest changes from
netdev->class_dev to netdev->dev break d80211. Perhaps we should rebase
wireless-dev immediately after 2.6.21-rc1, fix all compile issues and submit
the patch to -mm.
And iwlwifi is surprisingly good for a just announced driver. It worked for me
from the first attempt, and that's the first d80211 driver to do so. In my
opinion, it should go to wireless-dev as soon as possible so it can go to -mm
toghether with other drivers. A couple of wrinkles in the standalone build
system are irrelevant to the kernel interation.
--
Regards,
Pavel Roskin
On Tue, 2007-02-13 at 18:13 +0000, Pavel Machek wrote:
> Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
> but it did not contain d80211 stack. I'm now downloading wireless-dev
> git tree...
I would expect Intel to post patches some time soon to get into
wireless-dev.
johannes
Hello.
On Sat, 2007-02-10 at 09:26, Neil Brown wrote:
> On Friday February 9, [email protected] wrote:
> >
> > Ok. Now... any questions?
> >
>
> Yes. Does this require a closed user-space helper like the other
> 3945ABG driver, or is it completely open (maybe excepting firmware)?
Quote from the mentioned website:
"In addition to using the new d80211 subsystem, this project uses a
new microcode image which removes the need for the user space
regulatory daemon for this adapter"
regards
Stefan Schmidt
On Sat, Feb 10, 2007 at 11:22:54AM -0500, Theodore Tso wrote:
> On Fri, Feb 09, 2007 at 01:12:42PM -0800, James Ketrenos wrote:
> > Please hold all questions until I am done with this email. Thank you.
> >
> > We are pleased to announce the availability of a new driver for the
> > Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
> > uses the new d80211 subsystem previously only available as part of the
> > wireless-dev tree.
>
> Very cool! Is it likely that d80211 and iwlwifi will be pushed into
> mainline in time for 2.6.21?
Hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems
more likely for mainline.
John
--
John W. Linville
[email protected]
Hesse, Christian wrote:
> On Saturday 10 February 2007 14:23, Hesse, Christian wrote:
>
>> On Friday 09 February 2007 22:12, James Ketrenos wrote:
>>
>>> We are pleased to announce the availability of a new driver for the
>>> Intel PRO/Wireless 3945ABG Network Connection adapter.
>>>
>> Wow, great news on this rainy saturday! ;-)
>>
>> The driver works perfectly, I'm writing this mail via wireless link.
>> However there are two things to note:
>>
>> The driver generates two network devices. The second one is for promicious
>> mode? Is there any chance to disable the interface? ifrename renamed the
>> wrong one to wlan0 and I had to tell my system to use eth1 for the wireless
>> connection.
>>
>> Second problem is that I can't unload the module. I get the message "FATAL:
>> Module iwlwifi is in use." even if both interfaces are down.
>>
>
> Oh, I forgot one note: "make patch_kernel" is terribly broken. Any chance to
> get this fixed soon?
>
>
confirmed on my box it resulted in deleting all kernel modules.
(had to reinstall the kernel)
(make modules in /lib/modules/`uname -r`/build after make patch_kernel)
this was on fc6 x86_64
Pavel Machek wrote:
...
>> You can find the new driver, and additional information
>> about it, here:
>>
>> http://intellinuxwireless.org/iwlwifi.
> ...
>> You can find that package at:
>>
>> http://intellinuxwireless.org/d80211
>>
>> Ok. Now... any questions?
>
> Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
> but it did not contain d80211 stack. I'm now downloading wireless-dev
> git tree...
> Pavel
There isn't a singular merged iwlwifi + d80211 package tree outside of
wireless-dev, and iwlwifi isn't there yet (I'm cleaning out some dead
and duplicated code before we submit)
I've put up http://intellinuxwireless.org/repos/?p=d80211.git so you can
pull the d80211 package via git (vs. downloading the tarball). Running
'make patch_kernel' will then install the d80211 subsystem containing
patches not yet in wireless-dev into your kernel sources (specified via
KSRC=)
James
Ismail D=F6nmez wrote:
> On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote:
>> On 2/13/07, Ismail D=F6nmez <[email protected]> wrote:
>>> Tried this is on a patched 2.6.20 kernel with ipw3945 device and it
>>> always puts the card in 802.11a mode instead of 802.11bg mode.
>>>
>>> Ideas?
>> Before running "iwconfig wlan0 channel 8", the card is set to
>> 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the
>> channel, it sets to 802.11b mode, and I can't find a way to change
>> from 11Mb/s to 54MB/s.
>>
>> "iwlist eth0 rate" only show up to 11Mb/s.
>>
>> So, my problem is the card is always in 802.11b mode.
>=20
> So I guess there is a common problem with a/bg modes?
Regardless of what iwconfig reports as the mode or rate, you should be=20
able to associate to an AP in either spectrum (2.4 or 5.2) using any=20
valid rate. Once configured and associated, iwconfig should provide=20
more correct information.
If association is failing, verify that 'iwlist scan' shows the AP and=20
that you specify everything for the association, eg:
iwconfig wlan0 channel 8 essid MyAP ap 00:13:f0:0d:ca:fe
d80211 will only attempt to associate once -- if it fails, then you nee=
d=20
to currently "de-configure" the device and reconfigure it back to what=20
you want to associate to. I do that here by chaging the AP BSSID to=20
something else then changing it back. If you use wpa_supplicant, it=20
does the re-association attempts for you.
James
Pavel Roskin wrote:
> Hello, James!
>
> On Fri, 2007-02-09 at 13:12 -0800, James Ketrenos wrote:
>
>> You can find the new driver, and additional information about it, here:
>>
>> http://intellinuxwireless.org/iwlwifi.
>
> I cannot get it through git:
>
> $ git-clone http://intellinuxwireless.org/repos/iwlwifi.git
> Initialized empty Git repository in /home/proski/src/iwlwifi/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
>
> Perhaps git is right? There is no info/refs there.
Updated and tested 'git clone' and its working now (I use cg-clone)
> grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file
> or directory
>
> Apparently it should be looking into /lib/modules/2.6.20/source as well.
> That was a problem with the official ipw3945 drivers as well.
I'll look into it. Does it work if you explicitly set KSRC to point to
your kernel sources?
$ make KSRC=/lib/modules/2.6.20/source
?
Thanks,
James
Johannes Berg wrote:
> On Tue, 2007-02-13 at 18:13 +0000, Pavel Machek wrote:
>
>> Yes... is there merged .git tree somewhere? I downloaded iwl git tree,
>> but it did not contain d80211 stack. I'm now downloading wireless-dev
>> git tree...
>
> I would expect Intel to post patches some time soon to get into
> wireless-dev.
>
> johannes
Some of the patches contained in the d80211-1.0.1 'pending/' directory
have already been submitted to netdev in the past. The rest will be
submitted soon (I would have liked them to have been submitted a few
weeks back, but that slipped through my task list)
The d80211 packages I've pushed to date haven't done a very good job of
accounting regarding the pending/ directory. Those were the patches our
team here had been working with internally, and I wanted to get them out
to the users ASAP. I'm working to get better descriptions added to the
headers of those patches, as well as adding a status line indicating
when the patches were submitted to the mailing lists for discussion.
The goal is to only include patches in the d80211 tarballs which have
been submitted for eventual in-tree inclusion.
James
Hello, James!
On Fri, 2007-02-09 at 13:12 -0800, James Ketrenos wrote:
> You can find the new driver, and additional information about it, here:
>
> http://intellinuxwireless.org/iwlwifi.
I cannot get it through git:
$ git-clone http://intellinuxwireless.org/repos/iwlwifi.git
Initialized empty Git repository in /home/proski/src/iwlwifi/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
Perhaps git is right? There is no info/refs there.
> You can find that package at:
>
> http://intellinuxwireless.org/d80211
I appreciate that you are doing this. But it doesn't compile against
kernels compiled outside the tree:
grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file
or directory
Apparently it should be looking into /lib/modules/2.6.20/source as well.
That was a problem with the official ipw3945 drivers as well.
--
Regards,
Pavel Roskin
On Monday 12 February 2007 19:35, James Ketrenos wrote:
> Hesse, Christian wrote:
> > On Saturday 10 February 2007 14:23, Hesse, Christian wrote:
> >> On Friday 09 February 2007 22:12, James Ketrenos wrote:
> >>> We are pleased to announce the availability of a new driver for the
> >>> Intel PRO/Wireless 3945ABG Network Connection adapter.
>
> ...
>
> > Oh, I forgot one note: "make patch_kernel" is terribly broken. Any chance
> > to get this fixed soon?
>
> I've put up a new version of iwlwifi (0.0.6) with significant changes to
> the patch_kernel scripts as well as including Pavel's patch to KSRC.
>
> I performed some build testing with 2.6.18 and wireless-dev @ commit
> f66e5aaa88c1c0a7ee6c6427d6535ed8afd35427 (Jan 8).
>
> http://intellinuxwireless.org/?n=downloads
>
> Let me know if it is still breaking.
Hmm, it compiled once, but after I removed the tree and used a clean one I can
not reproduce it:
LD drivers/net/wireless/built-in.o
ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file or
directory
make[3]: *** [drivers/net/wireless/built-in.o] Error 1
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
So it is still broken.
--
Regards,
Chris
> Over the past year we were able to make the necessary changes to the
> microcode used with the 3945 such that we were able to remove the
> regulatory daemon.
Great news !! Congratz ;-)
--
As you read this post global entropy rises. Have Fun ;-)
Nick
On Fri, Feb 09, 2007 at 01:12:42PM -0800, James Ketrenos wrote:
> Please hold all questions until I am done with this email. Thank you.
>
> We are pleased to announce the availability of a new driver for the
> Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver
> uses the new d80211 subsystem previously only available as part of the
> wireless-dev tree.
Very cool! Is it likely that d80211 and iwlwifi will be pushed into
mainline in time for 2.6.21?
Regards,
- Ted
Norbert Preining wrote:
...
> Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up,
> maybe because I have CONFIG_D80211_LEDS off?
The LED code in iwlwifi isn't hooked up to the D80211 LED code yet. If
you'd file a bug at http://bughost.org regarding the LEDs being broken
(if you haven't already) I would appreciate it.
Thanks,
James
Hi all!
On Fre, 09 Feb 2007, James Ketrenos wrote:
> We are pleased to announce the availability of a new driver for the=20
> Intel PRO/Wireless 3945ABG Network Connection adapter. This new driv=
er=20
I am impressed: I had 2.6.20 running with ipw3945 + wpa_supplicant. I
installed the d80211 system and the new driver, rebooted, and you won't
believe it, I had network connection even with WEP encryption.
That was a big surprise for me that it worked out of the box without an=
y
magic.
If you are interested in any dmesg/log output, please let me know.
Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up=
,
maybe because I have CONFIG_D80211_LEDS off?
Again, thanks a lot for the good work!
Norbert
-----------------------------------------------------------------------=
--------
Dr. Norbert Preining <[email protected]> Universit=E0=
di Siena
Debian Developer <[email protected]> Debian T=
eX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 0=
9C5 B094
-----------------------------------------------------------------------=
--------
HARPENDEN (n.)
The coda to a phone conversion, consisting of about eight exchanges,
by which people try gracefully to get off the line.
--- Douglas Adams, The Meaning of Liff
Neil Brown wrote:
> On Friday February 9, [email protected] wrote:
>> Ok. Now... any questions?
>
> Yes. Does this require a closed user-space helper like the other
> 3945ABG driver, or is it completely open (maybe excepting firmware)?
The iwlwifi driver for the 3945 does not require the user space daemon,
but does require a new microcode image.
Over the past year we were able to make the necessary changes to the
microcode used with the 3945 such that we were able to remove the
regulatory daemon.
James
On Tue, Jan 27, 2009 at 11:15 AM, Johannes Berg
<[email protected]> wrote:
> drivers/net/wireless/iwlwifi/iwl3945-base.c: In function
> 'iwl3945_pci_resume':
> drivers/net/wireless/iwlwifi/iwl3945-base.c:6319: warning: ignoring
> return value of 'pci_enable_device', declared with attribute
> warn_unused_result
>
> drivers/net/wireless/iwlwifi/iwl-agn.c: In function 'iwl_pci_resume':
> drivers/net/wireless/iwlwifi/iwl-agn.c:4128: warning: ignoring return
> value of 'pci_enable_device', declared with attribute warn_unused_result
>
> drivers/net/wireless/iwlwifi/iwl-tx.c: In function 'iwl_tx_queue_alloc':
> drivers/net/wireless/iwlwifi/iwl-tx.c:302: warning: format '%zd' expects
> type 'signed size_t', but argument 4 has type 'u32'
Patch already queued.
Tomas
On Tue, 2009-01-27 at 11:34 +0200, Tomas Winkler wrote:
> On Tue, Jan 27, 2009 at 11:15 AM, Johannes Berg
> <[email protected]> wrote:
> > drivers/net/wireless/iwlwifi/iwl3945-base.c: In function
> > 'iwl3945_pci_resume':
> > drivers/net/wireless/iwlwifi/iwl3945-base.c:6319: warning: ignoring
> > return value of 'pci_enable_device', declared with attribute
> > warn_unused_result
> >
> > drivers/net/wireless/iwlwifi/iwl-agn.c: In function 'iwl_pci_resume':
> > drivers/net/wireless/iwlwifi/iwl-agn.c:4128: warning: ignoring return
> > value of 'pci_enable_device', declared with attribute warn_unused_result
> >
> > drivers/net/wireless/iwlwifi/iwl-tx.c: In function 'iwl_tx_queue_alloc':
> > drivers/net/wireless/iwlwifi/iwl-tx.c:302: warning: format '%zd' expects
> > type 'signed size_t', but argument 4 has type 'u32'
>
> Patch already queued.
Ok, cool.
johannes