Hi,
is it possible to cancel the hardware retransmissions of a packet
without receiving the corresponding hardware ACK and move on to the
next packet in the queue?
Thanks,
Stefan.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On Thursday 01 March 2012 11:09 AM, Mohammed Shafi Shajakhan wrote:
Hi Christian,
On Monday 27 February 2012 09:40 PM, Christian Lamparter wrote:
With the new tx status API: mac80211: implement wifi TX status
All skb originating from mac80211 needs to be given back to mac80211.
Signed-off-by:
On Thursday 01 March 2012 05:12 PM, Mohammed Shafi Shajakhan wrote:
On Thursday 01 March 2012 11:09 AM, Mohammed Shafi Shajakhan wrote:
Hi Christian,
On Monday 27 February 2012 09:40 PM, Christian Lamparter wrote:
With the new tx status API: mac80211: implement wifi TX status
All skb
Hi Christian,
On Monday 27 February 2012 10:02 PM, Christian Lamparter wrote:
With the new tx status API: mac80211: implement wifi TX status
All skb originating from mac80211 needs to be given back to mac80211.
Signed-off-by: Christian Lamparterchunk...@googlemail.com
---
It compiles, but
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
Work with someone who has hardware clue and just fix the problem.
completely agree, we got to fix it.
--
thanks,
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Hi everyone,
I read from Internet and archive of this mail list that TP-Link WN821Nv3
(using Atheros AR7010+AR9287) can't work. And that mail suggest this
issue related to virtualbox being used. I have come across the same problem.
Tested the device on Debian without using virtualbox, and it
Did disabling PM actually help?
Wysłane z iPoda
Dnia 1 mar 2012 o godz. 06:53 Kim Lidström dex...@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
On 1 March 2012 06:46, Peter Stuge pe...@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
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
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
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
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
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?
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
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.
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
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
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,
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
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
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
21 matches
Mail list logo
