rtl8xxxu maintains a pool of 32 RX URBs. Successful completions return
their URBs to a pending list and schedule the RX worker when more than
eight URBs are waiting. The worker allocates fresh receive buffers and
resubmits the queued URBs in a batch.

Completion errors free the affected URBs, reducing the pool. Once eight
or fewer survive, their completions can leave all remaining requests on
the pending list without reaching the worker scheduling threshold. If no
request is in flight and no worker is pending or running, nothing triggers
further submissions, so RX remains stalled after the errors stop.

Temporary submission failures can leave requests in the same state, while
retaining an skb that the next submission attempt overwrites.

This series fixes buffer ownership on failed submission, unwinds
incomplete startup, and preserves requests through one delayed retry path.
The retry worker schedules submission even for a single request. A
separate error list provides a 100 ms batch delay from the first error
while preserving normal successful RX batching. Shutdown drains retry
work, submission work and active requests in that order.

Completion retries cover EPROTO, EILSEQ, ETIME, EOVERFLOW, ECOMM and ENOSR;
ENOMEM/EAGAIN from startup or worker submission uses the same retry path.
Cancellation and removal keep their release behavior. EPIPE endpoint-halt
recovery is outside this series.

With 24 injected EPROTO completions, the original driver stopped at eight
pending requests and zero in flight for about 30 seconds. Under the same
error budget, the patched driver retained all 32 requests and resumed RX
without restarting the interface.

Validation:
- ARM64 QEMU KUnit: 11/11 cases passed, covering the actual RX helpers,
  worker, buffer ownership, startup failures and shutdown.
- RTL8192EU on Raspberry Pi, kernel 6.18.46-thesis-test-rt+: 13/13 cases
  passed using a compatibility backport. The lab fixture substitutes
  completion statuses and injects submission and allocation failures.
  Each of the six completion statuses recovered after 32 completion
  errors followed by 96 submission failures. Error-window, pending-retry
  stop, startup failure and clean RX/down-up cases also passed.
- W=1 ARM64 allmodconfig and allyesconfig builds passed with incremental
  caches; the changed driver and KUnit objects rebuilt in both.
  Sparse added no diagnostics relative to baseline.
- Each intermediate production commit compiled, and sequential patch
  application reproduced the corresponding source trees.

---
Changes in v2:
- Target the rtw-next branch of https://github.com/pkshih/rtw.git.
- Send the patches inline as plain text, without attachments.
- No code changes; the base commit is unchanged.
- Link to v1: https://lore.kernel.org/linux-wireless/CAH1Bc_yJ1e_nHk9tP2qP_4D8MHEve1R2EF5cYCEXRwc+1xVAxw@mail.gmail.com/

---
kimwooseok (4):
      wifi: rtl8xxxu: free RX skb when URB submission fails
      wifi: rtl8xxxu: unwind incomplete receive startup
      wifi: rtl8xxxu: preserve RX requests across recoverable transfer errors
      wifi: rtl8xxxu: test RX ownership and recovery across failures

 drivers/net/wireless/realtek/rtl8xxxu/.kunitconfig |  16 +
 drivers/net/wireless/realtek/rtl8xxxu/Kconfig      |  11 +
 drivers/net/wireless/realtek/rtl8xxxu/Makefile     |   3 +
 drivers/net/wireless/realtek/rtl8xxxu/core.c       | 236 ++++++++---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   |   3 +
 drivers/net/wireless/realtek/rtl8xxxu/rx-test.c    | 461 +++++++++++++++++++++
 drivers/net/wireless/realtek/rtl8xxxu/rx-test.h    |  27 ++
 7 files changed, 707 insertions(+), 50 deletions(-)
---
base-commit: f71dd599a98182d6bc34dce39977f928068ecd64
change-id: 20260913-codex-rtw-rx-v2-ffc2107308df

Best regards,
--  
kimwooseok <5mghybrid@khu.ac.kr>

kimwooseok via B4 Relay <devnull+5mghybrid.khu.ac.kr@kernel.org> wrote:
> - RTL8192EU on Raspberry Pi, kernel 6.18.46-thesis-test-rt+: 13/13 cases
>   passed using a compatibility backport. 

Forgot to ask what the 13/13 cases mean? The kunittest is 11 cases that
you will drop.

Hi Ping-Ke,

Here are the test conditions and results to help with the v3 review. I
have listed the 13 tests reported previously first, followed by the v3
results.

The tests used an RTL8192EU USB adapter on a Raspberry Pi. I adapted the
RX changes to the Pi's existing Linux 6.18.46 RT kernel so they could be
tested on the device.

For the recovery tests below, I checked that all 32 URBs were retained,
reception resumed without restarting the interface, and stop freed the
URBs. The RX completion counts are from after the injected errors ended.

1. clean-fixed-regression
   No faults: receive for 3 seconds, down/up, then receive for another 3
   seconds. PASS: 581 and 246 packets received, with no RX errors.

2. fixed-submit11-errno63-finite
   ENOSR completion errors x32 and EAGAIN submission failures x96. PASS:
   all faults were injected; RX then made 4,699 successful completions.

3. fixed-submit11-errno71-window
   EPROTO for 2 seconds (maximum 1,024), with up to 256 EAGAIN
   submission failures. PASS: 126 completion and 256 submission faults
   were injected; RX then made 5,227 successful completions.

4. fixed-submit11-errno75-finite
   EOVERFLOW completion errors x32 and EAGAIN submission failures x96.
   PASS: all faults were injected; RX then made 3,420 successful
   completions.

5. fixed-submit11-errno84-finite
   EILSEQ completion errors x32 and EAGAIN submission failures x96.
   PASS: all faults were injected; RX then made 4,243 successful
   completions.

6. fixed-submit12-errno62-finite
   ETIME completion errors x32 and ENOMEM submission failures x96. PASS:
   all faults were injected; RX then made 5,340 successful completions.

7. fixed-submit12-errno70-finite
   ECOMM completion errors x32 and ENOMEM submission failures x96. PASS:
   all faults were injected; RX then made 2,848 successful completions.

8. fixed-submit12-errno71-finite
   EPROTO completion errors x32 and ENOMEM submission failures x96.
   PASS: all faults were injected; RX then made 5,321 successful
   completions.

9. fixed-submit12-errno71-finite-control24
   EPROTO completion errors x24, with no submission faults. PASS: RX
   then made 4,921 successful completions.

10. fixed-submit12-errno71-finite-stop
   EPROTO budget 32 and ENOMEM budget 256; stop as soon as a retry is
   pending. PASS: stop saw two retry URBs after two completion faults
   and no submission faults; all RX URBs were released.

11. start-alloc8
   Fail the eighth RX URB allocation with ENOMEM. PASS: start returned
   failure and released its resources; the next start restored the pool
   and reception.

12. start-fatal8
   Fail the eighth RX submission with ENODEV. PASS: start returned
   failure and released its resources; the next start restored the pool
   and reception.

13. start-temporary
   Fail 64 RX submissions with ENOMEM beginning at startup. PASS: start
   succeeded, two delayed retry runs restored the pool and reception,
   and stop released the URBs.

V3 passed 52 tests: 42 from the main test plan, one matched-input
comparison, and nine first-start failure tests after a fresh module
load. Two interrupt-URB tests were not run because the RTL8192EU does
not use that path.

With the same 32-URB pool and 24 injected EPROTO completion errors, the
unpatched driver stalled with eight pending URBs and none in flight. V3
retained all 32 URBs and received 1,225 packets over 30 seconds without
restarting the interface.

Each of the nine first-start tests began before the driver had ever
started after probe. The first start failed and cleaned up; the next
start received packets normally.

Thanks,
Kim Wooseok

Kim Wooseok <5mghybrid@khu.ac.kr> wrote:
> Hi Ping-Ke,
> 
> Here are the test conditions and results to help with the v3 review. I
> have listed the 13 tests reported previously first, followed by the v3
> results.
> 
> The tests used an RTL8192EU USB adapter on a Raspberry Pi. I adapted the
> RX changes to the Pi's existing Linux 6.18.46 RT kernel so they could be
> tested on the device.
> 
> For the recovery tests below, I checked that all 32 URBs were retained,
> reception resumed without restarting the interface, and stop freed the
> URBs. The RX completion counts are from after the injected errors ended.
> 
> 1. clean-fixed-regression

Are these test items generated by LLM? and how did you make plan to test
these?  (Just curious.)

> 
> V3 passed 52 tests: 42 from the main test plan, one matched-input
> comparison, and nine first-start failure tests after a fresh module
> load. Two interrupt-URB tests were not run because the RTL8192EU does
> not use that path.

The new 52 or 42 tests I have lack information for them, but I don't
actually need them. I think you want to say "this patchset is fully
tested", right?

Ping-Ke

Hi Ping-Ke,

> Are these test items generated by LLM? and how did you make plan to test
> these?  (Just curious.)

Yes, an LLM helped put the test results together.

I based the plan on the failure points in the paths affected by the
changes: the start() error paths covered in my reply to patch 2/3,
completion errors, further submission failures during recovery, and
stop while RX work was pending or running.

The tests were designed to inject failures at those points and exercise
the actual driver paths on the RTL8192EU. For each path, the checks
followed what had already been allocated or submitted, whether it was
released or retained for retry, and whether RX recovered or stop left
any work or requests outstanding. Resource counts and work activity
were recorded to check those outcomes.

> I think you want to say "this patchset is fully tested", right?

Yes, that was what I intended to convey. I consider the series
thoroughly tested.

Thanks,
Kim Wooseok