* iwl3945 bug in 2.6.34
From: Satish Eerpini @ 2010-05-23 6:25 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless
hello,
I am running a custom compiled 2.6.34 (fedora 12) on a hp nx7400 with
a Intel Pro Wireless 3945 card, the card works fine and connects to a
WEP secure wireless connection on my router. But after some time
network manager starts reporting that the wireless access point is not
available anymore and tries to reconnect to the network, though the
network is still available, it fails to detect the network , I have
not been able to reproduce the situation conclusively, seems to be
happening randomly ... here is the tail from "dmesg" which looked
suspicious :
(btw, I also faced the same problem earlier when I was running RHEL
beta 6.0 on the same machine)
No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: IN
cfg80211: Regulatory domain changed to country: IN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 2000 mBm)
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:10:00.0: Error setting new configuration (-110).
iwl3945 0000:10:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
iwl3945 0000:10:00.0: No space in command queue
iwl3945 0000:10:00.0: Restarting adapter due to queue full
iwl3945 0000:10:00.0: Error sending REPLY_RXON: enqueue_hcmd failed: -28
iwl3945 0000:10:00.0: Error setting new configuration (-28).
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: BSM uCode verification failed at addr
0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
iwl3945 0000:10:00.0: request scan called when driver not ready.
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
usb 2-1: USB disconnect, address 2
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: BSM uCode verification failed at addr
0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
how can this be fixed ? I need to reboot the machine every time this happens,
please let me know if any other information is needed .
Cheers
Satish
--
http://tuxitter.blogspot.com
^ permalink raw reply
* Re: carl9170 1.0.9
From: David H. Lynch Jr. @ 2010-05-23 5:30 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
In-Reply-To: <201005230334.29866.chunkeey@googlemail.com>
On 05/22/2010 09:34 PM, Christian Lamparter wrote:
>> I beleive the timer_init() routine in carlfw/src/timer.c can not be
>> called for more than one timer. Any subsequent call will clear the
>> interrupt and mode bits for the previous timer.
>>
> there's more than that.
> Take a look at the (timer<< 2) and so forth...
>
The control and interrupt registers are bitmasks.
When you set the bit for the current timer you are clearing all the
others.
> based on observation: Some timers(1-4) are *driven* by the cpu clock.
> Which is of course determined by the operation mode and phy band.
> As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
> * 40MHz (refclock)
> * 20MHz (PSM, 5GHz)& 22MHz (PSM, 2.4GHz)
> * 40MHz (11an, 5GHz, HT20)& 44Mhz (11bgn, 2.4GHz, HT20)
> * 80MHz (11an, 5GHz, HT40)& 88MHz (11bgn, 2.4GHz, HT40)
>
Thanks I have been working alot more with the timers today.
TSF follows the docs and is 1us.
My docs say that CCR is 25ns and only 16 bit.
But your code and that of the original ar9710-fw has it as 2 16 bit
registers making 32bits.
I have verified that and verified that it is pretty close to 25ns.
in my system.
But the remainder of the timers seem to be much much slower. My dos
do not specify that they are tied to anything specific.
I tripped over the AHB/CPU clock in the code. I need to look much
more thoroughly at that, and I am going to need to work out exactly how
it effects the other timers. I need the fastest timer I can get for my
application.
Thanks alot.
i will pull 1.0.9.1 shortly
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: carl9170 1.0.9
From: Christian Lamparter @ 2010-05-23 1:34 UTC (permalink / raw)
To: dhlii; +Cc: linux-wireless, jal2
In-Reply-To: <4BF82CEE.8020502@dlasys.net>
On Saturday 22 May 2010 21:13:50 David H. Lynch Jr. wrote:
>
> some items I have found while making my changes to the code.
patches are welcome :-D
> In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF
> timer to make sure there is no roll over. According to the docs I have
> when TSF_LOW is read, TSF_HI is automatically concurrently copied to a
> temp register so that an immediate read of TSF_HI will get the value
> that was present when TSF_LO was read.
Thanks for that clarification. The code in question was actually a
adaptation from ar9170_op_get_tsf (patch author included in CC).
Since this is now settled, I made the necessary chances to the
kernel driver as well. (with a reference to your previous mail)
> I beleive the timer_init() routine in carlfw/src/timer.c can not be
> called for more than one timer. Any subsequent call will clear the
> interrupt and mode bits for the previous timer.
there's more than that.
Take a look at the (timer << 2) and so forth...
> I have not completely tracked these down, but the new config system
> must be missing some dependencies, because I can configure and build
> firmware that will not load.
> In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with
> CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.
>
fixed.
Thanks for your comments. I've just released 1.0.9.1, which
contains fixes for all of your comments and some additional changes.
BTW:
> I have been playing with the assorted timers in the ar9170.
> My preliminary observations seem to be indicating that
> AR9170_TIMER_REG_TIMER0 might actually be running at 40mhz/25ns,
> But that all the other timers seem to be running far slower - i.e.
> maybe they are cascaded of the overflow on timer0.
>
> I have specifically looked at timer1-4 and tic_timer and clock_low
> and they all seem to be running very slow.
> The docs that I have imply but do not state that all these clocks
> are directly off the 25ns/40mhz superH clock.
> Have you had any experience with the clocks and their rates ?
based on observation: Some timers(1-4) are *driven* by the cpu clock.
Which is of course determined by the operation mode and phy band.
As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
* 40MHz (refclock)
* 20MHz (PSM, 5GHz) & 22MHz (PSM, 2.4GHz)
* 40MHz (11an, 5GHz, HT20) & 44Mhz (11bgn, 2.4GHz, HT20)
* 80MHz (11an, 5GHz, HT40) & 88MHz (11bgn, 2.4GHz, HT40)
Regards,
Chr
^ permalink raw reply
* Re: [Regression][git head f4b87dee9] ath9k doesn't work correctly after resume from suspend to RAM
From: Rafael J. Wysocki @ 2010-05-22 22:13 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Luis R. Rodriguez, LKML, pm list,
Linus Torvalds, Andrew Morton, Maciej Rutecki
In-Reply-To: <201005222353.26920.rjw@sisk.pl>
On Saturday 22 May 2010, Rafael J. Wysocki wrote:
> Hi,
>
> With current -git on Acer Ferrari One the ath9k driver doesn't seem to work
> after resume from suspend to RAM. NetworkManager seems to think that it works,
> but it doesn't really connect with the AP and doesn't try to obtain an IP
> address.
Sorry, this was incorrect. It actually tries to obtain an IP address, but
fails. Apparently, it can't obtain the address without being reloaded.
Rafael
^ permalink raw reply
* [Regression][git head f4b87dee9] ath9k doesn't work correctly after resume from suspend to RAM
From: Rafael J. Wysocki @ 2010-05-22 21:53 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Luis R. Rodriguez, LKML, pm list,
Linus Torvalds, Andrew Morton, Maciej Rutecki
Hi,
With current -git on Acer Ferrari One the ath9k driver doesn't seem to work
after resume from suspend to RAM. NetworkManager seems to think that it works,
but it doesn't really connect with the AP and doesn't try to obtain an IP
address. Reloading the driver makes it work again.
The 2.6.34 (final) version works flawlessly with STR.
The user space is openSUSE 11.3 Milestone 6, so it may be somewhat unstable
in general, but this particular feature does work with 2.6.34.
Thanks,
Rafael
^ permalink raw reply
* [patch] ath9k: cleanup: remove unneeded null check
From: Dan Carpenter @ 2010-05-22 20:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jouni Malinen, Sujith Manoharan, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, Ming Lei,
linux-wireless, ath9k-devel, kernel-janitors
We dereference "wmi" on the line before and also when we initialize "ah".
This check has always been after a dereference since the first commit a
couple months ago. Looking through the code, it looks like "wmi" can't
actually be null here so I just removed the check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index e23172c..6260faa 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -279,9 +279,6 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
return 0;
- if (!wmi)
- return -EINVAL;
-
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
^ permalink raw reply related
* Re: RTL8185 mlme.c:341 warning and failure still in 2.6.34rc7
From: Rogerio Luz Coelho @ 2010-05-22 19:18 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-wireless, linux-kernel, rjw
In-Reply-To: <20100514133723.GA10351@basil.fritz.box>
2010/5/14 Andi Kleen <andi@firstfloor.org>:
>
> [ccing Rafael because this seems to be a regression. Please add it to your list.]
>
> When I boot my system with a RTL8185 the wireless doesn't come up at boot,
> only when I manually restart it. Instead i get
>
> I reported this a few rc*s back, but haven't heard anything back and the
> problem is still there.
>
> For me it's a serious problem when the wireless does not come up.
>
> This didn't happen in .33.
>
> -Andi
>
> wlan0: authenticate with 00:1f:3f:1d:54:46 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1f:3f:1d:54:46 (try 1)
> wlan0: associate with 00:1f:3f:1d:54:46 (try 2)
> wlan0: associate with 00:1f:3f:1d:54:46 (try 3)
> wlan0: association with 00:1f:3f:1d:54:46 timed out
> ------------[ cut here ]------------
> WARNING: at /home/lsrc/linux-2.6.34-rc7/net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xff/0x117 [cfg80211]()
> Hardware name: ...
> Modules linked in: ...
> Pid: 3344, comm: phy0 Not tainted 2.6.34-rc7 #7
> Call Trace:
> [<ffffffffa0072124>] ? cfg80211_send_assoc_timeout+0xff/0x117 [cfg80211]
> [<ffffffff8103a4f0>] warn_slowpath_common+0x7c/0xa9
> [<ffffffff8103a531>] warn_slowpath_null+0x14/0x16
> [<ffffffffa0072124>] cfg80211_send_assoc_timeout+0xff/0x117 [cfg80211]
> [<ffffffffa00e6393>] ieee80211_assoc_done+0x74/0xa9 [mac80211]
> [<ffffffffa00e85f0>] ieee80211_work_work+0xe4c/0xe8d [mac80211]
> [<ffffffff81033cbe>] ? finish_task_switch+0x42/0xab
> [<ffffffff810535d7>] ? prepare_to_wait+0x6e/0x7a
> [<ffffffff8104f832>] worker_thread+0x192/0x227
> [<ffffffffa00e77a4>] ? ieee80211_work_work+0x0/0xe8d [mac80211]
> [<ffffffff81053342>] ? autoremove_wake_function+0x0/0x3d
> [<ffffffff8104f6a0>] ? worker_thread+0x0/0x227
> [<ffffffff81052efc>] kthread+0x82/0x8a
> [<ffffffff81003954>] kernel_thread_helper+0x4/0x10
> [<ffffffff81052e7a>] ? kthread+0x0/0x8a
> [<ffffffff81003950>] ? kernel_thread_helper+0x0/0x10
> ---[ end trace 4e3067114aa2fd06 ]---
> wlan0: deauthenticating from 00:1f:3f:1d:54:46 by local choice (reason=3)
This is what my rtl8187b says also ... no luck finding the cure, just
look at the thread posted here in the last few months:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/48877/focus=50042
Rogerio
^ permalink raw reply
* carl9170 1.0.9
From: David H. Lynch Jr. @ 2010-05-22 19:13 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201005021452.01101.chunkeey@googlemail.com>
some items I have found while making my changes to the code.
In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF
timer to make sure there is no roll over. According to the docs I have
when TSF_LOW is read, TSF_HI is automatically concurrently copied to a
temp register so that an immediate read of TSF_HI will get the value
that was present when TSF_LO was read.
Presuming the docs are correct - and this feature is common in
multi-word timers you should be able to save some code.
Also with some complex casting or another pointer you can read directly
to your destination and save a memcpy()
I beleive the timer_init() routine in carlfw/src/timer.c can not be
called for more than one timer. Any subsequent call will clear the
interrupt and mode bits for the previous timer.
I have not completely tracked these down, but the new config system
must be missing some dependencies, because I can configure and build
firmware that will not load.
In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with
CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] ath9k: Fix rx of mcast/bcast frames in PS mode with auto sleep
From: Kalle Valo @ 2010-05-22 19:08 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1274229062-10412-1-git-send-email-vasanth@atheros.com>
Vasanthakumar Thiagarajan <vasanth@atheros.com> writes:
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Please describe more, this isn't very informative (if any). Especially
try to answer in the commit log:
o What was the original bug? How and why did it happen?
o How was it visible to the user?
o How does the fix actually fix the issue?
o In what version was the bug introduced? This helps backporters.
Powersave in 802.11 is very fragile and more information there is, the
easier it is to handle the issues.
> +#define ATH9K_CHECK_AUTO_SLEEP(__sc) \
> + (__sc->ps_enabled && \
> + (__sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_AUTOSLEEP))
Like Andrew Morton says: use C instead of CPP. Meaning that this can
be an inline function instead of a macro.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Make sure null func frame is acked before going into PS for ar9003
From: Kalle Valo @ 2010-05-22 18:43 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1274147876-9228-1-git-send-email-vasanth@atheros.com>
Vasanthakumar Thiagarajan <vasanth@atheros.com> writes:
> Add missing code to handle nullfunc frame completion in
> ath_tx_edma_tasklet().
[...]
> + /*
> + * Make sure null func frame is acked before configuring
> + * hw into ps mode.
> + */
> + if (bf->bf_isnullfunc && txok) {
> + if ((sc->ps_flags & PS_ENABLED))
> + ath9k_enable_ps(sc);
> + else
> + sc->ps_flags |= PS_NULLFUNC_COMPLETED;
> + }
Few months ago a similar test was added to mac80211. Why does ath9k
need this also in the driver?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH 1/1] cfg80211: Fix user-space crda query stall
From: Kalle Valo @ 2010-05-22 14:06 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1274438539-11259-2-git-send-email-juuso.oikarinen@nokia.com>
Moi Juuso,
Juuso Oikarinen <juuso.oikarinen@nokia.com> writes:
> The userspace crda utility can fail to respond to kernel requests in (at least)
> two scenarios: it is not runnable for any reason, or it is invoked with a
> country code not in its database.
>
[...]
> + printk(KERN_INFO "cfg80211: Call crda daemon timed out for country: "
> + "%c%c\n", last_request->alpha2[0], last_request->alpha2[1]);
I would prefer to mention in the print that kernel will revert back to
world domain. Nicer for the users.
--
Kalle Valo
^ permalink raw reply
* Problems with compilation "compat-wireless-2.6.34-rc4"
From: Jaroslav Fojtik @ 2010-05-22 13:05 UTC (permalink / raw)
To: linux-wireless
Dears,
It is interesting that compilation fails with misleading error
"cp: cannot create regular file `/lib/udev/rules.d/': Is a directory"
When I create a directory /lib/udev/rules.d/ manually, compilation
runs normally. It would be a good idea to check existency of
/lib/udev/rules.d/ e.g. insige "configure" script.
make -C /usr/src/linux-2.6.32.11 M=/I/USR_SRC/compat-wireless-2.6.34-rc4 modules
make[1]: Entering directory `/I/USR_SRC/linux-2.6.32.11'
Building modules, stage 2.
MODPOST 67 modules
make[1]: Leaving directory `/I/USR_SRC/linux-2.6.32.11'
make -C /usr/src/linux-2.6.32.11 M=/I/USR_SRC/compat-wireless-2.6.34-rc4 modules
depmod will prefer updates/ over kernel/ -- OK!
cp: cannot create regular file `/lib/udev/rules.d/': Is a directory
make: *** [install-scripts] Error 1
make: *** Waiting for unfinished jobs....
Your old wireless subsystem modules were left intact:
/lib/modules/2.6.21.5/kernel/drivers/net/b44.ko
Your old bluetooth subsystem modules were left intact:
make[1]: Entering directory `/I/USR_SRC/linux-2.6.32.11'
Building modules, stage 2.
MODPOST 67 modules
make[1]: Leaving directory `/I/USR_SRC/linux-2.6.32.11'
regards
Jara
^ permalink raw reply
* Problems connectring to an AP with Acer Aspire Revo
From: Christian P. Schmidt @ 2010-05-22 8:29 UTC (permalink / raw)
To: linux-wireless
Hi everyone,
I do have an... interesting... problem with my HTPC, an Intel Atom 230 +
Nvidia ION powered Acer Aspire Revo box.
By default it ships with an Atheros Mini PCI Express card. However,
since my experience with this card isn't the best (and it did not
connect to my access point with wither the Madwifi-NG or the ath9k
driver) I replaced it with an Intel WiFi Link 5100.
However, even with the new card, I could not make any kernel from 2.6.32
to 2.6.34 connect to any of my access points. Those are a Telekom DSL
router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
and even no encryption at all. My laptop with an Intel WiFi Link 5300
has no problems whatsoever in any of the modes.
The card is working for sure, if I put the 5100 in my laptop it works.
Also I feel it's not related to configuration or software - I took my
laptop's WiFi Link 5300 and the laptop HDD, and booted the HTPC up with
those - no connection to the AP possible.
I'm a bit at a loss here as what to try more. My access point doesn't
even see a packet, but there's no rfkill switch anywhere (it's a
stationary machine anyway).
Regards,
Christiam
^ permalink raw reply
* [PATCH 23/27] drivers/net/wireless/prism54: Use memdup_user
From: Julia Lawall @ 2010-05-22 8:25 UTC (permalink / raw)
To: Luis R. Rodriguez, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use memdup_user when user data is immediately copied into the
allocated region.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
position p;
identifier l1,l2;
@@
- to = \(kmalloc@p\|kzalloc@p\)(size,flag);
+ to = memdup_user(from,size);
if (
- to==NULL
+ IS_ERR(to)
|| ...) {
<+... when != goto l1;
- -ENOMEM
+ PTR_ERR(to)
...+>
}
- if (copy_from_user(to, from, size) != 0) {
- <+... when != goto l2;
- -EFAULT
- ...+>
- }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/prism54/isl_ioctl.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c
index 8d1190c..2a62c60 100644
--- a/drivers/net/wireless/prism54/isl_ioctl.c
+++ b/drivers/net/wireless/prism54/isl_ioctl.c
@@ -2751,14 +2751,9 @@ prism54_hostapd(struct net_device *ndev, struct iw_point *p)
p->length > PRISM2_HOSTAPD_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc(p->length, GFP_KERNEL);
- if (param == NULL)
- return -ENOMEM;
-
- if (copy_from_user(param, p->pointer, p->length)) {
- kfree(param);
- return -EFAULT;
- }
+ param = memdup_user(p->pointer, p->length);
+ if (IS_ERR(param))
+ return PTR_ERR(param);
switch (param->cmd) {
case PRISM2_SET_ENCRYPTION:
^ permalink raw reply related
* Re: [PATCH] compat-wireless: add linux-next-pending, crap patch dirs and nagometer
From: Luis R. Rodriguez @ 2010-05-22 1:42 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel, Luis R. Rodriguez
In-Reply-To: <AANLkTinAydFcFSOK7D7T7_gQsghiYwW1bp4DNloyTAcJ@mail.gmail.com>
On Fri, May 21, 2010 at 6:28 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, May 21, 2010 at 5:44 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> Sometimes you have no other option but to carry around patches.
>> This can happen for a variety of reasons. Ultimately testing of code
>> cannot happen on the kernel maintainer's clock but on your own.
>>
>> This expands the idea of the linux-next-cherry-pick patch directory
>> on compat-wireless to also allow for patches to be merged which are
>> posted to some mailing list but pending merge due to some reasons
>> (merge window is a good example). It also adds a crap patch directory
>> for those really nasty situations you can run into where you have
>> no other option but to give someone a release with some delta even
>> if the patch is not yet posted anywhere.
>>
>> The focus should always be upstream though so to avoid these
>> situations we will also provide code metrics to indicate to
>> the package maintainer how much code came from each directory,
>> including the backport code to support older kernel releases.
>>
>> Maybe we should add the code-metrics.txt file as a print out
>> on the compat module load :)
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> So this is what I get with what I just merged and using -p -c
>
> compat-wireless code metrics
>
> 497275 - Total upstream code being pulled
> 1393 - backport code changes
> 1163 - backport code additions
> 230 - backport code deletions
> 0.28 - % of code consists of backport work
I just realized this % is wrong as it only accounts for the *.patch
files for the backport. We'll have to exlude compat/ dir for the code
calculations and add the code there for the backport calculation.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: add linux-next-pending, crap patch dirs and nagometer
From: Luis R. Rodriguez @ 2010-05-22 1:28 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel, Luis R. Rodriguez
In-Reply-To: <1274489059-1019-1-git-send-email-lrodriguez@atheros.com>
On Fri, May 21, 2010 at 5:44 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Sometimes you have no other option but to carry around patches.
> This can happen for a variety of reasons. Ultimately testing of code
> cannot happen on the kernel maintainer's clock but on your own.
>
> This expands the idea of the linux-next-cherry-pick patch directory
> on compat-wireless to also allow for patches to be merged which are
> posted to some mailing list but pending merge due to some reasons
> (merge window is a good example). It also adds a crap patch directory
> for those really nasty situations you can run into where you have
> no other option but to give someone a release with some delta even
> if the patch is not yet posted anywhere.
>
> The focus should always be upstream though so to avoid these
> situations we will also provide code metrics to indicate to
> the package maintainer how much code came from each directory,
> including the backport code to support older kernel releases.
>
> Maybe we should add the code-metrics.txt file as a print out
> on the compat module load :)
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
So this is what I get with what I just merged and using -p -c
compat-wireless code metrics
497275 - Total upstream code being pulled
1393 - backport code changes
1163 - backport code additions
230 - backport code deletions
0.28 - % of code consists of backport work
6856 - Code changes posted but not yet merged
4412 - Code additions posted but not yet merged
2444 - Code deletions posted but not yet merged
1.38 - % of code not yet merged
1225 - Crap changes not yet posted
1181 - Crap additions not yet merged
44 - Crap deletions not yet posted
0.25 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100518
compat-wireless release: compat-wireless-20100521-3-g0935025
The 1.38% is code Atheros has posted but is not yet merged. By default
this code is not merged into the bleeding edge compat-wireless
releases.
Usage: ./scripts/admin-update.sh [ refresh] [ --help | -h | -n | -p | -c ]
refresh - will update your all your patch offsets using quilt
-n - apply the patches linux-next-cherry-picks directory
-p - apply the patches on the linux-next-pending directory
-c - apply the patches on the crap directory
In case it helps with the delay of the merge window feel free to send
me patches which are pending and you do think are important for
existing testing with the bleeding edge linux-next codebase. I am in
hopes as a side effect maybe this could help John and/or Marcel
*after* the merge window when they have to merge stuff for the next
release cycle.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: add linux-next-pending, crap patch dirs and nagometer
From: Luis R. Rodriguez @ 2010-05-22 1:19 UTC (permalink / raw)
To: Pavel Roskin
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1274490936.3439.14.camel@ct>
On Fri, May 21, 2010 at 06:15:36PM -0700, Pavel Roskin wrote:
> On Fri, 2010-05-21 at 20:44 -0400, Luis R. Rodriguez wrote:
> > Sometimes you have no other option but to carry around patches.
> > This can happen for a variety of reasons. Ultimately testing of code
> > cannot happen on the kernel maintainer's clock but on your own.
> >
> > This expands the idea of the linux-next-cherry-pick patch directory
> > on compat-wireless to also allow for patches to be merged which are
> > posted to some mailing list but pending merge due to some reasons
> > (merge window is a good example). It also adds a crap patch directory
> > for those really nasty situations you can run into where you have
> > no other option but to give someone a release with some delta even
> > if the patch is not yet posted anywhere.
>
> Please replace "crap" with some more descriptive name, like
> "unpublished". It's better to be friendly to users and express
> frustration in a different way.
I'm using crap to keep focus on not-yet-merged-or-posted code, I refuse
to be friendly to that type of code. I want the users to be frustrated
about that code.
> > + printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
> > + printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
> > + printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
>
> You want "not yet posted" in all cases.
OK thanks, I'll fix.
> "Crap deletions" may be offensive for Linux contributors whose code is
> being deleted. Besides, if patches are not posted, somebody still spent
> time on making them. Let's not discourage those who care.
Sure.
Luis
^ permalink raw reply
* AR9170 FW
From: David H. Lynch Jr. @ 2010-05-22 1:17 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
I have been playing with the assorted timers in the ar9170.
My preliminary observations seem to be indicating that
AR9170_TIMER_REG_TIMER0 might actually be running at 40mhz/25ns,
But that all the other timers seem to be running far slower - i.e.
maybe they are cascaded of the overflow on timer0.
I have specifically looked at timer1-4 and tic_timer and clock_low
and they all seem to be running very slow.
The docs that I have imply but do not state that all these clocks
are directly off the 25ns/40mhz superH clock.
Have you had any experience with the clocks and their rates ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] compat-wireless: add linux-next-pending, crap patch dirs and nagometer
From: Pavel Roskin @ 2010-05-22 1:15 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <1274489059-1019-1-git-send-email-lrodriguez@atheros.com>
On Fri, 2010-05-21 at 20:44 -0400, Luis R. Rodriguez wrote:
> Sometimes you have no other option but to carry around patches.
> This can happen for a variety of reasons. Ultimately testing of code
> cannot happen on the kernel maintainer's clock but on your own.
>
> This expands the idea of the linux-next-cherry-pick patch directory
> on compat-wireless to also allow for patches to be merged which are
> posted to some mailing list but pending merge due to some reasons
> (merge window is a good example). It also adds a crap patch directory
> for those really nasty situations you can run into where you have
> no other option but to give someone a release with some delta even
> if the patch is not yet posted anywhere.
Please replace "crap" with some more descriptive name, like
"unpublished". It's better to be friendly to users and express
frustration in a different way.
> + printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
> + printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
> + printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
You want "not yet posted" in all cases.
"Crap deletions" may be offensive for Linux contributors whose code is
being deleted. Besides, if patches are not posted, somebody still spent
time on making them. Let's not discourage those who care.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: carl9170 1.0.6 carl9170_tx_superdesc
From: David H. Lynch Jr. @ 2010-05-22 1:09 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
In-Reply-To: <201005220055.02528.chunkeey@googlemail.com>
On 05/21/2010 06:55 PM, Christian Lamparter wrote:
> On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
>
>> I need to track a new value for each tx frame only in the firmware.
>> It appears I should be adding it to carl9170_tx_superdesc.
>> But that structure seems to be used on both the Linux and firmware side,
>> and I have not been able to successfully add to it without breaking
>> something elsewhere either in the firmware or Linux driver or between them.
>>
> there are two superdesc structures:
> carl9170_tx_superdesc and _carl9170_tx_superdesc.
>
> This is due to the bit-field packing bug which is present
> in all GCC version prior to 4.4.
>
> Now, for the firmware we have a special toolchain and
> a BUILD_BUG check, so no problem is there.
>
> But kernel driver& userspace tools might be compiled by
> an older version.
>
> Therefore, if you want to introduce new fields, you have
> to update both structures accordingly.
>
> (And of course, always check that you're using your
> custom firmware and driver.)
>
For the moment I have found another way of resolving the issue.
I am not concerned that there are two versions of the structures
under Linux.
My problem was that it appears to add a field to the firmware I
must also add it to linux.
During a TX I am looking to track something in firmware, and then
return it to Linux.
If I have this correct the carl9170_tx_superframe is passed from
Linux to the firmware and the carl9170_tx_status is passed back to Linux.
I do not need the extra field in carl9170_tx_superframe in Linux. i
do need it at several different points prior to having a
carl9170_tx_status record, in the firmware. And then I need to return
the value to Linux in the carl9170_tx_status field.
I am gathering that whether I need or not that
carl9170_tx_superframe must match perfectly between Linux and the
firmware. And there is no other per packet data being managed in the
firmware.
My second problem is that even after adding it to both sides and
adjusting for all the alignment and other issues, I end up with
something that does not work.
I am being careful to keep the driver and firmware aligned. I
grasp that is an issue.
>
>> Alternately I can create a private array to hold my data, but then I
>> need to be able to find items in it using a carl9170_tx_superframe
>> pointer. I am gathering that the cookie and queue number constitute a
>> unique identifier, but that seems like alot of work to avoid adding a
>> u16 to carl9170_tx_superdesc.
>>
> It might not be visible at first glance, but carl9170_tx_superframe
> has two distinct header descriptors.
> * ar9170_tx_hwdesc
> * carl9170_tx_superdesc
>
> variables of those headers can not be mixed. This is because the
> layout of ar9170_tx_hwdesc is dictated by the hardware design.
>
> Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
> whereas the "cookie" is intended to be used by the firmware code.
> (In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV)
>
>
>> Any other ideas about tracking a u16 value for each tx frame only on
>> the firmware side without substantial complexity ?
>>
> Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
> from your employer cover this subject in great detail since this is a
> well-known limitation.
>
Pardon my sensitivity, but I am a consultant. I have clients not
employers.
The parts of the AR9170 spec I have read do not address this, but I
have not read everything thoroughly.
My project deals almost exclusively with timing. And I am trying
not to touch things I do not need to.
> What you could try - on the other hand - u32.
> even if you don't need the extra 2 bytes that come with this
> bigger storage class.
>
I may need to do that anyway. 25ns * 65K is 1.6ms before
overflow, that is almost too short.
>
> BTW:
> Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
> But let me run some experiments. Just to be on the safe side.
>
Thanks.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* [PATCH] compat-wireless: add linux-next-pending, crap patch dirs and nagometer
From: Luis R. Rodriguez @ 2010-05-22 0:44 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel, Luis R. Rodriguez
Sometimes you have no other option but to carry around patches.
This can happen for a variety of reasons. Ultimately testing of code
cannot happen on the kernel maintainer's clock but on your own.
This expands the idea of the linux-next-cherry-pick patch directory
on compat-wireless to also allow for patches to be merged which are
posted to some mailing list but pending merge due to some reasons
(merge window is a good example). It also adds a crap patch directory
for those really nasty situations you can run into where you have
no other option but to give someone a release with some delta even
if the patch is not yet posted anywhere.
The focus should always be upstream though so to avoid these
situations we will also provide code metrics to indicate to
the package maintainer how much code came from each directory,
including the backport code to support older kernel releases.
Maybe we should add the code-metrics.txt file as a print out
on the compat module load :)
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
crap/README | 17 ++++++
linux-next-pending/README | 17 ++++++
scripts/admin-update.sh | 130 ++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 156 insertions(+), 8 deletions(-)
create mode 100644 crap/README
create mode 100644 linux-next-pending/README
diff --git a/crap/README b/crap/README
new file mode 100644
index 0000000..c1b512e
--- /dev/null
+++ b/crap/README
@@ -0,0 +1,17 @@
+
+compat-wireless crap patches
+============================
+
+If you are including patches into this directory you
+must be fixing some critical bug for a customer which needs
+immediate release or immediate testing.
+
+Alternatively you would use this to apply some sort of
+crap code you are maintaining.
+
+You must have a really good reason to be adding files
+in this directory. If possible you should explain your
+reasoning of why the patch is getting included here and
+not upstream and why it hasn't even yet been posted.
+
+You should avoid these patches at all costs.
diff --git a/linux-next-pending/README b/linux-next-pending/README
new file mode 100644
index 0000000..cc531b2
--- /dev/null
+++ b/linux-next-pending/README
@@ -0,0 +1,17 @@
+
+compat-wireless linux-next-pending patches
+==========================================
+
+You must have a really good reason to be adding files
+in this directory. The requirement is your patches must have
+been posted to a public mailing list for the subsystem you are
+working on. Each patch you add here must have a really good
+explanation on the top of the file which clarifies why the
+patch has not yet been merged.
+
+We try to avoid having patch files because but we understand
+if you might because you need to test code posted but not yet
+merged into linux-next or a stable kernel release. This can happen
+often during the merge window, when the maintainers are unavailable,
+on vacation, suck at what they do, or for any other uncontrollable
+reasons.
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index 78a8c63..98c21a9 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -1,6 +1,6 @@
#!/bin/bash
#
-# Copyright 2007, 2008 Luis R. Rodriguez <mcgrof@winlab.rutgers.edu>
+# Copyright 2007, 2008, 2010 Luis R. Rodriguez <mcgrof@winlab.rutgers.edu>
#
# Use this to update compat-wireless-2.6 to the latest
# wireless-testing.git tree you have.
@@ -45,6 +45,112 @@ CYAN="\033[36m"
UNDERLINE="\033[02m"
NET_DIRS="wireless mac80211 rfkill"
+CODE_METRICS=code-metrics.txt
+
+usage() {
+ printf "Usage: $0 [ refresh] [ --help | -h | -n | -p | -c ]\n"
+
+ printf "${GREEN}%10s${NORMAL} - will update your all your patch offsets using quilt\n" "refresh"
+ printf "${GREEN}%10s${NORMAL} - apply the patches linux-next-cherry-picks directory\n" "-n"
+ printf "${GREEN}%10s${NORMAL} - apply the patches on the linux-next-pending directory\n" "-p"
+ printf "${GREEN}%10s${NORMAL} - apply the patches on the crap directory\n" "-c"
+}
+
+brag_backport() {
+ printf "${GREEN}%10s${NORMAL} - backport code changes\n" $2
+ printf "${GREEN}%10s${NORMAL} - backport code additions\n" $3
+ printf "${GREEN}%10s${NORMAL} - backport code deletions\n" $4
+ printf "${RED}%10s${NORMAL} - %% of code consists of backport work\n" $(perl -e 'printf("%.2f", 100 * '$2' / '$1');')
+}
+
+nag_next_cherry_pick() {
+ printf "${YELLOW}%10s${NORMAL} - Code changes brought in from linux-next\n" $2
+ printf "${YELLOW}%10s${NORMAL} - Code additions brought in from linux-next\n" $3
+ printf "${YELLOW}%10s${NORMAL} - Code deletions brought in from linux-next\n" $4
+ printf "${REG}%10s${NORMAL} - %% of code being cherry picked from linux-next\n" $(perl -e 'printf("%.2f", 100 * '$2' / '$1');')
+}
+
+nag_pending() {
+ printf "${YELLOW}%10s${NORMAL} - Code changes posted but not yet merged\n" $2
+ printf "${YELLOW}%10s${NORMAL} - Code additions posted but not yet merged\n" $3
+ printf "${YELLOW}%10s${NORMAL} - Code deletions posted but not yet merged\n" $4
+ printf "${REG}%10s${NORMAL} - %% of code not yet merged\n" $(perl -e 'printf("%.2f", 100 * '$2' / '$1');')
+}
+
+nag_crap() {
+ printf "${RED}%10s${NORMAL} - Crap changes not yet posted\n" $2
+ printf "${RED}%10s${NORMAL} - Crap additions not yet merged\n" $3
+ printf "${RED}%10s${NORMAL} - Crap deletions not yet posted\n" $4
+ printf "${REG}%10s${NORMAL} - %% of crap code\n" $(perl -e 'printf("%.2f", 100 * '$2' / '$1');')
+}
+
+nagometer() {
+ CHANGES=0
+
+ ORIG_CODE=$2
+ ADD=$(grep -c ^+ $1/*.patch| awk -F":" 'BEGIN {sum=0} {sum += $2} END { print sum}')
+ DEL=$(grep -c ^- $1/*.patch| awk -F":" 'BEGIN {sum=0} {sum += $2} END { print sum}')
+ # Total code is irrelevant unless you take into account each part,
+ # easier to just compare against the original code.
+ # let TOTAL_CODE=$ORIG_CODE+$ADD-$DEL
+
+ let CHANGES=$ADD+$DEL
+
+ case $1 in
+ "patches")
+ brag_backport $ORIG_CODE $CHANGES $ADD $DEL
+ ;;
+ "linux-next-cherry-picks")
+ nag_next_cherry_pick $ORIG_CODE $CHANGES $ADD $DEL
+ ;;
+ "linux-next-pending")
+ nag_pending $ORIG_CODE $CHANGES $ADD $DEL
+ ;;
+ "crap")
+ nag_crap $ORIG_CODE $CHANGES $ADD $DEL
+ ;;
+ *)
+ ;;
+ esac
+
+}
+
+EXTRA_PATCHES="patches"
+REFRESH="n"
+if [ $# -ge 1 ]; then
+ if [ $# -gt 4 ]; then
+ usage $0
+ exit
+ fi
+ if [[ $1 = "-h" || $1 = "--help" ]]; then
+ usage $0
+ exit
+ fi
+ while [ $# -ne 0 ]; do
+ if [[ "$1" = "-n" ]]; then
+ EXTRA_PATCHES="${EXTRA_PATCHES} linux-next-cherry-picks"
+ shift; continue;
+ fi
+ if [[ "$1" = "-p" ]]; then
+ EXTRA_PATCHES="${EXTRA_PATCHES} linux-next-pending"
+ shift; continue;
+ fi
+ if [[ "$1" = "-c" ]]; then
+ EXTRA_PATCHES="${EXTRA_PATCHES} crap"
+ shift; continue;
+ fi
+ if [[ "$1" = "refresh" ]]; then
+ REFRESH="y"
+ shift; continue;
+ fi
+
+ echo "Unexpected argument passed: $1"
+ usage $0
+ exit
+ done
+
+fi
+
# User exported this variable
if [ -z $GIT_TREE ]; then
GIT_TREE="/home/$USER/linux-next/"
@@ -274,12 +380,17 @@ patchRefresh() {
rm -rf patches.orig .pc $1/series
}
-if [[ "$1" = "refresh" ]]; then
- patchRefresh patches
- patchRefresh linux-next-cherry-picks
+if [[ "$REFRESH" = "y" ]]; then
+ for dir in $EXTRA_PATCHES; do
+ patchRefresh $dir
+ done
fi
-for dir in patches linux-next-cherry-picks; do
+ORIG_CODE=$(find ./ -type f -name \*.[ch]| xargs wc -l | tail -1 | awk '{print $1}')
+printf "\n${CYAN}compat-wireless code metrics${NORMAL}\n\n" > $CODE_METRICS
+printf "${PURPLE}%10s${NORMAL} - Total upstream code being pulled\n" $ORIG_CODE >> $CODE_METRICS
+
+for dir in $EXTRA_PATCHES; do
FOUND=$(find $dir/ -name \*.patch | wc -l)
if [ $FOUND -eq 0 ]; then
continue
@@ -293,6 +404,7 @@ for dir in patches linux-next-cherry-picks; do
exit $RET
fi
done
+ nagometer $dir $ORIG_CODE >> $CODE_METRICS
done
DIR="$PWD"
@@ -342,9 +454,11 @@ if [ -d ./.git ]; then
esac
cd $DIR
- echo -e "Base tree: ${GREEN}$(cat compat_base_tree)${NORMAL}"
- echo -e "Base tree version: ${PURPLE}$(cat compat_base_tree_version)${NORMAL}"
- echo -e "compat-wireless release: ${YELLOW}$(cat compat_version)${NORMAL}"
+ echo -e "\nBase tree: ${GREEN}$(cat compat_base_tree)${NORMAL}" >> $CODE_METRICS
+ echo -e "Base tree version: ${PURPLE}$(cat compat_base_tree_version)${NORMAL}" >> $CODE_METRICS
+ echo -e "compat-wireless release: ${YELLOW}$(cat compat_version)${NORMAL}" >> $CODE_METRICS
+
+ cat $CODE_METRICS
fi
./scripts/driver-select restore
--
1.6.3.3
^ permalink raw reply related
* Re: carl9170 1.0.6 carl9170_tx_superdesc
From: Christian Lamparter @ 2010-05-21 22:55 UTC (permalink / raw)
To: dhlii; +Cc: linux-wireless
In-Reply-To: <4BF6FC91.9060109@dlasys.net>
On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
> I need to track a new value for each tx frame only in the firmware.
> It appears I should be adding it to carl9170_tx_superdesc.
> But that structure seems to be used on both the Linux and firmware side,
> and I have not been able to successfully add to it without breaking
> something elsewhere either in the firmware or Linux driver or between them.
there are two superdesc structures:
carl9170_tx_superdesc and _carl9170_tx_superdesc.
This is due to the bit-field packing bug which is present
in all GCC version prior to 4.4.
Now, for the firmware we have a special toolchain and
a BUILD_BUG check, so no problem is there.
But kernel driver & userspace tools might be compiled by
an older version.
Therefore, if you want to introduce new fields, you have
to update both structures accordingly.
(And of course, always check that you're using your
custom firmware and driver.)
> Alternately I can create a private array to hold my data, but then I
> need to be able to find items in it using a carl9170_tx_superframe
> pointer. I am gathering that the cookie and queue number constitute a
> unique identifier, but that seems like alot of work to avoid adding a
> u16 to carl9170_tx_superdesc.
It might not be visible at first glance, but carl9170_tx_superframe
has two distinct header descriptors.
* ar9170_tx_hwdesc
* carl9170_tx_superdesc
variables of those headers can not be mixed. This is because the
layout of ar9170_tx_hwdesc is dictated by the hardware design.
Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
whereas the "cookie" is intended to be used by the firmware code.
(In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV)
> Any other ideas about tracking a u16 value for each tx frame only on
> the firmware side without substantial complexity ?
Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
from your employer cover this subject in great detail since this is a
well-known limitation.
What you could try - on the other hand - u32.
even if you don't need the extra 2 bytes that come with this
bigger storage class.
BTW:
Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
But let me run some experiments. Just to be on the safe side.
Regards,
Chr
^ permalink raw reply
* carl9170 1.0.6 carl9170_tx_superdesc
From: David H. Lynch Jr. @ 2010-05-21 21:35 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201005021452.01101.chunkeey@googlemail.com>
I need to track a new value for each tx frame only in the firmware.
It appears I should be adding it to carl9170_tx_superdesc. But that
structure seems to be used on both the Linux and firmware side, and I
have not been able to successfully add to it without breaking something
elsewhere either in the firmware or Linux driver or between them.
Alternately I can create a private array to hold my data, but then I
need to be able to find items in it using a carl9170_tx_superframe
pointer. I am gathering that the cookie and queue number constitute a
unique identifier, but that seems like alot of work to avoid adding a
u16 to carl9170_tx_superdesc.
Any other ideas about tracking a u16 value for each tx frame only on
the firmware side without substantial complexity ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
^ permalink raw reply
* Re: Iwlwifi and LEDS?
From: Gregy @ 2010-05-21 20:49 UTC (permalink / raw)
To: Abhijeet Kolekar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274465242.12391.0.camel@abhi-desktop>
On 21 May 2010 20:07, Abhijeet Kolekar <abhijeet.kolekar@intel.com> wrote:
> On Fri, 2010-05-21 at 02:11 -0700, Gregy wrote:
>> Hello, I noticed you removed support for led subsystem from iwlwifi. I
>> have used it to control wifi led from userspace. Is it still possible
>> somehow?
>>
> There is module parameter for iwlcore called 'led_mode'.
Yes but I cannot control the led through it. I can only set one of two
modes. Before I could use it as "connected to internet" indicator or
I could turn it off completely.
Gregy
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-21 20:28 UTC (permalink / raw)
To: Felix Fietkau
Cc: Bruno Randolf, David Quan, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com,
Luis Rodriguez, Sam Ng
In-Reply-To: <4BF6DAAE.6090903@openwrt.org>
On Fri, May 21, 2010 at 12:10 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-05-21 7:11 PM, Luis R. Rodriguez wrote:
>> On Thu, May 20, 2010 at 06:59:33PM -0700, Bruno Randolf wrote:
>>> so from my point of view this is not very different from what we can support
>>> with the API i suggested. for RX it seems to be 100% equivalent.
>>
>> Well I agree, the API *supports it* but I want *clean, clear and consistant
>> API*. And it just seems cleaner to separate the two.
>>
>>> the main difference as i see it is that with 802.11n you transmit on more than
>>> one antenna, while with 'legacy' we can only transmit on one antenna at a
>>> time.
>>
>> True, but note how the fact that you transmit over two antennas actually
>> has regulatory implications. Now, ath9k handles this within ath9k_hw already
>> but this itself seems like a worthy reason for this API to be separated.
>> While I think it is great for ath9k_hw to do this, wouldn't it be nice
>> if we can eventually instead expose the gain by using different chains
>> at the same time and do the regulatory calculation for all devices within
>> cfg80211?
>>
>>> actually i have to admit that on legacy "antenna set tx 3 (b11)" (select two
>>> antennas for transmit) does not make much sense. i have defined it before as
>>> "use diversity" but what about a different definition: like "bitmap of
>>> antennas/chains to TRANSMIT".
>>
>> Right, and while that *works*, I think it would be clearer to just use a
>> clear "diveristy" knob.
> Splitting it by mode of operation (11n vs legacy) does not work, because
> in AP mode you're doing both at the same time and there is an overlap in
> both settings.
Ah, hm, good point.
> I think that Bruno's suggestion of keeping them as one setting makes
> sense. About the regulatory concerns: where in the code does the
> chainmask currently affect the regulatory constraints?
I'm not sure, this was based on a quick review with David, I'll have
to review and poke at it but IIRC this was related to the chainmask
gains and I think we may get that from the EEPROM.
>>> so for 802.11n that would allow you to select multiple trasmit chains.
>>
>> Instead of leaving the API to be interpreted by the mode of operation
>> I think it would be much cleaner to just make your desires clearer and
>> have the API define it well, and let the driver reject/accept it.
>>
>>> on legacy you are only allowed to select one antenna
>>> in the bitmap. if it is set to "0" (or a separate flag) this could enable
>>> "follow RX antenna diversity" on legacy.
>>
>> Sure that is one way, but it seems cleaner and easier for legacy purposes
>> to just define an API that only fits legacy.
>>
>>> most of the other things you mention (need a reset/reassociate, regulatory
>>> concerns...) are driver implementation issues, which can be dealt with in the
>>> driver.
>>
>> Well so some of these things *could* be handled in mac80211 as well. For
>> example, we may want to just dissociate upon a tx/rx chain setting change
>> for all devices, but not for legacy. The regulatory stuff is another thing
>> which could eventually be made more generic accross the board.
>>
>> Additionally, suppose you write an iw-tweak-gui thingy, and you want to
>> provide expose tx/rx chainmask settings. Since some cards do not support
>> some chainmask settings we may want to allow for a query of unsupported
>> chainmasks and that way the GUI application could just grey-out the
>> unsupported chainmask settings instead of letting the user figure out
>> by trial and error that they are indeed not supported.
> The API should just provide a bitmask of possible chains/antennas to
> user space, which will be used as a mask for any values that the user
> space sets. That's easy for a GUI utility to process
The bitmask of possible chains/antennas makes more sense, we could
just add it to the general phy info request, it would just be a matter
of piggy backing a new attribute back.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox