Page MenuHomeFreeBSD

rtwn: Fix RTL8188EU and RTL8192EU cannot associate in STA mode
Needs ReviewPublic

Authored by cy on Mar 2 2023, 5:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 10, 5:08 PM
Unknown Object (File)
Sun, Oct 20, 4:58 AM
Unknown Object (File)
Oct 9 2024, 3:29 AM
Unknown Object (File)
Oct 9 2024, 3:29 AM
Unknown Object (File)
Oct 9 2024, 3:28 AM
Unknown Object (File)
Oct 9 2024, 3:28 AM
Unknown Object (File)
Oct 9 2024, 2:58 AM
Unknown Object (File)
Oct 4 2024, 6:32 AM
Subscribers

Details

Reviewers
imp
jhb
bz
arved
adrian
Group Reviewers
Src Committers
wireless
Summary

On some systems RTL8188EU and RTL8192EU will fail to associate in STA mode while
others it will work fine. On the systems RTL8188EU and RTL8192EU fails to associate
in STA mode, it works perfectly fine in AP mode. This points to a USB
timing issue when selecting a channel while in STA mode.

While here fix RTL8192EU power off and power on hang for the same reason.

Test Plan

Tested locally and in PR/247528.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

cy requested review of this revision.EditedMar 2 2023, 5:37 PM
cy updated this revision to Diff 118179.
cy created this revision.

Add similar fix for RTL8188EU as reported by rkoberman@gmail.com also in PR/247528. My 8188EU never experienced this problem so testing whether this fixes the problem or not must be confirmed by the person reporting it.

This would be a separate commit.

i understand the fix, but the whole code layout for rtwn is to avoid the HW code knowing too much about the bus/transport.

Honestly, I think we should move the delay stuff into the normal rtwn_softc and use it there, and only configure it for usb. That way the chipset HW code doesn't need to include the USB specific bits.

i understand the fix, but the whole code layout for rtwn is to avoid the HW code knowing too much about the bus/transport.

Honestly, I think we should move the delay stuff into the normal rtwn_softc and use it there, and only configure it for usb. That way the chipset HW code doesn't need to include the USB specific bits.

Thanks. I'll rework the patch and either update this revision or abandon it and open a new one instead.

With the patch I get an instant reboot (no coredump), so something is fishy. Sorry for not having much more information.

panic: _mtx_lock_sleep: recursed on non-recursive mutex rtwn0 @ /usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c:87

#6 0xffffffff80bd01a3 in panic (fmt=<unavailable>)

at /usr/src/sys/kern/kern_shutdown.c:907

#7 0xffffffff80baae8d in __mtx_lock_sleep (c=c@entry=0xfffffe00d8789018,

v=18446741878244833056, opts=opts@entry=0, 
file=file@entry=0xffffffff82aa8a54 "/usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c", line=line@entry=87) at /usr/src/sys/kern/kern_mutex.c:546

#8 0xffffffff80baa9d5 in __mtx_lock_flags (c=0xfffffe00d8789018, opts=0,

file=0xffffffff82aa8a54 "/usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c", line=87) at /usr/src/sys/kern/kern_mutex.c:284

#9 0xffffffff82aa4701 in r88eu_power_on (sc=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c:87

#10 0xffffffff82ac1739 in rtwn_init (sc=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/if_rtwn.c:1789

#11 rtwn_parent (ic=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/if_rtwn.c:1368

#12 0xffffffff80c3452a in taskqueue_run_locked (

queue=queue@entry=0xfffff8000896ba00)
at /usr/src/sys/kern/subr_taskqueue.c:514

panic: _mtx_lock_sleep: recursed on non-recursive mutex rtwn0 @ /usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c:87

#6 0xffffffff80bd01a3 in panic (fmt=<unavailable>)

at /usr/src/sys/kern/kern_shutdown.c:907

#7 0xffffffff80baae8d in __mtx_lock_sleep (c=c@entry=0xfffffe00d8789018,

v=18446741878244833056, opts=opts@entry=0, 
file=file@entry=0xffffffff82aa8a54 "/usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c", line=line@entry=87) at /usr/src/sys/kern/kern_mutex.c:546

#8 0xffffffff80baa9d5 in __mtx_lock_flags (c=0xfffffe00d8789018, opts=0,

file=0xffffffff82aa8a54 "/usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c", line=87) at /usr/src/sys/kern/kern_mutex.c:284

#9 0xffffffff82aa4701 in r88eu_power_on (sc=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/rtl8188e/usb/r88eu_init.c:87

#10 0xffffffff82ac1739 in rtwn_init (sc=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/if_rtwn.c:1789

#11 rtwn_parent (ic=0xfffffe00d8782000)

at /usr/src/sys/dev/rtwn/if_rtwn.c:1368

#12 0xffffffff80c3452a in taskqueue_run_locked (

queue=queue@entry=0xfffff8000896ba00)
at /usr/src/sys/kern/subr_taskqueue.c:514

Thanks. I'm taking adrian@'s advice to refactor, placing the added USB code into the bus portion of the code. The implementation will change. Thus it probably makes sense to abandon this revision and start a new revision when it's ready. As I'm working on other $JOB and FreeBSD things this week I'll start on this again next week.

cy retitled this revision from rtwn: Fix RTL8192EU cannot associate in STA mode to rtwn: Fix RTL8188EU and RTL8192EU cannot associate in STA mode.
cy edited the summary of this revision. (Show Details)

This is now two commits that:

rtwn: Fix RTL8192EU cannot associate in STA mode

On some systems RTL8192EU will fail to associate in STA mode while
others it will work fine. On the systems RTL8192EU fails to associate
in STA mode, it works perfectly fine in AP mode. This points to a USB
timing issue when selecting a channel while in STA mode.

While here fix RTL8192EU power off and power on hang for the same reason.

PR: 247528
Reported by: Mc James <realmcjames@protonmail.ch>, many

AND:

rtwn: Fix RTL8188EU cannot associate in STA mode

As with RTL8192EU a user reported that the RTL8188EU has identical
problems. Apply a similar fix to this chipset too.
others it will work fine. On the systems RTL8192EU fails to associate
in STA mode, it works perfectly fine in AP mode. This points to a USB
timing issue when selecting a channel while in STA mode.

PR: 247528
Reported by: rkoberman@gmail.co

The commits will be committed separately but are both listed here because they solve the same USB problem on two chipsets. Other chipsets, which I have here, do not have this problem.