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