On Wednesday 31 March 2010 03:27:00 Maxim Levitsky wrote:
quoted text
> On Sat, 2010-03-20 at 19:41 +0200, Maxim Levitsky wrote:
> > On Sun, 2010-03-14 at 18:33 +0200, Maxim Levitsky wrote:
> > > Hi,
> > > 
> > > I have some interesting results in regard to long transmission
> > > blackouts I experience with my ath5k based wifi card (AR2424 inside
> > > aspire one).
> > > 
> > > This is very old issue, and unfortunately I didn't have time to debug
> > > it properly. Fortunately, and strangely card works OK, if only used to
> > > surf the webs and download files.
> > > 
> > > This is standard testcase (don't know why nc sometimes exits, probably
> > > due to interrupted syscall):
> > > 
> > > This is run on the ath5k hosting machine. At same time network is
> > > quiet, and channel I use (#1) is free of neighbours APs.
> > > 
> > > Open AP is used, no networkmanager is running, so nothing could trigger
> > > the scan of wireless networks, and indeed the printks confirmed that
> > > card isn't reset randomly.
> > > 
> > > I do:
> > > 
> > > while true ; do nc -u $SERVER 1 < /dev/zero ; done
> > > 
> > > 
> > > After a while (no resets meanwhile), transmission stops.
> > > 
> > > After adding some strategic printks, I see that card sends
> > > AR5K_INT_RXORN interrupt, which is very strange, because all the card
> > > does is transmitting.
> > > 
> > > On purpose I disabled the card reset that follows the AR5K_INT_RXORN,
> > > and see that transmission halts before the reset.
> > > 
> > > The reset usually restores functionality, but often it is followed by
> > > another bath of AR5K_INT_RXORN errors.
> > > 
> > > Sometimes however, after the reset, nothing happens, nothing
> > > transmitted, until another reset is done. This also usually triggers
> > > disassociation, and long stalls on all TCP connections. enough said...
> > > 
> > > 
> > > To be sure I merged the git tip of the wireless-testing tree only to
> > > find out that nothing changed. I use vanilla git tree from kernel.org,
> > > but this issue is so old that the above isn't relevant much.
> > > 
> > > When I say 'high load' I probably overestimate it. I could trigger that
> > > bug by uploading to affected machine. The stream of tcp ACKs is enough
> > > to trigger this (about 80 Kbytes/s if I remember correctly)
> > > 
> > > Maybe deterministic timing between packets is what triggers this bug.
> > > What I know that a normal download from the web at ~300 Kbytes/s
> > > doesn't trigger that bug.
> > > 
> > > This is output of my hand crafted printks:
> > > 
> > > <4>[ 2489.249349] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.249882] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.250435] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.250881] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.251318] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.251768] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.252117] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.252640] ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x800824b5
> > > <4>[ 2489.254196] ath5k_hw_get_isr: ISR: 0x00000001 IMR: 0x800824b5
> > > <4>[ 2490.586420] ath5k_hw_get_isr: ISR: 0x00000020 IMR: 0x800824b5
> > > <4>[ 2490.586432] ath5k: reset due to AR5K_INT_RXORN
> > > <4>[ 2490.586453] ath5k_hw_get_isr: ISR: 0x00000020 IMR: 0x800824b5
> > > <4>[ 2490.586461] ath5k: reset due to AR5K_INT_RXORN
> > > <4>[ 2490.586479] ath5k_hw_get_isr: ISR: 0x00000020 IMR: 0x800824b5
> > > <4>[ 2490.586487] ath5k: reset due to AR5K_INT_RXORN
> > > <4>[ 2490.586505] ath5k_hw_get_isr: ISR: 0x00000020 IMR: 0x800824b5
> > > 
> > > Best regards,
> > > 
> > > 	Maxim Levitsky
> > 
> > Luis, I think this is some internal chip problem.
> > Maybe you can look at your internal documentation and see what is going
> > on.
> > 
> > Meanwhile, I verified that phy caliration interval doesn't affect this
> > problem.
> > 
> > It pretty much is as simple, as this:
> > 
> > While transmitting, card randomly stops transmitting (in fact it stops
> > issuing any IRQs) and then it starts to bomb out the AR5K_INT_RXORN
> > 
> > (In above trace you see it gave RXOK, before RXORN, but this doesn't
> > usually happen.)
> > 
> > A reset doesn't help always.
> > 
> > I really don't know what to do next.
> > 
> > Also note that for completeness sake I tried the ANI patch, the patch in
> > this thread.
> > 
> > I also tried once MadWifi, and had same results.
> > 
> > Best regards,
> > Maxim Levitsky
> 
> Anybody?

have you tried bob's patch, he sent in reply to the previous thread about this 
topic and as "[PATCH 4/5] ath5k: fix race condition in tx desc processing"?

bruno
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel