Kim Lidström | 29 Feb 22:35 2012
Picon

"Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Hello!
A while ago I had a situation where my AR9485 would lock up the kernel
so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I
forgot his last name) were very patient in helping me and trying to
debug it through patches, etc. Nothing worked.
Eventually, though, I noticed that when I removed the atl1c module my
wlan started working. "Awesome!" I thought... Until I noticed this other
problem.

Once in a while, seemingly at random, the wlan dies with the error
messages in the title. And I can't possibly restore it without
restarting the computer.

With this message I have attached a log with the error messages.
This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
currently running 3.2.8.
For some reason it happened at least 3-4 times shortly after each other
today - so I thought I might ask on here what's happening.
[   13.010134] ath9k 0000:07:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[   13.010160] ath9k 0000:07:00.0: setting latency timer to 64
[   13.018216] ath: EEPROM regdomain: 0x65
[   13.018222] ath: EEPROM indicates we should expect a direct regpair map
[   13.018229] ath: Country alpha2 being used: 00
[   13.018233] ath: Regpair used: 0x65
[   13.045598] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control'
[   13.046709] Registered led device: ath9k-phy0
[  125.432441] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006100
[  125.438365] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
(Continue reading)

Adrian Chadd | 29 Feb 22:50 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Hi!

Which kernel didn't this happen in?

adrian
Adrian Chadd | 1 Mar 00:52 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Hi,

I don't recall _how_ to do this, but would you mind verifying whether
you're actually somehow using power saving modes or not?

Thanks,

Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mohammed Shafi | 1 Mar 06:09 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

> With this message I have attached a log with the error messages.
> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
> currently running 3.2.8.
> For some reason it happened at least 3-4 times shortly after each other
> today - so I thought I might ask on here what's happening.

disabling power save would be a nice idea,  to see if this issue disappears.
i got the same issue after a long stress test with some other card, sujith
gave me the idea to see if disabling PS helps
sudo iwconfig wlanX power off
sudo iw dev wlanX set power_save off
also please ensure that you run with your power adapter :) i noticed
PS gets enabled
via wext when we plug out the power adapter

--

-- 
thanks,
shafi
Kim Lidström | 1 Mar 06:53 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 03/01/2012 06:09 AM, Mohammed Shafi wrote:
>> With this message I have attached a log with the error messages.
>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>> currently running 3.2.8.
>> For some reason it happened at least 3-4 times shortly after each other
>> today - so I thought I might ask on here what's happening.
> 
> disabling power save would be a nice idea,  to see if this issue disappears.
> i got the same issue after a long stress test with some other card, sujith
> gave me the idea to see if disabling PS helps
> sudo iwconfig wlanX power off
> sudo iw dev wlanX set power_save off
> also please ensure that you run with your power adapter :) i noticed
> PS gets enabled
> via wext when we plug out the power adapter
> 

I just tried it and will see what happens! That might take a while,
though, because it seems to occur at random.

But you know something? The thought has struck me before that it might
have something to do with power saving. Interesting :)

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mieszko Ślusarczyk | 1 Mar 17:23 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Did disabling PM actually help?

Wysłane z iPoda

Dnia 1 mar 2012 o godz. 06:53 Kim Lidström <dexter <at> lacto.se> napisał(a):

> On 03/01/2012 06:09 AM, Mohammed Shafi wrote:
>>> With this message I have attached a log with the error messages.
>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>>> currently running 3.2.8.
>>> For some reason it happened at least 3-4 times shortly after each other
>>> today - so I thought I might ask on here what's happening.
>> 
>> disabling power save would be a nice idea,  to see if this issue disappears.
>> i got the same issue after a long stress test with some other card, sujith
>> gave me the idea to see if disabling PS helps
>> sudo iwconfig wlanX power off
>> sudo iw dev wlanX set power_save off
>> also please ensure that you run with your power adapter :) i noticed
>> PS gets enabled
>> via wext when we plug out the power adapter
>> 
> 
> I just tried it and will see what happens! That might take a while,
> though, because it seems to occur at random.
> 
> But you know something? The thought has struck me before that it might
> have something to do with power saving. Interesting :)
> 
> _______________________________________________
(Continue reading)

Kim Lidström | 2 Mar 07:21 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

So far it seems it's working. Haven't had a single issue for a day at
least, but that's not uncommon.

On 03/01/2012 05:23 PM, Mieszko Ślusarczyk wrote:
> Did disabling PM actually help?
> 
> Wysłane z iPoda
> 
> Dnia 1 mar 2012 o godz. 06:53 Kim Lidström <dexter <at> lacto.se> napisał(a):
> 
>> On 03/01/2012 06:09 AM, Mohammed Shafi wrote:
>>>> With this message I have attached a log with the error messages.
>>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>>>> currently running 3.2.8.
>>>> For some reason it happened at least 3-4 times shortly after each other
>>>> today - so I thought I might ask on here what's happening.
>>>
>>> disabling power save would be a nice idea,  to see if this issue disappears.
>>> i got the same issue after a long stress test with some other card, sujith
>>> gave me the idea to see if disabling PS helps
>>> sudo iwconfig wlanX power off
>>> sudo iw dev wlanX set power_save off
>>> also please ensure that you run with your power adapter :) i noticed
>>> PS gets enabled
>>> via wext when we plug out the power adapter
>>>
>>
>> I just tried it and will see what happens! That might take a while,
>> though, because it seems to occur at random.
>>
(Continue reading)

Peter Stuge | 1 Mar 15:46 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Mohammed Shafi wrote:
> disabling power save would be a nice idea,  to see if this issue
> disappears.

I can not understand why Atheros insists on recommending "disable
power saving" in response to this error which has been pouring out
of ath9k hardware and driver for YEARS!

It's baffling.

Work with someone who has hardware clue and just fix the problem.

//Peter
Mohammed Shafi | 1 Mar 16:04 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

> Work with someone who has hardware clue and just fix the problem.

completely agree, we got to fix it.

--

-- 
thanks,
shafi
Ben Greear | 1 Mar 18:50 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 03/01/2012 07:04 AM, Mohammed Shafi wrote:
>> Work with someone who has hardware clue and just fix the problem.
>
> completely agree, we got to fix it.
>

There are folks with machines that can reproduce this very easily.

Maybe offer to rent their system for some short time to
see if you can reproduce it in your lab?

I tried just getting their NICs and putting them in my own
systems, but though I could occassionally get the error to print (maybe once
every 2 days under full load) nothing locked up.  It must be exacerbated by some
interaction with other system components and/or the environment...

Thanks,
Ben

--

-- 
Ben Greear <greearb <at> candelatech.com>
Candela Technologies Inc  http://www.candelatech.com
Peter Stuge | 1 Mar 19:01 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Ben Greear wrote:
> >> Work with someone who has hardware clue and just fix the problem.
> >
> > completely agree, we got to fix it.
> 
> There are folks with machines that can reproduce this very easily.
> 
> Maybe offer to rent their system for some short time to
> see if you can reproduce it in your lab?

This is a great idea. It would be both easy and quick. There's of
course a very real risk that the problems do not occur in the lab
environment (that's actually what I expect) so in the end it might
be neccessary to go on a field trip to the original environment
instead.

But getting a machine into the lab takes a day or three with UPS
and doesn't cost very much, so it's a great first step. Even if it
doesn't work out it's so easy to try.

> It must be exacerbated by some interaction with other system
> components and/or the environment...

I suspect both, but moving the system to the lab is so easy that it
should absolutely be tried before moving the lab into the
environment. :)

//Peter
Sune Mølgaard | 1 Mar 20:05 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Ben Greear wrote:
> On 03/01/2012 07:04 AM, Mohammed Shafi wrote:
>>> Work with someone who has hardware clue and just fix the problem.
>>
>> completely agree, we got to fix it.
>>
>
> There are folks with machines that can reproduce this very easily.
>
> Maybe offer to rent their system for some short time to
> see if you can reproduce it in your lab?
>
> I tried just getting their NICs and putting them in my own
> systems, but though I could occassionally get the error to print (maybe once
> every 2 days under full load) nothing locked up.  It must be exacerbated by some
> interaction with other system components and/or the environment...
>
> Thanks,
> Ben
>

Sending my server anywhere would be inconvenient, but I could, perhaps, 
be persuaded to let 1, trustworthy, individual get an account and sudo 
rights on it.

In my case, the problem doesn't lock the machine, but, of course, halts 
the wlan connection in question...

Best,

(Continue reading)

Adrian Chadd | 1 Mar 18:02 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 1 March 2012 06:46, Peter Stuge <peter <at> stuge.se> wrote:
> Mohammed Shafi wrote:
>> disabling power save would be a nice idea,  to see if this issue
>> disappears.
>
> I can not understand why Atheros insists on recommending "disable
> power saving" in response to this error which has been pouring out
> of ath9k hardware and driver for YEARS!

.. to debug whether it is related to power saving support or not?

I've still left power saving modes and sleep mode support off in BSD
for now as, honestly, I don't have the time or the ridiculous array of
laptops required to debug this.. let alone my own personal PCIe
analyser.

Adrian
Peter Stuge | 1 Mar 18:23 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Adrian Chadd wrote:
> > I can not understand why Atheros insists on recommending "disable
> > power saving" in response to this error which has been pouring out
> > of ath9k hardware and driver for YEARS!
> 
> .. to debug whether it is related to power saving support or not?

That isn't debugging, it's just playing around with some knobs.

Debugging starts at the lowest layer and works upwards, not the other
way around.

> I've still left power saving modes and sleep mode support off in BSD
> for now as, honestly, I don't have the time or the ridiculous array
> of laptops required to debug this..

Indeed a concentrated effort and detailed hardware knowledge is
required to resolve the problem.

I don't expect that a single community member can do that. I do
however expect that Atheros can do it, either completely on their
own, or if not (because they can't reproduce the problem) then
*certainly* together with someone in the community who has a clue
about hardware.

This requires intimate cooperation and sharing of information that
will make lawyers run and scream in fear of FCC wrath or worse. I
couldn't care less. There's a significant technical problem and if
there is a way to fix it then do it. If it is *really* neccessary
then bring out some NDAs.
(Continue reading)

Felix Fietkau | 1 Mar 18:22 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-03-01 3:46 PM, Peter Stuge wrote:
> Mohammed Shafi wrote:
>> disabling power save would be a nice idea,  to see if this issue
>> disappears.
> 
> I can not understand why Atheros insists on recommending "disable
> power saving" in response to this error which has been pouring out
> of ath9k hardware and driver for YEARS!
> 
> It's baffling.
> 
> Work with someone who has hardware clue and just fix the problem.
If you weren't so locked up in your bitching and moaning habit, you
might have noticed that just because the error messages are similar does
not mean that it's just one bug that has been lurking in the driver for
years.

Just because one ore more symptoms are the same does not mean that the
issue has just one cause, or always leads to the same connectivity issues.

I remember at least 5 different issues that I fixed myself, which had
all led to these exact symptoms, but were otherwise unrelated to each
other and had different side effects.

On most chips with recent kernels, these issues tend to not be fatal
anymore, and at least on embedded hardware it's getting much harder to
find people that can still produce connection stability issues.

Sometimes I wonder why you keep wasting your energy on these rants,
which do *nothing* to fix the underlying issues. In fact, while I'm
(Continue reading)

Peter Stuge | 1 Mar 18:53 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Felix Fietkau wrote:
> just because the error messages are similar does not mean that it's
> just one bug that has been lurking in the driver for years.

I didn't say that it's a single issue, but it's clearly a single
class of issues, and I'm surprised that there is noone who can take a
hard look at DMA (with all required information at hand) and make it
reliable, even after so long time.

> Just because one ore more symptoms are the same does not mean that the
> issue has just one cause, or always leads to the same connectivity
> issues.

Absolutely right. And from the error messages alone "Failed to stop
DMA" it's clear that connectivity issues are really not so relevant
for debugging the issue, they are merely the symptom and thus not
really useful. The problem must be instrumented at a much lower
level.

> I remember at least 5 different issues that I fixed myself, which had
> all led to these exact symptoms, but were otherwise unrelated to each
> other and had different side effects.

You and Adrian have done and continue to do amazing work. But I don't
think that it's supposed to be you who solve these issues.

> On most chips with recent kernels, these issues tend to not be fatal
> anymore, and at least on embedded hardware it's getting much harder
> to find people that can still produce connection stability issues.

(Continue reading)

Felix Fietkau | 1 Mar 19:13 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-03-01 6:53 PM, Peter Stuge wrote:
> Felix Fietkau wrote:
>> just because the error messages are similar does not mean that it's
>> just one bug that has been lurking in the driver for years.
> 
> I didn't say that it's a single issue, but it's clearly a single
> class of issues, and I'm surprised that there is noone who can take a
> hard look at DMA (with all required information at hand) and make it
> reliable, even after so long time.
Saying it's a single class of issues does not help in any way, because
with the issues I've fixed so far, the cause has been wildly different.
Sometimes software race conditions, sometimes wrong register settings,
or sometimes actual issues in setting up DMA descriptors.

>> Just because one ore more symptoms are the same does not mean that the
>> issue has just one cause, or always leads to the same connectivity
>> issues.
> 
> Absolutely right. And from the error messages alone "Failed to stop
> DMA" it's clear that connectivity issues are really not so relevant
> for debugging the issue, they are merely the symptom and thus not
> really useful. The problem must be instrumented at a much lower
> level.
Instrumenting at a lower level does not necessarily help. Even if you
manage to capture all PCI bus traffic, there's still a good chance that
this won't help, because the problem could very well be in a completely
different layer. My hunch on this particular issue is that it's AR9485
specific, and there's simply a chipset difference compared to AR93xx
that may not have been accounted for in the driver yet.

(Continue reading)

Peter Stuge | 1 Mar 19:42 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Felix Fietkau wrote:
> Saying it's a single class of issues does not help in any way, because
> with the issues I've fixed so far, the cause has been wildly different.
> Sometimes software race conditions, sometimes wrong register settings,
> or sometimes actual issues in setting up DMA descriptors.

All affecting DMA.

> Instrumenting at a lower level does not necessarily help. Even if you
> manage to capture all PCI bus traffic, there's still a good chance that
> this won't help, because the problem could very well be in a completely
> different layer.

Yes, it depends on what the error is of course. But making
assumptions is not the way to do debugging.

> > Still, DMA is not exotic, and here are DMA problems again.
> 
> That last sentence makes no sense at all.

My point is that DMA by peripheral devices and the drivers to manage
it are established technologies in computer busses across the world,
so it keeps surprising me that drivers in 2012 get it wrong.

> > I think it's clear that the community will never have the opportunity
> > to work closely with Atheros on the lowest levels,
> 
> How do you define 'lowest level'?

An example would be to monitor state machines inside the device using
(Continue reading)

Peter Stuge | 1 Mar 19:51 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Peter Stuge wrote:
> Suggesting hardware reverse engineering in an open source driver
> development effort is, well, not what I expect.

To clarify a bit; we do this all the time in coreboot, but only for
vendors who aren't participating in the community, where we are left
with no other choice than the most inefficient method, if we want the
code to get done. The extra effort is of course quite prohibitive.

//Peter
Felix Fietkau | 1 Mar 20:18 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-03-01 7:42 PM, Peter Stuge wrote:
> Felix Fietkau wrote:
>> Saying it's a single class of issues does not help in any way, because
>> with the issues I've fixed so far, the cause has been wildly different.
>> Sometimes software race conditions, sometimes wrong register settings,
>> or sometimes actual issues in setting up DMA descriptors.
> 
> All affecting DMA.
You're missing the point *again*. Many of the things I found were
unrelated to DMA, but messed up the MAC state enough to trigger this
warning. Of course you could say that since the MAC also does DMA, the
problem must thereby somehow be DMA related, but using that to justify
your whining would be kind of stupid. Let's just drop the "it says DMA,
so it must be DMA related" nonsense.

>> Instrumenting at a lower level does not necessarily help. Even if you
>> manage to capture all PCI bus traffic, there's still a good chance that
>> this won't help, because the problem could very well be in a completely
>> different layer.
> 
> Yes, it depends on what the error is of course. But making
> assumptions is not the way to do debugging.
Right, that's why I'm trying to bust your assumption that starting with
the lowest layer is a good idea.

>> > Still, DMA is not exotic, and here are DMA problems again.
>> 
>> That last sentence makes no sense at all.
> 
> My point is that DMA by peripheral devices and the drivers to manage
(Continue reading)

Peter Stuge | 1 Mar 20:53 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Felix Fietkau wrote:
> >> Instrumenting at a lower level does not necessarily help. Even if you
> >> manage to capture all PCI bus traffic, there's still a good chance that
> >> this won't help, because the problem could very well be in a completely
> >> different layer.
> > 
> > Yes, it depends on what the error is of course. But making
> > assumptions is not the way to do debugging.
> 
> Right, that's why I'm trying to bust your assumption that starting
> with the lowest layer is a good idea.

No assumption involved.

> >> > Still, DMA is not exotic, and here are DMA problems again.
> >> 
> >> That last sentence makes no sense at all.
> > 
> > My point is that DMA by peripheral devices and the drivers to manage
> > it are established technologies in computer busses across the world,
> > so it keeps surprising me that drivers in 2012 get it wrong.
> 
> Which proves to me yet again that you're completely missing the point of
> what I'm saying about the likelihood of this being *NOT* DMA related.

It is, because the error leads to either or both sides thinking about
DMA when they should not.

> >> How do you define 'lowest level'?
> > 
(Continue reading)

Adrian Chadd | 1 Mar 21:26 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Hi,

It turns out that "stuff" is complicated.

Want to fix it? Atheros/Qualcomm may be hiring. :-)

As Felix said, the trouble with "stuck DMA" is that it's almost
guaranteed to be the symptom, not the cause. Same deal with "stuck
beacon". It turns out that so many weird and wonderful things have
lead to "stuck beacons", some of which we're still wading through. The
recent ANI patch (which I hope hasn't just been blindly accepted into
the tree, grr...) is just one example of this.

So, my original point still stands. If disabling power save fixes the
issue, then it can be added to a bug report (Kim - you posted a bug
report in bugzilla.kernel.org, right? :-) and someone can begin
looking into things further.

I'd love to give more useful feedback but I've _explicitly_ stayed
away from network/bus power saving stuff until I've finished off the
BSD 11n support and found/fixed all the weird little race conditions
that keep popping up. Yes, I'm that kind of engineer.

Adrian
Felix Fietkau | 1 Mar 21:40 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-03-01 8:53 PM, Peter Stuge wrote:
>> >> > Still, DMA is not exotic, and here are DMA problems again.
>> >> 
>> >> That last sentence makes no sense at all.
>> > 
>> > My point is that DMA by peripheral devices and the drivers to manage
>> > it are established technologies in computer busses across the world,
>> > so it keeps surprising me that drivers in 2012 get it wrong.
>> 
>> Which proves to me yet again that you're completely missing the point of
>> what I'm saying about the likelihood of this being *NOT* DMA related.
> 
> It is, because the error leads to either or both sides thinking about
> DMA when they should not.
Either or both sides of what? Thinking about DMA? That sentence
unfortunately makes no sense to me.

Most of the time when the driver tries to stop DMA, the hardware doesn't
respond in time, because either the MAC or the host interface state has
locked up. It can also be caused by the MAC not fully waking up from a
sleep state (hence the powersave related suggestion).

>> >> How do you define 'lowest level'?
>> > 
>> > An example would be to monitor state machines inside the device using
>> > side channel debugging, while in parallell monitoring state machines
>> > inside the driver. Then comparing them after the fact and seeing
>> > where one goes wrong. Find out why, and audit the complete driver for
>> > similar types of errors.
>> 
(Continue reading)

Peter Stuge | 1 Mar 22:27 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Felix Fietkau wrote:
> > It is, because the error leads to either or both sides thinking about
> > DMA when they should not.
> 
> Either or both sides of what? Thinking about DMA? That sentence
> unfortunately makes no sense to me.

One side = driver
Other side = hardware

> Most of the time when the driver tries to stop DMA, the hardware doesn't
> respond in time, because either the MAC or the host interface state has
> locked up. It can also be caused by the MAC not fully waking up from a
> sleep state (hence the powersave related suggestion).

I should have added "or not thinking about DMA when they should"
above. This is of course just as likely.

> In the early stages of debugging, you will usually *never* get data
> points that only mean one thing. One data point leads to ideas for
> further tests

Yes it can, but the issue I have with the powersave suggestion is
that I haven't seen followup discussion after the test has been done.

So the takeaway becomes "you can maybe avoid the problem by disabling
powersave" instead of "if you first disable powersave and that makes
the issue go away then you can look at this-and-this and poke
there-and-there in order to make the driver do that-and-that which
will show what to do next."
(Continue reading)

Sujith Manoharan | 2 Mar 01:38 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Peter Stuge wrote:
> I think you may be misunderstanding what I write.

I don't think anyone is misunderstanding anything about you, or
what you write.

Sujith
Peter Stuge | 2 Mar 03:21 2012
Picon

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

Sujith Manoharan wrote:
> I don't think anyone is misunderstanding anything about you, or
> what you write.

Sadly I don't know you guys, have only very briefly met Felix, and
from merely the discussions on the list there's only very little that
can be understood about me, as with everyone else. I think it would
be great to meet and chat about other things, but the community is
pretty small.

Anyway, I try to write very clearly, if inconveniently blunt at
times. And from Felix' response it seemed that he had misunderstood,
so I tried to clarify that I do not consider anything impossible.

My point is about quickly and reliably getting to the bottom of an
issue. I will take too much data over not enough data every time.

If it's possible to work with a complete picture, with both desired
and actual results in both driver and hardware, then the output of
the debugging effort ends up being excellent, and more will have been
learned underway by all involved than otherwise, which in turn leads
to even better understanding and quality in the future. But of course
there's always a tradeoff involved when determining how much time to
spend.

//Peter
Felix Fietkau | 7 Mar 18:29 2012

Re: [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-02-29 10:35 PM, Kim Lidström wrote:
> Hello!
> A while ago I had a situation where my AR9485 would lock up the kernel
> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I
> forgot his last name) were very patient in helping me and trying to
> debug it through patches, etc. Nothing worked.
> Eventually, though, I noticed that when I removed the atl1c module my
> wlan started working. "Awesome!" I thought... Until I noticed this other
> problem.
> 
> Once in a while, seemingly at random, the wlan dies with the error
> messages in the title. And I can't possibly restore it without
> restarting the computer.
> 
> With this message I have attached a log with the error messages.
> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
> currently running 3.2.8.
> For some reason it happened at least 3-4 times shortly after each other
> today - so I thought I might ask on here what's happening.
Please try this patch with powersave enabled, using a recent
compat-wireless build (3.3 or linux-next based):
http://nbd.name/ps-fix.patch

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Paul Farrow | 7 Mar 19:37 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485


On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote:
> On 2012-02-29 10:35 PM, Kim Lidström wrote:
>> Hello!
>> A while ago I had a situation where my AR9485 would lock up the 
>> kernel
>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. 
>> Sorry I
>> forgot his last name) were very patient in helping me and trying to
>> debug it through patches, etc. Nothing worked.
>> Eventually, though, I noticed that when I removed the atl1c module 
>> my
>> wlan started working. "Awesome!" I thought... Until I noticed this 
>> other
>> problem.
>>
>> Once in a while, seemingly at random, the wlan dies with the error
>> messages in the title. And I can't possibly restore it without
>> restarting the computer.
>>
>> With this message I have attached a log with the error messages.
>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>> currently running 3.2.8.
>> For some reason it happened at least 3-4 times shortly after each 
>> other
>> today - so I thought I might ask on here what's happening.
> Please try this patch with powersave enabled, using a recent
> compat-wireless build (3.3 or linux-next based):
> http://nbd.name/ps-fix.patch
>
(Continue reading)

Felix Fietkau | 7 Mar 20:42 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485

On 2012-03-07 7:37 PM, Paul Farrow wrote:
> 
> On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote:
>> On 2012-02-29 10:35 PM, Kim Lidström wrote:
>>> Hello!
>>> A while ago I had a situation where my AR9485 would lock up the 
>>> kernel
>>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. 
>>> Sorry I
>>> forgot his last name) were very patient in helping me and trying to
>>> debug it through patches, etc. Nothing worked.
>>> Eventually, though, I noticed that when I removed the atl1c module 
>>> my
>>> wlan started working. "Awesome!" I thought... Until I noticed this 
>>> other
>>> problem.
>>>
>>> Once in a while, seemingly at random, the wlan dies with the error
>>> messages in the title. And I can't possibly restore it without
>>> restarting the computer.
>>>
>>> With this message I have attached a log with the error messages.
>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>>> currently running 3.2.8.
>>> For some reason it happened at least 3-4 times shortly after each 
>>> other
>>> today - so I thought I might ask on here what's happening.
>> Please try this patch with powersave enabled, using a recent
>> compat-wireless build (3.3 or linux-next based):
>> http://nbd.name/ps-fix.patch
(Continue reading)

Paul Farrow | 7 Mar 20:55 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485


On Wed, 07 Mar 2012 20:42:35 +0100, Felix Fietkau wrote:
> On 2012-03-07 7:37 PM, Paul Farrow wrote:
>>
>> On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote:
>>> On 2012-02-29 10:35 PM, Kim Lidström wrote:
>>>> Hello!
>>>> A while ago I had a situation where my AR9485 would lock up the
>>>> kernel
>>>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm..
>>>> Sorry I
>>>> forgot his last name) were very patient in helping me and trying 
>>>> to
>>>> debug it through patches, etc. Nothing worked.
>>>> Eventually, though, I noticed that when I removed the atl1c module
>>>> my
>>>> wlan started working. "Awesome!" I thought... Until I noticed this
>>>> other
>>>> problem.
>>>>
>>>> Once in a while, seemingly at random, the wlan dies with the error
>>>> messages in the title. And I can't possibly restore it without
>>>> restarting the computer.
>>>>
>>>> With this message I have attached a log with the error messages.
>>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm
>>>> currently running 3.2.8.
>>>> For some reason it happened at least 3-4 times shortly after each
>>>> other
>>>> today - so I thought I might ask on here what's happening.
(Continue reading)

Paul Farrow | 7 Mar 19:35 2012

Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485


Hi Felix

I would like to try your patch to see if it stops my Tx DMA errors on 
my AR9280 chipset pcie card.

1. Do you think it might work?
2. What is the best way to apply this patch?

Please be gentle with me as I am linux hobbyist and I am keen to get my 
Tx DMA error problem sorted.

Thanks

Paul

On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote:
> On 2012-02-29 10:35 PM, Kim Lidström wrote:
>> Hello!
>> A while ago I had a situation where my AR9485 would lock up the 
>> kernel
>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. 
>> Sorry I
>> forgot his last name) were very patient in helping me and trying to
>> debug it through patches, etc. Nothing worked.
>> Eventually, though, I noticed that when I removed the atl1c module 
>> my
>> wlan started working. "Awesome!" I thought... Until I noticed this 
>> other
>> problem.
(Continue reading)


Gmane