Hi everyone,
I'm working on fixing up the FreeBSD Atheros support to work with the
AR9160 based Ubiquiti SR-71 module. I've been finding/fixing issues as
they creep up. One of these issues is the length of time it's taking
some units to complete periodic calibration. Although tackling that
Hi everyone,
I've run the local test APs here with the AR9160 without ADC DC and
ADC Gain calibration (but with IQ calibration) in 2.4ghz 11b/g mode
and they seem to be behaving themselves. Of course this is no
indication that it's how it -should- be done.
I'd still really appreciate some
August 2010 07:43, Torquil Macdonald Sørensen torq...@gmail.com wrote:
On 19/08/10 03:22, Adrian Chadd wrote:
So there's plenty of things you can vary given the current setup to
try and eliminate things.
* Can you buy one of those dlink units for testing? (ie, so your
testing doesn't interfere
Hi,
I've found a rather curious artifact of the calibration behaviour.
An AR9160 in 11a mode (5745mhz) with no clients attached can take tens
of minutes to complete the reset calibrations (IQ, ADC DC offset, ADC
DC gain.)
When passing 100 pps of 64 byte ICMP echo/response through the AP to
an
On 12 September 2010 05:00, madloi...@gmx.net madloi...@gmx.net wrote:
Anyway, unfortunately there is no real support for 5416 here, since
it's one of the oldest ath9k hardware around. The situation may
improve still, but I believe that will mostly be a side-effect of
other
.. can't believe i missed this.
I know the AR9100 support in the ath9k tree works with whatever's in
the AR9132. I'm using it at home (on openwrt) and I've been porting it
to freebsd.
So it's there and works. You have to look at what openwrt does - IIRC
the ahb stuff requires a little setting up
Hi!
Did you test this in 11abg mode? Or just 11n?
I've got a 3x3 AR9160 card which I'm considering disabling radio
chains on to compare performance. This seems like it's a useful thing.
Whilst talking about antennas, do you/anyone know how TX/RX antenna
setting/diversity works on the
Hi,
FreeBSD's AR9160 support enables all three RX chains in legacy mode.
The ath9k codebase doesn't - it calibrates all three chains, but the
ADC calibration results in legacy mode give 0x0's for chain 1 and 2.
Is there any benefit or detriment to leaving RX chains 1 and 2 enabled
when in
Hi guys,
(again with the FreeBSD specific questions; my apologies.)
I'm seeing RX phy errors with the error code 15. That isn't documented
in freebsd or ath9k. Would someone please let me know what that status
code means?
Thanks,
Adrian
___
Hi,
FreeBSD's AR9160 support enables all three RX chains in legacy mode.
The ath9k codebase doesn't - it calibrates all three chains, but the
ADC calibration results in legacy mode give all 0x0's for chain 1 and 2.
(And seemingly invalid results for chain 0 in 11g mode, but that's another
issue
On 28 September 2010 02:18, Luis R. Rodriguez lrodrig...@atheros.com wrote:
(again with the FreeBSD specific questions; my apologies.)
No need to apologize, feel free to use the list for FreeBSD as well,
we assume we use similar HALs, and since Atheros engineers do monitor
this list, its
On 28 September 2010 04:53, Luis R. Rodriguez lrodrig...@atheros.com wrote:
Strongly seconded. With 3 antennas on and using MRC, you get something
like an average of 7--10 dB (i.e. a factor of 4 to 10) more useful signal
power in indoor environments, precisely because of the impact of
On 28 September 2010 03:25, Felix ic.fe...@gmail.com wrote:
Is there any benefit or detriment to leaving RX chains 1 and 2 enabled
when in 11a/11bg mode? Does the unit do any kind of multipath
discrimination?
Leaving all RX chains enabled will give a huge gain for all OFDM rates,
they get
On 30 September 2010 05:42, David Lamparter equi...@diac24.net wrote:
I've now tried madwifi and ndiswrapper. To sum up:
Have you tried windows?
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Hi all,
I've been tinkering with the SR-71A card under FreeBSD to try and tease
something near full power out of it. I've been watching the values written
to AR_PHY_POWER_TX_RATEx and the output power for that given rate is
consistently 3dBm less than what the register value indicates. The card
On 17 November 2010 16:17, Kyle Creyts kyle.cre...@gmail.com wrote:
Breaking it down, I am trying to figure out (among a large number of
other things) how to (monitor for, and capture all ) vendor-specific
IEs from frames, to allow my application to see past port
virtualization, and identify
So it turns out that the SR-71A card TX power rates are quoted based
on the sum of all three chain TX'ing, rather than per-chain TX power.
Given that legacy frames are transmitted through all chains anyway
(there's no special handling in the TX path that limits the TX
chainmask to 1 for non-11n
wrote:
On Mon, Nov 29, 2010 at 1:49 PM, Adrian Chadd adrian.ch...@gmail.com wrote:
So it turns out that the SR-71A card TX power rates are quoted based
on the sum of all three chain TX'ing, rather than per-chain TX power.
Given that legacy frames are transmitted through all chains anyway
(there's
iw dev wlan0 station dump ?
adrian
2010/12/6 Stanley Lee im@msa.hinet.net:
Dear All:
Does anyone know that Wireless Client table is supported by Ath9k ?
I use the Ralink Driver that I can capture the the Wireless Client table in
/proc/wireless/assocMob_tab like below:
# more
7, 2010 at 9:56 PM, Adrian Chadd adr...@freebsd.org wrote:
Hi guys,
Since I've been knee-deep in the AR9160 power calibration code (And
I've been eyeballing the AR92xx TX power calibration code, in prep for
porting it all to FreeBSD) I can help you guys start diagnosing it.
Firstly, I know
On 8 December 2010 03:10, Blaise Gassend bla...@willowgarage.com wrote:
Turns out that this bug was fixed a couple of days ago by this patch
(but it still exists in eeprom_9287.c and ar9003_eeprom.c):
http://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg04380.html
It is unfortunate that
the rate registers
and AR_PHY_TX_POWER_SUB.
Then retry in 11bgn mode, but at 1mbit legacy rate if you can.
Adrian
On 8 December 2010 22:10, Brian Prodoehl bprodo...@gmail.com wrote:
On Wed, Dec 8, 2010 at 3:26 AM, Adrian Chadd adr...@freebsd.org wrote:
On 8 December 2010 03:10, Blaise Gassend
Hi,
This is just a complete guess on my part!
Try playing with the RX filter register (be evil perhaps and write
0x?); see if you begin receiving a steady stream of received
packets that aren't PHY decoding errors?
Adrian
On 19 December 2010 03:54, Brian Prodoehl bprodo...@gmail.com
I think a large part of the problem here is that the focus of the
active technical developers is elsewhere. You should see what trouble
I've had getting questions answered here for the pre-AR9200 stuff. :-)
Eg, trying to figure out the above - I have no idea. 10% of expected
performance is pretty
Hi all,
I'm trying to make the AR9220 work under FreeBSD but I get all manner
of strange 0xdeadc0de's in from register reads.
From my understanding of things, I'm guessing the chip or parts of the
chip haven't been woken up.
The AR9280 support works (for values of work) in FreeBSD, so I'm
On 22 January 2011 01:53, Pavel Roskin pro...@gnu.org wrote:
Would someone mind letting me know what this particular fix does and
why it's needed?
I don't know much about the meaning of that bit. My patch only changes the
way the fixup is applied. Instead of modifying the common table that
Hi,
In ar5008_phy.c:ar5008_hw_init_chain_masks(), some special case
happens for AR5416 v1.0 when the chainmask is configured for two
chains.
But the comparison seems bogus - it's checking if
hw_version.macVersion == AR_SREV_REVISION_5416_10; it's comparing the
revision rather than the MAC
Hi,
I'm debugging Linux ath9k (a tplink 1043ND) - FreeBSD AR9280 station
in 11n mode. The problem is RX'ing packets on the FreeBSD station.
The throughput problems I'm having can be traced down (so far) to
-lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
on all the phy
On 8 February 2011 06:10, Adrian Chadd adrian.ch...@gmail.com wrote:
The throughput problems I'm having can be traced down (so far) to
-lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
on all the phy error mask bits, I also get various OFDM and CCK
decoding errors
...@atheros.com wrote:
On Mon, Feb 07, 2011 at 11:56:02PM -0800, Adrian Chadd wrote:
On 8 February 2011 10:51, Brian Prodoehl bprodo...@gmail.com wrote:
You may want to look into adding some rough ANI, following the new
ANI routines in ath9k. Normally when the OFDM or CCK error rate rises
Hi,
From my understanding:
* If your RX chainmask has 1 radio enabled, you'll always be doing
receive-side diversity (which is really combining (MRC) if I
understand the technology correctly on multi-radio atheros 11n cards);
* If your TX chainmask has 1 radio enabled and the TX descriptor has
, or if it
don't really depend on that.
2011/2/16 Adrian Chadd adr...@freebsd.org
Hi,
From my understanding:
* If your RX chainmask has 1 radio enabled, you'll always be doing
receive-side diversity (which is really combining (MRC) if I
understand the technology correctly on multi-radio atheros 11n
I've been meaning to extend the radiotap API in FreeBSD to include the
ctl+ext RSSI/NF for each radio chain.
Perhaps it's time that both Linux and FreeBSD did this? Is there an existing
set of radiotap parameters (that FreeBSD currently doesn't have in its
header declarations) for MIMO radios?
I've had a lot of success with:
* tweaking things, and seeing what happens;
* asking the right questions at the right time.
I haven't had -all- of my questions answered, but I've so far managed to
glean enough from the email archives, patent filings and ath9k source to get
a good handle on how
I've been looking at why ath9k-FreeBSD HT performance is bad when AMPDU is
enabled, and I've seen some strange things.
In particular, I've seen sequences where out-of-order packets occur (which
is fine, apparently, even if the TX side -could- reorder things) -and-
duplicates inside the same
They're twice the power level because it's in 0.5 dbm increments.
The hardware has multiple TX power registers which define the upper TX power
for each of the rates, along with TX power for self-generated stuff, ACKs,
etc. With TPC enabled, they act as a cap for values programmed in the TX
Is the hardware in some kind of deep sleep state? Is this on a laptop? It's
an AR9280 (merlin) from that PCI ID, so I'd gather it's in a laptop of some
sort.
If so, can you disable any/all power saving mode(s) and see if that fixes
the PCIe probe?
Adrian
On 22 February 2011 00:56, Peter Stuge
On 22 February 2011 00:47, Peter Stuge pe...@stuge.se wrote:
Adrian Chadd wrote:
absolute lack of open discussion about anything firmware level
I've had a lot of success with:
* tweaking things, and seeing what happens;
This is reverse engineering by trial and error, not open
Are they both going out on the same hardware TX queue?
This may explain some of the weird stuff I've seen from ath9k when sending
aggregate frames..
Adrian
On 22 February 2011 15:00, yue zhao yuezhao...@gmail.com wrote:
Dear all,
Good day.
I have got a question about disorder of hw tx
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 adr...@freebsd.org wrote:
I can reproduce this with my FreeBSD STA talking to an AR9132-based AP
running a recent (~ 2 weeks old
February 2011 13:24, Jouni Malinen jouni.mali...@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
Nothing's stopping someone from forking ath9k (for example) and creating
ath9k-without-regulatory-enforcement. :-)
Adrian
On 23 February 2011 15:40, Peter Stuge pe...@stuge.se wrote:
Luis R. Rodriguez wrote:
Unfortunately due to regulatory considerations which have also come
under recent
Yup, if it's PCI (and not PCIe) then it's an AR9220.
Adrian
On 23 February 2011 21:33, Peter Stuge pe...@stuge.se wrote:
Adrian Chadd wrote:
It's an AR9280 (merlin) from that PCI ID,
Well, it's not PCIe, so probably not. But I guess 9220 (which this is
according to my pci.ids) and 9280
Hi everyone,
I've been porting over the open-loop tx power control handling from ath9k to
FreeBSD to fix TX stability issues.
( A big thankyou to Felix, Luis and others at Atheros for enlightening me
about Merlin TX power control.)
I have a few questions about how things are handled in ath9k
Hi guys,
Would you be interested in trying FreeBSD-current out on the AR9280/AR9285?
I'm in the middle of making it work for me under FreeBSD and if it works for
you, we can compare what ath9k does to what FreeBSD does wrt setting up and
managing the packet/queue/dma engines.
Adrian
I don't know, to be honest. Maybe FreeBSD/Debian (ie, FreeBSD kernel, debian
userland) would be a good midpoint?
Adrian
On 7 March 2011 14:17, Peter Stuge pe...@stuge.se wrote:
Adrian Chadd wrote:
Would you be interested in trying FreeBSD-current out on the
AR9280/AR9285?
I've been
I've found a couple places that hard-code setting up both chains (eg
open-loop TX power control, which initialises it for both chains in the same
location!) but that shouldn't matter.
There's a function which sets the TX chainmask based on the sleep/btcoex
mode, maybe you could try setting it to
It's set to whatever is in rs_antenna, which is:
mac.c: rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
I'm not sure what that represents on MIMO cards. Atheros people, any
feedback?
Adrian
On 10 March 2011 14:16, Jussi Haakana jussi.haak...@7signal.com wrote:
On 9.3.2011 18:04, Adrian
How about trying each of those patches one a time, to see exactly what
fixes performance for you?
Once that's established, you can start working on trying to identify what's
different in the AP-STA negotiation, then see if the radio is being
tickled differently, etc.
The trouble with doing so
it depends what you're trying to do.
Are you trying to dynamically change channel based on channel usage? Then
you can just look at mac80211; it already knows how to change channels.
It'll just call the driver to change the channel as appropriate. You don't
need to necessarily modify ath9k to do
I believe what you're seeing is normal behaviour - ie, every time you
associate, it updates the current regulatory domain based on the configured
regdomain and what the AP announces the regdomain is.
Luis would know better than I though. :)
Adrian
On 8 April 2011 12:18, Larry Vaden
On 9 April 2011 11:24, Larry Vaden va...@texoma.net wrote:
Q1. Does the detail below guarantee we are operating at maximum legal
power for the US on the M900 series?
It _seems_ that when we disconnect (see 2nd question below), cfg80211
_tries_ to take us to most restrictive regulatory
On 10 April 2011 22:52, Sujith m.suj...@gmail.com wrote:
How does a newb set power_save off on an AP?
PowerSave support is mandatory for AP mode operation,
so disabling it is not possible.
Wait, just to be clear, power save here in AP mode is to support when
stations go to sleep (and go
Incorrect or misplaced EEPROM/OTP data, perhaps?
From what I gather, the PCI ID on earlier devices is loaded out of EEPROM by
the silicon itself at power-on. 'abcd' sounds a bit too convenient to be
what's in EEPROM/OTP; so maybe it's a default value in the silicon?
(All just conjecture here at
Is there an easy way to get an EEPROM/OTP contents dump in ath9k?
Adrian
2011/4/11 Hasan Rashid hras...@avionica.com
That's exactly what I did, also, I had to add the vendor ID in the
hw_init function for the driver to fully load. I got it to work after making
these changes in the ath9k
On 12 April 2011 11:09, Sujith m.suj...@gmail.com wrote:
Adrian Chadd wrote:
There's actually something in 802.11h that handles switching channels.
Does mac80211 handle sending/receiving CSA?
Yep.
Cool.
Serene, see if you can find the code that handles CSA. This is where the AP
makes
On 12 April 2011 18:59, Yoo Kaku kaku...@gmail.com wrote:
informations are filled in ctl7. In our test, for example, ctl3 = 8b; and
AR_2040 is set in ctl7. Since we are sending a broadcast frame, rtsctsRate
is not set. But RX result on another host is not correct as we expected:
the
RX rate
It sounds like perhaps there's some initialization issues, maybe the PCI bus
isn't being fondled correctly, or the card/slot isn't being woken up
correctly.
It may not be an ath9k issue but it certainly sounds like something which
should be investigated.
Adrian
On 12 April 2011 23:04, Hasan
):
reg-current_rd=ETSI1_WORLD
There is nothing changed in the EEPROM so I don't think this would break
the module certification.
Best regards
On Wed, Apr 13, 2011 at 1:16 AM, Adrian Chadd adr...@freebsd.org wrote:
On 13 April 2011 02:42, Peter Stuge pe...@stuge.se wrote:
It is not allowed
On 15 April 2011 23:18, Larry Vaden va...@texoma.net wrote:
Peter and Adrian,
If this post is essentially asking to peek behind Atheros' kimono,
please disregard this post.
Is there any chance that the only diff between any two units is likely
to be the mac address and the regdomain?
IIRC, the packet duration calculations all assume non-greenfield timing?
Do any of the AR9003 chipsets support greenfield HT?
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
The xpaBiasLvlFreq parameter array is made up of 16 bit words which
aren't byte-swapped like the other 16-bit eeprom parameters are.
It's only used by the AR9160.
Signed-off-by: Adrian Chadd adr...@freebsd.org
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c
b/drivers/net/wireless/ath
The xpaBiasLvlFreq parameter array is made up of 16 bit words which
aren't byte-swapped like the other 16-bit eeprom parameters are.
It's only used by the AR9160.
Signed-off-by: Adrian Chadd adr...@freebsd.org
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c
b/drivers/net/wireless/ath
On 27 April 2011 15:52, Felix Fietkau n...@openwrt.org wrote:
I'm eager to test ath9k hardware with fbsd because Adrian indeed has
much more than a clue.
Sure, Adrian is good at what he does, but Atheros support in FreeBSD is
still quite a bit behind, because for a long time very little work
On 28 April 2011 01:03, John Nielsen li...@jnielsen.net wrote:
Regarding the other direction this thread has taken, I also thought that the
doom and gloom re: the status and future of ath9k was a bit overstated. It is
disappointing to not have more direct support from Atheros but at least
On 28 April 2011 09:27, Larry Vaden va...@texoma.net wrote:
There is one vendor in the marketplace where if you want layer 2
transparency on a p-t-p link, you VILL use WDS :(
What's broken about WDS? Just that you halve bandwidth?
Adrian
___
On 28 April 2011 09:25, Larry Vaden va...@texoma.net wrote:
Is http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
more or less the best reference for learning about bisecting patches?
I think so. I'm not really up to date for doing Linux bisecting. :-)
Adrian
On 29 April 2011 07:16, Christian Lamparter chunk...@googlemail.com wrote:
If you just want to dump the eeprom, then why not with a userspace utility?
It's pretty easy to write such a thing with libusb, furthermore it's more
versatile and portable so the *BSD-folks are not left out!
I've
On 29 April 2011 09:19, Sujith m.suj...@gmail.com wrote:
And BSD ? BSD is dead. Adrian is just deluded. :-)
I know. There's even a commit to ath9k from me that obviously indicates that. :)
But in all seriousness, I just wrote a few tools for BSD that:
* take a dump of the EEPROM via the HAL
Felix is the better person to speak to, as he coded up minstrel (and I
guess you're using that, right?)
Felix, is your thesis online?
Adrian
On 28 April 2011 17:36, Andreas Hofmann andreas.hofm...@corscience.de wrote:
Hello folks,
I am currently running wireless video transmissions over
On 29 April 2011 15:21, Mohammed Shafi shafi.at...@gmail.com wrote:
no ath9k rate control.
Where's that hiding in the source tree?
adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
On 29 April 2011 21:31, Andreas Hofmann andreas.hofm...@corscience.de wrote:
I did try that and it performed better than the default
ath9k-ratecontrol, but with focus on PER, the slowed down
ath9k-ratecontrol gave even better results. I did not inspect the
performance regarding maximum data
I've not come across it before. But you could in theory do a complete
chip reset? Or even put the chip completely to sleep (MAC + BB +
radio) and wake it up?
What do others think?
Adrian
On 6 May 2011 19:01, Daniel Weinlader d...@weinlader.org wrote:
I am planning on using an SR-71E (AR9280)
On 7 May 2011 06:53, Ben Greear gree...@candelatech.com wrote:
[top post]
Ok, there's likely some PCI init bugs going on here; would someone
with more background in this please take a look?
Adrian
This and the previous AR93xx 0xabcd device id post is starting to
sound a lot like
On 7 May 2011 11:42, Ben Greear gree...@candelatech.com wrote:
Ok, there's likely some PCI init bugs going on here; would someone
with more background in this please take a look?
I haven't had a chance to try this on the Atom system with the
latest 39-rc6+ kernels.. I'll try that on Monday.
Hi all,
I'm debugging some strange behaviour with the AR9285 on FreeBSD. I've
traced down my particular issue to the diversity code which I ported
verbatim from ath9k.
Has anyone seen the AR9285 diversity code make poor decisions about
which LNA configurations to use?
Here's an example:
Here's
On 10 May 2011 22:26, kang haiyang hyk...@dongniannetworks.com wrote:
hi,
i saw some configurations in this file, but don't know the function of
them.
Where can i found the document about them, and are they hardware
independent?
i mean that they are valid for all board with the
I'm not sure what you're talking about when you say chainmask 2 on the AP.
How many antennas does your AP have?
How are you configuring the chainmask and chain?
Adrian
On 11 May 2011 13:42, kang haiyang hyk...@dongniannetworks.com wrote:
hi,
I connected my AP with client by cable, both
On 13 May 2011 15:00, Sucheta ROY sucheta@st.com wrote:
When I plug AR9285 in some other Linux PC and repeat the experiment I see
the throughput at iperf client side (AR9285) is 300Mbps.But this time I used
two aerials on AR9285.
Is this a UDP test?
iperf client will report the UDP
On 16 May 2011 16:26, Sucheta ROY sucheta@st.com wrote:
I have checked in the data rate table at
http://en.wikipedia.org/wiki/IEEE_802.11n-2009 , for a 40MHz channel data
rate is 150 Mbps for MCS 7(Max that AR9285 can support). My question is, -
then how I can see 300Mbps at client
On 18 May 2011 09:09, Peter Stuge pe...@stuge.se wrote:
Mohammed Shafi wrote:
bits 8:4 MSI Interrupt vector
Cool!
but several things need to be addressed before enabling this interrupt
Which ones?
Is MSI really that important just yet? :-) An AR9285 is only going to
be doing up to
On 18 May 2011 04:46, Luis R. Rodriguez mcg...@gmail.com wrote:
Patches go first into wireless-next, then stable stuff goes into
wirless-2.6 (current RC), and then both of these get pulled into
wireless-testing, which provides the RC fixes + the next bits, on a
stable kernel (RC).
On 18 May 2011 09:16, Peter Stuge pe...@stuge.se wrote:
+ len = sprintf(buf, %1d\n, common-disable_ani);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
Note that %1d does not really guarantee the output length. The buffer
is 32 chars so it should be fine, but
On 20 May 2011 12:20, Alex Hacker hac...@epn.ru wrote:
On Tue, May 17, 2011 at 05:04:49PM -0700, Eduard GV wrote:
Understood, big thank you.
However, the noise floor shouldn't take only thermal noise into
account. Man-made noise could raise the noise floor more than 6dB in
the congested
Hi,
The AR9287 initial calibration in ar9002_hw_init_cal() isn't ever
called because the Kite check (AR_SREV_9285_12_OR_LATER()) matches on
MACs versioned Kite and later.
The Atheros newma code checks it is Kite as well as being Kite = 1.2.
I don't currently have Linux ath9k on something with
On 26 May 2011 20:26, Mohammed Shafi shafi.at...@gmail.com wrote:
did a quick preliminary tx throughput test not much difference.
What about RX sensitivity/errors?
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On 26 May 2011 21:15, Mohammed Shafi shafi.at...@gmail.com wrote:
What about RX sensitivity/errors?
should I look recv debug stats?
I'm not a chip developer, so I don't really know. :)
I hazard a guess that the rx calibration will affect RX sensitivity,
maybe CRC errors? Or maximum link
On 26 May 2011 22:48, Mohammed Shafi shafi.at...@gmail.com wrote:
I hazard a guess that the rx calibration will affect RX sensitivity,
maybe CRC errors? Or maximum link distance?
Hmmm ok, if you got a chip please test it. I will be very happy if
this patch improves some performance or
Since Daniel asked about how TX power is configured, I thought I'd
brain-dump the next few minutes of me going spelunking through the
AR9300 TX power code.
The ath9k driver arch has the TX power and calibration configured as
an eeprom op. The reason behind it is because the specifics of TX
Can you drop the TX power on the client and see if it works?
(Ie, I wonder if it's something to do with receive-side attenuation,
but then I don't have the foggiest clue about the workings of the
AR9300 series hardware.)
Adrian
On 1 June 2011 03:03, Daniel Halperin dhalp...@cs.washington.edu
This begs the question - why not write your own rate control module
that lets you fix the TX rates?
Adrian
On 1 June 2011 17:55, kcilc.dra...@mamber.net wrote:
Newbie here as well. I managed to fix the MCS, using an older message on
this list, but when the signal gets weaker, it dips into
On 26 May 2011 22:12, Dani Camps danicamp...@yahoo.com wrote:
Dear all,
I would like to know if mac80211/ath9k (or ath5k) have support for 802.11h
Quiet
Elements.
[snip]
But I can not find anywhere whether ath9k or ath5k act upon the parsed quiet
element in order to suspend
Hi!
On 2 June 2011 15:07, kang haiyang hyk...@dongniannetworks.com wrote:
hi all,
Is there anyone who have evaluated ar9220's throughput with ath9k?
With this card and ath9k, the average tx throughput is about 120Mbps. I
thought with this card, it should be very easy to get 180Mbps (I can
On 3 June 2011 02:51, Galen gal...@zinkconsulting.com wrote:
I have also had problems with AMSDU length. Try sticking to 3839 to be on the
safe side.
I would like to learn more about the physical limits in Atheros chipsets...
.. physical limits?
Adrian
On 5 June 2011 01:08, Tony Houghton h...@realh.co.uk wrote:
I'm puzzled about why the driver works without the changes that
supposedly introduced support for AR9285. Does the older version use a
sort of generic 9k driver and the later version introduces specific
support for certain features
I went back to the original commit message:
http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commit;h=53bc7aa08b48e5cd745f986731cc7dc24eef2a9f
It looks like the commit did more than add a new AR9285 chip.
It did add the AR9285SE initvals and version check macro, but it also:
*
On 5 June 2011 21:04, Camilo Mesias cam...@mesias.co.uk wrote:
Hi,
thanks for the suggestions.
I didn't get back a stable value from that regidx/regval, I settled on this:
[root@newt ~]# for x in $(seq 1 1000) ; do echo 0x7868
/sys/kernel/debug/ieee80211/phy0/ath9k/regidx; cat
Hi Tony,
Would you please try to revert back to a kernel before that commit
mentioned above, then test a kernel with that commit?
It's possible that other stuff in the kernel that's been introduced
since is also causing issues. It's also possible we're not fixing the
root cause.
Either way, the
Well, that patch did a few things besides add AR9285SE specific stuff:
* added the carrier leak calibration workaround for AR9285;
* changed initvals for the normal ar9285 v1.2 case (they look like
BB/PHY and analog related settings, but I have no idea what misc bits
are floating around there,
For completeness, please report what you're actually testing it on. :)
Adrian
On 7 June 2011 16:31, Sucheta ROY sucheta@st.com wrote:
Hi,
I face the following error under Linux with AR9285 card :
PCI: Enabling device :00:01.0 ( - 0002)
PCI: Setting latency timer of device
1 - 100 of 785 matches
Mail list logo
