pends on (ATHEROS_AR231X &&
!PCI)
drivers/net/wireless/ath/ath5k/Kconfig:64: depends on (!ATHEROS_AR231X &&
PCI)
you can do with that what you will.
rday
--
====
Robert P. J. Day
raffic.
Information:
Chipset: Atheros 5413A (ath5k phy0: Atheros AR5413 chip found (MAC:
0xa4, PHY: 0x61))
Kernel: 2.6.33.7 - armeb/ixp4xx
Compat wireless: 2010-10-19
I have both kernel and drivers compiled with debug options so if you
need any more info, just a
If not joined, holds the cycles for the extension channel.
BR
Robert
-Ursprüngliche Nachricht-
Von: ath5k-devel-boun...@lists.ath5k.org
[mailto:ath5k-devel-boun...@lists.ath5k.org] Im Auftrag von Helmut Schaa
Gesendet: Donnerstag, 7. Oktober 2010 08:52
An: Bruno Randolf
Cc: ath5k-devel
What's the purpose of ath5k_rx_stop setting sc->rxlink to NULL?
As Bob points out, it causes problems if it's not done while holding the
rx buffer spinlock.
There's code in ath5k_intr that sets sc->rxlink to NULL, apparently
to handle a chip bug. It needs to hold the spinlock as well to avoid
sel
The wireshark experiment I ran earlier is worth considering again.
Wireshark
saw block 110413 sent, but the receive tasklet saw a stale block, 107223.
In the data file, block 110413 appears where block 110412 should be in
addition
to appearing in its proper spot. The receive tasklet saw data for
I don't know anything about work queues, but I did read some documentation
about tasklets. Relevant info: tasklets always run on the CPU that
schedules
them, multiple tasklets can run at the same time on different CPUs. You
folks
probably know this already
bob
On Wed, Jun 9, 2010 at 3:07
stored by ath5k_intr and aborts if the
counts
are different.
The change didn't fix anything, but it did demonstrate that DMA can be
enabled
several times between a call to ath5k_intr and the activation of
ath5k_tacklet_rx.
bob
On Mon, Jun 7, 2010 at 10:20 AM, Robert Br
I think corruption of received data can happen whenever
ath5k_reset is called when there are pending instances of ath5k_tasklet_rx
scheduled, but not yet executed.
ath5k_reset calls ath5k_rx_start to initialize the rxbuf queue, then sets
RXDP to the head of the queue and turns DMA back on. At som
sn't it possible that the tasklet will see sc->rxlink as non-NULL?
bob
====
On Sun, Jun 6, 2010 at 9:24 PM, Robert Brown wrote:
> Is it possible for one thread to set sc->rxlink but another
> thread reads a stale value from cache?
>
> I'm sorry, but I
Is it possible for one thread to set sc->rxlink but another
thread reads a stale value from cache?
I'm sorry, but I don't really hack kernel code, so I'm not
familiar with the memory model the code assumes.
bob
On Sun, Jun 6, 2010 at 8:16 PM, Robert Bro
ptors
and links. Is it certain the hardware has the same view of memory?
bob
===
On Sun, Jun 6, 2010 at 8:19 AM, Bob Copeland wrote:
> On Sat, Jun 5, 2010 at 3:16 PM, Robert Brown
> wrote:
> > I transferred 1 Gb of data twice while executing the scan command as
>
On Sat, Jun 5, 2010 at 4:34 AM, Benoit Papillault wrote:
> It might be likely that the problem is caused by background scan done by
> network manager since this calls ath5k_reset. So, one way to trigger the
> problem more often is by doing more scanning.
>
> Could you try a script like below when
I can try changing the DMA size. Can you give some motivation
for the change? Are you hopeful that it will fix the problem?
If so, what's the rationale?
bob
On Sat, Jun 5, 2010 at 2:56 PM, Nick Kossifidis wrote:
> 2010/6/5 Robert Brown :
> > On Sat, Jun 5
On Sat, Jun 5, 2010 at 8:29 AM, Benoit Papillault wrote:
> 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:
>>
>>
>>I
Comments below ...
On Sat, Jun 5, 2010 at 4:34 AM, Benoit Papillault wrote:
>
> It helps for sure. But i'm not seeing in your log where do you receive the
> duplicate 110413 & 110414 packet. Is it in the log? Is it indeed missing in
> the log?
>
I don't think the block is received twice. It ju
Answers interleaved ...
On Fri, Jun 4, 2010 at 5:39 PM, Bob Copeland wrote:
> On Fri, Jun 4, 2010 at 4:24 PM, Robert Brown
> wrote:
> > There seems to be stale data in the skb that ath5k_tacklet_rx passes to
> > __ieee80211_rx_handle_packet. Note that ieee80211_deliver_s
On Fri, Jun 4, 2010 at 4:31 PM, Bob Copeland wrote:
> On Fri, Jun 4, 2010 at 4:24 PM, Robert Brown
> wrote:
> >
> > Here's another instance of data corruption. One block containing labels
> > 110413 & 110414 is duplicated in the output file.
> > I've
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_packet prints MACI. Function
ieee80211_deliver_skb pri
Here's a progress report on tracking down the data corruption bug.
I created a 1 Gb file containing random data, except that every 1000 bytes
the file contains "" followed by a block number in the
range 0 to 99. I wrote some code to detect the pattern of Xs and print
out b
Yes, I'm using Ubuntu 10.04, so there's a network manager running.
bob
==
On Mon, May 31, 2010 at 11:58 PM, Bruno Randolf wrote:
> On Tuesday 01 June 2010 06:30:52 Robert Brown wrote:
>> All the calls to ath5k_reset appear to be from ath5k_chan_set.
>
> so tha
"123456789012345"
}
What do you think, is this a problem with ath5k or with wpa_supplicant?
Regards, Robert.
wpa_supplicant start log:
---
Initializing interface 'wlan0' conf '/tmp/wpa_supplicant-wlan0.conf'
driver 'n
All the calls to ath5k_reset appear to be from ath5k_chan_set.
bob
==
On Sun, May 30, 2010 at 8:51 PM, Bruno Randolf wrote:
> On Saturday 29 May 2010 02:39:38 Robert Brown wrote:
>> > also i am wondering why you have so many resets? (a review of the reset
>>
On Sun, May 30, 2010 at 8:51 PM, Bruno Randolf wrote:
> On Saturday 29 May 2010 02:39:38 Robert Brown wrote:
>> My repeated packet detection hack is not perfect and given how often it
>> fires it's probably showing TCP retransmissions or something similar
>> that's
Comments below
On Fri, May 28, 2010 at 8:36 AM, Bruno Randolf wrote:
> On Friday 28 May 2010 10:58:10 Robert Brown wrote:
>> It looks like the code I
>> added has made the corruption problem much worse.
>
> welcome to the wonderful world of ath5k "heisenbugs&q
I wasn't able to match up instances of data corruption with the repeated
packets I was printing or with the device resets.
Since the corruption doesn't seem to occur when ath5k_tasklet_rx sends the
same data twice, something more interesting is happening.
bob
_
I added some code to ath5k_tasklet_rx to check for adjacent packets with
runs of identical data. I compiled the ath5k driver with debugging turned
on. I turned on the "reset" debugging option. In the course of
transferring 1 Gb, I saw about 20 resets. I also got something like 10
instances of c
ption happens this is accompanied by
>> [ 469.663234] ath5k phy0: unsupported jumbo
>> [ 469.935929] ath5k phy0: unsupported jumbo
>
> that might be a good clue! robert do you see the same? in newer kernels we
> have removed the warning, however...
Yes, I have also seen th
n
ath5k_tasklet_rx to see if two adjacent data packets are the same.
Anything else like this sound worth trying?
bob
On Wed, May 26, 2010 at 5:16 PM, Robert Brown wrote:
> Thanks very much for the patch suggestion.
>
> I ran some large "scp" commands toda
s.rs_datalen,
> PCI_DMA_FROMDEVICE);
> pci_unmap_single(sc->pdev, bf->skbaddr, common->rx_bufsize,
> PCI_DMA_FROMDEVICE);
> skb_put(skb, rs.rs_datalen);
>
>
>
> On Wednesday 26 May 2010 04:10:17 Robert Brown wrote:
>> You
small files containing ASCII data until I see a mismatch.
bob
On Tue, May 25, 2010 at 2:45 PM, Bob Copeland wrote:
> On Tue, May 25, 2010 at 1:40 PM, Robert Brown wrote:
>> The symptom is a block of data, roughly 1400 bytes in size, that appears
>> t
ion might be caused.
bob
On Tue, May 25, 2010 at 10:16 AM, Bob Copeland wrote:
> On Sun, May 23, 2010 at 11:49 AM, Robert Brown wrote:
>> I do think it's worthwhile to think about how a repeated block of data could
>> get into the destination file, assuming something in the n
Here's the output of "cmp -l good bad" for two files that experienced
corruption in transfer.
I'll investigate turning on the kernel debugging options you suggested. It
looks like I may have to compile a kernel to do this, however. I'm not sure
right now what's possible with a stock Ubuntu kerne
(5735000 KHz - 5835000
KHz @ 4 KHz), (300 mBi, 2000 mBm)
=
On Mon, May 17, 2010 at 11:02 PM, Luis R. Rodriguez wrote:
> On Mon, May 17, 2010 at 7:51 PM, Bruno Randolf wrote:
>> On Tuesday 18 May 2010 11:29:27 Robert Brown wrote:
>>> I'm running Ub
Bruno Randolf wrote:
> On Tuesday 18 May 2010 17:38:12 Robert wrote:
>
>> Hi.
>>
>> I'm currently trying to migrate a small embedded linux distribution from
>> madwifi
>> to ath5k and have run in to some problems.
>>
>> I started out using
x kernel: 2.6.33-3, open embedded based "homebrew" distro
Arm ixp4xx big endian platform (Gateworks Cambria)
Radio cards (tested with several models, same result):
Compex WLM54AG (AR5413)
Wistron DCMA-82 (AR5414)
Wistron CM-9 (AR5213)
Regards, Robert.
_
I'm running Ubuntu Linux 10.04 on an Acer Aspire ZG5 netbook that contains
Atheros wifi hardware. There's a sticker on the back that says "Atheros
AR5BXB63". The uname command reports the kernel version as
2.6.32-22-generic. I'm using the ath5k driver.
I often get corrupted data when downloadin
tx seems to get stuck for some seconds. By switching channels
this problem can be solved. Are there any known issues and known
workarounds?
Thanks!
BR
Robert
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/net/wireless/ath5k/eeprom.c
b/drivers/net/wireless/ath5k/eeprom.c
index c0fb3b0..c85429d 100644
--- a/drivers/net/wireless/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath5k/eeprom.c
@@ -640,9 +640,9 @@ ath5k_eeprom_init_11bg_2413(struct
38 matches
Mail list logo
