Re: bf_next not NULL!
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
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: ath (AR9460) no longer works after going to 11-STABLE r302483
... I'm confused as to what's going on.. :) -a On 16 July 2016 at 02:30, Wolfgang Zenker wrote: > Hi, > > * Adrian Chadd [160715 22:40]: >> On 15 July 2016 at 13:28, Wolfgang Zenker wrote: >>> * Adrian Chadd [160715 00:00]: On 14 July 2016 at 14:37, Wolfgang Zenker wrote: > * Adrian Chadd [160710 21:47]: >> Since you've reverted the ath driver directories without success, I'm >> mostly out of simple ideas. I think you need to bisect the whole >> kernel version until you find the commit that broke things. > > done. The commit is 11-STABLE r302410. AFAICS the only change here > is the removal of debugging options from the GENERIC kernel config: > > https://svnweb.freebsd.org/base/stable/11/sys/amd64/conf/GENERIC?r1=302408&r2=302410 > ... loool, okay. Let me see. > Try INVARIANTS and INVARIANT_SUPPORT. Maybe something in the ath driver needs it.. oops! > >>> Nope, wlan0 still works after disabling INVARIANTS and INVARIANT_SUPPORT. >>> Any suggestions for next try? > >> Just try disabling the others and see what happens. > > commenting out DEADLKRES and MALLOC_DEBUG_MAXZONES in addition to > INVARIANTS and INVARIANT_SUPPORT did not change the situation: ath > still worked. Re-enabling all of the above and disabling WITNESS > resulted in ath failing. > > Wolfgang ___ 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!
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 > > wlan0: flags=8c43 metric 0 > mtu 1500 > ether c4:6e:1f:1e:b6:32 > inet 192.168.5.1 netmask 0
Re: bf_next not NULL!
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 (autoselect) status: no carrier ssid MyWirelessSSID channel 108 (5540 MHz 11a) regdomain ETSI country indoor ecm authmode OPEN privacy OFF
bf_next not NULL!
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"