* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Helmut Schaa @ 2010-05-06 18:38 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <s2ma32f33a41005061001w5e7258f0p3715ec238a00a4f4@mail.gmail.com>
Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> > used by the Ralink driver nor specified in 802.11.
> >
> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> > for CCK SIFS value.
> >
> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> > Ralink drivers).
>
> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
> Perhaps we should remove it in there, and no longer pass it from
> rt2x00lib. That way there can't be any confusion about which drivers
> uses the sifs field and whcih do not.
Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
value, so we could just leave the define in rt2x00.h and remove the sifs value
from the config_erp calback and use the define in all other places?
Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
working correctly with it set to 10 (the actual data frame was sent out
way too late after the CTS frame, somtimes with delays >100us). Using the 16us
also for CCK (as the ralink drivers do) results in perfect CTS & data frame
timing. Maybe it's a hardware issue and the (ralink) driver just works around
it?
Helmut
^ permalink raw reply
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Gertjan van Wingerde @ 2010-05-06 18:32 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.58509.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> rt2800 devices use a different enumeration to specify what IFS values should
> be used on frame transmission compared to the other rt2x00 devices. Hence,
> create a new enum called txop that contains the valid values.
>
> Furthermore use TXOP_HTTXOP as default on HT devices which means that the
> hardware should select the correct IFS value on its own.
>
> I'm not sure if we have the need to specify one of the other txop values
> in the future but as far as I could see TXOP_HTTXOP is used by the Ralink
> drivers for all normal data frames and should be a reasonable default.
>
> This patch doesn't really fix anything as until now the IFS_BACKOFF(=0)
> value was used as txop which luckily mapped to TXOP_HTTXOP(=0).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2x00ht.c | 2 ++
> drivers/net/wireless/rt2x00/rt2x00queue.h | 2 ++
> drivers/net/wireless/rt2x00/rt2x00reg.h | 10 ++++++++++
> 5 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index f08b6a3..df2c3fb 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -643,7 +643,7 @@ static int rt2800pci_write_tx_data(struct queue_entry* entry,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index e3f3a97..c9e1320 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -417,7 +417,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> index 1056c92..5483fec 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> +
> + txdesc->txop = TXOP_HTTXOP;
> }
I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
> index 94a48c1..36a957a 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00queue.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
> @@ -299,6 +299,7 @@ enum txentry_desc_flags {
> * @retry_limit: Max number of retries.
> * @aifs: AIFS value.
> * @ifs: IFS value.
> + * @txop: IFS value for 11n capable chips.
> * @cw_min: cwmin value.
> * @cw_max: cwmax value.
> * @cipher: Cipher type used for encryption.
> @@ -328,6 +329,7 @@ struct txentry_desc {
> short retry_limit;
> short aifs;
> short ifs;
> + short txop;
> short cw_min;
> short cw_max;
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00reg.h b/drivers/net/wireless/rt2x00/rt2x00reg.h
> index 603bfc0..894ff78 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00reg.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00reg.h
> @@ -101,6 +101,16 @@ enum ifs {
> };
>
> /*
> + * IFS values for HT devices
> + */
> +enum txop {
> + TXOP_HTTXOP = 0,
> + TXOP_PIFS = 1,
> + TXOP_SIFS = 2,
> + TXOP_BACKOFF = 3,
> +};
> +
> +/*
> * Cipher types for hardware encryption
> */
> enum cipher {
^ permalink raw reply
* Re: 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Valdis.Kletnieks @ 2010-05-06 18:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Andrew Morton, David S. Miller, John W. Linville, linux-kernel,
netdev, linux-wireless
In-Reply-To: <1273168696.23199.0.camel@jlt3.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Thu, 06 May 2010 19:58:16 +0200, Johannes Berg said:
> On Thu, 2010-05-06 at 13:35 -0400, Valdis.Kletnieks@vt.edu wrote:
> > Spotted these in my dmesg, hopefully somebody is interested...
> >
> > [ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
> > [ 54.080580]
> > [ 54.080581] ===================================================
> > [ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 54.080586] ---------------------------------------------------
> > [ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
>
> I'm pretty sure I fixed those so there should be a patch on its way to
> or in mainline somewhere.
Oh, OK. I didn't remember seeing them mentioned before, but I must have
missed somebody else's post about it due to the lkml firehose effect. I've
moved these to my "whinge if it isn't fixed in the next -mmotm" queue.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: John W. Linville @ 2010-05-06 18:22 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <1273162268.2226.2503.camel@rchatre-DESK>
On Thu, May 06, 2010 at 09:11:08AM -0700, reinette chatre wrote:
> On Mon, 2010-05-03 at 10:55 -0700, reinette chatre wrote:
> > From: Reinette Chatre <reinette.chatre@intel.com>
> >
> > We currently have this check as a BUG_ON, which is being hit by people.
> > Previously it was an error with a recalculation if not current, return that
> > code.
> >
> > The BUG_ON was introduced by:
> > commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
> > Author: Guy Cohen <guy.cohen@intel.com>
> > Date: Tue Sep 9 10:54:54 2008 +0800
> >
> > iwlwifi: Added support for 3 antennas
> >
> > ... the portion adding the BUG_ON is reverted since we are encountering the error
> > and BUG_ON was created with assumption that error is not encountered.
> >
> > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> > ---
>
> I noticed this patch in your wireless-next-2.6 pull request. Since it is
> addressing a system hang issue, could it perhaps be included in
> wireless-2.6 also? I should have included the bug report reference for
> this purpose, sorry ... it is
> https://bugzilla.redhat.com/show_bug.cgi?id=588021
I didn't send it that way because a) that code has been there for a
really long time; and b) the reporter couldn't reliably reproduce
the bug and therefore can't reliably test the fix. While I agree
that the fix looks harmless, no update is zero-risk.
Can you reliably hit that code? Has it been tested enough that we
should risk holding-up 2.6.34's release for it?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: Larry Finger @ 2010-05-06 18:20 UTC (permalink / raw)
To: seno; +Cc: linux-wireless
In-Reply-To: <loom.20100506T185847-345@post.gmane.org>
On 05/06/2010 12:36 PM, seno wrote:
> Hi Larry,
>
> I'm running Mandriva 2010 x86_64 (2.6.31.13) and have a 8187b chipset installed:
>
> 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network
> Adapter
>
> As many other linux users report, this chipset is supported but offers only
> limited performance, especially compared to results when using windows.
>
> Some time ago I connected to a Linksys wrt 54 GL router with Linksys firmware
> and recently I installed DD-wrt on that router, but perfomance remaind at the
> same (poor) level; meaning there must be something wrong with the rtl8187 linux
> modul.
>
> Right now the router is ~10 meters away and iwconfig wlan0 output is
>
> IEEE 802.11bg ESSID:"xxx"
> Mode:Managed Frequency:2.412 GHz Access Point: 00:14:BF:4A:ED:F9
> Bit Rate=18 Mb/s Tx-Power=27 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx [3]
> Power Management:off
> Link Quality=70/70 Signal level=-33 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Right after booting, I can reach a wireless download rate of ~ 10mbit/s (I have
> 10 mbit cable internet). After a while, it seems that the wireless rate drops
> to 1 mbit/s although iwconfig wlan0 stills shows a bit rate of 11 or 18 mbit/s.
> That means, I get stuck at a download speed of ~ 130 K/s -unless I come closer
> to the router, 1 meter ie, then the wireless speed goes up again.
>
> The router status shows
>
> Wireless Packet Info
> Received (RX)
> 45915806 OK, 10 errors
> Transmitted (TX)
> 81142592 OK, 746 errors
>
> If the machine with the 8187b chip is connected, I get a lot of TX errors on
> the router.
>
> While linux shows good connection quality, the router indicates a bad signal
> quality:
>
> Signal Noise SNR Signal Quality
> -74 -94 20 24%
>
> -I installed the latest package from linux wireless, driver loaded but for some
> reason it was not able to connect to a wpa2 network (iwconfig wlan0 never shot
> enc key), so I uninstalled that again.
> -I booted a Mandirva 2010.0 x86 live cd to see if the problem is the same on 32
> bit system, and yes, it is.
> -I found a 'newer' driver rtl8187B_linux_26.1056.1112.2009.release.tar.gz on
> ubuntu forum - compiled, installed but for any reason driver did not load
> correctly and something ooopsed (I blacklisted rtl8187 and set r8187 as alias
> for wlan0).
>
> Any idea what I could do to get some better performance with the 8187b chipset?
I do not understand the poor performance. I have a device with the
rtl8187b chip - USB IDs 0bda:8187. That is an ID for an rtl8187, but it
does have the B chip. I use tcpperf to measure the transmit speed. At 2
m from the AP with an indicated signal of -17 dBm, my throughput is 13
Mb/s. At 10 m with a signal of -49 dBm, the transmit speed is 3.5 Mb/s.
On the download using speedtest.net, I got 11.3 Mb/s at 2 m, and 2.64 at
10 m. I got 0.49 Mb/s upload at both distances as that is the speed of
my line.
What happens if you use iwconfig to force a particular rate? At what
setting is your throughput maximized. I don't think there is a problem
with the rate setting mechanism, but that would test it.
Larry
^ permalink raw reply
* Re: The case of the bogus SSID
From: Steve deRosier @ 2010-05-06 18:12 UTC (permalink / raw)
To: pigiron; +Cc: linux-wireless
In-Reply-To: <20100505120131.2b9f4e06@atom.pigiron.org>
On Wed, May 5, 2010 at 10:01 AM, pigiron <pigiron@gmx.com> wrote:
> I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the ieee80211.h file, and recently the same 52 was also assigned to WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
>
I can't answer the rest of your question, but AFAIK, the element IDs
for 802.11s mesh haven't been approved yet as the 802.11s draft
contains a note to that effect. The current ANA database sheet I
could find (Feb 2010) does have 52 assigned to Neighbor Report, and
the mesh element IDs are nowhere to be found.
- Steve
^ permalink raw reply
* Re: 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Johannes Berg @ 2010-05-06 17:58 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, David S. Miller, John W. Linville, linux-kernel,
netdev, linux-wireless
In-Reply-To: <5820.1273167313@localhost>
On Thu, 2010-05-06 at 13:35 -0400, Valdis.Kletnieks@vt.edu wrote:
> Spotted these in my dmesg, hopefully somebody is interested...
>
> [ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
> [ 54.080580]
> [ 54.080581] ===================================================
> [ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 54.080586] ---------------------------------------------------
> [ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
I'm pretty sure I fixed those so there should be a patch on its way to
or in mainline somewhere.
johannes
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: seno @ 2010-05-06 17:36 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BB7660A.3030900@lwfinger.net>
Hi Larry,
I'm running Mandriva 2010 x86_64 (2.6.31.13) and have a 8187b chipset installed:
0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network
Adapter
As many other linux users report, this chipset is supported but offers only
limited performance, especially compared to results when using windows.
Some time ago I connected to a Linksys wrt 54 GL router with Linksys firmware
and recently I installed DD-wrt on that router, but perfomance remaind at the
same (poor) level; meaning there must be something wrong with the rtl8187 linux
modul.
Right now the router is ~10 meters away and iwconfig wlan0 output is
IEEE 802.11bg ESSID:"xxx"
Mode:Managed Frequency:2.412 GHz Access Point: 00:14:BF:4A:ED:F9
Bit Rate=18 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx [3]
Power Management:off
Link Quality=70/70 Signal level=-33 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Right after booting, I can reach a wireless download rate of ~ 10mbit/s (I have
10 mbit cable internet). After a while, it seems that the wireless rate drops
to 1 mbit/s although iwconfig wlan0 stills shows a bit rate of 11 or 18 mbit/s.
That means, I get stuck at a download speed of ~ 130 K/s -unless I come closer
to the router, 1 meter ie, then the wireless speed goes up again.
The router status shows
Wireless Packet Info
Received (RX)
45915806 OK, 10 errors
Transmitted (TX)
81142592 OK, 746 errors
If the machine with the 8187b chip is connected, I get a lot of TX errors on
the router.
While linux shows good connection quality, the router indicates a bad signal
quality:
Signal Noise SNR Signal Quality
-74 -94 20 24%
-I installed the latest package from linux wireless, driver loaded but for some
reason it was not able to connect to a wpa2 network (iwconfig wlan0 never shot
enc key), so I uninstalled that again.
-I booted a Mandirva 2010.0 x86 live cd to see if the problem is the same on 32
bit system, and yes, it is.
-I found a 'newer' driver rtl8187B_linux_26.1056.1112.2009.release.tar.gz on
ubuntu forum - compiled, installed but for any reason driver did not load
correctly and something ooopsed (I blacklisted rtl8187 and set r8187 as alias
for wlan0).
Any idea what I could do to get some better performance with the 8187b chipset?
^ permalink raw reply
* 2.6.34-rc5-mmotm0428 - 2 RCU whinges in mac80211
From: Valdis.Kletnieks @ 2010-05-06 17:35 UTC (permalink / raw)
To: Andrew Morton, Johannes Berg, David S. Miller, John W. Linville
Cc: linux-kernel, netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 5105 bytes --]
Spotted these in my dmesg, hopefully somebody is interested...
[ 54.076863] wlan0: deauthenticating from 00:11:20:a4:4c:11 by local choice (reason=3)
[ 54.080580]
[ 54.080581] ===================================================
[ 54.080584] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 54.080586] ---------------------------------------------------
[ 54.080589] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
[ 54.080591]
[ 54.080591] other info that might help us debug this:
[ 54.080592]
[ 54.080594]
[ 54.080595] rcu_scheduler_active = 1, debug_locks = 1
[ 54.080597] no locks held by hald/3362.
[ 54.080599]
[ 54.080599] stack backtrace:
[ 54.080602] Pid: 3362, comm: hald Not tainted 2.6.34-rc5-mmotm0428 #1
[ 54.080604] Call Trace:
[ 54.080607] <IRQ> [<ffffffff81064eb9>] lockdep_rcu_dereference+0x9d/0xa5
[ 54.080619] [<ffffffff815649f9>] ieee80211_find_sta_by_hw+0x46/0x10f
[ 54.080623] [<ffffffff81564ad9>] ieee80211_find_sta+0x17/0x19
[ 54.080628] [<ffffffff8136e1ee>] iwlagn_tx_queue_reclaim+0xe7/0x1bd
[ 54.080632] [<ffffffff81371da3>] iwlagn_rx_reply_tx+0x4e9/0x5a6
[ 54.080638] [<ffffffff8136501f>] iwl_rx_handle+0x268/0x3fe
[ 54.080642] [<ffffffff813664ea>] iwl_irq_tasklet+0x2d3/0x3e4
[ 54.080647] [<ffffffff8103e337>] tasklet_action+0x79/0xd7
[ 54.080651] [<ffffffff8103fd54>] __do_softirq+0x15a/0x2a2
[ 54.080656] [<ffffffff8100358c>] call_softirq+0x1c/0x34
[ 54.080659] [<ffffffff81004ad8>] do_softirq+0x44/0xf0
[ 54.080663] [<ffffffff8103f3ba>] irq_exit+0x4a/0xb3
[ 54.080667] [<ffffffff81004211>] do_IRQ+0xa7/0xbe
[ 54.080671] [<ffffffff8159cd93>] ret_from_intr+0x0/0xf
[ 54.080673] <EOI>
[ 54.114898] wlan0: authenticate with 00:11:20:a4:4c:11 (try 1)
[ 54.122103] wlan0: authenticated
[ 54.122472] wlan0: associate with 00:11:20:a4:4c:11 (try 1)
[ 54.128267] wlan0: RX AssocResp from 00:11:20:a4:4c:11 (capab=0x31 status=0 aid=10)
[ 54.128271] wlan0: associated
[ 54.132990] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 54.133333] cfg80211: Calling CRDA for country: US
[ 54.135752]
[ 54.135753] ===================================================
[ 54.135756] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 54.135758] ---------------------------------------------------
[ 54.135760] net/mac80211/sta_info.c:858 invoked rcu_dereference_check() without protection!
[ 54.135763]
[ 54.135763] other info that might help us debug this:
[ 54.135764]
[ 54.135766]
[ 54.135767] rcu_scheduler_active = 1, debug_locks = 1
[ 54.135769] 1 lock held by udevd/2933:
[ 54.135771] #0: (policy_rwlock){.+.+..}, at: [<ffffffff811d4f60>] security_compute_av+0x29/0x259
[ 54.135781]
[ 54.135782] stack backtrace:
[ 54.135785] Pid: 2933, comm: udevd Not tainted 2.6.34-rc5-mmotm0428 #1
[ 54.135787] Call Trace:
[ 54.135790] <IRQ> [<ffffffff81064eb9>] lockdep_rcu_dereference+0x9d/0xa5
[ 54.135800] [<ffffffff81564a49>] ieee80211_find_sta_by_hw+0x96/0x10f
[ 54.135804] [<ffffffff81564ad9>] ieee80211_find_sta+0x17/0x19
[ 54.135809] [<ffffffff8136e1ee>] iwlagn_tx_queue_reclaim+0xe7/0x1bd
[ 54.135813] [<ffffffff81371da3>] iwlagn_rx_reply_tx+0x4e9/0x5a6
[ 54.135819] [<ffffffff8136501f>] iwl_rx_handle+0x268/0x3fe
[ 54.135823] [<ffffffff813664ea>] iwl_irq_tasklet+0x2d3/0x3e4
[ 54.135828] [<ffffffff8103e337>] tasklet_action+0x79/0xd7
[ 54.135832] [<ffffffff8103fd54>] __do_softirq+0x15a/0x2a2
[ 54.135837] [<ffffffff8100358c>] call_softirq+0x1c/0x34
[ 54.135841] [<ffffffff81004ad8>] do_softirq+0x44/0xf0
[ 54.135844] [<ffffffff8103f3ba>] irq_exit+0x4a/0xb3
[ 54.135847] [<ffffffff81004211>] do_IRQ+0xa7/0xbe
[ 54.135852] [<ffffffff8159cd93>] ret_from_intr+0x0/0xf
[ 54.135854] <EOI> [<ffffffff811ce48b>] ? avtab_search_node+0x6c/0x7b
[ 54.135862] [<ffffffff811d4cdb>] context_struct_compute_av+0x136/0x271
[ 54.135867] [<ffffffff811d506b>] security_compute_av+0x134/0x259
[ 54.135872] [<ffffffff811c2560>] avc_has_perm_noaudit+0x22e/0x537
[ 54.135876] [<ffffffff811c289f>] avc_has_perm+0x36/0x69
[ 54.135880] [<ffffffff810c52cd>] ? __do_fault+0x254/0x3f1
[ 54.135885] [<ffffffff811c4bca>] current_has_perm+0x3a/0x3f
[ 54.135888] [<ffffffff811c4c7d>] selinux_task_create+0x17/0x19
[ 54.135893] [<ffffffff811beced>] security_task_create+0x11/0x13
[ 54.135898] [<ffffffff81036dae>] copy_process+0x8d/0x11ed
[ 54.135901] [<ffffffff810c5434>] ? __do_fault+0x3bb/0x3f1
[ 54.135905] [<ffffffff8107c26b>] ? rcu_read_lock+0x0/0x35
[ 54.135909] [<ffffffff810380b2>] do_fork+0x1a4/0x3b5
[ 54.135913] [<ffffffff8107c2c1>] ? rcu_read_unlock+0x21/0x23
[ 54.135917] [<ffffffff8107dc56>] ? audit_filter_syscall+0xb4/0xc8
[ 54.135921] [<ffffffff81059044>] ? up_read+0x1e/0x36
[ 54.135924] [<ffffffff8105d760>] ? current_kernel_time+0x28/0x50
[ 54.135929] [<ffffffff81009705>] sys_clone+0x23/0x25
[ 54.135933] [<ffffffff810029d3>] stub_clone+0x13/0x20
[ 54.135936] [<ffffffff8100266b>] ? system_call_fastpath+0x16/0x1b
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00: rt2800: don't overwrite SIFS values on erp changes
From: Ivo Van Doorn @ 2010-05-06 17:02 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005061229.44923.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> The SIFS value is a constant and doesn't need to be updated on erp changes.
> Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
> which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
> initial SIFS values" for details).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index f786068..858455f 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -640,8 +640,6 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp)
> rt2800_register_write(rt2x00dev, BKOFF_SLOT_CFG, reg);
>
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, erp->sifs);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, erp->sifs);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, erp->eifs);
> rt2800_register_write(rt2x00dev, XIFS_TIME_CFG, reg);
>
> --
> 1.6.4.2
>
>
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Ivo Van Doorn @ 2010-05-06 17:01 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005061229.04897.helmut.schaa@googlemail.com>
On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> used by the Ralink driver nor specified in 802.11.
>
> Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> for CCK SIFS value.
>
> The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> Ralink drivers).
Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
Perhaps we should remove it in there, and no longer pass it from
rt2x00lib. That way there can't be any confusion about which drivers
uses the sifs field and whcih do not.
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
But that is really a different issue then this fix. So:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..f786068 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1415,9 +1415,16 @@ int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
>
> rt2800_register_write(rt2x00dev, EXP_ACK_TIME, 0x002400ca);
>
> + /*
> + * Usually the CCK SIFS time should be set to 10 and the OFDM SIFS
> + * time should be set to 16. However, the original Ralink driver uses
> + * 16 for both and indeed using a value of 10 for CCK SIFS results in
> + * connection problems with 11g + CTS protection. Hence, use the same
> + * defaults as the Ralink driver: 16 for both, CCK and OFDM SIFS.
> + */
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 32);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 32);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 16);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 16);
> rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_XIFS_TIME, 4);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, 314);
> rt2x00_set_field32(®, XIFS_TIME_CFG_BB_RXEND_ENABLE, 1);
> --
> 1.6.4.2
>
>
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00: rt2800: don't overwrite SIFS values on erp changes
From: Gertjan van Wingerde @ 2010-05-06 16:59 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.44923.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> The SIFS value is a constant and doesn't need to be updated on erp changes.
> Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
> which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
> initial SIFS values" for details).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index f786068..858455f 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -640,8 +640,6 @@ void rt2800_config_erp(struct rt2x00_dev *rt2x00dev, struct rt2x00lib_erp *erp)
> rt2800_register_write(rt2x00dev, BKOFF_SLOT_CFG, reg);
>
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, erp->sifs);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, erp->sifs);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, erp->eifs);
> rt2800_register_write(rt2x00dev, XIFS_TIME_CFG, reg);
>
^ permalink raw reply
* Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values
From: Gertjan van Wingerde @ 2010-05-06 16:57 UTC (permalink / raw)
To: Helmut Schaa, John Linville; +Cc: linux-wireless, Ivo van Doorn
In-Reply-To: <201005061229.04897.helmut.schaa@googlemail.com>
On 05/06/10 12:29, Helmut Schaa wrote:
> Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
> used by the Ralink driver nor specified in 802.11.
>
> Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
> Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
> 11g + CTS protected connections. Add a comment to the code why we don't use 10us
> for CCK SIFS value.
>
> The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
> Ralink drivers).
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..f786068 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1415,9 +1415,16 @@ int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
>
> rt2800_register_write(rt2x00dev, EXP_ACK_TIME, 0x002400ca);
>
> + /*
> + * Usually the CCK SIFS time should be set to 10 and the OFDM SIFS
> + * time should be set to 16. However, the original Ralink driver uses
> + * 16 for both and indeed using a value of 10 for CCK SIFS results in
> + * connection problems with 11g + CTS protection. Hence, use the same
> + * defaults as the Ralink driver: 16 for both, CCK and OFDM SIFS.
> + */
> rt2800_register_read(rt2x00dev, XIFS_TIME_CFG, ®);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 32);
> - rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 32);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_CCKM_SIFS_TIME, 16);
> + rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_SIFS_TIME, 16);
> rt2x00_set_field32(®, XIFS_TIME_CFG_OFDM_XIFS_TIME, 4);
> rt2x00_set_field32(®, XIFS_TIME_CFG_EIFS, 314);
> rt2x00_set_field32(®, XIFS_TIME_CFG_BB_RXEND_ENABLE, 1);
^ permalink raw reply
* Re: [PATCH] rt2x00: Fix RF3052 channel initialization
From: Gertjan van Wingerde @ 2010-05-06 16:49 UTC (permalink / raw)
To: Ivo van Doorn, John Linville; +Cc: linux-wireless, users
In-Reply-To: <201005061445.47170.IvDoorn@gmail.com>
On 05/06/10 14:45, Ivo van Doorn wrote:
> Update channel initialization for the RF3052 chipset.
> According to the Ralink drivers, the rt3x array must be
> used for this chipset, rather then the rt2x array.
>
> Furthermore RF3052 supports the 5GHz band, extend
> the rt3x array with the 5GHz channels, and use them
> for the RF3052 chip.
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 67 ++++++++++++++++++++++++++----
> 1 files changed, 58 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index e37bbea..6c0abc3 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2219,7 +2219,7 @@ int rt2800_init_eeprom(struct rt2x00_dev *rt2x00dev)
> EXPORT_SYMBOL_GPL(rt2800_init_eeprom);
>
> /*
> - * RF value list for rt28x0
> + * RF value list for rt28xx
> * Supports: 2.4 GHz (all) & 5.2 GHz (RF2850 & RF2750)
> */
> static const struct rf_channel rf_vals[] = {
> @@ -2294,10 +2294,10 @@ static const struct rf_channel rf_vals[] = {
> };
>
> /*
> - * RF value list for rt3070
> - * Supports: 2.4 GHz
> + * RF value list for rt3xxx
> + * Supports: 2.4 GHz (all) & 5.2 GHz (RF3052)
> */
> -static const struct rf_channel rf_vals_302x[] = {
> +static const struct rf_channel rf_vals_3x[] = {
> {1, 241, 2, 2 },
> {2, 241, 2, 7 },
> {3, 242, 2, 2 },
> @@ -2312,6 +2312,51 @@ static const struct rf_channel rf_vals_302x[] = {
> {12, 246, 2, 7 },
> {13, 247, 2, 2 },
> {14, 248, 2, 4 },
> +
> + /* 802.11 UNI / HyperLan 2 */
> + {36, 0x56, 0, 4},
> + {38, 0x56, 0, 6},
> + {40, 0x56, 0, 8},
> + {44, 0x57, 0, 0},
> + {46, 0x57, 0, 2},
> + {48, 0x57, 0, 4},
> + {52, 0x57, 0, 8},
> + {54, 0x57, 0, 10},
> + {56, 0x58, 0, 0},
> + {60, 0x58, 0, 4},
> + {62, 0x58, 0, 6},
> + {64, 0x58, 0, 8},
> +
> + /* 802.11 HyperLan 2 */
> + {100, 0x5b, 0, 8},
> + {102, 0x5b, 0, 10},
> + {104, 0x5c, 0, 0},
> + {108, 0x5c, 0, 4},
> + {110, 0x5c, 0, 6},
> + {112, 0x5c, 0, 8},
> + {116, 0x5d, 0, 0},
> + {118, 0x5d, 0, 2},
> + {120, 0x5d, 0, 4},
> + {124, 0x5d, 0, 8},
> + {126, 0x5d, 0, 10},
> + {128, 0x5e, 0, 0},
> + {132, 0x5e, 0, 4},
> + {134, 0x5e, 0, 6},
> + {136, 0x5e, 0, 8},
> + {140, 0x5f, 0, 0},
> +
> + /* 802.11 UNII */
> + {149, 0x5f, 0, 9},
> + {151, 0x5f, 0, 11},
> + {153, 0x60, 0, 1},
> + {157, 0x60, 0, 5},
> + {159, 0x60, 0, 7},
> + {161, 0x60, 0, 9},
> + {165, 0x61, 0, 1},
> + {167, 0x61, 0, 3},
> + {169, 0x61, 0, 5},
> + {171, 0x61, 0, 7},
> + {173, 0x61, 0, 9},
> };
>
> int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> @@ -2352,11 +2397,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> spec->supported_rates = SUPPORT_RATE_CCK | SUPPORT_RATE_OFDM;
>
> if (rt2x00_rf(rt2x00dev, RF2820) ||
> - rt2x00_rf(rt2x00dev, RF2720) ||
> - rt2x00_rf(rt2x00dev, RF3052)) {
> + rt2x00_rf(rt2x00dev, RF2720)) {
> spec->num_channels = 14;
> spec->channels = rf_vals;
> - } else if (rt2x00_rf(rt2x00dev, RF2850) || rt2x00_rf(rt2x00dev, RF2750)) {
> + } else if (rt2x00_rf(rt2x00dev, RF2850) ||
> + rt2x00_rf(rt2x00dev, RF2750)) {
> spec->supported_bands |= SUPPORT_BAND_5GHZ;
> spec->num_channels = ARRAY_SIZE(rf_vals);
> spec->channels = rf_vals;
> @@ -2364,8 +2409,12 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> rt2x00_rf(rt2x00dev, RF2020) ||
> rt2x00_rf(rt2x00dev, RF3021) ||
> rt2x00_rf(rt2x00dev, RF3022)) {
> - spec->num_channels = ARRAY_SIZE(rf_vals_302x);
> - spec->channels = rf_vals_302x;
> + spec->num_channels = 14;
> + spec->channels = rf_vals_3x;
> + } else if (rt2x00_rf(rt2x00dev, RF3052)) {
> + spec->supported_bands |= SUPPORT_BAND_5GHZ;
> + spec->num_channels = ARRAY_SIZE(rf_vals_3x);
> + spec->channels = rf_vals_3x;
> }
>
> /*
^ permalink raw reply
* Re: kernel BUG in iwl-agn-rs.c:2076, WAS: iwlagn + some accesspoint == hardlock
From: reinette chatre @ 2010-05-06 16:28 UTC (permalink / raw)
To: Christian Borntraeger
Cc: John W. Linville, NilsRadtkelkml@think-future.de,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <201005061114.35480.borntraeger@de.ibm.com>
Hi Christian,
On Thu, 2010-05-06 at 02:14 -0700, Christian Borntraeger wrote:
> Am Montag 03 Mai 2010 21:22:19 schrieb John W. Linville:
> > > /* Sanity-check TPT calculations */
> > > BUG_ON(window->average_tpt != ((window->success_ratio *
> > > tbl->expected_tpt[index] + 64) / 128));
> >
> > Interestingly enough, we have been discussing this line of code today. Could you try the patch here?
> >
> > http://marc.info/?l=linux-wireless&m=127290931304496&w=2
>
> I also see a hard lockup some time after connection to my companies
> wireless network. My private network does not seem to trigger that bug.
> Unfortunately the kernel is not able to switch back graphics, so I
> cannot tell if I see the same BUG - even if the problem description is
> the same.
It will be hard to debug this without some logs. Can you perhaps run
with netconsole for a while? Is it possible to trigger this when not in
X to be able to get some information about where issue is?
> For reference, the patch above does not help on my T61p.
>
> It started soon after 2.6.34-rc4. Before and with rc4 I had to
> apply this http://patchwork.ozlabs.org/patch/49850/mbox/ patch to avoid
> the other crash. With only this patch on top of rc4 everything seemed to
> work fine, so the lockup seems to be triggered by one of the other patches.
> Sometimes it takes some minutes to crash, which makes it hard to bisect
> the problem.
Below seven iwlwifi patches were added after rc4. If you are unable to
bisect ... perhaps you can run a while by reverting more and more from
this list?
f2fa1b015e9c199e45c836c769d94db595150731 iwlwifi: correct 6000 EEPROM regulatory address
88be026490ed89c2ffead81a52531fbac5507e01 iwlwifi: fix scan races
8b9fce77737ae9983f61ec56cd53f52fb738b2c7 iwlwifi: work around bogus active chains detection
ece6444c2fe80dab679beb5f0d58b091f1933b00 iwlwifi: need check for valid qos packet before free
de0f60ea94e132c858caa64a44b2012e1e8580b0 iwlwifi: avoid Tx queue memory allocation in interface down
04f2dec1c3d375c4072613880f28f43b66524876 iwlwifi: use consistent table for tx data collect
dd48744964296b5713032ea1d66eb9e3d990e287 iwlwifi: fix DMA allocation warnings
Reinette
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: reinette chatre @ 2010-05-06 16:11 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
Adel Gadllah
In-Reply-To: <1272909307.7879.5759.camel@rchatre-DESK>
Hi John,
On Mon, 2010-05-03 at 10:55 -0700, reinette chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> We currently have this check as a BUG_ON, which is being hit by people.
> Previously it was an error with a recalculation if not current, return that
> code.
>
> The BUG_ON was introduced by:
> commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
> Author: Guy Cohen <guy.cohen@intel.com>
> Date: Tue Sep 9 10:54:54 2008 +0800
>
> iwlwifi: Added support for 3 antennas
>
> ... the portion adding the BUG_ON is reverted since we are encountering the error
> and BUG_ON was created with assumption that error is not encountered.
>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> ---
I noticed this patch in your wireless-next-2.6 pull request. Since it is
addressing a system hang issue, could it perhaps be included in
wireless-2.6 also? I should have included the bug report reference for
this purpose, sorry ... it is
https://bugzilla.redhat.com/show_bug.cgi?id=588021
Reinette
^ permalink raw reply
* Re: b43: force_pio must be set in your kernel conf
From: Larry Finger @ 2010-05-06 15:36 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-wireless
In-Reply-To: <alpine.LSU.2.01.1005061707140.32387@obet.zrqbmnf.qr>
On 05/06/2010 10:16 AM, Jan Engelhardt wrote:
> Hi,
>
>
> I have here some typical windowscentric Dell laptop with a b43 chipset
> that refuses to work due to something with DMA.
>
> lspci:
> 08:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev
> 01)
> 08:00.0 0280: 14e4:4315 (rev 01)
>
> I installed the firmware using one of opensuse's scripts
> (install_bcm43xx_firmware, though it handles b43 and b43legacy according
> to the script's inner comments), which retrieves
>
> wl_apsta_mimo.o from
> mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
>
> and runs fwcutter on it. In dmesg, I then find on modprobe b43
> verbose=3:
>
> b43 ssb0:0: firmware: requesting b43/ucode15.fw
> b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
> b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
> b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
> b43-phy0 debug: Chip initialized
> b43-phy0 debug: 64-bit DMA initialized
> b43-phy0 debug: QoS enabled
> b43-phy0 debug: Wireless interface started
> b43-phy0 debug: Adding Interface type 2
> b43-phy0 ERROR: Fatal DMA error: 0x400, 0x0, 0x0, 0x0, 0x0, 0x0
> b43-phy0 ERROR: This device does not support DMA on your system. Please
> use PIO instead.
> b43-phy0 ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel
> configuration.
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
>
> So, can I get PIO mode for free without recompiling? (Since
> CONFIG_B43_PIO=y already.) What other info needs to be provided to help
> resolve this?
>
> System is a 2.6.33.2-x86_64.
In the latest mainline kernel (2.6.34-rc6), the fallback to PIO is
automatic. For a 2.6.33 kernel, you will need to rebuild the kernel or
install the latest compat-wireless package. Your distro may already
provide it.
We are working on this problem. Keep watching this list for trial
patches. Unfortunately, none of the developers have a machine that
suffers from this problem. It seems to be associated with Intel
processors (mostly netbooks with Atom chips) and the Phoenix BIOS.
Larry
^ permalink raw reply
* b43: force_pio must be set in your kernel conf
From: Jan Engelhardt @ 2010-05-06 15:16 UTC (permalink / raw)
To: linux-wireless
Hi,
I have here some typical windowscentric Dell laptop with a b43 chipset
that refuses to work due to something with DMA.
lspci:
08:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev
01)
08:00.0 0280: 14e4:4315 (rev 01)
I installed the firmware using one of opensuse's scripts
(install_bcm43xx_firmware, though it handles b43 and b43legacy according
to the script's inner comments), which retrieves
wl_apsta_mimo.o from
mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
and runs fwcutter on it. In dmesg, I then find on modprobe b43
verbose=3:
b43 ssb0:0: firmware: requesting b43/ucode15.fw
b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
b43-phy0 debug: Chip initialized
b43-phy0 debug: 64-bit DMA initialized
b43-phy0 debug: QoS enabled
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0 ERROR: Fatal DMA error: 0x400, 0x0, 0x0, 0x0, 0x0, 0x0
b43-phy0 ERROR: This device does not support DMA on your system. Please
use PIO instead.
b43-phy0 ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel
configuration.
ADDRCONF(NETDEV_UP): wlan0: link is not ready
So, can I get PIO mode for free without recompiling? (Since
CONFIG_B43_PIO=y already.) What other info needs to be provided to help
resolve this?
System is a 2.6.33.2-x86_64.
thanks,
Jan
^ permalink raw reply
* Re: 2.6.34-rc6 pci bridge problems
From: Bjorn Helgaas @ 2010-05-06 15:09 UTC (permalink / raw)
To: Christian Lamparter; +Cc: dhlii, linux-wireless, linux-kernel, linux-pci
In-Reply-To: <201005052159.55871.chunkeey@googlemail.com>
On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > When I build out of the wireless-testing git tree (puled today)
> > 2.6.34-rc6 using my current systems .config I get a very quick error
> > on boot about PCI bridge windows.
> > googling the error indicates this is a know 2.6.34 problem and that
> > there are fixes in other 2.6.34 trees.
> > I have been unable to find the actual patches or I would just apply
> > them to wireless-testing.
I made significant changes in the way we handle PCI bridge windows,
and I'm eager to fix any issues in that area. But "very quick error
on boot" doesn't give me any information to work with.
Please attach your complete dmesg output, serial console log (with
"ignore_loglevel"), digital photo of the error, or other specific
details.
Bjorn
^ permalink raw reply
* Re: 2.6.33.2: Turn tx power off/on for Atheros card
From: Yegor Yefremov @ 2010-05-06 14:52 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev
In-Reply-To: <r2xf69abfc31005050326oe123cb60s131ab4969341ef57@mail.gmail.com>
On Wed, May 5, 2010 at 12:26 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> I'm using kernel 2.6.33.2 with AR2413 WLAN card. Issuing
>
> iwconfig wlan0 txpower off
>
> turns txpower off. I can see this status by iwconfig wlan0 and the
> communication with AP terminates. But when I turn the txpower on
>
> iwconfig wlan0 txpower on
>
> nothing happens. Though iwconfig shows the previous tx power value.
> Only ifconfig wlan0 down and then up recovers the transmission.
>
> Is it a known bug or I'm doing something wrong?
I made some debugging and found out that after iwconfig wlan0 txpower
off dev_close() will be invoked, so that local->open_count will be 0.
The next time txpower on will be called, it will be checked if
local->open_count > 0 and this conditions fails, so no hardware
configuration will be made.
I've made a quick and dirty hack, that opens the wireless device by
enabling the txpower, if it was closed before. Is there any proper
solution? Is it really necessary to close device to tunr txpower off?
Best regards,
Yegor
Index: b/net/wireless/wext-compat.c
===================================================================
--- a/net/wireless/wext-compat.c 2010-04-30 05:02:05.000000000 +0200
+++ b/net/wireless/wext-compat.c 2010-05-06 16:31:20.000000000 +0200
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <net/iw_handler.h>
#include <net/cfg80211.h>
+#include "../mac80211/ieee80211_i.h"
#include "wext-compat.h"
#include "core.h"
@@ -824,6 +825,7 @@
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ struct ieee80211_local *local = wiphy_priv(wdev->wiphy);
enum tx_power_setting type;
int dbm = 0;
@@ -861,6 +863,8 @@
type = TX_POWER_LIMITED;
}
}
+ if(!local->open_count)
+ dev_open(wdev->netdev);
} else {
rfkill_set_sw_state(rdev->rfkill, true);
schedule_work(&rdev->rfkill_sync);
^ permalink raw reply
* [PATCH v2 1/2] mac80211: add offload channel switch support
From: wey-yi.w.guy @ 2010-05-06 15:25 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Wey-Yi Guy
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Adding support to offload the channel switch operation to driver if
driver can support the function.
The original approach, mac80211 utilize the mac_config callback function
and set the CHANNEL_CHANGE flag which is difficult to separate the true
channel switch request from all the other channel changes condition;
with this offload approach, driver has more control on how to handle the
channel switch request from AP, also can provide more accurate timing
calculation
The drivers like to support the channel switch offloading function will have
to provide the mactime information (at least for mgmt and action frames)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
v2: use "mactime" instead of timestamp in the frame body, the driver has to provide the mactime if need to support the channel switch function
---
include/net/mac80211.h | 32 ++++++++++++++++++++++++++++
net/mac80211/driver-ops.h | 11 +++++++++
net/mac80211/driver-trace.h | 49 +++++++++++++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/mlme.c | 48 ++++++++++++++++++++++++++++++++++++++---
5 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2879c8e..dc5ae23 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -708,6 +708,26 @@ struct ieee80211_conf {
};
/**
+ * struct ieee80211_channel_switch - holds the channel switch data
+ *
+ * The information provided in this structure is required for channel switch
+ * operation.
+ *
+ * @timestamp: value in microseconds of the 64-bit Time Synchronization
+ * Function (TSF) timer when the channel switch ie received.
+ * @block_tx: set to true if no more future frames transmission within the BSS
+ * until the scheduled channel switch
+ * @channel: pointer to ieee80211_channel contain then new channel information
+ * @count: specified the number of TBTT's until the channel switch event.
+ */
+struct ieee80211_channel_switch {
+ u64 timestamp;
+ bool block_tx;
+ struct ieee80211_channel *channel;
+ u8 count;
+};
+
+/**
* struct ieee80211_vif - per-interface data
*
* Data in this structure is continually present for driver
@@ -1694,6 +1714,8 @@ struct ieee80211_ops {
int (*testmode_cmd)(struct ieee80211_hw *hw, void *data, int len);
#endif
void (*flush)(struct ieee80211_hw *hw, bool drop);
+ void (*channel_switch)(struct ieee80211_hw *hw,
+ struct ieee80211_channel_switch *ch_switch);
};
/**
@@ -2444,6 +2466,16 @@ void ieee80211_cqm_rssi_notify(struct ieee80211_vif *vif,
enum nl80211_cqm_rssi_threshold_event rssi_event,
gfp_t gfp);
+/**
+ * ieee80211_chswitch_done - Complete channel switch process
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ * @is_seccess: make the channel switch successful or not
+ *
+ * Complete the channel switch post-process: set the new operational channel
+ * and wake up the suspended queues.
+ */
+void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success);
+
/* Rate control API */
/**
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 997008e..5662bb5 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -373,4 +373,15 @@ static inline void drv_flush(struct ieee80211_local *local, bool drop)
if (local->ops->flush)
local->ops->flush(&local->hw, drop);
}
+
+static inline void drv_channel_switch(struct ieee80211_local *local,
+ struct ieee80211_channel_switch *ch_switch)
+{
+ might_sleep();
+
+ local->ops->channel_switch(&local->hw, ch_switch);
+
+ trace_drv_channel_switch(local, ch_switch);
+}
+
#endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index ce734b5..cd1ae9f 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -774,6 +774,34 @@ TRACE_EVENT(drv_flush,
)
);
+TRACE_EVENT(drv_channel_switch,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_channel_switch *ch_switch),
+
+ TP_ARGS(local, ch_switch),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ __field(u64, timestamp)
+ __field(bool, block_tx)
+ __field(u16, freq)
+ __field(u8, count)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ __entry->timestamp = ch_switch->timestamp;
+ __entry->block_tx = ch_switch->block_tx;
+ __entry->freq = ch_switch->channel->center_freq;
+ __entry->count = ch_switch->count;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " new freq:%u count:%d",
+ LOCAL_PR_ARG, __entry->freq, __entry->count
+ )
+);
+
/*
* Tracing for API calls that drivers call.
*/
@@ -992,6 +1020,27 @@ TRACE_EVENT(api_sta_block_awake,
)
);
+TRACE_EVENT(api_chswitch_done,
+ TP_PROTO(struct ieee80211_sub_if_data *sdata, bool is_success),
+
+ TP_ARGS(sdata, is_success),
+
+ TP_STRUCT__entry(
+ VIF_ENTRY
+ __field(bool, is_success)
+ ),
+
+ TP_fast_assign(
+ VIF_ASSIGN;
+ __entry->is_success = is_success;
+ ),
+
+ TP_printk(
+ VIF_PR_FMT " chswitch:%d",
+ VIF_PR_ARG, __entry->is_success
+ )
+);
+
/*
* Tracing for internal functions
* (which may also be called in response to driver calls)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4e73660..be9dda9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -999,7 +999,8 @@ int ieee80211_max_network_latency(struct notifier_block *nb,
unsigned long data, void *dummy);
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
- struct ieee80211_bss *bss);
+ struct ieee80211_bss *bss,
+ u64 timestamp);
void ieee80211_sta_quiesce(struct ieee80211_sub_if_data *sdata);
void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 358226f..19b53a8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -340,7 +340,11 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
sdata->local->oper_channel = sdata->local->csa_channel;
- ieee80211_hw_config(sdata->local, IEEE80211_CONF_CHANGE_CHANNEL);
+ if (!sdata->local->ops->channel_switch) {
+ /* call "hw_config" only if doing sw channel switch */
+ ieee80211_hw_config(sdata->local,
+ IEEE80211_CONF_CHANGE_CHANNEL);
+ }
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->local->oper_channel;
@@ -352,6 +356,22 @@ static void ieee80211_chswitch_work(struct work_struct *work)
mutex_unlock(&ifmgd->mtx);
}
+void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool is_success)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_managed *ifmgd;
+
+ sdata = vif_to_sdata(vif);
+ ifmgd = &sdata->u.mgd;
+
+ trace_api_chswitch_done(sdata, is_success);
+ if (!is_success)
+ sdata->local->csa_channel = sdata->local->oper_channel;
+
+ ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
+}
+EXPORT_SYMBOL(ieee80211_chswitch_done);
+
static void ieee80211_chswitch_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
@@ -368,7 +388,8 @@ static void ieee80211_chswitch_timer(unsigned long data)
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
struct ieee80211_channel_sw_ie *sw_elem,
- struct ieee80211_bss *bss)
+ struct ieee80211_bss *bss,
+ u64 timestamp)
{
struct cfg80211_bss *cbss =
container_of((void *)bss, struct cfg80211_bss, priv);
@@ -396,6 +417,23 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
sdata->local->csa_channel = new_ch;
+ if (sdata->local->ops->channel_switch) {
+ /* use driver's channel switch callback */
+ struct ieee80211_channel_switch ch_switch;
+ memset(&ch_switch, 0, sizeof(ch_switch));
+ ch_switch.timestamp = timestamp;
+ if (sw_elem->mode) {
+ ch_switch.block_tx = true;
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+ }
+ ch_switch.channel = new_ch;
+ ch_switch.count = sw_elem->count;
+ ifmgd->flags |= IEEE80211_STA_CSA_RECEIVED;
+ drv_channel_switch(sdata->local, &ch_switch);
+ return;
+ }
+ /* mac80211 handle channel switch */
if (sw_elem->count <= 1) {
ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
} else {
@@ -1315,7 +1353,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
ETH_ALEN) == 0)) {
struct ieee80211_channel_sw_ie *sw_elem =
(struct ieee80211_channel_sw_ie *)elems->ch_switch_elem;
- ieee80211_sta_process_chanswitch(sdata, sw_elem, bss);
+ ieee80211_sta_process_chanswitch(sdata, sw_elem,
+ bss, rx_status->mactime);
}
}
@@ -1647,7 +1686,8 @@ static void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
ieee80211_sta_process_chanswitch(sdata,
&mgmt->u.action.u.chan_switch.sw_elem,
- (void *)ifmgd->associated->priv);
+ (void *)ifmgd->associated->priv,
+ rx_status->mactime);
break;
}
mutex_unlock(&ifmgd->mtx);
--
1.5.6.3
^ permalink raw reply related
* RE: [PATCH 1/2] mac80211: add offload channel switch support
From: Guy, Wey-Yi W @ 2010-05-06 14:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1273131876.3573.28.camel@jlt3.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5l
cyBCZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBUaHVyc2Rh
eSwgTWF5IDA2LCAyMDEwIDEyOjQ1IEFNDQpUbzogR3V5LCBXZXktWWkgVw0KQ2M6IGxpbnV4LXdp
cmVsZXNzQHZnZXIua2VybmVsLm9yZw0KU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIG1hYzgwMjEx
OiBhZGQgb2ZmbG9hZCBjaGFubmVsIHN3aXRjaCBzdXBwb3J0DQoNClNvcnJ5LCBqdXN0IHRob3Vn
aHQgb2Ygc29tZXRoaW5nLg0KDQpPbiBXZWQsIDIwMTAtMDUtMDUgYXQgMjA6MzQgLTA3MDAsIHdl
eS15aS53Lmd1eUBpbnRlbC5jb20gd3JvdGU6DQoNCj4gKyAqIEB0aW1lc3RhbXA6IHZhbHVlIGlu
IG1pY3Jvc2Vjb25kcyBvZiB0aGUgNjQtYml0IFRpbWUgU3luY2hyb25pemF0aW9uDQo+ICsgKglG
dW5jdGlvbiAoVFNGKSB0aW1lciB3aGVuIHRoZSBjaGFubmVsIHN3aXRjaCBpZSByZWNlaXZlZC4N
Cg0KVGhpcyBpcyBub3QgYWNjdXJhdGUgbm93IGJ1dCBzZWUgYmVsb3cuDQoNCj4gKwkJaWYgKGJl
YWNvbikNCj4gKwkJCXRpbWVzdGFtcCA9IGxlNjRfdG9fY3B1KG1nbXQtPnUuYmVhY29uLnRpbWVz
dGFtcCk7DQo+ICsJCWVsc2UNCj4gKwkJCXRpbWVzdGFtcCA9IGxlNjRfdG9fY3B1KG1nbXQtPnUu
cHJvYmVfcmVzcC50aW1lc3RhbXApOw0KPiArCQlpZWVlODAyMTFfc3RhX3Byb2Nlc3NfY2hhbnN3
aXRjaChzZGF0YSwgc3dfZWxlbSwNCj4gKwkJCQkJCSBic3MsIHRpbWVzdGFtcCk7DQo+ICAJfQ0K
PiAgfQ0KPiAgDQo+IEBAIC0xNjQ3LDcgKzE2OTEsOCBAQCBzdGF0aWMgdm9pZCBpZWVlODAyMTFf
c3RhX3J4X3F1ZXVlZF9tZ210KHN0cnVjdCBpZWVlODAyMTFfc3ViX2lmX2RhdGEgKnNkYXRhLA0K
PiAgDQo+ICAJCQlpZWVlODAyMTFfc3RhX3Byb2Nlc3NfY2hhbnN3aXRjaChzZGF0YSwNCj4gIAkJ
CQkJJm1nbXQtPnUuYWN0aW9uLnUuY2hhbl9zd2l0Y2guc3dfZWxlbSwNCj4gLQkJCQkJKHZvaWQg
KilpZm1nZC0+YXNzb2NpYXRlZC0+cHJpdik7DQo+ICsJCQkJCSh2b2lkICopaWZtZ2QtPmFzc29j
aWF0ZWQtPnByaXYsDQo+ICsJCQkJCXJ4X3N0YXR1cy0+bWFjdGltZSk7DQoNCkZvciBzb21lIHJl
YXNvbiBJIGRpZG4ndCBub3RpY2UgdGhlIGFjdGlvbiBmcmFtZSBoYW5kbGluZyBiZWZvcmUuIE1h
eWJlDQppdCB3b3VsZCBiZSBtb3JlIGNvbnNpc3RlbnQgdG8ga2VlcCB1c2luZyByeF9zdGF0dXMt
Pm1hY3RpbWUgZXZlbiBmb3INCmJlYWNvbnM/IEkgYXBvbG9naXNlLCB0aGlzIGlzIHRvdGFsbHkg
bXkgZmF1bHQgc2luY2UgSSBzdWdnZXN0ZWQgdXNpbmcNCnRoZSBiZWFjb24gdGltZSBiZWZvcmUs
IGJ1dCB0aGF0IGhhcyBhIHNsaWdodGx5IGRpZmZlcmVudCB2YWx1ZSByZWxhdGl2ZQ0KdG8gdGhl
IGZyYW1lLi4uIEhtbS4gTWF5YmUgaXQgd291bGQgYmUgYmV0dGVyIGFmdGVyIGFsbCB0byByZXF1
aXJlDQpkcml2ZXJzIHRvIHByb3ZpZGUgbWFjdGltZSBhdCBsZWFzdCBmb3IgbWdtdCBmcmFtZXMg
KGJlYWNvbnMgKyBhY3Rpb25zKQ0Kd2hlbiB0aGV5IHdhbnQgdG8gaW1wbGVtZW50IHRoaXMgY2Fs
bGJhY2suDQoNCkFueW9uZSBlbHNlIGhhdmUgaWRlYXM/DQoNCkl0IG1ha2VzIG1vcmUgc2Vuc2Ug
dG8gdXNlIG1hY3RpbWUsIHNvIGRyaXZlciBkbyBub3QgaGF2ZSB0byBwZWVrIGludG8gdGhlIGZy
YW1lIGJvZHkuIE5vdCBhIHByb2JsZW0sIEkgY2FuIG1ha2UgdGhlIGNoYW5nZXMgYW5kIHJlLXN1
Ym1pdC4NCg0KVGhhbmtzDQpXZXkNCg0K
^ permalink raw reply
* Re: rt61pci: WEP broken in current wireless-testing
From: John W. Linville @ 2010-05-06 13:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <20100506075157.whuptq9jgzkww4gs-cebfxv@webmail.spamcop.net>
On Thu, May 06, 2010 at 07:51:57AM -0400, Pavel Roskin wrote:
> Recent changes in wireless-testing have broken WEP support in rt61pci.
> An older kernel from wireless-testing identified as 2.6.34-rc5-wl is
> working fine.
> It's should be rather straightforward to bisect, but I'll be away from
> that system until next Monday.
When you get to this, you probably should use wireless-next-2.6
(or wireless-2.6) for the bisection. The pulls from linux-2.6 in
wireless-testing make bisection much more painful than necessary
(as long as the problem is actually evident in the other kernels).
You can use the 'master-<date>' tags as guidelines for matching
wireless-testing versions to representative wireless-next-2.6 (or
wireless-2.6) tree versions.
Hth!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC/RFT] ssb: resolve alternate SPROM offset for 14e4:4315
From: Larry Finger @ 2010-05-06 13:11 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, linux-wireless
In-Reply-To: <201005061201.18469.mb@bu3sch.de>
On 05/06/2010 05:01 AM, Michael Buesch wrote:
> On Thursday 06 May 2010 11:53:01 Michael Buesch wrote:
>> On Thursday 06 May 2010 07:00:13 Larry Finger wrote:
>>> This patch and the patch by Gabor entitled "[PATCH] ssb: Implement
>>> fast powerup delay calculation" are enough to allow the netbook from
>>> John to work with ssb/b43. As this patch tampers with the SPROM offset for
>>> 14e4:4315 devices, it should be tested by anyone with an LP PHY that works
>>> to ensure that it is not killed.
>>>
>>> The essential elements of this patch will also be tested as part of kernel Bug
>>> #15825.
>>>
>>> Larry
>>>
>>> Index: wireless-testing/drivers/ssb/pci.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/pci.c
>>> +++ wireless-testing/drivers/ssb/pci.c
>>> @@ -631,8 +631,17 @@ static int ssb_pci_sprom_get(struct ssb_
>>> return -ENODEV;
>>> }
>>>
>>> - bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
>>> - SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
>>> + /* get SPROM offset: SSB_SPROM_BASE1 except for chipcommon rev >= 31
>>> + * or chip ID is 0x4312 and bit 0x2 is set in chipcommon status
>>> + */
>>> + if (bus->chipco.dev->id.revision >= 31)
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else if (bus->chip_id == 0x4312 && (bus->chipco.status & 0x02))
>>> + bus->sprom_offset = SSB_SPROM_BASE31;
>>> + else
>>> + bus->sprom_offset = SSB_SPROM_BASE1;
>>> +
>>> + ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);
>>>
>>> buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
>>> if (!buf)
>>> Index: wireless-testing/drivers/ssb/scan.c
>>> ===================================================================
>>> --- wireless-testing.orig/drivers/ssb/scan.c
>>> +++ wireless-testing/drivers/ssb/scan.c
>>> @@ -306,6 +306,11 @@ int ssb_bus_scan(struct ssb_bus *bus,
>>> }
>>> tmp = scan_read32(bus, 0, SSB_CHIPCO_CAP);
>>> bus->chipco.capabilities = tmp;
>>> + if (bus->chip_rev >= 11)
>>
>> This still is wrong. the chip_rev is not the chipcommon core revision.
>
> Although technically in most (all?) cases it might be the same number.
> I'm not sure on that one.
> But it is read from an entirely different register and I think it's plain
> wrong to assume that chip_rev equals the chipcommon core rev.
Is it OK to read the chipcommon capabilities here?
>> We already went through this and we decided to read the chipstat later.
>> Read it in chipcommon init. The bus scan is _way_ too early to read this.
I missed that, but found it now.
Larry
^ permalink raw reply
* [PATCH] rt2x00: Fix RF3052 channel initialization
From: Ivo van Doorn @ 2010-05-06 12:45 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
Update channel initialization for the RF3052 chipset.
According to the Ralink drivers, the rt3x array must be
used for this chipset, rather then the rt2x array.
Furthermore RF3052 supports the 5GHz band, extend
the rt3x array with the 5GHz channels, and use them
for the RF3052 chip.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 67 ++++++++++++++++++++++++++----
1 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index e37bbea..6c0abc3 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2219,7 +2219,7 @@ int rt2800_init_eeprom(struct rt2x00_dev *rt2x00dev)
EXPORT_SYMBOL_GPL(rt2800_init_eeprom);
/*
- * RF value list for rt28x0
+ * RF value list for rt28xx
* Supports: 2.4 GHz (all) & 5.2 GHz (RF2850 & RF2750)
*/
static const struct rf_channel rf_vals[] = {
@@ -2294,10 +2294,10 @@ static const struct rf_channel rf_vals[] = {
};
/*
- * RF value list for rt3070
- * Supports: 2.4 GHz
+ * RF value list for rt3xxx
+ * Supports: 2.4 GHz (all) & 5.2 GHz (RF3052)
*/
-static const struct rf_channel rf_vals_302x[] = {
+static const struct rf_channel rf_vals_3x[] = {
{1, 241, 2, 2 },
{2, 241, 2, 7 },
{3, 242, 2, 2 },
@@ -2312,6 +2312,51 @@ static const struct rf_channel rf_vals_302x[] = {
{12, 246, 2, 7 },
{13, 247, 2, 2 },
{14, 248, 2, 4 },
+
+ /* 802.11 UNI / HyperLan 2 */
+ {36, 0x56, 0, 4},
+ {38, 0x56, 0, 6},
+ {40, 0x56, 0, 8},
+ {44, 0x57, 0, 0},
+ {46, 0x57, 0, 2},
+ {48, 0x57, 0, 4},
+ {52, 0x57, 0, 8},
+ {54, 0x57, 0, 10},
+ {56, 0x58, 0, 0},
+ {60, 0x58, 0, 4},
+ {62, 0x58, 0, 6},
+ {64, 0x58, 0, 8},
+
+ /* 802.11 HyperLan 2 */
+ {100, 0x5b, 0, 8},
+ {102, 0x5b, 0, 10},
+ {104, 0x5c, 0, 0},
+ {108, 0x5c, 0, 4},
+ {110, 0x5c, 0, 6},
+ {112, 0x5c, 0, 8},
+ {116, 0x5d, 0, 0},
+ {118, 0x5d, 0, 2},
+ {120, 0x5d, 0, 4},
+ {124, 0x5d, 0, 8},
+ {126, 0x5d, 0, 10},
+ {128, 0x5e, 0, 0},
+ {132, 0x5e, 0, 4},
+ {134, 0x5e, 0, 6},
+ {136, 0x5e, 0, 8},
+ {140, 0x5f, 0, 0},
+
+ /* 802.11 UNII */
+ {149, 0x5f, 0, 9},
+ {151, 0x5f, 0, 11},
+ {153, 0x60, 0, 1},
+ {157, 0x60, 0, 5},
+ {159, 0x60, 0, 7},
+ {161, 0x60, 0, 9},
+ {165, 0x61, 0, 1},
+ {167, 0x61, 0, 3},
+ {169, 0x61, 0, 5},
+ {171, 0x61, 0, 7},
+ {173, 0x61, 0, 9},
};
int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
@@ -2352,11 +2397,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
spec->supported_rates = SUPPORT_RATE_CCK | SUPPORT_RATE_OFDM;
if (rt2x00_rf(rt2x00dev, RF2820) ||
- rt2x00_rf(rt2x00dev, RF2720) ||
- rt2x00_rf(rt2x00dev, RF3052)) {
+ rt2x00_rf(rt2x00dev, RF2720)) {
spec->num_channels = 14;
spec->channels = rf_vals;
- } else if (rt2x00_rf(rt2x00dev, RF2850) || rt2x00_rf(rt2x00dev, RF2750)) {
+ } else if (rt2x00_rf(rt2x00dev, RF2850) ||
+ rt2x00_rf(rt2x00dev, RF2750)) {
spec->supported_bands |= SUPPORT_BAND_5GHZ;
spec->num_channels = ARRAY_SIZE(rf_vals);
spec->channels = rf_vals;
@@ -2364,8 +2409,12 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
rt2x00_rf(rt2x00dev, RF2020) ||
rt2x00_rf(rt2x00dev, RF3021) ||
rt2x00_rf(rt2x00dev, RF3022)) {
- spec->num_channels = ARRAY_SIZE(rf_vals_302x);
- spec->channels = rf_vals_302x;
+ spec->num_channels = 14;
+ spec->channels = rf_vals_3x;
+ } else if (rt2x00_rf(rt2x00dev, RF3052)) {
+ spec->supported_bands |= SUPPORT_BAND_5GHZ;
+ spec->num_channels = ARRAY_SIZE(rf_vals_3x);
+ spec->channels = rf_vals_3x;
}
/*
--
1.6.6.1
^ permalink raw reply related
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