Re: bf_next not NULL!

2016-07-16 Thread Andrew Stevenson

On 16 Jul 2016, at 17:51, Adrian Chadd wrote:

> hi!
> 
> both of these should be fixed in stable/11 :)


Excellent. Time for an upgrade then I guess :-)

Thanks very much!

Andrew
___
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"


[Bug 203745] A2DP Support for Bluetooth Headphone Audio

2016-07-16 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203745

Alexey Dokuchaev  changed:

   What|Removed |Added

 CC||da...@freebsd.org

--- Comment #32 from Alexey Dokuchaev  ---
(In reply to Hans Petter Selasky from comment #3)

These instructions worked perfectly for my combination of FreeBSD 8.4 and Leme
EB30A headphones.  However, music playback has occasional hiccups despite
unloaded CPU and that distance between devices was minimal and unobstructed;
any ideas what might be causing them?  (They do not occur when feeding sound
from a smartphone AFAICT.)

Another issue I had was with volume control.  By default it is set to 128
(returned correctly by issuing SNDCTL_DSP_GETPLAYVOL ioctl() call), and looking
at virtual-oss code it should support SNDCTL_DSP_SETPLAYVOL as well, but it
didn't for me (volume always remains 128).

Apart of that, great work Hans, thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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-16 Thread Adrian Chadd
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 for now
> Restoring Cal data from DRAM
> Restoring Cal data from EEPROM
> ar9300_hw_attach: ar9300_eeprom_attach returned 0
> 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] 3 RX streams; 3 TX streams
> ath0: AR9380 mac 448.3 RF5110 phy 3779.2
> ath0: 2GHz radio: 0x; 5GHz radio: 0x
>
> 

Re: bf_next not NULL!

2016-07-16 Thread Willem Offermans
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 for now
Restoring Cal data from DRAM
Restoring Cal data from EEPROM
ar9300_hw_attach: ar9300_eeprom_attach returned 0
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] 3 RX streams; 3 TX streams
ath0: AR9380 mac 448.3 RF5110 phy 3779.2
ath0: 2GHz radio: 0x; 5GHz radio: 0x

wlan0: flags=8c43 metric 0 mtu 
1500
ether c4:6e:1f:1e:b6:32
inet 192.168.5.1 netmask 0xff00 broadcast 192.168.5.255
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng 

bf_next not NULL!

2016-07-16 Thread Andrew Stevenson
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,

Andrew
___
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"