Intel IPU6 camera sometimes fails to stream after boot until v4l2-relayd is restarted
- Dominant language
- C
- Stars
- 51
- Forks
- 47
- PR merge metrics
- No merged PRs in 30d
Description
I'm experiencing a reproducible camera initialization issue on Fedora 44 with Intel IPU6.
The camera hardware is detected correctly after every boot, but applications initially receive no usable video. The interesting part is that the camera always starts working after I force a pipeline reinitialization by switching camera devices inside Cheese.
Hardware
- Lenovo ThinkPad X1 Yoga Gen 8
- Intel Core i7-1370P
- OV2740 camera sensor
- Fedora Workstation 44
- GNOME Wayland
- Secure Boot enabled
Kernel
```
7.1.5-201.fc44.x86_64
```
Installed packages
```
akmod-intel-ipu6-0.0-25.20250909git4bb5b4d.fc44.x86_64
ipu6-camera-hal-0.0-28.20250627gitc933525.fc44.x86_64
ipu6-camera-bins-0.0-20.20250627git30e8766.fc44.x86_64
gstreamer1-plugins-icamerasrc-0.0-16.20250325git7f90219.fc44.x86_64
v4l2-relayd-0.2.0-2.20251028gitd6ec36a.fc44.x86_64
```
Unlike issue #125, the PSYS module is already present and loaded correctly.
Loaded modules:
```
intel_ipu6_psys
intel_ipu6_isys
intel_ipu6
```
Module information:
```
filename:
/lib/modules/7.1.5-201.fc44.x86_64/extra/intel-ipu6/drivers/media/pci/intel/ipu6/psys/intel-ipu6-psys.ko.xz
vermagic:
7.1.5-201.fc44.x86_64 SMP preempt mod_unload
```
The PSYS device also exists:
```
/dev/ipu-psys0
```
Permissions:
```
crw-rw----+ root root
mode 660
```
After boot, the devices look like this:
```
ipu6:
/dev/video1
...
/dev/video32
Intel MIPI Camera (platform:v4l2loopback-000):
/dev/video0
```
The virtual camera exposes:
```
NV12
1280x720
24 fps
```
The behavior is always the same.
Immediately after boot:
- v4l2-relayd is running.
- /dev/video0 exists.
- Cheese opens with a black image.
- Google Meet cannot use the camera.
- Microsoft Teams cannot use the camera.
If I open Cheese, select another camera device, and then switch back to "Intel MIPI Camera", everything immediately starts working.
After doing only that:
- Cheese works.
- Google Meet works.
- Microsoft Teams works.
- Firefox works.
- Chromium works.
The camera keeps working normally until the next reboot.
I can also capture an image successfully after the workaround:
```bash
gst-launch-1.0 -e \
icamerasrc num-buffers=1 \
! jpegenc \
! filesink location=test.jpg
```
The relay service is active:
```
v4l2-relayd@icamerasrc.service
```
using
```
icamerasrc
→ videoconvert
→ v4l2sink
→ /dev/video0
```
During failed initialization I sometimes see these CamHAL messages:
```
Failed to open PSYS, error: Operation not permitted
Failed to initialize Context
create PG 187 error
```
and sometimes kernel messages like:
```
Payload checksum (CRC) error
Multiple packet header errors detected
Incomplete long packet detected
Frame sync error
```
What makes me think this is not a driver installation problem is that the exact same hardware, kernel, modules and userspace stack start working perfectly after the camera pipeline is recreated by Cheese.
Because of that, this seems different from issue #125. In my case:
- PSYS exists.
- The PSYS module is loaded.
- The module matches the running kernel.
- The camera hardware is detected correctly.
- The camera works reliably after the pipeline is reopened.
It feels more like the initial capture pipeline is created too early or is left in an unusable state until an application forces it to be rebuilt.
Has anyone seen this behavior before?
If there are specific CamHAL, icamerasrc or v4l2-relayd debug logs that would help identify the root cause, I'll be happy to collect and provide them.
One additional observation: if I reboot and do nothing, the camera does not work. The very first time I open Cheese and switch to another camera device and back to Intel MIPI Camera, every application immediately starts working without restarting any service or rebooting. This behavior is 100% reproducible on my machine.
This seems related to #125, but I don't think it is the same root cause because the PSYS module is present, loaded and matches the running kernel.
Contributor guide
Research direction
Start with v4l2-relayd@icamerasrc.service and its icamerasrc → videoconvert → v4l2sink pipeline, comparing boot-time behavior with the pipeline recreated by switching devices in Cheese. Collect the CamHAL errors and kernel packet errors during failed initialization, then verify that the camera streams immediately after boot without switching devices or restarting the service.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- audio-video-rtc, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100