rtl8723au_bt
rtl8723au_bt copied to clipboard
lwfinger
bt stops working with 3.13.0
This worked well before 3.13.0 now it doesn't work. Would like to see it fixed. I will submit any info you request.
email: imese -at- bellsouth .net
Thanks Gene
I do not have a device. If the problem is building the driver, send the actual error in the build. If it builds and installs OK, you will need to bisect the kernel to discover the bad commit.
I can confirm this. The driver installs fine without any errors but Bluetooth is still disabled according to gnome-bluetooth and hcitool doesn't find any devices :(
I'm running Arch Linux on a Lenovo Ideapad Yoga 13 which has this chip inside. The WiFi driver from your git still works fine (the Yoga 13 has both the network card and bt chip from rtl8723au).
(oh btw, no blocks and systemctl started the bluetooth service just fine) [vistaus@yoga13 ]$ rfkill list 0: ideapad_wlan: Wireless LAN Soft blocked: no Hard blocked: no 1: ideapad_bluetooth: Bluetooth Soft blocked: no Hard blocked: no 3: hci0: Bluetooth Soft blocked: no Hard blocked: no [vistaus@yoga13 ]$
As I have explained numerous times, I cannot help debug this issue as I do not have the hardware.
As the BT driver has not been changed, I suspect some change in the kernel has triggered a bug. A big help in finding it would be to obtain a git repo of the kernel sources and bisect between 3.13.0 (bad), and a previous good version (3.12.0?).
But I'm no kernel developer nor experienced programmer so I doubt I can find what's wrong... In the meantime, I've bought a bluetooth adapter that works OOTB so for now my issue is solved, at least with a workaround. Would be lovely to get this driver working though...
You can do what you want, but how hard would it be to do the bisection? The steps are:
- Get the source with "git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
- cd linux
- Copy your default kernel configuration to .config. As I do not use Ubuntu, I cannot give you the specifics.
- git bisect start ; git bisect bad ; git bisect good v3.12
- Build that kernel. On debian-based systems, I think you need to use "fakeroot mkpkg ...".
- Install the new test kernel, reboot and test.
- If good, "git bisect good". If not "git bisect bad". Repeat steps 5 and 6.
I said I'm using ARCH Linux, not Ubuntu. And you're coming off a bit harsh IMHO... I'd love to help you debug but please be a little less harsh.
root@go:/usr/src/linux# git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [e1a26170692dc1e5fbe0ccd98ef86cc9fcd31a64] Bluetooth: Provide hdev parameter to hci_recv_frame() driver callback
Thanks for the bisection. Unfortunately, nothing jumped off the page regarding that change affecting rtl8723au_bt.
When the driver fails, is anything logged in dmesg?
All I got. Nothing in logs.
root@go:~# dmesg | grep blue [ 3.282836] Bluetooth: Core ver 2.17 [ 3.286733] Bluetooth: HCI device and connection manager initialized [ 3.289247] Bluetooth: HCI socket layer initialized [ 3.291046] Bluetooth: L2CAP socket layer initialized [ 3.296076] Bluetooth: SCO socket layer initialized [ 3.316973] rtk_btusb: Realtek Bluetooth USB driver ver 0.8 [ 3.572038] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 3.574253] Bluetooth: BNEP filters: protocol multicast [ 3.578118] Bluetooth: BNEP socket layer initialized [ 4.152792] Bluetooth: hci0 sending frame failed root@go:~# dmesg|grep rtk [ 3.316973] rtk_btusb: Realtek Bluetooth USB driver ver 0.8 [ 3.446882] rtk_btusb: btusb_probe 1==========can_wakeup=1 flag2=0 [ 3.449186] rtk_btusb: wakeup_disable==========can_wakeup=1 flag2=0 [ 3.451496] rtk_btusb: patch_add [ 3.471437] usbcore: registered new interface driver rtk_btusb [ 3.475838] rtk_btusb: btusb_open start pm_usage_cnt(0x1) [ 3.478072] rtk_btusb: btusb_open hdev->promisc ==0 [ 3.480288] rtk_btusb: download_patch start [ 3.483386] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x1200 [ 3.483387] rtk_btusb: load_firmware [ 4.152406] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x342e [ 4.152515] rtk_btusb: Rtk patch end 0 [ 4.152594] rtk_btusb: btusb_open end pm_usage_cnt(0x0) [ 14.152081] rtk_btusb: btusb_flush add delay [ 14.162160] rtk_btusb: btusb_close
Those logs do not provide much info other than "hci0 sending frame failed". The commit that broke the driver only seems to affect hci_get_frame() and the driver does not use it.
Realtek had sent me a newer version recently. I have created a branch named "new" in the repo. Do a pull and "git checkout -b new --track origin/new". Does that help? BTW, this version will not build on kernels older than 3.13.
lwfinger I hate to be such a dope but 'git checkout -b new --track origin/new' gives: root@go:/usr/src# git checkout -b new --track origin/new fatal: Not a git repository (or any of the parent directories): .git
Can you give some help on what the actual command should be?
Thanks, Gene
git checkout -b new --track origin/new works for me. It appears that you were not in the directory that has the repository when you issued the command.
In addition, it is not usually wise to do this kind of stuff when you are root. Not only do you run the risk of filling the / partition and making your system unbootable, but a runaway or buggy Makefile can do real damage. At one point in the past, building the kernel as root caused /dev/null to be deleted. Once that happened, all manner of bad things happened. When a particular command needs privilege, use "sudo".
Sorry to be so dense. Do not use the tools enough to know what I am doing.
Thanks for the tips about root. Gene
Finally tried new git checkout. Caused a kernel panic on kernel 3.13.5 during bootup.
What else?
Hi @lwfinger
I just installed Ubuntu 14.04 beta 2 with 3.13 kernel. I can confirm that the master driver doesn't load and the 'new' branch causes an oops.
Here's the dmesg output from the master branch...
[ 2.561894] rtk_btusb: Realtek Bluetooth USB driver ver 0.8
[ 2.703624] rtk_btusb: btusb_probe 1==========can_wakeup=1 flag2=0
[ 2.703625] rtk_btusb: wakeup_disable==========can_wakeup=1 flag2=0
[ 2.703626] rtk_btusb: patch_add
[ 2.704058] rtk_btusb: btusb_open start pm_usage_cnt(0x1)
[ 2.704059] rtk_btusb: btusb_open hdev->promisc ==0
[ 2.704059] rtk_btusb: download_patch start
[ 2.704066] usbcore: registered new interface driver rtk_btusb
[ 2.704909] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x1200
[ 2.704910] rtk_btusb: load_firmware
[ 3.375668] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x342e
[ 3.375673] rtk_btusb: Rtk patch end 0
[ 3.375684] rtk_btusb: btusb_open end pm_usage_cnt(0x0)
[ 13.385764] rtk_btusb: btusb_flush add delay
[ 13.395704] rtk_btusb: btusb_close
Here's the kernel oops form the new branch...
Looks like the problem arises from btusb_tx_complete(.)
I note there is the following difference between new and master...
master:
struct btusb_data *data = GET_DRV_DATA(hdev);
new:
struct btusb_data *data = hci_get_drvdata(hdev);
May perhaps be that hci_get_drvdata is not returning a valid handle, causing the kernel to throw some sort of memory access violation.
Cheers Andrew
I can confirm this, too. The module built from master branch works fine with mainline 3.12.17 but not with 3.13.0, tested using the "generic" amd64 kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/.
dmesg on 3.13.0 (broken):
[ 21.298641] Bluetooth: Core ver 2.17
[ 21.298936] Bluetooth: HCI device and connection manager initialized
[ 21.298942] Bluetooth: HCI socket layer initialized
[ 21.298945] Bluetooth: L2CAP socket layer initialized
[ 21.298949] Bluetooth: SCO socket layer initialized
[ 21.305570] rtk_btusb: Realtek Bluetooth USB driver ver 0.8
[ 21.657000] rtk_btusb: btusb_probe 1==========can_wakeup=1 flag2=0
[ 21.657004] rtk_btusb: wakeup_disable==========can_wakeup=1 flag2=0
[ 21.657005] rtk_btusb: patch_add
[ 21.672617] rtk_btusb: btusb_open start pm_usage_cnt(0x1)
[ 21.672619] rtk_btusb: btusb_open hdev->promisc ==0
[ 21.672621] rtk_btusb: download_patch start
[ 21.672634] usbcore: registered new interface driver rtk_btusb
[ 21.673411] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x1200
[ 21.673414] rtk_btusb: load_firmware
[ 21.706182] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 21.706186] Bluetooth: BNEP filters: protocol multicast
[ 21.706196] Bluetooth: BNEP socket layer initialized
[ 21.758090] Bluetooth: RFCOMM TTY layer initialized
[ 21.758102] Bluetooth: RFCOMM socket layer initialized
[ 21.758107] Bluetooth: RFCOMM ver 1.11
[ 22.345177] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x342e
[ 22.345182] rtk_btusb: Rtk patch end 0
[ 22.345193] rtk_btusb: btusb_open end pm_usage_cnt(0x0)
[ 22.345772] Bluetooth: hci0 sending frame failed
[ 32.354287] rtk_btusb: btusb_flush add delay
[ 32.364230] rtk_btusb: btusb_close
dmesg on 3.12.17 (works):
[ 8.825633] Bluetooth: Core ver 2.16
[ 8.825656] Bluetooth: HCI device and connection manager initialized
[ 8.825663] Bluetooth: HCI socket layer initialized
[ 8.825665] Bluetooth: L2CAP socket layer initialized
[ 8.825677] Bluetooth: SCO socket layer initialized
[ 8.826999] rtk_btusb: Realtek Bluetooth USB driver ver 0.8
[ 8.827020] rtk_btusb: btusb_probe 1==========can_wakeup=1 flag2=0
[ 8.827022] rtk_btusb: wakeup_disable==========can_wakeup=1 flag2=0
[ 8.827023] rtk_btusb: patch_add
[ 8.827175] rtk_btusb: btusb_open start pm_usage_cnt(0x1)
[ 8.827176] rtk_btusb: btusb_open hdev->promisc ==0
[ 8.827178] rtk_btusb: download_patch start
[ 8.827274] usbcore: registered new interface driver rtk_btusb
[ 8.828111] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x1200
[ 8.828113] rtk_btusb: load_firmware
[ 9.075591] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 9.075594] Bluetooth: BNEP filters: protocol multicast
[ 9.075603] Bluetooth: BNEP socket layer initialized
[ 9.121778] Bluetooth: RFCOMM TTY layer initialized
[ 9.121792] Bluetooth: RFCOMM socket layer initialized
[ 9.121794] Bluetooth: RFCOMM ver 1.11
[ 9.510890] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x342e
[ 9.510896] rtk_btusb: Rtk patch end 0
[ 9.510906] rtk_btusb: btusb_open end pm_usage_cnt(0x0)
[ 9.543930] rtk_btusb: btusb_notify : hci0 evt 3
[ 14.748929] rtk_btusb: btusb_notify : hci0 evt 1
[ 15.130720] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 15.130729] Bluetooth: HIDP socket layer initialized
[ 15.132807] input: ThinkPad Bluetooth Laser Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:1/input13
[ 15.132949] hid-generic 0005:17EF:6038.0003: input,hidraw1: BLUETOOTH HID v2.00 Mouse [ThinkPad Bluetooth Laser Mouse] on 2c:d0:5a:b8:4e:dc
The module built from "new" branch causes panics on both kernels.
Guido
With regard to the master branch and 3.13, I found this in /var/log/kernel.log
Apr 12 14:20:40 ideapad-yoga13 kernel: [10503.724772] rtk_btusb 1-1.4:1.1: no reset_resume for driver rtk_btusb?
Perhaps the issue may be related to: https://lkml.org/lkml/2011/2/23/536
Although, adding usbcore.autosuspend=-1 to kernel args doesn't help. So maybe not!
That issue is for kernel 2.6.38 and is from 2011. I doubt that it is the problem.
I have no possibility of debugging anything regarding this on my own.
As it seems that the breakage happened sometime between 3.12 and 3.13, one of you with this problem needs to clone the mainline linux git repo and bisect between v3.13 (bad) and v3.12 (good). That will probably take 1-2 days, depending on the speed of your processor, and should tell us which kernel change is bad.
I will see what I can do about the oops and report back.
@lwfinger I'm already working on the bisect, will get back to you when finished.
Ok bisect finished. Actually, the commit @imesg mentioned was still ok for me, it was the following one that broke things:
[03:21:59] gsn@maragor:~/kernel/linux-stable$ git bisect good
7bd8f09f69f8a190f9b8334a07bb0a9237612314 is the first bad commit
commit 7bd8f09f69f8a190f9b8334a07bb0a9237612314
Author: Marcel Holtmann <[email protected]>
Date: Fri Oct 11 06:19:18 2013 -0700
Bluetooth: Add hdev parameter to hdev->send driver callback
Instead of masking hdev inside the skb->dev parameter, hand it
directly to the driver as a parameter to hdev->send. This makes
the driver interface more clear and simpler.
This patch fixes all drivers to accept and handle the new parameter
of hdev->send callback. Special care has been taken for bpa10x
and btusb drivers that require having skb->dev set to hdev for
the URB transmit complete handlers.
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
:040000 040000 3731791e3071b15c9b1e962c4db6596361d01388 27029e245f476dac4d639b7017872b31bbbb83f5 M drivers
:040000 040000 ef3ece7f45fc330a7e10d36611c9dd378b8ec242 34117f18ec4f139f744b68f5e158f569af10bcc1 M include
:040000 040000 69cf1d43a6cdf101edeed2031f30fd36d4d98d3d ab2ca4a4a4772d1e511035cd6e792aa382a04b92 M net
Just applied the changes made to drivers/bluetooth/btusb.c in this commit to rtk_btusb.c and that did the trick for me, working fine with 3.13.0 (mainline and current ubuntu 14.04 generic kernel) now.
New driver caused Kernel panic to my Ideapad yoga13. After causing that, I installed ubuntu14.10 and installed bluetooth driver but kernel panic happened again. Is there any idea to remove this bug?
Loading the module from the master branch causes a kernel panic on my lenovo yoga 13 laptop with kernel 3.13.0, too.
Value for skb-dev is forgotten to set. My prototype works well on Ubuntu14.04.
@lwfinger I sent pull request. Please check it.
The @asukiaaa patch prevents the crash on my system.
dmesg shows:
[ 6.381363] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x342e
[ 6.381365] rtk_btusb: Rtk patch end 0
[ 6.381373] rtk_btusb: btusb_open end pm_usage_cnt(0x0)
[ 6.414362] rtk_btusb: btusb_notify : hci0 evt 3
[ 6.439385] rtk_btusb: btusb_flush add delay
[ 6.449305] rtk_btusb: btusb_close
but the bluetooth device list is still empty
$ sudo hcitool dev
Devices:
$
@donpdonp Did you reboot your system? I also could not find the device after install this driver before reboot.
@asukiaaa I'm trying to use the new branch to make 13d3:3410 from rtl8723be bluetooth work.
I've cherrypicked your commit from the master branch to the new branch but it's still does not work.
I've contacted realtek to know if they want to support officially the 3.13 kernel for those cards.
Basically the firmware loads fine, but scanning using hcitool does not return anything.
Thanks for your help.
What patch did you cherry pick?
Does the output of dmesg show anything?
It would be most helpful if you were to install a git tree for the kernel source, and bisect to find what commit in that tree breaks BT. Otherwise, we are just blindly trying to find the problem.
@lwfinger : thanks for your answer.
i've cherrypicked 3ef437c9c43f3d84ef800ccf10ddd95237e2bdd7 " set value of skb->dev for kernel version 3.13.0" which is on Master and not on new , I thought this could explain why the new branch still doesn't work on 3.13
Yes I could bisect but people on this issue seems to tell that it works on 3.13 but maybe only with the rtl8723au BT part ? what is the pid/vid of the BT part of rtl8723au ?
I have some RTL8723BE Minipcie cards that I could send to a developer willing to investigate the issue. I could even raise some money on this problem as it's a blocking issue for our business right now.
I will also try to bisect tomorrow to find the faulty commit.
Good new. I've applied the patch from daniel (http://marc.info/?l=linux-bluetooth&m=140421888920289&w=2) and applied manually on linux 3.13 sources and it worked directly with RT8723BE with firmware loaded.
So there is something different between the "new" branch and his patch.