Hi Ping-Ke, hi Bitterblue,
I have a problem with the rtl8xxxu driver and 8188f, but only on some boards.
More specifically, I can see that during the second channel switch (which
happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110
(ETIMEDOUT) and after that no reads or writes work anymore until I unload and
reload the driver.
The strange thing now is, that even though it seems to be hardware dependent the
vendor driver does not have this problem.
I tried to change the probe and start functions, so that they behaved exactly as
their vendor driver equivalents, but so far I don't see any improvement.
I was hoping, that one of you maybe has an idea, what could be causing such an
issue and how to avoid it.
Martin
On 11/06/2024 18:54, Martin Kaistra wrote:
> Hi Ping-Ke, hi Bitterblue,
>
> I have a problem with the rtl8xxxu driver and 8188f, but only on some boards. More specifically, I can see that during the second channel switch (which happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110 (ETIMEDOUT) and after that no reads or writes work anymore until I unload and reload the driver.
>
> The strange thing now is, that even though it seems to be hardware dependent the vendor driver does not have this problem.
>
> I tried to change the probe and start functions, so that they behaved exactly as their vendor driver equivalents, but so far I don't see any improvement.
>
> I was hoping, that one of you maybe has an idea, what could be causing such an issue and how to avoid it.
>
> Martin
Does it still die if you do a passive scan?
I wonder what vendor driver you are using? Is it loading the
same v4.0 firmware as rtl8xxxu?
Why reloading rtl8xxxu makes it work again? A USB reset?
Or something in the disconnect function?
To avoid the problem, obviously you have to make rtl8xxxu
even more like the vendor driver. :)
Martin Kaistra <[email protected]> wrote:
> Hi Ping-Ke, hi Bitterblue,
>
> I have a problem with the rtl8xxxu driver and 8188f, but only on some boards.
> More specifically, I can see that during the second channel switch (which
> happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110
> (ETIMEDOUT) and after that no reads or writes work anymore until I unload and
> reload the driver.
If this symptom is 100% reproducible, I would add many rtl8xxxu_read32(0xe08)
somewhere to bisect the cause resulting from writing IO or certain H2C commands.
Example 1:
rtl8xxxu_write32(0x1234) // original code
rtl8xxxu_read32(0xe08) // add this to see if problem encounters?
Example 2:
rtl8xxxu_gen2_h2c_cmd() // original code
mdelay(50) // add some delay to wait firmware complete the work
rtl8xxxu_read32(0xe08) // add this to see if problem encounters?
The address of 0xe08 is not always on, so you should read it after power-on.
Am 11.06.24 um 22:15 schrieb Bitterblue Smith:
> On 11/06/2024 18:54, Martin Kaistra wrote:
>> Hi Ping-Ke, hi Bitterblue,
>>
>> I have a problem with the rtl8xxxu driver and 8188f, but only on some boards. More specifically, I can see that during the second channel switch (which happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110 (ETIMEDOUT) and after that no reads or writes work anymore until I unload and reload the driver.
>>
>> The strange thing now is, that even though it seems to be hardware dependent the vendor driver does not have this problem.
>>
>> I tried to change the probe and start functions, so that they behaved exactly as their vendor driver equivalents, but so far I don't see any improvement.
>>
>> I was hoping, that one of you maybe has an idea, what could be causing such an issue and how to avoid it.
>>
>> Martin
>
> Does it still die if you do a passive scan?
no, the problem seems to appear after the first sent frame. So, if I don't send
any frames, the channel switching works fine.
>
> I wonder what vendor driver you are using? Is it loading the
> same v4.0 firmware as rtl8xxxu?
using the firmware from the vendor driver or the firmware from rtl8xxxu made no
difference.
>
> Why reloading rtl8xxxu makes it work again? A USB reset?
> Or something in the disconnect function?
>
> To avoid the problem, obviously you have to make rtl8xxxu
> even more like the vendor driver. :)
Am 12.06.24 um 03:47 schrieb Ping-Ke Shih:
> Martin Kaistra <[email protected]> wrote:
>> Hi Ping-Ke, hi Bitterblue,
>>
>> I have a problem with the rtl8xxxu driver and 8188f, but only on some boards.
>> More specifically, I can see that during the second channel switch (which
>> happens when I do "iw dev wlan0 scan"), the rtl8xxxu_read32(0e08) returns -110
>> (ETIMEDOUT) and after that no reads or writes work anymore until I unload and
>> reload the driver.
>
> If this symptom is 100% reproducible, I would add many rtl8xxxu_read32(0xe08)
> somewhere to bisect the cause resulting from writing IO or certain H2C commands.
Thanks to your suggestion, I found out that
1) the timeouts start occuring right after the first frame is sent (rtl8xxxu_tx)
2) the adress doesn't matter, rtl8xxxu_read8(0x100) also gets a timeout
I am now looking into the differences between vendor driver and rtl8xxxu for
sending frames.
>
> Example 1:
>
> rtl8xxxu_write32(0x1234) // original code
> rtl8xxxu_read32(0xe08) // add this to see if problem encounters?
>
> Example 2:
> rtl8xxxu_gen2_h2c_cmd() // original code
> mdelay(50) // add some delay to wait firmware complete the work
> rtl8xxxu_read32(0xe08) // add this to see if problem encounters?
>
> The address of 0xe08 is not always on, so you should read it after power-on.
>
>
>
>