On 9/26/18 3:54 AM, Simon Beginn wrote:
>>
>> The convention has long been to use rnnnnxx for the Realtek drivers in
>> staging, and rtlnnnnxx when they are moved to the regular wireless tree. If
>> you want it renamed, then you need to do the work to get the driver into the
>> condition necessary for it to be in the regular tree.
> I'll see what I can do...
>
>> Module parameter ant_sel for rtl8723be and rtl8723de was created because some
>> vendors saved a few pennies by only supplying one antenna. The problem is that
>> they encoded the WRONG value into the EFUSE, thus code that uses that setting
>> (Linux) essentially has no antenna attached. The simple measure of opening the
>> case and moving the antenna to the other connector was not viable for warranty
>> conditions. In addition, it broke the Windows driver. Do you have a case where
>> there is a single antenna for the rtl8723bs, and the PROM shows the wrong
>> value? If not, then any antenna number option is not needed.
> Hmm. I cant answer this for sure. The symptoms on my tablet are that the wifi
> chip works OK using Windows (10) and is slow as **** under Linux. Under Linux
> the system also didn't connect directly to my router (or any other of its
> guest-networks) and prefers a far away adapter - which are all spread over my
> house. And I think the chip does select the wrong antenna, because my router
> (which the tablet doesn't like) discard all connection attempts if they are too
> weak. The, as mentioned before, other adapters doesn't have such a feature AND
> the wifi works only well if I stand directly beside the "i-take-everything"
> adapters. To make this analysis stand on something: How can I read the PROM
> values? The tablets BIOS is not the key - it only provides the EFI selection.
This driver is not reading any PROM data. It sets the antenna to 1 unless it is
overridden by the rtw_ant_num option. We need to use signal strengths to decide
if using ant_num 2 would be better. Use the following command to get the
baseline values:
sudo iw dev wlan0 scan | egrep "SSID|signal"
Change the wlan0 to the actual device name on your system.
Next, do the command sequence
sudo modprobe -rv r8723bs
sudo modprobe -v r8723bs rtw_ant_num=2
Then repeat the iw command.
If the second set of signals is something like 30 dBm greater, then prepare an
options file to force antenna #2. Post all the scan data for the AP you want to use.
Larry
> Use the following command to get the baseline values:
Done - aand nothing changes (The access point has a strength of -60dB on
my desk). Well maybe the manufacturer has two antennas builtin. Yay -
sorry for that.
> In dmesg
Yep, too late. I've already installed the necessary firmware-files. But
I didn't wrote it, because the WiFi test wasn't performed until yet.
> o the work to get the driver into the condition necessary for it to be
> in the regular tree.
Did my patch made it?
Best regards,
Simon
On 9/27/18 3:33 AM, Simon Beginn wrote:
>> Use the following command to get the baseline values:
> Done - aand nothing changes (The access point has a strength of -60dB on my
> desk). Well maybe the manufacturer has two antennas builtin. Yay - sorry for that.
That value means that the signal strength is way too low. One other possibility
is that the chip has retained the setting and is not obeying the antenna number
command. To check that, create a file (as root) named
/etc/modprobe.d/50-r8723bs.conf, and add a single line containing "options
r8723bs rtw_ant_num=2" (without the quotation marks). After that file is ready,
then do a cold boot so that the chip has been power cycled. Finally, redo the
signal test. Note: If your patch is applied, the above will not work!
>
>> In dmesg
> Yep, too late. I've already installed the necessary firmware-files. But I didn't
> wrote it, because the WiFi test wasn't performed until yet.
>
>
>> o the work to get the driver into the condition necessary for it to be in the
>> regular tree.
> Did my patch made it?
Your patch was not in the correct format to be accepted. Even if it had been
correctly done, I would have NACKed it. Given the location of the driver, the
name is what it should be. Once you, or someone else, has done the many hours to
put that Realtek crap into proper kernel form, then it could be placed in the
normal wireless tree and given the name rtl8723bs.
Larry
> That value means that the signal strength is way too low. One other
> possibility is that the chip has retained the setting and is not
> obeying the antenna number command. To check that, create a file (as
> root) named /etc/modprobe.d/50-r8723bs.conf, and add a single line
> containing "options r8723bs rtw_ant_num=2" (without the quotation
> marks). After that file is ready, then do a cold boot so that the chip
> has been power cycled. Finally, redo the signal test. Note: If your
> patch is applied, the above will not work!
I've applied my patch and got the following results (btw good idea with
the cold boot!):
***FILE CREATED***
options rtl8723bs rtw_ant_num=1
***POWEROFF + 2 MINUTES WAITING***
***REBOOT + COMMAND***
sudo iw dev wlan0 scan | egrep "SSID|signal"
-> Desk
signal: -93.00 dBm
SSID: Gonzales
signal: -63.00 dBm
SSID: Gonzales
signal: -63.00 dBm
SSID: Gonzales
signal: -50.00 dBm
SSID: TPC_Install
-> Place A
signal: -93.00 dBm
SSID: Gonzales
signal: -45.00 dBm
SSID: Gonzales
signal: -62.00 dBm
SSID: Gonzales
signal: -64.00 dBm
SSID: TPC_Install
***FILE MODIFIED***
options rtl8723bs rtw_ant_num=2
***POWEROFF + 2 MINUTES WAITING***
***REBOOT + COMMAND***
sudo iw dev wlan0 scan | egrep "SSID|signal"
-> Desk
signal: -85.00 dBm
SSID: Gonzales
signal: -64.00 dBm
SSID: Gonzales
signal: -65.00 dBm
SSID: Gonzales
signal: -48.00 dBm
SSID: Gonzales
signal: -48.00 dBm
SSID: TPC_Install
-> Place A
signal: -79.00 dBm
SSID: Gonzales
signal: -45.00 dBm
SSID: Gonzales
signal: -63.00 dBm
SSID: Gonzales
signal: -63.00 dBm
SSID: TPC_Install
> ccepted. Even if it had been correctly done, I would have NACKed it.
Sry, would you reformulate this, please? I just can't
understand/determine what the word "NACKed" means in this situation
(Neither google or the raw translation helps me).
Thank you,
Simon
On 09/27/2018 05:21 PM, Larry Finger wrote:
> On 9/27/18 3:33 AM, Simon Beginn wrote:
>>> Use the following command to get the baseline values:
>> Done - aand nothing changes (The access point has a strength of -60dB
>> on my desk). Well maybe the manufacturer has two antennas builtin.
>> Yay - sorry for that.
>
> That value means that the signal strength is way too low. One other
> possibility is that the chip has retained the setting and is not
> obeying the antenna number command. To check that, create a file (as
> root) named /etc/modprobe.d/50-r8723bs.conf, and add a single line
> containing "options r8723bs rtw_ant_num=2" (without the quotation
> marks). After that file is ready, then do a cold boot so that the chip
> has been power cycled. Finally, redo the signal test. Note: If your
> patch is applied, the above will not work!
>
>>
>>> In dmesg
>> Yep, too late. I've already installed the necessary firmware-files.
>> But I didn't wrote it, because the WiFi test wasn't performed until yet.
>>
>>
>>> o the work to get the driver into the condition necessary for it to
>>> be in the regular tree.
>> Did my patch made it?
>
> Your patch was not in the correct format to be accepted. Even if it
> had been correctly done, I would have NACKed it. Given the location of
> the driver, the name is what it should be. Once you, or someone else,
> has done the many hours to put that Realtek crap into proper kernel
> form, then it could be placed in the normal wireless tree and given
> the name rtl8723bs.
>
> Larry
On Fri, 2018-09-28 at 12:02 +0200, Simon Beginn wrote:
> >
<snip>
> > ccepted. Even if it had been correctly done, I would have NACKed
> > it.
>
> Sry, would you reformulate this, please? I just can't
> understand/determine what the word "NACKed" means in this situation
> (Neither google or the raw translation helps me).
Not ACKnowledged, in a word, refused.
On 9/28/18 5:02 AM, Simon Beginn wrote:
>> That value means that the signal strength is way too low. One other
>> possibility is that the chip has retained the setting and is not obeying the
>> antenna number command. To check that, create a file (as root) named
>> /etc/modprobe.d/50-r8723bs.conf, and add a single line containing "options
>> r8723bs rtw_ant_num=2" (without the quotation marks). After that file is
>> ready, then do a cold boot so that the chip has been power cycled. Finally,
>> redo the signal test. Note: If your patch is applied, the above will not work!
> I've applied my patch and got the following results (btw good idea with the cold
> boot!):
>
> ***FILE CREATED***
> options rtl8723bs rtw_ant_num=1
>
> ***POWEROFF + 2 MINUTES WAITING***
>
> ***REBOOT + COMMAND***
> sudo iw dev wlan0 scan | egrep "SSID|signal"
> -> Desk
> signal: -93.00 dBm
> SSID: Gonzales
> signal: -63.00 dBm
> SSID: Gonzales
> signal: -63.00 dBm
> SSID: Gonzales
> signal: -50.00 dBm
> SSID: TPC_Install
> -> Place A
> signal: -93.00 dBm
> SSID: Gonzales
> signal: -45.00 dBm
> SSID: Gonzales
> signal: -62.00 dBm
> SSID: Gonzales
> signal: -64.00 dBm
> SSID: TPC_Install
>
> ***FILE MODIFIED***
> options rtl8723bs rtw_ant_num=2
>
> ***POWEROFF + 2 MINUTES WAITING***
>
> ***REBOOT + COMMAND***
> sudo iw dev wlan0 scan | egrep "SSID|signal"
> -> Desk
> signal: -85.00 dBm
> SSID: Gonzales
> signal: -64.00 dBm
> SSID: Gonzales
> signal: -65.00 dBm
> SSID: Gonzales
> signal: -48.00 dBm
> SSID: Gonzales
> signal: -48.00 dBm
> SSID: TPC_Install
> -> Place A
> signal: -79.00 dBm
> SSID: Gonzales
> signal: -45.00 dBm
> SSID: Gonzales
> signal: -63.00 dBm
> SSID: Gonzales
> signal: -63.00 dBm
> SSID: TPC_Install
>
>> ccepted. Even if it had been correctly done, I would have NACKed it.
> Sry, would you reformulate this, please? I just can't understand/determine what
> the word "NACKed" means in this situation (Neither google or the raw translation
> helps me).
>
I do not think that changing rtw_ant_num made any difference. In each location,
both tests had one AP with a signal greater than -50, which should be strong
enough. We do not know if the driver is roaming correctly. At each location, is
that AP with the strongest signal actually the one that is selected? To see
that, change the scan command to
sudo iw dev wlan0 scan | egrep "associated|SSID|signal"
Check the output to see if the AP with the strongest signal is preceded by a BSS
line.
Sorry about using jargon that you could not run through a translator. As Bastien
explained, NACK means to reject a patch. You accept a patch by providing an
"ACKed-by: name <email address>" line. Thus NACK is the opposite.
Larry