* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Holger Schurig @ 2010-12-16 13:17 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTimWaopJnU5T6OZvqm4YSvSZeXs0dh7oMfU+ERJ8@mail.gmail.com>
> You use libertas_cs on an embedded device with compat-wireless, OK,
> thanks for the feedback. If you can help with patches when PCMCIA crap
> is advanced that would help too.
The problem is that I work on this in an on-off way. If a customer
notices some heavy bug with the current kernel on our devices, I'll do
the upgrade dance. As long as everything works, I'm lazy --- or busy
doing other things.
And I'm looking for a new job anyway :-)
Greetings,
Holger
--
Homepage: http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 04/17] rt2x00: fix hang when unplugging USB device in use
From: Walter Goldens @ 2010-12-16 13:04 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: js, linux-wireless, users
In-Reply-To: <599567.31181.qm@web56805.mail.re3.yahoo.com>
Even with the latest patches, rmmod'ing the rt2xXXX stuff causes a complete system freeze. Unless I bring down the interface first via 'ifconfig wlanX down', unloading the driver while operational equates OS hang and hard reset.
Walter.
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Johannes Berg @ 2010-12-16 12:53 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <AANLkTimZdxQNk2hr-ekGPAWJB5YTZBqxdppOAjdbrb1i@mail.gmail.com>
On Thu, 2010-12-16 at 04:46 -0800, Paul Stewart wrote:
> >> I haven't dug deep into it, but I can guess at a reason -- ath9k stores idle
> >> state in two different places -- one is meant to mirror mac80211's state,
> >> and the other one is internal, periodically computed from the state of all
> >> wiphys. The ath9k version of the fix modified the
> >> internal state without the mac80211 mirror.
> >
> > But at this point mac80211 doesn't care what the state is any more.
>
> Huh? I'm not sure I understand this statement. If mac80211 suspends
> and resumes with open_count > 1 (e.g, with an associated STA), I argue
> mac80211 _does_ care what the state is. In fact, although we called
> stop() on the driver, there's every expectation that on resume any state
> stored on suspend is recovered. Are you not assuming this?
Not really -- the driver may throw away all internal state, mac80211
will (attempt to) restore it all through drv_config() with changed = ~0.
Evidently ath9k has some magic that makes this fail?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2010-12-16 12:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <1292502934.3612.15.camel@jlt3.sipsolutions.net>
On Thu, Dec 16, 2010 at 4:35 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-12-16 at 04:27 -0800, Paul Stewart wrote:
>
>> > How so? After resume, mac80211 will invoke start(), add interfaces and
>> > stations back, and then invoke drv_config with all flags in "changed"
>> > set. Therefore, at this point, the device should be reset. Where's this
>> > not working?
>>
>> I haven't dug deep into it, but I can guess at a reason -- ath9k stores idle
>> state in two different places -- one is meant to mirror mac80211's state,
>> and the other one is internal, periodically computed from the state of all
>> wiphys. The ath9k version of the fix modified the
>> internal state without the mac80211 mirror.
>
> But at this point mac80211 doesn't care what the state is any more.
Huh? I'm not sure I understand this statement. If mac80211 suspends
and resumes with open_count > 1 (e.g, with an associated STA), I argue
mac80211 _does_ care what the state is. In fact, although we called
stop() on the driver, there's every expectation that on resume any state
stored on suspend is recovered. Are you not assuming this?
>> The ath9k config() routine
>> probably does nothing when called with "all changed" on resume because
>> in fact, if we suspend and resume when non-idle, nothing _has_ changed
>> from that perspective.
>
> Hmm, I still don't get it. The "idle just changed" flag is set -- and
> idle will actually be what it was at suspend time. If ath9k was simply
> setting its own idle state on stop(), and returning to what mac80211
> says when it first configures the device after start(), what would the
> problem be?
I don't have the code in front of me (in transit at the moment), but I'm
pretty sure the config routine in ath9k only checks to see whether the
idle state mac80211 passes in is different from the previous passed-in
value. It doesn't care what its internal state is because it believed it was
computed from mac80211 passed-in values. It may be possible to
rework that code.
>> I fear that unless ath9k gets changed more
>> substantially, it really does need to be informed of IDLE changes.
>
> I'd rather have ath9k change more than try to enforce this perfectly in
> mac80211. I still think that's brittle, and every little bug in a corner
> case will cause severe problems since it causes suspend/resume to fail.
>
> johannes
>
>
^ permalink raw reply
* Re: [RFC] ath9k_htc : Update txrate status to mac80211
From: Mohammed Shafi @ 2010-12-16 12:45 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <19722.1212.579544.451006@gargle.gargle.HOWL>
On Thursday 16 December 2010 05:53 PM, Sujith wrote:
> Mohammed Shafi wrote:
>
>> This patch just takes care for displaying the txrate and appropriately
>> sets mac80211 rate control flags,but completely ignores long retries.I
>> had tested it , except retries the MCS index , txrate in userspace
>> matches with the txrate reported in debug statistics.
>> Is there chance of any possible fix for this ?
>>
> Not really, unless the FW is changed so that it can report TX status.
>
Ok Sujith.
thanks,
shafi
> Sujith
> .
>
>
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Johannes Berg @ 2010-12-16 12:35 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <AANLkTiktMJvk55fz-Ww_nUtHcTS1mNVSR-hhkfbux+j_@mail.gmail.com>
On Thu, 2010-12-16 at 04:27 -0800, Paul Stewart wrote:
> > How so? After resume, mac80211 will invoke start(), add interfaces and
> > stations back, and then invoke drv_config with all flags in "changed"
> > set. Therefore, at this point, the device should be reset. Where's this
> > not working?
>
> I haven't dug deep into it, but I can guess at a reason -- ath9k stores idle
> state in two different places -- one is meant to mirror mac80211's state,
> and the other one is internal, periodically computed from the state of all
> wiphys. The ath9k version of the fix modified the
> internal state without the mac80211 mirror.
But at this point mac80211 doesn't care what the state is any more.
> The ath9k config() routine
> probably does nothing when called with "all changed" on resume because
> in fact, if we suspend and resume when non-idle, nothing _has_ changed
> from that perspective.
Hmm, I still don't get it. The "idle just changed" flag is set -- and
idle will actually be what it was at suspend time. If ath9k was simply
setting its own idle state on stop(), and returning to what mac80211
says when it first configures the device after start(), what would the
problem be?
> I fear that unless ath9k gets changed more
> substantially, it really does need to be informed of IDLE changes.
I'd rather have ath9k change more than try to enforce this perfectly in
mac80211. I still think that's brittle, and every little bug in a corner
case will cause severe problems since it causes suspend/resume to fail.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2010-12-16 12:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <1292501047.3612.9.camel@jlt3.sipsolutions.net>
On Thu, Dec 16, 2010 at 4:04 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-12-16 at 03:51 -0800, Paul Stewart wrote:
>> Fixing the problem in ath9k
>> alone causes a separate problem. If you stop the driver from mac80211's
>> pm.c, ath9k would set the device ps_idle, when mac80211 does not
>> consider the device to to be idle. Thus, when we resume from suspend,
>> the device stays quiescent (mac80211 has no reason to believe it needs
>> to do anything special to be able to tx, receive beacons, etc.)
>
> How so? After resume, mac80211 will invoke start(), add interfaces and
> stations back, and then invoke drv_config with all flags in "changed"
> set. Therefore, at this point, the device should be reset. Where's this
> not working?
I haven't dug deep into it, but I can guess at a reason -- ath9k stores idle
state in two different places -- one is meant to mirror mac80211's state,
and the other one is internal, periodically computed from the state of all
wiphys. The ath9k version of the fix modified the
internal state without the mac80211 mirror. The ath9k config() routine
probably does nothing when called with "all changed" on resume because
in fact, if we suspend and resume when non-idle, nothing _has_ changed
from that perspective. I fear that unless ath9k gets changed more
substantially, it really does need to be informed of IDLE changes.
> I think the problem might be that ath9k is expecting mac80211 to
> perfectly nest calls to idle/non-idle, even across suspend/resume and
> device shutdown. I don't think that's feasible at all.
--
Paul
^ permalink raw reply
* Re: [RFC] ath9k_htc : Update txrate status to mac80211
From: Sujith @ 2010-12-16 12:23 UTC (permalink / raw)
To: Mohammed Shafi
Cc: Sujith, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <4D0A012E.3090408@atheros.com>
Mohammed Shafi wrote:
> This patch just takes care for displaying the txrate and appropriately
> sets mac80211 rate control flags,but completely ignores long retries.I
> had tested it , except retries the MCS index , txrate in userspace
> matches with the txrate reported in debug statistics.
> Is there chance of any possible fix for this ?
Not really, unless the FW is changed so that it can report TX status.
Sujith
^ permalink raw reply
* Re: BUG: while bridging Ethernet and wireless device:
From: Johannes Berg @ 2010-12-16 12:16 UTC (permalink / raw)
To: Tomas Winkler; +Cc: linux-netdev, linux-wireless
In-Reply-To: <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i@mail.gmail.com>
On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
> Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
> Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
So as I said to Tomas in private before -- it kinda looks like something
here is not handling paged SKBs correctly? But I would imaging that
causing more issues, unless there was a bug here that made bridging
require more data in the skb header than we put in there right now -- it
can end up being empty I believe.
Thing is, I looked at the code and it seemed fine.
johannes
^ permalink raw reply
* BUG: while bridging Ethernet and wireless device:
From: Tomas Winkler @ 2010-12-16 12:11 UTC (permalink / raw)
To: linux-netdev, linux-wireless
Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Thanks
Tomas
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here
]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at
include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file:
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>]
EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at
br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX:
f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI:
f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800
f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440
f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c
00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ?
sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ?
enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ?
sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ?
select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ?
nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ?
br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ?
br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ?
br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ?
__netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ?
skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ?
netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ?
ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ?
ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ?
__netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ?
sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ?
default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ?
ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ?
ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ?
iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ?
iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ?
iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ?
iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ?
__rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ?
tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ?
__do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ?
nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ?
__do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ?
irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ?
common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ?
intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: ff ff ff be ea
ff ff ff 8b 82 b0 00 00 00 e9 fb f5 ff ff 89 c8 e8 4c dc ff ff 85 c0
89 c6 0f 84 9b f5 ff ff 66 90 e9 be fe ff ff <0f> 0b eb fe c7 47 20 01
00 00 00 8b 43 04 89 c2 81 e2 ff ff ff
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: [<f83edd65>]
br_multicast_rcv+0xc95/0xe1c [bridge] SS:ESP 0068:f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.124181] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181]
Dec 15 14:36:41 User-PC kernel: [175576.124181] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.124181] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.124181] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.124181] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124181] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.124181] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.124181] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.487562] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.497058] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.522221] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.550740]
Dec 15 14:36:41 User-PC kernel: [175576.557947] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.565201] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.572280] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.579125] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.585850] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.592460] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.599021] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.605632] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.612158] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.618953] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.625818] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.632737] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.639461] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.646168] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.652826] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.659441] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.673805] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.680668] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.687612] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.694516] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.711906] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.716280] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.734197] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.753330]
Dec 15 14:36:41 User-PC kernel: [175576.757845] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.762389] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.766809] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.771119] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.775348] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.780037] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.784159] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.788286] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.792375] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
^ permalink raw reply
* Re: [RFC] ath9k_htc : Update txrate status to mac80211
From: Mohammed Shafi @ 2010-12-16 12:08 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <19721.65246.410283.55163@gargle.gargle.HOWL>
On Thursday 16 December 2010 05:28 PM, Sujith wrote:
> Mohammed Shafi Shajakhan wrote:
>
>> From: Mohammed Shafi Shajakhan<mshajakhan@atheros.com>
>>
>> In ath9k htc txrate status is not updated to mac80211 as rate control is
>> handled in firmware.This workaround will obtain the txrate which was
>> supposed to be for debug statistics and updates it to mac80211 using
>> a rate control look up table.
>>
> Well, we can't match the TXRATE event with any transmitted frame,
> so we would end up sending bogus and most likely, stale, information to mac80211.
>
Hi Sujith,
Thanks for your reply.Yes we cannot cleanly send the actual
status to mac80211.
This patch just takes care for displaying the txrate and appropriately
sets mac80211 rate control flags,but completely ignores long retries.I
had tested it , except retries the MCS index , txrate in userspace
matches with the txrate reported in debug statistics.
Is there chance of any possible fix for this ?
> Sujith
> .
>
>
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Johannes Berg @ 2010-12-16 12:04 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <AANLkTimxoA+3GaZZWODKJ9MVJTJzRhnj5oh_jWGJhzWc@mail.gmail.com>
On Thu, 2010-12-16 at 03:51 -0800, Paul Stewart wrote:
> So, I'm trying to balance two fairly nasty problems here. On one end
> we have the problem before any changes where the device is not shut
> down when it legitimately should be -- we ifdown the device while scanning
> but the device in ath9k is not set to "idle".
See, I contend that statement -- we actually *turn off* the device with
stop(), so it shouldn't matter.
> Fixing the problem in ath9k
> alone causes a separate problem. If you stop the driver from mac80211's
> pm.c, ath9k would set the device ps_idle, when mac80211 does not
> consider the device to to be idle. Thus, when we resume from suspend,
> the device stays quiescent (mac80211 has no reason to believe it needs
> to do anything special to be able to tx, receive beacons, etc.)
How so? After resume, mac80211 will invoke start(), add interfaces and
stations back, and then invoke drv_config with all flags in "changed"
set. Therefore, at this point, the device should be reset. Where's this
not working?
I think the problem might be that ath9k is expecting mac80211 to
perfectly nest calls to idle/non-idle, even across suspend/resume and
device shutdown. I don't think that's feasible at all.
johannes
^ permalink raw reply
* [RFC] ath9k_htc : Update txrate status to mac80211
From: Sujith @ 2010-12-16 11:58 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan; +Cc: linux-wireless, linville, m.sujith
In-Reply-To: <1292499588-11636-1-git-send-email-mshajakhan@atheros.com>
Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
>
> In ath9k htc txrate status is not updated to mac80211 as rate control is
> handled in firmware.This workaround will obtain the txrate which was
> supposed to be for debug statistics and updates it to mac80211 using
> a rate control look up table.
Well, we can't match the TXRATE event with any transmitted frame,
so we would end up sending bogus and most likely, stale, information to mac80211.
Sujith
^ permalink raw reply
* Re: iwl rfkill suddenly dropped to hard block
From: Evgeniy Polyakov @ 2010-12-16 11:57 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, Intel Linux Wireless, netdev, linux-wireless,
wey-yi.w.guy
In-Reply-To: <4D099444.5040703@lwfinger.net>
On Wed, Dec 15, 2010 at 10:23:32PM -0600, Larry Finger (Larry.Finger@lwfinger.net) wrote:
> >I would imagine this is just related to some dellish crap, but I saw a
> >number of exactly the same cases in the web including linux-kernel mail
> >lists in the past and also without 'slider on the back' case.
>
> I doubt that it is Dell related, if that is what "dellish" means.
>
> I have had some success in clearing this problem by unloading and
> reloading the wireless driver. I had the problem on one box that has
> no rfkill switch and an 802.11b card that uses b43legacy.
I tried that as well as disabling and enabling wifi in bios (or is it
newr loader), but without success. I called this 'dellish' crap
because of the hell list of problems I had with this laptop and i915
video chipset in it. Apparently brother model e4200 does not have them
at all.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2010-12-16 11:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <1292499024.3612.3.camel@jlt3.sipsolutions.net>
On Thu, Dec 16, 2010 at 3:30 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-12-16 at 03:17 -0800, Paul Stewart wrote:
>
>> > I thought this was solved in ath9k differently? Was that somehow
>> > inadequate?
>>
>> Unfortunately previous attempts to solve this problem failed.
>
> I thought ath9k was fixed to simply go idle when stopped? Why didn't
> that help?
So, I'm trying to balance two fairly nasty problems here. On one end
we have the problem before any changes where the device is not shut
down when it legitimately should be -- we ifdown the device while scanning
but the device in ath9k is not set to "idle". Fixing the problem in ath9k
alone causes a separate problem. If you stop the driver from mac80211's
pm.c, ath9k would set the device ps_idle, when mac80211 does not
consider the device to to be idle. Thus, when we resume from suspend,
the device stays quiescent (mac80211 has no reason to believe it needs
to do anything special to be able to tx, receive beacons, etc.)
>> Here's a slightly better rationale, as I'm getting to understand the problem.
>> ieee80211_do_stop() decrements "open_count" so early during the function
>> that if the device is not idle at this point (e.g, due to scanning),
>> drv_config()
>> will never be called on the the lower-level driver, since ieee80211_hw_config()
>> tests for "open_count > 0" and silently returns no-error.
>
> Yes, I realise that -- but also Luis said this change wasn't sufficient
> in his tests, he also needed something in scan code itself. Also, this
> is really quite intentional if you read the comments around the area
> you're modifying -- mac80211 assumes that after it shuts down the device
> with stop(), the device will be powered off under control of the driver
> until start().
>
> I just don't think it'll be easy to actually make sure that we always go
> IDLE before calling stop(). This patch might solve part of the problem,
> but what about hardware scan, that might have to be stopped by the
> driver during stop()? Similar things might come up with other features.
>
> Therefore I'm not sure we should even try. If we stop() the hardware,
> what's preventing the driver from doing whatever it needs to put the
> device into a low power state?
>
> johannes
>
>
^ permalink raw reply
* [PATCH] iwlwifi: Fix error: struct iwl_lq_sta has no member named dbg_fixed_rate
From: Sedat Dilek @ 2010-12-16 11:46 UTC (permalink / raw)
To: Stephen Rothwell, John Linville
Cc: LKML, wireless, Johannes Berg, Wey-Yi Guy, Randy Dunlap
[-- Attachment #1: Type: text/plain, Size: 132 bytes --]
Attached patch fixes an issue with linux-next (20101216) and iwlwifi (see [1]).
- Sedat -
[1] http://lkml.org/lkml/2010/12/16/101
[-- Attachment #2: 0001-iwlwifi-Fix-error-struct-iwl_lq_sta-has-no-member-na.patch --]
[-- Type: text/plain, Size: 1827 bytes --]
From 7edfcb92159f36cb6aaa7eb1a9453f75d7461028 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Thu, 16 Dec 2010 12:26:04 +0100
Subject: [PATCH] iwlwifi: Fix error: struct iwl_lq_sta has no member named dbg_fixed_rate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
While compiling linux-next (next-20101216) I fell over this breakage:
...
drivers/net/wireless/iwlwifi/iwl-agn-rs.c: In function ‘iwl_rs_rate_init’:
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2876:8: error: ‘struct iwl_lq_sta’ has no member named ‘dbg_fixed_rate’
dbg_fixed_rate is only used when CONFIG_MAC80211_DEBUGFS is set:
[ drivers/net/wireless/iwlwifi/iwl-agn-rs.h ]
...
#ifdef CONFIG_MAC80211_DEBUGFS
struct dentry *rs_sta_dbgfs_scale_table_file;
struct dentry *rs_sta_dbgfs_stats_table_file;
struct dentry *rs_sta_dbgfs_rate_scale_data_file;
struct dentry *rs_sta_dbgfs_tx_agg_tid_en_file;
u32 dbg_fixed_rate;
#endif
The issue was introduced by commit a1da077bc36368eb7d6312e7e49260f0a3d92c77:
"iwlwifi: clear dbg_fixed_rate during init"
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 5083dba..75fcd30 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2873,7 +2873,9 @@ void iwl_rs_rate_init(struct iwl_priv *priv, struct ieee80211_sta *sta, u8 sta_i
lq_sta->last_txrate_idx += IWL_FIRST_OFDM_RATE;
lq_sta->is_agg = 0;
+#ifdef CONFIG_MAC80211_DEBUGFS
lq_sta->dbg_fixed_rate = 0;
+#endif
rs_initialize_lq(priv, conf, sta, lq_sta);
}
--
1.7.2.3
^ permalink raw reply related
* [RFC] ath9k_htc : Update txrate status to mac80211
From: Mohammed Shafi Shajakhan @ 2010-12-16 11:39 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
In ath9k htc txrate status is not updated to mac80211 as rate control is
handled in firmware.This workaround will obtain the txrate which was
supposed to be for debug statistics and updates it to mac80211 using
a rate control look up table.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 34 ++++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 30 +++-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 210 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/wmi.c | 8 +-
4 files changed, 272 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index fdf9d5f..7e2559a 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -196,6 +196,34 @@ struct ath9k_htc_target_rate {
struct ath9k_htc_rate rates;
};
+#define HTC_RATE_TABLE_SIZE 72
+
+#define HTC_RATE_INVALID 0x0
+#define HTC_RATE_LEGACY 0x1
+#define HTC_RATE_SS 0x2
+#define HTC_RATE_DS 0x4
+#define HTC_RATE_TS 0x8
+#define HTC_RATE_HT20 0x10
+#define HTC_RATE_HT40 0x20
+
+#define HTC_RATE_HT20_SS (HTC_RATE_SS | HTC_RATE_HT20)
+#define HTC_RATE_HT20_DS (HTC_RATE_DS | HTC_RATE_HT20)
+#define HTC_RATE_HT20_TS (HTC_RATE_TS | HTC_RATE_HT20)
+
+#define HTC_RATE_HT40_SS (HTC_RATE_SS | HTC_RATE_HT40)
+#define HTC_RATE_HT40_DS (HTC_RATE_DS | HTC_RATE_HT40)
+#define HTC_RATE_HT40_TS (HTC_RATE_TS | HTC_RATE_HT40)
+
+
+struct ath9k_htc_rate_table {
+ u8 htc_rate_cnt;
+ struct {
+ u32 htc_ratekbps;
+ s8 htc_rate_table_index;
+ u16 htc_rate_table_flags;
+ } info[HTC_RATE_TABLE_SIZE];
+};
+
struct ath9k_htc_target_stats {
__be32 tx_shortretry;
__be32 tx_longretry;
@@ -367,6 +395,9 @@ struct ath9k_htc_priv {
u16 nstations;
u16 seq_no;
u32 bmiss_cnt;
+ u32 txrate;
+ u16 htc_rate_flags;
+ u32 rate_ctrl_flags;
struct ath9k_hw_cal_data caldata[ATH9K_NUM_CHANNELS];
@@ -452,6 +483,9 @@ void ath9k_host_rx_init(struct ath9k_htc_priv *priv);
void ath9k_rx_tasklet(unsigned long data);
u32 ath9k_htc_calcrxfilter(struct ath9k_htc_priv *priv);
+enum htc_phymode ath9k_htc_get_curmode(struct ath9k_htc_priv *priv,
+ struct ath9k_channel *ichan);
+
void ath9k_htc_ps_wakeup(struct ath9k_htc_priv *priv);
void ath9k_htc_ps_restore(struct ath9k_htc_priv *priv);
void ath9k_ps_work(struct work_struct *work);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index dd17909..1c2eb78 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -36,7 +36,7 @@ static void ath_update_txpow(struct ath9k_htc_priv *priv)
}
/* HACK Alert: Use 11NG for 2.4, use 11NA for 5 */
-static enum htc_phymode ath9k_htc_get_curmode(struct ath9k_htc_priv *priv,
+enum htc_phymode ath9k_htc_get_curmode(struct ath9k_htc_priv *priv,
struct ath9k_channel *ichan)
{
enum htc_phymode mode;
@@ -353,6 +353,8 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv *priv,
}
}
trate->rates.legacy_rates.rs_nrates = j;
+ priv->htc_rate_flags = 0 ;
+ priv->rate_ctrl_flags = 0 ;
if (sta->ht_cap.ht_supported) {
for (i = 0, j = 0; i < 77; i++) {
@@ -362,21 +364,37 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv *priv,
break;
}
trate->rates.ht_rates.rs_nrates = j;
+ priv->rate_ctrl_flags |= IEEE80211_TX_RC_MCS;
caps = WLAN_RC_HT_FLAG;
- if (sta->ht_cap.mcs.rx_mask[1])
+ if (sta->ht_cap.mcs.rx_mask[1]) {
caps |= WLAN_RC_DS_FLAG;
+ priv->htc_rate_flags |= HTC_RATE_DS;
+ } else {
+ priv->htc_rate_flags |= HTC_RATE_SS;
+ }
+
if ((sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) &&
- (conf_is_ht40(&priv->hw->conf)))
+ (conf_is_ht40(&priv->hw->conf))) {
caps |= WLAN_RC_40_FLAG;
+ priv->htc_rate_flags |= HTC_RATE_HT40;
+ priv->rate_ctrl_flags |= IEEE80211_TX_RC_40_MHZ_WIDTH;
+ } else {
+ priv->htc_rate_flags |= HTC_RATE_HT20;
+ }
if (conf_is_ht40(&priv->hw->conf) &&
- (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40))
+ (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40)) {
caps |= WLAN_RC_SGI_FLAG;
- else if (conf_is_ht20(&priv->hw->conf) &&
- (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_20))
+ }
+ if (conf_is_ht20(&priv->hw->conf) &&
+ (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_20)) {
caps |= WLAN_RC_SGI_FLAG;
+ }
}
+ else
+ priv->htc_rate_flags |= HTC_RATE_LEGACY;
+
trate->sta_index = ista->index;
trate->isnew = 1;
trate->capflags = cpu_to_be32(caps);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 33f3602..1494c92 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -37,6 +37,193 @@ static const int subtype_txq_to_hwq[] = {
TXQ_FLAG_TXDESCINT_ENABLE; \
} while (0)
+
+struct ath9k_htc_rate_table htc_11na_ratetable = {
+ 68,
+ {
+ [0] = { 6000, 0, HTC_RATE_LEGACY }, /* 6 Mb */
+ [1] = { 9000, 1, HTC_RATE_LEGACY }, /* 9 Mb */
+ [2] = { 12000, 2, HTC_RATE_LEGACY }, /* 12 Mb */
+ [3] = { 18000, 3, HTC_RATE_LEGACY }, /* 18 Mb */
+ [4] = { 24000, 4, HTC_RATE_LEGACY }, /* 24 Mb */
+ [5] = { 36000, 5, HTC_RATE_LEGACY }, /* 36 Mb */
+ [6] = { 48000, 6, HTC_RATE_LEGACY }, /* 48 Mb */
+ [7] = { 54000, 7, HTC_RATE_LEGACY }, /* 54 Mb */
+ [8] = { 6500, 0, HTC_RATE_HT20_SS }, /* 6.5 Mb */
+ [9] = { 13000, 1, HTC_RATE_HT20_SS }, /* 13 Mb */
+ [10] = { 19500, 2, HTC_RATE_HT20_SS }, /* 19.5 Mb */
+ [11] = { 26000, 3, HTC_RATE_HT20_SS }, /* 26 Mb */
+ [12] = { 39000, 4, HTC_RATE_HT20_SS }, /* 39 Mb */
+ [13] = { 52000, 5, HTC_RATE_HT20_SS }, /* 52 Mb */
+ [14] = { 58500, 6, HTC_RATE_HT20_SS }, /* 58.5 Mb */
+ [15] = { 65000, 7, HTC_RATE_HT20_SS }, /* 65 Mb */
+ [16] = { 72200, 7, HTC_RATE_HT20_SS }, /* 72.2 Mb */
+ [17] = { 13000, 8, HTC_RATE_INVALID }, /* 13 Mb */
+ [18] = { 26000, 9, HTC_RATE_HT20_DS }, /* 26 Mb */
+ [19] = { 39000, 10, HTC_RATE_HT20_DS }, /* 39 Mb */
+ [20] = { 52000, 11, HTC_RATE_HT20_DS }, /* 52 Mb */
+ [21] = { 78000, 12, HTC_RATE_HT20_DS }, /* 78 Mb */
+ [22] = { 104000, 13, HTC_RATE_HT20_DS }, /* 104 Mb */
+ [23] = { 117000, 14, HTC_RATE_HT20_DS }, /* 117 Mb */
+ [24] = { 130000, 15, HTC_RATE_HT20_DS }, /* 130 Mb */
+ [25] = { 144400, 15, HTC_RATE_HT20_DS }, /* 144.4 Mb */
+ [26] = { 19500, 16, HTC_RATE_INVALID }, /* 19.5 Mb */
+ [27] = { 39000, 17, HTC_RATE_INVALID }, /* 39 Mb */
+ [28] = { 58500, 18, HTC_RATE_INVALID }, /* 58.5 Mb */
+ [29] = { 78000, 19, HTC_RATE_INVALID }, /* 78 Mb */
+ [30] = { 117000, 20, HTC_RATE_INVALID }, /* 117 Mb */
+ [31] = { 130000, 20, HTC_RATE_INVALID }, /* 130 Mb */
+ [32] = { 156000, 21, HTC_RATE_HT20_TS }, /* 156 Mb */
+ [33] = { 173300, 21, HTC_RATE_HT20_TS }, /* 173300 Mb */
+ [34] = { 175500, 22, HTC_RATE_HT20_TS }, /* 175500 Mb */
+ [35] = { 195000, 22, HTC_RATE_HT20_TS }, /* 195000 Mb */
+ [36] = { 195000, 23, HTC_RATE_HT20_TS }, /* 195000 Mb */
+ [37] = { 216700, 23, HTC_RATE_HT20_TS }, /* 216.7 Mb */
+ [38] = { 13500, 0, HTC_RATE_HT40_SS }, /* 13.5 Mb */
+ [39] = { 27500, 1, HTC_RATE_HT40_SS }, /* 27 Mb */
+ [40] = { 40500, 2, HTC_RATE_HT40_SS }, /* 40.5 Mb */
+ [41] = { 54000, 3, HTC_RATE_HT40_SS }, /* 54 Mb */
+ [42] = { 81500, 4, HTC_RATE_HT40_SS }, /* 81 Mb */
+ [43] = { 108000, 5, HTC_RATE_HT40_SS }, /* 108 Mb */
+ [44] = { 121500, 6, HTC_RATE_HT40_SS }, /* 121.5 Mb */
+ [45] = { 135000, 7, HTC_RATE_HT40_SS }, /* 135 Mb */
+ [46] = { 150000, 7, HTC_RATE_HT40_SS }, /* 150 Mb */
+ [47] = { 27000, 8, HTC_RATE_INVALID}, /* 27 Mb */
+ [48] = { 54000, 9, HTC_RATE_HT40_DS}, /* 54 Mb */
+ [49] = { 81000, 10, HTC_RATE_HT40_DS}, /* 81 Mb */
+ [50] = { 108000, 11, HTC_RATE_HT40_DS}, /* 108 Mb */
+ [51] = { 162000, 12, HTC_RATE_HT40_DS}, /* 162 Mb */
+ [52] = { 216000, 13, HTC_RATE_HT40_DS}, /* 216 Mb */
+ [53] = { 243000, 14, HTC_RATE_HT40_DS}, /* 243 Mb */
+ [54] = { 270000, 15, HTC_RATE_HT40_DS}, /* 270 Mb */
+ [55] = { 300000, 15, HTC_RATE_HT40_DS }, /* 300 Mb */
+ [56] = { 40500, 16, HTC_RATE_INVALID}, /* 40.5 Mb */
+ [57] = { 81000, 17, HTC_RATE_INVALID}, /* 81 Mb */
+ [58] = { 121500, 18, HTC_RATE_INVALID}, /* 121.5 Mb */
+ [59] = { 162000, 19, HTC_RATE_INVALID}, /* 162 Mb */
+ [60] = { 243000, 20, HTC_RATE_INVALID}, /* 243 Mb */
+ [61] = { 270000, 20, HTC_RATE_INVALID}, /* 270 Mb */
+ [62] = { 324000, 21, HTC_RATE_HT40_TS}, /* 324 Mb */
+ [63] = { 360000, 21, HTC_RATE_HT40_TS}, /* 360 Mb */
+ [64] = { 364500, 22, HTC_RATE_HT40_TS}, /* 364.5 Mb */
+ [65] = { 405000, 22, HTC_RATE_HT40_TS}, /* 405 Mb */
+ [66] = { 405000, 23, HTC_RATE_HT40_TS}, /* 405 Mb */
+ [67] = { 450000, 23, HTC_RATE_HT40_TS}, /* 450 Mb */
+ }
+};
+
+struct ath9k_htc_rate_table htc_11ng_ratetable = {
+ 72,
+ {
+
+ [0] = { 1000, 0, HTC_RATE_LEGACY }, /* 1 Mb */
+ [1] = { 2000, 1, HTC_RATE_LEGACY }, /* 2 Mb */
+ [2] = { 5500, 2, HTC_RATE_LEGACY }, /* 5.5 Mb */
+ [3] = { 11000, 3, HTC_RATE_LEGACY }, /* 11 Mb */
+ [4] = { 6000, 4, HTC_RATE_LEGACY }, /* 6 Mb */
+ [5] = { 9000, 5, HTC_RATE_LEGACY }, /* 9 Mb */
+ [6] = { 12000, 6, HTC_RATE_LEGACY }, /* 12 Mb */
+ [7] = { 18000, 7, HTC_RATE_LEGACY }, /* 18 Mb */
+ [8] = { 24000, 8, HTC_RATE_LEGACY }, /* 24 Mb */
+ [9] = { 36000, 9, HTC_RATE_LEGACY }, /* 36 Mb */
+ [10] = { 48000, 10, HTC_RATE_LEGACY }, /* 48 Mb */
+ [11] = { 54000, 11, HTC_RATE_LEGACY }, /* 54 Mb */
+ [12] = { 6500, 0, HTC_RATE_INVALID }, /* 6.5 Mb */
+ [13] = { 13000, 1, HTC_RATE_HT20_SS }, /* 13 Mb */
+ [14] = { 19500, 2, HTC_RATE_HT20_SS }, /* 19.5 Mb */
+ [15] = { 26000, 3, HTC_RATE_HT20_SS }, /* 26 Mb */
+ [16] = { 39000, 4, HTC_RATE_HT20_SS }, /* 39 Mb */
+ [17] = { 52000, 5, HTC_RATE_HT20_SS }, /* 52 Mb */
+ [18] = { 58500, 6, HTC_RATE_HT20_SS }, /* 58.5 Mb */
+ [19] = { 65000, 7, HTC_RATE_HT20_SS }, /* 65 Mb */
+ [20] = { 39000, 7, HTC_RATE_HT20_SS }, /* 72.2 Mb */
+ [21] = { 13000, 8, HTC_RATE_INVALID }, /* 13 Mb */
+ [22] = { 26000, 9, HTC_RATE_HT20_DS }, /* 26 Mb */
+ [23] = { 39000, 10, HTC_RATE_HT20_DS }, /* 39 Mb */
+ [24] = { 52000, 11, HTC_RATE_HT20_DS }, /* 52 Mb */
+ [25] = { 78000, 12, HTC_RATE_HT20_DS }, /* 78 Mb */
+ [26] = { 104000, 13, HTC_RATE_HT20_DS }, /* 104 Mb */
+ [27] = { 117000, 14, HTC_RATE_HT20_DS }, /* 117 Mb */
+ [28] = { 130000, 15, HTC_RATE_HT20_DS }, /* 130 Mb */
+ [29] = { 144400, 15, HTC_RATE_HT20_DS }, /* 144.4 Mb */
+ [30] = { 19500, 16, HTC_RATE_INVALID }, /* 19.5 Mb */
+ [31] = { 39000, 17, HTC_RATE_INVALID }, /* 39 Mb */
+ [32] = { 58500, 18, HTC_RATE_INVALID }, /* 58.5 Mb */
+ [33] = { 78000, 19, HTC_RATE_INVALID }, /* 78 Mb */
+ [34] = { 117000, 20, HTC_RATE_INVALID }, /* 117 Mb */
+ [35] = { 130000, 20, HTC_RATE_INVALID }, /* 130 Mb */
+ [36] = { 156000, 21, HTC_RATE_HT20_TS }, /* 156 Mb */
+ [37] = { 173300, 21, HTC_RATE_HT20_TS }, /* 173300 Mb */
+ [38] = { 175500, 22, HTC_RATE_HT20_TS }, /* 175500 Mb */
+ [39] = { 195000, 22, HTC_RATE_HT20_TS }, /* 195000 Mb */
+ [40] = { 195000, 23, HTC_RATE_HT20_TS}, /* 195000 Mb */
+ [41] = { 216700, 23, HTC_RATE_HT20_TS}, /* 216.7 Mb */
+ [42] = { 13500, 0, HTC_RATE_HT40_SS}, /* 13.5 Mb */
+ [43] = { 27500, 1, HTC_RATE_HT40_SS}, /* 27 Mb */
+ [44] = { 40500, 2, HTC_RATE_HT40_SS}, /* 40.5 Mb */
+ [45] = { 54000, 3, HTC_RATE_HT40_SS}, /* 54 Mb */
+ [46] = { 81500, 4, HTC_RATE_HT40_SS}, /* 81 Mb */
+ [47] = { 108000, 5, HTC_RATE_HT40_SS}, /* 108 Mb */
+ [48] = { 121500, 6, HTC_RATE_HT40_SS}, /* 121.5 Mb */
+ [49] = { 135000, 7, HTC_RATE_HT40_SS}, /* 135 Mb */
+ [50] = { 150000, 7, HTC_RATE_HT40_SS}, /* 150 Mb */
+ [51] = { 27000, 8, HTC_RATE_INVALID}, /* 27 Mb */
+ [52] = { 54000, 9, HTC_RATE_HT40_DS}, /* 54 Mb */
+ [53] = { 81000, 10, HTC_RATE_HT40_DS}, /* 81 Mb */
+ [54] = { 108000, 11, HTC_RATE_HT40_DS}, /* 108 Mb */
+ [55] = { 162000, 12, HTC_RATE_HT40_DS}, /* 162 Mb */
+ [56] = { 216000, 13, HTC_RATE_HT40_DS}, /* 216 Mb */
+ [57] = { 243000, 14, HTC_RATE_HT40_DS}, /* 243 Mb */
+ [58] = { 270000, 15, HTC_RATE_HT40_DS}, /* 270 Mb */
+ [59] = { 300000, 15, HTC_RATE_HT40_DS}, /* 300 Mb */
+ [60] = { 40500, 16, HTC_RATE_INVALID}, /* 40.5 Mb */
+ [61] = { 81000, 17, HTC_RATE_INVALID}, /* 81 Mb */
+ [62] = { 121500, 18, HTC_RATE_INVALID}, /* 121.5 Mb */
+ [63] = { 162000, 19, HTC_RATE_INVALID}, /* 162 Mb */
+ [64] = { 243000, 20, HTC_RATE_INVALID}, /* 243 Mb */
+ [65] = { 270000, 20, HTC_RATE_INVALID}, /* 270 Mb */
+ [66] = { 324000, 21, HTC_RATE_HT40_TS}, /* 324 Mb */
+ [67] = { 360000, 21, HTC_RATE_HT40_TS}, /* 360 Mb */
+ [68] = { 364500, 22, HTC_RATE_HT40_TS}, /* 364.5 Mb */
+ [69] = { 405000, 22, HTC_RATE_HT40_TS}, /* 405 Mb */
+ [70] = { 405000, 23, HTC_RATE_HT40_TS}, /* 405 Mb */
+ [71] = { 450000, 23, HTC_RATE_HT40_TS}, /* 450 Mb */
+ }
+};
+
+struct ath9k_htc_rate_table *htc_choose_rate_table(enum htc_phymode mode)
+{
+ switch (mode) {
+
+ case HTC_MODE_11NA:
+ return &htc_11na_ratetable;
+ break;
+ case HTC_MODE_11NG:
+ return &htc_11ng_ratetable;
+ break;
+ default:
+ return NULL;
+
+ }
+}
+static s8 ath9k_htc_get_rate_index(struct ath9k_htc_rate_table *htc_rtb,
+ struct ath9k_htc_priv *priv)
+{
+ s8 i;
+
+ for (i = 0; i < htc_rtb->htc_rate_cnt; i++) {
+
+ if ((priv->txrate == htc_rtb->info[i].htc_ratekbps) &&
+ (priv->htc_rate_flags ==
+ htc_rtb->info[i].htc_rate_table_flags))
+ break;
+ }
+
+ return htc_rtb->info[i].htc_rate_table_index;
+
+}
+
+
int get_hw_qnum(u16 queue, int *hwq_map)
{
switch (queue) {
@@ -215,10 +402,17 @@ static bool ath9k_htc_check_tx_aggr(struct ath9k_htc_priv *priv,
void ath9k_tx_tasklet(unsigned long data)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)data;
+ struct ieee80211_hw *hw = priv->hw;
+ struct ath_hw *ah = priv->ah;
+ struct ath9k_channel *chan;
struct ieee80211_sta *sta;
struct ieee80211_hdr *hdr;
struct ieee80211_tx_info *tx_info;
struct sk_buff *skb = NULL;
+ struct ath9k_htc_rate_table *htc_rtb = NULL;
+ enum htc_phymode mode;
+ u32 short_gi_rates[4] = {72200, 144400, 150000, 300000};
+ u8 i;
__le16 fc;
while ((skb = skb_dequeue(&priv->tx_queue)) != NULL) {
@@ -259,6 +453,22 @@ void ath9k_tx_tasklet(unsigned long data)
}
}
+ chan = ath9k_cmn_get_curchannel(hw, ah);
+ mode = ath9k_htc_get_curmode(priv, chan);
+ htc_rtb = htc_choose_rate_table(mode);
+ for (i = 0; i < 4; i++) {
+ if (priv->txrate == short_gi_rates[i])
+ priv->rate_ctrl_flags |=
+ IEEE80211_TX_RC_SHORT_GI;
+ }
+ tx_info->status.rates[0].idx =
+ ath9k_htc_get_rate_index(htc_rtb , priv);
+ tx_info->status.rates[0].flags = priv->rate_ctrl_flags;
+ tx_info->status.rates[0].count = 1;
+ tx_info->status.rates[1].idx = -1 ;
+ tx_info->status.rates[1].count = 0 ;
+
+
rcu_read_unlock();
/* Send status to mac80211 */
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index 8f42ea7..c037417 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -146,11 +146,10 @@ static void ath9k_wmi_ctrl_rx(void *priv, struct sk_buff *skb,
{
struct wmi *wmi = (struct wmi *) priv;
struct wmi_cmd_hdr *hdr;
+ struct ath9k_htc_priv *drv_priv = wmi->drv_priv;
u16 cmd_id;
void *wmi_event;
-#ifdef CONFIG_ATH9K_HTC_DEBUGFS
__be32 txrate;
-#endif
if (unlikely(wmi->stopped))
goto free_skb;
@@ -166,9 +165,10 @@ static void ath9k_wmi_ctrl_rx(void *priv, struct sk_buff *skb,
tasklet_schedule(&wmi->drv_priv->wmi_tasklet);
break;
case WMI_TXRATE_EVENTID:
-#ifdef CONFIG_ATH9K_HTC_DEBUGFS
txrate = ((struct wmi_event_txrate *)wmi_event)->txrate;
- wmi->drv_priv->debug.txrate = be32_to_cpu(txrate);
+ drv_priv->txrate = be32_to_cpu(txrate);
+#ifdef CONFIG_ATH9K_HTC_DEBUGFS
+ wmi->drv_priv->debug.txrate = drv_priv->txrate;
#endif
break;
default:
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Johannes Berg @ 2010-12-16 11:30 UTC (permalink / raw)
To: Paul Stewart; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <AANLkTi=pZAnyp5ztSqCo-MEF=_arECfAYg43JJ_j1Gb4@mail.gmail.com>
On Thu, 2010-12-16 at 03:17 -0800, Paul Stewart wrote:
> > I thought this was solved in ath9k differently? Was that somehow
> > inadequate?
>
> Unfortunately previous attempts to solve this problem failed.
I thought ath9k was fixed to simply go idle when stopped? Why didn't
that help?
> Here's a slightly better rationale, as I'm getting to understand the problem.
> ieee80211_do_stop() decrements "open_count" so early during the function
> that if the device is not idle at this point (e.g, due to scanning),
> drv_config()
> will never be called on the the lower-level driver, since ieee80211_hw_config()
> tests for "open_count > 0" and silently returns no-error.
Yes, I realise that -- but also Luis said this change wasn't sufficient
in his tests, he also needed something in scan code itself. Also, this
is really quite intentional if you read the comments around the area
you're modifying -- mac80211 assumes that after it shuts down the device
with stop(), the device will be powered off under control of the driver
until start().
I just don't think it'll be easy to actually make sure that we always go
IDLE before calling stop(). This patch might solve part of the problem,
but what about hardware scan, that might have to be stopped by the
driver during stop()? Similar things might come up with other features.
Therefore I'm not sure we should even try. If we stop() the hardware,
what's preventing the driver from doing whatever it needs to put the
device into a low power state?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2010-12-16 11:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, luis.rodriguez
In-Reply-To: <1292482775.3542.8.camel@jlt3.sipsolutions.net>
On Wed, Dec 15, 2010 at 10:59 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2010-12-15 at 10:54 -0800, Paul Stewart wrote:
>> Sometimes mac80211 doesn't push idle state downwards to the
>> driver. Specifically, there are times in some functions where
>> the "local->hw.conf.flags & IEEE80211_CONF_IDLE" may change but
>> the equivalent of "drv_config(local, IEEE80211_CONF_CHANGE_IDLE)"
>> does not end up being called. This is usually not all that
>> problematic except, for example, suspending and resuming an idle
>> ath9k device. If the device isn't marked idle when
>> ieee80211_stop_device() is called, the device never gets put to
>> sleep, and will end up in an unresponsive state on resume.
>
> I thought this was solved in ath9k differently? Was that somehow
> inadequate?
Unfortunately previous attempts to solve this problem failed.
>> As a precaution, explicitly call drv_config() before
>> ieee80211_stop_device(), which should be a no-op under normal
>> circumstances, but where this problem arises, it will shut down
>> the ath9k where necessary.
>
> I'm not convinced that this makes a lot of sense. I'm sure you can come
> up with other scenarios in which we stop a device and expect it to come
> back. I'm not sure why mac80211 should be responsible for all this?
>
>> One example where this problem occurs is when I down an interface
>> while a scan is in progress on ath9k. If the device was not shut
>> down correctly and the system suspends and resumes repeatedly with
>> ath9k, I end up with a fatal register read error (0x7000/deadbeef)
>> when trying to bring the interface back up.
>>
>> Signed-off-by: Paul Stewart <pstew@google.com>
>> ---
>> net/mac80211/iface.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
>> index b6db237..5af5a89 100644
>> --- a/net/mac80211/iface.c
>> +++ b/net/mac80211/iface.c
>> @@ -536,6 +536,7 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
>> if (local->ops->napi_poll)
>> napi_disable(&local->napi);
>> ieee80211_clear_tx_pending(local);
>> + drv_config(local, IEEE80211_CONF_CHANGE_IDLE);
>> ieee80211_stop_device(local);
>>
>> /* no reconfiguring after stop! */
>
> I don't like this anyway -- you're calling a driver callback directly,
> and there's no guarantee that just that particular change will be used
> by the driver -- it's free to look at other state given to it in each
> callback as well. That seems problematic because of all the other logic
> that we have in ieee80211_hw_config().
>
> At the very least I think you need to provide a better rationale for
> this patch and explain why the ath9k change isn't sufficient?
Here's a slightly better rationale, as I'm getting to understand the problem.
ieee80211_do_stop() decrements "open_count" so early during the function
that if the device is not idle at this point (e.g, due to scanning),
drv_config()
will never be called on the the lower-level driver, since ieee80211_hw_config()
tests for "open_count > 0" and silently returns no-error.
--
Paul
^ permalink raw reply
* Re: linux-next: Tree for December 16 (broken iwlwifi)
From: Sedat Dilek @ 2010-12-16 11:16 UTC (permalink / raw)
To: Stephen Rothwell, John Linville
Cc: LKML, wireless, Johannes Berg, Wey-Yi Guy, Randy Dunlap
In-Reply-To: <AANLkTi=t0VqSiZ=k9rBxPBVnHxy6v3JvTwW-n6ngM1f0@mail.gmail.com>
On Thu, Dec 16, 2010 at 12:05 PM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> On Thu, Dec 16, 2010 at 11:54 AM, Sedat Dilek
> <sedat.dilek@googlemail.com> wrote:
>> Hi,
>>
>> Just FYI (didn't look at the code right now, sorry for German output):
>>
>> [ build.log ]
>> ...
>> /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:
>> In function ‘iwl_rs_rate_init’:
>> /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2876:8:
>> error: ‘struct iwl_lq_sta’ has no member named ‘dbg_fixed_rate’
>> make[8]: *** [drivers/net/wireless/iwlwifi/iwl-agn-rs.o] Fehler 1
>> make[7]: *** [drivers/net/wireless/iwlwifi] Fehler 2
>> make[6]: *** [drivers/net/wireless] Fehler 2
>> make[6]: *** Warte auf noch nicht beendete Prozesse...
>> ...
>>
>> Regards,
>> - Sedat -
>>
>
> Looks like dbg_fixed_rate is only set when CONFIG_MAC80211_DEBUGFS is set:
>
> [ drivers/net/wireless/iwlwifi/iwl-agn-rs.h ]
> ...
> #ifdef CONFIG_MAC80211_DEBUGFS
> struct dentry *rs_sta_dbgfs_scale_table_file;
> struct dentry *rs_sta_dbgfs_stats_table_file;
> struct dentry *rs_sta_dbgfs_rate_scale_data_file;
> struct dentry *rs_sta_dbgfs_tx_agg_tid_en_file;
> u32 dbg_fixed_rate;
> #endif
> ...
>
> So I have no CONFIG_MAC80211_DEBUGFS... :-).
> Can someone fix that, please?
>
> - Sedat -
>
Untested !
----- SNIP -----
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 5083dba..75fcd30 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2873,7 +2873,9 @@ void iwl_rs_rate_init(struct iwl_priv *priv,
struct ieee80211_sta *sta, u8 sta_i
lq_sta->last_txrate_idx += IWL_FIRST_OFDM_RATE;
lq_sta->is_agg = 0;
+#ifdef CONFIG_MAC80211_DEBUGFS
lq_sta->dbg_fixed_rate = 0;
+#endif
rs_initialize_lq(priv, conf, sta, lq_sta);
}
----- SNAP -----
^ permalink raw reply related
* Re: linux-next: Tree for December 16 (broken iwlwifi)
From: Sedat Dilek @ 2010-12-16 11:05 UTC (permalink / raw)
To: Stephen Rothwell, John Linville
Cc: LKML, wireless, Johannes Berg, Wey-Yi Guy, Randy Dunlap
In-Reply-To: <AANLkTinbhb-_v+8tJBPeoLcDo0mFzwo2EZAy3bnvErFT@mail.gmail.com>
On Thu, Dec 16, 2010 at 11:54 AM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> Hi,
>
> Just FYI (didn't look at the code right now, sorry for German output):
>
> [ build.log ]
> ...
> /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:
> In function ‘iwl_rs_rate_init’:
> /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2876:8:
> error: ‘struct iwl_lq_sta’ has no member named ‘dbg_fixed_rate’
> make[8]: *** [drivers/net/wireless/iwlwifi/iwl-agn-rs.o] Fehler 1
> make[7]: *** [drivers/net/wireless/iwlwifi] Fehler 2
> make[6]: *** [drivers/net/wireless] Fehler 2
> make[6]: *** Warte auf noch nicht beendete Prozesse...
> ...
>
> Regards,
> - Sedat -
>
Looks like dbg_fixed_rate is only set when CONFIG_MAC80211_DEBUGFS is set:
[ drivers/net/wireless/iwlwifi/iwl-agn-rs.h ]
...
#ifdef CONFIG_MAC80211_DEBUGFS
struct dentry *rs_sta_dbgfs_scale_table_file;
struct dentry *rs_sta_dbgfs_stats_table_file;
struct dentry *rs_sta_dbgfs_rate_scale_data_file;
struct dentry *rs_sta_dbgfs_tx_agg_tid_en_file;
u32 dbg_fixed_rate;
#endif
...
So I have no CONFIG_MAC80211_DEBUGFS... :-).
Can someone fix that, please?
- Sedat -
^ permalink raw reply
* Re: linux-next: Tree for December 16 (broken iwlwifi)
From: Sedat Dilek @ 2010-12-16 10:54 UTC (permalink / raw)
To: Stephen Rothwell, John Linville
Cc: LKML, wireless, Johannes Berg, Wey-Yi Guy, Randy Dunlap
Hi,
Just FYI (didn't look at the code right now, sorry for German output):
[ build.log ]
...
/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:
In function ‘iwl_rs_rate_init’:
/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2876:8:
error: ‘struct iwl_lq_sta’ has no member named ‘dbg_fixed_rate’
make[8]: *** [drivers/net/wireless/iwlwifi/iwl-agn-rs.o] Fehler 1
make[7]: *** [drivers/net/wireless/iwlwifi] Fehler 2
make[6]: *** [drivers/net/wireless] Fehler 2
make[6]: *** Warte auf noch nicht beendete Prozesse...
...
Regards,
- Sedat -
^ permalink raw reply
* Re: Netlink Memory Leak Issue
From: jpo234 @ 2010-12-16 10:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <B659B0EE7F1D5A499E4A4BEB0BECBA2518292B3D21@GUREXMB01.ASIAN.AD.ARICENT.COM>
Saurabh8 Jain <saurabh8.jain@...> writes:
> Where is this memory getting free? Do I need to free this memory?
>
> When I executed iw commands to set few values in loop. I saw there is drop in
free memory of "top" command. I am
> working on compatwireless-2010-06-27.
Do you really think that a perceived memory leak in libnl could explain this?
This can't be true. If you run iw in a shell loop it will terminate after every
invocation and the kernel will free all associated resources.
Regards
Joerg
^ permalink raw reply
* RE: [PATCH 0/8] staging: brcm80211: Cleanup include/proto/ethernet.h
From: Arend Van Spriel @ 2010-12-16 10:33 UTC (permalink / raw)
To: Joe Perches
Cc: linux-wireless@vger.kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
In-Reply-To: <cover.1292287720.git.joe@perches.com>
Hi Joe
Thanks for digging in. I had same changes and some other in store for the driver, but pending some testing did not post them yet.
Greg,
Could you add my Acked-by to this patch series:
Acked-by: Arend van Spriel <arend@broadcom.com>
Gr. AvS
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] On Behalf Of Joe Perches [joe@perches.com]
Sent: Tuesday, December 14, 2010 1:56 AM
Cc: linux-wireless@vger.kernel.org; devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org
Subject: [PATCH 0/8] staging: brcm80211: Cleanup include/proto/ethernet.h
Use the standard kernel mechanisms and remove some entries from this file.
Joe Perches (8):
staging: brcm80211: Remove unused #defines ETHER_<foo>_LOCALADDR
staging: brcm80211: Convert ETHER_IS_MULTI to is_multicast_ether_addr
staging: brcm80211: Remove unused ether_<foo> #defines and struct
staging: brcm80211: Convert ETHER_IS<FOO> to is_<foo>_ether_addr
staging: brcm80211: Convert ETHER_ADDR_LEN to ETH_ALEN
staging: brcm80211: Remove ETHER_HDR_LEN, use ETH_HLEN
staging: brcm80211: Remove unused ETHER_TYPE_<foo> #defines
staging: brcm80211: Convert ETHER_TYPE_802_1X to ETH_P_PAE
drivers/staging/brcm80211/brcmfmac/dhd_cdc.c | 2 +-
drivers/staging/brcm80211/brcmfmac/dhd_common.c | 8 +-
drivers/staging/brcm80211/brcmfmac/dhd_linux.c | 32 +++++-----
drivers/staging/brcm80211/brcmfmac/wl_cfg80211.c | 38 ++++++------
drivers/staging/brcm80211/brcmfmac/wl_cfg80211.h | 2 +-
drivers/staging/brcm80211/brcmfmac/wl_iw.c | 63 ++++++++++----------
drivers/staging/brcm80211/include/proto/ethernet.h | 54 +++--------------
drivers/staging/brcm80211/sys/wl_mac80211.c | 2 +-
drivers/staging/brcm80211/sys/wlc_ampdu.c | 2 +-
drivers/staging/brcm80211/sys/wlc_bmac.c | 9 ++-
drivers/staging/brcm80211/sys/wlc_mac80211.c | 40 +++++++------
drivers/staging/brcm80211/util/bcmsrom.c | 15 +++--
12 files changed, 118 insertions(+), 149 deletions(-)
--
1.7.3.3.398.g0b0cd.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] wl12xx_sdio_test: rename files to match current style
From: Luciano Coelho @ 2010-12-16 9:26 UTC (permalink / raw)
To: Roger Quadros; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4D09D80B.1020402@nokia.com>
On Thu, 2010-12-16 at 11:12 +0200, Roger Quadros wrote:
> >> what platform do you use to verify with mainline kernel& sdio
> wl1271 ?
> >
> > I use both our RX-71 and a Beagleboard. I have trees which work on
> > both, let me know if you want to clone them from my local git.
> >
>
> Yes that will be helpful. Please provide me a link to your tree that
> works with RX-71.
Ok, I'll send it to you privately. This is on our intranet, so nobody
else can access it from outside anyway (hopefully! ;).
--
Cheers,
Luca.
^ 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