Surface Go (1st gen) camera: cros_camera_service crashes with DCHECK failed: ptr_ — no sensor subdevs registered

Support & help
,
1

:pushpin:Question Description

Have you searched the community for related issues?

Yes. I found a very similar thread about the Surface Go 2 (topic/43122) where the rear camera is detected but fails to capture (black screen, CSI-2/D-PHY errors). My issue is different and happens at an earlier stage: no sensor ever registers as a v4l-subdev, so cros_camera_service finds no camera at all and crashes.

Description

On my Surface Go (1st gen), cros_camera_service crashes consistently on startup with a DCHECK failed: ptr_ immediately after reporting 0 available cameras. The service enters a crash/respawn loop and no camera ever becomes available.

I’ve verified this is not a configuration or permissions issue, and not related to camera_hal.yaml: even using libcamera directly (cam --list, with sudo, bypassing cros_camera_service entirely) detects zero cameras. The problem is confirmed at the kernel level: no sensor ever registers as a v4l-subdev device, even though the kernel does detect and communicate with them over I2C.

Hardware and system information

  • Device: Microsoft Surface Go (1st gen)
  • FydeOS Board: surface-go-io
  • FydeOS Release Version: 16503.20.22.6
  • Kernel: 6.6.99-09011-gfdc62122de5f-dirty

Expected behaviour

cros_camera_service should register at least the ov8865 (rear) and ov5693 (front) cameras as v4l-subdevs and expose them without crashing.

Actual behaviour

ipu3-cio2 detects all 3 sensors via ACPI:

ipu3-cio2 0000:00:14.3: Found supported sensor INT33BE:00
ipu3-cio2 0000:00:14.3: Found supported sensor INT347A:00
ipu3-cio2 0000:00:14.3: Found supported sensor INT347E:00
ipu3-cio2 0000:00:14.3: Connected 3 cameras

The sensors respond over I2C:

ov8865 i2c-INT347A:00: Instantiated dw9719 VCM
ov7251 i2c-INT347E:00: OV7251 revision 7 (1F) detected at address 0x60

(ov5693/INT33BE does fail probe with error -121, falling back to dummy regulators for dovdd/dvdd — possibly a separate issue related to a missing real regulator; mentioning it in case it’s relevant.)

But no sensor ever creates a v4l-subdev node. Verified directly:

$ ls -la /dev/v4l-subdev*
crw-rw----. 1 root camera 81, 14 Aug  8 17:13 /dev/v4l-subdev0
crw-rw----. 1 root camera 81, 15 Aug  8 17:13 /dev/v4l-subdev1

$ cat /sys/class/video4linux/v4l-subdev0/name
ipu3-imgu 0
$ cat /sys/class/video4linux/v4l-subdev1/name
ipu3-imgu 1

The only two subdevs that exist anywhere on the system belong to the IMGU (image processor, PCI 0000:00:05.0) — none correspond to ov8865, ov7251, or ov5693. No cio2-bridge lines appear in dmesg at all.

As a result, cros_camera_service starts up with 0 cameras and crashes:

ProbeMediaController(): v4l-subdev node for sensor 'ov8865 2-0010' not found
ProbeMediaController(): v4l-subdev node for sensor 'ov7251 3-0060' not found
OnOptionsUpdated(): Cannot find feature profile as dict for device model "surface-go"
StartOnThread(): Camera module "libcamera camera HALv3 module" has 0 built-in camera(s)
StartOnThread(): SuperHAL started with 2 modules, 0 built-in cameras and 0 unexposed physical cameras
GetInternalModuleAndId(): Invalid camera id: 0
DCHECK failed: ptr_. Task trace:/usr/lib64/libmojo.so(+0xf4812)

Followed by a crash with sig 6 (SIGABRT), caught by crash_reporter.

Also confirmed with plain libcamera, bypassing ChromeOS/cros_camera_service entirely:

$ sudo cam --list
[INFO] Camera camera_manager.cpp:313 libcamera v0.0.0+4804-fc268340-dirty
Available cameras:
(empty)

Reproduction steps

  1. Boot FydeOS 16503.20.22.6 on the Surface Go 1.
  2. Run tail -f /var/log/messages | grep -iE "camera|ipu3|cio2".
  3. Observe that ipu3-cio2 detects and connects 3 sensors via ACPI.
  4. Observe that cros_camera_service finds no v4l-subdev for any of those sensors.
  5. The service crashes with DCHECK failed: ptr_ while trying to process camera id 0 with no camera registered.

Request

Could you investigate why the cio2-bridge is not registering the ov8865/ov7251/ov5693 subdevs as v4l2 devices in this build for surface-go-io, even though the kernel does detect and communicate with the sensors over ACPI/I2C? I’m happy to provide the full /var/log/messages output, complete dmesg output, or run additional diagnostics if useful (media-ctl, v4l2-ctl, etc. — not included in this build, and dev_install currently can’t resolve devserver.fydeos.io from my network).

Thanks in advance.