* Re: Help adding trace events to xHCI
From: Kalle Valo @ 2013-07-12 18:59 UTC (permalink / raw)
To: Sarah Sharp
Cc: Johannes Berg, Xenia Ragiadakou, OPW Kernel Interns List,
linux-usb, linux-wireless, Steven Rostedt, linux-trace-users
In-Reply-To: <20130712164104.GA15531@xanatos>
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
>
>> Instead of individual trace points for command I would recommend to
>> consider just pushing the whole command buffer to the trace point and
>> parse the command in trace-cmd plugin in user space. Kernel code would
>> be simpler that way.
>
> Thanks for the suggestion. I'm not familiar with all the userspace
> tools for trace events, so I didn't know about the command parser. Is
> there documentation or a list of resources for all the userspace trace
> event plugins? If so, can you give us a pointer to it?
For ath6kl I started writing (but did not finish yet) a simple python
plugin for trace-cmd. I really like the idea of implementing of
implementing the parser with python, it's so much faster and more
convenient. I haven't published the plugin yet so that's not going to
help you right now.
But trace-cmd documentation about python plugins should give some ideas
how to use python:
https://git.kernel.org/cgit/linux/kernel/git/rostedt/trace-cmd.git/tree/Documentation/README.PythonPlugin
And as usual, Johannes is a good source of information ;)
--
Kalle Valo
^ permalink raw reply
* fail to flush all tx fifo queues
From: Dave Jones @ 2013-07-12 18:34 UTC (permalink / raw)
To: ilw; +Cc: linux-wireless
I just hit this on Linus' current post 3.10 tree.
hardware is 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)
iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 11
iwlwifi 0000:03:00.0: Current SW read_ptr 247 write_ptr 2
iwl data: 00000000: 03 00 00 00 00 00 00 00 00 00 80 ff 00 00 00 03 ................
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(1) = 0xc010b001
iwlwifi 0000:03:00.0: FH TRBs(2) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(3) = 0x80300095
iwlwifi 0000:03:00.0: FH TRBs(4) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(5) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(6) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(7) = 0x00704006
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [150,150]
iwlwifi 0000:03:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [67,71]
iwlwifi 0000:03:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 4 is active and mapped to fifo 7 ra_tid 0x0000 [7,7]
iwlwifi 0000:03:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 9 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 11 is active and mapped to fifo 1 ra_tid 0x0000 [247,2]
iwlwifi 0000:03:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
iwlwifi 0000:03:00.0: Current SW read_ptr 157 write_ptr 161
iwl data: 00000000: 00 00 00 e0 00 00 00 00 01 00 00 00 00 00 00 00 ................
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(1) = 0xc010b0e6
iwlwifi 0000:03:00.0: FH TRBs(2) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(3) = 0x80300098
iwlwifi 0000:03:00.0: FH TRBs(4) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(5) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(6) = 0x00000000
iwlwifi 0000:03:00.0: FH TRBs(7) = 0x0070408e
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [153,153]
iwlwifi 0000:03:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [157,161]
iwlwifi 0000:03:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 4 is active and mapped to fifo 7 ra_tid 0x0000 [143,143]
iwlwifi 0000:03:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 9 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 11 is active and mapped to fifo 1 ra_tid 0x0000 [227,231]
iwlwifi 0000:03:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
iwlwifi 0000:03:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
At this point, the chip was hung. Even unloading/reloading the driver, or suspend/resume
wouldn't bring it back to life. I had to power off/on to get it to work again.
Dave
^ permalink raw reply
* Re: [Ilw] Re: Slow throughput on Ultimate-N 6300
From: Mariano Aliaga @ 2013-07-12 18:02 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Steve Freitas, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3019FFE28@HASMSX103.ger.corp.intel.com>
Hi Emmanuel,
On Wed, Jul 10, 2013 at 2:55 AM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>>
>> Emmanuel,
>>
>> Thank you for your quick response!
>>
>> It is a regression. I regularly had 300 Mbps speeds on this very access point,
>> but it was years ago, in the 2.6 kernel series. However, I believe, from
>> extensive online searches, that Intel has disabled the N functionality in the
>> firmware on Linux, ostensibly until they (you? :-)
>> ) can fix whatever problem they were seeing. With the demise of the Intel
>> Linux Wireless bug tracker, though, public tracking of the bug has been
>> impossible. There are now-dead links to the defunct bug tracker over this
>> very issue.
>>
>
> 11n hasn't been disabled in firmware, but rather in driver.
> There is a bug we know about the "fail to flush tx fifo" thing that people reports (through mailing list or bugzilla of RedHat).
> Can you please send the output of the kerne log (dmesg)?
>
I've been also experiencing the "fail to flush tx fifo" bug for a
long time, so I'll provide my environment and logs in case it's
helpful:
- System: Thinkpad T410
- Chipset: Intel Corporation Centrino Advanced-N 6200 [8086:4239] (rev 35)
- Kernel: 3.10.0 x86_64 (tried 3.2, 3.5, 3.8 and 3.9 also. It got a
lot better on 3.10 btw)
- Firmware: 9.221.4.1 build 25532
- AP: Linksys E1200 fw ver 1.0.00 build 11 (but happens also with
other N AP's)
- Log on dmesg: this repeated 12 times when I booted and connected
to my wifi network
[ 19.576029] iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 0
[ 19.576039] iwlwifi 0000:03:00.0: Current SW read_ptr 3 write_ptr 4
[ 19.576089] iwl data: 00000000: 08 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 ................
[ 19.576125] iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[ 19.576183] iwlwifi 0000:03:00.0: FH TRBs(1) = 0x80102004
[ 19.576196] iwlwifi 0000:03:00.0: FH TRBs(2) = 0x00000000
[ 19.576209] iwlwifi 0000:03:00.0: FH TRBs(3) = 0x80300003
[ 19.576222] iwlwifi 0000:03:00.0: FH TRBs(4) = 0x00000000
[ 19.576235] iwlwifi 0000:03:00.0: FH TRBs(5) = 0x00000000
[ 19.576248] iwlwifi 0000:03:00.0: FH TRBs(6) = 0x00000000
[ 19.576261] iwlwifi 0000:03:00.0: FH TRBs(7) = 0x00704040
[ 19.576317] iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo
3 ra_tid 0x0000 [3,4]
[ 19.576373] iwlwifi 0000:03:00.0: Q 1 is active and mapped to fifo
2 ra_tid 0x0000 [0,0]
[ 19.576429] iwlwifi 0000:03:00.0: Q 2 is active and mapped to fifo
1 ra_tid 0x0000 [4,5]
[ 19.576484] iwlwifi 0000:03:00.0: Q 3 is active and mapped to fifo
0 ra_tid 0x0000 [0,0]
[ 19.576540] iwlwifi 0000:03:00.0: Q 4 is active and mapped to fifo
7 ra_tid 0x0000 [65,65]
[ 19.576595] iwlwifi 0000:03:00.0: Q 5 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576651] iwlwifi 0000:03:00.0: Q 6 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576705] iwlwifi 0000:03:00.0: Q 7 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576761] iwlwifi 0000:03:00.0: Q 8 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576815] iwlwifi 0000:03:00.0: Q 9 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576871] iwlwifi 0000:03:00.0: Q 10 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576928] iwlwifi 0000:03:00.0: Q 11 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.576983] iwlwifi 0000:03:00.0: Q 12 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577038] iwlwifi 0000:03:00.0: Q 13 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577094] iwlwifi 0000:03:00.0: Q 14 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577149] iwlwifi 0000:03:00.0: Q 15 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577204] iwlwifi 0000:03:00.0: Q 16 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577261] iwlwifi 0000:03:00.0: Q 17 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577317] iwlwifi 0000:03:00.0: Q 18 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.577372] iwlwifi 0000:03:00.0: Q 19 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[ 19.628329] cfg80211: Calling CRDA to update world regulatory domain
[ 19.632242] cfg80211: World regulatory domain updated:
[ 19.632245] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 19.632247] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 19.632249] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 19.632250] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 19.632252] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 19.632253] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 23.041735] wlan0: authenticate with 58:6d:8f:c3:47:2e
[ 23.068235] wlan0: send auth to 58:6d:8f:c3:47:2e (try 1/3)
[ 23.081353] wlan0: authenticated
[ 23.082190] wlan0: associate with 58:6d:8f:c3:47:2e (try 1/3)
[ 23.085720] wlan0: RX AssocResp from 58:6d:8f:c3:47:2e (capab=0x411
status=0 aid=6)
[ 23.091628] wlan0: associated
This does not always happen, it's kind of random. I think it
happens more frequently in places with a lot of wifi networks
available.
I'll try with older firmwares as suggested and let you know. I can
provide more info if you need.
TIA
Mariano
^ permalink raw reply
* Re: [PATCH] brcmsmac: Further reduce log spam from tx phy messages
From: Joe Perches @ 2013-07-12 18:00 UTC (permalink / raw)
To: John Greene; +Cc: linville, arend, linux-wireless
In-Reply-To: <1373640919-2685-1-git-send-email-jogreene@redhat.com>
On Fri, 2013-07-12 at 10:55 -0400, John Greene wrote:
> Relegate 2 phy messages to debug status as they create excessive
> log spam, noted in multiple bugzillas for brcmsmac v3.8 and up.
Hi John,
Just trivia:
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
[]
> @@ -928,7 +928,7 @@ brcms_c_ampdu_dotxstatus_complete(struct ampdu_info *ampdu, struct scb *scb,
[]
> - brcms_err(wlc->hw->d11core,
> + brcms_dbg_ht(wlc->hw->d11core,
> "%s: ampdu tx phy error (0x%x)\n",
> __func__, txs->phyerr);
Please keep the indentation of the arguments of
the same statement aligned to the open parenthesis.
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
[]
> @@ -882,7 +882,7 @@ brcms_c_dotxstatus(struct brcms_c_info *wlc, struct tx_status *txs)
[]
> - brcms_err(wlc->hw->d11core, "phyerr 0x%x, rate 0x%x\n",
> + brcms_dbg_tx(wlc->hw->d11core, "phyerr 0x%x, rate 0x%x\n",
> txs->phyerr, txh->MainRates);
Here too.
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Mathieu Desnoyers @ 2013-07-12 17:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: Kalle Valo, Johannes Berg, Xenia Ragiadakou,
OPW Kernel Interns List, linux-usb, linux-wireless,
Steven Rostedt, linux-trace-users, lttng-dev
In-Reply-To: <20130712164104.GA15531@xanatos>
* Sarah Sharp (sarah.a.sharp@linux.intel.com) wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> >
> > > My initial list of specific trace points was something like:
> > >
> > > 1. xHCI host initialization and shutdown
> > >
> > > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
> > >
> > > 3. A few individual xHCI host controller command tracepoints:
> > > * status only for all completed commands
> > > * Address Device command status and output
> > > * Configure Endpoint and Evaluate Context output
> > > * individual trace points for other xHCI commands
> > >
> > > 4. Tracepoints for all USB transfer types:
> > > * Control TX output (only for non-successful transfers)
> > > * Bulk TX
> > > * Interrupt TX
> > > * Isoc TX
> > >
> > > 5. URB cancellation
> > >
> > > And probably more. Basically, I want to be able to control what gets
> > > printed, based on where I think the xHCI bug might be. Does that sound
> > > reasonable?
> >
> > Instead of individual trace points for command I would recommend to
> > consider just pushing the whole command buffer to the trace point and
> > parse the command in trace-cmd plugin in user space. Kernel code would
> > be simpler that way.
>
> Thanks for the suggestion. I'm not familiar with all the userspace
> tools for trace events, so I didn't know about the command parser. Is
> there documentation or a list of resources for all the userspace trace
> event plugins? If so, can you give us a pointer to it?
(CCing lttng-dev)
You might want to try out LTTng-UST. It provides TRACEPOINT_EVENT() and
tracepoint() for user-space instrumentation. See:
- https://lttng.org/files/doc/man-pages/man3/lttng-ust.3.html
- http://lttng.org
Thanks,
Mathieu
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Steven Rostedt @ 2013-07-12 16:55 UTC (permalink / raw)
To: Sarah Sharp
Cc: Kalle Valo, Johannes Berg, Xenia Ragiadakou,
OPW Kernel Interns List, linux-usb, linux-wireless,
linux-trace-users, Jiri Olsa
In-Reply-To: <20130712164104.GA15531@xanatos>
On Fri, 2013-07-12 at 09:41 -0700, Sarah Sharp wrote:
> On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Thanks for the suggestion. I'm not familiar with all the userspace
> tools for trace events, so I didn't know about the command parser. Is
> there documentation or a list of resources for all the userspace trace
> event plugins? If so, can you give us a pointer to it?
>
Currently the plugins only exist in trace-cmd. But there's going to be
work done to get them into the kernel tools directory. I was just
talking with Jiri about this today. Perf will require it.
trace-cmd repo is here:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
-- Steve
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Sarah Sharp @ 2013-07-12 16:41 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, Xenia Ragiadakou, OPW Kernel Interns List,
linux-usb, linux-wireless, Steven Rostedt, linux-trace-users
In-Reply-To: <87y59c4d60.fsf@kamboji.qca.qualcomm.com>
On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote:
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>
> > My initial list of specific trace points was something like:
> >
> > 1. xHCI host initialization and shutdown
> >
> > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
> >
> > 3. A few individual xHCI host controller command tracepoints:
> > * status only for all completed commands
> > * Address Device command status and output
> > * Configure Endpoint and Evaluate Context output
> > * individual trace points for other xHCI commands
> >
> > 4. Tracepoints for all USB transfer types:
> > * Control TX output (only for non-successful transfers)
> > * Bulk TX
> > * Interrupt TX
> > * Isoc TX
> >
> > 5. URB cancellation
> >
> > And probably more. Basically, I want to be able to control what gets
> > printed, based on where I think the xHCI bug might be. Does that sound
> > reasonable?
>
> Instead of individual trace points for command I would recommend to
> consider just pushing the whole command buffer to the trace point and
> parse the command in trace-cmd plugin in user space. Kernel code would
> be simpler that way.
Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?
Sarah Sharp
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware.
From: Ben Greear @ 2013-07-12 15:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87d2qn4yr9.fsf@kamboji.qca.qualcomm.com>
On 07/12/2013 07:51 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 07/11/2013 02:36 AM, Kalle Valo wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to
>>>> + * be cleaned up, but this method is still called a few times. Check
>>>> + * for NULL here so we don't crash. Probably a better fix is to stop
>>>> + * the ath10k_pci_ce_tasklet sooner.
>>>> + */
>>>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id))
>>>> + return;
>>>> +
>>>> + ctrl_addr = ce_state->ctrl_addr;
>>>> +
>>>
>>> The tests you add look like workarounds. I would prefer to try fix these
>>> by going to the source of the problem. Maybe we should add
>>> ath10k_pci_wake() and ath10k_do_pci_wake()?
>
> Doh, dropped an essential word from a sentence, again. That's what I get
> when trying to do multiple things at the same time.
>
> What I was trying to say: Maybe we should add proper error hanling to
> ath10k_pci_wake() and ath10k_do_pci_wake() and that way avoid this?
Maybe..I haven't spent much time in the driver yet, so not sure
the best place to fix the null ce_state issue.
>> These are work-arounds, but you should not let a bad piece of
>> hardware/firmware crash the entire OS just because you don't want to
>> do sanity checking on the values you get from the firmware. Perhaps
>> there is a better fix for the code above, but the warning splat should
>> still provide incentive to get it right, while not crashing the OS in
>> the meantime.
>
> Sure, the driver should not crash if HW is not functioning correctly.
> I'm just saying that adding odd checks at random places is not the
> "kernel way" to do things, only GTK people do that ;)
>
> I was thinking that the proper way is to check that wakeup succeeds and
> not enable interrupts or something like that.
With the array-index crashes, you are asking firmware for some
value, and not sanity checking the return value to make sure it
is bounded by the array length. In my case, it's returning something very
wrong because PCI isn't talking, or something like that.
But, even with functional PCI, you could get a value that for
whatever reason doesn't match the expected value (ie, buggy firmware).
I think you must sanity check those values that can crash the OS
with stray memory access, at least.
>>> Can you enable few debug logs, like ATH10K_DBG_PCI, and post them? That
>>> would give more hint there things are going wrong.
>>
>> Yes, I can do that.
>
> Thanks.
>
> Oh, did you mention something that ath10k detect the device as hw2.0?
> Maybe the PCI ids are wrong? Then you could also force the same
> workaround for hw2.0 as hw1.0 has:
I tried just changing the #defines so that it was treated as V1,
but that did not help. I can try your suggestion when I get
a chance. I hope to have some time to do some more
twiddling on these NICs later today or early next week.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] brcmsmac: Further reduce log spam from tx phy messages
From: John Greene @ 2013-07-12 14:55 UTC (permalink / raw)
To: linville; +Cc: arend, linux-wireless
Relegate 2 phy messages to debug status as they create excessive
log spam, noted in multiple bugzillas for brcmsmac v3.8 and up.
This is a follow on to net-next 99e94940697adec4f84758adb2db71f4a82c7ba5:
brcmsmac: Reduce log spam in heavy tx, make err print in debug
brcmsmac bcma0:0: phyerr 0x10, rate 0x14
brcmsmac bcma0:0: brcms_c_ampdu_dotxstatus_complete:
ampdu tx phy error (0x10)
Signed-off-by: John Greene <jogreene@redhat.com>
---
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c | 2 +-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
index bd98285..42efac7 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
@@ -928,7 +928,7 @@ brcms_c_ampdu_dotxstatus_complete(struct ampdu_info *ampdu, struct scb *scb,
}
} else if (txs->phyerr) {
update_rate = false;
- brcms_err(wlc->hw->d11core,
+ brcms_dbg_ht(wlc->hw->d11core,
"%s: ampdu tx phy error (0x%x)\n",
__func__, txs->phyerr);
}
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 9fd6f2f..fdb4c3f 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -882,7 +882,7 @@ brcms_c_dotxstatus(struct brcms_c_info *wlc, struct tx_status *txs)
mcl = le16_to_cpu(txh->MacTxControlLow);
if (txs->phyerr)
- brcms_err(wlc->hw->d11core, "phyerr 0x%x, rate 0x%x\n",
+ brcms_dbg_tx(wlc->hw->d11core, "phyerr 0x%x, rate 0x%x\n",
txs->phyerr, txh->MainRates);
if (txs->frameid != le16_to_cpu(txh->TxFrameID)) {
--
1.7.11.7
^ permalink raw reply related
* Re: Poor wireless reception on BCM4313
From: Maximilian Engelhardt @ 2013-07-12 15:27 UTC (permalink / raw)
To: Piotr Haber; +Cc: brcm80211-dev-list, linux-wireless
In-Reply-To: <51E008FC.4010104@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 22191 bytes --]
On Friday 12 July 2013 15:47:40 Piotr Haber wrote:
> On 07/12/13 14:55, Maximilian Engelhardt wrote:
> > On Friday 21 June 2013 20:26:25 Maximilian Engelhardt wrote:
> >> Hello developers,
> >>
> >> I'm having problems with the reception performance of my BCM4313 wireless
> >> card. The card is basically working fine, but the reception is quite bad
> >> compared to other wifi equipment. I first suspected a hardware problem,
> >> but
> >> after I tried Windows 7 with the same hardware and having no problem
> >> there
> >> I'm quite sure this is a software issue.
> >>
> >>
> >> Here is a more detailed explanation of a test setup I performed to show
> >> the
> >> problem:
> >>
> >> I have an AP in about 2m distance and I connected to it by my BCM4313
> >> card
> >> and by a USB dongle (TP-Link TL-WN821N, using ath9k_htc). Both
> >> connections
> >> work and I can ping the AP using both cards.
> >>
> >> iw dev $DEV link shows a signal of about -68 dBm for the broadcom card
> >> and
> >> about -51 dBm for the atheros dongle. I have no idea in how far one can
> >> trust these values, but the difference between these two cards mostly
> >> seems
> >> to be 20-30 dB, also in my further experiments (greater distance from the
> >> AP).
> >>
> >> Now with both dongles being connected I move my laptop away from the AP
> >> and
> >> of course the signal is getting weaker. However at some point the
> >> broadcom
> >> card looses the connection to the AP while the USB dongle still has good
> >> connection (at this point the signal strength of the broadcom card is
> >> about
> >> -90dBm and -60dBm for the USB dongle). In my test with the Windows driver
> >> at that point the connection was still good and maximum distance till I
> >> lost the connection was much larger. So I don't think is a hardware
> >> problem.
> >>
> >> In general I can say my BCM4313 card is only usable when I'm in vicinity
> >> of
> >> the AP. If I move further away the connection becomes unusable slow or is
> >> lost, while it is still working well using other cards/drivers.
> >>
> >>
> >> I'm currently using a 3.10-rc5 kernel with Debian jessie (kernel is from
> >> experimental, but the same behavior has been there with kernel 3.9, 3.8
> >> (and older)). The driver used for the broadcom card is brcmsmac.
> >>
> >>
> >> I did a search non the Internet regarding this issue and found some other
> >> people having the same problem but no real solution to this. There is a
> >> workaround some Ubuntu related sites, which consists of blacklisting the
> >> brcmsmac driver and installing the wl driver. With the wl driver this
> >> problem seems to be fixed according to the web (I didn't try it myself).
> >>
> >> As I have no idea where this problem could be and how I can debug it, so
> >> I'm writing this mail now. If you need any addition information I'm
> >> happy to provide it.
> >> From the numbers shown above it seems like there is an attenuator of
> >> 20-30dB active on the receiver of the broadcom card.
> >
> > [...]
> >
> >
> > Hello,
> >
> > Is there any progress on this issue?
> > Here are the results of some additional test I performed.
> >
> >
> > I set up a AP (11g) and connected two client to it. The clients were my
> > bcm4313 wireless card and the TP-Link TL-WN821N USB dongle which was
> > connected to the laptop with the broadcom card. I connected both cards to
> > the AP. The distance between the cards and the AP was about 3m.
> > Then I set up another wireless card (TP-WN722N) in monitor mode about 3m
> > away from the AP and about 3m away from the laptop with the two wireless
> > cards. This card was connected to a different PC and I captured the data
> > of the clients and the AP. I then had a look at the reported SSI. You can
> > see my measured results below:
> >
> > SSI for packets from the AP: -27 to -23dBm
> > SSI for packets from client1 (broadcom): -20 to -14dBm
> > SSI for packets from client2 (atheros): -40 to -38dBm
> >
> > The received signal from the broadcom card were quite strong. The signal
> > from the AP was a bit weaker. Interestingly the signal from the second
> > card was noticeably weaker. I didn't investigate any further as I wanted
> > to know how the broadcom cards performs in transmitting. So for me
> > transmitting power seems to be fine with the broadcom card. My guess for
> > the weaker signal from the 2nd client is ether some active power saving
> > or different propagation conditions.
> >
> > Here are the reported signal strength from the clients (while being
> > connected to the AP):
> > client1 (broadcom): -74 to -75dBm
> > client2 (atheros): -44 to -42dBm
> >
> >
> > So for me this test shows that the card only seems to have problems on
> > receiving packets, transmitting seems to work fine.
> >
> >
> >
> > Additionally I performed a test with the wl driver. I booted an ubuntu
> > live CD and installed the wl driver there. Then I connected to my AP
> > using this driver and tested reception. Everything looked like it was
> > supposed to work. After connecting to the AP I got a reported signal
> > strength of about -38dBm. I then moved away from the AP and was still
> > able to get good connection where before I wasn't able to get any
> > connection at all using the brcmsmac driver.
> >
> >
> >
> > Please let me know if I should perform any additional tests or if you need
> > any additional information.
> >
> >
> > Greetings,
> > Maxi
>
> Hi Maximilian,
>
> poor rx performance is observed on Wifi/Bluetooth combo modules (which
> according to hardware info sent before you have), I'm working on this
> problem.
>
> Is Bluetooth function of the card usable under linux? What about windows?
> Could you send me output of 'lspci -nn'?
>
> Kind regards
> Piotr
Hi Piotr,
Thank you for you reply, it's nice to hear you are working on this.
I don't use any other Bluetooth devices, however I did some tests in the past
and there I was able to find other devices and connect to them, so I think
Bluetooth should be working. I can do some better testing if you think it
might be useful.
However I'm not 100% sure that my wifi card is also used for Bluetooth. I have
the following usb device which seems to be a Blutooth device (see below for
more details):
$ lsusb -s 004:004
Bus 004 Device 004: ID 0a5c:21f4 Broadcom Corp.
I did a test with Windows some time ago and there wifi did work fine. However
I did not test Bluetooth on Windows. As testing with Windows is quite
complicated for me, so I want to avoid it if possible.
You can find the output of 'lspci -nn' below.
$ lsusb
Bus 004 Device 004: ID 0a5c:21f4 Broadcom Corp.
Bus 007 Device 003: ID 5986:0299 Acer, Inc
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lsusb -t
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
|__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=btusb, 12M
|__ Port 3: Dev 4, If 1, Class=Vendor Specific Class, Driver=btusb, 12M
|__ Port 3: Dev 4, If 2, Class=Vendor Specific Class, Driver=, 12M
|__ Port 3: Dev 4, If 3, Class=Application Specific Interface, Driver=, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
$ lsusb -v -s 004:004
Bus 004 Device 004: ID 0a5c:21f4 Broadcom Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 1
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x0a5c Broadcom Corp.
idProduct 0x21f4
bcdDevice 1.12
iManufacturer 1 Broadcom Corp
iProduct 2 BCM20702A0
iSerial 3 C0143DC1809E
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 218
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 0
Device Firmware Upgrade Interface Descriptor:
bLength 9
bDescriptorType 33
bmAttributes 5
Will Not Detach
Manifestation Tolerant
Upload Unsupported
Download Supported
wDetachTimeout 5000 milliseconds
wTransferSize 64 bytes
bcdDFUVersion 1.10
Device Status: 0x0001
Self Powered
$ lspci -nn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Complex [1022:1510]
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7340] [1002:9808]
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler HDMI Audio [1002:1314]
00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Port [1022:1513]
00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Port [1022:1514]
00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Port [1022:1515]
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7812] (rev 03)
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7801]
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11)
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11)
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11)
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11)
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 14)
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller [1022:780d] (rev 01)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:780e] (rev 11)
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge [1022:780f] (rev 40)
00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7809] (rev 11)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 0 [1022:1700] (rev 43)
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 1 [1022:1701]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 2 [1022:1702]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 3 [1022:1703]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 4 [1022:1704]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 6 [1022:1718]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 5 [1022:1716]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 7 [1022:1719]
02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 07)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader [10ec:5209] (rev 01)
Greetings and thanks for your help,
Maxi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware.
From: Kalle Valo @ 2013-07-12 14:51 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, linux-wireless
In-Reply-To: <51DEC9A7.2080207@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 07/11/2013 02:36 AM, Kalle Valo wrote:
>> greearb@candelatech.com writes:
>>
>>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to
>>> + * be cleaned up, but this method is still called a few times. Check
>>> + * for NULL here so we don't crash. Probably a better fix is to stop
>>> + * the ath10k_pci_ce_tasklet sooner.
>>> + */
>>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id))
>>> + return;
>>> +
>>> + ctrl_addr = ce_state->ctrl_addr;
>>> +
>>
>> The tests you add look like workarounds. I would prefer to try fix these
>> by going to the source of the problem. Maybe we should add
>> ath10k_pci_wake() and ath10k_do_pci_wake()?
Doh, dropped an essential word from a sentence, again. That's what I get
when trying to do multiple things at the same time.
What I was trying to say: Maybe we should add proper error hanling to
ath10k_pci_wake() and ath10k_do_pci_wake() and that way avoid this?
> These are work-arounds, but you should not let a bad piece of
> hardware/firmware crash the entire OS just because you don't want to
> do sanity checking on the values you get from the firmware. Perhaps
> there is a better fix for the code above, but the warning splat should
> still provide incentive to get it right, while not crashing the OS in
> the meantime.
Sure, the driver should not crash if HW is not functioning correctly.
I'm just saying that adding odd checks at random places is not the
"kernel way" to do things, only GTK people do that ;)
I was thinking that the proper way is to check that wakeup succeeds and
not enable interrupts or something like that.
>> Can you enable few debug logs, like ATH10K_DBG_PCI, and post them? That
>> would give more hint there things are going wrong.
>
> Yes, I can do that.
Thanks.
Oh, did you mention something that ath10k detect the device as hw2.0?
Maybe the PCI ids are wrong? Then you could also force the same
workaround for hw2.0 as hw1.0 has:
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2145,10 +2145,8 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
switch (pci_dev->device) {
case QCA988X_1_0_DEVICE_ID:
- set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features);
- break;
case QCA988X_2_0_DEVICE_ID:
- set_bit(ATH10K_PCI_FEATURE_MSI_X, ar_pci->features);
+ set_bit(ATH10K_PCI_FEATURE_HW_1_0_WARKAROUND, ar_pci->features);
break;
default:
ret = -ENODEV;
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-12 14:43 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Bing Zhao, linux-wireless@vger.kernel.org
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5951035636368@SC-VEXCH1.marvell.com>
On Fri, Jul 12, 2013 at 7:14 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> Hi Daniel,
>
>> Hmm. Now that I heard back from you and Bing, that interrupts at this
>> point are totally unexpected, I would prefer to see the interrupt
>> handler being disabled at the appropriate time, I think we can do
>> better than my original patch. Let me see if I can find some time
>> today/tomorrow to explore a better approach.
>
>>What about this one?
>
> The patch looks fine to me.
> Some comments
> 1) Unused HOST_INT_DISABLE macro can be removed now.
> 2) if_ops.disable_int() should be called before if_ops.unregister_dev() even in driver load failure code path. Otherwise we will miss to release sdio irq in this case.
> (You can consider applying attached changes on top of your patch for (1) and (2))
>
> 3) Previously we used to have error handling for sdio_claim_irq(). Now we should check return status of if_ops.enable_int(). As I have couple of other patches to handle driver load failure paths correctly, I will take care of this separately.
>
> 4) I will create separate patch to avoid forward declaration of mwifiex_sdio_interrupt() by moving some code.
Thanks for looking at it, all your comments make sense. In your diff
that you provided, I don't understand why you had to modify the
mwifiex_add_card error path to disable the interrupt though. If there
were any failures the interrupt handler will already have been
disabled by your fixes to the mwifiex_fw_dpc() error handling path,
right?
Daniel
^ permalink raw reply
* Re: Poor wireless reception on BCM4313
From: Piotr Haber @ 2013-07-12 13:47 UTC (permalink / raw)
To: Maximilian Engelhardt; +Cc: brcm80211-dev-list, linux-wireless
In-Reply-To: <30534146.LWDmOHhHCG@eisbaer>
On 07/12/13 14:55, Maximilian Engelhardt wrote:
> On Friday 21 June 2013 20:26:25 Maximilian Engelhardt wrote:
>> Hello developers,
>>
>> I'm having problems with the reception performance of my BCM4313 wireless
>> card. The card is basically working fine, but the reception is quite bad
>> compared to other wifi equipment. I first suspected a hardware problem, but
>> after I tried Windows 7 with the same hardware and having no problem there
>> I'm quite sure this is a software issue.
>>
>>
>> Here is a more detailed explanation of a test setup I performed to show the
>> problem:
>>
>> I have an AP in about 2m distance and I connected to it by my BCM4313 card
>> and by a USB dongle (TP-Link TL-WN821N, using ath9k_htc). Both connections
>> work and I can ping the AP using both cards.
>>
>> iw dev $DEV link shows a signal of about -68 dBm for the broadcom card and
>> about -51 dBm for the atheros dongle. I have no idea in how far one can
>> trust these values, but the difference between these two cards mostly seems
>> to be 20-30 dB, also in my further experiments (greater distance from the
>> AP).
>>
>> Now with both dongles being connected I move my laptop away from the AP and
>> of course the signal is getting weaker. However at some point the broadcom
>> card looses the connection to the AP while the USB dongle still has good
>> connection (at this point the signal strength of the broadcom card is about
>> -90dBm and -60dBm for the USB dongle). In my test with the Windows driver
>> at that point the connection was still good and maximum distance till I
>> lost the connection was much larger. So I don't think is a hardware
>> problem.
>>
>> In general I can say my BCM4313 card is only usable when I'm in vicinity of
>> the AP. If I move further away the connection becomes unusable slow or is
>> lost, while it is still working well using other cards/drivers.
>>
>>
>> I'm currently using a 3.10-rc5 kernel with Debian jessie (kernel is from
>> experimental, but the same behavior has been there with kernel 3.9, 3.8 (and
>> older)). The driver used for the broadcom card is brcmsmac.
>>
>>
>> I did a search non the Internet regarding this issue and found some other
>> people having the same problem but no real solution to this. There is a
>> workaround some Ubuntu related sites, which consists of blacklisting the
>> brcmsmac driver and installing the wl driver. With the wl driver this
>> problem seems to be fixed according to the web (I didn't try it myself).
>>
>> As I have no idea where this problem could be and how I can debug it, so I'm
>> writing this mail now. If you need any addition information I'm happy to
>> provide it.
>> From the numbers shown above it seems like there is an attenuator of 20-30dB
>> active on the receiver of the broadcom card.
>>
> [...]
>
>
> Hello,
>
> Is there any progress on this issue?
> Here are the results of some additional test I performed.
>
>
> I set up a AP (11g) and connected two client to it. The clients were my
> bcm4313 wireless card and the TP-Link TL-WN821N USB dongle which was connected
> to the laptop with the broadcom card. I connected both cards to the AP. The
> distance between the cards and the AP was about 3m.
> Then I set up another wireless card (TP-WN722N) in monitor mode about 3m away
> from the AP and about 3m away from the laptop with the two wireless cards.
> This card was connected to a different PC and I captured the data of the
> clients and the AP. I then had a look at the reported SSI. You can see my
> measured results below:
>
> SSI for packets from the AP: -27 to -23dBm
> SSI for packets from client1 (broadcom): -20 to -14dBm
> SSI for packets from client2 (atheros): -40 to -38dBm
>
> The received signal from the broadcom card were quite strong. The signal from
> the AP was a bit weaker. Interestingly the signal from the second card was
> noticeably weaker. I didn't investigate any further as I wanted to know how
> the broadcom cards performs in transmitting. So for me transmitting power
> seems to be fine with the broadcom card. My guess for the weaker signal from
> the 2nd client is ether some active power saving or different propagation
> conditions.
>
> Here are the reported signal strength from the clients (while being connected
> to the AP):
> client1 (broadcom): -74 to -75dBm
> client2 (atheros): -44 to -42dBm
>
>
> So for me this test shows that the card only seems to have problems on
> receiving packets, transmitting seems to work fine.
>
>
>
> Additionally I performed a test with the wl driver. I booted an ubuntu live CD
> and installed the wl driver there. Then I connected to my AP using this driver
> and tested reception. Everything looked like it was supposed to work. After
> connecting to the AP I got a reported signal strength of about -38dBm. I then
> moved away from the AP and was still able to get good connection where before
> I wasn't able to get any connection at all using the brcmsmac driver.
>
>
>
> Please let me know if I should perform any additional tests or if you need any
> additional information.
>
>
> Greetings,
> Maxi
Hi Maximilian,
poor rx performance is observed on Wifi/Bluetooth combo modules (which according to hardware info
sent before you have), I'm working on this problem.
Is Bluetooth function of the card usable under linux? What about windows?
Could you send me output of 'lspci -nn'?
Kind regards
Piotr
^ permalink raw reply
* 802.11 MAC fails
From: Barlow-Bignell, James @ 2013-07-12 13:37 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hiya
Does anyone familiar with the 802.11 mac code know what the kernel currently does with frames which fail to send after reaching the re-transmit limit?
I would imagine that either the mac layer reports the failure to the upper layer (e.g. TCP), or the failure is simply swallowed and upper layers should rely on ACK timeouts if necessary.
Many thanks
^ permalink raw reply
* Re: interested in py80211?
From: Arend van Spriel @ 2013-07-12 13:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Thomas Graf
In-Reply-To: <1373616129.8205.2.camel@jlt4.sipsolutions.net>
On 07/12/13 10:02, Johannes Berg wrote:
> Yep, I'd totally be interested. Not that I don't have enough things on
> my plate already ;-)
>
> On Wed, 2013-07-03 at 22:57 +0200, Arend van Spriel wrote:
>> A common say in Linux arena is "when you have an itch, just scratch it".
>
> :-)
>
>> My itch is that tools like ifconfig and iw are great, but in an
>> automated test environment it kind of sucks to parse output, which is
>> confirmed by blurb from iw: "Do NOT screenscrape this tool, we don't
>> consider its output stable.".
>
> Heh, yeah ...
>
>> Ever since my first contact with Python I tend to favor it over other
>> scripting alternatives so I decided to scratch my itch with that and
>> another old acquaintance called SWIG. With those I went to create
>> py80211. A first attempt was to have SWIG create a wrapper API directly
>> exposing the libnl-3 API, but that did not feel comfortable in a
>> scripting environment. So the level of abstraction is a bit higher. It
>> is just in a kick-off state (eg. can only send u32 attributes), but I
>> decided to push it to github anyway.
>
> Another approach might be exposing the libnl APIs and then build a
> higher-level library in python. Have you considered that? That might
> make it useful to other users of netlink as well, while keeping a 'nice'
> nl80211 API?
I am still at that fork in the road and not sure about it. The libnl
project itself already has libnl stuff exposed in a python lib being the
core api and route. So I could go and add genl support to that and build
the high-level python library from there.
Regards,
Arend
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-12 13:14 UTC (permalink / raw)
To: 'Daniel Drake'; +Cc: Bing Zhao, linux-wireless@vger.kernel.org
In-Reply-To: <CAMLZHHSFEoOJ3W+nyJUqzGTKy=8TEB6mSibrXN6ze1xzGHv35Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
Hi Daniel,
> Hmm. Now that I heard back from you and Bing, that interrupts at this
> point are totally unexpected, I would prefer to see the interrupt
> handler being disabled at the appropriate time, I think we can do
> better than my original patch. Let me see if I can find some time
> today/tomorrow to explore a better approach.
>What about this one?
The patch looks fine to me.
Some comments
1) Unused HOST_INT_DISABLE macro can be removed now.
2) if_ops.disable_int() should be called before if_ops.unregister_dev() even in driver load failure code path. Otherwise we will miss to release sdio irq in this case.
(You can consider applying attached changes on top of your patch for (1) and (2))
3) Previously we used to have error handling for sdio_claim_irq(). Now we should check return status of if_ops.enable_int(). As I have couple of other patches to handle driver load failure paths correctly, I will take care of this separately.
4) I will create separate patch to avoid forward declaration of mwifiex_sdio_interrupt() by moving some code.
Regards,
Amitkumar Karwar
[-- Attachment #2: minor_corrections.diff --]
[-- Type: application/octet-stream, Size: 1353 bytes --]
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 2083cf8..28617d6 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -482,6 +482,8 @@ err_add_intf:
mwifiex_del_virtual_intf(adapter->wiphy, priv->wdev);
rtnl_unlock();
err_init_fw:
+ if (adapter->if_ops.disable_int)
+ adapter->if_ops.disable_int(adapter);
pr_debug("info: %s: unregister device\n", __func__);
adapter->if_ops.unregister_dev(adapter);
done:
@@ -874,6 +876,8 @@ mwifiex_add_card(void *card, struct semaphore *sem,
return 0;
err_init_fw:
+ if (adapter->if_ops.disable_int)
+ adapter->if_ops.disable_int(adapter);
pr_debug("info: %s: unregister device\n", __func__);
if (adapter->if_ops.unregister_dev)
adapter->if_ops.unregister_dev(adapter);
diff --git a/drivers/net/wireless/mwifiex/sdio.h b/drivers/net/wireless/mwifiex/sdio.h
index 6d51dfd..532ae0a 100644
--- a/drivers/net/wireless/mwifiex/sdio.h
+++ b/drivers/net/wireless/mwifiex/sdio.h
@@ -92,9 +92,6 @@
/* Host Control Registers : Download host interrupt mask */
#define DN_LD_HOST_INT_MASK (0x2U)
-/* Disable Host interrupt mask */
-#define HOST_INT_DISABLE 0xff
-
/* Host Control Registers : Host interrupt status */
#define HOST_INTSTATUS_REG 0x03
/* Host Control Registers : Upload host interrupt status */
^ permalink raw reply related
* Re: Poor wireless reception on BCM4313
From: Maximilian Engelhardt @ 2013-07-12 12:55 UTC (permalink / raw)
To: brcm80211-dev-list; +Cc: linux-wireless
In-Reply-To: <1624172.s6pnfBcJL7@fuchs>
[-- Attachment #1: Type: text/plain, Size: 4955 bytes --]
On Friday 21 June 2013 20:26:25 Maximilian Engelhardt wrote:
> Hello developers,
>
> I'm having problems with the reception performance of my BCM4313 wireless
> card. The card is basically working fine, but the reception is quite bad
> compared to other wifi equipment. I first suspected a hardware problem, but
> after I tried Windows 7 with the same hardware and having no problem there
> I'm quite sure this is a software issue.
>
>
> Here is a more detailed explanation of a test setup I performed to show the
> problem:
>
> I have an AP in about 2m distance and I connected to it by my BCM4313 card
> and by a USB dongle (TP-Link TL-WN821N, using ath9k_htc). Both connections
> work and I can ping the AP using both cards.
>
> iw dev $DEV link shows a signal of about -68 dBm for the broadcom card and
> about -51 dBm for the atheros dongle. I have no idea in how far one can
> trust these values, but the difference between these two cards mostly seems
> to be 20-30 dB, also in my further experiments (greater distance from the
> AP).
>
> Now with both dongles being connected I move my laptop away from the AP and
> of course the signal is getting weaker. However at some point the broadcom
> card looses the connection to the AP while the USB dongle still has good
> connection (at this point the signal strength of the broadcom card is about
> -90dBm and -60dBm for the USB dongle). In my test with the Windows driver
> at that point the connection was still good and maximum distance till I
> lost the connection was much larger. So I don't think is a hardware
> problem.
>
> In general I can say my BCM4313 card is only usable when I'm in vicinity of
> the AP. If I move further away the connection becomes unusable slow or is
> lost, while it is still working well using other cards/drivers.
>
>
> I'm currently using a 3.10-rc5 kernel with Debian jessie (kernel is from
> experimental, but the same behavior has been there with kernel 3.9, 3.8 (and
> older)). The driver used for the broadcom card is brcmsmac.
>
>
> I did a search non the Internet regarding this issue and found some other
> people having the same problem but no real solution to this. There is a
> workaround some Ubuntu related sites, which consists of blacklisting the
> brcmsmac driver and installing the wl driver. With the wl driver this
> problem seems to be fixed according to the web (I didn't try it myself).
>
> As I have no idea where this problem could be and how I can debug it, so I'm
> writing this mail now. If you need any addition information I'm happy to
> provide it.
> From the numbers shown above it seems like there is an attenuator of 20-30dB
> active on the receiver of the broadcom card.
>
[...]
Hello,
Is there any progress on this issue?
Here are the results of some additional test I performed.
I set up a AP (11g) and connected two client to it. The clients were my
bcm4313 wireless card and the TP-Link TL-WN821N USB dongle which was connected
to the laptop with the broadcom card. I connected both cards to the AP. The
distance between the cards and the AP was about 3m.
Then I set up another wireless card (TP-WN722N) in monitor mode about 3m away
from the AP and about 3m away from the laptop with the two wireless cards.
This card was connected to a different PC and I captured the data of the
clients and the AP. I then had a look at the reported SSI. You can see my
measured results below:
SSI for packets from the AP: -27 to -23dBm
SSI for packets from client1 (broadcom): -20 to -14dBm
SSI for packets from client2 (atheros): -40 to -38dBm
The received signal from the broadcom card were quite strong. The signal from
the AP was a bit weaker. Interestingly the signal from the second card was
noticeably weaker. I didn't investigate any further as I wanted to know how
the broadcom cards performs in transmitting. So for me transmitting power
seems to be fine with the broadcom card. My guess for the weaker signal from
the 2nd client is ether some active power saving or different propagation
conditions.
Here are the reported signal strength from the clients (while being connected
to the AP):
client1 (broadcom): -74 to -75dBm
client2 (atheros): -44 to -42dBm
So for me this test shows that the card only seems to have problems on
receiving packets, transmitting seems to work fine.
Additionally I performed a test with the wl driver. I booted an ubuntu live CD
and installed the wl driver there. Then I connected to my AP using this driver
and tested reception. Everything looked like it was supposed to work. After
connecting to the AP I got a reported signal strength of about -38dBm. I then
moved away from the AP and was still able to get good connection where before
I wasn't able to get any connection at all using the brcmsmac driver.
Please let me know if I should perform any additional tests or if you need any
additional information.
Greetings,
Maxi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: fix regression when initializing ibss wmm params
From: Johannes Berg @ 2013-07-12 11:59 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1373558866-5756-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Thu, 2013-07-11 at 18:07 +0200, Simon Wunderlich wrote:
> There appear to be two regressions in ibss.c when calling
> ieee80211_sta_def_wmm_params():
> * the second argument should be a rate length, not a rate array. This
> was introduced by my commit "mac80211: select and adjust bitrates
> according to channel mode"
> * the third argument is not initialized (anymore), making further
> checks within this function useless.
>
> Since ieee80211_sta_def_wmm_params() is only used by ibss anyway,
> remove the function entirely and handle the operating mode decision
> immediately.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix off-by-one regression in ibss beacon generation
From: Johannes Berg @ 2013-07-12 11:59 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Simon Wunderlich
In-Reply-To: <1373567389-6287-1-git-send-email-siwu@hrz.tu-chemnitz.de>
On Thu, 2013-07-11 at 20:29 +0200, Simon Wunderlich wrote:
> There is an off-by-one error in the beacon generation for the ibss mode,
> falsely a rate the extended supported rates which was already added to
> supported rates, messing up the beacon. This was introduced by commit
> "mac80211: select and adjust bitrates according to channel mode".
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: set the forwading in mesh capability info accordingly
From: Johannes Berg @ 2013-07-12 11:58 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1373626522-19486-1-git-send-email-yeohchunyeow@gmail.com>
On Fri, 2013-07-12 at 18:55 +0800, Chun-Yeow Yeoh wrote:
> Set the Forwarding bit in Mesh Capability Info according
> to dot11MeshForwarding as defined in IEEE 802.11-2012
> section 8.4.2.100.8.
Applied (with typo in subject fixed)
johannes
^ permalink raw reply
* hung task while plugging in cfg80211
From: Jeff Layton @ 2013-07-12 11:49 UTC (permalink / raw)
To: linux-wireless, linville
I updated the kernel on my rawhide KVM guest, and noticed that the
ethernet interface wasn't coming up at all. While poking around, I saw
this stack trace pop up:
Jul 12 07:29:25 rawhide kernel: [ 241.156196] INFO: task modprobe:501 blocked for more than 120 seconds.
Jul 12 07:29:25 rawhide kernel: [ 241.157222] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 12 07:29:25 rawhide kernel: [ 241.158379] modprobe D ffff880118c526e0 4584 501 500 0x00000080
Jul 12 07:29:25 rawhide kernel: [ 241.159458] ffff8800d10c3ba8 0000000000000046 00000000001d5300 ffff8800d10c3fd8
Jul 12 07:29:25 rawhide kernel: [ 241.160644] ffff8800d10c3fd8 00000000001d5300 ffff8800d2ae4dc0 ffff8800d2ae4dc0
Jul 12 07:29:25 rawhide kernel: [ 241.161875] ffffffff81d0bfa0 ffffffff81d0bfa8 ffffffff00000000 ffffffff81d0bff0
Jul 12 07:29:25 rawhide kernel: [ 241.163096] Call Trace:
Jul 12 07:29:25 rawhide kernel: [ 241.163460] [<ffffffff817377e9>] schedule+0x29/0x70
Jul 12 07:29:25 rawhide kernel: [ 241.164235] [<ffffffff817392ad>] rwsem_down_write_failed+0xed/0x1a0
Jul 12 07:29:25 rawhide kernel: [ 241.165489] [<ffffffff810bb600>] ? update_cpu_load_active+0xb0/0xb0
Jul 12 07:29:25 rawhide kernel: [ 241.166267] [<ffffffff8137d503>] call_rwsem_down_write_failed+0x13/0x20
Jul 12 07:29:25 rawhide kernel: [ 241.166760] [<ffffffff81736aad>] ? down_write+0x9d/0xb2
Jul 12 07:29:25 rawhide kernel: [ 241.167189] [<ffffffff8162d975>] ? genl_lock_all+0x15/0x30
Jul 12 07:29:25 rawhide kernel: [ 241.167603] [<ffffffff8162d975>] genl_lock_all+0x15/0x30
Jul 12 07:29:25 rawhide kernel: [ 241.168036] [<ffffffff8162ea83>] genl_register_family+0x53/0x1f0
Jul 12 07:29:25 rawhide kernel: [ 241.168490] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.168877] [<ffffffff8162f520>] genl_register_family_with_ops+0x20/0x80
Jul 12 07:29:25 rawhide kernel: [ 241.169406] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.169802] [<ffffffffa0101ec4>] nl80211_init+0x24/0xf0 [cfg80211]
Jul 12 07:29:25 rawhide kernel: [ 241.170297] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.170686] [<ffffffffa015e043>] cfg80211_init+0x43/0xdb [cfg80211]
Jul 12 07:29:25 rawhide kernel: [ 241.171230] [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0
Jul 12 07:29:25 rawhide kernel: [ 241.171651] [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50
Jul 12 07:29:25 rawhide kernel: [ 241.172099] [<ffffffff810fa2bf>] load_module+0x1c6f/0x27f0
Jul 12 07:29:25 rawhide kernel: [ 241.172515] [<ffffffff810f59a0>] ? store_uevent+0x40/0x40
Jul 12 07:29:25 rawhide kernel: [ 241.172933] [<ffffffff810fafd6>] SyS_finit_module+0x86/0xb0
Jul 12 07:29:25 rawhide kernel: [ 241.173379] [<ffffffff81744019>] system_call_fastpath+0x16/0x1b
...on a hunch, I blacklisted the cfg80211 module, and that seems to
have worked around the problem for now. I suspect that NM was trying to
plug in this module and it hung, and it couldn't proceed any further to
configure the virtual ethernet interface.
In the fedora rawhide kernels, last known good one is
kernel-3.11.0-0.rc0.git3.1.fc20, and bad one is
kernel-3.11.0-0.rc0.git6.1.fc20. I haven't bisected it further.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* [PATCH] iw: print out mesh configuration element on scan
From: Chun-Yeow Yeoh @ 2013-07-12 11:17 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Chun-Yeow Yeoh
Print out mesh configuration element which will be useful for
decision making whether to join or not join the mesh network.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
---
scan.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index 6d770d3..4fb0f23 100644
--- a/scan.c
+++ b/scan.c
@@ -787,6 +787,37 @@ static void print_bss_load(const uint8_t type, uint8_t len, const uint8_t *data)
printf("\t\t * available admission capacity: %d [*32us]\n", (data[4] << 8) | data[3]);
}
+static void print_mesh_conf(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ printf("\n");
+ printf("\t\t * Active Path Selection Protocol ID: %d\n", data[0]);
+ printf("\t\t * Active Path Selection Metric ID: %d\n", data[1]);
+ printf("\t\t * Congestion Control Mode ID: %d\n", data[2]);
+ printf("\t\t * Synchronization Method ID: %d\n", data[3]);
+ printf("\t\t * Authentication Protocol ID: %d\n", data[4]);
+ printf("\t\t * Mesh Formation Info:\n");
+ printf("\t\t\t Number of Peerings: %d\n", (data[5] & 0x7E) >> 1);
+ if (data[5] & 0x01)
+ printf("\t\t\t Connected to Mesh Gate\n");
+ if (data[5] & 0x80)
+ printf("\t\t\t Connected to AS\n");
+ printf("\t\t * Mesh Capability\n");
+ if (data[6] & 0x01)
+ printf("\t\t\t Accepting Additional Mesh Peerings\n");
+ if (data[6] & 0x02)
+ printf("\t\t\t MCCA Supported\n");
+ if (data[6] & 0x04)
+ printf("\t\t\t MCCA Enabled\n");
+ if (data[6] & 0x08)
+ printf("\t\t\t Forwarding\n");
+ if (data[6] & 0x10)
+ printf("\t\t\t MBCA Supported\n");
+ if (data[6] & 0x20)
+ printf("\t\t\t TBTT Adjusting\n");
+ if (data[6] & 0x40)
+ printf("\t\t\t Mesh Power Save Level\n");
+}
+
struct ie_print {
const char *name;
void (*print)(const uint8_t type, uint8_t len, const uint8_t *data);
@@ -846,6 +877,7 @@ static const struct ie_print ieprinters[] = {
[192] = { "VHT operation", print_vht_oper, 5, 255, BIT(PRINT_SCAN), },
[48] = { "RSN", print_rsn, 2, 255, BIT(PRINT_SCAN), },
[50] = { "Extended supported rates", print_supprates, 0, 255, BIT(PRINT_SCAN), },
+ [113] = { "MESH Configuration", print_mesh_conf, 7, 7, BIT(PRINT_SCAN), },
[114] = { "MESH ID", print_ssid, 0, 32, BIT(PRINT_SCAN) | BIT(PRINT_LINK), },
[127] = { "Extended capabilities", print_capabilities, 0, 255, BIT(PRINT_SCAN), },
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH] mac80211: set the forwading in mesh capability info accordingly
From: Chun-Yeow Yeoh @ 2013-07-12 10:55 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh
Set the Forwarding bit in Mesh Capability Info according
to dot11MeshForwarding as defined in IEEE 802.11-2012
section 8.4.2.100.8.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
---
net/mac80211/mesh.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index e536f22..885a5f6 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -273,7 +273,9 @@ int mesh_add_meshconf_ie(struct ieee80211_sub_if_data *sdata,
neighbors = min_t(int, neighbors, IEEE80211_MAX_MESH_PEERINGS);
*pos++ = neighbors << 1;
/* Mesh capability */
- *pos = IEEE80211_MESHCONF_CAPAB_FORWARDING;
+ *pos = 0x00;
+ *pos |= ifmsh->mshcfg.dot11MeshForwarding ?
+ IEEE80211_MESHCONF_CAPAB_FORWARDING : 0x00;
*pos |= ifmsh->accepting_plinks ?
IEEE80211_MESHCONF_CAPAB_ACCEPT_PLINKS : 0x00;
/* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ath10k: pass also QOS Null frames through mgmt tx path
From: Janusz Dziedzic @ 2013-07-12 10:25 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Janusz Dziedzic
Fw will report wrong tx status for QOS Null frames
sent through data tx path.
This patch fixes station(s) keep alive detection
triggered from wpa_supplicant/hostapd when work
as AP/GO and WMM enabled.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index da5c333..81b1a4b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1398,11 +1398,15 @@ static void ath10k_tx_htt(struct ath10k *ar, struct sk_buff *skb)
if (ieee80211_is_mgmt(hdr->frame_control))
ret = ath10k_htt_mgmt_tx(ar->htt, skb);
- else if (ieee80211_is_nullfunc(hdr->frame_control))
- /* FW does not report tx status properly for NullFunc frames
- * unless they are sent through mgmt tx path. mac80211 sends
- * those frames when it detects link/beacon loss and depends on
- * the tx status to be correct. */
+ else if (ieee80211_is_nullfunc(hdr->frame_control) ||
+ ieee80211_is_qos_nullfunc(hdr->frame_control))
+ /* FW does not report tx status properly for NullFunc and
+ * QOS NullFunc frames unless they are sent through mgmt
+ * tx path. mac80211 sends those frames when it detects
+ * link/beacon loss and depends on the tx status to be
+ * correct. mac80211 also send those frames when probe_client
+ * in case of AP/GO mode.
+ */
ret = ath10k_htt_mgmt_tx(ar->htt, skb);
else
ret = ath10k_htt_tx(ar->htt, skb);
--
1.7.9.5
^ permalink raw reply related
* Re: interested in py80211?
From: Johannes Berg @ 2013-07-12 8:02 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51D49027.9010803@broadcom.com>
Yep, I'd totally be interested. Not that I don't have enough things on
my plate already ;-)
On Wed, 2013-07-03 at 22:57 +0200, Arend van Spriel wrote:
> A common say in Linux arena is "when you have an itch, just scratch it".
:-)
> My itch is that tools like ifconfig and iw are great, but in an
> automated test environment it kind of sucks to parse output, which is
> confirmed by blurb from iw: "Do NOT screenscrape this tool, we don't
> consider its output stable.".
Heh, yeah ...
> Ever since my first contact with Python I tend to favor it over other
> scripting alternatives so I decided to scratch my itch with that and
> another old acquaintance called SWIG. With those I went to create
> py80211. A first attempt was to have SWIG create a wrapper API directly
> exposing the libnl-3 API, but that did not feel comfortable in a
> scripting environment. So the level of abstraction is a bit higher. It
> is just in a kick-off state (eg. can only send u32 attributes), but I
> decided to push it to github anyway.
Another approach might be exposing the libnl APIs and then build a
higher-level library in python. Have you considered that? That might
make it useful to other users of netlink as well, while keeping a 'nice'
nl80211 API?
johannes
^ 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