ricardgb commented on issue #19435:
URL: https://github.com/apache/nuttx/issues/19435#issuecomment-4984664811
## macOS CONFIRMED: the mass-storage drive now mounts
Retest on the same macOS host (Apple Silicon, AppleT8132 XHCI) with the
bug-5 + bug-6
fixes applied: **the MSC volume now appears in Finder and mounts normally.**
The
enumerate → probe → reset-loop → "port disabled" failure is gone. The
composite's
CDC-ACM and CDC-NCM functions continue to work alongside.
That closes the macOS side of this issue end-to-end. Final tally of distinct
defects
found behind "macOS never mounts a NuttX composite MSC device", each
root-caused,
fixed, and validated on RP2350 silicon (fixes mirrored to rp2040 where the
code is
shared/ported):
1. **usbmsc_setup() compares wIndex against the compile-time interface id**
instead of
the composite-assigned `devinfo.ifnobase` → GET MAX LUN / MS-RESET /
GET,SET-INTERFACE
all EP0-stall in composite mode (macOS read a garbage LUN count off the
stall).
2. **usbmsc_deferredresponse() is compiled out in composite mode** (body
inside
`#ifndef CONFIG_USBMSC_COMPOSITE`) → Bulk-Only Mass Storage Reset never
gets its
status stage → timeout.
3. **Gratuitous bulk-IN stall on Hi>Di residue** even though the short
packet already
terminated the data phase → needless BOT reset recovery on macOS.
4. (Open, unreachable via this path now:) ARM lockup observed once during the
stall/reset storm; pc=0xEFFFFFFE, CFSR=0x00080001. Not reproducible from
Linux in
deliberate race testing; evidence preserved earlier in this thread.
5. **rp2040/rp23xx DCD drops IN requests submitted while the endpoint is
halted**
(David Hewson's CSW race, documented in usbmsc_scsi.c for over a decade)
→ the failed
command's CSW is lost and the host times out waiting for it after
Clear-Halt. Fixed by
implementing stall queuing (`ARCH_USBDEV_STALLQUEUE`) in the DCD.
6. **rp2040/rp23xx DCD never answers GET STATUS** (any recipient) → macOS's
GetPipeStatus on the halted pipe times out ~50 ms after the stall → reset
spiral.
Sibling issue #19434 (SIE_CTRL.PULLUP_EN clobbered in usbdev_register →
cold-plug
never enumerates) makes it seven distinct defects across
rp2040_usbdev.c / rp23xx_usbdev.c / usbmsc in this investigation arc.
A process note that may help others debugging similar reports: bugs 5 and 6
each
survived a Linux validation round because Linux's SCSI stack neither sends
the failing
command (MODE SENSE page 0), nor GET STATUS, and clears halts within 100
µs-100 ms.
What finally worked was replaying the exact macOS command bytes AND timing
(raw usbfs,
post-stall delay sweep 0-1000 ms in macOS's recovery order). Happy to share
the test
scripts if useful.
I'll leave patches/PR logistics to the maintainers' preference as before —
all fixes are
described precisely in this thread and are small.
## Disclosure
As above: this investigation and the fixes were performed by an AI agent
(Claude Code),
operated and directed by the submitter, and reviewed by the submitter 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]
