Le 30/06/2010 11:16, Marcel GMail a écrit :
> I tried to post this e-mail on the list, but it seems the moderator did
> not approve it.
> Can you check my question below.
> Thanks
> Marcel
>
> Original Message
> Subject: Re: [ath5k-devel] Half/Quarter Channel Support
> Date:
Le 30/06/2010 05:44, Jono a écrit :
> Hi,
>
> I'm not sure if this is the right place to ask, but I'm looking for
> information on a specific register on Atheros cards.
>
> I've been told that there is a register that Atheros chips update with
> information about how much of a set period has been d
Le 25/06/2010 22:08, Steve Brown a écrit :
> I have a couple of Ubiquity XR9's. They use an AR5413 (168c:001b, ss
> 3009:0777) and downconvert to the 900MHz ISM band. The default channel
> width is 20MHz and confirmed by my spec analyzer. I'd like to use them
> at 10MHz and 5MHz.
>
> My searching t
>> We "read-and-clear" RXDP on hw_nic_reset (actually we do that for any
>> pending register writes -we need to ensure that all pending register
>> writes are complete by doing a DMA register read, docs suggest RXDP
>> and that's what we are doing on nic_reset, we need to change that
>> comment-) a
Le 05/06/2010 14:50, Robert Brown a écrit :
>
> I think I have a likely explanation for the data corruption. It looks like
> the hardware is not transferring the data to place the driver expects.
>
> I ran Wireshark on a Macintosh portable while transferring a file, so I now
> know what packets th
Le 05/06/2010 14:01, Robert Brown a écrit :
> Comments below ...
>
> On Sat, Jun 5, 2010 at 4:34 AM, Benoit Papillault
> mailto:benoit.papilla...@free.fr>> wrote:
>
>
> It helps for sure. But i'm not seeing in your log where do you
> receive the duplica
Le 04/06/2010 22:24, Robert Brown a écrit :
>
> Here's another instance of data corruption. One block containing labels
> 110413 & 110414 is duplicated in the output file.
>
> I've instrumented ath5k_tasklet_rx to print "ATH" followed by packet block
> information. Function __ieee80211_rx_handle_
Le 27/05/2010 17:14, Bob Copeland a écrit :
>
> That said... reset() rebuilds the buffer list and resets the sclink pointers
> etc. I'm not so sure it does it properly, though last time I reviewed it
> I didn't find anything.
It worth to check it again. I guess RXDP are reset to NULL pointers
du
Le 27/05/2010 10:08, Johannes Berg a écrit :
> On Thu, 2010-05-27 at 09:45 +0900, Bruno Randolf wrote:
>> IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5& 11 Mbits are
>> mandatory rates for what they call High Rate direct sequence spread spectrum
>> (HR/DSSS) PHY (with long PLCP).
>
Le 27/05/2010 12:46, Bruno Randolf a écrit :
> hi!
>
> i case anyone is interested - here is a diagram of the descriptor structures
> used by ath5k and the realtionship between the structures ath5k_buf and
> ath5k_desc.
>
> i have sent an older version of this a few years ago, but have updated it t
nd(struct
> ieee80211_supported_band *sband,
> sband->bitrates[i].flags |=
> IEEE80211_RATE_ERP_G;
> }
> - WARN_ON(want != 0&& want != 3&& want != 6);
> + WARN_ON(want != 0&& want !=
Bob Copeland a écrit :
> On Thu, Apr 22, 2010 at 4:54 PM, Miklos Christine
> wrote:
>
>> Thank you for your reply.
>> Is it possible to write a separate kernel module that reads that register
>> value when the ath5k driver is in use?
>> Or would I have to modify the ath5k driver code directly t
Pavel Roskin a écrit :
> On Fri, 2010-04-16 at 00:07 +0200, Benoit Papillault wrote:
>
>
>> It follows the logic mentionned by Derek, with only 2 register reads
>> needed at each additional steps instead of 3 (the minimum number of
>> register reads is still 3).
&g
mentionned by Derek, with only 2 register reads
needed at each additional steps instead of 3 (the minimum number of
register reads is still 3).
Signed-off-by: Benoit Papillault
---
drivers/net/wireless/ath/ath5k/pcu.c | 31 +--
drivers/net/wireless/ath/ath9k/hw.c
Nabeel Ahmed a écrit :
> Hi Benoit,
>
> Thanks for your fast response. I did disable virtual carrier sense as
> well. But, I still see these unpredictable delays. Can you think of
> what possibly the hardware may be doing during these transmission
> periods that could introduce such delays?
>
>
Nabeel Ahmed a écrit :
> Hi All,
>
> I'm wondering if someone can provide me some hints to tackle a problem
> I've been hitting my head on for the last couple of days. I've been
> working with the ath5k code for the last couple of weeks and am running
> into some performance issues with the driv
Bruno Randolf a écrit :
> hey!
>
> look at that funky piece of code found in the HAL and also ath9k/ani.c:
>
> #define AR_MIBC_COW 0x0001
> #define AR_MIBC_FMC 0x0002
> #define AR_MIBC_CMC 0x0004
> #define AR_MIBC_MCS 0x0008
> REG_WRITE(ah,
Bob Copeland a écrit :
> On Sun, Mar 14, 2010 at 08:43:02PM +0200, Maxim Levitsky wrote:
>
>> One thing I noticed is racy behaviour of ath5k_txbuf_setup.
>>
>> ..
>>
>> spin_lock_bh(&txq->lock);
>> list_add_tail(&bf->list, &txq->q);
>> if (txq->link == NULL) /* is this first packe
Johannes Berg a écrit :
> On Sun, 2010-02-28 at 23:08 +0100, Benoit Papillault wrote:
>
>
>> -u64 tsf = ath5k_hw_reg_read(ah, AR5K_TSF_U32);
>> +u32 tsf_lower, tsf_upper;
>> +
>> +/*
>> + * While reading TSF upper and then lower part, th
Derek Smithies a écrit :
> [cut]
> TSF jumps - yeah I looked into that on madwifi. For no apparent reason,
> the TSF would jump to stupidly high values (hundred thousand years). After
> chasing all the possible reasons on madwifi, I found that if you do the
> script
> while true; do iwpriv ath0
Bruno Randolf a écrit :
> On Wednesday 03 March 2010 11:46:59 Derek Smithies wrote:
>
>> On Wed, 3 Mar 2010, Bruno Randolf wrote:
>>
>>> (can we say that ath5k hardware is crap for IBSS?).
>>>
>> No - one cannot prove that ath5k hardware is crap in IBSS until you can
>> demonstrably
Bruno Randolf a écrit :
> please ignore this one, sorry ;(
>
> bruno
>
This one is cool & needed for testing IBSS merges. I have pretty much
the same in my tree.
Regards,
Benoit
> On Monday 01 March 2010 20:59:03 Bruno Randolf wrote:
>
>> injected frames have to use AR5K_PKT_TYPE_NORMAL, ot
Bruno Randolf a écrit :
> hi!
>
> i think we don't need to worry too much about one or two register reads more
> or less. (in my tests on a pretty slow board, one TSF register read needed
> about 1,3us in average thru 1000 reads).
>
> also i can reproduce the wrap problems here on a 5414 chip.
>
s a first step, but like you mentioned, it
does not handle every cases, so let's forget it.
Regards,
Benoit
> On Sun, 28 Feb 2010, Benoit Papillault wrote:
>
>> +
>> +tsf_upper = ath5k_hw_reg_read(ah, AR5K_TSF_U32);
>> +tsf_lower = ath5k_hw_reg_read(ah,
= {0004-000b}
This patch corrects this by reading the upper part once again in such
case. It has been tested in an IBSS network where artifical IBSS merges
have been done in order to trigger hundreds of rollover for the TSF
lower part.
Signed-off-by: Benoit Papillault
---
drivers/net
Hi Derek,
I've added ath5k-devel list since I think it worth a public discussion.
Derek Smithies a écrit :
> Hi,
> On Sun, 28 Feb 2010, Benoit PAPILLAULT wrote:
>>
>> So, there is no latch behavior IMHO. This test has been run with an
>> AR2425 minipci-e card.
>
rame generator and a monitor
interface for each card.
v2: Added ath5k_add_padding / ath5k_remove_padding
Signed-off-by: Benoit Papillault
---
drivers/net/wireless/ath/ath5k/ath5k.h |9 +--
drivers/net/wireless/ath/ath5k/base.c | 105
drivers/net/wireless/ath/a
Bob Copeland a écrit :
> On Sat, Feb 27, 2010 at 01:58:38PM +0100, Benoit Papillault wrote:
>
>> Currently, the padding position is based on
>> ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
>> padding on RX (and expect the same padding to
rame generator and a monitor
interface for each card.
Signed-off-by: Benoit Papillault
---
drivers/net/wireless/ath/ath5k/ath5k.h |9 +---
drivers/net/wireless/ath/ath5k/base.c | 70 +++-
drivers/net/wireless/ath/ath5k/desc.c | 10 +++--
3 files changed, 59 insert
Jouni Malinen a écrit :
> On Tue, Feb 16, 2010 at 09:39:25PM +0100, Benoit PAPILLAULT wrote:
>
>> I don't have an ath5k based card at hand. I will try to grab one and
>> will give an example of said frame. Basically, I followed the same
>> strategy for ath9k alread
Bob Copeland a écrit :
> On Mon, Feb 15, 2010 at 11:06:29PM +0100, Benoit PAPILLAULT wrote:
>
>>> Can you tell what the functional difference is between the old code and new
>>> code? E.g. a padding that would be incorrectly computed from before?
>>>
>
Bob Copeland a écrit :
> On Sun, Feb 14, 2010 at 6:36 PM, Benoit Papillault
> wrote:
>
>> Instead of computing the padding size based on the IEEE 802.11 header length,
>> we directly compute the padding position first and then the padding size
>> next.
>>
different chipset
(zd1211rw to name it)
Signed-off-by: Benoit Papillault
---
drivers/net/wireless/ath/ath5k/ath5k.h |9 +---
drivers/net/wireless/ath/ath5k/base.c | 70 +++-
drivers/net/wireless/ath/ath5k/desc.c | 10 +++--
3 files changed, 59 insertions(+), 30
Vitalik Nikolyenko a écrit :
> Hi! Injecting cooked frames in monitor mode (default ath5k in 2.6.32)
> does not
> preserve sequence numbers even though IEEE80211_TX_CTL_ASSIGN_SEQ is
> not set.
> I'm not sure if this has been fixed in newer releases and if so,
> please ignore
> me. The patch is
Pavel Roskin a écrit :
> On Fri, 2010-01-08 at 16:43 +0100, nurbs van nurbsen wrote:
>
>> Hi!
>>
>> I'm having problems with your ath5k kernel module. Every time I download
>> bigger files, meaning 15+ MB, I always get another md5 checksum, but never
>> the right one. Surfing and therefore downl
n n a écrit :
> Also, I didn't find any packet encapsulation fucntions in ath5k code.
> (something like "struct sk_buff *ieee80211_encap(struct ieee80211_node
> *ni, struct sk_buff *skb, int *framecnt)" in madwifi code.
> )
>
> any body give me a hint?
>
> Thank you very much.
encapsulation is
n n a écrit :
> Hi, all
>I'm a student at NYU and I'm very interested in ath5k driver code.
>
> To understand the structure of the ath5k code, I've spent weeks on
> reading the ath5k code. However, I still cant figure out what is the
> general process of transmitting and receiving a data packe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Kossifidis a écrit :
> Since we started the discussion about ath5k and proprietary
> features i started a new thread to continue.
>
> So this is what we have...
>
> a) X.R.: eXtended Range is a set of proprietary rates and some
> extra techniques
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Roskin a écrit :
> On Thu, 2009-08-20 at 04:41 -0700, shashi raj singh wrote:
>> Hi Aditya
>>
>> I think by changing PLL control register setting u sud b able to
>> achieve your goal.(also u will require som sw changes) look in
>> reg.h of ath5k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aditya Bhave a écrit :
> Thanks Benoit for your prompt response.
>
> So you are saying that 'ath9k' has this command, but not 'ath5k'?
>
> Can you please tell me the sections of code I need to look at in
> order to understand how to change the channel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aditya a écrit :
> Hi,
>
> I am a completely newbie to ath5k.
>
> My question is: Is there a command I can use to dynamically (within
> a program) change the channel width of the radio between the values
> 5, 10, 20, 40 MHz?
>
> Thanks for your help re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dhaval Shah a écrit :
> Hi,
>
> I am chasing the "beacon stuck issue" with my wifi board. On the
> "stuck beacon" wiki page
> "http://madwifi-project.org/wiki/StuckBeacon";, user "tsharples" has
> commented
>
> "In the last 3+ years we've used various
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jouni Malinen a écrit :
> On Mon, Dec 15, 2008 at 03:34:58PM +0100, Benoit Papillault wrote:
>> This patch is close to the original code except that
>> ieee80211_get_hdrlen_from_skb() has been replaced by
>> ath5k_hw_get_hdrle
Johannes Berg a écrit :
> On Thu, 2008-12-11 at 14:08 -0800, Harvey Harrison wrote:
>> On Thu, 2008-12-11 at 22:58 +0100, Benoit PAPILLAULT wrote:
>>> Padding the 802.11 header to a multiple of 4 bytes needs to be done only
>>> for DATA frames. This fixes a bug wh
Padding the 802.11 header to a multiple of 4 bytes needs to be done only
for DATA frames. This fixes a bug where 2 bytes were missing in monitor
mode for ACK frames.
Ref: http://bugzilla.kernel.org/show_bug.cgi?id=12101 :
Signed-off-by: Benoit Papillault
---
drivers/net/wireless/ath5k/base.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Felix Fietkau a écrit :
> While reading the code for calculating the frame duration, i noticed
> something odd: It doesn't seem to be taking into account the short
> vs long preamble distinction for ERP rates. IMHO this might be causing
> issues like t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davide a écrit :
> I've more news on the subject as it may not me a driver or hardware problem.
>
> I found out that if I try to set manually frequency channel on ath5k driver
> it is successful only upto channel 11 while with the madwifi-nr-r3366+ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maxim Levitsky a écrit :
> Derek Smithies wrote:
>> Hi,
>> to verify that it is a rate control issue, there is one very simple and
>> very practical test.
>>
>> Take both ends of your link, and set them to fixed rate, and at the rate
>> you think it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Felix Fietkau a écrit :
> Luis R. Rodriguez wrote:
>> http://support.dlink.com/products/view.asp?productid=DWL-G520M
>>
>> AR5513 is dual band 5 GHZ/2.4 GHZ radio. This seems to come with
>> AR5112 or AR2112 which I think are the MACs. Not sure if we s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrea Tarasconi a écrit :
| Dear Sir/Madam,
|
| even if we have an official TLA with Atheros, we cannot have the
| needed support about few RF Register usage, so we are looking for
| somebody giving us the needed support.
|
| What support we a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Kossifidis a écrit :
| Hello ppl ;-)
|
| Can someone check out these 2 fixes of ath_info and update the code on
svn ?
|
| http://madwifi.org/ticket/1653
| http://madwifi.org/ticket/1654 (i think Pavel fixed this some time ago)
|
| Also can we sync
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Randolf a écrit :
| From: Bruno Randolf <[EMAIL PROTECTED]>
|
| atheros hardware seems to have a problem with the rx timestamp of IBSS
beacons.
| unfortunately this is the case where rx timestamps count most in order to
| correctly merge IBSS. sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luis R. Rodriguez a écrit :
>
>
> Also by playing with the RSSI threshold you can get another atheros
> card to ignore carrier sense and basically become a noise
> generator, regardless of the band and frequency you're in. In
> previous e-mails I have
53 matches
Mail list logo
