Re: Can't get BCM4313 ndis driver to work

2016-07-18 Thread Felix Friedlander 
> On 19 Jul. 2016, at 10:41, Yuri  wrote:
> 
>> On 07/17/2016 16:02, Yuri wrote:
>> This post https://forums.freebsd.org/threads/33728/ says that BCM4313 should 
>> work.
>> 
>> But ndis driver when loaded doesn't create the ndis0 interface.
>> 
>> I think only bcmwl564_sys.ko should suffice, though I also tried with 3 .ko 
>> files too like this guy suggested.
>> 
>> 
>> Why doesn't ndis0 appear? How to troubleshoot this? Is BCM4313 still not 
>> supported by the native drivers
> 
> This was probably a wrong version of the Windows drivers. Some website called 
> WikiDrivers had the right version.
> 
> Yuri
> 

Does this mean that NDIS drivers are working again? I thought they were broken…

-- 
Felix Friedlander 



smime.p7s
Description: S/MIME cryptographic signature

Re: Can't get BCM4313 ndis driver to work

2016-07-18 Thread Yuri 

On 07/17/2016 16:02, Yuri wrote:
This post https://forums.freebsd.org/threads/33728/ says that BCM4313 
should work.


But ndis driver when loaded doesn't create the ndis0 interface.

I think only bcmwl564_sys.ko should suffice, though I also tried with 
3 .ko files too like this guy suggested.



Why doesn't ndis0 appear? How to troubleshoot this? Is BCM4313 still 
not supported by the native drivers


This was probably a wrong version of the Windows drivers. Some website 
called WikiDrivers had the right version.


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

Re: bf_next not NULL!

2016-07-18 Thread Willem Offermans 
Hello Adrian and FreeBSD friends,

Great news, I cannot wait till stable/11 is out. Thank you for all your 
effort.

On Sat, Jul 16, 2016 at 08:51:04AM -0700, Adrian Chadd wrote:
> hi!
> 
> both of these should be fixed in stable/11 :)
> 
> 
> -adrian
> 
> 
> On 16 July 2016 at 03:58, Willem Offermans  wrote:
> > Hello FreeBSD friends,
> >
> > On Sat, Jul 16, 2016 at 12:12:40PM +0200, Andrew Stevenson wrote:
> >> Hi,
> >>
> >> I have an Atheros 9227 card in AP mode. It looks like there is some packet 
> >> loss at the wireless layer, resulting in large delays at the IP layer. 
> >> Also, every few days, nothing seems to be able to associate. Restarting 
> >> the interface (/etc/rc.d/netif restart wlan0) fixes that but the possible 
> >> packet loss remains.
> >>
> >> I notice quite numerous errors in dmesg. Bursts of:
> >>
> >> ath0: ath_tx_default_comp: bf 0xfe826aa0: seqno 550: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe831d20: seqno 551: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe827298: seqno 552: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe815bb0: seqno 553: bf_next not 
> >> NULL!
> >> ath0: ath_tx_default_comp: bf 0xfe821160: seqno 554: bf_next not 
> >> NULL!
> >>
> >> That can go on for about 20 lines, plus the ubiquitous:
> >>
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >> ath0: stuck beacon; resetting (bmiss count 4)
> >>
> >> that seems to be pretty regular.
> >>
> >> My card from dmesg:
> >>
> >> ath0:  mem 0x4810-0x4810 irq 21 at device 0.0 on pci4
> >> ath0: [HT] enabling HT modes
> >> ath0: [HT] enabling short-GI in 20MHz mode
> >> ath0: [HT] 1 stream STBC receive enabled
> >> ath0: [HT] 1 stream STBC transmit enabled
> >> ath0: [HT] 2 RX streams; 2 TX streams
> >> ath0: Enabling register serialisation
> >> ath0: AR9227 mac 384.2 RF5133 phy 15.15
> >> ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0
> >>
> >> And ifconfig output:
> >>
> >> wlan0: flags=8843 metric 0 mtu 1500
> >> ether 64:70:02:f0:c8:03
> >> inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
> >> inet6 fe80::6670:2ff:fef0:c803%wlan0 prefixlen 64 scopeid 0x6
> >> nd6 options=61
> >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g 
> >> status: running
> >> ssid UgH channel 11 (2462 MHz 11g) bssid 64:70:02:f0:c8:03
> >> regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
> >> privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit
> >> txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
> >>
> >> I had previously been using 11ng but have just tried switching to see if 
> >> 11g had the same problems (it seems to).
> >>
> >> I'm running 10.3-STABLE r302736.
> >>
> >> Any ideas?
> >>
> >> Thanks,
> >>
> >
> > Maybe it is not related, maybe it is. I tried to use an Atheros AR938x
> > card in AP mode on FreeBSD 10.3, r302295 and 11.0, r297415 for quite some
> > time now. Of course I got the ``ath0: stuck beacon; resetting (bmiss count
> > 4)`` over and over again. Beside this, I also observed the following
> >   messages:
> >
> > Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> > Jul 12 11:15:47 kwik kernel: ath0: ath_edma_tx_processq: Q3: empty?
> > Jul 12 12:13:33 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 15:10:19 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 16:10:32 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 18:40:01 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 18:42:36 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 19:52:05 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> > Jul 12 20:11:45 kwik kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 
> > 0; skipping
> >
> > and
> >
> > Jun  9 07:37:57 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
> > Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> > Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> > 0x 0x 0x
> > Jun  9 22:21:35 kwik kernel: ath0: hardware error; resetting
> > Jun  9 22:21:35 kwik kernel: ath0: 0x 0x 0x, 
> > 0x 0x 0x
> > Jun  9 23:07:35 kwik kernel: ath0: stuck beacon; resetting (bmiss count 4)
> >
> > The Wifi was so unstable that I looked for a different solution.
> >
> >
> > My card from dmesg:
> >
> > ath0:  mem 0xfbfe-0xfbff irq 16 at device 0.0 on 
> > pci1
> > ar9300_attach: calling ar9300_hw_attach
> > ar9300_hw_attach: calling ar9300_eeprom_attach
> > ar9300_flash_map: unimplemented