* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Gábor Stefanik @ 2009-09-16 20:44 UTC (permalink / raw)
To: Thomas Ilnseher
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <1253132275.2989.75.camel@note>
2009/9/16 Thomas Ilnseher <illth@gmx.de>:
> Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
>> You are essentially implementing dead code at this point - this will
>> only ever be called if hardware-accelerated TX power control is
>> enabled - and HW TX power control is unsupported, even for G-PHYs.
> Then the question remains, why this brings my device to 54 MBit/s ?
>
> I did double check again with the old driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point:
> Bit Rate=9 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=5 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Patched driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point: XXX
> Bit Rate=54 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=10 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
>
>> > Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>> >
>> > ---
>> > diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
>> > --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
>> > +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
>> > @@ -1125,6 +1125,18 @@
>> > dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
>> > }
>> >
>> > +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
>> > +{
>> > + int i;
>> > + int id = 7;
>> > + if (dev->phy.rev < 2)
>> > + id = 10;
>> > + for (i = 0; i < 12; i++)
>> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
>> > + for (i = 0; i < 64; i++)
>> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
>> > +}
>> > +
>> > static void lpphy_set_tx_power_control(struct b43_wldev *dev,
>> > enum b43_lpphy_txpctl_mode mode)
>> > {
>> > @@ -1139,7 +1151,7 @@
>> >
>> > if (oldmode == B43_LPPHY_TXPCTL_HW) {
>> > lpphy_update_tx_power_npt(dev);
>> > - //TODO Clear all TX Power offsets
>> > + lpphy_clear_tx_power_offsets(dev);
Put a printk here to see if this branch is getting hit.
(BTW, are you loading b43 with the "hwpctl" modparam? That enables
experimental HW TX power control support, which might explain what you
were seeing.)
>> > } else {
>> > if (mode == B43_LPPHY_TXPCTL_HW) {
>> > //TODO Recalculate target TX power
>> >
>> >
>>
>>
>>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* RE: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Bing Zhao @ 2009-09-16 20:20 UTC (permalink / raw)
To: Andrey Yurovsky
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
Amitkumar Karwar, Dan Williams
In-Reply-To: <45e8e6c40909151641o423cbc70y22033061505661b6@mail.gmail.com>
Hi Andrey,
> -----Original Message-----
> From: Andrey Yurovsky [mailto:andrey@cozybit.com]
> Sent: Tuesday, September 15, 2009 4:41 PM
> To: Bing Zhao
> Cc: libertas-dev@lists.infradead.org; linux-wireless@vger.kernel.org; Amitkumar Karwar; Dan Williams
> Subject: Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
>
> Hi Bing. This is not specific to the actual implementation of the
> deep sleep commands in your patch but,
>
> On Tue, Sep 15, 2009 at 4:45 PM, Bing Zhao <bzhao@marvell.com> wrote:
> > + Path: /sys/kernel/debug/libertas_wireless/ethX/
>
> Is the sysfs interface really necessary? It seems like yet another
> non-standard configuration option to keep track of.
Actually the debugfs interface is used in the patch.
Some information (such as the interface name and path) in README file is out of date. We just copy-and-paste it for the new deepsleep command. We need a separate patch to clean up the REAME file and keep it up to date.
>
> Deep sleep seems to pretty much "turn off" the wifi card (as far as
> the user is concerned) so how about a simpler approach: enter deep
> sleep when the interface is brought down (ifconfig wlanN down) and
> exit deep sleep when it's brought up. Do this only when deep sleep is
> supported/possible. Alternately, maybe this belongs as an rfkill
> feature?
Entering/exiting deep sleep doesn't have to depend on wlanN interface's up and down. User can still put the chip into sleep when wlanN is up. And, with auto deep sleep feature, the driver automatically wakes the chip up for sending user commands (for example, scan) and put the chip back to sleep after certain time period of inactivity. The deepsleep command through debugfs interface provides the flexibility of deep sleep options.
The rfkill shuts down the RF transmitter of the device but most of other modules may be still functioning. The deep sleep shuts down most of the modules (including the RF) on the chip to save as much power as possible.
Regards,
Bing
>
> -Andrey
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Thomas Ilnseher @ 2009-09-16 20:17 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <69e28c910909161240p7739edebi653b5d402a792856@mail.gmail.com>
Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
> You are essentially implementing dead code at this point - this will
> only ever be called if hardware-accelerated TX power control is
> enabled - and HW TX power control is unsupported, even for G-PHYs.
Then the question remains, why this brings my device to 54 MBit/s ?
I did double check again with the old driver:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point:
Bit Rate=9 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=5 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Patched driver:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point: XXX
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> > Signed-off-by: Thomas Ilnseher <illth@gmx.de>
> >
> > ---
> > diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> > --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
> > +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
> > @@ -1125,6 +1125,18 @@
> > dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
> > }
> >
> > +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
> > +{
> > + int i;
> > + int id = 7;
> > + if (dev->phy.rev < 2)
> > + id = 10;
> > + for (i = 0; i < 12; i++)
> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
> > + for (i = 0; i < 64; i++)
> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
> > +}
> > +
> > static void lpphy_set_tx_power_control(struct b43_wldev *dev,
> > enum b43_lpphy_txpctl_mode mode)
> > {
> > @@ -1139,7 +1151,7 @@
> >
> > if (oldmode == B43_LPPHY_TXPCTL_HW) {
> > lpphy_update_tx_power_npt(dev);
> > - //TODO Clear all TX Power offsets
> > + lpphy_clear_tx_power_offsets(dev);
> > } else {
> > if (mode == B43_LPPHY_TXPCTL_HW) {
> > //TODO Recalculate target TX power
> >
> >
>
>
>
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: Maciej Rutecki @ 2009-09-16 19:59 UTC (permalink / raw)
To: reinette chatre
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <1253124149.26521.438.camel@rc-desk>
2009/9/16 reinette chatre <reinette.chatre@intel.com>:
>
> You mentioned that you tried to connect to two networks. From the logs I
> can understand that the connection to the first network took a long
> time. This is also not due to the warnings you encountered (the warnings
> only showed up after you disconnected from second network). The reason
> why the connection to the first network took so long was some protocol
> exchange problems with AP. Here is the relevant information from your
> log:
>
[...]
>
> As you can see the AP keeps deauthenticating you with Reason 6. This
> means "Incorrect frame type or subtype received from unauthenticated
> station". Can you try to connect using wpa_supplicant? When you do make
> sure there is no other network managing applications (like network
> manager, wicd, or even other instances of wpa_supplicant etc) running.
>
> The connection to the second network went very fast - completed in one
> second. But a disconnection was requested locally just as fast. Do you
> perhaps have more than one network managing application running?
1. Stop wicd daemon (I don't use another application to connect to the network).
2. Connect to network "x" (with WPA)
Script (wifi_wpa.sh):
#!/bin/sh
INTERFACE=wlan0
WPA_FILE=/etc/wpa_supplicant/wpa_supplicant.conf
DRIVER=wext
ifconfig eth0 down
ifconfig $INTERFACE up
sleep 3
killall wpa_supplicant &> /dev/null
wpa_supplicant -c $WPA_FILE -D $DRIVER -i $INTERFACE -B
dhclient $INTERFACE
iwconfig $INTERFACE
File /etc/wpa_supplicant/wpa_supplicant.conf:
# WPA-PSK/TKIP
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="x"
key_mgmt=WPA-PSK
proto=WPA
pairwise=TKIP
group=TKIP
psk=<data hidden>
priority=4
}
First try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_wpa.sh
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
Trying recorded lease 192.168.0.102
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
No working leases in persistent database - sleeping.
wlan0 IEEE 802.11abg ESSID:"x"
Mode:Managed Frequency:2.457 GHz Access Point: 00:1B:11:F6:0F:28
Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
>From dmesg:
[ 256.945249] b44: eth0: powering down PHY
[ 256.948714] iwl3945 0000:08:00.0: firmware: requesting
iwlwifi-3945-2.ucode
[ 256.985907] iwl3945 0000:08:00.0: loaded firmware version 15.32.2.9
[ 257.060922] Registered led device: iwl-phy0::radio
[ 257.061021] Registered led device: iwl-phy0::assoc
[ 257.061070] Registered led device: iwl-phy0::RX
[ 257.061109] Registered led device: iwl-phy0::TX
[ 262.899954] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 262.902445] wlan0 direct probe responded
[ 262.902455] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 262.904278] wlan0: authenticated
[ 262.904328] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 262.906702] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431
status=0 aid=1)
[ 262.906711] wlan0: associated
[ 266.615969] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 269.342010] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 269.344434] wlan0 direct probe responded
[ 269.344441] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 269.346167] wlan0: authenticated
[ 269.346197] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 269.348470] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[...]
[ 416.396624] wlan0: associated
[ 419.907739] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 422.633775] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 422.832075] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 2)
[ 423.032068] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 3)
[ 423.034477] wlan0 direct probe responded
[ 423.034484] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 423.036229] wlan0: authenticated
[ 423.036266] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 423.038518] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 423.038524] wlan0: associated
[ 481.301801] wlan0: deauthenticating by local choice (reason=3)
Second try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_wpa.sh
There is already a pid file /var/run/dhclient.pid with pid 4555
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPOFFER from 192.168.0.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.0.102 -- renewal in 571812 seconds.
wlan0 IEEE 802.11abg ESSID:"x"
Mode:Managed Frequency:2.457 GHz Access Point: 00:1B:11:F6:0F:28
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=68/70 Signal level=-42 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Dmesg:
[ 481.460263] Registered led device: iwl-phy0::radio
[ 481.460289] Registered led device: iwl-phy0::assoc
[ 481.460375] Registered led device: iwl-phy0::RX
[ 481.460396] Registered led device: iwl-phy0::TX
[ 481.476399] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 481.478822] wlan0 direct probe responded
[ 481.478828] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 481.480750] wlan0: authenticated
[ 481.480775] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 481.483111] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431
status=0 aid=1)
[ 481.483116] wlan0: associated
[ 485.238506] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 485.361103] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 485.363480] wlan0 direct probe responded
[ 485.363487] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 485.365222] wlan0: authenticated
[ 485.365253] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 485.367505] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 485.367512] wlan0: associated
[ 489.334545] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 492.052130] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 492.054555] wlan0 direct probe responded
[ 492.054562] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 492.056507] wlan0: authenticated
[ 492.056541] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 492.058793] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 492.058800] wlan0: associated
[ 495.580873] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 498.302685] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 498.305121] wlan0 direct probe responded
[ 498.305129] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 498.306855] wlan0: authenticated
[ 498.306885] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 498.309142] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 498.309149] wlan0: associated
[ 501.520066] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 504.250066] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 504.252493] wlan0 direct probe responded
[ 504.252500] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 504.254227] wlan0: authenticated
[ 504.254256] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 504.256525] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 504.256532] wlan0: associated
[ 507.766452] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 510.518231] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 510.520682] wlan0 direct probe responded
[ 510.520689] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 510.522415] wlan0: authenticated
[ 510.522447] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 510.524699] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 510.524706] wlan0: associated
[ 514.012725] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 516.718174] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 516.720611] wlan0 direct probe responded
[ 516.720619] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 516.722346] wlan0: authenticated
[ 516.722377] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 516.724653] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 516.724660] wlan0: associated
[ 520.873494] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 523.608977] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 523.611397] wlan0 direct probe responded
[ 523.611405] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 523.613133] wlan0: authenticated
[ 523.613165] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 523.615415] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 523.615421] wlan0: associated
[ 527.011070] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 529.714994] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 529.717412] wlan0 direct probe responded
[ 529.717420] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 529.719146] wlan0: authenticated
[ 529.719176] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 529.721458] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 529.721465] wlan0: associated
3. Connect to network "y" (without wpa/wep/etc.)
Script:
#!/bin/sh
INTERFACE="wlan0"
ESSID="y"
killall wpa_supplicant
ifconfig $INTERFACE down
iwconfig $INTERFACE essid $ESSID
ifconfig $INTERFACE up
sleep 3
killall dhclient &> /dev/null
dhclient $INTERFACE
sleep 3
iwconfig $INTERFACE
First try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_dhcp.sh
There is already a pid file /var/run/dhclient.pid with pid 4819
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.1.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.1.102 -- renewal in 40350 seconds.
wlan0 IEEE 802.11abg ESSID:"y"
Mode:Managed Frequency:2.462 GHz Access Point: 00:0D:F3:0D:D1:4C
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=31/70 Signal level=-79 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Dmesg:
[ 1088.324243] Registered led device: iwl-phy0::radio
[ 1088.324270] Registered led device: iwl-phy0::assoc
[ 1088.324354] Registered led device: iwl-phy0::RX
[ 1088.324374] Registered led device: iwl-phy0::TX
[ 1088.339739] wlan0: direct probe to AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.343450] wlan0 direct probe responded
[ 1088.343458] wlan0: authenticate with AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.345313] wlan0: authenticated
[ 1088.345337] wlan0: associate with AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.347943] wlan0: RX AssocResp from 00:0d:f3:0d:d1:4c (capab=0x401
status=0 aid=2)
[ 1088.347948] wlan0: associated
Normally I use wicd to manage all networks. In first e-mail I connect
to "x" and - after this - connect to "y".
Network "x" is my own network. Sometimes (if is visible) I connect to
"y" - somebody create fast network without any protection... :-) Till
2.6.31 all works ok.
Note: in "x" and "y" I have the same IP (this only coincidence).
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Gábor Stefanik @ 2009-09-16 19:40 UTC (permalink / raw)
To: Thomas Ilnseher
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <1253129879.2989.48.camel@note>
You are essentially implementing dead code at this point - this will
only ever be called if hardware-accelerated TX power control is
enabled - and HW TX power control is unsupported, even for G-PHYs.
On Wed, Sep 16, 2009 at 9:37 PM, Thomas Ilnseher <illth@gmx.de> wrote:
> This patch adds the lpphy_clear_tx_power_offsets to b43.
>
> Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>
> ---
> diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
> +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
> @@ -1125,6 +1125,18 @@
> dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
> }
>
> +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
> +{
> + int i;
> + int id = 7;
> + if (dev->phy.rev < 2)
> + id = 10;
> + for (i = 0; i < 12; i++)
> + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
> + for (i = 0; i < 64; i++)
> + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
> +}
> +
> static void lpphy_set_tx_power_control(struct b43_wldev *dev,
> enum b43_lpphy_txpctl_mode mode)
> {
> @@ -1139,7 +1151,7 @@
>
> if (oldmode == B43_LPPHY_TXPCTL_HW) {
> lpphy_update_tx_power_npt(dev);
> - //TODO Clear all TX Power offsets
> + lpphy_clear_tx_power_offsets(dev);
> } else {
> if (mode == B43_LPPHY_TXPCTL_HW) {
> //TODO Recalculate target TX power
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Thomas Ilnseher @ 2009-09-16 19:37 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
This patch adds the lpphy_clear_tx_power_offsets to b43.
Signed-off-by: Thomas Ilnseher <illth@gmx.de>
---
diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
--- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
+++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
@@ -1125,6 +1125,18 @@
dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
}
+static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
+{
+ int i;
+ int id = 7;
+ if (dev->phy.rev < 2)
+ id = 10;
+ for (i = 0; i < 12; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
+ for (i = 0; i < 64; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1139,7 +1151,7 @@
if (oldmode == B43_LPPHY_TXPCTL_HW) {
lpphy_update_tx_power_npt(dev);
- //TODO Clear all TX Power offsets
+ lpphy_clear_tx_power_offsets(dev);
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
//TODO Recalculate target TX power
^ permalink raw reply
* [PATCH 1/2] b43: Add lpphy_update_tx_power_npt function to improve TX power handling on LP PHYs
From: Thomas Ilnseher @ 2009-09-16 19:27 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
The lpphy_update_tx_power_npt routine is currently missing in the code.
I added the routine according to the specs.
Signed-off-by: Thomas Ilnseher <illth@gmx.de>
---
diff -uNr compat-wireless-2009-09-15/drivers/net/wireless/b43/b43.h compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/b43.h
--- compat-wireless-2009-09-15/drivers/net/wireless/b43/b43.h 2009-09-15 06:13:53.000000000 +0200
+++ compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/b43.h 2009-09-15 23:35:02.651859159 +0200
@@ -255,7 +255,10 @@
#define B43_SHM_SH_MAXBFRAMES 0x0080 /* Maximum number of frames in a burst */
#define B43_SHM_SH_SPUWKUP 0x0094 /* pre-wakeup for synth PU in us */
#define B43_SHM_SH_PRETBTT 0x0096 /* pre-TBTT in us */
-
+/* MAC Statistics */
+#define B43_SHM_SH_TX_FRAMES_SENT 0x00E0 /* # TX Frames sent */
+#define B43_SHM_SH_TX_RTS 0x00E2 /* # TX RTS */
+#define B43_SHM_SH_TX_CTS 0x00E4 /* # TX CTS */
/* SHM_SCRATCH offsets */
#define B43_SHM_SC_MINCONT 0x0003 /* Minimum contention window */
#define B43_SHM_SC_MAXCONT 0x0004 /* Maximum contention window */
diff -uNr compat-wireless-2009-09-15/drivers/net/wireless/b43/phy_lp.c compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/phy_lp.c
--- compat-wireless-2009-09-15/drivers/net/wireless/b43/phy_lp.c 2009-09-15 06:13:53.000000000 +0200
+++ compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/phy_lp.c 2009-09-16 00:00:20.712857949 +0200
@@ -1103,6 +1103,28 @@
(u16)~B43_LPPHY_TX_PWR_CTL_CMD_MODE, ctl);
}
+static void lpphy_update_tx_power_npt(struct b43_wldev *dev)
+{
+ u16 tx_cnt;
+ u16 npt;
+ u16 s3;
+
+ s3 = b43_shm_read16(dev, B43_SHM_SHARED, B43_SHM_SH_TX_FRAMES_SENT);
+ tx_cnt = s3 - dev->phy.lp->tssi_tx_count;
+ npt = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_NNUM) & 0x700) >> 8;
+
+ if ((1 << (npt & 0x1F)) >= tx_cnt)
+ return;
+ /* NB: Spec says do the stuff if xxx < tx_cnt, so return on xxx > txcnt */
+ dev->phy.lp->tssi_tx_count = s3;
+ if (npt < 7) {
+ npt++;
+ b43_phy_maskset(dev, B43_LPPHY_TX_PWR_CTL_NNUM, 0xF8FF, (npt << 8));
+ }
+ dev->phy.lp->tssi_npt = npt;
+ dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1116,7 +1138,7 @@
lpphy->txpctl_mode = mode;
if (oldmode == B43_LPPHY_TXPCTL_HW) {
- //TODO Update TX Power NPT
+ lpphy_update_tx_power_npt(dev);
//TODO Clear all TX Power offsets
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
^ permalink raw reply
* [PATCH 0/2] b43: improve TX power handling for LP PHYs
From: Thomas Ilnseher @ 2009-09-16 19:25 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
I implemented the functions:
"lpphy_update_tx_power_npt"
and
"lpphy_set_tx_power_control",
and together, both improve the bitrate of my device:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point: XXX
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
without these patches, I maxed out at about 24 Mbit/s.
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: reinette chatre @ 2009-09-16 18:02 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <8db1092f0909161036t5bae781eqa6f0a0df308ec4cd@mail.gmail.com>
Hi Maciej,
On Wed, 2009-09-16 at 10:36 -0700, Maciej Rutecki wrote:
> 2009/9/16 reinette chatre <reinette.chatre@intel.com>:
> >
> > The important information is not what you posted here, but still in the
> > dmesg file you provided. In that log we see the following right before
> > the warnings:
> >
> > [ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.130027] wlan0 direct probe responded
> > [ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.131924] wlan0: authenticated
> > [ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
> > [ 163.134331] wlan0: associated
> > [ 163.155938] wlan0: deauthenticating by local choice (reason=3)
> >
> > It shows that association was successful, but something in userspace requested a disconnect.
>
> Hmm. Yes, connect takes more time than in 2.6.31.
You mentioned that you tried to connect to two networks. From the logs I
can understand that the connection to the first network took a long
time. This is also not due to the warnings you encountered (the warnings
only showed up after you disconnected from second network). The reason
why the connection to the first network took so long was some protocol
exchange problems with AP. Here is the relevant information from your
log:
[ 117.741190] wlan0: deauthenticating by local choice (reason=3)
[ 117.741308] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 117.745515] wlan0 direct probe responded
[ 117.745523] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 117.747256] wlan0: authenticated
[ 117.747288] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 117.749529] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 117.749536] wlan0: associated
[ 121.404153] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 124.123203] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 124.126121] wlan0 direct probe responded
[ 124.126129] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 124.127876] wlan0: authenticated
[ 124.127906] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 124.130164] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 124.130172] wlan0: associated
[ 128.263997] wlan0: disassociated (Reason: 3)
[ 128.280067] wlan0: deauthenticating by local choice (reason=3)
[ 130.968263] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 130.970685] wlan0 direct probe responded
[ 130.970692] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 130.972497] wlan0: authenticated
[ 130.972529] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 130.974780] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 130.974787] wlan0: associated
[ 134.511593] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 137.216183] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 137.218606] wlan0 direct probe responded
[ 137.218614] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 137.220520] wlan0: authenticated
[ 137.220555] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 137.222808] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 137.222815] wlan0: associated
[ 140.758586] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 143.513364] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 143.524448] wlan0 direct probe responded
[ 143.524456] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 143.526207] wlan0: authenticated
[ 143.526238] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 143.540625] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 143.540632] wlan0: associated
[ 162.901260] b44: eth0: powering down PHY
[ 162.919757] wlan0: deauthenticating by local choice (reason=3)
As you can see the AP keeps deauthenticating you with Reason 6. This
means "Incorrect frame type or subtype received from unauthenticated
station". Can you try to connect using wpa_supplicant? When you do make
sure there is no other network managing applications (like network
manager, wicd, or even other instances of wpa_supplicant etc) running.
The connection to the second network went very fast - completed in one
second. But a disconnection was requested locally just as fast. Do you
perhaps have more than one network managing application running?
Reinette
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: Maciej Rutecki @ 2009-09-16 17:36 UTC (permalink / raw)
To: reinette chatre
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <1253122055.26521.431.camel@rc-desk>
2009/9/16 reinette chatre <reinette.chatre@intel.com>:
>
> The important information is not what you posted here, but still in the
> dmesg file you provided. In that log we see the following right before
> the warnings:
>
> [ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.130027] wlan0 direct probe responded
> [ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.131924] wlan0: authenticated
> [ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
> [ 163.134331] wlan0: associated
> [ 163.155938] wlan0: deauthenticating by local choice (reason=3)
>
> It shows that association was successful, but something in userspace requested a disconnect.
Hmm. Yes, connect takes more time than in 2.6.31.
>
>>
>> [ 163.208063] ------------[ cut here ]------------
>> [ 163.208114] WARNING: at net/mac80211/scan.c:267
>> ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
>
> I cannot get an exact line match based on the kernel information you
> provided. I assume it is the first warning in
> ieee80211_scan_completed(). This is not serious as it indicates that
> mac80211 received a "scan completed" indication when it was not
> scanning.
>
>
>> [ 163.232845] ------------[ cut here ]------------
>> [ 163.232908] WARNING: at net/wireless/core.c:613
>> wdev_cleanup_work+0xbb/0xe0 [cfg80211]()
>
> This warning has just been reported in linux-wireless also. Perhaps you
> can follow its discussion there. See
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/39607
Thanks for information
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: reinette chatre @ 2009-09-16 17:27 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <8db1092f0909160236i5d2b1f31k3ec289fbd9ac0bfa@mail.gmail.com>
Hi Maciej,
> Steps to reproduce:
> 1. Connect to the wireless network (WPA2), it takes long time (longer
> than in 2.6.31)
> 2. Connect to another wireless network:
> 3. Connect fails with error:
The important information is not what you posted here, but still in the
dmesg file you provided. In that log we see the following right before
the warnings:
[ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 163.130027] wlan0 direct probe responded
[ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 163.131924] wlan0: authenticated
[ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 163.134331] wlan0: associated
[ 163.155938] wlan0: deauthenticating by local choice (reason=3)
It shows that association was successful, but something in userspace requested a disconnect.
>
> [ 163.208063] ------------[ cut here ]------------
> [ 163.208114] WARNING: at net/mac80211/scan.c:267
> ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
I cannot get an exact line match based on the kernel information you
provided. I assume it is the first warning in
ieee80211_scan_completed(). This is not serious as it indicates that
mac80211 received a "scan completed" indication when it was not
scanning.
> [ 163.232845] ------------[ cut here ]------------
> [ 163.232908] WARNING: at net/wireless/core.c:613
> wdev_cleanup_work+0xbb/0xe0 [cfg80211]()
This warning has just been reported in linux-wireless also. Perhaps you
can follow its discussion there. See
http://thread.gmane.org/gmane.linux.kernel.wireless.general/39607
Reinette
^ permalink raw reply
* Continuous monitoring of wifi stats
From: John Goyette @ 2009-09-16 17:24 UTC (permalink / raw)
To: linux-wireless
Hello all,
I am looking for some advice on a Libertas related issue. I am having a problem with a recent feature we added to our embedded system that continuously monitors wifi statistics, i.e., signal strength. We are using a Blackfin platform with a Marvell 8686 device in the G-SPI configuration. Our kernel is based on a 2.6.28.6 release.
The problem occurs after pressing Ctrl-C to terminate a user space program that is polling the wireless stats in a loop. A number of libertas error messages appear indicating a failure to download command 0x0000. I am pretty sure there is no command 0x0000, so I do not know how it got queued. Here is a sample of the error messages from dmesg:
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (#1)
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (0000002 <http://schicksw/mantis/view.php?id=2> )
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (0000003 <http://schicksw/mantis/view.php?id=3> )
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: Excessive timeouts submitting command 0x0000
This can be reproduced by enabling IEEE Power Savings mode and flooding the card with wireless stats requests by running something like the following from a terminal:
while true; do iwconfig eth1;done
Let this run for 30-60 secs, and then press Ctrl-C. With IEEE power savings off, it may take several minutes, but does eventually give the same problem. I have downloaded the compat-wireless-2.6.30 release and was able to cross-compile it for our kernel. It helped a little in that it seemed to take longer before the error messaged occurred after pressing ctrl-c, but it did not completely resolve the problem.
Has anyone seen something similar? Are there any more recent patches that may address this issue?
Thanks.
-John Goyette
Schick Technologies, Inc.
^ permalink raw reply
* Re: linuxwireless Driver information: zd1211rw
From: Stefan Lippers-Hollmann @ 2009-09-16 17:17 UTC (permalink / raw)
To: Markus Becker; +Cc: linux-wireless
In-Reply-To: <200909161804.04296.mab@comnets.uni-bremen.de>
Hi
On Wednesday 16 September 2009, Markus Becker wrote:
> Hello,
>
> is the information on the page
> http://www.linuxwireless.org/en/users/Drivers/zd1211rw about the Debian
> firmware package still true?
>
> "Firmware is pulled from userspace, get the files here.
> Debian users beware: don't use the the zd1211-firmware package, as this is for
> Debian's fork of the vendor-based driver"
>
> The current debian package contains the same files as in the link
> http://sourceforge.net/project/showfiles.php?group_id=129083
zd1211-firmware (2.16.0.0-0.1) unstable; urgency=low
* NMU
[...]
* Use symlink farm to provide the firmware in the locations used by the
zd1211rw in-kernel driver, as well as the zd1211 extra-kernel driver.
Closes: #383604
* Should be suitable for etch release now. Closes: #411912
[...]
-- Joey Hess <joeyh@debian.org> Wed, 21 Feb 2007 15:09:09 -0500
(the symlink farm is gone by now and the the package only keeps
compatibility with in-kernel zd1211rw, all what's left is the version
number derived from the vendor-based driver)
In other words, the past two major Debian releases (shipping with kernel
2.6.18/ etch and 2.6.26/ lenny respectively) had a working firmware package
available from the non-free section.
Kernel 2.6.18, which was the first to ship with zd1211rw, was released on
Tue, Sep 19 20:42:06 2006 -0700, so the advice pointing at a broken
firmware package in Debian's unreleased branches was true for roughly 4
months and never affected a released version (sarge shipped with kernel
2.6.8, etch with 2.6.18 and zd1211-firmware 2.16.0.0-0.1).
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* Re: iwlagn rfkill and 2.6.31 on Intel Corporation PRO/Wireless 5100 AGN
From: reinette chatre @ 2009-09-16 16:30 UTC (permalink / raw)
To: Fabio Coatti
Cc: John W. Linville, linux-wireless@vger.kernel.org, mjg@redhat.com
In-Reply-To: <200909161657.44453.fabio.coatti@gmail.com>
Hi Fabio,
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
> But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
> my side). Basically if the laptop starts with wifi enabled (rfkill off)
> wpa_supplicant can establish a connection, that can be killed by rfkill switch
> (both wifi and bluetooth seems to be killed). But when I turn off rfkill
> switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
> can see activity in bt stack, but no messages regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Reinette
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: reinette chatre @ 2009-09-16 16:26 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed
In-Reply-To: <20090916150239.GG1993@csn.ul.ie>
On Wed, 2009-09-16 at 08:02 -0700, Mel Gorman wrote:
> If vanilla, Reinette, is your patch already upstream or in a subsystem
> tree somewhere?
Not yet.
Reinette
^ permalink raw reply
* linuxwireless Driver information: zd1211rw
From: Markus Becker @ 2009-09-16 16:04 UTC (permalink / raw)
To: linux-wireless
Hello,
is the information on the page
http://www.linuxwireless.org/en/users/Drivers/zd1211rw about the Debian
firmware package still true?
"Firmware is pulled from userspace, get the files here.
Debian users beware: don't use the the zd1211-firmware package, as this is for
Debian's fork of the vendor-based driver"
The current debian package contains the same files as in the link
http://sourceforge.net/project/showfiles.php?group_id=129083
BR,
Markus
^ permalink raw reply
* [PATCH] cfg80211: fix SME connect
From: Johannes Berg @ 2009-09-16 16:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
There's a check saying
/* we're good if we have both BSSID and channel */
if (wdev->conn->params.bssid && wdev->conn->params.channel) {
but that isn't true -- we need the BSS struct. This leads
to errors such as
Trying to associate with 00:1b:53:11:dc:40 (SSID='TEST' freq=2412 MHz)
ioctl[SIOCSIWFREQ]: No such file or directory
ioctl[SIOCSIWESSID]: No such file or directory
Association request to the driver failed
Associated with 00:1b:53:11:dc:40
in wpa_supplicant, as reported by Holger.
Instead, we really need to have the BSS struct, and if we
don't, then we need to initiate a scan for it. But we may
already have the BSS struct here, so hang on to it if we
do and scan if we don't.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
net/wireless/sme.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- wireless-testing.orig/net/wireless/sme.c 2009-09-15 21:33:41.000000000 -0700
+++ wireless-testing/net/wireless/sme.c 2009-09-15 21:37:58.000000000 -0700
@@ -188,7 +188,7 @@ void cfg80211_conn_work(struct work_stru
rtnl_unlock();
}
-static bool cfg80211_get_conn_bss(struct wireless_dev *wdev)
+static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev)
{
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
struct cfg80211_bss *bss;
@@ -205,7 +205,7 @@ static bool cfg80211_get_conn_bss(struct
WLAN_CAPABILITY_ESS | WLAN_CAPABILITY_PRIVACY,
capa);
if (!bss)
- return false;
+ return NULL;
memcpy(wdev->conn->bssid, bss->bssid, ETH_ALEN);
wdev->conn->params.bssid = wdev->conn->bssid;
@@ -213,14 +213,14 @@ static bool cfg80211_get_conn_bss(struct
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
schedule_work(&rdev->conn_work);
- cfg80211_put_bss(bss);
- return true;
+ return bss;
}
static void __cfg80211_sme_scan_done(struct net_device *dev)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ struct cfg80211_bss *bss;
ASSERT_WDEV_LOCK(wdev);
@@ -234,7 +234,10 @@ static void __cfg80211_sme_scan_done(str
wdev->conn->state != CFG80211_CONN_SCAN_AGAIN)
return;
- if (!cfg80211_get_conn_bss(wdev)) {
+ bss = cfg80211_get_conn_bss(wdev);
+ if (bss) {
+ cfg80211_put_bss(bss);
+ } else {
/* not found */
if (wdev->conn->state == CFG80211_CONN_SCAN_AGAIN)
schedule_work(&rdev->conn_work);
@@ -670,6 +673,7 @@ int __cfg80211_connect(struct cfg80211_r
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct ieee80211_channel *chan;
+ struct cfg80211_bss *bss = NULL;
int err;
ASSERT_WDEV_LOCK(wdev);
@@ -760,7 +764,7 @@ int __cfg80211_connect(struct cfg80211_r
/* don't care about result -- but fill bssid & channel */
if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
- cfg80211_get_conn_bss(wdev);
+ bss = cfg80211_get_conn_bss(wdev);
wdev->sme_state = CFG80211_SME_CONNECTING;
wdev->connect_keys = connkeys;
@@ -770,10 +774,11 @@ int __cfg80211_connect(struct cfg80211_r
wdev->conn->prev_bssid_valid = true;
}
- /* we're good if we have both BSSID and channel */
- if (wdev->conn->params.bssid && wdev->conn->params.channel) {
+ /* we're good if we have a matching bss struct */
+ if (bss) {
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
err = cfg80211_conn_do_work(wdev);
+ cfg80211_put_bss(bss);
} else {
/* otherwise we'll need to scan for the AP first */
err = cfg80211_conn_scan(wdev);
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Larry Finger @ 2009-09-16 15:52 UTC (permalink / raw)
To: Bryan Wu; +Cc: Gábor Stefanik, mb, linux-wireless
In-Reply-To: <4AB0EDEB.9010803@canonical.com>
Bryan Wu wrote:
> Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
> anything need me to do, please feel free ping me.
Not an issue with 64-bit DMA. Those people with 64-bit DMA problems
get error messages.
Larry
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-16 15:37 UTC (permalink / raw)
To: Mel Gorman
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <20090916150239.GG1993@csn.ul.ie>
On Wednesday 16 September 2009, Mel Gorman wrote:
> > kcryptd: page allocation failure. order:2, mode:0x4020
> > Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
>
> Is this with Reinette Chatre's patch applied or vanilla?
Vanilla.
^ permalink raw reply
* Re: Re[6]: cfg80211 and rfkill_backport question.
From: Hin-Tak Leung @ 2009-09-16 15:24 UTC (permalink / raw)
To: Nikolai ZHUBR
Cc: Luis R. Rodriguez, linux-wireless, Gaurav Jauhar,
Senthil Balasubramanian
In-Reply-To: <1382256815.20090916121443@mail.ru>
On Wed, Sep 16, 2009 at 10:14 AM, Nikolai ZHUBR <zhubr@mail.ru> 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)?
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Gábor Stefanik @ 2009-09-16 15:13 UTC (permalink / raw)
To: Bryan Wu; +Cc: mb, stefano.brivio, linux-wireless
In-Reply-To: <4AB0EDEB.9010803@canonical.com>
2009/9/16 Bryan Wu <bryan.wu@canonical.com>:
> Hi Gabor,
>
> I tried the latest cmpat-wireless 09-16 snapshot on my machine which runs on 2.6.31
> Ubuntu Karmic latest kernel. The hardware probing passes and wlan1 interface shows up.
> But the iwlist scanning got no data from wlan1 interface,
>
> dmesg:
> ---
> [ 364.371703] b43-pci-bridge 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 364.371761] b43-pci-bridge 0000:07:00.0: setting latency timer to 64
> [ 364.437779] ssb: Sonics Silicon Backplane found on PCI device 0000:07:00.0
> [ 364.491488] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
> [ 364.533562] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
> [ 364.533604] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
> [ 364.693040] phy0: Selected rate control algorithm 'minstrel'
> [ 364.701666] Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
> [ 364.748486] udev: renamed network interface wlan0 to wlan1
> [ 364.824296] b43 ssb0:0: firmware: requesting b43/ucode15.fw
> [ 364.901848] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
> [ 364.931482] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
> [ 365.140212] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Please test with v478 or newer.
> [ 365.144349] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
> [ 365.412558] b43-phy0 debug: Chip initialized
> [ 365.413163] b43-phy0 debug: 64-bit DMA initialized
> [ 365.413356] b43-phy0 debug: QoS enabled
Try disabling QoS via modparam. Also, try earlier compat-wireless versions.
> [ 365.434064] Registered led device: b43-phy0::tx
> [ 365.434315] Registered led device: b43-phy0::rx
> [ 365.434545] Registered led device: b43-phy0::radio
> [ 365.435079] b43-phy0 debug: Wireless interface started
> [ 365.435208] b43-phy0 debug: Adding Interface type 2
> ----
>
> ifconfig:
> ---
> $ ifconfig
> eth0 Link encap:Ethernet HWaddr 00:24:e8:bd:c9:3d
> inet addr:10.101.46.6 Bcast:10.101.46.255 Mask:255.255.255.0
> inet6 addr: fe80::224:e8ff:febd:c93d/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:797 errors:0 dropped:0 overruns:0 frame:0
> TX packets:663 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:76364 (76.3 KB) TX bytes:452350 (452.3 KB)
> Interrupt:30 Base address:0xc000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:29 errors:0 dropped:0 overruns:0 frame:0
> TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:6202 (6.2 KB) TX bytes:6202 (6.2 KB)
>
> wlan1 Link encap:Ethernet HWaddr 00:25:56:a0:15:58
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> ---
>
> $ iwconfig wlan1
> wlan1 IEEE 802.11bg Mode:Managed Access Point: Not-Associated
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Power Management:off
>
> $ sudo iwlist wlan1 scanning
> wlan1 No scan results
Use "sudo iw dev wlan1 scan" with mac80211 drivers.
>
> Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
> anything need me to do, please feel free ping me.
>
> Thanks
> -Bryan
>
> Gábor Stefanik wrote:
>> This chip works (though not quite "supported", that is, can't
>> guarantee that it will work for you, and speed is not up to par with
>> wl_hybrid) in wireless-testing. It should also work in
>> compat-wireless, though compat-wireless is having problems with 64-bit
>> DMA lately (probably also affects the G-PHY 4311/02). Specifically,
>> the Dell 1397 (half-mini version of the 1395) and the HP 459263-002
>> are known to work.
>>
>> On Fri, Sep 11, 2009 at 4:22 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
>>> Dear Michael and Stefano,
>>>
>>> I have a project which integrate Broadcom Wifi chip. But the mainline b43 still does not support this chip, because it has Low Power PHY.
>>>
>>> Here is my lspci -vvnn output for this device:
>>> ------
>>> 07:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
>>> Subsystem: Dell Device [1028:000c]
>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 32 bytes
>>> Interrupt: pin A routed to IRQ 17
>>> Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>>> Capabilities: [58] Vendor Specific Information <?>
>>> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
>>> Address: 0000000000000000 Data: 0000
>>> Capabilities: [d0] Express (v1) Endpoint, MSI 00
>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
>>> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>> RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
>>> MaxPayload 128 bytes, MaxReadReq 128 bytes
>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
>>> ClockPM+ Suprise- LLActRep- BwNot-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>>> Kernel driver in use: b43-pci-bridge
>>> Kernel modules: ssb
>>> ------
>>>
>>> Do you guys know how to support this device in 2.6.31 kernel? Need I backport some code from wireless-testing? I enabled the PHY_LP config manually in 2.6.31 kernel and b43 driver recognized the hardware wifi device, but it still
>>> does not work at all.
>>>
>>> Or there is no choice but Broadcom's STA driver? I do not like such non-GPL stuff.
>>>
>>> Thanks a lot
>>> --
>>> Bryan Wu <bryan.wu@canonical.com>
>>> Kernel Developer +86.138-1617-6545 Mobile
>>> Ubuntu Kernel Team | Hardware Enablement Team
>>> Canonical Ltd. www.canonical.com
>>> Ubuntu - Linux for human beings | www.ubuntu.com
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Mel Gorman @ 2009-09-16 15:02 UTC (permalink / raw)
To: Frans Pop
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <200909161636.20590.elendil@planet.nl>
On Wed, Sep 16, 2009 at 04:36:16PM +0200, Frans Pop wrote:
> On Wednesday 09 September 2009, Frans Pop wrote:
> > On Wednesday 09 September 2009, you wrote:
> > > The problem with this theory is that the patches have been in since
> > > Nov 2008 but reports are only showing up now. Frans, how sure are you
> > > that this is a recent problem? Is it readily reproducible?
> >
> > The only thing I can say here is that I've never seen the issue before
> > (and thanks to logcheck I certainly would have).
> > The laptop is in constant use, but I rarely stress the memory like that.
> > Swap is almost always at 0.
>
> JFYI, it happened again yesterday.
> The first time it was swapper, here it's kcryptd. The top part of the
> trace is the same.
>
> kcryptd: page allocation failure. order:2, mode:0x4020
> Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
Is this with Reinette Chatre's patch applied or vanilla?
If vanilla, Reinette, is your patch already upstream or in a subsystem
tree somewhere?
> Call Trace:
> <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a
> [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb
> [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b
> [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
> [<ffffffff81079153>] __get_free_pages+0x12/0x41
> [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec
> [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b
> [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
> [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
> [<ffffffffa037c8e3>] iwl_rx_handle+0x356/0x39a [iwlagn]
> [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
> [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
> [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod]
> [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
> [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
> [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
> [<ffffffff8100e694>] do_softirq+0x34/0x72
> [<ffffffff8103e601>] irq_exit+0x3f/0x79
> [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
> [<ffffffff8100c413>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64]
> [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64]
> [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc]
> [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a
> [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64]
> [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a
> [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113
> [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt]
> [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt]
> [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt]
> [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca
> [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38
> [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca
> [<ffffffff8104c325>] ? kthread+0x8f/0x97
> [<ffffffff8100ca7a>] ? child_rip+0xa/0x20
> [<ffffffff8104c296>] ? kthread+0x0/0x97
> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
> Mem-Info:
> DMA per-cpu:
> CPU 0: hi: 0, btch: 1 usd: 0
> CPU 1: hi: 0, btch: 1 usd: 0
> DMA32 per-cpu:
> CPU 0: hi: 186, btch: 31 usd: 172
> CPU 1: hi: 186, btch: 31 usd: 163
> Active_anon:278449 active_file:18846 inactive_anon:93192
> inactive_file:18343 unevictable:407 dirty:0 writeback:7726 unstable:0
> free:25175 slab:10409 mapped:34634 pagetables:4385 bounce:0
> DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB
> active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0
> all_unreclaimable? no
> lowmem_reserve[]: 0 1976 1976 1976
> DMA32 free:92776kB min:5664kB low:7080kB high:8496kB active_anon:1111448kB inactive_anon:370432kB
> active_file:74300kB inactive_file:71764kB unevictable:1628kB present:2023748kB pages_scanned:32
> all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB
> DMA32: 18882*4kB 2076*8kB 10*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 92776kB
> 82554 total pagecache pages
> 44961 pages in swap cache
> Swap cache stats: add 160004, delete 115046, find 2431510/2434120
> Free swap = 1549576kB
> Total swap = 2097144kB
> 518064 pages RAM
> 10323 pages reserved
> 117029 pages shared
> 398165 pages non-shared
> iwlagn 0000:10:00.0: Can not allocate SKB buffers
> kcryptd: page allocation failure. order:2, mode:0x4020
> Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
> Call Trace:
> <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a
> [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb
> [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b
> [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
> [<ffffffff81079153>] __get_free_pages+0x12/0x41
> [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec
> [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b
> [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
> [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
> [<ffffffffa037c90e>] iwl_rx_handle+0x381/0x39a [iwlagn]
> [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
> [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
> [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod]
> [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
> [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
> [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
> [<ffffffff8100e694>] do_softirq+0x34/0x72
> [<ffffffff8103e601>] irq_exit+0x3f/0x79
> [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
> [<ffffffff8100c413>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64]
> [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64]
> [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc]
> [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a
> [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64]
> [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a
> [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113
> [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt]
> [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt]
> [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt]
> [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca
> [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38
> [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca
> [<ffffffff8104c325>] ? kthread+0x8f/0x97
> [<ffffffff8100ca7a>] ? child_rip+0xa/0x20
> [<ffffffff8104c296>] ? kthread+0x0/0x97
> [<ffffffff8100ca70>] ? child_rip+0x0/0x20
> Mem-Info:
> DMA per-cpu:
> CPU 0: hi: 0, btch: 1 usd: 0
> CPU 1: hi: 0, btch: 1 usd: 0
> DMA32 per-cpu:
> CPU 0: hi: 186, btch: 31 usd: 172
> CPU 1: hi: 186, btch: 31 usd: 173
> Active_anon:277951 active_file:18714 inactive_anon:93068
> inactive_file:18252 unevictable:407 dirty:0 writeback:7726 unstable:0
> free:25861 slab:10409 mapped:34634 pagetables:4385 bounce:0
> DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB
> active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0
> all_unreclaimable? no
> lowmem_reserve[]: 0 1976 1976 1976
> DMA32 free:95520kB min:5664kB low:7080kB high:8496kB active_anon:1109584kB inactive_anon:369808kB
> active_file:73772kB inactive_file:71400kB unevictable:1628kB present:2023748kB pages_scanned:66
> all_unreclaimable? no
> lowmem_reserve[]: 0 0 0 0
> DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB
> DMA32: 19178*4kB 2285*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95520kB
> 81717 total pagecache pages
> 44349 pages in swap cache
> Swap cache stats: add 160008, delete 115659, find 2431510/2434120
> Free swap = 1549560kB
> Total swap = 2097144kB
> 518064 pages RAM
> 10323 pages reserved
> 117031 pages shared
> 398265 pages non-shared
> iwlagn 0000:10:00.0: Can not allocate SKB buffers
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: iwlagn rfkill and 2.6.31 on Intel Corporation PRO/Wireless 5100 AGN
From: Fabio Coatti @ 2009-09-16 14:57 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, mjg
In-Reply-To: <20090916132549.GA10634@tuxdriver.com>
Thanks for the answer;
In fact, it wasn't loaded.
I've inserted that module and the behaviour changed: now the rfkill switch
reacts in the correct way and I'm able to turn on and off bluetooth system.
But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
my side). Basically if the laptop starts with wifi enabled (rfkill off)
wpa_supplicant can establish a connection, that can be killed by rfkill switch
(both wifi and bluetooth seems to be killed). But when I turn off rfkill
switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
can see activity in bt stack, but no messages regarding wlan0.
Any suggestion?
dmeIn data mercoledì 16 settembre 2009 15:25:49, John W. Linville ha scritto:
> Is the hp-wmi module loaded?
>
> On Wed, Sep 16, 2009 at 03:21:15PM +0200, Fabio Coatti wrote:
> > Hi all,
> > I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
> > description:
> >
> > Kernels: 2.6.30.[5,6] 2.6.31
> > Hardware: HP EliteBook 6930p
> >
> > Behaviour: once a working wireless is killed activating the rfkill
> > button, there is no way to turn off the rfkill and riactivate wifi
> > network. Even a reboot is not able to reset the situation; to get again
> > the control of rfkill button is to reboot under windows xp and activate
> > wifi. After that I can boot inder linux with wifi active and kill it with
> > rfkill button and the loop starts again :)
> > I'm pretty sure that this issue is present since some kernel before the
> > one I've reported, but I'm not sure about the versions.
> >
> > I don't know if this is iwlagn or acpi related bug (or my fault), I'm
> > available for any test.
> >
> > HW:
> > Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh]
> > Network Connection
> > Subsystem: Intel Corporation Device 1211
> > Flags: bus master, fast devsel, latency 0, IRQ 33
> > Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
> > Capabilities: [c8] Power Management version 3
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
> > Kernel driver in use: iwlagn
> > Kernel modules: iwlagn
> >
> > Let me know if more information are needed.
> >
> > Thanks for any answer (I'm not subscribed to this list, so please CC me
> > on answers, thanks)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> > 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
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-16 14:36 UTC (permalink / raw)
To: Mel Gorman
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <200909091919.16461.elendil@planet.nl>
On Wednesday 09 September 2009, Frans Pop wrote:
> On Wednesday 09 September 2009, you wrote:
> > The problem with this theory is that the patches have been in since
> > Nov 2008 but reports are only showing up now. Frans, how sure are you
> > that this is a recent problem? Is it readily reproducible?
>
> The only thing I can say here is that I've never seen the issue before
> (and thanks to logcheck I certainly would have).
> The laptop is in constant use, but I rarely stress the memory like that.
> Swap is almost always at 0.
JFYI, it happened again yesterday.
The first time it was swapper, here it's kcryptd. The top part of the
trace is the same.
kcryptd: page allocation failure. order:2, mode:0x4020
Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
Call Trace:
<IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a
[<ffffffff81256a62>] ? _spin_unlock+0x9/0xb
[<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b
[<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
[<ffffffff81079153>] __get_free_pages+0x12/0x41
[<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec
[<ffffffff811da4ab>] __alloc_skb+0x66/0x15b
[<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
[<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
[<ffffffffa037c8e3>] iwl_rx_handle+0x356/0x39a [iwlagn]
[<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
[<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
[<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod]
[<ffffffff8103dff0>] tasklet_action+0x71/0xbc
[<ffffffff8103e877>] __do_softirq+0x9b/0x12c
[<ffffffff8100cb7c>] call_softirq+0x1c/0x28
[<ffffffff8100e694>] do_softirq+0x34/0x72
[<ffffffff8103e601>] irq_exit+0x3f/0x79
[<ffffffff8100dd95>] do_IRQ+0xa3/0xba
[<ffffffff8100c413>] ret_from_intr+0x0/0xa
<EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64]
[<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64]
[<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc]
[<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a
[<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64]
[<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a
[<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113
[<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt]
[<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt]
[<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt]
[<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca
[<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38
[<ffffffff81048a93>] ? worker_thread+0x0/0x1ca
[<ffffffff8104c325>] ? kthread+0x8f/0x97
[<ffffffff8100ca7a>] ? child_rip+0xa/0x20
[<ffffffff8104c296>] ? kthread+0x0/0x97
[<ffffffff8100ca70>] ? child_rip+0x0/0x20
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 172
CPU 1: hi: 186, btch: 31 usd: 163
Active_anon:278449 active_file:18846 inactive_anon:93192
inactive_file:18343 unevictable:407 dirty:0 writeback:7726 unstable:0
free:25175 slab:10409 mapped:34634 pagetables:4385 bounce:0
DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB
active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 1976 1976 1976
DMA32 free:92776kB min:5664kB low:7080kB high:8496kB active_anon:1111448kB inactive_anon:370432kB
active_file:74300kB inactive_file:71764kB unevictable:1628kB present:2023748kB pages_scanned:32
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB
DMA32: 18882*4kB 2076*8kB 10*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 92776kB
82554 total pagecache pages
44961 pages in swap cache
Swap cache stats: add 160004, delete 115046, find 2431510/2434120
Free swap = 1549576kB
Total swap = 2097144kB
518064 pages RAM
10323 pages reserved
117029 pages shared
398165 pages non-shared
iwlagn 0000:10:00.0: Can not allocate SKB buffers
kcryptd: page allocation failure. order:2, mode:0x4020
Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
Call Trace:
<IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a
[<ffffffff81256a62>] ? _spin_unlock+0x9/0xb
[<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b
[<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
[<ffffffff81079153>] __get_free_pages+0x12/0x41
[<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec
[<ffffffff811da4ab>] __alloc_skb+0x66/0x15b
[<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
[<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
[<ffffffffa037c90e>] iwl_rx_handle+0x381/0x39a [iwlagn]
[<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
[<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
[<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod]
[<ffffffff8103dff0>] tasklet_action+0x71/0xbc
[<ffffffff8103e877>] __do_softirq+0x9b/0x12c
[<ffffffff8100cb7c>] call_softirq+0x1c/0x28
[<ffffffff8100e694>] do_softirq+0x34/0x72
[<ffffffff8103e601>] irq_exit+0x3f/0x79
[<ffffffff8100dd95>] do_IRQ+0xa3/0xba
[<ffffffff8100c413>] ret_from_intr+0x0/0xa
<EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64]
[<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64]
[<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc]
[<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a
[<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64]
[<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a
[<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113
[<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt]
[<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt]
[<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt]
[<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca
[<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38
[<ffffffff81048a93>] ? worker_thread+0x0/0x1ca
[<ffffffff8104c325>] ? kthread+0x8f/0x97
[<ffffffff8100ca7a>] ? child_rip+0xa/0x20
[<ffffffff8104c296>] ? kthread+0x0/0x97
[<ffffffff8100ca70>] ? child_rip+0x0/0x20
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 172
CPU 1: hi: 186, btch: 31 usd: 173
Active_anon:277951 active_file:18714 inactive_anon:93068
inactive_file:18252 unevictable:407 dirty:0 writeback:7726 unstable:0
free:25861 slab:10409 mapped:34634 pagetables:4385 bounce:0
DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB
active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 1976 1976 1976
DMA32 free:95520kB min:5664kB low:7080kB high:8496kB active_anon:1109584kB inactive_anon:369808kB
active_file:73772kB inactive_file:71400kB unevictable:1628kB present:2023748kB pages_scanned:66
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB
DMA32: 19178*4kB 2285*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95520kB
81717 total pagecache pages
44349 pages in swap cache
Swap cache stats: add 160008, delete 115659, find 2431510/2434120
Free swap = 1549560kB
Total swap = 2097144kB
518064 pages RAM
10323 pages reserved
117031 pages shared
398265 pages non-shared
iwlagn 0000:10:00.0: Can not allocate SKB buffers
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Bryan Wu @ 2009-09-16 13:53 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: mb, stefano.brivio, linux-wireless
In-Reply-To: <69e28c910909102318u465f6c75w46a2404a8e8d9f08@mail.gmail.com>
Hi Gabor,
I tried the latest cmpat-wireless 09-16 snapshot on my machine which runs on 2.6.31
Ubuntu Karmic latest kernel. The hardware probing passes and wlan1 interface shows up.
But the iwlist scanning got no data from wlan1 interface,
dmesg:
---
[ 364.371703] b43-pci-bridge 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 364.371761] b43-pci-bridge 0000:07:00.0: setting latency timer to 64
[ 364.437779] ssb: Sonics Silicon Backplane found on PCI device 0000:07:00.0
[ 364.491488] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[ 364.533562] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
[ 364.533604] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
[ 364.693040] phy0: Selected rate control algorithm 'minstrel'
[ 364.701666] Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
[ 364.748486] udev: renamed network interface wlan0 to wlan1
[ 364.824296] b43 ssb0:0: firmware: requesting b43/ucode15.fw
[ 364.901848] b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
[ 364.931482] b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
[ 365.140212] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[ 365.144349] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[ 365.412558] b43-phy0 debug: Chip initialized
[ 365.413163] b43-phy0 debug: 64-bit DMA initialized
[ 365.413356] b43-phy0 debug: QoS enabled
[ 365.434064] Registered led device: b43-phy0::tx
[ 365.434315] Registered led device: b43-phy0::rx
[ 365.434545] Registered led device: b43-phy0::radio
[ 365.435079] b43-phy0 debug: Wireless interface started
[ 365.435208] b43-phy0 debug: Adding Interface type 2
----
ifconfig:
---
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:24:e8:bd:c9:3d
inet addr:10.101.46.6 Bcast:10.101.46.255 Mask:255.255.255.0
inet6 addr: fe80::224:e8ff:febd:c93d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:797 errors:0 dropped:0 overruns:0 frame:0
TX packets:663 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:76364 (76.3 KB) TX bytes:452350 (452.3 KB)
Interrupt:30 Base address:0xc000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:29 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6202 (6.2 KB) TX bytes:6202 (6.2 KB)
wlan1 Link encap:Ethernet HWaddr 00:25:56:a0:15:58
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
---
$ iwconfig wlan1
wlan1 IEEE 802.11bg Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
$ sudo iwlist wlan1 scanning
wlan1 No scan results
Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
anything need me to do, please feel free ping me.
Thanks
-Bryan
Gábor Stefanik wrote:
> This chip works (though not quite "supported", that is, can't
> guarantee that it will work for you, and speed is not up to par with
> wl_hybrid) in wireless-testing. It should also work in
> compat-wireless, though compat-wireless is having problems with 64-bit
> DMA lately (probably also affects the G-PHY 4311/02). Specifically,
> the Dell 1397 (half-mini version of the 1395) and the HP 459263-002
> are known to work.
>
> On Fri, Sep 11, 2009 at 4:22 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
>> Dear Michael and Stefano,
>>
>> I have a project which integrate Broadcom Wifi chip. But the mainline b43 still does not support this chip, because it has Low Power PHY.
>>
>> Here is my lspci -vvnn output for this device:
>> ------
>> 07:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
>> Subsystem: Dell Device [1028:000c]
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 17
>> Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>> Capabilities: [58] Vendor Specific Information <?>
>> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
>> Address: 0000000000000000 Data: 0000
>> Capabilities: [d0] Express (v1) Endpoint, MSI 00
>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
>> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
>> MaxPayload 128 bytes, MaxReadReq 128 bytes
>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
>> ClockPM+ Suprise- LLActRep- BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> Kernel driver in use: b43-pci-bridge
>> Kernel modules: ssb
>> ------
>>
>> Do you guys know how to support this device in 2.6.31 kernel? Need I backport some code from wireless-testing? I enabled the PHY_LP config manually in 2.6.31 kernel and b43 driver recognized the hardware wifi device, but it still
>> does not work at all.
>>
>> Or there is no choice but Broadcom's STA driver? I do not like such non-GPL stuff.
>>
>> Thanks a lot
>> --
>> Bryan Wu <bryan.wu@canonical.com>
>> Kernel Developer +86.138-1617-6545 Mobile
>> Ubuntu Kernel Team | Hardware Enablement Team
>> Canonical Ltd. www.canonical.com
>> Ubuntu - Linux for human beings | www.ubuntu.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox