Skip to content

PSPLinkUSB / pspsh stops responding after many hours of mostly idle USB connection #74

Open
Open
PSPLinkUSB / pspsh stops responding after many hours of mostly idle USB connection#74

Description

@fjtrujy
fjtrujy
opened on Oct 23, 2026

Problem

On a real PSP running PSPLinkUSB over USB, pspsh / PSPLinkUSB can become unresponsive after many hours of connection, despite the PSP and host being idle for the majority of that time. The exact component that hangs is not yet identified: the PSP-side kernel USB transport, usbhostfs_pc on the host, or their interaction.

Environment

  • Real Sony PSP connected by USB to a Mac running usbhostfs_pc and pspsh.
  • PSPLinkUSB running on PSP; PSP-side USB HostFS kernel module.
  • Workload: mostly idle for several hours, with occasional shell commands; high-volume transfers are not a prerequisite for the reported failure.
  • Exact PSP model/firmware and exact time to failure not yet recorded.

Steps to reproduce (intermittent, long duration)

  1. Launch PSPLinkUSB on the PSP with its USB cable connected to the Mac.
  2. Start usbhostfs_pc and connect using pspsh.
  3. Leave both running and connected for several hours, mostly idle.
  4. Attempt to use the existing shell or establish a new session. Try pspsh -e 'echo ALIVE', pspsh -e 'ls ms0:/' and pspsh -e 'ls host0:/'.

Expected: The PSP shell and host file operations remain responsive; transient USB errors recover or produce an actionable failure.

Observed (user report): After many hours, pspsh / PSPLinkUSB no longer responds or accepts usable communication.

The original long-duration failure has not yet been reproduced in a controlled soak test. It is not known whether the PSP remains enumerated when this failure occurs or which recovery action is necessary.

Potential causes (hypotheses, not proven)

  • Unbounded PSP waits in usbhostfs/main.c: bulk read/write operations use sceKernelWaitEventFlag(..., NULL); command and async operations use sceKernelWaitSema(..., NULL). A lost USB completion or stalled host request may block a thread permanently.
  • Initial connection/attach handshake: usb_thread() synchronously waits to read the host magic in the same thread handling USB events. A blocked read may prevent timely detach/reconnect handling.
  • Host USB-handle lifetime race: the asynchronous thread accesses global usbhdr while the main thread may close/reassign it after a transfer error, without coordinated lifetime synchronization.
  • Async receive rearming: certain failed or zero-length completions previously disabled shell input reception until reconnect; partially addressed by PR Fix HostFS directory leaks, dangling symlinks and DREAD replies #72.

The PSP SDK libcglue code was investigated but appears less likely as the primary kernel USB transport cause; the relevant PRX links PSP kernel libraries rather than Newlib libcglue.

Important safety constraint: A timeout must not immediately reuse a static UsbdDeviceReq while the previous request might still be in flight. Cancellation and callback completion/endpoint quiescence must be handled first.

Related fixes and hardware validation

PR #72 addresses several adjacent confirmed issues: async receive rearming, failed transfer submissions, response validation, a HOSTFS_CMD_DREAD response-tag mismatch, successful scandir() allocation leaks, and dangling-symlink listings. It was validated on real PSP hardware with:

  • 1,000/1,000 native-C shell/HostFS test commands passed, with no timeouts or reported failures.
  • 3/3 physical USB cable disconnect/reconnect cycles recovered, without restarting the PSPLinkUSB application or the same host daemon.
  • Controlled host-daemon restarts recovered communications without a PSP restart.

These tests do not establish a fix for the many-hour, mostly-idle hang. This issue should remain open independently of PR #72 until long-uptime validation confirms the problem is resolved.

Related: PR #72; PR #71 (previous host-side reconnect/busy-loop work); docs/USB_LONG_UPTIME_INVESTIGATION.md in PR #72.

Useful diagnostics at the next occurrence

Before restarting anything, capture:

  1. Whether the PSP is still enumerated as USB VID 054c / PID 01c9 (macOS: ioreg -p IOUSB -l -w 0).
  2. Whether usbhostfs_pc is running and listening on localhost TCP ports 10000–10007, and whether a fresh pspsh TCP connection succeeds but no shell prompt or response arrives.
  3. Whether echo, ls ms0:/ and ls host0:/ behave differently (use a bounded per-command timeout to avoid leaving hung clients around).
  4. Host daemon logs, USB transfer errors, and thread stacks where practical.
  5. Whether physical USB unplug/replug, host daemon restart, or PSPLinkUSB restart is required to recover, plus elapsed time until the hang.

A several-hour idle soak with occasional bounded native-C probes can help isolate the failure without placing continuous transfer load on the PSP.

Activity

  1. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Confirmed physical long-uptime reproduction — 2026-10-24, approximately 10:44 CEST

    The original reporter left the PSP connected overnight with the USB HostFS daemon and PSPLinkUSB running. The next morning, new pspsh connections stopped responding. No PSP reset, physical unplug, or host-daemon restart has been performed during the investigation.

    Live observations in the failed state

    • Original Mac host daemon PID 89905 remains running, started 2026-10-23 at 11:53:29 CEST, 22h 50m+ process uptime when captured. RSS 7,760 KiB, not consistent with runaway resident-memory growth.
    • macOS still enumerates Sony PSP 054c:01c9 as "PSP" Type B, with the interface exclusively owned by PID 89905. Current USB sessionID 5459133570798, which differs from the one observed in the earlier successful tests.
    • Daemon still listens on localhost TCP ports 10000–10007. Thus, an exited daemon or missing TCP listener is not the failure mode.
    • Native C hardware test: usb_hardware_smoke --iterations 3 --timeout 3 failed on its first shell echo after timeout, no output. Repeated with a two-second timeout; same result.
    • Control check using the older backed-up pspsh binary also timed out on its first echo. The recent unmatched-quotes pspsh fix is not responsible.
    • Two independent sample captures of PID 89905: main thread in start_hostfs() -> libusb_bulk_transfer() -> asynchronous USB bulk-IN read waiting in poll(); host async thread waiting in select(). These are host-side waiting states, not definitive proof of a deadlocked PSP-side kernel thread. No new data returned by the PSP to complete the shell echo.
    • Mac host daemon log has its last modification timestamp 2026-10-24 00:49:56 CEST, with some final HostFS file activity at that time. The logging is partially buffered; this timestamp cannot establish exactly when the freeze began.
    • macOS pmset -g log confirms that the host entered system sleep at 03:57:24 CEST and underwent repeated maintenance DarkWake/sleep cycles overnight. USB device session also changed. Mac sleep/wake and PSP USB detach/attach recovery are now high-priority suspects, but temporal correlation does not prove they caused the original hang.

    Code areas to instrument next

    1. PSP-side usb_thread() processes USB attach/detach/async events, but during USB_EVENT_ATTACH calls read_data(&magic, 4) synchronously. That function waits in sceKernelWaitEventFlag(..., NULL) for completion. A stalled handshake can prevent the same thread from processing later detach events.
    2. PSP synchronous HostFS commands and async shell transfers use unbounded sceKernelWaitSema(..., NULL) / sceKernelWaitEventFlag(..., NULL); a lost completion may retain the semaphore and stall shell/HostFS indefinitely.
    3. Investigate host-side usbhdr lifetime across the main and async threads and whether USB sleep/wake reenumeration can leave a stale receive request or endpoint state.

    Important: Do not introduce a timeout which immediately resets/reuses an in-flight static UsbdDeviceReq. Quiescence and cancellation completion must be verified before reuse.

    Preserved evidence

    Local-only diagnostic snapshots (not uploaded because of machine-specific/private data):
    ~/Downloads/psplinkusb-issue74-reproduction-20261024/

    Contains host process and TCP snapshots, USB IORegistry snapshot, two 2-second host daemon thread samples, failure output for the C test with installed and original backed-up pspsh. The original host daemon and PSP connection have not been reset yet; further non-disruptive physical observations and an isolated recovery test can follow.

    Status: Confirmed overnight failure; specific root cause still under investigation. The short-duration USB/reconnection fixes in PR #72 are insufficient to guarantee long-uptime stability. This issue should remain open.

  2. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Recovery experiment following the confirmed overnight hang (2026-10-24)

    After saving thread samples, macOS USB descriptors, logs and two failing native-C shell probes, I stopped only the original Mac host daemon (PID 89905) via SIGTERM. I did not exit or reboot PSPLinkUSB on the PSP and did not physically unplug the cable.

    Important interpretation: on shutdown, the host's close_device() invokes libusb_reset_device(). macOS consequently re-enumerated the PSP, giving it a new USB session ID 5807329636962. The recovery therefore combines host daemon restart + USB device reset; it must not be described as proof that restarting only userspace fixes the hang.

    • Restarted the same rebuilt host executable as PID 9028.
    • usb_hardware_smoke (native C) passed 3/3 commands, then 120/120 commands (shell echoes, ms0:/, host0:/), with zero failures; p95 53 ms, maximum 60 ms.
    • The PSP application itself remained running and did not require a reboot.
    • Saved original pre-reset host log, new host log, native-C smoke outputs and more details locally in ~/Downloads/psplinkusb-issue74-reproduction-20261024/.

    This confirms an overnight communication hang recoverable by host restart plus USB reset. The leading next investigation is whether macOS sleep/wake or a lost PSP-side completion/async receive causes the stale transport. A controlled A/B soak with Mac system sleep disabled, then enabled, would help distinguish causes. Keep the issue open.

    The HOME button is not an appropriate PSPLinkUSB responsiveness test because the application has never supported HOME-to-exit, including when functioning normally.

  3. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Fresh macOS reboot baseline — 2026-10-24, 12:05–12:09 CEST

    The Mac was rebooted by the reporter after our overnight-failure capture and controlled host-daemon + USB-reset recovery.

    • Fresh Mac boot: 2026-10-24 12:02:56 CEST.
    • PSP remained enumerated as Sony 054c:01c9, while no usbhostfs_pc was running immediately after reboot.
    • Started the previously installed corrected Mac host binary from the PSP toolchain, PID 1951, without requesting a PSP reboot.
    • Real-hardware native C smoke: 12/12 commands passed right after startup.
    • Extended real-hardware native C smoke: 1,000/1,000 shell, ms0:/, and host0:/ commands passed in 36.52 seconds, p95 70 ms, maximum 90 ms. Host daemon resident memory was 7,440 KiB before and 7,536 KiB after (96 KiB change; not evidence of an unbounded leak).
    • C-only offline regression tests also passed: directory operations, mocked command error/timeout handling.
    • The daemon subsequently reconnected when macOS observed a new PSP USB session (around 12:07); the daemon remained active. This change was not a controlled sleep/wake test, so the cause of the re-enumeration is not established.

    Interpretation: Current build passes both short command stress and host-startup recovery following an OS restart. It has not yet passed a controlled overnight idle test. To test the sleep/wake hypothesis, perform a future controlled long-idle A/B: macOS prevented from system sleeping (e.g. a time-bounded caffeinate session, with user consent) versus normal sleep enabled. Do not overinterpret overnight uptime when pmset -g log confirms repeated sleep cycles.

    Baseline diagnostic logs were saved at ~/Downloads/psplinkusb-issue74-reproduction-20261024/ (host-after-macos-reboot.log, smoke-after-macos-reboot.txt, stress-after-macos-reboot.txt).

  4. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Additional diagnostic instrument prepared (2026-10-24)

    Built an opt-in host-only USB transport trace in branch investigate/usb-sleep-wake-issue74 (commit 18ba8d0). This is deliberately not part of PR #72, and it does not change USB recovery logic.

    • usbhostfs_pc -T logs timestamps, the outcome of TCP async channel USB submissions, bulk-IN errors, and every 30 seconds of idle read timeouts whether the original libusb_device_handle refers to an object still in the live enumerated libusb device list (1 / 0 / -1).
    • Native C regression test with mocked libusb lists covers same-device, re-enumeration/stale-device and enumeration-error cases. Both this and the existing directory test pass.
    • A traced host daemon is now running on the Mac as PID 25415, with the original PSP application intact. Baseline at 13:03 CEST: macOS PSP session ID 84332294269, current-device check 1, shell/HostFS native C smoke 12/12 passed. The new log is in the user's private local ~/Downloads/psplinkusb-issue74-sleep-wake-diagnostics-20261024/ directory.
    • Next: compare the state immediately after a manual Mac sleep/wake, without first resetting the PSP or daemon, to test the sleep hypothesis. A successful short sleep/wake does not disprove a long-idle issue, but a failure will distinguish stale host handles from other USB transport stalls.

    The traced binary is launched from the working repository, not installed over the toolchain's normal host binary. The GitHub PR #72 production patch remains unchanged.

  5. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Second confirmed real-hardware idle hang, captured with the -T host trace — October 24, 2026, 23:52 CEST

    The reporter observed pspsh hanging again after the diagnostic host daemon had been running 10h 51m. No reboot, USB unplug, host daemon restart, or USB reset was done before capturing this evidence. This is a significant advance over the original reproduction because the trace identifies the direction and libusb status of a failed transfer.

    Frozen state:

    • usbhostfs_pc -T -v remained alive as PID 25415 (started at 13:01:23); resident memory approximately 7,520 KiB.
    • macOS still enumerated the PSP 054c:01c9; USB sessionID 118627976632, with exclusive owner PID 25415. TCP shell port 10000 and other channels were listening.
    • The main daemon thread was in start_hostfs() waiting on a bulk-IN read (libusb_bulk_transfer, timeout/retry loop). The host async thread was in select() between requests. Host sample files were captured both before and after the test.
    • 818 idle bulk-IN timeouts were logged (rate-limited to 1 line per 30 seconds), consistently reporting original device enumerated=1. This argues against a stale libusb device object as the primary explanation; the same live device was still listed.
    • Mac power logs report 54 entries for entering system sleep over the day, including repeated DarkWake/sleep cycles and a normal wake at 22:31:35. Correlation with the hang is not yet causal proof.

    Decisive failure:

    A bounded native-C test failed on the first pspsh -e 'echo PSPLINK_USB_SMOKE_OK', timing out after 3 s with no response. The host subsequently logged:

    [USB trace 2026-10-24 23:53:05] async channel=0: submitted 14 bytes, transferred=-7

    libusb -7 is LIBUSB_ERROR_TIMEOUT. The Mac daemon accepted the shell command and attempted to send its 14-byte async frame host -> PSP via USB bulk OUT endpoint 0x03, but the write did not complete within the host's 10-second USB transfer timeout. In parallel, the PSP -> host bulk-IN endpoint 0x81 continued producing the expected idle read timeouts, and the PSP remained USB-enumerated.

    Most recent successfully submitted shell writes were at 22:34:53 and 22:37:02 (14 bytes each, reported transferred=14). We do not yet know whether the PSP processed those commands; transfer success alone is not evidence of shell execution. The observed hard failure occurred on/after the attempted shell write at 23:52:55.

    Leading diagnosis: the PSP is no longer accepting/scheduling receives on its async USB command endpoint (endpoint 3), or the endpoint/controller is stalled, despite the device remaining enumerated. This is consistent with set_ayncreq() failing to arm a replacement request without retry scheduling, an in-flight g_async_req lost across suspend/resume, or a blocked PSP-side connection thread. The precise PSP request state is not yet captured, so none of these individual mechanisms is proven. It is now less likely that either the local TCP socket or a generic stale host USB device handle is the primary fault.

    Evidence saved locally under ~/Downloads/psplinkusb-issue74-freeze2-20261024/: snapshots of the USB device, host process and sockets, thread samples before/after probe, copy of the trace before and after the failed write, native C failure output and macOS sleep/wake history.

    No unsafe timeout/reuse workaround: The PSP's static UsbdDeviceReq can still be owned by the USB driver after an apparent stall. A safe repair requires tracking in-flight ownership and cancellation/completion, and a way to rearm endpoint 3 after failures. Further experiments should isolate whether resetting only the USB interface (without restarting the PSP) restores normal operation, after preserving the frozen state.

  6. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Major recovery discriminator: reconnect works without a USB device reset or re-enumeration (2026-10-24 ~23:56 CEST)

    After preserving the second frozen-state trace and host process samples, we conducted a controlled test to distinguish a Mac userspace/USB interface rebind from a full USB device reset:

    1. Terminated the frozen PID 25415 with SIGKILL so the normal close_device() cleanup and its libusb_reset_device() call were not executed.
    2. macOS continued to report PSP USB sessionID 118627976632 unchanged, with no exclusive owner while the daemon was stopped.
    3. Launched the rebuilt diagnostic host daemon as PID 77967 with a new -N flag that suppresses libusb_reset_device() on close. The new daemon acquired the same enumerated PSP instance (sessionID 118627976632). PSPLinkUSB itself remained running on the console; there was no cable disconnect or PSP reboot.
    4. The native C smoke test passed 3/3, then 120/120 shell/PSP-memory-stick/host directory commands. The 120-command run took 4.41 s (p95 62 ms, max 76 ms), and the macOS USB session ID remained identical throughout.

    Conclusion: A full USB device reset or PSP reboot is not required to recover this reproduced hang. Releasing the old host process's libusb interface and opening/claiming the same PSP device through a fresh host process is sufficient. This strongly implicates host-side USB interface/pipe state or a host/PSP endpoint mismatch that can be cleared by re-claiming the interface. The OS/driver may still reset individual USB pipe state on release/claim; we have NOT proven this is purely a host-userspace defect, nor that the PSP endpoint was healthy throughout.

    The original hang's decisive symptom was an endpoint 0x03 (Mac -> PSP async command) libusb write timeout -7, while the host's endpoint 0x81 bulk-IN polling loop and USB device enumeration remained active. This suggests a targeted next host recovery approach: when endpoint 3 write fails, coordinate the host's async and main threads to quiesce transfers, safely release/close the interface, then reopen it without forcibly resetting the whole USB device. The current host uses an unsynchronized global usbhdr in both threads; it must not close a handle while the other thread has a transfer in flight.

    Evidence stored locally under ~/Downloads/psplinkusb-issue74-freeze2-20261024/: before/after IORegistry snapshots, host logs, test output, host thread samples, power events. Host diagnostic branch has a local uncommitted -N switch; this experimental change is not included in PR #72.

  7. fjtrujy
    added a commit that references this issue on Oct 24, 2026

    Recover stalled async USB commands with synchronized device reconnect

    2187e26

  8. fjtrujy commented on Oct 24, 2026

    @fjtrujy
    fjtrujy
    on Oct 24, 2026
    MemberAuthor

    Candidate automatic recovery implemented and validated with fault injection (2026-10-25)

    Investigative branch: investigate/usb-sleep-wake-issue74, commit 2187e26 (not part of PR #72).

    Mechanism

    • The host async USB thread now acquires a shared libusb handle through a short-lived mutex-protected reference counter. The mutex is not held over USB I/O, so the 1-second idle read does not block normal interactive writes.
    • If a bulk OUT endpoint 0x03 write fails or transfers fewer bytes than requested (the real hang reported LIBUSB_ERROR_TIMEOUT, -7), the async thread requests recovery and stops admitting new writers.
    • The host's main receive loop observes the request between bounded bulk IN reads, waits for any in-flight async write to finish, then safely releases, resets and closes the USB device before reconnecting.
    • This avoids the old unsafe cross-thread handle-close race on this recovery path. The stalled shell command may be lost and must not be automatically retried if non-idempotent.

    Critical experiment: why no-reset recovery was rejected

    A special debug build injecting a one-shot endpoint-3 LIBUSB_ERROR_TIMEOUT was run on a physical PSP. Attempting automatic interface release/reclaim without a reset produced a persistent HELLO/reconnection loop: pspsh still timed out. This differed from our earlier SIGKILL/new-process recovery, emphasizing that host process termination and graceful interface release are not equivalent at the USB-pipe level. A known-good installed host daemon restored the PSP connection without rebooting the console.

    With a coordinated USB device reset enabled for async failure, the same injected timeout was detected, a new PSP USB session was enumerated, the daemon reconnected automatically, and 120/120 subsequent real-PSP commands passed (6.35 seconds, p95 77 ms, max 85 ms). The originally injected command was lost, as expected.

    The production (non-injected) branch binary was then launched (host PID 82343, launched from the local repository with -T -v); the fault-injection code is compiled out. Baseline 12/12, followed by 1,000/1,000 real PSP shell/HostFS operations (36.99 s, p95 74 ms, max 96 ms) passed with zero failures. macOS still enumerates the connected PSP, and the daemon remains alive. make -C tests test also passes, including the new plain-C multi-threaded recovery regression test.

    Status: automatic recovery from this particular endpoint 3 error is demonstrated; long-term prevention of the originating stall and recovery from a naturally occurring overnight failure are not yet proven. This is not ready to close #74. Leave the connected PSP and diagnostic host running through another normal idle/sleep period, then look for the error/reconnect trace and verify fresh shell and HostFS commands work without a manual restart.

    Local diagnostic logs: ~/Downloads/psplinkusb-issue74-auto-recovery-20261025/ (contains the failed no-reset test, successful injected-reset test and the 1,000-command normal build run). No machine-private logs uploaded.

  9. fjtrujy commented on Oct 25, 2026

    @fjtrujy
    fjtrujy
    on Oct 25, 2026
    MemberAuthor

    Third overnight reproduction: endpoint 3 write succeeds, but PSP shell is silent (2026-10-25, 13:28–13:30 CET)

    This is a distinct failure mode from the earlier endpoint-3 USB write timeout, and explains why the automatic recovery candidate at 2187e26 did not recover this session.

    • Normal (non-fault-injected) auto-recovery daemon PID 82343, running 14h 13m, RSS about 7.6 MiB, still owns the enumerated PSP USB device. PSP session ID 719306001058 remains unchanged; all TCP listeners 10000–10007 are present.
    • Reporter observed pspsh hanging after the Mac's overnight sleep/wake cycles. macOS pmset logs many sleep/DarkWake events and a human wake at 13:28:02 CET.
    • Host trace: shell TCP traffic reached the daemon and a 14-byte bulk OUT write to endpoint 0x03 completed (transferred=14) at 13:28:20 CET. A second bounded C echo probe at 13:30:11 CET again showed transferred=14 but no response, timing out after 3 seconds.
    • The async write's successful transfer status is an acknowledgement by the USB stack, not proof that PSPLinkUSB processed the command. No matching PSP->host shell output was observed. The host's endpoint 0x81 idle bulk-IN timeout loop continued and the original libusb device object remained enumerated (enumerated=1).
    • The auto-recovery code only triggers on error/short-write, so it observed zero recovery-worthy failures, and therefore made zero recovery attempts. The daemon's main thread is in libusb polling for bulk-IN data; async thread is in select() waiting for local TCP activity.
    • Last successful outbound shell frame previously seen around 01:49:30, but no probes were run between that and 13:28; the first actual moment of failure cannot be established.

    Implication: We need either PSP-side visibility into async endpoint-3 request-completion/rearm and shell dispatch, or a host-side liveness/after-sleep policy, not only an endpoint error trigger. The macOS sleep-causation hypothesis remains plausible but is not yet proven. Blindly replaying a command after a USB write reported success is unsafe (it might have been executed without a response).

    Full diagnostic snapshots captured before any recovery locally at ~/Downloads/psplinkusb-issue74-freeze3-20261025/ including USB IORegistry, daemon samples, power history, trace and bounded C failure. No daemon or PSP restart at time of this note.

  10. fjtrujy commented on Oct 25, 2026

    @fjtrujy
    fjtrujy
    on Oct 25, 2026
    MemberAuthor

    Candidate wake-triggered recovery after third confirmed overnight hang (2026-10-25)

    Third natural failure: original daemon PID 82343 was running for 14h 13m after the previous endpoint-error-only fix. pspsh could not obtain shell output, yet the Mac accepted the local TCP command and successfully transmitted a 14-byte frame over USB bulk OUT endpoint 0x03 (transferred=14) at 13:28:20 CET and on another bounded C probe at 13:30:11 CET. The PSP did not respond. Bulk-IN endpoint 0x81 continued its idle read timeout loop and the device remained enumerated under USB session 719306001058. No short-write/error occurred, so the existing endpoint-error auto-recovery was never invoked. pmset shows repeated sleep/DarkWake cycles immediately preceding the wake at 13:28:02 CET. Root cause still not proven.

    Preserved failure-state process/thread samples, USB IORegistry, log snapshots and power history before any reset in ~/Downloads/psplinkusb-issue74-freeze3-20261025/.

    New opt-in host recovery candidate: commit f254e16 on branch investigate/usb-sleep-wake-issue74 adds macOS -W. It compares clocks that include and exclude time spent in system sleep. On waking from >5 seconds of sleep, the main thread quiesces async USB I/O and resets/reconnects the USB device even if endpoint-3 writes previously succeeded. This avoids guessing whether a command with a successful transfer actually executed, and does not auto-replay commands. -W is mutually exclusive with -N (no device reset). The endpoint-error recovery remains in place.

    Validation: all 4 native-C offline tests pass (new sleep-gap unit test included). A build with test-only synthetic 120-second wake injection auto-reset/reconnected and passed 120/120 real-PSP commands (p95 76ms, max 91ms). The normal non-injected experimental build then passed 12/12 + 1,000/1,000 real-PSP commands (1000 operations: p95 77ms, max 91ms). PSPLinkUSB on the console was not rebooted.

    Active test: non-injected host daemon PID 19673, running locally from the investigation branch with -T -W -v. Do not confuse this with installation of a permanent toolchain binary or merging into PR #72; neither happened.

    Limits: -W is experimental. It also reacts to overnight DarkWake, so repeated reset/re-enumeration churn is possible; inspect the trace for frequency. Need a real macOS sleep/wake and follow-up shell/HostFS verification, then extended soak. Sleep causation and PSP endpoint callback/request state remain open. #74 must remain open until naturally occurring recovery is validated.

  11. fjtrujy commented on Oct 25, 2026

    @fjtrujy
    fjtrujy
    on Oct 25, 2026
    MemberAuthor

    First real macOS sleep/wake validation of experimental -W recovery — 2026-10-25

    The reporter manually put macOS to sleep and woke it, leaving the PSP with PSPLinkUSB running and the cable untouched. The existing experimental host daemon continued running as PID 19673 (usbhostfs_pc -T -W -v); it was not manually restarted.

    macOS power logs confirm software sleep and subsequent wake at approximately 13:51–13:52 CET. The host logged:

    Mac resumed from 9.2s of sleep; refreshing PSP USB session
[USB trace 2026-10-25 13:52:19] wake-triggered reconnect after 9.2s of sleep
[USB trace 2026-10-25 13:52:19] coordinated USB reset (async failure=0 wake=1)
waiting for device...
Connected to device

    The 9.2s value is the delta observed by the continuous-vs-awake clock comparison; it is not necessarily the full wall-clock interval that the machine spent in sleep/DarkWake.

    Physical PSP post-wake results:

    • First native C shell/HostFS smoke test: 12/12 commands passed in 0.45s, p95/max 55ms.
    • Additional smoke test: 120/120 commands passed in 2.75s, p95 51ms, max 52ms.
    • The Mac host process remained PID 19673, RSS approximately 7.6 MiB; USB was re-enumerated to session ID 1209936286652, as expected after the deliberate reset.
    • Exactly one wake-triggered reconnect was logged in this session so far. No repeated reset loop, async transfer errors or manual PSP restart during validation.

    Interpretation: -W now has successful real sleep/wake validation in addition to the injected-wake and endpoint-timeout tests. This is a promising workaround, but still not evidence that sleep causes every observed hang or that the PSP async endpoint issue has been corrected. Extended unattended sleep/DarkWake soak and fresh post-idle shell tests remain necessary. Issue #74 should remain open.

    Branch: investigate/usb-sleep-wake-issue74 @ f254e16. Private diagnostic snapshots saved locally under ~/Downloads/psplinkusb-issue74-wake-recovery-20261025/real-sleep-20261025/.

  12. fjtrujy commented on Oct 26, 2026

    @fjtrujy
    fjtrujy
    on Oct 26, 2026
    MemberAuthor

    First successful overnight soak with the opt-in macOS -W workaround (2026-10-26, 07:53 CET)

    The reporter left a real PSP running PSPLinkUSB and the non-injected experimental usbhostfs_pc -T -W -v daemon overnight. pspsh remained connected and responsive the next morning. I independently confirmed:

    • Same host PID 19673, daemon uptime 18h 14m, RSS 7,872 KiB; process did not restart.
    • PSP remains enumerated and claimed by the same process, with TCP shell listener active.
    • New native C hardware smoke run: 120/120 shell/HostFS commands passed in 6.34 s, p95 76 ms, maximum 82 ms. No manual PSP reboot, cable disconnect, or host-daemon restart was required.
    • Full trace contains 28 wake-triggered coordinated USB resets/reconnects, mostly following overnight macOS maintenance DarkWake cycles, and two independent bulk-IN error=-1 (LIBUSB_ERROR_IO) events that reconnected successfully. Zero async endpoint-3 write failures and no repeated reconnect loops in this period.

    Assessment: This is the first successful real overnight result for our workaround, strengthening the case for sleep-related USB session state as a contributing factor. It still does not prove the root cause or that the connection would otherwise have failed during the same overnight period.

    Production concern: 28 full USB resets over approximately 18 hours is too eager; most were on maintenance DarkWake, when no user interaction was required. The next refinement should avoid unnecessary resets, e.g. distinguish interactive wake from maintenance wake or add an explicit safe liveness handshake with the PSP before resetting. Please do not close issue #74 or enable -W by default yet.

    Documentation committed to investigation branch as 9a0534a; private snapshots on the reporter's Mac under ~/Downloads/psplinkusb-issue74-wake-recovery-20261025/overnight-20261026/. PSP session is currently left running with -W unchanged for observation.

  13. fjtrujy commented on Oct 27, 2026

    @fjtrujy
    fjtrujy
    on Oct 27, 2026
    MemberAuthor

    Second consecutive overnight: responsive after 43h 32m without host/PSP restart (2026-10-27, 09:11 CET)

    The reporter again confirmed pspsh remained connected following an overnight sleep period. Independently verified on physical hardware:

    • The same usbhostfs_pc -T -W -v PID 19673, started 2026-10-25 at 13:40 CET, has now run 43h 32m without process restart. The connected Sony PSP USB device is still enumerated, exclusively owned by this daemon; RSS around 7.4 MiB.
    • New native-C shell/HostFS smoke test: 120/120 passed in 5.75s; p95 75ms, max 87ms.
    • Full log across the 43+ hour run: 50 wake-triggered USB reset/reconnect events; 23 independent bulk-IN LIBUSB_ERROR_IO read errors that the host reconnected after; 0 endpoint-3 async write failures. The bulk-IN errors warrant attention but did not make the link unavailable. macOS power logs corroborate repeated overnight maintenance DarkWake events, with a wake-triggered reset at 07:54 CET on October 27.
    • No PSP reboot, USB cable disconnect or host daemon restart was needed; no reset-loop that prevented eventual operation was observed.

    This is two consecutive overnight stability successes for the opt-in -W host workaround, but it is not evidence that the originating failure is prevented or its precise root cause is identified. 50 full USB resets over ~43h is excessively aggressive for default behavior. A conservative follow-up should reduce maintenance DarkWake resets by checking application-level PSP liveness before resetting, taking care not to replay commands that may already have executed.

    Updated investigation docs in commit ede1228 on branch investigate/usb-sleep-wake-issue74; captured private logs and state under ~/Downloads/psplinkusb-issue74-wake-recovery-20261025/overnight-20261027/. Issue remains open pending a less intrusive reliable recovery design.

  14. fjtrujy commented on Oct 30, 2026

    @fjtrujy
    fjtrujy
    on Oct 30, 2026
    MemberAuthor

    Fourth physical hang reproduced — installed host WITHOUT -W (2026-10-30)

    The reporter noticed pspsh hanging again. I captured the live frozen state before any reset:

    • usbhostfs_pc PID 6771 had run for 22h 16m since October 29, 12:36 CET. Unlike the preceding successful overnight trials, it was the installed PSP toolchain binary (.../pspdev/bin/usbhostfs_pc) built October 23, launched without -W and without diagnostic -T. The installed binary has neither option. This was not the experimental wake-recovery daemon.
    • PSP Sony USB device remained enumerated, original session ID 2941927314478, exclusively owned by this PID; TCP shell port 10000 was listening. macOS had repeatedly slept and DarkWoken.
    • Native C smoke failed the first pspsh echo with no output. Host thread samples before and after the test show the main thread polling libusb bulk-IN and async thread waiting in select. As the installed binary lacks -T, endpoint-3 transfer status was not observable in this reproduction.
    • Preserved logs, samples, USB IORegistry and power history in ~/Downloads/psplinkusb-issue74-freeze4-20261030/ before stopping the host.

    Restoration: gracefully stopped PID 6771, rebuilt and launched the non-fault-injected experimental branch daemon as PID 19610, with -T -W -v, without overwriting the installed toolchain binary or rebooting/unplugging the PSP. USB re-enumerated under session 3738831471722, and the native PSP hardware test passed 12/12 then 120/120 commands (120 commands in 3.00s, p95 55ms, max 56ms). PID 19610 remains running for soak.

    Interpretation: This is a further reproduction of the long-idle failure without the wake workaround, not a failure of that workaround. The PSP-side async PR #76 is still open and was not deployed, so this occurrence does not test it. The actual USB-level root cause remains unresolved; recovery by reconnect is confirmed. The high rate of wake-triggered resets remains a concern for production. Investigation branch documentation updated in 4241fb2. Keep #74 open.

  15. fjtrujy commented on Oct 30, 2026

    @fjtrujy
    fjtrujy
    on Oct 30, 2026
    MemberAuthor

    Fifth incident — PSP disappears from macOS USB while -T -W recovery host is running (2026-10-30)

    At 23:38 CET, the reporter found pspsh unresponsive again. Captured the failure before any cable, PSP or host restart.

    • Experimental usbhostfs_pc -T -W -v is still PID 19610, ~12h 44m uptime since 10:54. Its TCP shell sockets are listening, but Sony PSP is completely absent from IOUSB/IORegistry (not merely inaccessible). No USB exclusive owner is listed for the PSP. Native C shell/HostFS probe fails the first command.
    • The daemon trace stopped 10+ hours earlier, after two successfully reconnected LIBUSB_ERROR_IO bulk-IN failures at 10:55:44 and 12:34:26. A third at 13:12:52 was fatal to the host's USB session:
    [USB trace 2026-10-30 13:12:50] async channel=0: submitted 14 bytes, transferred=14
[USB trace 2026-10-30 13:12:51] async channel=0: submitted 14 bytes, transferred=14
[USB trace 2026-10-30 13:12:52] bulk-IN error=-1 (LIBUSB_ERROR_IO); reconnecting
[USB trace 2026-10-30 13:12:52] closing USB device handle; reconnect requested
waiting for device...
    • No Connected to device after the third failure, no wake-triggered reconnect, and no async endpoint-3 transfer failures logged for this session. Mac sleep/DarkWake events around 22:23 onward happened many hours after USB disappeared.
    • Thread sample confirms main thread is polling in wait_for_device() (not deadlocked), async TCP server thread in select. -W only runs the wake detector while attached; it cannot recover an absent physical USB device.
    • The normal close_device() path calls libusb_reset_device(). It is not established whether that host reset left PSP USB unenumerated, the PSP firmware/USB driver stopped, or a power/cable/port event occurred. We need to inspect the powered-on PSP and USB cable status before concluding cause.

    No restart performed. Diagnostic IORegistry, full host trace, process thread samples and bounded smoke result are at ~/Downloads/psplinkusb-issue74-freeze5-20261030/. Investigation docs committed/pushed as 5863217. Keep issue open; next experiment is observe PSP screen/USB physical status, then controlled cable or driver reconnect while leaving the host waiting for device. We should also record libusb_reset_device return values/USB enumeration transitions in future builds.

  16. fjtrujy commented on Oct 31, 2026

    @fjtrujy
    fjtrujy
    on Oct 31, 2026
    MemberAuthor

    Correction to the October 31 "again hanging" report

    The reporter has clarified that PSPLinkUSB was not connected at the time of the October 31 check. Therefore, the October 31 observation that macOS could not enumerate the PSP, and that the host daemon was waiting in wait_for_device(), was expected and must not be counted as a new confirmed long-idle hang.

    No USB or daemon reset was performed during that check. The trace still contains the October 30 13:12:52 LIBUSB_ERROR_IO and subsequent lack of enumeration, but because the precise connection/disconnection timing has not been established, that earlier event cannot be confidently attributed to a software hang or to host-triggered USB reset. Keep the saved diagnostics as historical observations, but treat the cause of that earlier disappearance as unconfirmed until reproduced while PSPLinkUSB is definitely running and physically connected.

    For further validation, ensure the PSP is running PSPLinkUSB and the cable is attached, and verify successful pspsh commands before beginning any long-idle soak.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions