* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Luis Correia @ 2009-07-28 13:38 UTC (permalink / raw)
To: Chris Clayton; +Cc: Johannes Berg, Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <c6b1100b0907280634j4610d077rb30f1f571aac7f36@mail.gmail.com>
Chris
On Tue, Jul 28, 2009 at 14:34, Chris Clayton<chris2553@googlemail.com> wrote:
> 2009/7/28 Luis Correia <luis.f.correia@gmail.com>:
>> Hi Chris
>
>> Can you do a very dumb test for me?
>>
>> Boot your laptop by adding 'irqpoll' to the kernel command line
>> options and see if the problem still occours.
>>
>
> Not so dumb a request, actually. Running -rc4 with the irqpoll
> command line option, the laptop has just survived 30 minutes without a
> freeze. It can't survive more than 5 minutes without that option.
>
> Chris
Well, if the laptop hangs on working without any problems, this may
proove to be some strange kind of hardware incompatibility.
The irqpoll option solves some of the interrupt related problems, by
polling them instead of 'grabbing' them (at least that is what I think
it is happening, correct me if I'm wrong:))
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Chris Clayton @ 2009-07-28 13:34 UTC (permalink / raw)
To: Luis Correia; +Cc: Johannes Berg, Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <efe7343f0907280411y61e8a68dj500c2a74ad1af28a@mail.gmail.com>
2009/7/28 Luis Correia <luis.f.correia@gmail.com>:
> Hi Chris
> Can you do a very dumb test for me?
>
> Boot your laptop by adding 'irqpoll' to the kernel command line
> options and see if the problem still occours.
>
Not so dumb a request, actually. Running -rc4 with the irqpoll
command line option, the laptop has just survived 30 minutes without a
freeze. It can't survive more than 5 minutes without that option.
Chris
> Luis Correia
> rt2x00 project admin
>
--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson
^ permalink raw reply
* Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode
From: Johannes Berg @ 2009-07-28 13:19 UTC (permalink / raw)
To: Igor Perminov; +Cc: linux-wireless
In-Reply-To: <1248784603.29068.44.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Tue, 2009-07-28 at 16:36 +0400, Igor Perminov wrote:
> And here is my question: what would be the correct behaviour?
> A) The mac80211 stack should pass the FIF_CONTROL flag to the driver
> when the device is configured in the AP mode.
> B) The driver should configure the hardware to receive PS Poll frames by
> itself when the device is configured in the AP mode, even if the
> FIF_CONTROL flag isn't passed by the mac80211 stack.
Hmm. Passing up *all* control frames wouldn't really be good -- think of
all the ACK frames. Do you have filters per frame type?
Maybe we should introduce a FIF_PSPOLL flag?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode
From: Igor Perminov @ 2009-07-28 12:36 UTC (permalink / raw)
To: linux-wireless
Dear colleagues,
I've discovered that a rt73 usb wi-fi stick in the AP mode doesn't
receive PS Poll frames from a station. The station sends a PS Poll
frame, but the mac80211 stack doesn't see it.
More details can be found here:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10,
issue #1.
I've found that the FIF_CONTROL flag isn't passed to the rt2x00's
configure_filter function (namely rt2x00mac_configure_filter) by the
mac80211 stack even if the device is configured as an access point.
So, the hardware is configured by the driver to filter out control
frames according to the flags given.
And here is my question: what would be the correct behaviour?
A) The mac80211 stack should pass the FIF_CONTROL flag to the driver
when the device is configured in the AP mode.
B) The driver should configure the hardware to receive PS Poll frames by
itself when the device is configured in the AP mode, even if the
FIF_CONTROL flag isn't passed by the mac80211 stack.
Best regards,
Igor Perminov
^ permalink raw reply
* iwlagn - compat-wireless (5GHz) and fglrx modules
From: Greg Oliver @ 2009-07-28 12:31 UTC (permalink / raw)
To: linux-wireless
Hello,
I am experiencing a very odd issue between the ilagn and fglrx modules.
I am writing here since the ubuntu devs are not supporting running
either modules (fglrx since I am not using their packages, or iwlagn
since I am using the compat-wireless frmo linux-wireless.org).
The results are very reproducible - here is what is happening:
I can successfully use any version of compat-wireless with the OSS ATI
video modules. I can successfully run the closed source fglrx ATI
module with the Ubuntu provided (albeit ancient) iwlagn and related
modules. Once I try to run the closed fglrx module alongside the
compat-wireless packages from linux-wireless, ONLY the 5GHz channels
(both wide and narrow) fail. Association works, but debug outputs over
and over:
[ 470.128306] iwlagn 0000:04:00.0: ERROR: No TX rate available.
over and over.... Switching to a 2.4 channel works like a champ, but
the laptop in general is unstable and sometimes becomes unusable, and
others kard kernel locks (blinking caps lock)..
I have tried All Ubuntu kernel PPA kernels as well as latest git and
released compat-wireless relases with same effect, as well as all ATI
catalyst drivers from 9.4 - 9.7.
Hardware invloved:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
HD 3670
Subsystem: Dell Device 0272
Flags: bus master, fast devsel, latency 0, IRQ 2296
Memory at d0000000 (32-bit, prefetchable) [size=256M]
I/O ports at 2000 [size=256]
Memory at cfef0000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at cfe00000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: fglrx_pci
Kernel modules: fglrx
04:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN
[Shiloh] Network Connection
Subsystem: Intel Corporation Device 1101
Flags: bus master, fast devsel, latency 0, IRQ 2297
Memory at f8000000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: iwlagn
Kernel modules: iwlagn
BAD Module combo:
filename: /lib/modules/2.6.28-13-generic/updates/dkms/fglrx.ko
license: Proprietary. (C) 2002 - ATI Technologies, Starnberg,
GERMANY
description: ATI Fire GL
author: Fire GL - ATI Research GmbH, Germany
srcversion: 2C2CE01E2172B42D35D1980
alias: pci:v00001002d000095CFsv*sd*bc*sc*i*
alias: pci:v00001002d000095CEsv*sd*bc*sc*i*
alias: pci:v00001002d000095CDsv*sd*bc*sc*i*
alias: pci:v00001002d00009446sv*sd*bc*sc*i*
alias: pci:v00001002d00009456sv*sd*bc*sc*i*
alias: pci:v00001002d00009444sv*sd*bc*sc*i*
alias: pci:v00001002d0000949Csv*sd*bc*sc*i*
alias: pci:v00001002d0000949Esv*sd*bc*sc*i*
alias: pci:v00001002d0000949Fsv*sd*bc*sc*i*
alias: pci:v00001002d00009511sv*sd*bc*sc*i*
alias: pci:v00001002d0000958Dsv*sd*bc*sc*i*
alias: pci:v00001002d0000958Csv*sd*bc*sc*i*
alias: pci:v00001002d000095CCsv*sd*bc*sc*i*
alias: pci:v00001002d00009447sv*sd*bc*sc*i*
alias: pci:v00001002d0000944Fsv*sd*bc*sc*i*
alias: pci:v00001002d0000940Asv*sd*bc*sc*i*
alias: pci:v00001002d0000940Bsv*sd*bc*sc*i*
alias: pci:v00001002d0000940Fsv*sd*bc*sc*i*
alias: pci:v00001002d0000946Bsv*sd*bc*sc*i*
alias: pci:v00001002d0000946Asv*sd*bc*sc*i*
alias: pci:v00001002d0000947Bsv*sd*bc*sc*i*
alias: pci:v00001002d0000947Asv*sd*bc*sc*i*
alias: pci:v00001002d000094A3sv*sd*bc*sc*i*
alias: pci:v00001002d00009489sv*sd*bc*sc*i*
alias: pci:v00001002d0000959Bsv*sd*bc*sc*i*
alias: pci:v00001002d00009595sv*sd*bc*sc*i*
alias: pci:v00001002d0000958Fsv*sd*bc*sc*i*
alias: pci:v00001002d0000945Bsv*sd*bc*sc*i*
alias: pci:v00001002d0000945Asv*sd*bc*sc*i*
alias: pci:v00001002d0000944Bsv*sd*bc*sc*i*
alias: pci:v00001002d0000944Asv*sd*bc*sc*i*
alias: pci:v00001002d000094A1sv*sd*bc*sc*i*
alias: pci:v00001002d000094A0sv*sd*bc*sc*i*
alias: pci:v00001002d00009488sv*sd*bc*sc*i*
alias: pci:v00001002d00009480sv*sd*bc*sc*i*
alias: pci:v00001002d00009491sv*sd*bc*sc*i*
alias: pci:v00001002d00009555sv*sd*bc*sc*i*
alias: pci:v00001002d00009552sv*sd*bc*sc*i*
alias: pci:v00001002d00009553sv*sd*bc*sc*i*
alias: pci:v00001002d00009509sv*sd*bc*sc*i*
alias: pci:v00001002d00009508sv*sd*bc*sc*i*
alias: pci:v00001002d00009506sv*sd*bc*sc*i*
alias: pci:v00001002d00009504sv*sd*bc*sc*i*
alias: pci:v00001002d00009593sv*sd*bc*sc*i*
alias: pci:v00001002d00009591sv*sd*bc*sc*i*
alias: pci:v00001002d000095C2sv*sd*bc*sc*i*
alias: pci:v00001002d000095C4sv*sd*bc*sc*i*
alias: pci:v00001002d0000958Bsv*sd*bc*sc*i*
alias: pci:v00001002d00009583sv*sd*bc*sc*i*
alias: pci:v00001002d00009581sv*sd*bc*sc*i*
alias: pci:v00001002d000094C8sv*sd*bc*sc*i*
alias: pci:v00001002d000094CBsv*sd*bc*sc*i*
alias: pci:v00001002d000094C9sv*sd*bc*sc*i*
alias: pci:v00001002d00009462sv*sd*bc*sc*i*
alias: pci:v00001002d00009460sv*sd*bc*sc*i*
alias: pci:v00001002d00009440sv*sd*bc*sc*i*
alias: pci:v00001002d0000944Esv*sd*bc*sc*i*
alias: pci:v00001002d00009442sv*sd*bc*sc*i*
alias: pci:v00001002d00009452sv*sd*bc*sc*i*
alias: pci:v00001002d0000944Csv*sd*bc*sc*i*
alias: pci:v00001002d00009450sv*sd*bc*sc*i*
alias: pci:v00001002d000094B1sv*sd*bc*sc*i*
alias: pci:v00001002d000094B3sv*sd*bc*sc*i*
alias: pci:v00001002d000094B5sv*sd*bc*sc*i*
alias: pci:v00001002d00009495sv*sd*bc*sc*i*
alias: pci:v00001002d00009490sv*sd*bc*sc*i*
alias: pci:v00001002d00009498sv*sd*bc*sc*i*
alias: pci:v00001002d0000948Fsv*sd*bc*sc*i*
alias: pci:v00001002d00009487sv*sd*bc*sc*i*
alias: pci:v00001002d0000954Fsv*sd*bc*sc*i*
alias: pci:v00001002d0000954Esv*sd*bc*sc*i*
alias: pci:v00001002d00009542sv*sd*bc*sc*i*
alias: pci:v00001002d00009541sv*sd*bc*sc*i*
alias: pci:v00001002d00009540sv*sd*bc*sc*i*
alias: pci:v00001002d00009517sv*sd*bc*sc*i*
alias: pci:v00001002d00009519sv*sd*bc*sc*i*
alias: pci:v00001002d00009515sv*sd*bc*sc*i*
alias: pci:v00001002d00009500sv*sd*bc*sc*i*
alias: pci:v00001002d00009507sv*sd*bc*sc*i*
alias: pci:v00001002d00009501sv*sd*bc*sc*i*
alias: pci:v00001002d00009505sv*sd*bc*sc*i*
alias: pci:v00001002d00009597sv*sd*bc*sc*i*
alias: pci:v00001002d00009596sv*sd*bc*sc*i*
alias: pci:v00001002d00009599sv*sd*bc*sc*i*
alias: pci:v00001002d00009598sv*sd*bc*sc*i*
alias: pci:v00001002d00009590sv*sd*bc*sc*i*
alias: pci:v00001002d00009589sv*sd*bc*sc*i*
alias: pci:v00001002d00009588sv*sd*bc*sc*i*
alias: pci:v00001002d00009580sv*sd*bc*sc*i*
alias: pci:v00001002d00009587sv*sd*bc*sc*i*
alias: pci:v00001002d00009586sv*sd*bc*sc*i*
alias: pci:v00001002d0000958Esv*sd*bc*sc*i*
alias: pci:v00001002d0000958Asv*sd*bc*sc*i*
alias: pci:v00001002d000095C6sv*sd*bc*sc*i*
alias: pci:v00001002d000095C9sv*sd*bc*sc*i*
alias: pci:v00001002d000095C7sv*sd*bc*sc*i*
alias: pci:v00001002d000095C5sv*sd*bc*sc*i*
alias: pci:v00001002d000095C0sv*sd*bc*sc*i*
alias: pci:v00001002d000094CCsv*sd*bc*sc*i*
alias: pci:v00001002d000094C6sv*sd*bc*sc*i*
alias: pci:v00001002d000094C5sv*sd*bc*sc*i*
alias: pci:v00001002d000094C4sv*sd*bc*sc*i*
alias: pci:v00001002d000094C3sv*sd*bc*sc*i*
alias: pci:v00001002d000094C1sv*sd*bc*sc*i*
alias: pci:v00001002d000094C7sv*sd*bc*sc*i*
alias: pci:v00001002d000094C0sv*sd*bc*sc*i*
alias: pci:v00001002d00009443sv*sd*bc*sc*i*
alias: pci:v00001002d00009441sv*sd*bc*sc*i*
alias: pci:v00001002d00009451sv*sd*bc*sc*i*
alias: pci:v00001002d00009513sv*sd*bc*sc*i*
alias: pci:v00001002d0000950Fsv*sd*bc*sc*i*
alias: pci:v00001002d00009405sv*sd*bc*sc*i*
alias: pci:v00001002d00009403sv*sd*bc*sc*i*
alias: pci:v00001002d00009402sv*sd*bc*sc*i*
alias: pci:v00001002d00009401sv*sd*bc*sc*i*
alias: pci:v00001002d00009400sv*sd*bc*sc*i*
alias: pci:v00001002d00009714sv*sd*bc*sc*i*
alias: pci:v00001002d00009713sv*sd*bc*sc*i*
alias: pci:v00001002d00009712sv*sd*bc*sc*i*
alias: pci:v00001002d00009711sv*sd*bc*sc*i*
alias: pci:v00001002d00009710sv*sd*bc*sc*i*
alias: pci:v00001002d00009616sv*sd*bc*sc*i*
alias: pci:v00001002d00009615sv*sd*bc*sc*i*
alias: pci:v00001002d00009614sv*sd*bc*sc*i*
alias: pci:v00001002d00009613sv*sd*bc*sc*i*
alias: pci:v00001002d00009612sv*sd*bc*sc*i*
alias: pci:v00001002d00009611sv*sd*bc*sc*i*
alias: pci:v00001002d00009610sv*sd*bc*sc*i*
depends:
vermagic: 2.6.28-13-generic SMP mod_unload modversions
parm: firegl:charp
filename: /lib/modules/2.6.28-13-generic/updates/drivers/net/wireless/iwlwifi/iwlagn.ko
alias: iwl4965
license: GPL
author: Copyright(c) 2003-2009 Intel Corporation
<ilw@linux.intel.com>
version: 1.3.27ks
description: Intel(R) Wireless WiFi Link AGN driver for Linux
firmware: iwlwifi-4965-2.ucode
firmware: iwlwifi-5150-2.ucode
firmware: iwlwifi-5000-2.ucode
firmware: iwlwifi-6050-2.ucode
firmware: iwlwifi-6000-2.ucode
srcversion: B87DD476B37C73CA673C6F4
alias: pci:v00008086d00000084sv*sd*bc*sc*i*
alias: pci:v00008086d00000083sv*sd*bc*sc*i*
alias: pci:v00008086d00000089sv*sd*bc*sc*i*
alias: pci:v00008086d00000088sv*sd*bc*sc*i*
alias: pci:v00008086d00000087sv*sd*bc*sc*i*
alias: pci:v00008086d00000086sv*sd*bc*sc*i*
alias: pci:v00008086d00000085sv*sd*bc*sc*i*
alias: pci:v00008086d00000082sv*sd*bc*sc*i*
alias: pci:v00008086d00004239sv*sd*bc*sc*i*
alias: pci:v00008086d00004238sv*sd*bc*sc*i*
alias: pci:v00008086d0000422Csv*sd*bc*sc*i*
alias: pci:v00008086d0000422Bsv*sd*bc*sc*i*
alias: pci:v00008086d00000082sv*sd00001122bc*sc*i*
alias: pci:v00008086d00000085sv*sd00001112bc*sc*i*
alias: pci:v00008086d00000082sv*sd00001102bc*sc*i*
alias: pci:v00008086d0000423Dsv*sd*bc*sc*i*
alias: pci:v00008086d0000423Csv*sd*bc*sc*i*
alias: pci:v00008086d0000423Bsv*sd00001011bc*sc*i*
alias: pci:v00008086d0000423Asv*sd00001021bc*sc*i*
alias: pci:v00008086d0000423Asv*sd00001001bc*sc*i*
alias: pci:v00008086d00004237sv*sd*bc*sc*i*
alias: pci:v00008086d00004236sv*sd*bc*sc*i*
alias: pci:v00008086d00004235sv*sd*bc*sc*i*
alias: pci:v00008086d00004232sv*sd*bc*sc*i*
alias: pci:v00008086d00004237sv*sd00001216bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001326bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001306bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001206bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001305bc*sc*i*
alias: pci:v00008086d00004232sv*sd00001205bc*sc*i*
alias: pci:v00008086d00004230sv*sd*bc*sc*i*
alias: pci:v00008086d00004229sv*sd*bc*sc*i*
depends: iwlcore,mac80211,cfg80211
vermagic: 2.6.28-13-generic SMP mod_unload modversions
parm: swcrypto50:using software crypto engine (default 0
[hardware])
(bool)
parm: debug50:50XX debug output mask (uint)
parm: queues_num50:number of hw queues in 50xx series (int)
parm: 11n_disable50:disable 50XX 11n functionality (int)
parm: amsdu_size_8K50:enable 8K amsdu size in 50XX series
(int)
parm: fw_restart50:restart firmware in case of error (int)
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both])
(int)
parm: swcrypto:using crypto in software (default 0 [hardware])
(int)
parm: debug:debug output mask (uint)
parm: disable_hw_scan:disable hardware scanning (default 0)
(int)
parm: queues_num:number of hw queues. (int)
parm: 11n_disable:disable 11n functionality (int)
parm: amsdu_size_8K:enable 8K amsdu size (int)
parm: fw_restart4965:restart firmware in case of error (int)
[ 18.189913] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
1.3.27ks
[ 18.189915] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[ 18.189993] iwlagn 0000:04:00.0: PCI INT A -> GSI 17 (level, low) ->
IRQ 17
[ 18.190000] iwlagn 0000:04:00.0: setting latency timer to 64
[ 18.190061] iwlagn 0000:04:00.0: Detected Intel Wireless WiFi Link
5300AGN REV=0x24
[ 18.227051] iwlagn 0000:04:00.0: Tunable channels: 13 802.11bg, 24
802.11a channels
[ 18.227114] iwlagn 0000:04:00.0: irq 2297 for MSI/MSI-X
[ 18.270223] phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 78.738523] iwlagn 0000:04:00.0: firmware: requesting
iwlwifi-5000-2.ucode
[ 78.845574] iwlagn 0000:04:00.0: loaded firmware version 8.24.2.12
[ 79.026242] Registered led device: iwl-phy0::radio
[ 79.027598] Registered led device: iwl-phy0::assoc
[ 79.027624] Registered led device: iwl-phy0::RX
[ 79.027640] Registered led device: iwl-phy0::TX
Easiest way to remedy is to simply remove the compat-wireless "extra"
modules and reload the originals.
Thanks, and I can provide any info needed to try to get somewhere with
this.
-Greg
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Luis Correia @ 2009-07-28 11:11 UTC (permalink / raw)
To: Chris Clayton; +Cc: Johannes Berg, Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <c6b1100b0907280403x697d8816mfb5206e1fb93243a@mail.gmail.com>
Hi Chris
On Tue, Jul 28, 2009 at 12:03, Chris Clayton<chris2553@googlemail.com> wrote:
> Hi everyone,
>
> 2009/7/27 Johannes Berg <johannes@sipsolutions.net>:
>> On Mon, 2009-07-27 at 21:22 +0100, Chris Clayton wrote:
>>
>>> Yes, I remove the card once the laptop has frozen, because doing so "thaws" it again. The laptop is
>>> then usable until 2-5 minutes after I insert the card again, when it will freeze again. I can
>>> repeat this cycle over and over.
>>
>
> Inspired by the fact that Pavel doesn't get the freeze, I've just
> cloned and tested the latest and greatest wireless-testing tree and,
> unfortunately, the freeze still occurs. In fact it seems to happen
> even more quickly now!
>
>> That really points to a hw (or hw programming) bug that causes the card
>> to lock up the bus. Had that many times in early b43 days.
>
> If it's a programming problem, might it be fixable in the firmware
> (rt2561s.bin)?
>
> If not and given this is a Belkin card (model F5D7010), I guess there
> could be thousands of them out there, so some note on the Devices
> section of linuxwireless.org might help other users. In fact two
> versions of this this model are currently shown as supported by the
> b43 driver, but this, which has worked fine until now, isn't mentioned
> at all. T
>
>>> > It looks like a problem specific to the hardware, not anything in the
>>> > common wireless code. I suggest that you post your question to
>>> > users@rt2x00.serialmonkey.com. That's the mailing list for rt61pci and
>>> > other Ralink devices.
>>>
>>> I think I'll just configure MAC80211 power saving off or use the ath5k card that I also own.
>>
>> You could also ask Ivo to disable power saving for rt61pci.
>>
>
> Rather than simply disabling power saving, could it be done though a
> module parameter, so that those with more robust cards are not
> disadvantaged?
>
> Chris
Can you do a very dumb test for me?
Boot your laptop by adding 'irqpoll' to the kernel command line
options and see if the problem still occours.
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Chris Clayton @ 2009-07-28 11:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <1248726744.32365.4.camel@johannes.local>
Hi everyone,
2009/7/27 Johannes Berg <johannes@sipsolutions.net>:
> On Mon, 2009-07-27 at 21:22 +0100, Chris Clayton wrote:
>
>> Yes, I remove the card once the laptop has frozen, because doing so "thaws" it again. The laptop is
>> then usable until 2-5 minutes after I insert the card again, when it will freeze again. I can
>> repeat this cycle over and over.
>
Inspired by the fact that Pavel doesn't get the freeze, I've just
cloned and tested the latest and greatest wireless-testing tree and,
unfortunately, the freeze still occurs. In fact it seems to happen
even more quickly now!
> That really points to a hw (or hw programming) bug that causes the card
> to lock up the bus. Had that many times in early b43 days.
If it's a programming problem, might it be fixable in the firmware
(rt2561s.bin)?
If not and given this is a Belkin card (model F5D7010), I guess there
could be thousands of them out there, so some note on the Devices
section of linuxwireless.org might help other users. In fact two
versions of this this model are currently shown as supported by the
b43 driver, but this, which has worked fine until now, isn't mentioned
at all. T
>> > It looks like a problem specific to the hardware, not anything in the
>> > common wireless code. I suggest that you post your question to
>> > users@rt2x00.serialmonkey.com. That's the mailing list for rt61pci and
>> > other Ralink devices.
>>
>> I think I'll just configure MAC80211 power saving off or use the ath5k card that I also own.
>
> You could also ask Ivo to disable power saving for rt61pci.
>
Rather than simply disabling power saving, could it be done though a
module parameter, so that those with more robust cards are not
disadvantaged?
Chris
--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson
^ permalink raw reply
* Re: [PATCH] ar9170: remove EXPERIMENTAL marker
From: Chunkeey @ 2009-07-28 10:12 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
"Luis R. Rodriguez" <lrodriguez@atheros.com> wrote:
> Cc: Christian Lamparter <chunkeey@web.de>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ar9170/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ar9170/Kconfig b/drivers/net/wireless/ath/ar9170/Kconfig
> index de4281f..05918f1 100644
> --- a/drivers/net/wireless/ath/ar9170/Kconfig
> +++ b/drivers/net/wireless/ath/ar9170/Kconfig
> @@ -1,12 +1,13 @@
> config AR9170_USB
> tristate "Atheros AR9170 802.11n USB support"
> - depends on USB && MAC80211 && WLAN_80211 && EXPERIMENTAL
> + depends on USB && MAC80211 && WLAN_80211
>
huh? there are still:
- 9 TODOs
- 7 XXX
- 3 FIXMEs
left _to do_ for the driver.
Not to mention known problems and bugs!
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* Re: [PATCH] libertas: Read buffer overflow
From: Roel Kluin @ 2009-07-28 10:05 UTC (permalink / raw)
To: Holger Schurig; +Cc: dcbw, libertas-dev, linux-wireless, Andrew Morton
In-Reply-To: <200907281019.56855.hs4233@mail.mn-solutions.de>
Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.
rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.
tmp_size can increment at most to (ARRAY_SIZE(lbs_bg_rates) - 1) *
(*rates_size - 1), so that should be the number of elements of tmp[].
A goto can be eliminated: ret was already set upon its declaration.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Op 28-07-09 10:19, Holger Schurig schreef:
>> - size_t num_card_rates = sizeof(lbs_bg_rates);
>> + size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
>
> Hmm, not sure about this. First I don't know if we need a
> variable for this at all. Can't you simply use ARRAY_SIZE()
> whenever it's needed?
Of course. Please note the additional changes.
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..d699737 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
/* Copyright (C) 2006, Red Hat, Inc. */
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/ieee80211.h>
#include <linux/if_arp.h>
@@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
u16 *rates_size)
{
u8 *card_rates = lbs_bg_rates;
- size_t num_card_rates = sizeof(lbs_bg_rates);
int ret = 0, i, j;
- u8 tmp[30];
+ u8 tmp[(ARRAY_SIZE(lbs_bg_rates) - 1) * (*rates_size - 1)];
size_t tmp_size = 0;
/* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
- for (j = 0; rates[j] && (j < *rates_size); j++) {
+ for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
+ for (j = 0; j < *rates_size && rates[j]; j++) {
if (rates[j] == card_rates[i])
tmp[tmp_size++] = card_rates[i];
}
}
lbs_deb_hex(LBS_DEB_JOIN, "AP rates ", rates, *rates_size);
- lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates, num_card_rates);
+ lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates,
+ ARRAY_SIZE(lbs_bg_rates));
lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
@@ -69,10 +70,7 @@ static int get_common_rates(struct lbs_private *priv,
lbs_pr_alert("Previously set fixed data rate %#x isn't "
"compatible with the network.\n", priv->cur_rate);
ret = -1;
- goto done;
}
- ret = 0;
-
done:
memset(rates, 0, *rates_size);
*rates_size = min_t(int, tmp_size, *rates_size);
@@ -322,7 +320,7 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
memcpy(&rates->rates, &bss->rates, MAX_RATES);
- tmplen = MAX_RATES;
+ tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
goto done;
@@ -598,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");
^ permalink raw reply related
* Re: Problem with exclusive interrupt in hostap_cs
From: Wolfram Sang @ 2009-07-28 8:34 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-pcmcia, linux-wireless
In-Reply-To: <4A6E2A12.30009@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
> As Dominik was missing and there was no action on the linux-pcmcia
> list, I took advantage of the fact that this is a wireless device and
> submitted the patch to John Linville. It is commit
> e4a01604b8e5656f3a059f52b3e8f2560740c057 in the wireless-testing tree
> and was sent to DaveM on July 24 for linux-next. It will be in 2.6.32.
Great. IMHO the netdev-tree was the more apropriate one anyhow. It seems it got
into linux-next shortly after I checked, so sorry for the noise!
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] libertas: Read buffer overflow
From: Holger Schurig @ 2009-07-28 8:19 UTC (permalink / raw)
To: Roel Kluin; +Cc: dcbw, libertas-dev, linux-wireless, Andrew Morton
In-Reply-To: <4A6EB00D.5010401@gmail.com>
> - size_t num_card_rates = sizeof(lbs_bg_rates);
> + size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
Hmm, not sure about this. First I don't know if we need a
variable for this at all. Can't you simply use ARRAY_SIZE()
whenever it's needed?
If you want to keep num_card_rates, you should change it's
type. "size_t" is normally used to denote sizes in bytes, e.g.
it's the type for the length of malloc and friends. But now the
variable holds a number of elements and should be int or
unsigned int.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] libertas: Read outside array bounds
From: Holger Schurig @ 2009-07-28 8:13 UTC (permalink / raw)
To: Roel Kluin; +Cc: dcbw, libertas-dev, linux-wireless, Andrew Morton
In-Reply-To: <4A6EAFF3.8050502@gmail.com>
Acked-by: Holger Schurig <hs4233@mail.mn-solutions.de>
--
http://www.holgerschurig.de
^ permalink raw reply
* [PATCH] libertas: Read buffer overflow
From: Roel Kluin @ 2009-07-28 8:00 UTC (permalink / raw)
To: dcbw, libertas-dev, linux-wireless, Andrew Morton
Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.
rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.
Since ratesize is at most MAX_RATES, tmp_size can increment at most
to MAX_RATES * ARRAY_SIZE(lbs_bg_rates), so that should be the number
of elements of tmp[].
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Please review.
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..7dfbb0c 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
/* Copyright (C) 2006, Red Hat, Inc. */
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/ieee80211.h>
#include <linux/if_arp.h>
@@ -43,14 +44,14 @@ static int get_common_rates(struct lbs_private *priv,
u16 *rates_size)
{
u8 *card_rates = lbs_bg_rates;
- size_t num_card_rates = sizeof(lbs_bg_rates);
+ size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
int ret = 0, i, j;
- u8 tmp[30];
+ u8 tmp[MAX_RATES * ARRAY_SIZE(lbs_bg_rates)];
size_t tmp_size = 0;
/* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
- for (j = 0; rates[j] && (j < *rates_size); j++) {
+ for (i = 0; i < num_card_rates && card_rates[i]; i++) {
+ for (j = 0; j < *rates_size && rates[j]; j++) {
if (rates[j] == card_rates[i])
tmp[tmp_size++] = card_rates[i];
}
@@ -322,7 +323,7 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
memcpy(&rates->rates, &bss->rates, MAX_RATES);
- tmplen = MAX_RATES;
+ tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
goto done;
@@ -598,7 +599,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.
");
^ permalink raw reply related
* [PATCH] libertas: Read outside array bounds
From: Roel Kluin @ 2009-07-28 7:59 UTC (permalink / raw)
To: dcbw, libertas-dev, linux-wireless, Andrew Morton
reads bss->rates[j] before checking bounds of index, and should use
ARRAY_SIZE to determine the size of the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 601b542..6c95af3 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
@@ -5,6 +5,7 @@
* for sending scan commands to the firmware.
*/
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/if_arp.h>
#include <asm/unaligned.h>
@@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
iwe.u.bitrate.disabled = 0;
iwe.u.bitrate.value = 0;
- for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
+ for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
/* Bit rate given in 500 kb/s units */
iwe.u.bitrate.value = bss->rates[j] * 500000;
current_val = iwe_stream_add_value(info, start, current_val,
^ permalink raw reply related
* Re: [PATCH 04/14] iwlwifi: Thermal Throttling Management - part 2
From: reinette chatre @ 2009-07-28 7:47 UTC (permalink / raw)
To: Johannes Berg
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Guy, Wey-Yi W
In-Reply-To: <1248766429.8113.1.camel@johannes.local>
On Tue, 2009-07-28 at 00:33 -0700, Johannes Berg wrote:
> On Mon, 2009-07-27 at 15:46 -0700, reinette chatre wrote:
>
> > Sorry for missing this. We are trying to be better with documentation
> > and need to do more work in this area. This patch is currently in
> > wireless-testing. I am not sure how to proceed here. If I send a cleanup
> > patch on top of current wireless-testing it will only make sense to
> > address other kernel-doc mishaps. As our driver has not been tested
> > (afaik) to provide meaningful documentation when kernel-doc is used I am
> > hesitant to take on this right now ... but it is something we have to
> > address at some point.
>
> Yeah, I know it's not used, and I'm sure there's more -- I was just
> looking at the code trying to rebase a patch and this caught my eye.
> It's certainly not too important, but I wanted to point it out anyway if
> only to avoid that in the future :)
Point taken. Thank you very much.
Reinette
^ permalink raw reply
* Re: [RFC] cfg80211: send country ie processing on the reg_work struct
From: Johannes Berg @ 2009-07-28 7:37 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1248744593-6597-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Mon, 2009-07-27 at 18:29 -0700, Luis R. Rodriguez wrote:
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>
> Did this in a flash, so just want to see if this is you like this
> approach. Of course a lot of cleaning can be done here but ignore that
> for now (like the fact that beacon hint doesn't really process IEs,
> and the functions names used here).
>
> This just compiles for me, never tested it.
Looks ok, but I don't see why you need this type enum?
> + * enum beacon_hint_type - type of regulatory beacon hint
I mean -- if the beacon was received we could just process it as before,
and if it also has a country IE we can just process that additionally?
Why bother doing both separately?
Also, I would have allocated the struct and the space for the IE
together, but that really doesn't matter :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 04/14] iwlwifi: Thermal Throttling Management - part 2
From: Johannes Berg @ 2009-07-28 7:33 UTC (permalink / raw)
To: reinette chatre
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Guy, Wey-Yi W
In-Reply-To: <1248734807.1216.619.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On Mon, 2009-07-27 at 15:46 -0700, reinette chatre wrote:
> Sorry for missing this. We are trying to be better with documentation
> and need to do more work in this area. This patch is currently in
> wireless-testing. I am not sure how to proceed here. If I send a cleanup
> patch on top of current wireless-testing it will only make sense to
> address other kernel-doc mishaps. As our driver has not been tested
> (afaik) to provide meaningful documentation when kernel-doc is used I am
> hesitant to take on this right now ... but it is something we have to
> address at some point.
Yeah, I know it's not used, and I'm sure there's more -- I was just
looking at the code trying to rebase a patch and this caught my eye.
It's certainly not too important, but I wanted to point it out anyway if
only to avoid that in the future :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* ath5k connection loss (failed to wakeup the MAC Chip)
From: Adrian von Bidder @ 2009-07-28 6:38 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 19042 bytes --]
Heyho!
(This is using kernel 2.6.31-rc3 as packaged by Debian)
While taking a full backup of my laptop, I noticed that after a few 100M the
ath5k can't connect to WLAN anymore.
syslog shows:
+++
Jul 28 00:12:59 laeggerli kernel: [187967.601820] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:13:04 laeggerli wpa_supplicant[2574]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Jul 28 00:13:04 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Jul 28 00:13:04 laeggerli kernel: [187973.344128] wlan0: no probe response from AP 00:21:29:7c:d6:7e - disassociating
Jul 28 00:13:05 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: Trying to associate with 00:21:29:7c:d6:7e (SSID='JUNGBORN' freq=2437 MHz)
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: Association request to the driver failed
Jul 28 00:13:06 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
Jul 28 00:13:06 laeggerli kernel: [187974.834410] wlan0: authenticate with AP 00:21:29:7c:d6:7e
Jul 28 00:13:06 laeggerli kernel: [187974.835893] wlan0: authenticated
Jul 28 00:13:06 laeggerli kernel: [187974.835902] wlan0: associate with AP 00:21:29:7c:d6:7e
Jul 28 00:13:06 laeggerli kernel: [187974.838825] wlan0: RX ReassocResp from 00:21:29:7c:d6:7e (capab=0x411 status=13 aid=0)
Jul 28 00:13:06 laeggerli kernel: [187974.838839] wlan0: AP denied association (code=13)
Jul 28 00:13:06 laeggerli kernel: [187975.032147] wlan0: associate with AP 00:21:29:7c:d6:7e
Jul 28 00:13:06 laeggerli kernel: [187975.232140] wlan0: associate with AP 00:21:29:7c:d6:7e
Jul 28 00:13:06 laeggerli kernel: [187975.234415] wlan0: RX AssocResp from 00:21:29:7c:d6:7e (capab=0x411 status=0 aid=2)
Jul 28 00:13:06 laeggerli kernel: [187975.234427] wlan0: associated
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: Associated with 00:21:29:7c:d6:7e
Jul 28 00:13:06 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: associating -> associated
Jul 28 00:13:06 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: associated -> 4-way handshake
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: WPA: Key negotiation completed with 00:21:29:7c:d6:7e [PTK=CCMP GTK=CCMP]
Jul 28 00:13:06 laeggerli wpa_supplicant[2574]: CTRL-EVENT-CONNECTED - Connection to 00:21:29:7c:d6:7e completed (reauth) [id=0 id_str=]
Jul 28 00:13:06 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: 4-way handshake -> group handshake
Jul 28 00:13:06 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed
Jul 28 00:13:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:15:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:16:57 laeggerli kernel: [188206.300081] CE: hpet increasing min_delta_ns to 22500 nsec
Jul 28 00:17:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:19:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:21:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:23:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:25:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:27:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:29:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:31:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:33:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:35:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:36:33 laeggerli wpa_supplicant[2574]: WPA: Group rekeying completed with 00:21:29:7c:d6:7e [GTK=CCMP]
Jul 28 00:36:33 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: completed -> group handshake
Jul 28 00:36:33 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed
Jul 28 00:37:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:39:50 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:40:39 laeggerli wpa_supplicant[2574]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Jul 28 00:40:39 laeggerli kernel: [189628.185908] wlan0: no probe response from AP 00:21:29:7c:d6:7e - disassociating
Jul 28 00:40:39 laeggerli kernel: [189628.312377] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:40:39 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Jul 28 00:40:39 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 28 00:40:40 laeggerli kernel: [189628.381965] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:40 laeggerli kernel: [189628.381984] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:40 laeggerli kernel: [189628.419755] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:40 laeggerli kernel: [189628.419771] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:40 laeggerli kernel: [189628.457511] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:40 laeggerli kernel: [189628.457526] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:40 laeggerli kernel: [189628.495260] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:40 laeggerli kernel: [189628.495276] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:40 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:40:45 laeggerli kernel: [189633.901859] __ratelimit: 20 callbacks suppressed
Jul 28 00:40:45 laeggerli kernel: [189633.901872] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:45 laeggerli kernel: [189633.901886] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:45 laeggerli kernel: [189633.939635] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:45 laeggerli kernel: [189633.939651] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:45 laeggerli kernel: [189633.977350] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:45 laeggerli kernel: [189633.977365] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:45 laeggerli kernel: [189634.015105] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:45 laeggerli kernel: [189634.015120] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:45 laeggerli kernel: [189634.052883] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:45 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:40:50 laeggerli kernel: [189639.310908] __ratelimit: 18 callbacks suppressed
Jul 28 00:40:50 laeggerli kernel: [189639.310923] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:40:51 laeggerli kernel: [189639.423590] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:51 laeggerli kernel: [189639.423608] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:51 laeggerli kernel: [189639.461345] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:51 laeggerli kernel: [189639.461361] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:51 laeggerli kernel: [189639.499131] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:51 laeggerli kernel: [189639.499147] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:51 laeggerli kernel: [189639.536910] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:51 laeggerli kernel: [189639.536926] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:51 laeggerli kernel: [189639.574650] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:51 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): device state change: 8 -> 3
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): deactivating device (reason: 11).
Jul 28 00:40:55 laeggerli NetworkManager: <info> wlan0: canceled DHCP transaction, dhcp client pid 22348
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): removing resolv.conf from /sbin/resolvconf
Jul 28 00:40:55 laeggerli NetworkManager: <WARN> check_one_route(): (wlan0) error -34 returned from rtnl_route_del(): Sucess#012
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) starting connection 'JUNGBORN'
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): device state change: 3 -> 4
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jul 28 00:40:55 laeggerli NetworkManager: <info> (wlan0): device state change: 4 -> 5
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0/wireless): connection 'JUNGBORN' has security, and secrets exist. No
new
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: added 'ssid' value 'JUNGBORN'
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: added 'scan_ssid' value '1'
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: added 'auth_alg' value 'OPEN'
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: added 'psk' value '<omitted>'
Jul 28 00:40:55 laeggerli NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jul 28 00:40:55 laeggerli NetworkManager: <info> Config: set interface ap_scan to 1
Jul 28 00:40:56 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 28 00:40:56 laeggerli kernel: [189644.942989] __ratelimit: 19 callbacks suppressed
Jul 28 00:40:56 laeggerli kernel: [189644.943006] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:56 laeggerli kernel: [189644.943025] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:56 laeggerli kernel: [189644.980644] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:56 laeggerli kernel: [189644.980657] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:56 laeggerli kernel: [189645.018382] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:56 laeggerli kernel: [189645.018400] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:56 laeggerli kernel: [189645.056153] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:56 laeggerli kernel: [189645.056169] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:56 laeggerli kernel: [189645.093905] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:40:56 laeggerli kernel: [189645.093920] ath5k phy0: can't reset hardware (-5)
Jul 28 00:40:57 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:41:01 laeggerli kernel: [189650.312282] __ratelimit: 18 callbacks suppressed
Jul 28 00:41:01 laeggerli kernel: [189650.312297] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:41:02 laeggerli kernel: [189650.465854] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:02 laeggerli kernel: [189650.465873] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:02 laeggerli kernel: [189650.503638] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:02 laeggerli kernel: [189650.503654] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:02 laeggerli kernel: [189650.541381] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:02 laeggerli kernel: [189650.541397] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:02 laeggerli kernel: [189650.579152] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:02 laeggerli kernel: [189650.579168] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:02 laeggerli kernel: [189650.616908] ath5k phy0: failed to wakeup the MAC Chip
...
Jul 28 00:41:19 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:41:21 laeggerli NetworkManager: <info> Activation (wlan0/wireless): association took too long.
Jul 28 00:41:21 laeggerli NetworkManager: <info> (wlan0): device state change: 5 -> 6
Jul 28 00:41:21 laeggerli NetworkManager: <info> Activation (wlan0/wireless): asking for new secrets
Jul 28 00:41:21 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected
Jul 28 00:41:23 laeggerli kernel: [189672.311165] __ratelimit: 18 callbacks suppressed
Jul 28 00:41:23 laeggerli kernel: [189672.311180] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:41:34 laeggerli kernel: [189683.312283] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:41:36 laeggerli NetworkManager: <info> wlan0: link timed out.
Jul 28 00:41:45 laeggerli kernel: [189694.310974] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:41:49 laeggerli NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 28 00:41:49 laeggerli kernel: [189697.437887] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:49 laeggerli kernel: [189697.437906] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:49 laeggerli kernel: [189697.475626] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:49 laeggerli kernel: [189697.475640] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:49 laeggerli kernel: [189697.513393] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:49 laeggerli kernel: [189697.513410] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:49 laeggerli kernel: [189697.551173] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:49 laeggerli kernel: [189697.551190] ath5k phy0: can't reset hardware (-5)
Jul 28 00:41:49 laeggerli kernel: [189697.588922] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:41:49 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:41:56 laeggerli kernel: [189705.310991] __ratelimit: 19 callbacks suppressed
Jul 28 00:41:56 laeggerli kernel: [189705.311005] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:42:07 laeggerli kernel: [189716.310940] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:42:18 laeggerli kernel: [189727.311011] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:42:29 laeggerli kernel: [189738.312159] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:42:40 laeggerli kernel: [189749.310972] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:42:51 laeggerli kernel: [189760.310827] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:43:02 laeggerli kernel: [189771.310876] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:43:13 laeggerli kernel: [189782.310957] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:43:24 laeggerli kernel: [189793.310941] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:43:49 laeggerli kernel: [189817.437845] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:43:49 laeggerli kernel: [189817.437864] ath5k phy0: can't reset hardware (-5)
Jul 28 00:43:49 laeggerli kernel: [189817.475614] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:43:49 laeggerli kernel: [189817.475627] ath5k phy0: can't reset hardware (-5)
Jul 28 00:43:49 laeggerli kernel: [189817.513366] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:43:49 laeggerli kernel: [189817.513383] ath5k phy0: can't reset hardware (-5)
Jul 28 00:43:49 laeggerli kernel: [189817.551138] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:43:49 laeggerli kernel: [189817.551153] ath5k phy0: can't reset hardware (-5)
Jul 28 00:43:49 laeggerli kernel: [189817.588901] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:43:49 laeggerli wpa_supplicant[2574]: CTRL-EVENT-SCAN-RESULTS
Jul 28 00:43:57 laeggerli kernel: [189826.310939] __ratelimit: 19 callbacks suppressed
Jul 28 00:43:57 laeggerli kernel: [189826.310954] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:44:08 laeggerli kernel: [189837.310993] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:44:19 laeggerli kernel: [189848.310941] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:44:30 laeggerli kernel: [189859.312331] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:44:41 laeggerli kernel: [189870.310908] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:44:52 laeggerli kernel: [189881.310876] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:03 laeggerli kernel: [189892.310988] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:14 laeggerli kernel: [189903.311005] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:25 laeggerli kernel: [189914.310988] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:36 laeggerli kernel: [189925.312394] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:47 laeggerli kernel: [189936.310909] ath5k phy0: noise floor calibration timeout (2437MHz)
Jul 28 00:45:49 laeggerli kernel: [189937.437866] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:45:49 laeggerli kernel: [189937.437885] ath5k phy0: can't reset hardware (-5)
Jul 28 00:45:49 laeggerli kernel: [189937.475614] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:45:49 laeggerli kernel: [189937.475628] ath5k phy0: can't reset hardware (-5)
Jul 28 00:45:49 laeggerli kernel: [189937.513360] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:45:49 laeggerli kernel: [189937.513377] ath5k phy0: can't reset hardware (-5)
Jul 28 00:45:49 laeggerli kernel: [189937.551138] ath5k phy0: failed to wakeup the MAC Chip
Jul 28 00:45:49 laeggerli kernel: [189937.551154] ath5k phy0: can't reset hardware (-5)
Jul 28 00:45:49 laeggerli kernel: [189937.588900] ath5k phy0: failed to wakeup the MAC Chip
etc. etc.
+++
This only happens with bulk data transfers, and probably only when sending.
Downloading large dataset over WLAN is fine (I haven't tested it as much as
sending, though: downloads are mostly small, while the bulk sending happens
regularly during backup.)
It is not related to how long the WLAN is up: I can work for days or weeks
(happened with earlier kernels as well) with this laptop, over
suspend/resume, and WLAN works fine. It's only when I run backup that it
happens (always - but I since backups usually are incremental, they're often
small enough. But once I do a full backup WLAN goes down. So use cable for
those...)
Is this known? Can I get you more information?
Hardware is Acer AOA 150.
thanks
-- vbi
--
featured link: Debian Bookmark Collection - http://bookmarks.debian.net/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 388 bytes --]
^ permalink raw reply
* Re: [PATCH] rt2x00: remove experimental on kconfig
From: Ivo van Doorn @ 2009-07-28 6:17 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1248736854-443-1-git-send-email-lrodriguez@atheros.com>
On Tuesday 28 July 2009, Luis R. Rodriguez wrote:
> These have been around for a while, if there are issues
> they should be reported.
>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>
> Ivo, is this fair to say? Was surprised to see rt2x00 marked
> as experimental still.
Well I think removing the experimental flag is fine, the most serious
problem with most drivers is the throughput, but I guess that is not
a blocker for removing the experimental flag.
However please move the experimental flag to rt2800usb, since that
driver is very recent and is not working correctly for a lot of people.
Thanks,
Ivo
> drivers/net/wireless/rt2x00/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
> index f970aa2..379da5c 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -1,8 +1,8 @@
> menuconfig RT2X00
> tristate "Ralink driver support"
> - depends on MAC80211 && WLAN_80211 && EXPERIMENTAL
> + depends on MAC80211 && WLAN_80211
> ---help---
> - This will enable the experimental support for the Ralink drivers,
> + This will enable the support for the Ralink drivers,
> developed in the rt2x00 project <http://rt2x00.serialmonkey.com>.
>
> These drivers make use of the mac80211 stack.
^ permalink raw reply
* RE: [PATCH] iwlwifi: Read outside array bounds
From: Zhu Yi @ 2009-07-28 5:17 UTC (permalink / raw)
To: Chatre, Reinette
Cc: Winkler, Tomas, Roel Kluin, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton
In-Reply-To: <1248756646.1216.662.camel@rc-desk>
On Tue, 2009-07-28 at 12:50 +0800, Chatre, Reinette wrote:
> On Mon, 2009-07-27 at 19:27 -0700, Zhu, Yi wrote:
> > On Tue, 2009-07-28 at 06:12 +0800, Chatre, Reinette wrote:
> > > On Mon, 2009-07-27 at 01:28 -0700, Winkler, Tomas wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Zhu, Yi
> > > > > Sent: Monday, July 27, 2009 4:42 AM
> > > > > To: Roel Kluin; Winkler, Tomas; Chatre, Reinette
> > > > > Cc: linux-wireless@vger.kernel.org; ipw3945-devel@lists.sourceforge.net;
> > > > > Andrew Morton
> > > > > Subject: Re: [PATCH] iwlwifi: Read outside array bounds
> > > > >
> > > > > On Sun, 2009-07-26 at 05:34 +0800, Roel Kluin wrote:
> > > > > > tid is bounded (above) by the size of default_tid_to_tx_fifo (17
> > > > > elements), but
> > > > > > the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
> > > > >
> > > > > I think MAX_TID_COUNT should be defined as 16 or 17. Tomas?
> > > > >
> > > >
> > > > In general it's 16. In practice we use only 8.
> > >
> > > I think the above statement means that we are mostly using EDCA quality
> > > of service which only uses 8 tids. We do not currently use HCCA (and
> > > thus of course not the hybrid) which would cause more tids to be used.
> > >
> > > A closer look at this flow to this function shows:
> > > rs_tl_turn_on_agg
> >
> > rs_tl_add_packet
> > {
> > ...
> > u8 *qc = ieee80211_get_qos_ctl(hdr);
> > tid = qc[0] & 0xf;
> > ...
> >
> > tl = &lq_data->load[tid];
> > }
> >
> > This should be a problem.
>
> Indeed. Are there any other cases like this that you can think of? It
> seems like we need Roel's fix for iwl_tx_agg_stop also.
Yes. I think we can do an audit for all the ieee80211_ops callbacks with
tid as a parameter. Because mac80211 use u16 for tid, but iwlwifi use u8
internally.
Thanks,
-yi
^ permalink raw reply
* RE: [PATCH] iwlwifi: Read outside array bounds
From: reinette chatre @ 2009-07-28 4:50 UTC (permalink / raw)
To: Zhu, Yi
Cc: Winkler, Tomas, Roel Kluin, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton
In-Reply-To: <1248748076.3747.1097.camel@debian>
On Mon, 2009-07-27 at 19:27 -0700, Zhu, Yi wrote:
> On Tue, 2009-07-28 at 06:12 +0800, Chatre, Reinette wrote:
> > On Mon, 2009-07-27 at 01:28 -0700, Winkler, Tomas wrote:
> > >
> > > > -----Original Message-----
> > > > From: Zhu, Yi
> > > > Sent: Monday, July 27, 2009 4:42 AM
> > > > To: Roel Kluin; Winkler, Tomas; Chatre, Reinette
> > > > Cc: linux-wireless@vger.kernel.org; ipw3945-devel@lists.sourceforge.net;
> > > > Andrew Morton
> > > > Subject: Re: [PATCH] iwlwifi: Read outside array bounds
> > > >
> > > > On Sun, 2009-07-26 at 05:34 +0800, Roel Kluin wrote:
> > > > > tid is bounded (above) by the size of default_tid_to_tx_fifo (17
> > > > elements), but
> > > > > the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
> > > >
> > > > I think MAX_TID_COUNT should be defined as 16 or 17. Tomas?
> > > >
> > >
> > > In general it's 16. In practice we use only 8.
> >
> > I think the above statement means that we are mostly using EDCA quality
> > of service which only uses 8 tids. We do not currently use HCCA (and
> > thus of course not the hybrid) which would cause more tids to be used.
> >
> > A closer look at this flow to this function shows:
> > rs_tl_turn_on_agg
>
> rs_tl_add_packet
> {
> ...
> u8 *qc = ieee80211_get_qos_ctl(hdr);
> tid = qc[0] & 0xf;
> ...
>
> tl = &lq_data->load[tid];
> }
>
> This should be a problem.
Indeed. Are there any other cases like this that you can think of? It
seems like we need Roel's fix for iwl_tx_agg_stop also.
Reinette
^ permalink raw reply
* RE: [PATCH] iwlwifi: Read outside array bounds
From: Zhu Yi @ 2009-07-28 2:27 UTC (permalink / raw)
To: Chatre, Reinette
Cc: Winkler, Tomas, Roel Kluin, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton
In-Reply-To: <1248732735.1216.565.camel@rc-desk>
On Tue, 2009-07-28 at 06:12 +0800, Chatre, Reinette wrote:
> On Mon, 2009-07-27 at 01:28 -0700, Winkler, Tomas wrote:
> >
> > > -----Original Message-----
> > > From: Zhu, Yi
> > > Sent: Monday, July 27, 2009 4:42 AM
> > > To: Roel Kluin; Winkler, Tomas; Chatre, Reinette
> > > Cc: linux-wireless@vger.kernel.org; ipw3945-devel@lists.sourceforge.net;
> > > Andrew Morton
> > > Subject: Re: [PATCH] iwlwifi: Read outside array bounds
> > >
> > > On Sun, 2009-07-26 at 05:34 +0800, Roel Kluin wrote:
> > > > tid is bounded (above) by the size of default_tid_to_tx_fifo (17
> > > elements), but
> > > > the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
> > >
> > > I think MAX_TID_COUNT should be defined as 16 or 17. Tomas?
> > >
> >
> > In general it's 16. In practice we use only 8.
>
> I think the above statement means that we are mostly using EDCA quality
> of service which only uses 8 tids. We do not currently use HCCA (and
> thus of course not the hybrid) which would cause more tids to be used.
>
> A closer look at this flow to this function shows:
> rs_tl_turn_on_agg
rs_tl_add_packet
{
...
u8 *qc = ieee80211_get_qos_ctl(hdr);
tid = qc[0] & 0xf;
...
tl = &lq_data->load[tid];
}
This should be a problem.
Thanks,
-yi
^ permalink raw reply
* [RFC] cfg80211: send country ie processing on the reg_work struct
From: Luis R. Rodriguez @ 2009-07-28 1:29 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Did this in a flash, so just want to see if this is you like this
approach. Of course a lot of cleaning can be done here but ignore that
for now (like the fact that beacon hint doesn't really process IEs,
and the functions names used here).
This just compiles for me, never tested it.
net/wireless/reg.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 93 insertions(+), 8 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index fb40428..3005ddf 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -73,9 +73,35 @@ static spinlock_t reg_pending_beacons_lock;
/* Used to keep track of processed beacon hints */
static LIST_HEAD(reg_beacon_list);
+/**
+ * enum beacon_hint_type - type of regulatory beacon hint
+ *
+ * Beacons contain useful information for regulatory purposes.
+ * Regular beacons are useful as they indicate to world
+ * roaming stations that an AP is nearby. With careful precautions
+ * taken one can use this to assess whether or not one can lift
+ * passive scan flags and no-ibss flags on a channel.
+ * Beacons also contain certain information elements, the country
+ * IE is very specific to regulatory and contains channels specific
+ * information an AP is indicating should be respected.
+ *
+ * @REG_BEACON: indicates a beacon has been received on a
+ * specified channel. This is useful for world roaming.
+ * @REG_BEACON_COUNTRY_IE: indicates a beacon has been received
+ * with a country IE attached.
+ */
+enum beacon_hint_type {
+ REG_BEACON,
+ REG_BEACON_COUNTRY_IE,
+};
+
struct reg_beacon {
+ enum beacon_hint_type type;
+ struct wiphy *wiphy;
struct list_head list;
struct ieee80211_channel chan;
+ u8 *ie;
+ u8 ie_len;
};
/* We keep a static world regulatory domain in case of the absence of CRDA */
@@ -1607,10 +1633,35 @@ static void reg_process_pending_hints(void)
spin_unlock(®_requests_lock);
}
-/* Processes beacon hints -- this has nothing to do with country IEs */
-static void reg_process_pending_beacon_hints(void)
+static void processs_reg_beacon(struct reg_beacon *reg_beacon)
{
struct cfg80211_registered_device *rdev;
+
+ /* Applies the beacon hint to current wiphys */
+ list_for_each_entry(rdev, &cfg80211_rdev_list, list)
+ wiphy_update_new_beacon(&rdev->wiphy, reg_beacon);
+
+ /* Remembers the beacon hint for new wiphys or reg changes */
+ list_add_tail(®_beacon->list, ®_beacon_list);
+}
+
+
+static void regulatory_hint_11d_work(struct wiphy *wiphy,
+ u8 *country_ie,
+ u8 country_ie_len);
+
+static void process_reg_beacon_country_ie(struct reg_beacon *reg_beacon)
+{
+ regulatory_hint_11d_work(reg_beacon->wiphy,
+ reg_beacon->ie,
+ reg_beacon->ie_len);
+ kfree(reg_beacon->ie);
+ kfree(reg_beacon);
+}
+
+/* Processes beacon hints */
+static void reg_process_pending_beacon_hints(void)
+{
struct reg_beacon *pending_beacon, *tmp;
mutex_lock(&cfg80211_mutex);
@@ -1628,12 +1679,14 @@ static void reg_process_pending_beacon_hints(void)
list_del_init(&pending_beacon->list);
- /* Applies the beacon hint to current wiphys */
- list_for_each_entry(rdev, &cfg80211_rdev_list, list)
- wiphy_update_new_beacon(&rdev->wiphy, pending_beacon);
-
- /* Remembers the beacon hint for new wiphys or reg changes */
- list_add_tail(&pending_beacon->list, ®_beacon_list);
+ switch (pending_beacon->type) {
+ case REG_BEACON:
+ processs_reg_beacon(pending_beacon);
+ break;
+ case REG_BEACON_COUNTRY_IE:
+ process_reg_beacon_country_ie(pending_beacon);
+ break;
+ }
}
spin_unlock_bh(®_pending_beacons_lock);
@@ -1766,6 +1819,37 @@ void regulatory_hint_11d(struct wiphy *wiphy,
u8 *country_ie,
u8 country_ie_len)
{
+ struct reg_beacon *reg_beacon;
+
+ reg_beacon = kzalloc(sizeof(struct reg_beacon), GFP_KERNEL);
+ if (!reg_beacon)
+ return;
+
+ reg_beacon->ie = kzalloc(country_ie_len, GFP_KERNEL);
+ if (!reg_beacon->ie) {
+ kfree(reg_beacon);
+ return;
+ }
+
+ reg_beacon->wiphy = wiphy;
+ reg_beacon->ie_len = country_ie_len;
+ reg_beacon->type = REG_BEACON_COUNTRY_IE;
+
+ memcpy(®_beacon->ie, country_ie, reg_beacon->ie_len);
+
+ spin_lock_bh(®_pending_beacons_lock);
+ list_add_tail(®_beacon->list, ®_pending_beacons);
+ spin_unlock_bh(®_pending_beacons_lock);
+
+ schedule_work(®_work);
+
+ return;
+}
+
+static void regulatory_hint_11d_work(struct wiphy *wiphy,
+ u8 *country_ie,
+ u8 country_ie_len)
+{
struct ieee80211_regdomain *rd = NULL;
char alpha2[2];
u32 checksum = 0;
@@ -1933,6 +2017,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
memcpy(®_beacon->chan, beacon_chan,
sizeof(struct ieee80211_channel));
+ reg_beacon->type = REG_BEACON;
/*
* Since we can be called from BH or and non-BH context
--
1.6.3.3
^ permalink raw reply related
* [PATCH] wireless: use menuconfig for WLAN_PRE80211 and WLAN_80211
From: Luis R. Rodriguez @ 2009-07-27 23:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
This should make it very clear which are pre-802.11 or not
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index ca7a8a3..dda7cc2 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -5,7 +5,7 @@
menu "Wireless LAN"
depends on !S390
-config WLAN_PRE80211
+menuconfig WLAN_PRE80211
bool "Wireless LAN (pre-802.11)"
depends on NETDEVICES
---help---
@@ -101,7 +101,7 @@ config PCMCIA_NETWAVE
called netwave_cs. If unsure, say N.
-config WLAN_80211
+menuconfig WLAN_80211
bool "Wireless LAN (IEEE 802.11)"
depends on NETDEVICES
---help---
--
1.6.3.3
^ permalink raw reply related
* [PATCH] ar9170: remove EXPERIMENTAL marker
From: Luis R. Rodriguez @ 2009-07-27 23:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Christian Lamparter
In-Reply-To: <1248738730-4003-1-git-send-email-lrodriguez@atheros.com>
Cc: Christian Lamparter <chunkeey@web.de>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ar9170/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/Kconfig b/drivers/net/wireless/ath/ar9170/Kconfig
index de4281f..05918f1 100644
--- a/drivers/net/wireless/ath/ar9170/Kconfig
+++ b/drivers/net/wireless/ath/ar9170/Kconfig
@@ -1,12 +1,13 @@
config AR9170_USB
tristate "Atheros AR9170 802.11n USB support"
- depends on USB && MAC80211 && WLAN_80211 && EXPERIMENTAL
+ depends on USB && MAC80211 && WLAN_80211
select FW_LOADER
help
This is a driver for the Atheros "otus" 802.11n USB devices.
These devices require additional firmware (2 files).
For now, these files can be downloaded from here:
+
http://wireless.kernel.org/en/users/Drivers/ar9170
If you choose to build a module, it'll be called ar9170usb.
--
1.6.0.4
^ 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