Re: AR9462 PCIe1x card: endless messages in dmesg

2015-01-21 Thread Adrian Chadd 
Nope, because kernel modules need to pick up options from opt_xxx.h,
and there's a lot of them.

(other modules do it by picking defaults; but the wifi infrastructure
has a lot of options.)



-a
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: AR9462 PCIe1x card: endless messages in dmesg

2015-01-21 Thread Adrian Chadd 
Put ATH_ENABLE_11N in your kernel config.

Oh and if you build modules, build it with make buildkernel, no cd
/usr/src/sys/dev/modules/ath; make.



-a


On 21 January 2015 at 01:20, Alexey Dokuchaev da...@nsu.ru wrote:
 Hi there,

 Just installed this AR9462-based PCIe (1x) card into my work i386 desktop
 running fortnight-old -CURRENT (r276691).  So far so good -- it delivers
 pretty stable, lagless Internet experience, but keeps shitting in kernel
 buffer very quickly with these (tons of them):

 ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
 ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?

 Should I worry about it?  What's the proper way to shut it up?

 ./danfe
 ___
 freebsd-wireless@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
 To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: AR9462 PCIe1x card: endless messages in dmesg

2015-01-21 Thread Alexey Dokuchaev 
On Wed, Jan 21, 2015 at 08:06:09AM -0800, Adrian Chadd wrote:
 Put ATH_ENABLE_11N in your kernel config.

I will try that tomorrow, thanks!

 Oh and if you build modules, build it with make buildkernel, no cd
 /usr/src/sys/dev/modules/ath; make.

Everything I've reported thus far was with kernel and modules built with
make buildkernel (and no local patches applied), but I'll keep a note.

That said, it would be nice to rebuild ath(4) with cd ..  make like
you're mentioned.  Can we expect it one day? ;-)

./danfe
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: Fragmented EAP ACK problem on -current

2015-01-21 Thread Olivier Cochard-Labbé 
The problem was identified and have nothing to do with the wireless stack.
The author of hostapd found the problem: The RADIUS UDP packet containing
the client certificate is a very big packet, and was fragmented between the
Authenticator and Authentication server. The first (big) UDP packet never
reach to join the Authentication server (OpenVPN tunnel between)... This is
why the authentication server never ACK, then Authenticator never transfer
the ACK to the client.

Sorry for the noise.
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: Problem with iwn: iwn0: iwn_intr: fatal firmware error

2015-01-21 Thread Sergey V. Dyatko 
On Wed, 21 Jan 2015 16:32:50 +0300
Ilya A. Arkhipov rum1...@ya.ru wrote: 

 Hi All,
 
 Yesterday, I update my laptop to (HEAD: 373e66e(master) or r277372), and got
 problem with iwn like: iwn0: iwn_read_firmware: ucode rev=0x12a80601
 iwn0: iwn_intr: fatal firmware error
 firmware error log:
   error type  = UNKNOWN (0x1038)
   program counter = 0x000256B0
   source line = 0x1014
   error data  = 0x1014
   branch link = 0x000255CC000255CC
   interrupt link  = 0xD6BE
   time= 10659578
 driver status:
   tx ring  0: qid=0  cur=0   queued=0  
   tx ring  1: qid=1  cur=0   queued=0  
   tx ring  2: qid=2  cur=0   queued=0  
   tx ring  3: qid=3  cur=0   queued=0  
   tx ring  4: qid=4  cur=0   queued=0  
   tx ring  5: qid=5  cur=0   queued=0  
   tx ring  6: qid=6  cur=0   queued=0  
   tx ring  7: qid=7  cur=0   queued=0  
   tx ring  8: qid=8  cur=0   queued=0  
   tx ring  9: qid=9  cur=22  queued=0  
   tx ring 10: qid=10 cur=0   queued=0  
   tx ring 11: qid=11 cur=0   queued=0  
   tx ring 12: qid=12 cur=0   queued=0  
   tx ring 13: qid=13 cur=0   queued=0  
   tx ring 14: qid=14 cur=0   queued=0  
   tx ring 15: qid=15 cur=0   queued=0  
   tx ring 16: qid=16 cur=0   queued=0  
   tx ring 17: qid=17 cur=0   queued=0  
   tx ring 18: qid=18 cur=0   queued=0  
   tx ring 19: qid=19 cur=0   queued=0  
   rx ring: cur=20
 iwn0: iwn_panicked: controller panicked, iv_state = 1; resetting...
 iwn0: iwn_read_firmware: ucode rev=0x12a80601
 
 After that I've destroy wlan0 and start /etc/netstart, after that wlan0 get
 status: associated but ip was 0.0.0.0 ;( I've again destroy wlan0 and
 get: #8  0x80d3d602 in calltrap ()
 at /usr/src_git/sys/amd64/amd64/exception.S:235 #9  0x805900b8 in
 iwn_tx_done (sc=value optimized out, desc=value optimized out,
 ackfailcnt=value optimized out, status=0 '\0') at ieee80211_ratectl.h:99
 #10 0x80589a9e in iwn_notif_intr (sc=0xfef62000)
 at /usr/src_git/sys/dev/iwn/if_iwn.c:3794
 #11 0x80588320 in iwn_intr (arg=0xfef62000)
 at /usr/src_git/sys/dev/iwn/if_iwn.c:4093
 #12 0x8092bd41 in intr_event_execute_handlers (
 p=value optimized out, ie=0xf800031dd900)
 at /usr/src_git/sys/kern/kern_intr.c:1241
 #13 0x8092c6fc in ithread_loop (arg=0xf80003230ce0)
 at /usr/src_git/sys/kern/kern_intr.c:1254
 
 file was attached.
 
 Have someone the same issue?
 
 
hi,

from my dmesg:

wlan0: link state changed to DOWN
wlan0: link state changed to UP
iwn0: iwn_intr: fatal firmware error
firmware error log:
  error type  = UNKNOWN (0x1038)
  program counter = 0x0002A698
  source line = 0x1014
  error data  = 0x1014
  branch link = 0x0002A5B40002A5B4
  interrupt link  = 0xEC7A
  time= 1518592964
driver status:
  tx ring  0: qid=0  cur=3   queued=0  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=6   queued=1  
  tx ring  4: qid=4  cur=0   queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=248 queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  tx ring 16: qid=16 cur=0   queued=0  
  tx ring 17: qid=17 cur=0   queued=0  
  tx ring 18: qid=18 cur=0   queued=0  
  tx ring 19: qid=19 cur=0   queued=0  
  rx ring: cur=33
iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting...
iwn0: iwn_read_firmware: ucode rev=0x12a80601

it is  r277355 amd64, GENERIC-NODEBUG kernel

iwn0@pci0:2:0:0:class=0x028000 card=0x42628086 chip=0x0086 rev=0xc4
hdr=0x00 vendor = 'Intel Corporation'
device = 'Centrino Wireless-N 2230'
class  = network


sometimes network begins to work after few minutes (skype became online:) ),
sometimes (when I-need-network-right-now) I do /etc/rc.d/netif restart 

-- 
wbr, tiger

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

AR9462 PCIe1x card: endless messages in dmesg

2015-01-21 Thread Alexey Dokuchaev 
Hi there,

Just installed this AR9462-based PCIe (1x) card into my work i386 desktop
running fortnight-old -CURRENT (r276691).  So far so good -- it delivers
pretty stable, lagless Internet experience, but keeps shitting in kernel
buffer very quickly with these (tons of them):

ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?

Should I worry about it?  What's the proper way to shut it up?

./danfe
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org