* [ath9k-devel] DMA issues with ar9280 cards
@ 2011-02-23 15:34 Bernhard Schmidt
2011-02-23 16:22 ` Peter Stuge
0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Schmidt @ 2011-02-23 15:34 UTC (permalink / raw)
To: ath9k-devel
Hi,
[resend, due to ehlo/MX being checked case sensitive]
I have some issues using any of my AR9280 cards, identified as:
- Ubiquiti SR71E
[ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11
- Sparklan WPEA-110N
[ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11
On a recent wireless-testing kernel:
# uname -a
% Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux
I see this behaviour:
# hostapd /etc/hostapd.conf
% scan due to ht40
[ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
..
% scan done, setting up the BSS
[ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 296.083032] ath: Failed to stop TX DMA!
[ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
% ..
A monitor mode vif on another interface tells me that on average only
6 beacons leave the device before it's going deaf. Restarting hostapd
will make it send another 6 beacons. Behaviour in sta mode is similar
unusable, if I'm lucky enough to get any scan results the connect fails
or it goes deaf after the first few packets have been transmitted.
I tried a few different kernel version back to 2.6.36.4 which all have
the same behaviour (except the error messages, which have been mask
till lately). Also, this issue seems to be only seen on AR9820, all
other chips I have (9160, 9220, 93xx) work as expected.
Felix already told me that this is a known issue and going over other
reports on this list and linux-wireless-ml it indeed is. Just wanted
to know if there is any "known-good" kernel version or a workaround
for that?
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 15:34 [ath9k-devel] DMA issues with ar9280 cards Bernhard Schmidt
@ 2011-02-23 16:22 ` Peter Stuge
2011-02-23 18:02 ` Luis R. Rodriguez
0 siblings, 1 reply; 26+ messages in thread
From: Peter Stuge @ 2011-02-23 16:22 UTC (permalink / raw)
To: ath9k-devel
Bernhard Schmidt wrote:
> Felix already told me that this is a known issue and going over other
> reports on this list and linux-wireless-ml it indeed is. Just wanted
> to know if there is any "known-good" kernel version or a workaround
> for that?
I fear you will not get any further info on this mailing list. I would
suggest to watch the l-w list and try any patches that are sent there.
They never appear here and there's also no discussion here. Thinking
about it I actually don't really understand the purpose of this list.
It's mostly disinforming, in that it detracts from l-w, which seems
to be the more significant forum for ath9k development.
//Peter
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 16:22 ` Peter Stuge
@ 2011-02-23 18:02 ` Luis R. Rodriguez
2011-02-23 19:51 ` Peter Stuge
0 siblings, 1 reply; 26+ messages in thread
From: Luis R. Rodriguez @ 2011-02-23 18:02 UTC (permalink / raw)
To: ath9k-devel
On Wed, Feb 23, 2011 at 08:22:30AM -0800, Peter Stuge wrote:
> Bernhard Schmidt wrote:
> > Felix already told me that this is a known issue and going over other
> > reports on this list and linux-wireless-ml it indeed is. Just wanted
> > to know if there is any "known-good" kernel version or a workaround
> > for that?
>
> I fear you will not get any further info on this mailing list. I would
> suggest to watch the l-w list and try any patches that are sent there.
>
> They never appear here and there's also no discussion here. Thinking
> about it I actually don't really understand the purpose of this list.
> It's mostly disinforming, in that it detracts from l-w, which seems
> to be the more significant forum for ath9k development.
Would you stop trolling, really. I told you what you can do to help
with resolving observed issues, where are your bug reports BTW? Trust
me that people are reading these lists, and issues do get fixed, for
some reason however *you* are not getting your issues resolved. Have
you ever stopped to really consider perhaps its not *us* and that you
can likely consider some changes on your behalf to work better with
our teams who *are* engaged in fixing issues. Your focus is to say
you are very well experienced but don't want to hack.. fine but,
given your experience you should be able to work even further with
devlopers, but that's not happening, why? Because *you* are expecting
people to simply read every e-mail rant from you digged into other
people's replies.
Make this simple, split all of your issues, document them into
bug reports for a specific kernel release, help see if you can identify
them as regressions, etc.
Have you done all this?
LUis
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 18:02 ` Luis R. Rodriguez
@ 2011-02-23 19:51 ` Peter Stuge
0 siblings, 0 replies; 26+ messages in thread
From: Peter Stuge @ 2011-02-23 19:51 UTC (permalink / raw)
To: ath9k-devel
Luis R. Rodriguez wrote:
> > I fear you will not get any further info on this mailing list. I would
> > suggest to watch the l-w list and try any patches that are sent there.
> >
> > They never appear here and there's also no discussion here. Thinking
> > about it I actually don't really understand the purpose of this list.
> > It's mostly disinforming, in that it detracts from l-w, which seems
> > to be the more significant forum for ath9k development.
>
> Would you stop trolling, really.
I'm sorry you feel it is trolling, and not constructive criticism.
> I told you what you can do to help with resolving observed issues,
> where are your bug reports BTW?
I told you a few times by now why I can't really file the kind of bug
reports for my issues that I believe you want.
If I filed bug reports they would lack any useful information, and as
has happened the oneor two times that I tried, they would likely be
closed without much investigation or discussion.
That's useless, so I'm saving everyone the time until there is
something concrete to put into the bug report. What would be useful
meanwhile is to discuss particulars of hardware and driver so that I
could help find the actual problem.
> Trust me that people are reading these lists,
I have no doubt about that. What disappoints me is the lack of
duplex communication. Open discussion. Two-way. Sharing. There's
not much of that. There can be plenty of reasons, but regardless
of why, the situation makes me sad and a little bit bitter. :\
> and issues do get fixed,
I also have no doubt about that. But from following this list for
well over a year it is clear to me that nearly nothing gets fixed
*here* which is why I pointed out to Bernard that l-w is a better
place to look for patches, and thus probably also discussion, even
though this is an ath9k list. You yourself pointed me to l-w, and
it matches my experience.
> for some reason however *you* are not getting your issues resolved.
> Have you ever stopped to really consider perhaps its not *us* and
> that you can likely consider some changes on your behalf to work
> better with our teams who *are* engaged in fixing issues.
I don't have to stop and consider to see why there is not much
progress; my issues are a f*ing pain in the ass to work with,
especially remotely, and even more so if you're on the vendor side
and gagged by NDAs. This is not a reason to throw the fight IMO, and
why I am still on this list and still have the card in my machine.
If I just wanted to get work done I would have thrown ath9k far f-ing
away from my laptop long long ago.
> Your focus is to say you are very well experienced but don't want
> to hack..
I'm afraid you misunderstood. I never said I don't want to hack, but
I said that I don't have time to really dig into the complete driver,
and that this means that in order to help nail these issues I will
need help from someone who is knowledgeable about both hardware and
driver. Your teams seem like they would fit that perfectly, but they
would need to spend some time focusing on the problem(s) together
with me, and this seems not to be their modus operandi. Jouni is the
exception so far.
> given your experience you should be able to work even further with
> devlopers, but that's not happening, why?
It's difficult to say because I don't know what your teams are
thinking. The questions I got back from Jouni not long ago I would
love to pursue, but unfortunately that PCI problem I mentioned again
yesterday is effectively blocking ath9k from even seeing the card.
> Because *you* are expecting people to simply read every e-mail rant
> from you digged into other people's replies.
I try to combine my rants with something useful by now. This list is
short on answers in my experience, and I try to not be a part of that
problem, even if the answer is just to divert attention elsewhere, in
this case to l-w.
> Make this simple, split all of your issues, document them into
> bug reports for a specific kernel release, help see if you can
> identify them as regressions, etc.
>
> Have you done all this?
I tried it once for my disconnect problem with the 5414 card,
actually someone else had already opened a bug for that, but it got
closed prematurely when you thought the issue had some satisfactory
resolution. Basically I gave up on that bug for now because the right
kind of questions weren't being asked and because I could not get
data out of driver to confirm my speculation which might be required.
I have explained at least once, but probably several times by now,
why I really can't do all what you ask, for most if not all my issues.
In particular I have never had a good system with ath9k, so I can't
bisect and I can't consider anything a regression.
The PCI thing I could file and if it would help of course I'll do
that, but I'd think discussion on this list could be more efficient
as a start. That's how it is in many other projects. And there is
some already, over in the other thread, so let's go there.
//Peter
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-26 9:37 ` Bernhard Schmidt
@ 2011-03-10 0:40 ` Felix Fietkau
0 siblings, 0 replies; 26+ messages in thread
From: Felix Fietkau @ 2011-03-10 0:40 UTC (permalink / raw)
To: ath9k-devel
On 2011-02-26 10:37 AM, Bernhard Schmidt wrote:
> On Friday 25 February 2011 18:12:09 Luis R. Rodriguez wrote:
>> On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote:
>> > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote:
>> > > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote:
>> > > > I've stripped everything not necessary, this one is use for the
>> > > > log below.
>> > > >
>> > > > # cat /etc/hostapd.conf
>> > > > interface=wlan0
>> > > > driver=nl80211
>> > > > ssid=testtest
>> > > > hw_mode=a
>> > > > channel=44
>> > > >
>> > > > [ 574.605956] ath: Enable TXE on queue: 9
>> > > > [ 574.708386] ath: Enable TXE on queue: 9
>> > > > [ 574.810752] ath: Enable TXE on queue: 9
>> > > > [ 574.913151] ath: Enable TXE on queue: 9
>> > > > [ 575.015541] ath: Enable TXE on queue: 9
>> > > > [ 575.117938] ath: Enable TXE on queue: 9
>> > > > [ 575.220335] ath: Enable TXE on queue: 9
>> > > > [ 575.322732] ath: Enable TXE on queue: 9
>> > > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX
>> > > > Frames 1 on Q 9 [ 576.259188] ath: Failed to stop TX DMA in
>> > > > 100 msec after killing last frame
>> > >
>> > > Can you confirm what kernel ?
>> > >
>> > > I see 2.6.38-rc6-wl-12466-g09f3227
>> > >
>> > > So I take it you are using wireless-testing, is this right? Can
>> > > you reproduce with wireless-testing as of today? This would be
>> > > helpful for our own testing.
>> >
>> > Yes, the logs were posted using wireless-testing, always pulled
>> > before doing the tests.
>> >
>> > Just to confirm, with wireless-testing as of a few minutes ago,
>> > same behavior.
>> >
>> > # uname -a
>> > Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25
>> > 10:19:49 CET 2011 i686 GNU/Linux # git log --pretty=oneline | head
>> > -n1
>> > 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge
>> > ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless
>> > -next-2.6
>> >
>> > [ 176.675020] ath: Enable TXE on queue: 9
>> > [ 176.777416] ath: Enable TXE on queue: 9
>> > [ 176.827134] ath: qnum: 0, txq depth: 0
>> > [ 176.831007] ath: Enable TXE on queue: 0
>> > [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4
>> > [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4
>> > [ 176.879857] ath: Enable TXE on queue: 9
>> > [ 176.982217] ath: Enable TXE on queue: 9
>> > ..
>> > [ 202.786342] ath: Enable TXE on queue: 9
>> > [ 202.888732] ath: Enable TXE on queue: 9
>> > [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1
>> > on Q 9 [ 203.825260] ath: Failed to stop TX DMA in 100 msec after
>> > killing last frame
>> >
>> > [ 203.836898] ath: Reset TX queue: 0
>> > [ 203.840352] ath: Reset TX queue: 1
>> > [ 203.843794] ath: Reset TX queue: 2
>> > [ 203.847238] ath: Reset TX queue: 3
>> > [ 203.850683] ath: Reset TXQ, inactive queue: 4
>> > [ 203.855077] ath: Reset TXQ, inactive queue: 5
>> > [ 203.859469] ath: Reset TXQ, inactive queue: 6
>> > [ 203.863864] ath: Reset TXQ, inactive queue: 7
>> > [ 203.868258] ath: Reset TX queue: 8
>> > [ 203.871709] ath: Reset TX queue: 9
>> > [ 203.877917] ath: Set queue properties for: 9
>> > [ 203.882244] ath: Reset TX queue: 9
>> > [ 203.978048] ath: Enable TXE on queue: 9
>> > [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1
>> > on Q 9 [ 204.914536] ath: Failed to stop TX DMA in 100 msec after
>> > killing last frame [ 204.933408] ath: DMA failed to stop in 10 ms
>> > AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 204.941106] ath: Could
>> > not stop RX, we could be confusing the DMA engine when we start RX
>> > up [ 204.949576] ------------[ cut here ]------------
>> > [ 204.954249] WARNING: at
>> > drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9
>> > [ath9k]()
>>
>> Ok neat.. how soon after starting hostapd does this come up,
>> immeidiately?
>
> 2 mails back is a complete log including timestamps, about 30 seconds
> from hostapd start until the error.
>
>> What version of hostapd?
>
> hostap.git @cbcf92b4
I just sent out a 4-patch series to linux-wireless@ which almost
completely fixes all the tx dma stop issues that I could reproduce in my
setup. Please give it a try and let me know if it fixes your issues as well.
- Felix
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-05 23:49 ` crocket
@ 2011-03-09 10:22 ` Peter Stuge
0 siblings, 0 replies; 26+ messages in thread
From: Peter Stuge @ 2011-03-09 10:22 UTC (permalink / raw)
To: ath9k-devel
crocket wrote:
> I don't know why Luis said " "DMA failed to stop" issues are non-fatal "
> It definitely stops the chipset and is certainly fatal.
I believe because Luis has only seen the error message in other,
unrelated, circumstances, where the issue is indeed not fatal.
This can of course not invalidate reports of the issue having a
different effect.
//Peter
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 17:16 ` Bernhard Schmidt
2011-03-09 9:58 ` Mohammed Shafi
@ 2011-03-09 10:01 ` Mohammed Shafi
1 sibling, 0 replies; 26+ messages in thread
From: Mohammed Shafi @ 2011-03-09 10:01 UTC (permalink / raw)
To: ath9k-devel
On Fri, Mar 4, 2011 at 10:46 PM, Bernhard Schmidt
<bschmidt@techwires.net> wrote:
> On Friday 04 March 2011 16:29:13 Mohammed Shafi wrote:
>> On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>> > On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
>> >> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
>> >>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
>> >>> <bschmidt@techwires.net> wrote:
>> >>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>> >>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> >>> >> > % scan done, setting up the BSS
>> >>> >> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?296.083032] ath: Failed to stop TX DMA!
>> >>> >> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >>> >> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >>> >> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > % ..
>> >>> >>
>> >>> >> If its so easy to reproduce we can likely fix this for good!
>> >>> >
>> >>> > Actually, haven't found a way to *not* reproduce it. :)
>> >>>
>> >>> the obvious way of increasing the timeout for stopping the DMA might help ?
>> >>> in mac.c
>> >>>
>> >>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT ? ? ? 4000 ? ?/* usec */
>> >>> increase it to 10000 usec
>> >>>
>> >>> and
>> >>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 ? /* usec */
>> >>> increase it to 20,000 usec
>> >>
>> >> Did try to play with various values, no differences whatsoever,
>> >> obviously. Even tried polling a whole second. The messages do indicate
>> >> that there is an issue. It's not that the reg isn't polled for long
>> >> enough, but instead this is an indicator for something wrong going on.
>> >> What I'm wondering though is, that the queue resets which eventually
>> >> happen do not have any effect, only after a "full" reset (e.g.
>> >> ifconfig down/up) the queues will be usable again.
>> >
>> > Thanks for trying it out, I thought we have to give sufficient time so
>> > that the bit goes low.
>> >
>> >>
>> >> On a site note, after falling back to other chips (9380, 9160), I see
>> >> the same issue there too. Not as often, or as immediate as with 9280,
>> >> but they do occur (even on different hardware). Having a hostapd
>> >> instance idle long enough is able to trigger it eventually.
>>
>> Can you please give some information regarding this issue in station mode.
>> In the station mode does scanning seems to easily trigger this issue?
>> Or is there with something like running the traffic or plugging the card out?
>
> After a fresh boot I can trigger it with just:
> % modprobe ath9k
> % ifconfig wlan0 up
> % iw wlan0 scan
> the only traffic involved are probe requests being sent and of course
> all frames received during a scan. Most of the time it happens on the
> first invocation of the scan command, sometimes I need to call it 2 or
> 3 times.
Ok does the fix provided by Felix might help this issue?
[PATCH 2.6.38] ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag
>
> --
> Bernhard
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 17:16 ` Bernhard Schmidt
@ 2011-03-09 9:58 ` Mohammed Shafi
2011-03-09 10:01 ` Mohammed Shafi
1 sibling, 0 replies; 26+ messages in thread
From: Mohammed Shafi @ 2011-03-09 9:58 UTC (permalink / raw)
To: ath9k-devel
On Fri, Mar 4, 2011 at 10:46 PM, Bernhard Schmidt
<bschmidt@techwires.net> wrote:
> On Friday 04 March 2011 16:29:13 Mohammed Shafi wrote:
>> On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
>> > On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
>> >> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
>> >>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
>> >>> <bschmidt@techwires.net> wrote:
>> >>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>> >>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> >>> >> > % scan done, setting up the BSS
>> >>> >> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?296.083032] ath: Failed to stop TX DMA!
>> >>> >> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >>> >> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >>> >> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >>> >> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >>> >> > % ..
>> >>> >>
>> >>> >> If its so easy to reproduce we can likely fix this for good!
>> >>> >
>> >>> > Actually, haven't found a way to *not* reproduce it. :)
>> >>>
>> >>> the obvious way of increasing the timeout for stopping the DMA might help ?
>> >>> in mac.c
>> >>>
>> >>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT ? ? ? 4000 ? ?/* usec */
>> >>> increase it to 10000 usec
>> >>>
>> >>> and
>> >>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 ? /* usec */
>> >>> increase it to 20,000 usec
>> >>
>> >> Did try to play with various values, no differences whatsoever,
>> >> obviously. Even tried polling a whole second. The messages do indicate
>> >> that there is an issue. It's not that the reg isn't polled for long
>> >> enough, but instead this is an indicator for something wrong going on.
>> >> What I'm wondering though is, that the queue resets which eventually
>> >> happen do not have any effect, only after a "full" reset (e.g.
>> >> ifconfig down/up) the queues will be usable again.
>> >
>> > Thanks for trying it out, I thought we have to give sufficient time so
>> > that the bit goes low.
>> >
>> >>
>> >> On a site note, after falling back to other chips (9380, 9160), I see
>> >> the same issue there too. Not as often, or as immediate as with 9280,
>> >> but they do occur (even on different hardware). Having a hostapd
>> >> instance idle long enough is able to trigger it eventually.
>>
>> Can you please give some information regarding this issue in station mode.
>> In the station mode does scanning seems to easily trigger this issue?
>> Or is there with something like running the traffic or plugging the card out?
>
> After a fresh boot I can trigger it with just:
> % modprobe ath9k
> % ifconfig wlan0 up
> % iw wlan0 scan
> the only traffic involved are probe requests being sent and of course
> all frames received during a scan. Most of the time it happens on the
> first invocation of the scan command, sometimes I need to call it 2 or
> 3 times.
Ok thanks, looks like the deafness happens when configured as AP mode
>
> --
> Bernhard
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 11:29 ` Bernhard Schmidt
2011-03-04 15:25 ` Mohammed Shafi
@ 2011-03-05 23:49 ` crocket
2011-03-09 10:22 ` Peter Stuge
1 sibling, 1 reply; 26+ messages in thread
From: crocket @ 2011-03-05 23:49 UTC (permalink / raw)
To: ath9k-devel
I knew it. AR9280 wouldn't last days or months in AP or station mode.
AR9280 would go deaf after one or more scan requests and after hostapd
stays idle for a while.
I don't know why Luis said " "DMA failed to stop" issues are non-fatal "
It definitely stops the chipset and is certainly fatal.
On Fri, Mar 4, 2011 at 8:29 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
>> <bschmidt@techwires.net> wrote:
>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> >> > % scan done, setting up the BSS
>> >> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?296.083032] ath: Failed to stop TX DMA!
>> >> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > % ..
>> >>
>> >> If its so easy to reproduce we can likely fix this for good!
>> >
>> > Actually, haven't found a way to *not* reproduce it. :)
>>
>> the obvious way of increasing the timeout for stopping the DMA might help ?
>> in mac.c
>>
>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT ? ? ? 4000 ? ?/* usec */
>> increase it to 10000 usec
>>
>> and
>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 ? /* usec */
>> increase it to 20,000 usec
>
> Did try to play with various values, no differences whatsoever,
> obviously. Even tried polling a whole second. The messages do indicate
> that there is an issue. It's not that the reg isn't polled for long
> enough, but instead this is an indicator for something wrong going on.
> What I'm wondering though is, that the queue resets which eventually
> happen do not have any effect, only after a "full" reset (e.g.
> ifconfig down/up) the queues will be usable again.
>
> On a site note, after falling back to other chips (9380, 9160), I see
> the same issue there too. Not as often, or as immediate as with 9280,
> but they do occur (even on different hardware). Having a hostapd
> instance idle long enough is able to trigger it eventually.
>
> --
> Bernhard
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 15:29 ` Mohammed Shafi
@ 2011-03-04 17:16 ` Bernhard Schmidt
2011-03-09 9:58 ` Mohammed Shafi
2011-03-09 10:01 ` Mohammed Shafi
0 siblings, 2 replies; 26+ messages in thread
From: Bernhard Schmidt @ 2011-03-04 17:16 UTC (permalink / raw)
To: ath9k-devel
On Friday 04 March 2011 16:29:13 Mohammed Shafi wrote:
> On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> > On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
> >> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
> >>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
> >>> <bschmidt@techwires.net> wrote:
> >>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
> >>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> >>> >> > % scan done, setting up the BSS
> >>> >> > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [ 296.083032] ath: Failed to stop TX DMA!
> >>> >> > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >>> >> > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >>> >> > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >>> >> > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >>> >> > % ..
> >>> >>
> >>> >> If its so easy to reproduce we can likely fix this for good!
> >>> >
> >>> > Actually, haven't found a way to *not* reproduce it. :)
> >>>
> >>> the obvious way of increasing the timeout for stopping the DMA might help ?
> >>> in mac.c
> >>>
> >>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT 4000 /* usec */
> >>> increase it to 10000 usec
> >>>
> >>> and
> >>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 /* usec */
> >>> increase it to 20,000 usec
> >>
> >> Did try to play with various values, no differences whatsoever,
> >> obviously. Even tried polling a whole second. The messages do indicate
> >> that there is an issue. It's not that the reg isn't polled for long
> >> enough, but instead this is an indicator for something wrong going on.
> >> What I'm wondering though is, that the queue resets which eventually
> >> happen do not have any effect, only after a "full" reset (e.g.
> >> ifconfig down/up) the queues will be usable again.
> >
> > Thanks for trying it out, I thought we have to give sufficient time so
> > that the bit goes low.
> >
> >>
> >> On a site note, after falling back to other chips (9380, 9160), I see
> >> the same issue there too. Not as often, or as immediate as with 9280,
> >> but they do occur (even on different hardware). Having a hostapd
> >> instance idle long enough is able to trigger it eventually.
>
> Can you please give some information regarding this issue in station mode.
> In the station mode does scanning seems to easily trigger this issue?
> Or is there with something like running the traffic or plugging the card out?
After a fresh boot I can trigger it with just:
% modprobe ath9k
% ifconfig wlan0 up
% iw wlan0 scan
the only traffic involved are probe requests being sent and of course
all frames received during a scan. Most of the time it happens on the
first invocation of the scan command, sometimes I need to call it 2 or
3 times.
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 15:25 ` Mohammed Shafi
@ 2011-03-04 15:29 ` Mohammed Shafi
2011-03-04 17:16 ` Bernhard Schmidt
0 siblings, 1 reply; 26+ messages in thread
From: Mohammed Shafi @ 2011-03-04 15:29 UTC (permalink / raw)
To: ath9k-devel
On Fri, Mar 4, 2011 at 8:55 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
>> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
>>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
>>> <bschmidt@techwires.net> wrote:
>>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>>> >> > % scan done, setting up the BSS
>>> >> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> >> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> >> > [ ?296.083032] ath: Failed to stop TX DMA!
>>> >> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>>> >> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>>> >> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>>> >> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> >> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>>> >> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>>> >> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>>> >> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> >> > % ..
>>> >>
>>> >> If its so easy to reproduce we can likely fix this for good!
>>> >
>>> > Actually, haven't found a way to *not* reproduce it. :)
>>>
>>> the obvious way of increasing the timeout for stopping the DMA might help ?
>>> in mac.c
>>>
>>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT ? ? ? 4000 ? ?/* usec */
>>> increase it to 10000 usec
>>>
>>> and
>>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 ? /* usec */
>>> increase it to 20,000 usec
>>
>> Did try to play with various values, no differences whatsoever,
>> obviously. Even tried polling a whole second. The messages do indicate
>> that there is an issue. It's not that the reg isn't polled for long
>> enough, but instead this is an indicator for something wrong going on.
>> What I'm wondering though is, that the queue resets which eventually
>> happen do not have any effect, only after a "full" reset (e.g.
>> ifconfig down/up) the queues will be usable again.
>
> Thanks for trying it out, I thought we have to give sufficient time so
> that the bit goes low.
>
>>
>> On a site note, after falling back to other chips (9380, 9160), I see
>> the same issue there too. Not as often, or as immediate as with 9280,
>> but they do occur (even on different hardware). Having a hostapd
>> instance idle long enough is able to trigger it eventually.
Can you please give some information regarding this issue in station mode.
In the station mode does scanning seems to easily trigger this issue?
Or is there with something like running the traffic or plugging the card out?
thanks,
shafi
>>
>
> Oh the issue is easily reproducible with AR9280
>
>> --
>> Bernhard
>>
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-04 11:29 ` Bernhard Schmidt
@ 2011-03-04 15:25 ` Mohammed Shafi
2011-03-04 15:29 ` Mohammed Shafi
2011-03-05 23:49 ` crocket
1 sibling, 1 reply; 26+ messages in thread
From: Mohammed Shafi @ 2011-03-04 15:25 UTC (permalink / raw)
To: ath9k-devel
On Fri, Mar 4, 2011 at 4:59 PM, Bernhard Schmidt <bschmidt@techwires.net> wrote:
> On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
>> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
>> <bschmidt@techwires.net> wrote:
>> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> >> > % scan done, setting up the BSS
>> >> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?296.083032] ath: Failed to stop TX DMA!
>> >> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> >> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> >> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> >> > % ..
>> >>
>> >> If its so easy to reproduce we can likely fix this for good!
>> >
>> > Actually, haven't found a way to *not* reproduce it. :)
>>
>> the obvious way of increasing the timeout for stopping the DMA might help ?
>> in mac.c
>>
>> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT ? ? ? 4000 ? ?/* usec */
>> increase it to 10000 usec
>>
>> and
>> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 ? /* usec */
>> increase it to 20,000 usec
>
> Did try to play with various values, no differences whatsoever,
> obviously. Even tried polling a whole second. The messages do indicate
> that there is an issue. It's not that the reg isn't polled for long
> enough, but instead this is an indicator for something wrong going on.
> What I'm wondering though is, that the queue resets which eventually
> happen do not have any effect, only after a "full" reset (e.g.
> ifconfig down/up) the queues will be usable again.
Thanks for trying it out, I thought we have to give sufficient time so
that the bit goes low.
>
> On a site note, after falling back to other chips (9380, 9160), I see
> the same issue there too. Not as often, or as immediate as with 9280,
> but they do occur (even on different hardware). Having a hostapd
> instance idle long enough is able to trigger it eventually.
>
Oh the issue is easily reproducible with AR9280
> --
> Bernhard
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-03-02 14:51 ` Mohammed Shafi
@ 2011-03-04 11:29 ` Bernhard Schmidt
2011-03-04 15:25 ` Mohammed Shafi
2011-03-05 23:49 ` crocket
0 siblings, 2 replies; 26+ messages in thread
From: Bernhard Schmidt @ 2011-03-04 11:29 UTC (permalink / raw)
To: ath9k-devel
On Wednesday, March 02, 2011 15:51:37 Mohammed Shafi wrote:
> On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
> <bschmidt@techwires.net> wrote:
> > On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
> >> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> >> > % scan done, setting up the BSS
> >> > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >> > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >> > [ 296.083032] ath: Failed to stop TX DMA!
> >> > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >> > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >> > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >> > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >> > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >> > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> >> > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> >> > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >> > % ..
> >>
> >> If its so easy to reproduce we can likely fix this for good!
> >
> > Actually, haven't found a way to *not* reproduce it. :)
>
> the obvious way of increasing the timeout for stopping the DMA might help ?
> in mac.c
>
> 148 #define ATH9K_TX_STOP_DMA_TIMEOUT 4000 /* usec */
> increase it to 10000 usec
>
> and
> 781#define AH_RX_STOP_DMA_TIMEOUT 10000 /* usec */
> increase it to 20,000 usec
Did try to play with various values, no differences whatsoever,
obviously. Even tried polling a whole second. The messages do indicate
that there is an issue. It's not that the reg isn't polled for long
enough, but instead this is an indicator for something wrong going on.
What I'm wondering though is, that the queue resets which eventually
happen do not have any effect, only after a "full" reset (e.g.
ifconfig down/up) the queues will be usable again.
On a site note, after falling back to other chips (9380, 9160), I see
the same issue there too. Not as often, or as immediate as with 9280,
but they do occur (even on different hardware). Having a hostapd
instance idle long enough is able to trigger it eventually.
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 20:06 ` Bernhard Schmidt
2011-02-24 9:33 ` Bernhard Schmidt
@ 2011-03-02 14:51 ` Mohammed Shafi
2011-03-04 11:29 ` Bernhard Schmidt
1 sibling, 1 reply; 26+ messages in thread
From: Mohammed Shafi @ 2011-03-02 14:51 UTC (permalink / raw)
To: ath9k-devel
On Thu, Feb 24, 2011 at 1:36 AM, Bernhard Schmidt
<bschmidt@techwires.net> wrote:
> On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
>> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> > Hi,
>> >
>> > I have some issues using any of my AR9280 cards, identified as:
>> > - Ubiquiti SR71E
>> > [ ?172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11
>> > - Sparklan WPEA-110N
>> > [ ? 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11
>> >
>> > On a recent wireless-testing kernel:
>> > # uname -a
>> > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux
>> >
>> > I see this behaviour:
>> > # hostapd /etc/hostapd.conf
>> > % scan due to ht40
>> > [ ?289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > [ ?289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > [ ?289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > [ ?289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > ..
>>
>> This should not be fatal but we do want to fix it, it was just hard to reproduce.
>> Can you paste your hostapd.conf ?
>
> Will do that tomorrow when back at the office. Note, the error might
> not be fatal, but, due it taking 100ms (see below), which is exactly
> the beacon interval, no frames are sent. It is also not related to AP
> mode, I see the exact same behavior in station mode. If I manage to get
> through the association phase, it quickly goes deaf after the first
> few packets.
>
>> > % scan done, setting up the BSS
>> > [ ?296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> > [ ?296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> > [ ?296.083032] ath: Failed to stop TX DMA!
>> > [ ?296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > [ ?296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> > [ ?297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
>> > [ ?297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
>> > [ ?298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> > % ..
>>
>> If its so easy to reproduce we can likely fix this for good!
>
> Actually, haven't found a way to *not* reproduce it. :)
the obvious way of increasing the timeout for stopping the DMA might help ?
in mac.c
148 #define ATH9K_TX_STOP_DMA_TIMEOUT 4000 /* usec */
increase it to 10000 usec
and
781#define AH_RX_STOP_DMA_TIMEOUT 10000 /* usec */
increase it to 20,000 usec
>
>> Do you see the same issue if you just have one card plugged in or
>> is this happening on two separate boxes?
>
> It's one card at a time on this box. The monitor device is running on
> another box. It is the only miniPCIe capable box I have around here
> atm.
>
> While playing around a bit with various debug options, I've noticed
> that the amount of debug messages has an influence on when the issue
> does occur. As in the more debug message, the sooner it will go deaf.
> Smells racy somehow.
>
> Will post a slightly more verbose log tomorrow.
>
> --
> Bernhard
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-25 17:12 ` Luis R. Rodriguez
@ 2011-02-26 9:37 ` Bernhard Schmidt
2011-03-10 0:40 ` Felix Fietkau
0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Schmidt @ 2011-02-26 9:37 UTC (permalink / raw)
To: ath9k-devel
On Friday 25 February 2011 18:12:09 Luis R. Rodriguez wrote:
> On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote:
> > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote:
> > > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote:
> > > > I've stripped everything not necessary, this one is use for the
> > > > log below.
> > > >
> > > > # cat /etc/hostapd.conf
> > > > interface=wlan0
> > > > driver=nl80211
> > > > ssid=testtest
> > > > hw_mode=a
> > > > channel=44
> > > >
> > > > [ 574.605956] ath: Enable TXE on queue: 9
> > > > [ 574.708386] ath: Enable TXE on queue: 9
> > > > [ 574.810752] ath: Enable TXE on queue: 9
> > > > [ 574.913151] ath: Enable TXE on queue: 9
> > > > [ 575.015541] ath: Enable TXE on queue: 9
> > > > [ 575.117938] ath: Enable TXE on queue: 9
> > > > [ 575.220335] ath: Enable TXE on queue: 9
> > > > [ 575.322732] ath: Enable TXE on queue: 9
> > > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX
> > > > Frames 1 on Q 9 [ 576.259188] ath: Failed to stop TX DMA in
> > > > 100 msec after killing last frame
> > >
> > > Can you confirm what kernel ?
> > >
> > > I see 2.6.38-rc6-wl-12466-g09f3227
> > >
> > > So I take it you are using wireless-testing, is this right? Can
> > > you reproduce with wireless-testing as of today? This would be
> > > helpful for our own testing.
> >
> > Yes, the logs were posted using wireless-testing, always pulled
> > before doing the tests.
> >
> > Just to confirm, with wireless-testing as of a few minutes ago,
> > same behavior.
> >
> > # uname -a
> > Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25
> > 10:19:49 CET 2011 i686 GNU/Linux # git log --pretty=oneline | head
> > -n1
> > 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge
> > ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless
> > -next-2.6
> >
> > [ 176.675020] ath: Enable TXE on queue: 9
> > [ 176.777416] ath: Enable TXE on queue: 9
> > [ 176.827134] ath: qnum: 0, txq depth: 0
> > [ 176.831007] ath: Enable TXE on queue: 0
> > [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4
> > [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4
> > [ 176.879857] ath: Enable TXE on queue: 9
> > [ 176.982217] ath: Enable TXE on queue: 9
> > ..
> > [ 202.786342] ath: Enable TXE on queue: 9
> > [ 202.888732] ath: Enable TXE on queue: 9
> > [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1
> > on Q 9 [ 203.825260] ath: Failed to stop TX DMA in 100 msec after
> > killing last frame
> >
> > [ 203.836898] ath: Reset TX queue: 0
> > [ 203.840352] ath: Reset TX queue: 1
> > [ 203.843794] ath: Reset TX queue: 2
> > [ 203.847238] ath: Reset TX queue: 3
> > [ 203.850683] ath: Reset TXQ, inactive queue: 4
> > [ 203.855077] ath: Reset TXQ, inactive queue: 5
> > [ 203.859469] ath: Reset TXQ, inactive queue: 6
> > [ 203.863864] ath: Reset TXQ, inactive queue: 7
> > [ 203.868258] ath: Reset TX queue: 8
> > [ 203.871709] ath: Reset TX queue: 9
> > [ 203.877917] ath: Set queue properties for: 9
> > [ 203.882244] ath: Reset TX queue: 9
> > [ 203.978048] ath: Enable TXE on queue: 9
> > [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1
> > on Q 9 [ 204.914536] ath: Failed to stop TX DMA in 100 msec after
> > killing last frame [ 204.933408] ath: DMA failed to stop in 10 ms
> > AR_CR=0x00000024 AR_DIAG_SW=0x42000020 [ 204.941106] ath: Could
> > not stop RX, we could be confusing the DMA engine when we start RX
> > up [ 204.949576] ------------[ cut here ]------------
> > [ 204.954249] WARNING: at
> > drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9
> > [ath9k]()
>
> Ok neat.. how soon after starting hostapd does this come up,
> immeidiately?
2 mails back is a complete log including timestamps, about 30 seconds
from hostapd start until the error.
> What version of hostapd?
hostap.git @cbcf92b4
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-25 9:37 ` Bernhard Schmidt
@ 2011-02-25 17:12 ` Luis R. Rodriguez
2011-02-26 9:37 ` Bernhard Schmidt
0 siblings, 1 reply; 26+ messages in thread
From: Luis R. Rodriguez @ 2011-02-25 17:12 UTC (permalink / raw)
To: ath9k-devel
On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote:
> On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote:
> > On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote:
> > >
> > > I've stripped everything not necessary, this one is use for the log
> > > below.
> > >
> > > # cat /etc/hostapd.conf
> > > interface=wlan0
> > > driver=nl80211
> > > ssid=testtest
> > > hw_mode=a
> > > channel=44
> >
> > > [ 574.605956] ath: Enable TXE on queue: 9
> > > [ 574.708386] ath: Enable TXE on queue: 9
> > > [ 574.810752] ath: Enable TXE on queue: 9
> > > [ 574.913151] ath: Enable TXE on queue: 9
> > > [ 575.015541] ath: Enable TXE on queue: 9
> > > [ 575.117938] ath: Enable TXE on queue: 9
> > > [ 575.220335] ath: Enable TXE on queue: 9
> > > [ 575.322732] ath: Enable TXE on queue: 9
> > > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
> > > [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame
> >
> > Can you confirm what kernel ?
> >
> > I see 2.6.38-rc6-wl-12466-g09f3227
> >
> > So I take it you are using wireless-testing, is this right? Can you reproduce with
> > wireless-testing as of today? This would be helpful for our own testing.
>
> Yes, the logs were posted using wireless-testing, always pulled before
> doing the tests.
>
> Just to confirm, with wireless-testing as of a few minutes ago, same
> behavior.
>
> # uname -a
> Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 10:19:49 CET 2011 i686 GNU/Linux
> # git log --pretty=oneline | head -n1
> 8ccd3c862a39d46626ba89777e59d1775a579b62 Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
>
> [ 176.675020] ath: Enable TXE on queue: 9
> [ 176.777416] ath: Enable TXE on queue: 9
> [ 176.827134] ath: qnum: 0, txq depth: 0
> [ 176.831007] ath: Enable TXE on queue: 0
> [ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4
> [ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4
> [ 176.879857] ath: Enable TXE on queue: 9
> [ 176.982217] ath: Enable TXE on queue: 9
> ..
> [ 202.786342] ath: Enable TXE on queue: 9
> [ 202.888732] ath: Enable TXE on queue: 9
> [ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
> [ 203.825260] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 203.836898] ath: Reset TX queue: 0
> [ 203.840352] ath: Reset TX queue: 1
> [ 203.843794] ath: Reset TX queue: 2
> [ 203.847238] ath: Reset TX queue: 3
> [ 203.850683] ath: Reset TXQ, inactive queue: 4
> [ 203.855077] ath: Reset TXQ, inactive queue: 5
> [ 203.859469] ath: Reset TXQ, inactive queue: 6
> [ 203.863864] ath: Reset TXQ, inactive queue: 7
> [ 203.868258] ath: Reset TX queue: 8
> [ 203.871709] ath: Reset TX queue: 9
> [ 203.877917] ath: Set queue properties for: 9
> [ 203.882244] ath: Reset TX queue: 9
> [ 203.978048] ath: Enable TXE on queue: 9
> [ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
> [ 204.914536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 204.933408] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 204.941106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 204.949576] ------------[ cut here ]------------
> [ 204.954249] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]()
Ok neat.. how soon after starting hostapd does this come up, immeidiately?
What version of hostapd?
Luis
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-24 18:18 ` Luis R. Rodriguez
@ 2011-02-25 9:37 ` Bernhard Schmidt
2011-02-25 17:12 ` Luis R. Rodriguez
0 siblings, 1 reply; 26+ messages in thread
From: Bernhard Schmidt @ 2011-02-25 9:37 UTC (permalink / raw)
To: ath9k-devel
On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote:
> On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote:
> >
> > I've stripped everything not necessary, this one is use for the log
> > below.
> >
> > # cat /etc/hostapd.conf
> > interface=wlan0
> > driver=nl80211
> > ssid=testtest
> > hw_mode=a
> > channel=44
>
> > [ 574.605956] ath: Enable TXE on queue: 9
> > [ 574.708386] ath: Enable TXE on queue: 9
> > [ 574.810752] ath: Enable TXE on queue: 9
> > [ 574.913151] ath: Enable TXE on queue: 9
> > [ 575.015541] ath: Enable TXE on queue: 9
> > [ 575.117938] ath: Enable TXE on queue: 9
> > [ 575.220335] ath: Enable TXE on queue: 9
> > [ 575.322732] ath: Enable TXE on queue: 9
> > [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
> > [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame
>
> Can you confirm what kernel ?
>
> I see 2.6.38-rc6-wl-12466-g09f3227
>
> So I take it you are using wireless-testing, is this right? Can you reproduce with
> wireless-testing as of today? This would be helpful for our own testing.
Yes, the logs were posted using wireless-testing, always pulled before
doing the tests.
Just to confirm, with wireless-testing as of a few minutes ago, same
behavior.
# uname -a
Linux meshnode 2.6.38-rc6-wl-12527-g8ccd3c8 #25 SMP Fri Feb 25 10:19:49 CET 2011 i686 GNU/Linux
# git log --pretty=oneline | head -n1
8ccd3c862a39d46626ba89777e59d1775a579b62 Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
[ 176.675020] ath: Enable TXE on queue: 9
[ 176.777416] ath: Enable TXE on queue: 9
[ 176.827134] ath: qnum: 0, txq depth: 0
[ 176.831007] ath: Enable TXE on queue: 0
[ 176.834979] ath: tx queue 0 (2f1b01f4), link ef1b01f4
[ 176.840244] ath: tx queue 0 (2f1b01f4), link ef1b01f4
[ 176.879857] ath: Enable TXE on queue: 9
[ 176.982217] ath: Enable TXE on queue: 9
..
[ 202.786342] ath: Enable TXE on queue: 9
[ 202.888732] ath: Enable TXE on queue: 9
[ 203.814434] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 203.825260] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 203.836898] ath: Reset TX queue: 0
[ 203.840352] ath: Reset TX queue: 1
[ 203.843794] ath: Reset TX queue: 2
[ 203.847238] ath: Reset TX queue: 3
[ 203.850683] ath: Reset TXQ, inactive queue: 4
[ 203.855077] ath: Reset TXQ, inactive queue: 5
[ 203.859469] ath: Reset TXQ, inactive queue: 6
[ 203.863864] ath: Reset TXQ, inactive queue: 7
[ 203.868258] ath: Reset TX queue: 8
[ 203.871709] ath: Reset TX queue: 9
[ 203.877917] ath: Set queue properties for: 9
[ 203.882244] ath: Reset TX queue: 9
[ 203.978048] ath: Enable TXE on queue: 9
[ 204.903691] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 204.914536] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 204.933408] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 204.941106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 204.949576] ------------[ cut here ]------------
[ 204.954249] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]()
[ 204.963240] Hardware name: To be filled by O.E.M.
[ 204.967982] Modules linked in: ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 e1000e [last unloaded: cfg80211]
[ 204.978657] Pid: 0, comm: swapper Not tainted 2.6.38-rc6-wl-12527-g8ccd3c8 #25
[ 204.985905] Call Trace:
[ 204.988409] [<c01288c2>] ? warn_slowpath_common+0x6a/0x7f
[ 204.993952] [<f88e9bcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k]
[ 204.999483] [<c01288eb>] ? warn_slowpath_null+0x14/0x18
[ 205.004860] [<f88e9bcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k]
[ 205.010398] [<f88e6d37>] ? ath_reset+0x6b/0x185 [ath9k]
[ 205.015760] [<f88e4aa9>] ? ath9k_ioread32+0x56/0x60 [ath9k]
[ 205.021486] [<f88e3186>] ? ath_beacon_tasklet+0xad/0x63c [ath9k]
[ 205.027622] [<c0233190>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 205.033326] [<c037a31c>] ? restore_all_notrace+0x0/0x18
[ 205.038680] [<c037a05f>] ? _raw_spin_unlock_irq+0x29/0x2b
[ 205.044209] [<c01337af>] ? run_timer_softirq+0x28a/0x292
[ 205.049654] [<c012d825>] ? tasklet_action+0x3a/0xd9
[ 205.054661] [<c012d858>] ? tasklet_action+0x6d/0xd9
[ 205.059670] [<c012df14>] ? __do_softirq+0xb1/0x16a
[ 205.064591] [<c012de63>] ? __do_softirq+0x0/0x16a
[ 205.069449] <IRQ> [<c012d62a>] ? irq_exit+0x3a/0x3c
[ 205.074644] [<c0103dc2>] ? do_IRQ+0x81/0x95
[ 205.078957] [<c0102d6e>] ? common_interrupt+0x2e/0x34
[ 205.084146] [<c027a4bc>] ? acpi_idle_enter_bm+0x24b/0x27f
[ 205.089676] [<c02ef3cf>] ? cpuidle_idle_call+0xee/0x183
[ 205.095035] [<c0101aec>] ? cpu_idle+0x44/0x5c
[ 205.099528] [<c0368d5e>] ? rest_init+0x92/0x97
[ 205.104107] [<c04f4884>] ? start_kernel+0x2d7/0x2dc
[ 205.109122] [<c04f40d2>] ? i386_start_kernel+0xd2/0xd9
[ 205.114382] ---[ end trace dfe2ba9402d5b1b9 ]---
[ 205.130883] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 205.143064] ath: Reset TX queue: 0
[ 205.146515] ath: Reset TX queue: 1
[ 205.149959] ath: Reset TX queue: 2
[ 205.153401] ath: Reset TX queue: 3
[ 205.156849] ath: Reset TXQ, inactive queue: 4
[ 205.161249] ath: Reset TXQ, inactive queue: 5
[ 205.165641] ath: Reset TXQ, inactive queue: 6
[ 205.170034] ath: Reset TXQ, inactive queue: 7
[ 205.174459] ath: Reset TX queue: 8
[ 205.177913] ath: Reset TX queue: 9
[ 205.184112] ath: Set queue properties for: 9
[ 205.188473] ath: Reset TX queue: 9
[ 205.284238] ath: Enable TXE on queue: 9
[ 206.209936] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 206.220793] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 206.239678] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 206.247372] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 206.267676] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 206.279844] ath: Reset TX queue: 0
[ 206.283302] ath: Reset TX queue: 1
[ 206.286744] ath: Reset TX queue: 2
[ 206.290185] ath: Reset TX queue: 3
[ 206.293633] ath: Reset TXQ, inactive queue: 4
[ 206.298026] ath: Reset TXQ, inactive queue: 5
[ 206.302418] ath: Reset TXQ, inactive queue: 6
[ 206.306813] ath: Reset TXQ, inactive queue: 7
[ 206.311204] ath: Reset TX queue: 8
[ 206.314655] ath: Reset TX queue: 9
[ 206.320858] ath: Set queue properties for: 9
[ 206.325186] ath: Reset TX queue: 9
[ 206.420948] ath: Enable TXE on queue: 9
[ 207.346657] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 207.357515] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 207.376403] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 207.384127] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 207.404435] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
..
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-24 9:33 ` Bernhard Schmidt
@ 2011-02-24 18:18 ` Luis R. Rodriguez
2011-02-25 9:37 ` Bernhard Schmidt
0 siblings, 1 reply; 26+ messages in thread
From: Luis R. Rodriguez @ 2011-02-24 18:18 UTC (permalink / raw)
To: ath9k-devel
On Thu, Feb 24, 2011 at 01:33:18AM -0800, Bernhard Schmidt wrote:
>
> I've stripped everything not necessary, this one is use for the log
> below.
>
> # cat /etc/hostapd.conf
> interface=wlan0
> driver=nl80211
> ssid=testtest
> hw_mode=a
> channel=44
> [ 574.605956] ath: Enable TXE on queue: 9
> [ 574.708386] ath: Enable TXE on queue: 9
> [ 574.810752] ath: Enable TXE on queue: 9
> [ 574.913151] ath: Enable TXE on queue: 9
> [ 575.015541] ath: Enable TXE on queue: 9
> [ 575.117938] ath: Enable TXE on queue: 9
> [ 575.220335] ath: Enable TXE on queue: 9
> [ 575.322732] ath: Enable TXE on queue: 9
> [ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
> [ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame
Can you confirm what kernel ?
I see 2.6.38-rc6-wl-12466-g09f3227
So I take it you are using wireless-testing, is this right? Can you reproduce with
wireless-testing as of today? This would be helpful for our own testing.
Luis
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 20:06 ` Bernhard Schmidt
@ 2011-02-24 9:33 ` Bernhard Schmidt
2011-02-24 18:18 ` Luis R. Rodriguez
2011-03-02 14:51 ` Mohammed Shafi
1 sibling, 1 reply; 26+ messages in thread
From: Bernhard Schmidt @ 2011-02-24 9:33 UTC (permalink / raw)
To: ath9k-devel
On Wednesday, February 23, 2011 21:06:30 Bernhard Schmidt wrote:
> On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
> > On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> > > Hi,
> > >
> > > I have some issues using any of my AR9280 cards, identified as:
> > > - Ubiquiti SR71E
> > > [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11
> > > - Sparklan WPEA-110N
> > > [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11
> > >
> > > On a recent wireless-testing kernel:
> > > # uname -a
> > > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux
> > >
> > > I see this behaviour:
> > > # hostapd /etc/hostapd.conf
> > > % scan due to ht40
> > > [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > ..
> >
> > This should not be fatal but we do want to fix it, it was just hard to reproduce.
> > Can you paste your hostapd.conf ?
>
> Will do that tomorrow when back at the office. Note, the error might
> not be fatal, but, due it taking 100ms (see below), which is exactly
> the beacon interval, no frames are sent. It is also not related to AP
> mode, I see the exact same behavior in station mode. If I manage to get
> through the association phase, it quickly goes deaf after the first
> few packets.
I've stripped everything not necessary, this one is use for the log
below.
# cat /etc/hostapd.conf
interface=wlan0
driver=nl80211
ssid=testtest
hw_mode=a
channel=44
> > > % scan done, setting up the BSS
> > > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > > [ 296.083032] ath: Failed to stop TX DMA!
> > > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > > % ..
> >
> > If its so easy to reproduce we can likely fix this for good!
>
> Actually, haven't found a way to *not* reproduce it. :)
>
> > Do you see the same issue if you just have one card plugged in or
> > is this happening on two separate boxes?
>
> It's one card at a time on this box. The monitor device is running on
> another box. It is the only miniPCIe capable box I have around here
> atm.
>
> While playing around a bit with various debug options, I've noticed
> that the amount of debug messages has an influence on when the issue
> does occur. As in the more debug message, the sooner it will go deaf.
> Smells racy somehow.
>
> Will post a slightly more verbose log tomorrow.
# hostapd /etc/hostapd.conf
Configuration file: /etc/hostapd.conf
[ 568.080816] device: 'mon.wlan0': device_add
[ 568.086085] PM: Adding info for No Bus:mon.wlan0
[ 568.111733] ath: Reset TX queue: 0
[ 568.115192] ath: Reset TX queue: 1
[ 568.118645] ath: Reset TX queue: 2
[ 568.122092] ath: Reset TX queue: 3
[ 568.125540] ath: Reset TXQ, inactive queue: 4
[ 568.129941] ath: Reset TXQ, inactive queue: 5
[ 568.134336] ath: Reset TXQ, inactive queue: 6
[ 568.138738] ath: Reset TXQ, inactive queue: 7
[ 568.143140] ath: Reset TX queue: 8
[ 568.146590] ath: Reset TX queue: 9
[ 568.159349] ath: Reset TX queue: 0
[ 568.162805] ath: Reset TX queue: 1
[ 568.166287] ath: Reset TX queue: 2
[ 568.169730] ath: Reset TX queue: 3
[ 568.173178] ath: Reset TXQ, inactive queue: 4
[ 568.177581] ath: Reset TXQ, inactive queue: 5
[ 568.181982] ath: Reset TXQ, inactive queue: 6
[ 568.186375] ath: Reset TXQ, inactive queue: 7
[ 568.190769] ath: Reset TX queue: 8
[ 568.194249] ath: Reset TX queue: 9
[ 568.206830] ath: Reset TX queue: 0
[ 568.210288] ath: Reset TX queue: 1
[ 568.213738] ath: Reset TX queue: 2
[ 568.217186] ath: Reset TX queue: 3
[ 568.220626] ath: Reset TXQ, inactive queue: 4
[ 568.225027] ath: Reset TXQ, inactive queue: 5
[ 568.229421] ath: Reset TXQ, inactive queue: 6
[ 568.233814] ath: Reset TXQ, inactive queue: 7
[ 568.238239] ath: Reset TX queue: 8
[ 568.241691] ath: Reset TX queue: 9
[ 568.248196] ath: Set queue properties for: 0
[ 568.252538] ath: Reset TX queue: 0
[ 568.256004] ath: Set queue properties for: 1
[ 568.260329] ath: Reset TX queue: 1
[ 568.263806] ath: Set queue properties for: 2
[ 568.268131] ath: Reset TX queue: 2
[ 568.271594] ath: Set queue properties for: 3
[ 568.275919] ath: Reset TX queue: 3
[ 568.395590] ath: Reset TX queue: 0
[ 568.399075] ath: Reset TX queue: 1
[ 568.402527] ath: Reset TX queue: 2
[ 568.405980] ath: Reset TX queue: 3
[ 568.409429] ath: Reset TXQ, inactive queue: 4
[ 568.413828] ath: Reset TXQ, inactive queue: 5
[ 568.418229] ath: Reset TXQ, inactive queue: 6
[ 568.422621] ath: Reset TXQ, inactive queue: 7
[ 568.427016] ath: Reset TX queue: 8
[ 568.430465] ath: Reset TX queue: 9
[ 568.439461] ath: qnum: 0, txq depth: 0
[ 568.443276] ath: Enable TXE on queue: 0
[ 568.447335] ath: tx queue 0 (2f4c0000), link ef4c0000
[ 568.452851] ath: tx queue 0 (2f4c0000), link ef4c0000
Using interface wlan0 with hwadd[ 568.462337] ath: Set queue properties for: 9
r 00:0e:8e:30:8f[ 568.467299] ath: Reset TX queue: 9
:e2 and ssid 'testtest'
[ 568.564542] ath: Enable TXE on queue: 9
[ 568.666920] ath: Enable TXE on queue: 9
[ 568.769318] ath: Enable TXE on queue: 9
[ 568.871718] ath: Enable TXE on queue: 9
[ 568.974158] ath: Enable TXE on queue: 9
[ 569.076514] ath: Enable TXE on queue: 9
[ 569.178910] ath: Enable TXE on queue: 9
[ 569.281309] ath: Enable TXE on queue: 9
[ 569.383702] ath: Enable TXE on queue: 9
[ 569.486145] ath: Enable TXE on queue: 9
[ 569.588492] ath: Enable TXE on queue: 9
[ 569.690887] ath: Enable TXE on queue: 9
[ 569.793287] ath: Enable TXE on queue: 9
[ 569.895680] ath: Enable TXE on queue: 9
[ 569.998122] ath: Enable TXE on queue: 9
[ 570.100481] ath: Enable TXE on queue: 9
[ 570.202873] ath: Enable TXE on queue: 9
[ 570.305273] ath: Enable TXE on queue: 9
[ 570.407668] ath: Enable TXE on queue: 9
[ 570.510097] ath: Enable TXE on queue: 9
[ 570.612470] ath: Enable TXE on queue: 9
[ 570.714910] ath: Enable TXE on queue: 9
[ 570.817262] ath: Enable TXE on queue: 9
[ 570.919655] ath: Enable TXE on queue: 9
[ 571.022052] ath: Enable TXE on queue: 9
[ 571.124456] ath: Enable TXE on queue: 9
[ 571.226883] ath: Enable TXE on queue: 9
[ 571.329246] ath: Enable TXE on queue: 9
[ 571.431649] ath: Enable TXE on queue: 9
[ 571.534047] ath: Enable TXE on queue: 9
[ 571.636442] ath: Enable TXE on queue: 9
[ 571.738853] ath: Enable TXE on queue: 9
[ 571.841237] ath: Enable TXE on queue: 9
[ 571.943629] ath: Enable TXE on queue: 9
[ 572.046024] ath: Enable TXE on queue: 9
[ 572.148419] ath: Enable TXE on queue: 9
[ 572.250824] ath: Enable TXE on queue: 9
[ 572.353220] ath: Enable TXE on queue: 9
[ 572.455655] ath: Enable TXE on queue: 9
[ 572.558012] ath: Enable TXE on queue: 9
[ 572.660416] ath: Enable TXE on queue: 9
[ 572.762815] ath: Enable TXE on queue: 9
[ 572.865201] ath: Enable TXE on queue: 9
[ 572.967641] ath: Enable TXE on queue: 9
[ 573.069994] ath: Enable TXE on queue: 9
[ 573.172397] ath: Enable TXE on queue: 9
[ 573.274792] ath: Enable TXE on queue: 9
[ 573.377193] ath: Enable TXE on queue: 9
[ 573.479588] ath: Enable TXE on queue: 9
[ 573.581980] ath: Enable TXE on queue: 9
[ 573.684433] ath: Enable TXE on queue: 9
[ 573.786786] ath: Enable TXE on queue: 9
[ 573.889176] ath: Enable TXE on queue: 9
[ 573.991567] ath: Enable TXE on queue: 9
[ 574.093968] ath: Enable TXE on queue: 9
[ 574.196417] ath: Enable TXE on queue: 9
[ 574.298764] ath: Enable TXE on queue: 9
[ 574.401156] ath: Enable TXE on queue: 9
[ 574.503557] ath: Enable TXE on queue: 9
[ 574.605956] ath: Enable TXE on queue: 9
[ 574.708386] ath: Enable TXE on queue: 9
[ 574.810752] ath: Enable TXE on queue: 9
[ 574.913151] ath: Enable TXE on queue: 9
[ 575.015541] ath: Enable TXE on queue: 9
[ 575.117938] ath: Enable TXE on queue: 9
[ 575.220335] ath: Enable TXE on queue: 9
[ 575.322732] ath: Enable TXE on queue: 9
[ 576.248395] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 576.259188] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 576.270827] ath: Reset TX queue: 0
[ 576.274288] ath: Reset TX queue: 1
[ 576.277732] ath: Reset TX queue: 2
[ 576.281179] ath: Reset TX queue: 3
[ 576.284620] ath: Reset TXQ, inactive queue: 4
[ 576.289042] ath: Reset TXQ, inactive queue: 5
[ 576.293439] ath: Reset TXQ, inactive queue: 6
[ 576.297833] ath: Reset TXQ, inactive queue: 7
[ 576.302227] ath: Reset TX queue: 8
[ 576.305676] ath: Reset TX queue: 9
[ 576.311886] ath: Set queue properties for: 9
[ 576.316216] ath: Reset TX queue: 9
[ 576.412070] ath: Enable TXE on queue: 9
[ 576.514417] ath: Enable TXE on queue: 9
[ 576.616820] ath: Enable TXE on queue: 9
[ 576.719211] ath: Enable TXE on queue: 9
[ 576.821613] ath: Enable TXE on queue: 9
[ 576.924041] ath: Enable TXE on queue: 9
[ 577.026404] ath: Enable TXE on queue: 9
[ 577.128809] ath: Enable TXE on queue: 9
[ 577.231203] ath: Enable TXE on queue: 9
[ 577.333589] ath: Enable TXE on queue: 9
[ 577.435986] ath: Enable TXE on queue: 9
[ 577.538387] ath: Enable TXE on queue: 9
[ 577.640834] ath: Enable TXE on queue: 9
[ 577.743186] ath: Enable TXE on queue: 9
[ 577.845593] ath: Enable TXE on queue: 9
[ 577.947986] ath: Enable TXE on queue: 9
[ 578.050372] ath: Enable TXE on queue: 9
[ 578.152823] ath: Enable TXE on queue: 9
[ 578.255175] ath: Enable TXE on queue: 9
[ 578.357573] ath: Enable TXE on queue: 9
[ 578.459970] ath: Enable TXE on queue: 9
[ 578.562363] ath: Enable TXE on queue: 9
[ 578.664793] ath: Enable TXE on queue: 9
[ 578.767159] ath: Enable TXE on queue: 9
[ 578.869553] ath: Enable TXE on queue: 9
[ 578.971949] ath: Enable TXE on queue: 9
[ 579.074347] ath: Enable TXE on queue: 9
[ 579.176751] ath: Enable TXE on queue: 9
[ 579.279147] ath: Enable TXE on queue: 9
[ 579.381592] ath: Enable TXE on queue: 9
[ 579.483945] ath: Enable TXE on queue: 9
[ 579.586339] ath: Enable TXE on queue: 9
[ 579.688730] ath: Enable TXE on queue: 9
[ 579.791131] ath: Enable TXE on queue: 9
[ 579.893564] ath: Enable TXE on queue: 9
[ 579.995919] ath: Enable TXE on queue: 9
[ 580.098316] ath: Enable TXE on queue: 9
[ 580.200722] ath: Enable TXE on queue: 9
[ 580.303114] ath: Enable TXE on queue: 9
[ 580.405526] ath: Enable TXE on queue: 9
[ 580.507907] ath: Enable TXE on queue: 9
[ 580.610308] ath: Enable TXE on queue: 9
[ 580.712702] ath: Enable TXE on queue: 9
[ 580.815106] ath: Enable TXE on queue: 9
[ 580.917496] ath: Enable TXE on queue: 9
[ 581.019892] ath: Enable TXE on queue: 9
[ 581.122337] ath: Enable TXE on queue: 9
[ 581.224692] ath: Enable TXE on queue: 9
[ 581.327082] ath: Enable TXE on queue: 9
[ 581.429485] ath: Enable TXE on queue: 9
[ 581.531882] ath: Enable TXE on queue: 9
[ 581.634308] ath: Enable TXE on queue: 9
[ 581.736672] ath: Enable TXE on queue: 9
[ 581.839070] ath: Enable TXE on queue: 9
[ 581.941469] ath: Enable TXE on queue: 9
[ 582.043873] ath: Enable TXE on queue: 9
[ 582.146288] ath: Enable TXE on queue: 9
[ 582.248664] ath: Enable TXE on queue: 9
[ 582.351054] ath: Enable TXE on queue: 9
[ 582.453454] ath: Enable TXE on queue: 9
[ 582.555857] ath: Enable TXE on queue: 9
[ 582.658256] ath: Enable TXE on queue: 9
[ 582.760643] ath: Enable TXE on queue: 9
[ 582.863090] ath: Enable TXE on queue: 9
[ 582.965450] ath: Enable TXE on queue: 9
[ 583.067847] ath: Enable TXE on queue: 9
[ 583.170237] ath: Enable TXE on queue: 9
[ 583.272634] ath: Enable TXE on queue: 9
[ 583.375065] ath: Enable TXE on queue: 9
[ 583.477429] ath: Enable TXE on queue: 9
[ 583.579826] ath: Enable TXE on queue: 9
[ 583.682228] ath: Enable TXE on queue: 9
[ 583.784627] ath: Enable TXE on queue: 9
[ 583.887024] ath: Enable TXE on queue: 9
[ 583.989414] ath: Enable TXE on queue: 9
[ 584.091867] ath: Enable TXE on queue: 9
[ 584.194207] ath: Enable TXE on queue: 9
[ 584.296603] ath: Enable TXE on queue: 9
[ 584.399002] ath: Enable TXE on queue: 9
[ 584.501401] ath: Enable TXE on queue: 9
[ 584.603841] ath: Enable TXE on queue: 9
[ 584.706197] ath: Enable TXE on queue: 9
[ 584.808599] ath: Enable TXE on queue: 9
[ 584.910990] ath: Enable TXE on queue: 9
[ 585.013390] ath: Enable TXE on queue: 9
[ 585.115810] ath: Enable TXE on queue: 9
[ 585.218186] ath: Enable TXE on queue: 9
[ 585.320578] ath: Enable TXE on queue: 9
[ 585.422982] ath: Enable TXE on queue: 9
[ 585.525379] ath: Enable TXE on queue: 9
[ 585.627771] ath: Enable TXE on queue: 9
[ 585.730166] ath: Enable TXE on queue: 9
[ 585.832622] ath: Enable TXE on queue: 9
[ 585.934957] ath: Enable TXE on queue: 9
[ 586.037370] ath: Enable TXE on queue: 9
[ 586.139772] ath: Enable TXE on queue: 9
[ 586.242158] ath: Enable TXE on queue: 9
[ 586.344587] ath: Enable TXE on queue: 9
[ 586.446947] ath: Enable TXE on queue: 9
[ 586.549348] ath: Enable TXE on queue: 9
[ 586.651748] ath: Enable TXE on queue: 9
[ 586.754137] ath: Enable TXE on queue: 9
[ 586.856552] ath: Enable TXE on queue: 9
[ 586.958936] ath: Enable TXE on queue: 9
[ 587.061339] ath: Enable TXE on queue: 9
[ 587.163731] ath: Enable TXE on queue: 9
[ 587.266125] ath: Enable TXE on queue: 9
[ 587.368522] ath: Enable TXE on queue: 9
[ 587.470922] ath: Enable TXE on queue: 9
[ 587.573366] ath: Enable TXE on queue: 9
[ 587.675716] ath: Enable TXE on queue: 9
[ 587.778118] ath: Enable TXE on queue: 9
[ 587.880508] ath: Enable TXE on queue: 9
[ 587.982912] ath: Enable TXE on queue: 9
[ 588.085345] ath: Enable TXE on queue: 9
[ 588.187705] ath: Enable TXE on queue: 9
[ 588.290108] ath: Enable TXE on queue: 9
[ 588.392494] ath: Enable TXE on queue: 9
[ 588.494893] ath: Enable TXE on queue: 9
[ 588.597289] ath: Enable TXE on queue: 9
[ 588.699696] ath: Enable TXE on queue: 9
[ 588.802134] ath: Enable TXE on queue: 9
[ 588.904478] ath: Enable TXE on queue: 9
[ 589.006885] ath: Enable TXE on queue: 9
[ 589.109276] ath: Enable TXE on queue: 9
[ 589.211674] ath: Enable TXE on queue: 9
[ 589.314120] ath: Enable TXE on queue: 9
[ 589.416464] ath: Enable TXE on queue: 9
[ 589.518861] ath: Enable TXE on queue: 9
[ 589.621271] ath: Enable TXE on queue: 9
[ 589.723665] ath: Enable TXE on queue: 9
[ 589.826095] ath: Enable TXE on queue: 9
[ 589.928452] ath: Enable TXE on queue: 9
[ 590.030855] ath: Enable TXE on queue: 9
[ 590.133255] ath: Enable TXE on queue: 9
[ 590.235646] ath: Enable TXE on queue: 9
[ 590.338045] ath: Enable TXE on queue: 9
[ 590.440437] ath: Enable TXE on queue: 9
[ 590.542882] ath: Enable TXE on queue: 9
[ 590.645237] ath: Enable TXE on queue: 9
[ 590.747627] ath: Enable TXE on queue: 9
[ 590.850028] ath: Enable TXE on queue: 9
[ 590.952428] ath: Enable TXE on queue: 9
[ 591.054865] ath: Enable TXE on queue: 9
[ 591.157228] ath: Enable TXE on queue: 9
[ 591.259622] ath: Enable TXE on queue: 9
[ 591.362016] ath: Enable TXE on queue: 9
[ 591.464416] ath: Enable TXE on queue: 9
[ 591.566828] ath: Enable TXE on queue: 9
[ 591.669215] ath: Enable TXE on queue: 9
[ 591.771604] ath: Enable TXE on queue: 9
[ 591.874003] ath: Enable TXE on queue: 9
[ 591.976405] ath: Enable TXE on queue: 9
[ 592.078806] ath: Enable TXE on queue: 9
[ 592.181201] ath: Enable TXE on queue: 9
[ 592.283649] ath: Enable TXE on queue: 9
[ 592.385993] ath: Enable TXE on queue: 9
[ 592.488387] ath: Enable TXE on queue: 9
[ 592.590786] ath: Enable TXE on queue: 9
[ 592.693186] ath: Enable TXE on queue: 9
[ 592.795611] ath: Enable TXE on queue: 9
[ 592.897975] ath: Enable TXE on queue: 9
[ 593.000381] ath: Enable TXE on queue: 9
[ 593.102772] ath: Enable TXE on queue: 9
[ 593.205170] ath: Enable TXE on queue: 9
[ 593.307568] ath: Enable TXE on queue: 9
[ 593.409963] ath: Enable TXE on queue: 9
[ 593.512358] ath: Enable TXE on queue: 9
[ 593.614759] ath: Enable TXE on queue: 9
[ 593.717149] ath: Enable TXE on queue: 9
[ 593.819548] ath: Enable TXE on queue: 9
[ 593.921958] ath: Enable TXE on queue: 9
[ 594.024388] ath: Enable TXE on queue: 9
[ 594.126741] ath: Enable TXE on queue: 9
[ 594.229140] ath: Enable TXE on queue: 9
[ 594.331537] ath: Enable TXE on queue: 9
[ 594.433940] ath: Enable TXE on queue: 9
[ 594.536366] ath: Enable TXE on queue: 9
[ 594.638731] ath: Enable TXE on queue: 9
[ 594.741125] ath: Enable TXE on queue: 9
[ 594.843521] ath: Enable TXE on queue: 9
[ 594.945917] ath: Enable TXE on queue: 9
[ 595.048340] ath: Enable TXE on queue: 9
[ 595.150714] ath: Enable TXE on queue: 9
[ 595.253167] ath: Enable TXE on queue: 9
[ 595.355505] ath: Enable TXE on queue: 9
[ 595.457913] ath: Enable TXE on queue: 9
[ 595.560303] ath: Enable TXE on queue: 9
[ 595.662703] ath: Enable TXE on queue: 9
[ 595.765141] ath: Enable TXE on queue: 9
[ 595.867498] ath: Enable TXE on queue: 9
[ 595.969895] ath: Enable TXE on queue: 9
[ 596.072298] ath: Enable TXE on queue: 9
[ 596.174687] ath: Enable TXE on queue: 9
[ 596.277116] ath: Enable TXE on queue: 9
[ 596.379487] ath: Enable TXE on queue: 9
[ 596.481881] ath: Enable TXE on queue: 9
[ 596.584280] ath: Enable TXE on queue: 9
[ 596.686673] ath: Enable TXE on queue: 9
[ 596.789068] ath: Enable TXE on queue: 9
[ 596.891468] ath: Enable TXE on queue: 9
[ 596.993912] ath: Enable TXE on queue: 9
[ 597.096263] ath: Enable TXE on queue: 9
[ 597.198659] ath: Enable TXE on queue: 9
[ 597.301055] ath: Enable TXE on queue: 9
[ 597.403450] ath: Enable TXE on queue: 9
[ 597.505888] ath: Enable TXE on queue: 9
[ 597.608248] ath: Enable TXE on queue: 9
[ 597.710655] ath: Enable TXE on queue: 9
[ 597.813050] ath: Enable TXE on queue: 9
[ 597.915446] ath: Enable TXE on queue: 9
[ 598.017881] ath: Enable TXE on queue: 9
[ 598.120235] ath: Enable TXE on queue: 9
[ 598.222630] ath: Enable TXE on queue: 9
[ 599.148292] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 599.159148] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 599.170789] ath: Reset TX queue: 0
[ 599.174242] ath: Reset TX queue: 1
[ 599.177684] ath: Reset TX queue: 2
[ 599.181127] ath: Reset TX queue: 3
[ 599.184575] ath: Reset TXQ, inactive queue: 4
[ 599.188976] ath: Reset TXQ, inactive queue: 5
[ 599.193368] ath: Reset TXQ, inactive queue: 6
[ 599.197762] ath: Reset TXQ, inactive queue: 7
[ 599.202157] ath: Reset TX queue: 8
[ 599.205605] ath: Reset TX queue: 9
[ 599.211798] ath: Set queue properties for: 9
[ 599.216128] ath: Reset TX queue: 9
[ 599.311924] ath: Enable TXE on queue: 9
[ 600.237580] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 600.248425] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 600.267322] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 600.275012] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 600.283526] ------------[ cut here ]------------
[ 600.288203] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:509 ath_stoprecv+0xb7/0xc9 [ath9k]()
[ 600.297198] Hardware name: To be filled by O.E.M.
[ 600.301934] Modules linked in: ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 [last unloaded: cfg80211]
[ 600.311932] Pid: 0, comm: swapper Tainted: G W 2.6.38-rc6-wl-12525-g2f478dd #24
[ 600.320045] Call Trace:
[ 600.322549] [<c01288c2>] ? warn_slowpath_common+0x6a/0x7f
[ 600.328082] [<fa74bbcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k]
[ 600.333614] [<c01288eb>] ? warn_slowpath_null+0x14/0x18
[ 600.338974] [<fa74bbcb>] ? ath_stoprecv+0xb7/0xc9 [ath9k]
[ 600.344512] [<fa748d37>] ? ath_reset+0x6b/0x185 [ath9k]
[ 600.349876] [<fa746aa9>] ? ath9k_ioread32+0x56/0x60 [ath9k]
[ 600.355587] [<fa745186>] ? ath_beacon_tasklet+0xad/0x63c [ath9k]
[ 600.361733] [<c014564e>] ? local_clock+0x2d/0x4e
[ 600.366492] [<c014dbc8>] ? lock_release_holdtime+0x1a/0x10e
[ 600.372198] [<c037a05d>] ? _raw_spin_unlock_irq+0x27/0x2b
[ 600.377724] [<c037a31c>] ? restore_all_notrace+0x0/0x18
[ 600.383081] [<c0233190>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 600.388786] [<c012d825>] ? tasklet_action+0x3a/0xd9
[ 600.393793] [<c012d858>] ? tasklet_action+0x6d/0xd9
[ 600.398803] [<c012df14>] ? __do_softirq+0xb1/0x16a
[ 600.403724] [<c012de63>] ? __do_softirq+0x0/0x16a
[ 600.408551] <IRQ> [<c012d62a>] ? irq_exit+0x3a/0x3c
[ 600.413713] [<c0103dc2>] ? do_IRQ+0x81/0x95
[ 600.418028] [<c0102d6e>] ? common_interrupt+0x2e/0x34
[ 600.423215] [<c037a09e>] ? _raw_spin_unlock_irqrestore+0x3d/0x41
[ 600.429350] [<c014b0b3>] ? clockevents_notify+0xcd/0xd4
[ 600.434708] [<c0279f27>] ? lapic_timer_state_broadcast+0x36/0x39
[ 600.440840] [<c027a4d8>] ? acpi_idle_enter_bm+0x267/0x27f
[ 600.446377] [<c02ef3cf>] ? cpuidle_idle_call+0xee/0x183
[ 600.451734] [<c0101aec>] ? cpu_idle+0x44/0x5c
[ 600.456228] [<c0368d5e>] ? rest_init+0x92/0x97
[ 600.460806] [<c04f4884>] ? start_kernel+0x2d7/0x2dc
[ 600.465821] [<c04f40d2>] ? i386_start_kernel+0xd2/0xd9
[ 600.471084] ---[ end trace 90d0638f5273e6d8 ]---
[ 600.487573] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 600.499749] ath: Reset TX queue: 0
[ 600.503206] ath: Reset TX queue: 1
[ 600.506649] ath: Reset TX queue: 2
[ 600.510089] ath: Reset TX queue: 3
[ 600.513532] ath: Reset TXQ, inactive queue: 4
[ 600.517930] ath: Reset TXQ, inactive queue: 5
[ 600.522325] ath: Reset TXQ, inactive queue: 6
[ 600.526718] ath: Reset TXQ, inactive queue: 7
[ 600.531113] ath: Reset TX queue: 8
[ 600.534561] ath: Reset TX queue: 9
[ 600.540762] ath: Set queue properties for: 9
[ 600.545091] ath: Reset TX queue: 9
[ 600.640849] ath: Enable TXE on queue: 9
[ 601.566512] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 601.577368] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 601.596278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 601.603968] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 601.624273] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 601.636474] ath: Reset TX queue: 0
[ 601.639931] ath: Reset TX queue: 1
[ 601.643375] ath: Reset TX queue: 2
[ 601.646814] ath: Reset TX queue: 3
[ 601.650255] ath: Reset TXQ, inactive queue: 4
[ 601.654648] ath: Reset TXQ, inactive queue: 5
[ 601.659040] ath: Reset TXQ, inactive queue: 6
[ 601.663433] ath: Reset TXQ, inactive queue: 7
[ 601.667826] ath: Reset TX queue: 8
[ 601.671277] ath: Reset TX queue: 9
[ 601.677477] ath: Set queue properties for: 9
[ 601.681806] ath: Reset TX queue: 9
[ 601.777567] ath: Enable TXE on queue: 9
[ 602.703270] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 602.714126] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 602.733107] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 602.740800] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 602.761182] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 602.773405] ath: Reset TX queue: 0
[ 602.776860] ath: Reset TX queue: 1
[ 602.780308] ath: Reset TX queue: 2
[ 602.783748] ath: Reset TX queue: 3
[ 602.787190] ath: Reset TXQ, inactive queue: 4
[ 602.791590] ath: Reset TXQ, inactive queue: 5
[ 602.795982] ath: Reset TXQ, inactive queue: 6
[ 602.800377] ath: Reset TXQ, inactive queue: 7
[ 602.804771] ath: Reset TX queue: 8
[ 602.808221] ath: Reset TX queue: 9
[ 602.814422] ath: Set queue properties for: 9
[ 602.818753] ath: Reset TX queue: 9
[ 602.914530] ath: Enable TXE on queue: 9
[ 603.840166] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 603.851022] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 603.869909] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 603.877600] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 603.897916] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 603.910127] ath: Reset TX queue: 0
[ 603.913581] ath: Reset TX queue: 1
[ 603.917023] ath: Reset TX queue: 2
[ 603.920462] ath: Reset TX queue: 3
[ 603.923905] ath: Reset TXQ, inactive queue: 4
[ 603.928307] ath: Reset TXQ, inactive queue: 5
[ 603.932699] ath: Reset TXQ, inactive queue: 6
[ 603.937091] ath: Reset TXQ, inactive queue: 7
[ 603.941484] ath: Reset TX queue: 8
[ 603.944936] ath: Reset TX queue: 9
[ 603.951134] ath: Set queue properties for: 9
[ 603.955466] ath: Reset TX queue: 9
[ 604.051225] ath: Enable TXE on queue: 9
[ 604.976891] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 604.987746] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 605.006735] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 605.014430] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 605.034754] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 605.046956] ath: Reset TX queue: 0
[ 605.050411] ath: Reset TX queue: 1
[ 605.053854] ath: Reset TX queue: 2
[ 605.057303] ath: Reset TX queue: 3
[ 605.060788] ath: Reset TXQ, inactive queue: 4
[ 605.065192] ath: Reset TXQ, inactive queue: 5
[ 605.069590] ath: Reset TXQ, inactive queue: 6
[ 605.073982] ath: Reset TXQ, inactive queue: 7
[ 605.078376] ath: Reset TX queue: 8
[ 605.081826] ath: Reset TX queue: 9
[ 605.088038] ath: Set queue properties for: 9
[ 605.092366] ath: Reset TX queue: 9
[ 605.188161] ath: Enable TXE on queue: 9
[ 606.113820] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 606.124675] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 606.143583] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 606.151275] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 606.171592] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 606.183782] ath: Reset TX queue: 0
[ 606.187241] ath: Reset TX queue: 1
[ 606.190683] ath: Reset TX queue: 2
[ 606.194133] ath: Reset TX queue: 3
[ 606.197581] ath: Reset TXQ, inactive queue: 4
[ 606.201982] ath: Reset TXQ, inactive queue: 5
[ 606.206374] ath: Reset TXQ, inactive queue: 6
[ 606.210767] ath: Reset TXQ, inactive queue: 7
[ 606.215160] ath: Reset TX queue: 8
[ 606.218611] ath: Reset TX queue: 9
[ 606.224803] ath: Set queue properties for: 9
[ 606.229131] ath: Reset TX queue: 9
[ 606.324880] ath: Enable TXE on queue: 9
[ 607.250573] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 607.261401] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 607.280294] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 607.287984] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 607.308292] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 607.320469] ath: Reset TX queue: 0
[ 607.323923] ath: Reset TX queue: 1
[ 607.327365] ath: Reset TX queue: 2
[ 607.330815] ath: Reset TX queue: 3
[ 607.334290] ath: Reset TXQ, inactive queue: 4
[ 607.338689] ath: Reset TXQ, inactive queue: 5
[ 607.343080] ath: Reset TXQ, inactive queue: 6
[ 607.347477] ath: Reset TXQ, inactive queue: 7
[ 607.351868] ath: Reset TX queue: 8
[ 607.355320] ath: Reset TX queue: 9
[ 607.361547] ath: Set queue properties for: 9
[ 607.365873] ath: Reset TX queue: 9
[ 607.461645] ath: Enable TXE on queue: 9
[ 608.387340] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 608.398185] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 608.417136] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 608.424832] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 608.445154] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 608.457373] ath: Reset TX queue: 0
[ 608.460829] ath: Reset TX queue: 1
[ 608.464273] ath: Reset TX queue: 2
[ 608.467720] ath: Reset TX queue: 3
[ 608.471162] ath: Reset TXQ, inactive queue: 4
[ 608.475564] ath: Reset TXQ, inactive queue: 5
[ 608.479964] ath: Reset TXQ, inactive queue: 6
[ 608.484358] ath: Reset TXQ, inactive queue: 7
[ 608.488750] ath: Reset TX queue: 8
[ 608.492201] ath: Reset TX queue: 9
[ 608.498401] ath: Set queue properties for: 9
[ 608.502730] ath: Reset TX queue: 9
[ 608.598520] ath: Enable TXE on queue: 9
[ 609.524198] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 609.535053] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 609.553987] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 609.561678] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 609.581992] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 609.594203] ath: Reset TX queue: 0
[ 609.597660] ath: Reset TX queue: 1
[ 609.601102] ath: Reset TX queue: 2
[ 609.604548] ath: Reset TX queue: 3
[ 609.607989] ath: Reset TXQ, inactive queue: 4
[ 609.612384] ath: Reset TXQ, inactive queue: 5
[ 609.616777] ath: Reset TXQ, inactive queue: 6
[ 609.621168] ath: Reset TXQ, inactive queue: 7
[ 609.625562] ath: Reset TX queue: 8
[ 609.629013] ath: Reset TX queue: 9
[ 609.635213] ath: Set queue properties for: 9
[ 609.639542] ath: Reset TX queue: 9
[ 609.735332] ath: Enable TXE on queue: 9
[ 610.660995] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 610.671842] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 610.690802] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 610.698499] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 610.718807] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 610.731028] ath: Reset TX queue: 0
[ 610.734476] ath: Reset TX queue: 1
[ 610.737922] ath: Reset TX queue: 2
[ 610.741371] ath: Reset TX queue: 3
[ 610.744810] ath: Reset TXQ, inactive queue: 4
[ 610.749205] ath: Reset TXQ, inactive queue: 5
[ 610.753605] ath: Reset TXQ, inactive queue: 6
[ 610.757998] ath: Reset TXQ, inactive queue: 7
[ 610.762391] ath: Reset TX queue: 8
[ 610.765842] ath: Reset TX queue: 9
[ 610.772045] ath: Set queue properties for: 9
[ 610.776372] ath: Reset TX queue: 9
[ 610.872125] ath: Enable TXE on queue: 9
[ 611.797822] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 611.808666] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 611.827561] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 611.835259] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 611.855601] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 611.867777] ath: Reset TX queue: 0
[ 611.871230] ath: Reset TX queue: 1
[ 611.874673] ath: Reset TX queue: 2
[ 611.878120] ath: Reset TX queue: 3
[ 611.881591] ath: Reset TXQ, inactive queue: 4
[ 611.885989] ath: Reset TXQ, inactive queue: 5
[ 611.890381] ath: Reset TXQ, inactive queue: 6
[ 611.894775] ath: Reset TXQ, inactive queue: 7
[ 611.899168] ath: Reset TX queue: 8
[ 611.902618] ath: Reset TX queue: 9
[ 611.908846] ath: Set queue properties for: 9
[ 611.913176] ath: Reset TX queue: 9
[ 612.008933] ath: Enable TXE on queue: 9
[ 612.934678] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 612.945534] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 612.964430] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 612.972121] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 612.992426] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 613.004684] ath: Reset TX queue: 0
[ 613.008137] ath: Reset TX queue: 1
[ 613.011578] ath: Reset TX queue: 2
[ 613.015037] ath: Reset TX queue: 3
[ 613.018479] ath: Reset TXQ, inactive queue: 4
[ 613.022878] ath: Reset TXQ, inactive queue: 5
[ 613.027271] ath: Reset TXQ, inactive queue: 6
[ 613.031666] ath: Reset TXQ, inactive queue: 7
[ 613.036060] ath: Reset TX queue: 8
[ 613.039509] ath: Reset TX queue: 9
[ 613.045703] ath: Set queue properties for: 9
[ 613.050030] ath: Reset TX queue: 9
[ 613.145822] ath: Enable TXE on queue: 9
[ 614.071505] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 614.082362] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 614.101292] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 614.108986] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 614.129346] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 614.141563] ath: Reset TX queue: 0
[ 614.145018] ath: Reset TX queue: 1
[ 614.148461] ath: Reset TX queue: 2
[ 614.151900] ath: Reset TX queue: 3
[ 614.155342] ath: Reset TXQ, inactive queue: 4
[ 614.159733] ath: Reset TXQ, inactive queue: 5
[ 614.164129] ath: Reset TXQ, inactive queue: 6
[ 614.168520] ath: Reset TXQ, inactive queue: 7
[ 614.172915] ath: Reset TX queue: 8
[ 614.176365] ath: Reset TX queue: 9
[ 614.182558] ath: Set queue properties for: 9
[ 614.186886] ath: Reset TX queue: 9
[ 614.282647] ath: Enable TXE on queue: 9
^C[ 614.494452] ath: qnum: 0, txq depth: 0
[ 614.498324] ath: Enable TXE on queue: 0
[ 614.522420] PM: Removing info for No Bus:mon.wlan0
[ 614.795955] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 614.806919] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 614.825618] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 614.836493] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 614.848169] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 614.859083] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 614.866350] ieee80211 phy0: device now idle
[ 615.052173] ath: Drop frames from hw queue:0
[ 615.060878] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 0
[ 615.071768] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 615.083072] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 9
[ 615.093887] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 615.105036] ath: ath9k_hw_stoptxdma: Num of pending TX Frames 1 on Q 0
[ 615.115854] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 615.122901] ath: Failed to stop TX DMA!
[ 615.138958] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 615.146659] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 615.167008] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 615.179248] ath: Reset TX queue: 0
[ 615.182707] ath: Reset TX queue: 1
[ 615.186158] ath: Reset TX queue: 2
[ 615.189605] ath: Reset TX queue: 3
[ 615.193055] ath: Reset TXQ, inactive queue: 4
[ 615.197505] ath: Reset TXQ, inactive queue: 5
[ 615.201905] ath: Reset TXQ, inactive queue: 6
[ 615.206304] ath: Reset TXQ, inactive queue: 7
[ 615.210700] ath: Reset TX queue: 8
[ 615.214158] ath: Reset TX queue: 9
[ 615.233921] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
[ 615.241624] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 615.255148] ath: Reset TX queue: 0
[ 615.258607] ath: Reset TX queue: 1
[ 615.262092] ath: Reset TX queue: 2
[ 615.265542] ath: Reset TX queue: 3
[ 615.268991] ath: Reset TXQ, inactive queue: 4
[ 615.273391] ath: Reset TXQ, inactive queue: 5
[ 615.277793] ath: Reset TXQ, inactive queue: 6
[ 615.282187] ath: Reset TXQ, inactive queue: 7
[ 615.286582] ath: Reset TX queue: 8
[ 615.290032] ath: Reset TX queue: 9
#
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 18:40 ` Adrian Chadd
@ 2011-02-23 23:06 ` Jouni Malinen
0 siblings, 0 replies; 26+ messages in thread
From: Jouni Malinen @ 2011-02-23 23:06 UTC (permalink / raw)
To: ath9k-devel
On Wed, 2011-02-23 at 10:40 -0800, Adrian Chadd wrote:
> The trouble is, I don't know if this macbook pro NIC (some broadcom
> 11n thing) is handing over garbage frames or not. I know it sometimes
> shows frames from ath9k with incorrect FCS, but that could be in-air
> garbage. So it's entirely possible there -was- a frame in there, but
> it was garbled to the point where the NIC couldn't decode it.
Yeah.. That was kind of the reason I wanted to see a capture trace, so
that I could look at the timing of the frames.
> I've also got a wireless capture file showing this exchange (which
> feels a lot more "validly" broken) :
>
>
> Ath9k -> STA : QoS Data (non-aggregate)
> STA->AP : ACK
> Ath9k -> STA : same frame
> STA->AP : ACK
> ..
> ..
> ..
> Ath9k -> STA: QoS data (same frame, again)
> STA-> AP : ACK
> You can find that at
> http://people.freebsd.org/~adrian/pcap4-sn-512-retrans.pcap
Which device is the ath9k device? The one with MAC address ending a2:2a?
There were some innovative uses of sequence number 512 in some frames,
but the payload was actually different even if the seq# did not change.
I don't think that those frames would be duplicated by ath9k (they could
be duplicated by mac80211). Which kernel/driver/mac80211 was used here?
> I also see the FreeBSD STA (AR9280) send multiple CTS-to-self before
> not sending an actual data frame.
Are you sure the TX descriptor for the frame that triggered this is set
correctly?
> Is there any way to stick an ath9k hostap interface in actual monitor
> mode, and get =all= the frames to show up on mon.wlan0 ? (So I can
> compare what ath9k thinks its sending/receiving, to what FreeBSD STA
> thinks its sending/receiving, to what's going on in the air) ? Or
> should I just hack the code to enable all the RX filter bits?
I don't think you would want all the frames on mon.wlan0, but adding
another monitor interface without using cooked mode could do more or
less this. Not that all frames would be seen since TX frames generated
in hardware (like ack) would not be indicated.
- Jouni
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 17:46 ` Luis R. Rodriguez
2011-02-23 18:12 ` Adrian Chadd
@ 2011-02-23 20:06 ` Bernhard Schmidt
2011-02-24 9:33 ` Bernhard Schmidt
2011-03-02 14:51 ` Mohammed Shafi
1 sibling, 2 replies; 26+ messages in thread
From: Bernhard Schmidt @ 2011-02-23 20:06 UTC (permalink / raw)
To: ath9k-devel
On Wednesday 23 February 2011 18:46:49 Luis R. Rodriguez wrote:
> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> > Hi,
> >
> > I have some issues using any of my AR9280 cards, identified as:
> > - Ubiquiti SR71E
> > [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11
> > - Sparklan WPEA-110N
> > [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11
> >
> > On a recent wireless-testing kernel:
> > # uname -a
> > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux
> >
> > I see this behaviour:
> > # hostapd /etc/hostapd.conf
> > % scan due to ht40
> > [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > ..
>
> This should not be fatal but we do want to fix it, it was just hard to reproduce.
> Can you paste your hostapd.conf ?
Will do that tomorrow when back at the office. Note, the error might
not be fatal, but, due it taking 100ms (see below), which is exactly
the beacon interval, no frames are sent. It is also not related to AP
mode, I see the exact same behavior in station mode. If I manage to get
through the association phase, it quickly goes deaf after the first
few packets.
> > % scan done, setting up the BSS
> > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > [ 296.083032] ath: Failed to stop TX DMA!
> > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> > % ..
>
> If its so easy to reproduce we can likely fix this for good!
Actually, haven't found a way to *not* reproduce it. :)
> Do you see the same issue if you just have one card plugged in or
> is this happening on two separate boxes?
It's one card at a time on this box. The monitor device is running on
another box. It is the only miniPCIe capable box I have around here
atm.
While playing around a bit with various debug options, I've noticed
that the amount of debug messages has an influence on when the issue
does occur. As in the more debug message, the sooner it will go deaf.
Smells racy somehow.
Will post a slightly more verbose log tomorrow.
--
Bernhard
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 18:24 ` Jouni Malinen
@ 2011-02-23 18:40 ` Adrian Chadd
2011-02-23 23:06 ` Jouni Malinen
0 siblings, 1 reply; 26+ messages in thread
From: Adrian Chadd @ 2011-02-23 18:40 UTC (permalink / raw)
To: ath9k-devel
Absolutely! I'll dig out some examples and fire them off.
The trouble is, I don't know if this macbook pro NIC (some broadcom 11n
thing) is handing over garbage frames or not. I know it sometimes shows
frames from ath9k with incorrect FCS, but that could be in-air garbage. So
it's entirely possible there -was- a frame in there, but it was garbled to
the point where the NIC couldn't decode it.
I've also got a wireless capture file showing this exchange (which feels a
lot more "validly" broken) :
Ath9k -> STA : QoS Data (non-aggregate)
STA->AP : ACK
Ath9k -> STA : same frame
STA->AP : ACK
..
..
..
Ath9k -> STA: QoS data (same frame, again)
STA-> AP : ACK
You can find that at
http://people.freebsd.org/~adrian/pcap4-sn-512-retrans.pcap
I also see the FreeBSD STA (AR9280) send multiple CTS-to-self before not
sending an actual data frame.
Is there any way to stick an ath9k hostap interface in actual monitor mode,
and get =all= the frames to show up on mon.wlan0 ? (So I can compare what
ath9k thinks its sending/receiving, to what FreeBSD STA thinks its
sending/receiving, to what's going on in the air) ? Or should I just hack
the code to enable all the RX filter bits?
Adrian
On 23 February 2011 13:24, Jouni Malinen <jouni.malinen@atheros.com> wrote:
> On Wed, 2011-02-23 at 10:20 -0800, Adrian Chadd wrote:
> > in fact, I lie - it's ath9k seemingly sending two ACKs for the same
> > frame.
>
> I don't remember having seen that and cannot really think of any reason
> that would cause this type of behavior. Would you happen to have a
> wireless capture file showing this?
>
> - Jouni
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/305204d4/attachment-0001.htm
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 18:20 ` Adrian Chadd
@ 2011-02-23 18:24 ` Jouni Malinen
2011-02-23 18:40 ` Adrian Chadd
0 siblings, 1 reply; 26+ messages in thread
From: Jouni Malinen @ 2011-02-23 18:24 UTC (permalink / raw)
To: ath9k-devel
On Wed, 2011-02-23 at 10:20 -0800, Adrian Chadd wrote:
> in fact, I lie - it's ath9k seemingly sending two ACKs for the same
> frame.
I don't remember having seen that and cannot really think of any reason
that would cause this type of behavior. Would you happen to have a
wireless capture file showing this?
- Jouni
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 18:12 ` Adrian Chadd
@ 2011-02-23 18:20 ` Adrian Chadd
2011-02-23 18:24 ` Jouni Malinen
0 siblings, 1 reply; 26+ messages in thread
From: Adrian Chadd @ 2011-02-23 18:20 UTC (permalink / raw)
To: ath9k-devel
in fact, I lie - it's ath9k seemingly sending two ACKs for the same frame.
Why would the hardware do that?
Adrian
On 23 February 2011 13:12, Adrian Chadd <adrian@freebsd.org> wrote:
> I can reproduce this with my FreeBSD STA talking to an AR9132-based AP
> running a recent (~ 2 weeks old) openwrt.
>
> There seems to be certain situations where the MAC gets completely confused
> and does crazy stuff like continuously retransmit a frame+ACK. It ends up as
> a BB hang on the STA side, and these messages on the AP side.
>
> I can't provide more info; I'll try to re-re-reproduce it when I'm back
> home in a couple weeks.
>
>
> Adrian
>
> On 23 February 2011 12:46, Luis R. Rodriguez <lrodriguez@atheros.com>wrote:
>
>> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
>> > Hi,
>> >
>> > I have some issues using any of my AR9280 cards, identified as:
>> > - Ubiquiti SR71E
>> > [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000,
>> irq=11
>> > - Sparklan WPEA-110N
>> > [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000,
>> irq=11
>> >
>> > On a recent wireless-testing kernel:
>> > # uname -a
>> > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23
>> 08:48:45 CET 2011 i686 GNU/Linux
>> >
>> > I see this behaviour:
>> > # hostapd /etc/hostapd.conf
>> > % scan due to ht40
>> > [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 289.397106] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 289.707992] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 289.887952] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 290.067926] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > ..
>>
>> This should not be fatal but we do want to fix it, it was just hard to
>> reproduce.
>> Can you paste your hostapd.conf ?
>>
>> > % scan done, setting up the BSS
>> > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last
>> frame
>> > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last
>> frame
>> > [ 296.083032] ath: Failed to stop TX DMA!
>> > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last
>> frame
>> > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA
>> engine when we start RX up
>> > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
>> AR_DIAG_SW=0x42000020
>> > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last
>> frame
>> > % ..
>>
>> If its so easy to reproduce we can likely fix this for good!
>>
>> Do you see the same issue if you just have one card plugged in or
>> is this happening on two separate boxes?
>>
>> Luis
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/b7fd1975/attachment.htm
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
2011-02-23 17:46 ` Luis R. Rodriguez
@ 2011-02-23 18:12 ` Adrian Chadd
2011-02-23 18:20 ` Adrian Chadd
2011-02-23 20:06 ` Bernhard Schmidt
1 sibling, 1 reply; 26+ messages in thread
From: Adrian Chadd @ 2011-02-23 18:12 UTC (permalink / raw)
To: ath9k-devel
I can reproduce this with my FreeBSD STA talking to an AR9132-based AP
running a recent (~ 2 weeks old) openwrt.
There seems to be certain situations where the MAC gets completely confused
and does crazy stuff like continuously retransmit a frame+ACK. It ends up as
a BB hang on the STA side, and these messages on the AP side.
I can't provide more info; I'll try to re-re-reproduce it when I'm back home
in a couple weeks.
Adrian
On 23 February 2011 12:46, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:
> On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> > Hi,
> >
> > I have some issues using any of my AR9280 cards, identified as:
> > - Ubiquiti SR71E
> > [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000,
> irq=11
> > - Sparklan WPEA-110N
> > [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000,
> irq=11
> >
> > On a recent wireless-testing kernel:
> > # uname -a
> > % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45
> CET 2011 i686 GNU/Linux
> >
> > I see this behaviour:
> > # hostapd /etc/hostapd.conf
> > % scan due to ht40
> > [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 289.397106] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 289.707992] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 289.887952] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 290.067926] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > ..
>
> This should not be fatal but we do want to fix it, it was just hard to
> reproduce.
> Can you paste your hostapd.conf ?
>
> > % scan done, setting up the BSS
> > [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last
> frame
> > [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last
> frame
> > [ 296.083032] ath: Failed to stop TX DMA!
> > [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 296.106884] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last
> frame
> > [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 297.190677] ath: Could not stop RX, we could be confusing the DMA
> engine when we start RX up
> > [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024
> AR_DIAG_SW=0x42000020
> > [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last
> frame
> > % ..
>
> If its so easy to reproduce we can likely fix this for good!
>
> Do you see the same issue if you just have one card plugged in or
> is this happening on two separate boxes?
>
> Luis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/77ec9d6b/attachment.htm
^ permalink raw reply [flat|nested] 26+ messages in thread
* [ath9k-devel] DMA issues with ar9280 cards
[not found] <201102230955.35674.bschmidt@techwires.net>
@ 2011-02-23 17:46 ` Luis R. Rodriguez
2011-02-23 18:12 ` Adrian Chadd
2011-02-23 20:06 ` Bernhard Schmidt
0 siblings, 2 replies; 26+ messages in thread
From: Luis R. Rodriguez @ 2011-02-23 17:46 UTC (permalink / raw)
To: ath9k-devel
On Wed, Feb 23, 2011 at 12:55:35AM -0800, Bernhard Schmidt wrote:
> Hi,
>
> I have some issues using any of my AR9280 cards, identified as:
> - Ubiquiti SR71E
> [ 172.321483] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf9760000, irq=11
> - Sparklan WPEA-110N
> [ 58.456404] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf8760000, irq=11
>
> On a recent wireless-testing kernel:
> # uname -a
> % Linux meshnode 2.6.38-rc6-wl-12466-g09f3227 #23 SMP Wed Feb 23 08:48:45 CET 2011 i686 GNU/Linux
>
> I see this behaviour:
> # hostapd /etc/hostapd.conf
> % scan due to ht40
> [ 289.389379] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 289.397106] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 289.548409] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 289.700270] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 289.707992] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 289.728509] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 289.880228] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 289.887952] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 289.908455] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 290.060168] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 290.067926] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> ..
This should not be fatal but we do want to fix it, it was just hard to reproduce.
Can you paste your hostapd.conf ?
> % scan done, setting up the BSS
> [ 296.060536] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 296.075985] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 296.083032] ath: Failed to stop TX DMA!
> [ 296.099187] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 296.106884] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 296.127247] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 297.163998] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 297.182977] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 297.190677] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
> [ 297.211004] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
> [ 298.247659] ath: Failed to stop TX DMA in 100 msec after killing last frame
> % ..
If its so easy to reproduce we can likely fix this for good!
Do you see the same issue if you just have one card plugged in or
is this happening on two separate boxes?
Luis
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-03-10 0:40 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-23 15:34 [ath9k-devel] DMA issues with ar9280 cards Bernhard Schmidt
2011-02-23 16:22 ` Peter Stuge
2011-02-23 18:02 ` Luis R. Rodriguez
2011-02-23 19:51 ` Peter Stuge
[not found] <201102230955.35674.bschmidt@techwires.net>
2011-02-23 17:46 ` Luis R. Rodriguez
2011-02-23 18:12 ` Adrian Chadd
2011-02-23 18:20 ` Adrian Chadd
2011-02-23 18:24 ` Jouni Malinen
2011-02-23 18:40 ` Adrian Chadd
2011-02-23 23:06 ` Jouni Malinen
2011-02-23 20:06 ` Bernhard Schmidt
2011-02-24 9:33 ` Bernhard Schmidt
2011-02-24 18:18 ` Luis R. Rodriguez
2011-02-25 9:37 ` Bernhard Schmidt
2011-02-25 17:12 ` Luis R. Rodriguez
2011-02-26 9:37 ` Bernhard Schmidt
2011-03-10 0:40 ` Felix Fietkau
2011-03-02 14:51 ` Mohammed Shafi
2011-03-04 11:29 ` Bernhard Schmidt
2011-03-04 15:25 ` Mohammed Shafi
2011-03-04 15:29 ` Mohammed Shafi
2011-03-04 17:16 ` Bernhard Schmidt
2011-03-09 9:58 ` Mohammed Shafi
2011-03-09 10:01 ` Mohammed Shafi
2011-03-05 23:49 ` crocket
2011-03-09 10:22 ` Peter Stuge
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.