Re: Ars Technica article

2020-04-12 Thread Alexey Dokuchaev
[ setting CC to a more appropriate -wireless@ list ]

On Fri, Apr 10, 2020 at 07:20:14PM -0500, Jason Bacon wrote:
> ...
> I think [well-working gfx stack] a great long-term goal, but it will
> take a significant investment of man-hours to get us there.  In the
> meantime there's a lot of lower-hanging fruit, like minor improvements
> to the bsdinstall UI, external media mounting, etc.

What I find more frustrating when reading similar articles (they are
all more or less the same) is that they rarely focus on FreeBSD's *real*
problems (and no, that's not the awkward installer, having to manually
find working DRM port + xf86-video driver combination, search for the
scattered knowledge of which magic lines to add to /etc/rc.conf and/or
/boot/loader.conf, read the Handbook N times before one can set up their
bluetooth mouse, et cetera).  While installer's issues, better defaults,
bash vs sh, sudo, modelines, and those other little things might seem
significant for someone coming from Ubuntu, it would take them a day
to learn, adopt, and get back most, if not all, from their previous
environment.  Our real problems aren't solved that easily, and being
solved painfully slowly.

Leaving X.org/DRM mess aside, we lack a lot in our laptop department.
Our WiFi stack is essentially maintained solely by adrian@, and he's
currently not very active.  Some ~4 y.o. cards like BCM43228 are still
not supported [1].  If you search for "atheros" in our Bugzilla, it
returns 13 bugs, the latest action being on 2019-01-26 (reassignment).

AR5B22 WLAN+Bluetooth combo does not work/broken, discussion [2] had
ended nowhere.

Realtek 5209 card readers are quite common and also do not work; the
WIP OpenBSD driver porting effort [3] is stuck because apparently
something is missing in FreeBSD [subsystems], although [the] driver
seems to faithfully implement the OpenBSD [code].  No kernel hacker
had chimed in to help. :-(

Our WMI stack is unmaintained and incomplete: brightness and multimedia
keys do not work on many laptops despite corresponding kernel modules
being loaded.

This list goes on.  Yes, these are deep, hard problems, not the low-
hanging fruit, but if Foundation decides where to spend some money,
I'd rather see it considers these rather than bsdinstall UI, external
media mounting, or some other "lipstick on a pig" type of tasks.

./danfe

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202501
[2] https://lists.freebsd.org/pipermail/freebsd-wireless/2019-April/008660.html
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-18 Thread Alexey Dokuchaev
On Thu, Apr 18, 2019 at 07:58:34AM -0700, Adrian Chadd wrote:
> Ok, so it found and loaded in the bluetooth firmware into the
> bluetooth NIC RAM.

Why do you think so?

> On Thu, 18 Apr 2019 at 07:50, Matthias Apitz  wrote:
> >
> > I have booted the other C720 from USB and here are the results:
> >
> > # ./ath3kfw -D -d ugen0.4 -I
> > ath3kfw: opening dev 0.4
> > ath3k_is_3012: found AR3012
> > main: AR3012; bcdDevice=2, exiting

/* See if its an AR3012 */
if (ath3k_is_3012(&d)) {
is_3012 = 1;

/* If it's bcdDevice > 1, don't attach */
if (d.bcdDevice > 0x0001) {
ath3k_debug("%s: AR3012; bcdDevice=%d, exiting\n",
__func__,
d.bcdDevice);
exit(0);
}
}

It looks to me it never reached the stage of loading the firmware because
of bcdDevice=2.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-17 Thread Alexey Dokuchaev
On Tue, Apr 16, 2019 at 12:34:12PM +0200, Matthias Apitz wrote:
> # ./ath3kfw -D -d ugen0.3 -I
> ath3kfw: opening dev 0.3
> ath3k_is_3012: found AR3012
> main: state=0x0e
> ROM version: 285343744, build version: 155, ram version: 155, ref clock=1
> ath3kfw: ath3k_fw_read: open: 
> /usr/share/firmware/ath3k//ar3k/AthrBT_0x1102.dfu: No such file or 
> directory

OK, so the file is not in the right place (as indicated by this message).

> ath3k_load_patch: ath3k_fw_read() failed
> Loading patch file failed
> 
> The ROM version: 285343744 does not look like something meaningful,
> maybe the tool reads the wrong place.

It is meaningful and correct, it is just printed in decimal which is
probably bogus:

$ echo 16 o 285343744 p | dc
1102

> Which file I should use from ath3k/share/firmware/ath3k
> # ls -C1
> ar3k
> ath3k-1.fw
> LICENCE.atheros_firmware
> 
> below ar3k/ are a lot more files 

Is there AthrBT_0x1102.dfu amongst them?  Try placing it under
/usr/share/firmware/ath3k/ar3k/ and repeat the procedure.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-15 Thread Alexey Dokuchaev
On Mon, Apr 15, 2019 at 02:52:17PM +0200, Matthias Apitz wrote:
> I have not missed (or deleted) any mail in this thread of 24++ mails.
> But as Adrian said "Does ath3k load OK?" I was confused and thinking
> in a loadable kernel module.

Ah, OK, I understand.  Anyways, now that this little confusion is resolved,
could you try to upload the firmware using this tool?  For me it didn't
work, but that might be because of the particular hardware (USB 3.0/xHCI).
I don't know about C720, but it can be sufficiently different so ath3kfw
would work on it.  This is very important to understand our next course of
action.  Thanks,

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-15 Thread Alexey Dokuchaev
On Sat, Apr 13, 2019 at 12:35:30PM -0700, Adrian Chadd wrote:
> On Sat, 13 Apr 2019 at 12:14, Alexey Dokuchaev wrote:
> > ...
> > If you tell me how to implement Linuxish usleep_range() correctly in
> > our userland, I can do that. :-)
> 
> usleep_range() is just the same as usleep() at either min, max or a value
> in between. It's just a hint to the scheduler that says "look, don't sleep
> exactly for this amount of time to wake me up; here are my bounds that are
> fine so if you schedule something else before then don't forget about me."

I understand, and it makes sense to give hints to the scheduler from the
kernel side, but less so when calling uslee() from userland.

> Just pick a value in between. :-)

Oh well, maybe that'll do.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-15 Thread Alexey Dokuchaev
On Mon, Apr 15, 2019 at 06:48:36AM +0200, Matthias Apitz wrote:
> I git cloned it and built it, but this does not give any kernel module
> to load: [...]
> 
> $ ./ath3kfw
> Usage: ath3kfw (-D) -d ugenX.Y (-f firmware path) (-I)
> -D: enable debugging
> -d: device to operate upon
> -f: firmware path, if not default
> -I: enable informational output
> 
> What next? Will it brick my Wifi chip? I need this C720 for work. :-)

No, it should not brick your chip (well, at least it didn't brick mine,
even that it didn't manage to load the firmware correctly and left the
chip in a bogus state, but reboot seems to cure it).

I've posted exact instructions how to use it and debug log earlier in
this thread, you being CC'ed, I don't understand how could you've missed
those emails.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-13 Thread Alexey Dokuchaev
On Sat, Apr 13, 2019 at 11:44:25AM -0700, Adrian Chadd wrote:
> Hm, is this a problem with our usb3 stack itself?
> 
> If you send me a pull request against ath3k I'll merge it into my git
> tree just for completeness.

If you tell me how to implement Linuxish usleep_range() correctly in our
userland, I can do that. :-)

> Maybe we need to loop in hps@ with a bunch of usbdump output to see what
> the transactions look like...

CC'ed (sorry for the lack of context hps@, but it's hard with Adrian's
top-post replies).  Please see the archives for the gory details.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-13 Thread Alexey Dokuchaev
On Fri, Apr 12, 2019 at 05:12:18PM +, Alexey Dokuchaev wrote:
> I've then rebooted back into FreeBSD.  Apparently, this AR3012 hardware
> is very fragile, it can be easily left in confused state and won't accept
> further commands, "usbconfig reset" does not help.  To avoid this, it is
> better run ./ath3kfw as root, after powercycling machine (to reset the
> card).  This got me further:
> 
> ath3kfw: opening dev 2.2
> main: state=0x0e
> ROM version: 285343744, build version: 155, ram version: 155, ref clock=1
> ath3k_init_firmware: loading ath3k-1.fw
> ath3k_load_fwfile: file=/home/danfe/ath3k/share/firmware/ath3k/ath3k-1.fw,
> size=246804
> ath3k_load_fwfile: transferring 20 bytes, offset 4096

Looks like there is a bug with the logging, consider this pseudo-patch:

@@ ...
ath3k_debug("%s: transferring %d bytes, offset %d\n",
__func__,
-   sent,
-   size);
+   size, sent);

> ...
> ath3k_load_fwfile: transferring 65556 bytes, offset 4096
> LIBUSB_FUNCTION: libusb_bulk_transfer enter
> LIBUSB_FUNCTION: libusb_submit_transfer enter
> LIBUSB_FUNCTION: libusb_submit_transfer leave 0
> LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
> LIBUSB_FUNCTION: libusb10_handle_events_sub enter
> LIBUSB_TRANSFER: sync I/O done
> LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
> LIBUSB_FUNCTION: libusb_bulk_transfer leave
> Can't load firmware: err=Timeout, size=4096
> ath3k_load_fwfile: transferring 65556 bytes, offset 4096

I've found seemingly related bug report about Atheros BT devices (ath3k)
failing to work on USB 3.0 buses, while working well on USB 2.0:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400215

In 2015, a work-around for this problem was committed* to Linux kernel:

author  Adam Lee2015-01-28
committer   Marcel Holtmann2015-01-29
commit  c561a5753dd631920c4459a067d22679b3d110d6

  Bluetooth: ath3k: workaround the compatibility issue with xHCI controller

  ath3k devices fail to load firmwares on xHCI buses, but work well on
  EHCI, this might be a compatibility issue between xHCI and ath3k chips.
  As my testing result, those chips will work on xHCI buses again with
  this patch.

  This workaround is from Qualcomm, they also did some workarounds in
  Windows driver.

I've patched ath3kfw tool in a similar way like this:

+#define TIMEGAP_USEC_MIN 50
+#define TIMEGAP_USEC_MAX 100
+
+static inline void
+usleep_range(unsigned long min, unsigned long max)
+{
+usleep(min); // or usleep(max);
+}
 ...

 while (count) {
+/* workaround the compatibility issue with xHCI controller */
+usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);

Unfortunately, this hack didn't help, neither with usleep(min) nor with
usleep(max).  Error message is the same "Can't load firmware: err=Timeout,
size=4096".

I will try to find a USB 2.0-only laptop which supports mini-PCIe cards
to get more data points, but not sure if I can find one easily.  It would
be nice if someone who has pre-xHCI hardware could conduct this test.

./danfe

*) 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/ath3k.c?id=c561a5753dd631920c4459a067d22679b3d110d6
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-12 Thread Alexey Dokuchaev
On Thu, Apr 11, 2019 at 02:23:50PM +, Alexey Dokuchaev wrote:
> On Thu, Apr 11, 2019 at 06:36:26AM -0700, Adrian Chadd wrote:
> > I have a tool to upload firmware -- github.com/erikarn/ath3k.
> > See if that helps!
> 
> Something's wrong:
> 
>   $ git clone https://github.com/erikarn/ath3k.git
>   $ cd ath3k/src/usr.bin/ath3k
>   $ make
>   $ usbconfig list | grep 0x0930
>   ugen2.2:  at usbus2 <...>
>   $ ./ath3kfw -D -d ugen2.2 -I
>   ath3kfw: opening dev 2.2
>   ath3k_get_state: libusb_control_transfer() failed: code=-4
>   main: ath3k_get_state() failed!

I've booted off Fedora 26 USB thumbdrive, to discover that everything
works (dualband WiFi, BT, devices can be discovered), so the hardware
is not faulty.

I've converted Linux' drivers/bluetooth/ath3k.c to libusb to obtain
rom_version and ref_clock of my card, so I know which firmware files
I need (just in case):

  # ./a.out
  get_state -> 1, state = 0xce
  get_version -> 20, rom_version = 0x1102, clock value = 40

I've then rebooted back into FreeBSD.  Apparently, this AR3012 hardware
if very fragile, it can be easily left in confused state and won't accept
further commands, "usbconfig reset" does not help.  To avoid this, it is
better run ./ath3kfw as root, after powercycling machine (to reset the
card).  This got me further:

ath3kfw: opening dev 2.2
main: state=0x0e
ROM version: 285343744, build version: 155, ram version: 155, ref clock=1
ath3k_init_firmware: loading ath3k-1.fw
ath3k_load_fwfile: file=/home/danfe/ath3k/share/firmware/ath3k/ath3k-1.fw,
size=246804
ath3k_load_fwfile: transferring 20 bytes, offset 4096
LIBUSB_FUNCTION: libusb_bulk_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer leave 0
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_TRANSFER: sync I/O done
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_bulk_transfer leave
ath3k_load_fwfile: transferring 4116 bytes, offset 4096
...
ath3k_load_fwfile: transferring 8212 bytes, offset 4096
...
ath3k_load_fwfile: transferring 12308 bytes, offset 4096
...
... (numbers go 16404, 20500, 24596, 28692, 32788, 36884, 40980, 45076 ...)
...
ath3k_load_fwfile: transferring 65556 bytes, offset 4096
LIBUSB_FUNCTION: libusb_bulk_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer leave 0
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_TRANSFER: sync I/O done
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_bulk_transfer leave
Can't load firmware: err=Timeout, size=4096
ath3k_load_fwfile: transferring 65556 bytes, offset 4096

After that, ``hccontrol inquiry'' stops working at all (says "operation
timed out"), dmesg shows this:

ubt0: ubt_ctrl_write_callback:782: control transfer failed: USB_ERR_TIMEOUT
ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command
OGF=0x1, OCF=0x1. Timeout

./danfe

P.S.  Fedora is amazing (just as Ubuntu) on this laptop: everything works,
WMI multimedia keys, LCD brightness control, mic/speaker mute buttons, WiFi
and Bluetooth.  Under FreeBSD, only WiFi works from this list. :-(
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-11 Thread Alexey Dokuchaev
On Thu, Apr 11, 2019 at 04:05:27PM +, Matthias Apitz wrote:
> On Thu, 11 Apr 2019 14:23:50 +0000, Alexey Dokuchaev wrote:
> > On Thu, Apr 11, 2019 at 06:36:26AM -0700, Adrian Chadd wrote:
> >> I have a tool to upload firmware -- github.com/erikarn/ath3k.
> >> See if that helps!
> >
> > Something's wrong:
> >
> >   $ git clone https://github.com/erikarn/ath3k.git
> >   $ cd ath3k/src/usr.bin/ath3k
> >   $ make
> >   $ usbconfig list | grep 0x0930
> >   ugen2.2:  at usbus2 <...>
> >   $ ./ath3kfw -D -d ugen2.2 -I
> >   ath3kfw: opening dev 2.2
> >   ath3k_get_state: libusb_control_transfer() failed: code=-4
> >   main: ath3k_get_state() failed!
> >
> > USB device permissions are fine.

To be clear: running it root does not change the output.

> Is this on CURRENT?

Yes, and pretty fresh one (kernel 1300018, userland 1300014).

Do you observe different results?  If so, does it help or can you
share anything?

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-11 Thread Alexey Dokuchaev
On Thu, Apr 11, 2019 at 06:36:26AM -0700, Adrian Chadd wrote:
> I have a tool to upload firmware -- github.com/erikarn/ath3k.
> See if that helps!

Something's wrong:

  $ git clone https://github.com/erikarn/ath3k.git
  $ cd ath3k/src/usr.bin/ath3k
  $ make
  $ usbconfig list | grep 0x0930
  ugen2.2:  at usbus2 <...>
  $ ./ath3kfw -D -d ugen2.2 -I
  ath3kfw: opening dev 2.2
  ath3k_get_state: libusb_control_transfer() failed: code=-4
  main: ath3k_get_state() failed!

USB device permissions are fine.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-11 Thread Alexey Dokuchaev
On Thu, Apr 11, 2019 at 03:13:28PM +0200, Matthias Apitz wrote:
> # usbconfig list
> ...
> ugen0.3:  at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON (100mA)
> 
> The later vendor 0x0489 product 0xe056 seems to be:
> 
> https://cateee.net/lkddb/web-lkddb/BT_ATH3K.html

Yes, it is also Atheros AR3012 (with sflash firmware), in Linux it's
handled by the same ath3k driver as my chip.  I'll try to boot under
Ubuntu LiveCD on the weekend to see if it really works.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-11 Thread Alexey Dokuchaev
On Thu, Apr 11, 2019 at 12:46:47PM +0200, Matthias Apitz wrote:
> > ...
> > I've just stumbled upon this email* of Adrian's that tells how to enable
> > Bluetooth Coexistence by adding ``hint.ath.0.btcoex_profile="wb222"'' to
> > /boot/device.hints (for AR9462 cards).  I've done that, and logs tell me
> > it is enabled, but Bluetooth still does not work:
> > 
> >   % dmesg | grep -i coex
> >   ath0: Enabling WB222 BTCOEX
> >   # hccontrol inquiry
> >   ... repeated attempts, plenty of devices around ...
> >   Inquiry complete. Status: No error [00]
> 
> I own an Acer C720 and set the same in /boot/device.hints. After boot it
> says in dmesg:
> 
> $ dmesg | grep ath
> ath0:  mem 0xe040-0xe047 at device 0.0 on pci1
> ath0: RX status length: 48
> ath0: RX buffer size: 4096
> ath0: TX descriptor length: 128
> ath0: TX status length: 36
> ath0: TX buffers per descriptor: 4
> ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries
> ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries
> ath0: Enabling WB222 BTCOEX
> ...
> 
> But I don't know how to further enable any BT device.

What does "usbconfig list" say about your BT device?  Mine is
0x0930:0x021c, which is AR3012 with sflash firmware according to
the Linux' drivers/bluetooth/ath3k.c.  Ubuntu users had reported*
similar problems:

  "My BT seems to work to some extent.. answers to commands etc.
   But it doesn't discover anything

   sudo hcitool -i hci0 inq gives nothing.. even though devices
   are discoverable."

Which apparently might be solved by updating the card's firmware:

  commit 0a9640c85c781a4ec0c82f16fbf7333b7ce6daa6
  Author: Costa Yao
  Date: Wed Jul 4 17:38:09 2012 +0800

ar3k: add patch and sysconfig for Qualcomm Atheros AR9462

 add patch and sysconfig for Qualcomm Atheros AR9462

Signed-off-by: Costa Yao
Signed-off-by: Ben Hutchings

This commit is from 2012, but I'm not sure how relevant it is to
FreeBSD because it seems that ATH_EEPROM_FIRMWARE is disabled by
default in our ath(4); then again, I have no real knowledge about
our drivers and how ath3k/ath9k (BT/WiFi) parts are handled.

./danfe

*) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1024884
   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1394368
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-11 Thread Alexey Dokuchaev
On Wed, Apr 10, 2019 at 03:22:50PM +, Alexey Dokuchaev wrote:
> On Tue, Apr 09, 2019 at 04:03:44PM +0000, Alexey Dokuchaev wrote:
> > On Sun, Jun 02, 2013 at 09:59:05AM -0700, Adrian Chadd wrote:
> > > Hi,
> > > 
> > > It's supported in -HEAD.
> 
> Driver attaches correctly if I move module loading to loader.conf(5):
> 
> if_ath_load="YES"
> if_ath_pci_load="YES"
> 
> Bluetooth still doesn't work though.

I've just stumbled upon this email* of Adrian's that tells how to enable
Bluetooth Coexistence by adding ``hint.ath.0.btcoex_profile="wb222"'' to
/boot/device.hints (for AR9462 cards).  I've done that, and logs tell me
it is enabled, but Bluetooth still does not work:

  % dmesg | grep -i coex
  ath0: Enabling WB222 BTCOEX
  # hccontrol inquiry
  ... repeated attempts, plenty of devices around ...
  Inquiry complete. Status: No error [00]

./danfe

*) https://lists.freebsd.org/pipermail/freebsd-wireless/2016-June/006766.html
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-10 Thread Alexey Dokuchaev
On Tue, Apr 09, 2019 at 04:03:44PM +, Alexey Dokuchaev wrote:
> On Sun, Jun 02, 2013 at 09:59:05AM -0700, Adrian Chadd wrote:
> > Hi,
> > 
> > It's supported in -HEAD.
> 
> Hmm, almost six years later, apparently it is still not:
> 
> % uname -UK
> 1300014 1300014
> 
> # kldload if_ath_pci if_ath

Driver attaches correctly if I move module loading to loader.conf(5):

if_ath_load="YES"
if_ath_pci_load="YES"

Bluetooth still doesn't work though.

./danfe
___
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: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD

2019-04-09 Thread Alexey Dokuchaev
On Sun, Jun 02, 2013 at 09:59:05AM -0700, Adrian Chadd wrote:
> Hi,
> 
> It's supported in -HEAD.

Hmm, almost six years later, apparently it is still not:

% uname -UK
1300014 1300014

# kldload if_ath_pci if_ath

% pciconf -lv | tail -4
none2@pci0:3:0:0:   class=0x028000 card=0x66ad chip=0x0034168c
rev=0x01 hdr=0x00
vendor = 'Qualcomm Atheros'
device = 'AR9462 Wireless Network Adapter'
class  = network

> Bluetooth may or may not work. I've not sat down and focused on that,
> sorry.

Looks like it does not work either: ``hccontrol inquiry'' does not see
any devices around. :-(

./danfe
___
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: Broadcom Wireless BCM43228 support?

2019-01-18 Thread Alexey Dokuchaev
On Sun, Sep 03, 2017 at 10:06:49AM -0700, Adrian Chadd wrote:
> hi!
> 
> It's coming! Landon is going to start on the SIBA bus code and will
> start on the MAC core integration. I'll then do the PHY testing!

Hi Adrian,

Just discovered this thread (and PR 202501).  Any news about BCM43228
support in fresh -CURRENT?

./danfe

> On 3 September 2017 at 09:56,   wrote:
> > Is there a change to get the Broadcom Wireless BCM43228 card working? At the
> > BWNWiki the BCM4322 chip is supported. Look in then Linux b43 documentation
> > http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/ the card has the
> > same PHY. So I have tried to build the Kernel with the BWN_GPL_PHY option
> > and add the device id 0x4359 to the siba_bwn.c File as ???Broadcom BCM43228
> > 802.11a/b/g/n Wireless???. But as result I have got:
> >
> > siba_bwn0:  mem
> > 0xf020-0xf0203fff irq 17 at device 0.0 on pci2
> >
> > siba_bwn0: unknown PCI did (17241)
> >
> > siba_bwn0: unknown the chipset ID 0
> >
> > siba_bwn0: unsupported coreid (unknown)
> >
> > siba_bwn0: warn: bad SPROM CRC
> >
> > siba_bwn0: unknown SPROM revision 0.
> >
> > device_attach: siba_bwn0 attach returned 92
> >
> > pci0:2:0:0: Device leaked memory resources
> >
> > Is the code ready and I miss something or is the N(16) PHY still
> > unsupported? Thank you for some hints.
___
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: AR9462 PCIe1x card: endless messages in dmesg

2015-04-20 Thread Alexey Dokuchaev
On Wed, Jan 21, 2015 at 08:06:09AM -0800, Adrian Chadd wrote:
> On 21 January 2015 at 01:20, Alexey Dokuchaev  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?
> 
> Put ATH_ENABLE_11N in your kernel config.

Haven't used it for a while, but now with 11.0-CURRENT (r280285), suddenly
it doesn't work, telling me this in dmesg:

  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
  Restoring Cal data from Flash
  Restoring Cal data from Flash
  Restoring Cal data from OTP
  ar9300_hw_attach: ar9300_eeprom_attach returned 0
  ath0: unable to alloc memory for 5120 tx descriptors, error 12
  ath0: failed to allocate TX descriptors: 12
  device_attach: ath0 attach returned 12

./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: AR9462 PCIe1x card: endless messages in dmesg

2015-01-22 Thread Alexey Dokuchaev
On Wed, Jan 21, 2015 at 08:06:09AM -0800, Adrian Chadd wrote:
> On 21 January 2015 at 01:20, Alexey Dokuchaev  wrote:
> > 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?
> 
> Put ATH_ENABLE_11N in your kernel config.

This helped, thank you.  Message storm is gone.  It seems I've been stripping
GENERIC overly aggressively.  Would it make sense to add these lines to the
/usr/src/sys/modules/ath_pci/Makefile:

  .if !defined(KERNBUILDDIR)
  CFLAGS+= -DATH_ENABLE_11N <... maybe some other useful defines ...>
  .endif

?  This way, in-kernel ath_pci(4) would obey kernel config, yet module will
always have them by default.  As a bonus, this would allow to build it with
simply calling make(1) from the module directory.

./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: Dual-band AR5414 card test-run on stable/8 and head

2015-01-21 Thread Alexey Dokuchaev
On Wed, Jan 21, 2015 at 03:12:36PM +0600, Alexey Dokuchaev wrote:
> On Tue, Jan 20, 2015 at 08:47:17PM -0800, Adrian Chadd wrote:
> > No idea why it doesn't work on stable/8. That's odd. It should work
> > just fine.
> 
> True, esp. since it lists the nets and apparently can talk to DHCP server;
> getting "sendto: Host is down" is very strange.  I will try again at home
> or some cafe [to see why this AR5413 behaves].

[Typing this email wirelessly over AR5413]

Works like a charm at home; hooked to the Netgear router at channel 11
(2462 MHz 11g).  LED is sane after previously mentioned dances and had
survived the suspend/resume.  Not sure what was wrong at the office, but
I'll try to find out.

./danfe

P.S.  Didn't try shutting the laptop down yet, maybe it will bring more
dragons (will of course be reported).
___
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"


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"


Re: Dual-band AR5414 card test-run on stable/8 and head

2015-01-21 Thread Alexey Dokuchaev
On Tue, Jan 20, 2015 at 08:47:17PM -0800, Adrian Chadd wrote:
> No idea why it doesn't work on stable/8. That's odd. It should work just
> fine.

True, esp. since it lists the nets and apparently can talk to DHCP server;
getting "sendto: Host is down" is very strange.  I will try again at home
or some cafe.

> sysctl dev.ath.0.ledon=<1 | 0 - ie, the LED polarity>
> sysctl dev.ath.0.softled=1
> 
> Toggle softled 0 -> 1 each time you change ledpin, just to make sure
> the programming takes.

OK, running the following loop toggles LED on and off for a second:

  sysctl dev.ath.0.ledpin=1
  while :; do
  sysctl dev.ath.0.ledon=1
  sysctl dev.ath.0.softled=0
  sysctl dev.ath.0.softled=1
  sleep 1
  sysctl dev.ath.0.ledon=0
  sysctl dev.ath.0.softled=0
  sysctl dev.ath.0.softled=1
  sleep 1
  done

I got confused in the beginning, because it was not obvious that actually
both softled=0 and softled=1 commands are required after each ledon change.

When I changed the pin (0 -> 1) and set LED to off, the card started to
show some activity, looking sane.  So it looks like it generally DTRT, but
needs to be told which pin to use.  Any hint I can put in /boot/loader.conf
for that, or I have to patch the driver?

> What's broken with suspend/resume? That should be fixed.

I didn't imply "broken wireless stack and/or drivers".  It took quite a
long time (almost three minutes) and several presses of power button, all
accompanied with weird screen artifacts, to get laptop back to life.  Some
relevant messages:

  pcib0: failed to set ACPI power state D2 on \134_SB_.PCI0: AE_BAD_PARAMETER
  acpi0: cleared fixed power button status
  error: [drm:pid1651:intel_lvds_enable] *ERROR* timed out waiting for panel to 
power off
  uhci_interrupt: host system error
  uhci_interrupt: host controller process error
  wakeup from sleeping state (slept 00:02:52)

On stable/8 resume is nearly instant (around one second to get myself back
to X11 with keyboard and mouse working).

> I've no idea about what or why it broke on stable/8 but isn't on
> -HEAD. I've done some pretty significant surgery to ath and net80211
> since stable/8. You can try narrowing it down by trying stable/9 and
> stable/10 to see if it started working during one of those releases.

Yes, I will probably do something like that.  Thanks Adrian!

./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"


Dual-band AR5414 card test-run on stable/8 and head

2015-01-20 Thread Alexey Dokuchaev
Hi there,

Recently I've purchased few assorted AR-based wireless cards.  Original
plan was to replace 2200BG Intel of mine (it's not really stable and driver
does not support frame injection), but this goal had failed: my new awesome
(and quite expensive) industry-grade 9220-based dual-band card was too tall
for my laptop's miniPCI bay and had MMCX antenna plugs rather than U.FL. :(

So I was only left to play with AR5414 2.4GHz/5GHz (per specs from the shop)
card; looks like it is Askey WLL4070-D50.

After doing "ifconfig ath0" (on stable/8, this loads ath.ko):

ath0:  mem 0xb011-0xb011 irq 17 at device 8.0 on pci6
ath0: [ITHREAD]
ath0: AR5413 mac 10.5 RF5413 phy 6.1

.. and "kldload ath_pci" on head (r277422, ifconfig(8) alone does not DTRT):

ath0:  mem 0xb011-0xb011 irq 17 at device 8.0 on pci6
ath0: AR5413 mac 10.5 RF5413 phy 6.1
ath0: 2GHz radio: 0x; 5GHz radio: 0x0063

Per `pciconf -lv`, it's class=0x02 card=0x132910cf chip=0x001b168c
rev=0x01 hdr=0x00 network ethernet, by Atheros Communications Inc.  Device
string differs between stable/8 (AR5006 family 802.11abg Wireless NIC) and
head (AR5413/AR5414 Wireless Network Adapter [AR5006X(S) 802.11abg]).

Now, here's my quest.  I first tried to use it under stable/8 (which is my
every-day working system).  Apparently it could connect to the access point
and obtained DHCP lease, but I could not ping even the gateway (and thus
anything outside).  I've also noticed two things:

1). WiFi LED is always on, immediately once I press the power button (before
FreeBSD gets to boot).  With 2200BG, it was actually correctly reflecting
network activity.  Any chance it can be fixed to work with Atheros card(s)?
This applies to both stable/8 and head.  The LED goes off only when laptop
is switched off or put to suspend (S3).

2). I have "WiFi radio on/off" button on the keyboard (Fn-F2) which seems
to work with both cards, Intel and Askey.  There is a difference, however:
with iwi(4), there are "radio turned off/on" messages in dmesg, but nothing
alike with ath(4).  Since LED stays always on, it is impossible to easily
tell at which state is the card at any given moment.

On -CURRENT, modulo that I had to "kldload ath_pci" instead of just saying
"ifconfig ath0", it works quite well.  I could connect to the office WiFi
(at 2.4GHz, probably because the access point doesn't support or offer 5GHz
radio), and finally I could ssh wirelessly and has the same responsiveness
as on copper (previously, with 2200BG, it was pretty laggy, bad enough for
typing anything become a real PITA).  Too bad I cannot stay on -CURRENT for
too long due to broken suspend/resume cycle.

TL;DR: the card works on head, but not on stable/8; any revisions I should
take a look at, test, and ask for MFC if all goes well?  What about always-
on LED, can it be controlled?  Does ath(4) expects anything from e.g. ACPI
to be able to do so?

I will probably continue to buy more of ath(4) cards to see how well they
behave. :-)

./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: Intel Pro/Wireless 2200BG iwi(4) card stopped working in 8-stable

2015-01-09 Thread Alexey Dokuchaev
On Sat, Oct 06, 2012 at 03:12:58AM +0700, Alexey Dokuchaev wrote:
> On Fri, Oct 05, 2012 at 07:02:26AM -0700, Adrian Chadd wrote:
> > On 5 October 2012 05:38, Alexey Dokuchaev  wrote:
> > > Since this card gave me lots of troubles over the past, any one can
> > > recommend a decent mini-pci replacement?  It looks like ath(4) chips
> > > are currently best supported. [...]
> > 
> > AR5416 or AR9220 will be fine. Even an AR9160 will be fine.
> 
> OK, but shall I give predilection towards one of them, or they're all
> pretty much the same?

Today I've revisited this old topic and found that similar question was
asked before on ath9k-de...@lists.ath9k.org [1].  I will quote some parts
of it here (and thus answer my own question) for the sake of history.

  Gen 1 - AR5008:
  AR5416+AR5122 - 2x2 dual band, PCI
  AR5416+AR5133 - 3x3 dual band, PCI
  AR5418+AR5133 - 3x3 dual band, PCIe

  Gen 2 - AR9001:
  AR9160+AR9104 - 2x2 dual band, PCI
  AR9160+AR9106 - 3x3 dual band, PCI

  Gen 3 - AR9002:
  AR9220 - 2x2, dual band, PCI
  AR9280 - 2x2, dual band, PCIe

[We know that] the AR9002 is a single chip solution, likely reducing cost,
power and size. But is there any improvement to radio functionality or
other features?

Answer (by Luis R. Rodriguez):

Having a single chip itself yields a lot more benefits than that.  Since
things are closer together it also means less complexity on overall
programming.

I recommend the single chip families, and specificaly AR9280 is a great
candidate as its dual band and uses PCI-E.  From a software perspective
Atheros dedicates more of its own resources for testing our newer chipsets,
the newer gernation 802.11n chipsets.  AR9001 didn't get formal testing
but the AR9002 did.  Now its AR9002, in the near future it will be AR9003
and so on.

./danfe

[1] http://ath9k-devel.ath9k.narkive.com/GqjxAbUB/ar-chipset-differences
___
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"


Intel Pro/Wireless 2200BG iwi(4) card stopped working in 8-stable

2012-10-05 Thread Alexey Dokuchaev
Hello,

Since yesterday, Intel 2200BG wifi card in my laptop stopped working all
of sudden.  Reboots and usual dances with driver (iwi(4)) did not help.
Attached is relevant parts of dmesg(8) with debug.iwi=5 (also downloadable
from http://193.124.210.26/iwi.dmesg).  Basically, once I try to configure
it, I will see "iwi0: firmware error" on the console.  I did not do
anything with the kernel or the base.  Any ideas on how to fix it?

Since this card gave me lots of troubles over the past, any one can
recommend a decent mini-pci replacement?  It looks like ath(4) chips are
currently best supported.  I am thinking of something AR9223-based, which
should provide me with better experience and give 802.11n support as a
nice bonus.  Opinions?

Thanks,

./danfe
iwi_newstate: SCAN -> INIT flags 0x1
enter LOADING state
exit LOADING state
Setting MAC address to 00:16:6f:b2:61:51
sending command idx=0 type=11 len=6
Configuring adapter
sending command idx=1 type=6 len=20
Setting .11bg supported rates (12)
sending command idx=2 type=22 len=16
Setting .11a supported rates (8)
sending command idx=3 type=22 len=16
Setting initialization vector to 4054530237
sending command idx=4 type=34 len=4
Enabling adapter
sending command idx=5 type=2 len=0
iwi_newstate: INIT -> SCAN flags 0x1
enter SCANNING state
Scan request: index 7 dwell 200/200/200
Scan 1 2.4GHz channels: 1/BCAST
sending command idx=6 type=26 len=96
Notification (20)
received frame len=139 chan=1 rssi=24 rssi_dbm=62
received frame len=226 chan=1 rssi=21 rssi_dbm=53
received frame len=226 chan=1 rssi=21 rssi_dbm=53
received frame len=349 chan=1 rssi=23 rssi_dbm=47
received frame len=145 chan=1 rssi=26 rssi_dbm=62
received frame len=129 chan=1 rssi=20 rssi_dbm=52
received frame len=349 chan=1 rssi=22 rssi_dbm=45
received frame len=145 chan=1 rssi=26 rssi_dbm=62
Scan of channel 2412 complete (1)
Scan completed (1, 1)
exit SCANNING state
enter SCANNING state
Scan request: index 8 dwell 200/200/200
Scan 1 2.4GHz channels: 6/BCAST
sending command idx=7 type=26 len=96
iwi0: firmware error
sending command idx=8 type=23 len=0
iwi0: firmware error
enter LOADING state
exit LOADING state
Setting MAC address to 00:16:6f:b2:61:51
sending command idx=0 type=11 len=6
Configuring adapter
sending command idx=1 type=6 len=20
Setting .11bg supported rates (12)
sending command idx=2 type=22 len=16
Setting .11a supported rates (8)
sending command idx=3 type=22 len=16
Setting initialization vector to 1453468842
sending command idx=4 type=34 len=4
Enabling adapter
sending command idx=5 type=2 len=0
Notification (20)
Notification (15)
Notification (15)
___
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"