ValveSoftware / ValveSoftware/SteamOS

[SteamMachine] SD card reader cannot read lexar play sd card specifically

Open
#2,814 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
2.6k
Forks
83
Avg merge
4m
Merged PRs (30d)
3

Description

Your system information
  • Steam client version: 1788652215 (built Sep 1 2026)
  • SteamOS version: 3.8.16 (build 20260716.1), kernel 6.16.12-valve24.5-1-neptune-616-gb2f7cfe85e45
  • Opted into Steam client beta?: No
  • Opted into SteamOS beta?: No
  • Have you checked for updates in Settings > System?: Yes
  • Hardware: Steam Machine (Valve Fremont), BIOS F7F0106
  • Steam ID: 76561198114900211
  • System report submitted via Settings → System → Advanced → System Report: Yes
Please describe your issue in as much detail as possible

Expected: a microSD card inserted into the built-in slot is detected and mounted, and its presence does not affect boot time.

What happens: with one specific card (Lexar PLAY microSDXC 512 GB, UHS-I/V30/A2) the SCSI probe of sda never completes normally. The async probe worker blocks indefinitely in read_capacity_10(), which blocks the udev coldplug queue and extends boot from 10 s to 2 min 28 s.

Boot with a working card (Samsung EVO Plus 512 GB) in the same slot:

20:42:22 usb 2-1: new SuperSpeed USB device number 2
20:42:22 sd 0:0:0:0: [sda] 1001390080 512-byte logical blocks: (513 GB/478 GiB)
20:42:24 Mounted /dev/sda1 at /run/media/deck/SD_MMC CRW
20:42:25 Startup finished in 4.244s (firmware) + 652ms (loader) + 1.668s (kernel)
         + 3.539s (userspace) = 10.104s

Boot with the Lexar card in the same slot:

20:44:31 usb 2-1: new SuperSpeed USB device number 2
20:45:01 usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
20:45:31 systemd-udevd: Worker [655] processing SEQNUM=3825 is taking a long time
         (~35 further workers: cpu0-cpu11, input0/1/2, PCI bridges, LNXVIDEO, MSFT0101)
20:46:01 systemd-modules-load.service: start operation timed out. Terminating.
20:46:01 dev-tpmrm0.device: Job dev-tpmrm0.device/start timed out.
20:46:49 sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
20:46:49 systemd-modules-load.service: Failed with result 'timeout'
20:46:52 Startup finished in 4.240s (firmware) + 650ms (loader) + 1.669s (kernel)
         + 2min 21.445s (userspace) = 2min 28.005s

The 138 s gap from enumeration to probe completion matches the userspace boot delay.

Blocked worker stack while the card is inserted:

[<0>] blk_execute_rq+0xea/0x160
[<0>] scsi_execute_cmd+0xff/0x410
[<0>] read_capacity_10+0x115/0x230
[<0>] sd_revalidate_disk.isra.0+0x116a/0x2b30
[<0>] sd_probe+0x2fe/0x540
[<0>] really_probe+0xdb/0x340
[<0>] __device_attach_async_helper+0xa1/0xf0
[<0>] async_run_entry_fn+0x33/0x140

On the first insertion after boot this also blocks modprobe of usb-storage/uas (async_synchronize_cookie_domain), hung-task warning after 122 s. Parent is systemd-udevd. In that run the Bluetooth Xbox controller appeared exactly 1 s after the probe returned, ~3 min after insertion.

Behaviour is non-deterministic. Across four consecutive insertions, READ CAPACITY(10) succeeded once (returning the correct 977305600 blocks in 2 s) and timed out three times (~3 min each, ending in a 0-byte device). In the successful case the subsequent Read(10) was aborted after 88 s (DID_ABORT), the device was offlined, and capacity later changed to 0. USB resets recur every 30 s indefinitely, continuing after the device is offlined.

The reader is not at fault, and neither is the card in isolation:

  • The same Lexar card works correctly in a Steam Deck (native SDHCI): timing spec: 6 (sd uhs SDR104), 200 MHz, 1.80 V, no retries, mounts normally.
  • A Samsung EVO Plus 512 GB in the same Steam Machine slot completes the whole sequence in 2 s with zero USB resets.
  • USB descriptors are byte-identical in both cases (bcdDevice 8.00, 1 interface, Bulk-Only, bMaxBurst 3, MaxPower 800 mA, SuperSpeed 5 Gbps). INQUIRY response is byte-identical.
  • Both cards negotiate identical bus parameters on the Deck; SCR differs only in SD_SECURITY, CSD only in C_SIZE.

Already tested, no effect: usbcore.quirks=0bda:0316:k (USB_QUIRK_NO_LPM), confirmed applied (/sys/bus/usb/devices/2-1/quirks = 0x400).

Full logs, descriptors and card registers: [gist](https://gist.github.com/winxp3/4382eb8f3b8c59c2f096d786a43c5461)

Steps for reproducing this issue
  1. Insert a Lexar PLAY microSDXC 512 GB card into the built-in SD slot. No SD card detected in settings -> storage
  2. Reboot. Boot takes ~2 min 28 s instead of ~10 s; systemd-modules-load.service fails with result 'timeout'.
  3. Remove and reinsert the card several times. Roughly one insertion in four reports the correct capacity; the rest report 0 512-byte logical blocks: (0 B/0 B) after ~3 minutes of 30-second USB resets.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the blocked kernel stack at read_capacity_10() and compare the attached logs, USB descriptors, and card registers for the Lexar and Samsung cards. Reproduce repeated insertions and boot with the Lexar PLAY card, then verify that probing completes without USB resets or boot delays and that the card mounts with its correct capacity.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.