ap17

This error has no relation, it has nothing to do with 8723bs driver. This means that the distributive you are using has an internal incorrectness. You probably forgot : Open the file ".../drivers/net/wireless/realtek/Kconfig" in a text editor, look at what it contains and add the line mentioned. Remember to select “Realtek Devices” in the menuconfig: make menuconfig -> device drivers-> network device support -> wireless LAN And after all, don't forget :

Dear Dysmas! You did not understand me at all. Have you ever built the Linux kernel yourself? Please try to find some article on how to build a Linux kernel somewhere on the Internet. Or ask someone to help you step by step. X1. install the tree on the Tinker Board - ??? 1. install armbian-config -- for what? 2. Install libncurses-dev -- required. 3. Log in as root -- required. 4. in armbian-config select Software / kernel headers -- what is it? 5. in armbian-config select Software / kernel source -- what is it? X2. what does the "full tree in linux-headers (etc.)" have to do with it ? I wish you good luck.

This source is not for android, it is for Linux. It seems to me that you are trying to build this driver in "out-of-tree" mode. This driver must be built in "in-tree" mode. 1. put driver sources to ".../drivers/net/wireless/realtek/rtl8723bs" 2. into file ".../drivers/net/wireless/realtek/Kconfig" insert line: source "/drivers/net/wireless/realtek/rtl8723bs/Kconfig" 3. into file ".../drivers/net/wireless/realtek/Makefile" insert line: obj-$(CONFIG_RTL8723BS) += rtl8723bs/ 4. do : make menuconfig -> device drivers-> network device support -> wireless LAN -> select 8723bs 5. by hand deselect 8723bs in ".../drivers/staging/Makefile" -- just comment out 8723bs line by #, driver 8723bs from staging does not work. 6. do make.

look at https://github.com/ap17/rtl8723bs

You are probably using bs driver version 4.3.x, but try version 5.2.17 - it works well with kernel versions up to 5.6.

Hi Igor, Hi Ant333! Due to the fact that I use a drivers with my own “patches” (essentially, I think they are the same as yours), the lines numbering and structures of files that you and I use are different. Therefore, I can not send a patch in the form of a patch file. The correction consists of insert of 1 line. In the kernel tree where the 8189fs (es/eu/au/?bs?) driver is located, in the file drivers/net/wireless/realtek/rtl8189fs/os_dep/linux/ioctl_cfg80211.c in the function “rtw_cfg80211_indicate_sta_assoc(…)” during filling of fields of structure “sinfo“ insert indicated line. . . . . . . void rtw_cfg80211_indicate_sta_assoc(_adapter *padapter, u8 *pmgmt_frame, uint frame_len) { s32 freq; int channel; struct wireless_dev *pwdev = padapter->rtw_wdev; struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv); struct net_device *ndev = padapter->pnetdev; #if defined(RTW_USE_CFG80211_STA_EVENT) || defined(COMPAT_KERNEL_RELEASE) { struct station_info sinfo; u8 ie_offset; if (GetFrameSubType(pmgmt_frame) == WIFI_ASSOCREQ) ie_offset = _ASOCREQ_IE_OFFSET_; else // WIFI_REASSOCREQ ie_offset = _REASOCREQ_IE_OFFSET_; . . . . . . sinfo.pertid = 0; // Somewhere here (before cfg80211_new_sta(…)) insert this line. sinfo.filled = 0; sinfo.assoc_req_ies = pmgmt_frame + WLAN_HDR_A3_LEN + ie_offset; sinfo.assoc_req_ies_len = frame_len - WLAN_HDR_A3_LEN - ie_offset; cfg80211_new_sta(ndev, GetAddr2Ptr(pmgmt_frame), &sinfo, GFP_ATOMIC); } . . . . . . Please let me know if this solves the problem. If you're interested, I can explain how the "error" occures.

Hi! I did not understand what you mean. I do not use OS Armbian and don't know what Armbian-5.70 is. But if we are talking about a problem found in the drivers RT 8189es, 8189fs, 8188eu, 8812au, then after applying the proposed patch, the mentioned drivers are used and work fine from 4.18 up to 5.0 on O.Pi. Zero (88eu), R1 (89es?fs), Lite (89es?fs), PC (eu, au), PC+ (89es?fs), Plus2e (fs). There is no time to check it on O.Pi Prime with its 8723bs. October 29, 2018 I sent the"patches" to user KKJ (vanilla 4.19 O.Pi Lite board) and he replies me that this solved his problem.

Has anyone had the following error when using kernel 4.18 and 19? 1. Start hostapd (with or without dhcpd) 2. Try connecting via WiFi 3. Result... ---------------------------------------------- Aug 01 15:06:24 P2E vmunix: [ 5553.586947] ------------[ cut here ]------------ Aug 01 15:06:24 P2E vmunix: [ 5553.591573] kernel BUG at mm/slub.c:3902! Aug 01 15:06:24 P2E vmunix: [ 5553.595577] Internal error: Oops - BUG: 0 [#1] SMP ARM Aug 01 15:06:24 P2E vmunix: [ 5553.600707] Modules linked in: cpufreq_userspace realtek sy8106a_regulator evdev dwmac_sun8i mdio_mux stmmac_platform stmmac i2c_mv64xxx sun8i_ths ptp 8189fs sunxi_wdt cfg80211 rfkill cpufreq_dt gpio_keys thermal_sys uio_pdrv_genirq uio ip_tables x_tables Aug 01 15:06:24 P2E vmunix: [ 5553.623305] CPU: 2 PID: 668 Comm: RTW_CMD_THREAD Not tainted 4.19.0-rc1-H23.a1 #1 Aug 01 15:06:24 P2E vmunix: [ 5553.630775] Hardware name: Allwinner sun8i Family Aug 01 15:06:24 P2E vmunix: [ 5553.635481] PC is at kfree+0xfc/0x140 Aug 01 15:06:24 P2E vmunix: [ 5553.639233] LR is at nl80211_send_station+0xb10/0xc80 [cfg80211] Aug 01 15:06:24 P2E vmunix: [ 5553.645229] pc : [<c0135f04>] lr : [<bf09710c>] psr: 40000013 Aug 01 15:06:24 P2E vmunix: [ 5553.651483] sp : ed193dc8 ip : 00000008 fp : ecfaa030 Aug 01 15:06:24 P2E vmunix: [ 5553.656697] r10: ecfaa168 r9 : 00000000 r8 : ed193e50 Aug 01 15:06:24 P2E vmunix: [ 5553.661912] r7 : ed193de0 r6 : ecffd840 r5 : c082ae88 r4 : ecfaa014 Aug 01 15:06:24 P2E vmunix: [ 5553.668428] r3 : eee44b78 r2 : eee44b74 r1 : 00000024 r0 : c0135f40 Aug 01 15:06:24 P2E vmunix: [ 5553.674944] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Aug 01 15:06:24 P2E vmunix: [ 5553.682067] Control: 10c5387d Table: 6cda006a DAC: 00000051 Aug 01 15:06:24 P2E vmunix: [ 5553.687808] Process RTW_CMD_THREAD (pid: 668, stack limit = 0x68dce8d5) Aug 01 15:06:24 P2E vmunix: [ 5553.694410] Stack: (0xed193dc8 to 0xed194000) Aug 01 15:06:24 P2E vmunix: [ 5553.698763] 3dc0: 00000005 00000013 ecfaa014 c082ae88 00000012 ecfaa034 Aug 01 15:06:24 P2E vmunix: [ 5553.706929] 3de0: e598c000 e3a010c0 00000000 3085c00e 00000000 ee707800 00480020 ee7071a0 Aug 01 15:06:24 P2E vmunix: [ 5553.715094] 3e00: ed193e50 ecffd840 00000000 ed2efe8a f0db4108 bf09741c 00000000 ee707000 Aug 01 15:06:24 P2E vmunix: [ 5553.723260] 3e20: ee707800 ed2efe8a ed193e50 bf10b294 c082ae88 0000001c 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.731425] 3e40: f0db40f8 00080416 ed192000 bf11ac28 00000000 00000000 c082ae88 00060040 Aug 01 15:06:24 P2E vmunix: [ 5553.739590] 3e60: 00000002 01d40801 00000000 3085c00e 00000001 f0db3000 00000001 c082ae88 Aug 01 15:06:24 P2E vmunix: [ 5553.747754] 3e80: 00000007 bf0d79e0 00000001 bf13c8a4 ed192000 00000001 00210d00 00060040 Aug 01 15:06:24 P2E vmunix: [ 5553.755919] 3ea0: c082ae88 ed2f4180 ee472000 c082ae88 00000006 00000000 ed2efe9c 00000038 Aug 01 15:06:24 P2E vmunix: [ 5553.764084] 3ec0: 00000000 00000000 f0db4108 3085c00e f0e1d074 ee401d00 ed193ef8 00012785 Aug 01 15:06:24 P2E vmunix: [ 5553.772249] 3ee0: ed2efe80 f0db40f8 00080416 ed192000 f0db4108 c0135f40 00000001 bf0de80c Aug 01 15:06:24 P2E vmunix: [ 5553.780414] 3f00: f0db40f8 3085c00e f0e1d074 f0db3000 f0e1d074 00000054 ed2efe80 bf0de838 Aug 01 15:06:24 P2E vmunix: [ 5553.788579] 3f20: 00000058 ee5c7a00 f0db3000 bf173990 f0db40f8 bf0ed70c ecca40c0 f0db3000 Aug 01 15:06:24 P2E vmunix: [ 5553.796745] 3f40: f0db4118 f0db4000 f0db40f8 bf0ccbc4 ffffe000 bf0ed698 f0db4144 ee5c7a00 Aug 01 15:06:24 P2E vmunix: [ 5553.804910] 3f60: ffffe000 ed368b80 ece06980 00000000 ed192000 f0db3000 bf0cc8dc ed368b9c Aug 01 15:06:24 P2E vmunix: [ 5553.813075] 3f80: ed5cd864 c0045244 000000af ece06980 c0045124 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.821239] 3fa0: 00000000 00000000 00000000 c00090e8 00000000 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.829403] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.837569] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 Aug 01 15:06:24 P2E vmunix: [ 5553.845741] [<c0135f04>] (kfree) from [<3085c00e>] (0x3085c00e) Aug 01 15:06:24 P2E vmunix: [ 5553.851655] Code: 1a000003 e5923004 e3130001 1a000000 (e7f001f2) Aug 01 15:06:24 P2E vmunix: [ 5553.857742] ---[ end trace 964b2ab036abba84 ]--- ---------------------------------------------- I solved this problem and can share the result.

Thank you. I made a comparison of our works. They are almost identical. The same files have been fixed, not more, not less. But you did it more carefully.

I have a request to Igor. Dear Igor! The OS “19- Nov-2017 Testing image for Orange Pi R1 (4.13.14)” has the driver for 8189ETV (8189es.ko). As far as I understand, the mainlining of this driver was carried out by you personally. I ran this OS on my OPi-R1 only once, with the sole purpose of seeing how this driver identifies itself, nothing more. OK. In what my request consists: if it is possible, please, point me to or send me, maybe by e-mail, the sources of this your mainlined driver. Why do I need it? In mid-October, I completed my personal mainlining (4.14) of this driver (v4.3.18.1_15373.20151005) and now I’m using it for a month. On infrastructure and AP modes it works well (fine? – it will be seen in a month). But some aspects of this mainlining have been solved by me rather roughly, in my opinion. It’s technically interesting to me to see how you did it. Thank you in advance. By the way. Sorry for off-topic. Applying the same approaches to perform the mainlining … 1. … at the same time I have done my personal mainlining (4.14) of 8189FS driver (v4.3.24_15589.20151023) and now I’m using it on my OPi-P2E. The same words: on the above modes it works well, etc. It does not concern to mainlining, but doing it I found one nuance deep in 8189fs driver code, which causes a random assignment of the mac address, not affecting operation of the driver. The same code is present in 8723bs driver, but there it works correctly because of known features of this device. For 8189fs, this problem is still not solved, and I doubt that it can be solved at all with our knowledge of the details of the 8189fs device. 2. … a week ago I completed the mainlining of 8188EU driver (v4.3.0.6_12167.20140828) and now I’m using it on my OPi-PC. The same words again: it works well, etc. I also have mainlined (4.14) 8723bs drv. (v4.3.5.5_12290.20140916_BTCOEX20140507-4E40) for OPi-Prime and can share all my results.

DVFS works fine on a patched 4.12.0, but on OPi-Prime. If you need I may send patches.