gt;> this kind of projects were related to that driver.
>>>>
>>>> I also have talked with my advisor and whatever we accomplish will come
>>>> back to the community.
>>>>
>>>> I am just starting with the project and I am needing
adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of
> Adrian Chadd
> Sent: 17 July, 2014 6:13 PM
> To: Wojciech Dubowik
> Cc: ath5k-devel@lists.ath5k.org; Wright, Brett
> Subject: Re: [ath5k-devel] ath5k 5GHz Receive Diversity problem
>
> Hi,
>
> Right. It takes
Hi,
Right. It takes time for the hardware to figure out the signal level
on each antenna - there's a coarse gain change and then a couple of
fine gain changes so it can calculate RSSI. If the packet has a short
preamble or it picks it up a little too late then yeah, you won't get
any fast diversit
I have that model chip somewhere. Resuming works fine in freebsd.
Is the MAC/PHY and PCI reset stuff correctly being (re) initialised
after resume?
What's in AR_SCR, AR_PCICFG, AR_RC ?
AR_SCR = 0x4004
AR_PCICFG = 0x4010
AR_RC = 0x4000
-a
On 25 March 2014 01:07, Eugene Shatokhin wrote:
> Hi,
Hi,
I recall someone (Bob?) had patches for power saving. Where are they?
Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Yes its called ofdm restart. Its enabled on some and disabled on others,
depending upon the chipset bugs.
Adrian
On Feb 8, 2014 11:52 AM, "Mathy" wrote:
> Hi,
>
> I encountered two papers [1, 2] which claim that the AR5112 and 5213
> support message in message mode. This would allow a receiver t
Hi,
I've just created "AdrianChadd". Please go forth and add me to the
relevant bits. :P
-a
On 26 February 2014 01:50, Nick Kossifidis wrote:
> So will you edit the OPW wiki (http://kernelnewbies.org/OPWIntro) or
> should I do it ? I've already added a project description for AR5513
> support
sted in power saving stuff ?
>
> Is anyone interested in working on DFS ?
>
>
> 2014-02-25 5:30 GMT+00:00 Adrian Chadd :
>> I'm happy to be a mentor for the AR5523 support. Who knows, I may end
>> up learning how the hardware works!
>>
>> I&#
I'm happy to be a mentor for the AR5523 support. Who knows, I may end
up learning how the hardware works!
I'll see if I can dig up my AR5523 and get the basic probe/attach working.
-a
On 24 February 2014 10:39, Sarah Sharp wrote:
> On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wro
... because some of the 802.11p NICs are actually ath5k NICs that have
the relevant bandpass filters for 5.9GHz and high output amplifiers.
-a
On 17 February 2014 01:27, Holger Schurig wrote:
> Okay, I admit that I cannot help you, I have no clue on the driver level.
>
> But maybe I can help
On 9 November 2013 05:40, Nick Kossifidis wrote:
> Adrian/Bob, these fixes (along with power saving etc) are very
> interesting projects and I was thinking to submit them in OPW
> (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring
> (http://kernelnewbies.org/OPWMentor) ?
I'm ha
On 7 November 2013 06:20, Bob Copeland wrote:
> On Wed, Nov 06, 2013 at 09:17:46AM -0800, Adrian Chadd wrote:
>> The TL;DR version - you need to keep the the final descriptor around
>> for each hardware queue. The legacy madwifi/freebsd way of doing it
>> was to keep the las
On 6 November 2013 05:41, Bob Copeland wrote:
> Hi Adrian (and anyone else who wants to chime in),
>
> I'm looking to fix some accounting issues in the ath5k tx path, which
> arise because we always try to keep one descriptor available at the
> end for the hardware's sake.
>
> I believe you have s
Yup!
That was my doing, before i left Qualcomm Atheros.
-adrian
On 5 October 2013 16:45, Andrea Scoppettone wrote:
> Hi there is the HAL for AR5513
> https://github.com/qca/qca-ar5513-hal
>
> The AR5513 is a 2-antenna MIMO 11abg (not 11n) device that was sold
> into a few markets. As far a
[snip all the things]
Ok, so ath5k is doing better with regards to interrupt handling and
processing it seems. So next I would look at the TX and RX descriptor
contents and timing. I think you'll need to add tracing to ath5k.
I'd trace:
* interrupts coming in
* the timestamp of each RX'ed frame
... I think you should start doing some more in-depth system profiling to
see where that CPU is actually being used. Saying "ksoftirqd" is only a
little helpful.
See if it's handling way too much interrupts, or whether there's lots of
card error conditions, or the TX/RX queues are being too freque
.. in fact, what I'd really _really_ like is if someone would build an
open source phased antenna array that's intended to be used by
three-stream (ie, three transmit/receive chain) antenna devices.
That way we could do both phased array station operation (when it
directs its transmit power _to_ a
ue via serial port (RS232) to control and direct the antenna radiation
> pattern towards desired direction. I have already achieved this by modifying
> MADAWIFI. I have to try it using mac80211 and ath5k driver. The only
> challenge is achieving neighbor discovery especially in ad-hoc
Hi,
I figure I'll give a 30 second introduction into "sectored antenna" support.
So the AR5212 era chips have four antenna control bits. They're ANTA -> ANTD.
Now, there's some switch table registers. By default the HAL code sets
these up so BB_ANTENNA_CONTROL, BB_SWITCH_TABLE1 and BB_SWITCH_TAB
Well, I can help you with the hardware tweaks for "sectored antennas."
But first you need to tell me how you plan on hooking up said sectored
antenna to the ath5k NIC.
Adrian
On 7 May 2013 00:27, Holger Schurig wrote:
> You're probably 5 years too late. The MADWIFI driver is quite out of fa
On 13 May 2013 09:39, Jonathan Bither wrote:
>> ... is anyone using this on openwrt?
>>
> I am.
> I am also reworking AR2131X drivers and will submit a patch to linux-mips
> shortly.
Sweet. Someone say NACK then? :)
Adrian
___
ath5k-devel mailing li
... is anyone using this on openwrt?
Adrian
On 13 May 2013 08:03, Paul Bolle wrote:
> AHB bus support was added in v2.6.38, through commit a0b907ee2a ("ath5k:
> Add AHB bus support."). That code can only be build if the Kconfig
> symbol ATHEROS_AR231X is set. But that symbol has never been ad
Hi,
I've just pushed a copy of the AR5513 HAL from Qualcomm Atheros into
the QCA github repository.
https://github.com/qca/qca-ar5513-hal
The AR5513 is a 2-antenna MIMO 11abg (not 11n) device that was sold
into a few markets. As far as I'm aware, it's the only legacy PCI(e)
chipset which the ope
On 22 March 2013 14:41, Colleen Josephson wrote:
> Which bit rate selection protocols are available in the ath5k driver? How
> does this compare to what's available in the madwifi and the ath9k drivers?
>
> I am trying to set up an experiment to measure the performance of the
> various bit rate se
On 27 February 2013 04:39, Lynne Stevens wrote:
>
> * So how do I install the drive for AR5B95 . . ie the ath5k driver as
> when I did this it kicked in and seen all the wifi connections I just could
> not get it to work as it did not have the driver
> *
>
> * modprobe ath5k
> sudo ip link set wla
of the NAV timer? That would certainly be informative for MAC
> research.
>
> Hugh
>
>
>
>
> On 17 January 2013 15:37, Adrian Chadd wrote:
>>
>> On 16 January 2013 18:45, Hugh O'Brien wrote:
>> > Hi there,
>> >
>> > I'm doing som
On 16 January 2013 18:45, Hugh O'Brien wrote:
> Hi there,
>
> I'm doing some research on CTS based co-existence with wifi for other 2.4GHz
> protocols. I've been using packet injection to get the CTS frames on the
> air, which I can verify, but I'm not sure that certain stations are
> receiving th
On 12 November 2012 11:40, Sam Leffler wrote:
> From my experience doing tdma on ath chipsets I know the timestamp is
> a snapshot of the tsf recorded by the dma engine when it writes the
> descriptor on dma completion. This was only legacy frames; don't know
> how things work for aggregate fram
Hi,
It may be; that's the problem. :/
Adrian
On 12 November 2012 10:53, Thomas Pedersen wrote:
> This is true for at least AR5213, and shouldn't be different for other
> ath5k PHYs.
>
> Signed-off-by: Thomas Pedersen
> ---
> drivers/net/wireless/ath/ath5k/base.c | 13 +
> 1 fi
Hi,
I can't point you to any working implementations, sorry. I know that
channel change on the older platforms takes time; even "fast channel
change" wasn't terribly fast and came with a _lot_ of restrictions.
There was some attempt at a virtualised phy with mac80211 and ath9k in
the past. It may
This is why I asked for a bit of a summary.
What specific behaviour are you chasing from the keycache,
source/destination MAC address matching and encryption engine?
There've apparently been some keycache matching bugs in the past ..
Adrian
___
ath5k
Hi,
The problem with doing multi-channel single radio work is that channel
change will take quite a bit of time; so you will have to take that
into account when implementing this.
Then you have to ensure all the whacky power save stuff works
absolutely correctly.. :-)
Adrian
On 4 September 201
Hiya,
Yeoh - can you please email me privately with a summary of what you
implemented, what you've tested and what worked / what didn't work?
I can do some digging into what changed with the encryption stuff and
see if I can figure it out in my (limited) spare time. I can try to do
it sometime ne
On 31 August 2012 08:24, Yeoh Chun-Yeow wrote:
> Hi, Adrian
>
> Appreciate your testing on this.
>
Hi,
I don't have time to test ath5k stuff. I'm just an Atheros employee
who hacks on FreeBSD in his spare time. I'm lurking to provide
feedback. :-)
I suggest that you at least wrap this in a run-
.. you just have to ask the right question. :)
half and quarter rates simply clock the chip at half or quarter the
normal clock rate. Everything runs at a slower speed and you end up
with your reduced bandwidth.
There are some tricks to it. Felix is the best person to describe it to you.
There a
Hi,
Would you be able to boot a FreeBSD live image on that machine and see
if FreeBSD has the same issue with wifi?
I've been doing a whole bunch of testing with AR5210/AR5211 hardware
recently to ensure I haven't broken anything.
If FreeBSD works better then the ath5k guys have a bit more of a
Hi,
0xff1b indicates the device wasn't correctly setup post power on.
So I'd try to find out exactly why that is.
Adrian
On 13 April 2012 08:32, Yoshinori Sato wrote:
> This device works fine of ath5k.
>
> Details bellow
> 05:00.0 0200: 168c:ff1b (rev 01)
> 05:00.0 Ethernet controller: Athe
hi,
I'm -pretty- sure that the PLCP will indicate the normal 802.11 rate,
but it's just modulated on half/quarter size carriers.
adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Hi!
There's no CPU on the NIC.
The interrupt load is going down because at some point, you're not
handling each RX interrupt before the next RX packet comes, so it
doesn't generate a new interrupt.
There was code in madwifi/freebsd/HAL that did TX interrupt mitigation
by only flipping on the TXI
On 23 March 2012 10:18, Ben Greear wrote:
> I wouldn't ask someone to do it and then tell them what language. Just
> suggest
> to them what it needs to do instead.
I'm sorry if it came across as demanding. It's more that I've looked
at how/where people tend to use these kinds of visualisation t
Hi all,
I'd like some help in writing a GUI toolkit for recording, playing
back and visualising some of the PHY/MAC statistics the Atheros NICs
expose.
What I can do: help with the MAC/PHY side of things, identify what
initial things would be good to support and what would actually be
useful.
Wha
On 18 March 2012 22:18, Joe Perches wrote:
>> Otherwise compiling in debugging will cause a _lot_ of spurious
>> register reads to occur that are then tossed. This was one of the big
>> reasons for instability and slow performance when AH_DEBUG was
>> enabled.
>
> That doesn't make any sense in t
Hi,
So the reason this is a macro in the FreeBSD HAL is so that the args
aren't evaluated unless the level (or debug bitmap in my case) fires
off.
Otherwise compiling in debugging will cause a _lot_ of spurious
register reads to occur that are then tossed. This was one of the big
reasons for inst
Hi!
There's a couple of things I can think of.
Firstly, it'd be nice if we had per-packet TPC working on some of
those earlier chips. Then you could throw in TX power into the mix.
Secondly, yes - you can do per-packet TX antenna selection on these
NICs. You could modify the rate control API in
I'd ignore wireshark for now. Look through the TX and TX completion
code. There's a timestamp field somewhere that should be populated for
all TXed frames.
Verify first that the TSF is being written into that timestamp field
upon completion, and then verify that it's pushed all the way back up
thr
Hi!
On 14 March 2012 13:57, Alexander Watson wrote:
> Hello,
>
> I am working on a project where I need to be able to accurately timestamp
> both transmitted and received packets from an Atheros NIC. I am aware that
> in its normal mode of operation and that Ath5k only timestamps received
> packe
On 10 March 2012 10:56, David Fries wrote:
>> > http://nbd.name/gitweb.cgi?p=openwrt.git;a=blob_plain;f=package/mac80211/patches/440-ath5k_calibrate_no_queue_stop.patch;hb=HEAD
>> > http://nbd.name/gitweb.cgi?p=openwrt.git;a=blob_plain;f=package/mac80211/patches/441-ath5k_no_agc_recalibration.pat
.. and you'll be able to sense ACKs how? :-)
Adrian
On 29 February 2012 14:25, srinivas prasad wrote:
> I thought that it will enable me to transmit without sensing the carrier. I
> am a bit new to this so maybe I interpreted it wrong. My aim is to induce
> overlaps as many overlaps as possible
On 29 February 2012 09:19, srinivas prasad wrote:
> Thanks for the reply. Just to make it clear, So are you saying that the
> patch is buggy? I thought it is supposed to disable carrier sensing
> (physical and virtual) by turning on and off some flags.
I don't think that patch does what you thin
On 16 February 2012 08:19, Alexandros Chimarios
wrote:
> Hi,
>
> Regarding the CCA, I have noticed that ath5k currently supports only the
> ANI
> patent. Is there any feature in the ath5k driver to support the 802.11
> CCA mode 1(802.11 DSSS PHY conformant signal detection) and 2(Energy
> detecti
** **
>
> http://wiki.spench.net/wiki/RADAR
>
> ** **
>
> Hope it all makes sense (and works for you!).
>
> Let me know what happens…
>
> Balint
>
> ** **
>
> *From:* adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] *On Behalf
> Of *Adrian
Hi!
On 22 January 2012 16:56, Balint Seeber wrote:
> Hi folks,
>
> I’ve finally put up some results of my experimentation with the PHY’s
> RADAR pulse detection system:
>
> ** **
>
> http://wiki.spench.net/wiki/RADAR
>
> ** **
>
> I hope this will be useful to those investigating DFS
s if I thought this would be possible.
>
> Thanks
> Dave
>
>
>
> On 20/01/12 05:59, Luis R. Rodriguez wrote:
>
>> On Thu, Jan 19, 2012 at 07:45:52AM -0800, Adrian Chadd wrote:
>>
>>> If it's anything like what ath9k does, there's a flag that the
If it's anything like what ath9k does, there's a flag that the upper layers
can set which marks that particular frame as not requiring an ACK.
So you wouldn't require it to be done via an iw command - you'd just
appropriately tag your data frames.
Adrian
On 19 January 2012 00:35, David Murray
.. and as a "DFS when?" followup:
* hostap's are expected to listen out for radar pulses whilst traffic
is on-going.
* in an IBSS, a DFS 'master' is elected which does radar detection.
* a hostap can request that stations be quiet for a certain period
after a beacon, so it can sample the air for r
Hi,
Ruh roh, we're straying into evil territory here!
I suggest starting here:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
I've crimed the radar setup code from the reference driver and the
madwifi-dfs branch, and I've started collecting the relevant public
documentation for the r
On 28 November 2011 03:59, Nick Kossifidis wrote:
>> Oh wait. Where are you clearing these bits? It doesn't look like
>> you're even clearing the ah_txq_isr bits in the most recent ath5k tree
>> I have here. This means you're likely not missing events; but you're
>> likely always scanning those qu
Hi,
Review #2:
One thing that I discovered whilst debugging some silly races in
FreeBSD was that the update of the txq active mask wasn't done
atomically.
Ie, when you check this:
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1689,7 +1689,7 @@ ath5k_tasklet_tx(unsigned long data)
struc
2011/11/22 Gábor Stefanik :
> My guess is that they are using some king of ES/pre-production silicon
> that should have been destroyed, but was instead dumped on the
> black/grey-market.
That should be pretty clear by the MAC major/minor revision.
Maybe if someone can write down the exact part nu
On 21 November 2011 19:16, Albert Gall wrote:
> The same problem described in this thread appear AR2414 hardware. Loading
> ath5k with nohwcrypt = 1 everything works fine, attached information and
> evidence that I hope will be useful.
> If you need more please just ask.
Well, what would be usefu
Well, unless that vendor spun their own silicon, or there's something
funky on the board that'd change crypto behaviour, the only thing I
can really think of are EEPROM settings.
Or maybe the MAC revision is slightly different, I dunno.
Adrian
___
ath5
On 21 November 2011 12:08, Nick Kossifidis wrote:
> Some time ago we had a few reports of AR2413 cards being unable to
> encrypt packets of specific lengths.
>
> From https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568090, user
> Musaraigne did some further investigation/debuging on this:
>
>
.. replying to this after having not slept for > 24 hours, thanks to
being in transit between the US and Western Australia..
On 20 November 2011 15:56, Nick Kossifidis wrote:
> Since we dont read a snapshot of the interrupt
> registers it might be possible to get a new interrupt
> while reading t
Hm, have you looked to see whether you're then touching any of the
registers you shouldn't touch?
Ie, some parts of the chip are now asleep, so you may not be able to
do things like calibration whilst it's asleep.
Adrian
___
ath5k-devel mailing list
ath
.. does madwifi have that net80211 "aggressive mode" by default, where
it overrides the best-effort WME queue parameters to allow for
bursting?
I see exactly that difference in FreeBSD (33mbit vs 22mbit) when I
disable that aggressive mode code.
Thanks,
Adrian
__
Is there stuff in the cabq?
Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
I haven't read the ath5k code, but I do know the HAL code has stuff to
glue the GPIO pin in question to the baseband so it becomes a "hard"
kill.
Also, as I said privately, I think interrupt may be broken on some
NICs. Have you guys thought about doing polling to see if the GPIO pin
is actually me
On 13 September 2011 00:27, Bob Copeland wrote:
> The hardware handles it - the tx descriptor specifies a list of rates
> and number of attempts to retry the frame and the hardware reports
> back how many tries at which rates were used (of course upper layers might
> retransmit packets unknown to
You should only add to your channel usage estimate it if the buffer
has been marked complete - ie:
* the status bit in the descriptor indicates DMA is complete;
* .. and the relevant flags say that it did go on the air or try to go
on the air - ie, it can fail but still have been attempted.
I don
Hi,
This isn't strictly involved in fixing your problem, but when you do
get it fixed, you're going to notice a bunch of discrepancies:
* the ack calculation is lifted from elsewhere in the code, but please
note that they use the basic rate for ACKs, not the current TX rate.
Please re-read the co
al message.
> Does this mean that the only solution is to cover pin13?
>
> Can't it be done with ath5k? It was working fine with ath_pci. So the
> code in ath_pci exists.
> It can't be so difficult to fix...
>
> Antonis.
>
>
> Στις 04/08/2011 01:58 πμ, ο/η
> Obviously, something is wrong with ath5k. If the device is "hard
> blocked", how come it can be enabled by disabling "rfkill"? We need to
> change the logic here. If the pin 13 can be overridden, it should be
> treated like an input device, not as a hardware block.
It looks like you can disab
On 12 June 2011 04:06, Stefan Hellermann wrote:
> Hi,
>
> I have a "Alfa Networks AWPCI085P" Wlan Card. It can receive the
> outside, but I cannot connect to any AP. While testing with another
> notebook, I tried airmon from the aircrack-ng suite, and sometimes I can
> see packets from this statio
On 11 June 2011 11:15, Liang wrote:
> Hi Adrian,
> It really works! When adding
> the REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS)
> after ath9k_hw_process_ini(), Wireshark monitors no IEEE ACK any more.
> There is another question. It is found the transmission rate is really low
> even with UDP
> function3: ath9k_hw_abortpcurecv()
> REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_RX_ABORT | AR_DIAG_RX_DIS);
> Thank you.
> Best,
> Liang
>
>
> On Thu, Jun 9, 2011 at 4:07 PM, Adrian Chadd wrote:
>>
>> Best thing to do is look at the code that disables ACK in the TX
>> desc
On 9 June 2011 20:00, Bob Copeland wrote:
>> http://linuxwireless.org/en/users/Documentation/Bluetooth-coexistence
>
> From that page:
>
> Apart from AFS and channel skipping techniques Bluetooth
> coexistence is typically tested with bundled 802.11 and Bluetooth
> devices. This becomes
e the ACK in the
> ath5k/ath9k driver?
> Best,
> Leon
>
> On Thu, Jun 9, 2011 at 2:32 PM, Adrian Chadd wrote:
>>
>> No, retry doesn't stop ack's, it just stops the hardware from retrying
>> a packet if it hasn't heard an ACK.
>>
>> You can fiddl
No, retry doesn't stop ack's, it just stops the hardware from retrying
a packet if it hasn't heard an ACK.
You can fiddle with the diag register, or you can just ensure that the
relevant bit in the TX descriptor isn't set.
fgrep NOACK ath9k/*.h
mac.h:#define ATH9K_TXDESC_NOACK0x00
On 9 June 2011 09:01, Bob Copeland wrote:
>> Hm, is there BT coexistance support for ath5k?
>
> No, but my understanding is that BT coex support is only for co-located
> devices, so unless the phone is using ath5k it wouldn't help here.
>From my understanding, bluetooth coexistance is so devices
On 9 June 2011 04:34, Piotr Kaczorek wrote:
> Sorry for no new packet dumps yet but i wanted to tell you that i've
> found a possible reason. Bluetooth. Our hotspot has 'a lot of bluetooth
> going on' on it. Today after installing compat-wireless modules with
> still no luck as a last resort i de
It may also be the different 802.11 layer; it doesn't have to be ath5k specific.
I know there's an outstanding bug with FreeBSD (which uses net80211,
like madwifi does) with power save queue management timers being
off-whack and that appears like this, also I found this comment in the
source:
Well, I see the same on FreeBSD/MIPS whenever an Atheros device is
fondled incorrectly. Either because the chip isn't yet fully awake or
the register plainly doesn't exist.
See if you can add some debugging in ath5k_hw_reset_tx_queue() to see
which register is being read/written before the PCI bus
The obvious question - have you bisected the kernel versions to find
which one introduced this regression?
Adrian
On 30 April 2011 03:13, Denis Periša wrote:
> Hello to all,
>
> I have problem since 2.6.38 kernel.
> I use link in ad-hoc mode between two nods. Link is 5ghz (channel doesn't
> see
This is just my off-the-morning-coffee calculation without (yet) having any
experience with the coverage class parameters, but:
* light travels roughly 300m/microsecond sec;
* means you're going to travel 36.6 microseconds for 11,000 metres, so call
it 37 microseconds.
* the AR_D_GBL_IFS_MISC_SIFS
Does it do the same in 11bg mode?
Does madwifi behave the same way?
Don't forget to include the MAC/radio chipset and revision details; those
who "know" how the radios work will likely need that.
Adrian
On 17 March 2011 16:45, Alex wrote:
> Hi,
>
> the last few days i've been experimenting
Just as a reference, does madwifi exhibit this behaviour?
Adrian
On 3 March 2011 13:14, Fabrice wrote:
> I'm now able able to prevent the CM9 to lock up.
> I changed the RX/TX DMA burst size from 128 bytes to 16 bytes.
> When I stream TCP data, I still some issues. The TX queue gets stuck and
hen the driver is in 802.11a mode.
>
>
> Alex
>
>
>
> On 3/3/2011 9:59 μμ, Adrian Chadd wrote:
>
> Have you also added a hook or two to monitor what's going on to the noise
> floor?
>
> IIRC, atheros radios report RSSI as an offset from the curre
Have you also added a hook or two to monitor what's going on to the noise
floor?
IIRC, atheros radios report RSSI as an offset from the current NF; if the NF
raises but the signal doesn't, RSSI will "decrease".
Adrian
On 3 March 2011 11:50, Alex wrote:
> Hi,
>
> i'd list to ask the members
Do you suitably tickle the clock rate definitions for some of the registers?
IIRC (having looked into this stuff in FreeBSD), enabling turbo mode sets
the clock to double-rate, needing changes to some of the registers like ACK
timeout, slot time, SIFS, etc., which operate on clock-ticks rather tha
Hi all,
I'm working on fixing up the FreeBSD ath codebase, both for new 11n
chipsets and older chipsets that ath5k supports.
I've noticed something strange with the AR5213. (I don't have any
AR5212 chips or variants thereof.) It happens on MIPS, not on i386. It
doesn't happen with exactly the sam
90 matches
Mail list logo
