ricardgb commented on issue #19435:
URL: https://github.com/apache/nuttx/issues/19435#issuecomment-4983905777

   ## Validation results (silicon, RP2350 / Pico 2 W, Linux host)
   
   Both fixes from the previous comment are now implemented and validated on 
hardware
   (composite CDC-ACM + CDC-NCM + USBMSC, USBMSC at interface 4, usbmon 
captures):
   
   **Bug 2 (deferred response no-op) — FIXED, validated:** Bulk-Only Mass 
Storage Reset now
   completes with a proper status stage instead of timing out. Before:
   `MSRESET: errno=110 (ETIMEDOUT)` (raw usbfs control transfer). After: 
`MSRESET: OK`,
   10/10 iterations, GET MAX LUN remains functional after each. Also exercised 
with MSRESET
   arriving *while* a Data-In command's CSW is pending, plus an immediate USB 
bus reset after
   it (mimicking macOS's recovery), 12 cycles: all clean.
   
   **Bug 3 (gratuitous Hi>Di stall) — FIXED, validated:** exact macOS trigger
   (`sg_raw -r 192 ... 1a 00 3f 00 c0 00`, MODE SENSE(6) alloc=0xC0):
   
   Before: 16-byte short data, then CSW read STALLed (-EPIPE) → clear-halt → 
CSW retry.
   After (wire trace): 16-byte short data, then the CSW immediately —
   `55534253 xx000000 b0000000 00` (dCSWDataResidue=0xB0, status good). **Zero 
bulk-IN
   stalls, zero clear-halts** across the whole suite (MODE SENSE 6/10, INQUIRY 
alloc 255,
   REQUEST SENSE alloc 252, READ CAPACITY exact-8).
   
   **No regressions:** FAT drive mounts and full-reads, CDC-NCM and CDC-ACM 
unaffected, warm
   reboots re-enumerate cleanly, and the GET MAX LUN fix from this issue still 
validates.
   
   **On the crash mentioned earlier:** the ARM lockup (wild jump in the USB IRQ 
path during
   the macOS stall→BOT-reset→device-reset loop) did NOT reproduce from Linux in 
24 deliberate
   race cycles (stall + MSRESET mid-flight + immediate bus reset) on either the 
unfixed or
   fixed firmware — it appears to need a narrow timing window that macOS's 
exact sequence
   hits. Since fixes 2+3 remove the entire triggering path (no stall → no BOT 
reset storm),
   the practical exposure is gone, but the underlying arch-level fragility 
remains
   un-root-caused; I'm leaving the evidence here (lockup registers, DPSRAM 
SETUP=MSRESET) in
   case it rings a bell for the rp2040/rp23xx driver authors.
   
   macOS mount test of the fixed image is next; will report the result here.
   
   ## Disclosure
   As above: investigation, fixes, and validation performed by an AI agent 
(Claude Code),
   operated and directed by the submitter, reviewed before posting.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to