1. Please describe the problem: Camera is not detected, while there are references to my machine type in the kernel docs (https://docs.kernel.org/admin-guide/media/ipu6-isys.html) so I suppose it's meant to work. I tested this by booting from a USB flash drive with Fedora Workstation Live x86_64 41 (20241006) and running qcam which did not list my camera device. From dmesg: [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: FW version: 20230925 [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: FW version: 20230925 [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [Mon Oct 7 09:33:01 2024] intel-ipu6 0000:00:05.0: FW version: 20230925 The last two messages just keep repeating and I can't tell what's missing. Seeing the same behavior on Arch Linux with kernel 6.11.2-arch1-1 which I'm currently booted in. 2. What is the Version-Release number of the kernel: 6.11.2-300.fc41.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Did not test 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Download the latest live media from https://openqa.fedoraproject.org/nightlies.html, boot it and the camera is not detected. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Did not test 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
First of all run: ls /sys/bus/i2c/devices and check that there is a i2c-OVTI01A0:xx device there. Note there will also be a OVTI01AB entry there, that is the infrared sensor. The normal sensor not being visible under /sys/bus/i2c/devices typically is caused by something being amiss with the Intel VSC driver which needs to probe the iVSC chip successfully before the main sensor will show up under /sys/bus/i2c/devices. On my own test XPS laptop with iVSC chip sometimes the vsc chip times out during initialization. This typically happens whens witching from a kernel where it was not supported to one where it is supported and then powering the machine on + off clears things. So the first thing to do is to check the output of: sudo dmesg | grep vsc For me this outputs: "intel_vsc: silicon stepping is version is 0:2" If there is some timeout error instead try power-cycling the laptop, booting directly into the livecd after powering the laptop off + on again. If there are no intel_vsc messages in demsg, lets start with checking that the iVSC chip is really there. Please provide the output of "ls -l /sys/bus/spi/devices/" if there is a iVSC chip there this will contain something like: lrwxrwxrwx. 1 root root 0 Oct 31 10:22 spi-INTC1094:00 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8:1.0/ljca-spi.17.auto/spi_master/spi1/spi-INTC1094:00 now lets check if there is a driver bound to the SPI iVSC chip, run: ls -l /sys/bus/spi/devices/spi-INTC... replacing the ... with the name, this should show a driver symlink pointing to a "vsc-tp" driver. And then there should a bunch of intel_vsc-xxxx devices under: ls -l /sys/bus/mei/devices please run: ls -l /sys/bus/mei/devices/intel_vsc-*/ and check that 1 device has a driver symlink pointing to ivsc_ace and 1 other device has a driver symlink pointing to ivsc_csi Also please collect dmesg output (do a reboot if the ringbuffer has overflowed and there are boot messages missing) and run: sudo dmesg > dmesg.txt and attach the dmesg.txt file here in bugzilla.
On Arch Linux I see this: [Mon Oct 7 09:33:01 2024] vsc-tp spi-INTC1094:00: probe with driver vsc-tp failed with error -22 I do see the SPI device: lrwxrwxrwx 1 root root 0 Oct 7 13:32 /sys/bus/spi/devices/spi-INTC1094:00 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/usb_ljca.ljca-spi.0/spi_master/spi1/spi-INTC1094:00 But no intel_vsc devices under /sys/bus/mei/devices I'll shutdown and reboot into F41 in a bit and update with more information.
liveuser@localhost-live:~$ sudo dmesg | grep -i vsc [ 18.804018] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 18.804027] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 19.351063] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 19.351084] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 19.895289] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 19.895317] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 19.895370] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 19.895382] intel_vsc intel_vsc: reset failed ret = -19 [ 19.895387] intel_vsc intel_vsc: link layer initialization failed. [ 19.895392] intel_vsc intel_vsc: error -ENODEV: init hw failed I'll shutdown again and try a new clean boot, at least it's something different than Arch Linux (which I know is irrelevant for this bugreport, I'm just trying to be informative :)).
No i2c-OVTI01A0:xx device in /sys/bus/i2c/devices Same output in dmesg: liveuser@localhost-live:~$ sudo dmesg | grep vsc [ 16.392164] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 16.392173] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 16.931617] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 16.931640] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 17.484246] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 17.484267] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 17.484313] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 17.484321] intel_vsc intel_vsc: reset failed ret = -19 [ 17.484325] intel_vsc intel_vsc: link layer initialization failed. [ 17.484329] intel_vsc intel_vsc: error -ENODEV: init hw failed liveuser@localhost-live:~$ ls -l /sys/bus/spi/devices/ total 0 lrwxrwxrwx. 1 root root 0 Oct 7 07:59 spi2.0 -> ../../../devices/pci0000:00/0000:00:1f.5/spi_master/spi2/spi2.0 lrwxrwxrwx. 1 root root 0 Oct 7 2024 spi-INTC1094:00 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/usb_ljca.ljca-spi.0/spi_master/spi3/spi-INTC1094:00 liveuser@localhost-live:~$ ls -l /sys/bus/spi/devices/spi-INTC1094\:00 lrwxrwxrwx. 1 root root 0 Oct 7 2024 /sys/bus/spi/devices/spi-INTC1094:00 -> ../../../devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/usb_ljca.ljca-spi.0/spi_master/spi3/spi-INTC1094:00 liveuser@localhost-live:~$ ls -l /sys/bus/spi/devices/spi-INTC1094\:00/ total 0 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 driver -> ../../../../../../../../../../bus/spi/drivers/vsc-tp -rw-r--r--. 1 root root 4096 Oct 7 08:00 driver_override lrwxrwxrwx. 1 root root 0 Oct 7 08:00 firmware_node -> ../../../../../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:37/INTC1094:00 -r--r--r--. 1 root root 4096 Oct 7 08:00 modalias drwxr-xr-x. 2 root root 0 Oct 7 08:00 power drwxr-xr-x. 2 root root 0 Oct 7 08:00 statistics lrwxrwxrwx. 1 root root 0 Oct 7 2024 subsystem -> ../../../../../../../../../../bus/spi -rw-r--r--. 1 root root 4096 Oct 7 2024 uevent liveuser@localhost-live:~$ ls -l /sys/bus/mei/devices/ total 0 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-082ee5a7-7c25-470a-9643-0c06f0466ea1 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-082ee5a7-7c25-470a-9643-0c06f0466ea1 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-309dcde8-ccb1-4062-8f78-600115a34327 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-309dcde8-ccb1-4062-8f78-600115a34327 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-3c4852d6-d47b-4f46-b05e-b5edc1aa440e -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-3c4852d6-d47b-4f46-b05e-b5edc1aa440e lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-42b3ce2f-bd9f-485a-96ae-26406230b1ff -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-42b3ce2f-bd9f-485a-96ae-26406230b1ff lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-4fcc395c-a9e5-4647-bc68-47bad7cc6bd3 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-4fcc395c-a9e5-4647-bc68-47bad7cc6bd3 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-55213584-9a29-4916-badf-0fb7ed682aeb -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-55213584-9a29-4916-badf-0fb7ed682aeb lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-5565a099-7fe2-45c1-a22b-d7e9dfea9a2e -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-5565a099-7fe2-45c1-a22b-d7e9dfea9a2e lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-6861ec7b-d07a-4673-856c-7f22b4d55769 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-6861ec7b-d07a-4673-856c-7f22b4d55769 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-8c2f4425-77d6-4755-aca3-891fdbc66a58 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-8c2f4425-77d6-4755-aca3-891fdbc66a58 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-8e6a6715-9abc-4043-88ef-9e39c6f63e0f -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-8e6a6715-9abc-4043-88ef-9e39c6f63e0f lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-cea154ea-8ff5-4f94-9290-0bb7355a34db -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-cea154ea-8ff5-4f94-9290-0bb7355a34db lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-dba4d603-d7ed-4931-8823-17ad585705d5 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-dba4d603-d7ed-4931-8823-17ad585705d5 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-dd17041c-09ea-4b17-a271-5b989867ec65 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-dd17041c-09ea-4b17-a271-5b989867ec65 lrwxrwxrwx. 1 root root 0 Oct 7 08:00 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1 -> ../../../devices/pci0000:00/0000:00:16.0/0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1
Created attachment 2050834 [details] F41 Live Media dmesg
(In reply to Thomas from comment #3) > liveuser@localhost-live:~$ sudo dmesg | grep -i vsc > [ 18.804018] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > [ 18.804027] intel_vsc intel_vsc: hw_reset failed ret = -110 > [ 19.351063] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > [ 19.351084] intel_vsc intel_vsc: hw_reset failed ret = -110 > [ 19.895289] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > [ 19.895317] intel_vsc intel_vsc: hw_reset failed ret = -110 > [ 19.895370] intel_vsc intel_vsc: reset: reached maximal consecutive > resets: disabling the device > [ 19.895382] intel_vsc intel_vsc: reset failed ret = -19 > [ 19.895387] intel_vsc intel_vsc: link layer initialization failed. > [ 19.895392] intel_vsc intel_vsc: error -ENODEV: init hw failed I have seen these too, but for me they have always been intermittent errors, going away after a power-cycle or reboot. I think it is probable best if you file an issue for these with the Intel IVSC driver team. Note make sure that you mention that you are using the upstream version of the driver and which Fedora kernel version you are exactly running. You can file an issue with the Intel IVSC driver team here: https://github.com/intel/ivsc-driver/
There now is an upstream bug for this here: https://github.com/intel/ivsc-driver/issues/51
Hello everyone, Some info: Fedora 41, updated from Fedora 40 GNOME Workstation Dell XPS 13 9315 I upgrade my fedora 40 to fedora 41 yesterday. My webcam Intel IPU6 still not work. The firmware failed with code -2. I have collected some information if it can help you to solve the bug. $ hostnamectl Static hostname: xps-9315 Pretty hostname: XPS-9315 Icon name: computer-laptop Chassis: laptop 💻 Machine ID: 29aab9f533dc4c55806307a13517b1c7 Boot ID: b7458c8ff2024be699b99b02500729d4 Product UUID: 4c4c4544-0056-4c10-8059-c3c04f373234 Operating System: Fedora Linux 41 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:41 OS Support End: Tue 2025-05-13 OS Support Remaining: 6month 1w 4d Kernel: Linux 6.11.5-300.fc41.x86_64 Architecture: x86-64 Hardware Vendor: Dell Inc. Hardware Model: XPS 9315 Hardware Serial: CVLY724 Firmware Version: 1.24.0 Firmware Date: Wed 2024-09-11 Firmware Age: 1month 2w 4d theo@xps-9315 ~ $ sudo dmesg | grep firmware [sudo] Mot de passe de theo : [ 3.391675] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc.bin (v2.20) [ 3.445994] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.29.2 [ 3.446002] i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 [ 4.610757] systemd[1]: systemd-hibernate-clear.service - Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67). [ 5.252168] intel-ipu6 0000:00:05.0: Direct firmware load for intel/ipu/ipu6ep_fw.bin failed with error -2 [ 5.252178] intel-ipu6 0000:00:05.0: error -ENOENT: Requesting signed firmware intel/ipu/ipu6ep_fw.bin failed [ 5.646124] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 5.712480] Bluetooth: hci0: Found device firmware: intel/ibt-0040-0041.sfi``` [ 5.750319] iwlwifi 0000:00:14.3: loaded firmware version 89.6b44fa0b.0 so-a0-gf-a0-89.ucode op_mode iwlmvm [ 5.831919] intel_vsc intel_vsc: Direct firmware load for intel/vsc/ivsc_fw.bin failed with error -2 [ 5.873254] intel_vsc intel_vsc: Direct firmware load for intel/vsc/ivsc_fw.bin failed with error -2 [ 5.916661] intel_vsc intel_vsc: Direct firmware load for intel/vsc/ivsc_fw.bin failed with error -2 [ 7.319029] Bluetooth: hci0: Waiting for firmware download to complete sudo fwupdmgr get-upgrades Devices with no available firmware updates: • VEN 04F3:00 04F3:3242 • Fingerprint Sensor • TPM • UEFI Device Firmware • UEFI Device Firmware Devices with the latest available firmware version: • HD22Q • Package level of Dell dock • RTS5413 in Dell dock • RTS5487 in Dell dock • VMM6210 in Dell dock • 3460 NVMe Micron 512GB • System Firmware • UEFI dbx No updates available $ sudo dmesg | fpaste https://paste.centos.org/view/4c723331
There have also been some issues where sometimes the ov2740 sensor connected to the LJCA IO expander on ThinkPads would not probe / initialize properly. This issue has just been fixed with some LJCA patches and the VSC on the XPS is connected to the LJCA IO expander too. So with some luck those patches will help for this issue too. I have started a Fedora test kernel build with this patch added here: https://koji.fedoraproject.org/koji/taskinfo?taskID=125591567 Note this is still building at the moment, it should be finished in a couple of hours. Here are some generic instructions for installing a kernel directly from koji (Fedora's buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt If you are seeing this issue, please give this kernel a try and report back here if the test kernel fixes things.
The test kernel has completed building and is available for download here now: https://koji.fedoraproject.org/koji/taskinfo?taskID=125591567
Here is a newer test-build which includes one more patch to help debugging ivsc probing errors where people are getting -22 (EINVAL) as error rather then -110 (ETIMEOUT): https://koji.fedoraproject.org/koji/taskinfo?taskID=125626930 This is still building atm, I started it 2 hours ago, so it should be done soonish. Testing instructions (unchanged): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please give this a spin, let me know how things go and please collect: dmesg | grep vsc output after booting the new kernel.
And the new test kernel just completed building: https://koji.fedoraproject.org/koji/taskinfo?taskID=125626930
I've applied the following patches on 6.12.0, none of them fixes the problem for me (I've only rebooted 4 times): https://lore.kernel.org/all/20241031102321.409454-1-stanislaw.gruszka@linux.intel.com/ https://lore.kernel.org/all/20241106220102.40549-1-hdegoede@redhat.com/ https://lore.kernel.org/all/20241108151234.36884-1-hdegoede@redhat.com/ https://lore.kernel.org/all/20241112075514.680712-1-stanislaw.gruszka@linux.intel.com/ https://lore.kernel.org/all/20241112075514.680712-2-stanislaw.gruszka@linux.intel.com/ https://bugzilla.redhat.com/attachment.cgi?id=2059082 I can't really make out which (relevant) patches are included in the above builds, so I don't know if I missed anything.
Story time: Was playing around with adding debug logs to drivers/misc/mei/vsc-tp.c and rebooted a few times, but the camera never appeared. Eventually I broke the driver (booting stalls) by added the following bit above the `atomic_set()` call at https://github.com/torvalds/linux/blob/v6.12/drivers/misc/mei/vsc-tp.c#L518 if (tp->spi->irq < 0) { dev_err(dev, "invalid irq number: %d\n", tp->spi->irq); return tp->spi->irq; } I attempted to boot with this modification a few times and decided to boot with my fall-back kernel, removed these lines, rebuilt the kernel and rebooted into it and *magic*: $ cam -l [0:13:47.925951760] [7205] ERROR IPAModule ipa_module.cpp:171 Symbol ipaModuleInfo not found [0:13:47.925965838] [7205] ERROR IPAModule ipa_module.cpp:291 v4l2-compat.so: IPA module has no valid info [0:13:47.925977583] [7205] INFO Camera camera_manager.cpp:325 libcamera v0.3.2 [0:13:47.935155173] [7206] WARN CameraSensorProperties camera_sensor_properties.cpp:293 No static properties available for 'ov01a10' [0:13:47.935167925] [7206] WARN CameraSensorProperties camera_sensor_properties.cpp:295 Please consider updating the camera sensor properties database [0:13:47.935615848] [7206] WARN IPAProxy ipa_proxy.cpp:160 Configuration file 'ov01a10.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml' [0:13:47.935627444] [7206] WARN IPASoft soft_simple.cpp:114 Failed to create camera sensor helper for ov01a10 Available cameras: 1: Internal front camera (\_SB_.PC00.LNK1) $ sudo dmesg | grep -i -e vsc -e ipu [ 0.005655] ACPI: SSDT 0x000000005D75F000 000150 (v02 INTEL IpuSsdt 00001000 INTL 20200717) [ 14.573814] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) [ 14.574384] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.579806] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.583792] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.586569] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.628707] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.630656] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.631833] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.633923] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.639305] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.641406] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.646379] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.648171] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.670418] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.672794] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.674794] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.676968] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.687230] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.690123] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.792662] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.794502] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.920373] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.921914] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.941692] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.944553] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.974144] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.976941] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 14.985209] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 14.987123] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.042695] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.044359] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.234541] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.236523] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.237248] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.238444] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.244618] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.246260] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.248036] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.249896] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.250604] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.251978] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.261039] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.263150] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.264007] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.265988] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.273959] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.276075] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.276658] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.278388] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.287198] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.291203] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.303357] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.305622] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.309320] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.311754] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.326949] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.329530] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.334891] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.337587] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.340403] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.342644] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.356584] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.359451] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.361726] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.364110] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.447747] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.450635] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.454049] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.456600] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.458292] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.461186] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.463616] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.466490] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.467824] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.470638] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.484677] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.488023] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.489719] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.492533] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.497374] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.499594] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.500477] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.502478] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.532577] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.535200] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.536278] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.538160] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.539189] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.541706] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.584032] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.586791] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.591213] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.594113] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.595468] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.598246] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.667551] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.670705] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.693084] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.695946] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.697148] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.699753] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.700626] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.702520] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.703223] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.705178] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.705836] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.707738] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.709139] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.711725] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.715135] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.719430] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.720963] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.723551] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.725193] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.728083] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.730721] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.733473] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.737190] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.739969] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.742235] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.744998] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.776098] vsc-tp spi-INTC1094:00: Probing device: IRQ=188 [ 15.780958] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.783783] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.835873] intel_vsc intel_vsc: silicon stepping version is 0:2 [ 15.860908] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.863545] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.873130] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.876239] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.913284] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.918175] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.932594] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.935130] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.974915] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 15.977870] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.999548] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 16.002688] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 22.922813] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 22.927108] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 24.816683] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 24.820688] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 26.612399] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 26.619033] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 26.668744] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 26.672455] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 26.678951] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 26.682293] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 26.684635] intel-ipu6 0000:00:05.0: Found supported sensor OVTI01A0:00 [ 26.684870] intel-ipu6 0000:00:05.0: Connected 1 cameras [ 26.687261] intel-ipu6 0000:00:05.0: IPU6-v3[465d] hardware version 5
I've rebooted 3 times now, camera is always detected. Forgot to mention in my previous comment: this is still a build with all mentioned patches applied on 6.12.0 Also interesting: I remember breaking the driver in the same way a few days ago in 6.11 where I also had to reboot in a fallback kernel and undo this change and having a working camera after rebooting. I have no idea about any of this, but maybe the device is put in some broken state on shutdown or when disabling it due to reaching the maximum consecutive resets, which prevents it from properly being activated on boot and when I broke the driver I accidentally prevented it from entering that state?
> I have no idea about any of this, but maybe the device is put in some broken state on shutdown or when disabling it due to reaching the maximum consecutive resets, which prevents it from properly being activated on boot and when I broke the driver I accidentally prevented it from entering that state? Various people have observed the -110 / -ETIMEDOUT errors going away after a power-cycle. Unfortunately it is unknown what exactly causes the iVSC chip to get into its unresponsive state and I myself have also seen the chip be in that state directly after a power-on of the laptop. So we really do not know what is going on atm. Hopefully the ljca + vsc-tp patches help to avoid the chip getting into an unresponsive state again.
I did power-cycle after building with all mentioned patches: turned off my laptop for >15 minutes before starting it again. When I noticed that the camera wasn't detected, I decided to retry every step I made last time I got the camera to work, which was breaking the driver :) and the camera was detected as soon as I rebuilt the kernel to unbreak the driver, without a power-cycle as such, just a simple reboot.
(In reply to Thomas from comment #17) > I did power-cycle after building with all mentioned patches: turned off my > laptop for >15 minutes before starting it again. > > When I noticed that the camera wasn't detected, I decided to retry every > step I made last time I got the camera to work, which was breaking the > driver :) and the camera was detected as soon as I rebuilt the kernel to > unbreak the driver, without a power-cycle as such, just a simple reboot. Not sure if I understand. With all 5 patches from comment 13 plus spi fix from: https://lore.kernel.org/linux-spi/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com/ does is still possible to break ivsc chip ? If so, is possible to determine conditions when it happens and provide steps to reproduce ? Thanks.
(In reply to Stanislaw Gruszka from comment #18) > (In reply to Thomas from comment #17) > > I did power-cycle after building with all mentioned patches: turned off my > > laptop for >15 minutes before starting it again. > > > > When I noticed that the camera wasn't detected, I decided to retry every > > step I made last time I got the camera to work, which was breaking the > > driver :) and the camera was detected as soon as I rebuilt the kernel to > > unbreak the driver, without a power-cycle as such, just a simple reboot. > > Not sure if I understand. > > With all 5 patches from comment 13 plus spi fix from: > https://lore.kernel.org/linux-spi/20241122094224.226773-1-stanislaw. > gruszka.com/ > does is still possible to break ivsc chip ? > > If so, is possible to determine conditions when it happens and provide steps > to reproduce ? > Thanks. No, I don't think it still happens, but I don't know why turning off my laptop didn't unbreak things. I'll rebuild later today and test again.
I just booted Arch Linux 6.12.1 kernel (unpatched): camera not detected. Soft reboot into previous kernel, which was capable of using the camera: camera not detected. Shutdown laptop and waited 5 minutes: camera not detected. Shutdown laptop and removed battery for 5 minutes: camera not detected. So I suppose I'm going to break the driver again, like i did before, boot into that kernel (which will hang), boot into fallback kernel and boot into my current kernel version again.
Right, I should mention: the spi patch you mentioned was not applied yet, maybe I should try that first.
Applied 5 patches from comment #13 + spi fix from https://lore.kernel.org/linux-spi/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com/ Rebooted into patched 6.12.0: no camera detected. Broke the mei driver as mentioned in comment #14 and rebooted, which results in an Oops as expected. Rebooted into fallback kernel and reinstalled the patched 6.12.0 kernel which did not detect the camera earlier: camera works. So does the patched kernel still break the ivsc chip? Maybe? At least it's not able to recover from the broken state until I break the mei_vsc_hw module.
I own a Dell XPS9320 + ov01a10, and I am encoutering this issue as well (vsc-tp failing to probe, hw_reset failed ret = -110) on Arch kernel v6.12.1-arch1-1. I initially did not get this exact issue (I was having some -EINVAL error), but Hans has helped me make some progress on this and I eventually reached this -110 error. The error happens on every boot. I did also run some tests with the v6.12.1-arch1-1 with some patches on top of it, fetched from the mailing list: usb: misc: ljca: move usb_autopm_put_interface() after wait for response usb: misc: ljca: set small runtime autosuspend delay mei: vsc: Do not re-enable interrupt from vsc_tp_reset() media: intel/ipu6: do not handle interrupts when device is disabled spi: Fix acpi deferred irq probe No success so far, the vsc tp probe keeps failing. I have also been trying to reproduce the scenario mentioned above by Thomas (breaking a module, try to boot it, boot back to a fallback kernel, fix driver, boot patched kernel again), but without success so far.
(In reply to Thomas from comment #20) > I just booted Arch Linux 6.12.1 kernel (unpatched): camera not detected. (In reply to Thomas from comment #22) > Applied 5 patches from comment #13 + spi fix from > https://lore.kernel.org/linux-spi/20241122094224.226773-1-stanislaw. > gruszka.com/ > > Rebooted into patched 6.12.0: no camera detected. > > Broke the mei driver as mentioned in comment #14 and rebooted, which results > in an Oops as expected. > > Rebooted into fallback kernel and reinstalled the patched 6.12.0 kernel > which did not detect the camera earlier: camera works. Thomas, could you attach logs for each of those boots, started from unpached 6.12.1. This could be done by something like this - assuming current -0 boot is kernel patched and camera works, (otherwise numbers should be shifted for example: -5,-4,-3,-2 ) . Thanks. journalctl --dmesg --boot -3 > boot-3.txt # unpached journalctl --dmesg --boot -2 > boot-2.txt # patched camera not work journalctl --dmesg --boot -1 > boot-1.txt # oops journalctl --dmesg --boot -0 > boot-0.txt # patched camera works
Created attachment 2059849 [details] dmesg unpatched 6.12.1
Created attachment 2059850 [details] dmesg patched 6.12.0 (first boot, no camera detected)
Created attachment 2059851 [details] dmesg patched 6.12.0 (second boot, shutdown, battery connected, no camera)
Created attachment 2059852 [details] dmesg patched 6.12.0 (third boot, shutdown, battery disconnected, no camera)
Created attachment 2059853 [details] dmesg patched 6.12.0 with spi fix (no camera)
Created attachment 2059854 [details] dmesg fallback kernel 6.6.63 (no camera)
Created attachment 2059855 [details] dmesg patched 6.12.0 with spi fix (camera detected)
(In reply to Stanislaw Gruszka from comment #24) > (In reply to Thomas from comment #20) > > I just booted Arch Linux 6.12.1 kernel (unpatched): camera not detected. > > (In reply to Thomas from comment #22) > > Applied 5 patches from comment #13 + spi fix from > > https://lore.kernel.org/linux-spi/20241122094224.226773-1-stanislaw. > > gruszka.com/ > > > > Rebooted into patched 6.12.0: no camera detected. > > > > Broke the mei driver as mentioned in comment #14 and rebooted, which results > > in an Oops as expected. > > > > Rebooted into fallback kernel and reinstalled the patched 6.12.0 kernel > > which did not detect the camera earlier: camera works. > > Thomas, could you attach logs for each of those boots, started from unpached > 6.12.1. > This could be done by something like this - assuming current -0 boot is > kernel patched and camera works, > (otherwise numbers should be shifted for example: -5,-4,-3,-2 ) . Thanks. > > journalctl --dmesg --boot -3 > boot-3.txt # unpached > journalctl --dmesg --boot -2 > boot-2.txt # patched camera not work > journalctl --dmesg --boot -1 > boot-1.txt # oops > journalctl --dmesg --boot -0 > boot-0.txt # patched camera works Added the logs as requested, but I don't have logs from the OOPS, because the system was not able to start/store the logs.
(In reply to Alexis Lothoré from comment #23) > I own a Dell XPS9320 + ov01a10, and I am encoutering this issue as well > (vsc-tp failing to probe, hw_reset failed ret = -110) on Arch kernel > v6.12.1-arch1-1. I initially did not get this exact issue (I was having some > -EINVAL error), but Hans has helped me make some progress on this and I > eventually reached this -110 error. The error happens on every boot. I did > also run some tests with the v6.12.1-arch1-1 with some patches on top of it, > fetched from the mailing list: > > usb: misc: ljca: move usb_autopm_put_interface() after wait for response > usb: misc: ljca: set small runtime autosuspend delay > mei: vsc: Do not re-enable interrupt from vsc_tp_reset() > media: intel/ipu6: do not handle interrupts when device is disabled > spi: Fix acpi deferred irq probe > > No success so far, the vsc tp probe keeps failing. I have also been trying > to reproduce the scenario mentioned above by Thomas (breaking a module, try > to boot it, boot back to a fallback kernel, fix driver, boot patched kernel > again), but without success so far. I've uploaded my compiled packages on github: https://github.com/twouters/kernel-images I installed the package from the breaker directory, tried to boot but I always have to power down my laptop because it freezes, rebooted into LTS kernel and installed the package from the works directory, reboot and camera is listed when I run `sudo cam -l`: $ sudo cam -l [16:48:25.272405833] [93684] ERROR IPAModule ipa_module.cpp:171 Symbol ipaModuleInfo not found [16:48:25.272416216] [93684] ERROR IPAModule ipa_module.cpp:291 v4l2-compat.so: IPA module has no valid info [16:48:25.272423779] [93684] INFO Camera camera_manager.cpp:325 libcamera v0.3.2 [16:48:25.285855627] [93685] WARN CameraSensorProperties camera_sensor_properties.cpp:293 No static properties available for 'ov01a10' [16:48:25.285866138] [93685] WARN CameraSensorProperties camera_sensor_properties.cpp:295 Please consider updating the camera sensor properties database [16:48:25.286350926] [93685] WARN IPAProxy ipa_proxy.cpp:160 Configuration file 'ov01a10.yaml' not found for IPA module 'simple', falling back to 'uncalibrated.yaml' [16:48:25.286360671] [93685] WARN IPASoft soft_simple.cpp:114 Failed to create camera sensor helper for ov01a10 Available cameras: 1: Internal front camera (\_SB_.PC00.LNK1)
Thanks Thomas. I tried your pkg. I managed to fully boot the breaking kernel but pacman hangs after trying to installed the working kernel. I hard powered it down, rebooted in LTS, installed the working kernel. I booted your working kernel. Bam camera works! I'll attach the dmesg from the breaking kernel.
Created attachment 2059952 [details] dmesg breaking 6.12.0 (cam not working)
Just want to add that the image feels a bit sepia look.
I'm quite confused by this. What seems the oops in vsc_tp_probe() does is we do not touch further vsc hardware. I.e. we do not try to reset the hardware or unwind intialization on EPROBE_DEFFER error. And have to do power cycle. This seems to be some variant of issue that was addressed by: https://lore.kernel.org/all/20240625081047.4178494-1-wentong.wu@intel.com/ But maybe not completely.
Hi all, got pointed here by Stanislaw from https://github.com/intel/ipu6-drivers/issues/302 I have the issue with Latitude 7440/0982JK with OV02C10 Applied all the patches mentioned including the suggested ones without any change in behavior.
I also have the issue, but with the Dell XPS 9640 laptop. I applied all the patches mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2316918#c13 and from https://github.com/intel/ipu6-drivers on top of 6.13-rc1 (and 6.12) without any success. I keep getting the vsc-tp spi-INTC10D0:00: wait rom failed ret: -110 logs in dmesg. Power cycling the laptop does not work for me (or I might doing this wrong...) I am glad to help out with testing and/or providing more information. So please let me know if I can provide anything.
Created attachment 2061891 [details] vsc-tp-gpiod-sleep.patch.txt We are working on reproducing the problem with some success. Looks there is difference on timings of asserting / de-asserting reset gpio between good and bad case. Is possible that adding additional sleeps between setting gpio's will help. Please test this patch.
Created attachment 2061912 [details] dmesg with vsc-tp-gpio-sleep.patch I applied the vsc-tp-gpio-sleep.patch on top of the other patches. It did not result in any changes compared to without, I have the same vsc errors in my dmesg
Created attachment 2061979 [details] dmesg 6.12.4 with vsc-tp-gpiod-sleep.patch Built vanilla 6.12.4 with just the suggested patch (and the IPU6 DMA mapping patch, just to make sure, as I read there could be issues with 6.12.4: https://lore.kernel.org/all/20241209175416.59433-1-stanislaw.gruszka@linux.intel.com/) and same result as comment #41: no camera detected.
Same result here with the vsc-tp-gpio-sleep.patch, still no camera detected, and the same error is present: [ 8.577444] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 8.577447] intel_vsc intel_vsc: CMD_DUMP_MEM error -110 token 0 [ 8.577450] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 9.504469] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 9.504471] intel_vsc intel_vsc: CMD_DUMP_MEM error -110 token 0 [ 9.504473] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 10.430933] vsc-tp spi-INTC1094:00: wait rom failed ret: -110 [ 10.430935] intel_vsc intel_vsc: CMD_DUMP_MEM error -110 token 0 [ 10.430937] intel_vsc intel_vsc: hw_reset failed ret = -110 [ 10.430941] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 10.430942] intel_vsc intel_vsc: reset failed ret = -19 [ 10.430943] intel_vsc intel_vsc: link layer initialization failed. [ 10.430944] intel_vsc intel_vsc: error -ENODEV: init hw failed
Hi, I just wanted to share here that with kernel 6.12.8 (arch) it (hw_reset failed ret = -110 and similar errors) is still happening and I wanted to add a bit more details about when/how it happens: - when it starts happening, then even with powering down, reboot, etc, I never can't make it work again - the only way I found to fix the situation is using the trick from Thomas above (https://bugzilla.redhat.com/show_bug.cgi?id=2316918#c33): restarting on a broken kernel then on a LTS (6.6.69) kernel (which does not have the ipu6/vsc modules at all) and then back on the 6.12.8 kernel - I also tried just restarting on the LTS kernel then back to latest but it does not work, I really need to go through that broken kernel from Thomas - after that it can work for a few reboots then one day stop working again without any good reason I hope this can help :)
Created attachment 2066273 [details] vsc-tp-toggle-reset.patch.txt Hi, this is anther patch to try. It changes the behavior of reset corresponding to to behavior of old out of tree driver https://github.com/intel/ivsc-driver/blob/006b0f5ecb12b262e4c22d7574b441cf4591389c/drivers/misc/mei/hw-vsc.c#L324 There is some chance it can help.
I'm creating list of laptops where the problem happens. XPS 9315, XPS 9640, Latitude 7440, any other laptop ?
With the vsc-tp-toggle-reset.patch I have the same results ("wait rom failed ret: -110", and similar ones) as in my previous attempt (see attachment 2061912 [details] for full/related dmesg log) Dell XPS 9640
With the vsc-tp-toggle-reset.patch I have the same results also Dell XPS 9315
Thanks for testing. One more question ? Are the system when the problem happens dual boot i.e. Windows/Linux , or it happens only when Linux is used ?
(In reply to Stanislaw Gruszka from comment #49) > Thanks for testing. One more question ? Are the system when the problem > happens > dual boot i.e. Windows/Linux , or it happens only when Linux is used ? I tested this yesterday: - booted Windows (from a usb drive) and the camera works in Windows. - rebooted into Arch Linux (6.12.9) afterwards, somewhat expecting the camera to work, but it isn't detected. Ran the same tests after rebuilding the Arch Linux kernel with your last patch and got the same results. I think I can run the same test with Ubuntu (with the proprietary driver) instead of Windows later.
My system is dual booting "enabled". But my tests doesn't include starting Windows. - building the kernel with patch - booting the kernel a first time - booting the kernel a second time Still not working Camera works on Windows but I feel that on some boot it takes time to initialize.
(In reply to Stanislaw Gruszka from comment #49) > Thanks for testing. One more question ? Are the system when the problem > happens dual boot i.e. Windows/Linux , or it happens only when Linux is used ? I only have (Arch) Linux on my laptop. I never tried, but I assume the camera works with Windows, the laptop is only 2 months old.
(In reply to Thomas from comment #50) > (In reply to Stanislaw Gruszka from comment #49) > > Thanks for testing. One more question ? Are the system when the problem > > happens > > dual boot i.e. Windows/Linux , or it happens only when Linux is used ? > > I tested this yesterday: > > - booted Windows (from a usb drive) and the camera works in Windows. > - rebooted into Arch Linux (6.12.9) afterwards, somewhat expecting the > camera to work, but it isn't detected. > > Ran the same tests after rebuilding the Arch Linux kernel with your last > patch and got the same results. > > I think I can run the same test with Ubuntu (with the proprietary driver) > instead of Windows later. Tested with my Ubuntu install, camera works with the intel ipu6 dkms module on 6.11.0-1011-oem and 6.8.0-47-generic. Camera is not detected after subsequent reboots in Arch Linux.
(In reply to Thomas from comment #53) > Tested with my Ubuntu install, camera works with the intel ipu6 dkms module > on 6.11.0-1011-oem and 6.8.0-47-generic. Camera is not detected after > subsequent reboots in Arch Linux. As long this is not some strange issue that happen due to different timings on boot process, seems that some patches are missed upstream that are in ubuntu oem and/or ipu6 external dkms. Would be possible to identify the difference ? I'll ask internally about that also.
(In reply to Stanislaw Gruszka from comment #54) > (In reply to Thomas from comment #53) > > > Tested with my Ubuntu install, camera works with the intel ipu6 dkms module > > on 6.11.0-1011-oem and 6.8.0-47-generic. Camera is not detected after > > subsequent reboots in Arch Linux. > > As long this is not some strange issue that happen due to different timings > on boot process, > seems that some patches are missed upstream that are in ubuntu oem and/or > ipu6 external dkms. > Would be possible to identify the difference ? > > I'll ask internally about that also. Just want to clarify: I did not test the mainlined kernel drivers on Ubuntu, only the intel out-of-tree drivers (dkms)
(In reply to Thomas from comment #55) > (In reply to Stanislaw Gruszka from comment #54) > > (In reply to Thomas from comment #53) > > > > > Tested with my Ubuntu install, camera works with the intel ipu6 dkms module > > > on 6.11.0-1011-oem and 6.8.0-47-generic. Camera is not detected after > > > subsequent reboots in Arch Linux. > > > > As long this is not some strange issue that happen due to different timings > > on boot process, > > seems that some patches are missed upstream that are in ubuntu oem and/or > > ipu6 external dkms. > > Would be possible to identify the difference ? > > > > I'll ask internally about that also. > > Just want to clarify: I did not test the mainlined kernel drivers on Ubuntu, > only the intel out-of-tree drivers (dkms) And after submitting my comment I realize that the 6.11.0 oem kernel should be using the mainlined vsc driver :/
(In reply to Thomas from comment #56) > And after submitting my comment I realize that the 6.11.0 oem kernel should > be using the mainlined vsc driver :/ Yes, vsc-tp driver is upstreamed. From what I can tell there is no difference in vsc-tp between ubuntu and upstream. But please double check that if possible. I can see some possibly related patches, for example this one: https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/noble/commit/?h=oem-6.11-next&id=d06f34bed22104c230bb82f03f594075f2c2a0f3 Another possibility is difference in firmware and kernel config. While the rom timeout error happens before any firmware is loaded by vsc-tp driver, still would be good to check if there is difference in /lib/firmware/intel/vsc/ Or better, backup content of /lib/firmware on Arch, copy /lib/firmware from Ubuntu and test if does it make difference, is possible that some other component firmware has impact here.
Hello, > I'm creating list of laptops where the problem happens. > XPS 9315, XPS 9640, Latitude 7440, any other laptop ? You can add XPS 9320 to the list > Another possibility is difference in firmware and kernel config. > > While the rom timeout error happens before any firmware is loaded by vsc-tp > driver, > still would be good to check if there is difference in > /lib/firmware/intel/vsc/ > Or better, backup content of /lib/firmware on Arch, copy /lib/firmware from > Ubuntu and test > if does it make difference, is possible that some other component firmware > has impact here. I have actually performed this test: I got the /lib/firmware dir from a colleague running Ubuntu, replaced my own with it, and did a reboot: the -110 error is still here. This test has been performed with kernel 6.12.9-arch1, with the few other patches mentioned in this thread on top of it.
(In reply to Stanislaw Gruszka from comment #46) > I'm creating list of laptops where the problem happens. > XPS 9315, XPS 9640, Latitude 7440, any other laptop ? yes, add Dell Precision 5680 to the list:)
(In reply to Stanislaw Gruszka from comment #46) > I'm creating list of laptops where the problem happens. > XPS 9315, XPS 9640, Latitude 7440, any other laptop ? Dell Precision 5490 too. :)
I have been poking at this a bit today and I have a couple of interesting observations: 1. I can sorta reproduce this, but my reproducer does not result in the ivsc being stuck until doing the magic unstuck dance from comment 14. This patch is my reproducer: diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index 35d349fee769..2725adcfceca 100644 --- a/drivers/misc/mei/vsc-tp.c +++ b/drivers/misc/mei/vsc-tp.c @@ -485,6 +485,7 @@ static int vsc_tp_probe(struct spi_device *spi) struct platform_device *pdev; struct acpi_device *adev; int ret; + static int first = 1; tp = devm_kzalloc(dev, sizeof(*tp), GFP_KERNEL); if (!tp) @@ -506,6 +507,12 @@ static int vsc_tp_probe(struct spi_device *spi) if (IS_ERR(tp->wakeuphost)) return PTR_ERR(tp->wakeuphost); + if (first) { + first = 0; + dev_err(dev, "First\n"); + return -EPROBE_DEFER; + } + tp->resetfw = devm_gpiod_get(dev, "resetfw", GPIOD_OUT_HIGH); if (IS_ERR(tp->resetfw)) return PTR_ERR(tp->resetfw); The idea here is that this emulates the LJCA GPIO controller not being ready yet when vsc_tp_probe() runs. This is quite unlikely to actually happen in real life though. Unless maybe when the ljca-SPI driver is build into the kernel and the GPIO driver is a module ? Here is a patch which explains what goes wrong if we return -EPROBE_DEFER once + fixes it: https://lore.kernel.org/lkml/20250214212425.84021-1-hdegoede@redhat.com/T/#u I doubt if this really is the root cause though, as mentioned when I use my reproducer it does not result in the ivsc being stuck the next boot. But maybe this is a combination of the BIOS/firmware not properly resetting things at reboot (I'm at the latest BIOS version) in combination with above bug ? I also noticed that if I do "sudo reboot --force" while having qcam showing the camera picture the privacy LED stays on until Linux loads its camera drivers. This suggests that the iVSC which I believe is the chip driving the privacy LED indeed is not reset by the BIOS on reboots. 2. Another interesting observation which I made while poking at this is the following: Requesting the IRQ results in PADCFG0_RXINV getting set in the PADCFG0 register for the wakeuphost GPIO (and that is the GPIO which we are polling when the timeout happens). If I blacklist mei-vsc-hw + mei-vsc in a /etc/modprobe.d/*.conf file and then look at /sys/kernel/debug/pinctrl/INTC1055:00/pins and then at the line for pin 23 (wakeuphost GPIO) I see 0x82000103 for padcfg0 if mei-vsc-hw is not loaded. After doing "modprobe mei-vsc-hw" this changes to 0x82800103, setting PADCFG0_RXINV which is necessary for negative edge interrupts. Thomas' magic 'fix' broken kernel does request the GPIOs (setting "resetfw" and "PADCFG0_RXINVwakeupfw" both to 1) but then oopses before calling request_irq() and this before setting the PADCFG0_RXINV flag ... and the behavior I saw with the wrong active-low flag (which also inverts the rx value, but then in the kernel) is the exact same behavior as people are seeing when the ivsc is stuck. So possibly the PADCFG0_RXINV flag may have something to do with this...
Lo and behold, the patch worked for me! Applied it on 6.13.3 on Arch Linux and uploaded my modified PKGBUILD with your patch to a git repo for testing purposes: https://github.com/twouters/kernel-images/tree/f83806f6d6c5708d4ddf825340d3c0dbf428bba1/works
I can confirm the kernel Thomas built is also working here (XPS 9315) on first boot. The image is greenish both in Cheese and Firefox.
Created attachment 2077018 [details] dmesg with 'wakeuphostint' patch I rebuild the kernel with the files provided by Thomas in comment 62 and it seems to have fixed the issue with vsc-tp spi-INTC10D0:00: wait rom failed ret: -110 on my XPS 9640. But I now have a whole bunch of ipu6 cameras: v4l2-ctl --list-devices ipu6 (): /dev/video0 /dev/video1 ... /dev/video47 ipu6 (PCI:0000:00:05.0): /dev/media0 but none of them seem to work when I try them with ffplay: $ ffplay /dev/video0 ... [video4linux2,v4l2 @ 0x7a8e2c000c80] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device [video4linux2,v4l2 @ 0x7a8e2c000c80] Time per frame unknown [video4linux2,v4l2 @ 0x7a8e2c000c80] ioctl(VIDIOC_STREAMON): Link has been severed /dev/video0: Link has been severed I have no idea whether this is part of this ticket, or has to do with something else though. For completeness sake I attached my dmesg filtered on vsc and ipu
Thomas, Nicolas, Maarten thank you for testing! In the mean time gkh has queued the fix in char-misc-linus: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-linus&id=fdb1ada57cf8b8752cdf54f08709d76d74999544 so the fix is on its way to Linus' tree. I've also submitted pull-requests to get this added as a downstream patch to the Fedora kernels while we wait for the fix to reach the stable series: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3704 https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3705
Maarten, IPU6 / MIPI cameras are so called complex cameras and these cannot be directly opened by applications as e.g. UVC applications could in the past. In stead libcamera needs to be used, see: https://libcamera.org/introduction.html for some more info about why complex cameras need a userspace abstraction layer (its because they are complex). If you install qcam (part of libcamera) then you should be able to get a picture for testing through that For actually using the camera in applications the plan is to use pipewire and then have e.g. Firefox talk to pipewire to access the camera. This is already working in Fedora, see: https://fedoraproject.org/wiki/Changes/IPU6_Camera_support#How_To_Test for some testing instructions for this, note I'm not sure if other distros like e.g. Arch already have all the necessary bits integrated...
I can confirm also that applying the patch (taken from https://github.com/twouters/kernel-images/tree/f83806f6d6c5708d4ddf825340d3c0dbf428bba1/works) to the LTS version (6.12.15-1-lts here, after a few hours of compiling the kernel, I feel like I'm in the 90s again :D) solves the problem. I too get a green-tinted image, but I guess this is expected with the current state of libcamera support for those devices? I also noticed the booting process stops for a few seconds in the middle of starting all the services (before GDM is shown), I think at the same place where it was previously showing the -110 error. FYI this is what I see in dmesg: $ sudo dmesg | egrep "ipu|vsc" [ 9.465051] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) [ 9.465392] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.473360] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.516396] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.518671] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.527890] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.531602] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.535564] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.539649] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.586422] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.590586] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.630053] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.633807] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.645318] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.648639] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.674108] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.679054] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.743515] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.746092] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.774544] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.778412] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.779410] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.781683] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.787501] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.789700] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.836106] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.838212] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.887939] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.890916] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 9.993703] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 9.996600] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.004552] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.007434] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.017516] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.019457] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.019808] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.021709] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.030359] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.032323] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.051245] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.054230] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.068545] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.072114] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.085285] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.089670] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.090746] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.093979] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.101868] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.105717] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.107152] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.111041] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.126192] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.130239] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.133141] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.136988] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.143127] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.146138] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.149095] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.153330] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.155136] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.159224] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.162351] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.165398] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.171778] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.173148] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.183565] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.185176] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.197721] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.199131] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.203285] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.204682] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.205609] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.207439] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.230808] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.232395] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.276827] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.278432] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.280011] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.281519] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.302952] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.304500] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.357569] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.359061] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.435997] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 10.437425] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 10.585214] intel_vsc intel_vsc: silicon stepping version is 0:2 [ 12.026152] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 12.027405] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.278881] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 21.283410] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.300688] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 21.305767] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.314066] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 21.318928] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.341444] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 21.343087] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.347586] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff [ 21.349251] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 21.350401] intel-ipu6 0000:00:05.0: Found supported sensor OVTI01A0:00 [ 21.350531] intel-ipu6 0000:00:05.0: Connected 1 cameras [ 21.351602] intel-ipu6 0000:00:05.0: IPU6-v3[465d] hardware version 5
> I too get a green-tinted image, but I guess this is expected with the current state of libcamera support for those devices? Yes I think some recent libcamera changes have messed up the white-balance code. I need to look into this one of these days, but there are too many things I need to look into wrt IPU6 support...
> Yes I think some recent libcamera changes have messed up the white-balance code. I need to look into this one of these days, but there are too many things I need to look into wrt IPU6 support... Hehe, at least we get an image, thanks for the hard work already done :)
> If you install qcam (part of libcamera) then you should be able to get a picture for testing through that qcam does not work for me, it has an empty list of cameras and shows: $ qcam [0|0] [0:01:09.575475551] [2297] ERROR IPAModule ipa_module.cpp:171 Symbol ipaModuleInfo not found [0:01:09.575500122] [2297] ERROR IPAModule ipa_module.cpp:291 v4l2-compat.so: IPA module has no valid info [0:01:09.575517325] [2297] INFO Camera camera_manager.cpp:325 libcamera v0.3.2 [0:01:09.593817211] [2307] INFO SimplePipeline simple.cpp:1548 No sensor found for /dev/media0 even when dmesg shows [ 26.457559] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 So I guess there is something missing in libcamera, as the kernel found the sensor. On a (slightly) related note: It took me about 7 tries to reboot in the kernel before dmesg didn't contain this error anymore: [ 22.138911] pci 0000:00:05.0: deferred probe pending: intel-ipu6: IPU6 bridge init failed (nothing else is different compared to my latest dmesg, attachment 2077018 [details]) Since qcam was not working, I wondered whether did happened due to that error. But now that I maanged to boot without it, it did not help. In the end the error was gone when I 'reboot'-ed from a working (unpatched) 6.13.2 kernel, so there might be something in my laptop that is not fully reset on reboot?
The wakeuphostint patch above fixes the webcam on my laptop as well (XPS9320) when applied on top of current Archlinux kernel. Many thanks and kudos to Hans for the hard work on this issue, much appreciated.
I've requested to patch this on the Arch Linux kernel too, but have little hope as patches are often rejected: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/113
> qcam does not work for me, it has an empty list of cameras and shows: > [ 26.457559] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 > So I guess there is something missing in libcamera, as the kernel found the sensor. The kernel / ipu6-driver has found the sensor, but there is no driver in the mainline kernel for that sensor yet. FYI getting that driver merged is being tracked in bug 2333347 you may want to add yourself to the Cc there. There is a v7 posting of the driver upstream which you can try adding to your local kernel build: https://lore.kernel.org/linux-media/20250116232207.217402-1-heimir.sverrisson@gmail.com/ Heimir who has been so kind to work on upstreaming this indicated that he does not have time to address Sakari's review remarks, so I'm working on preparing a v8 submission myself. This is pretty high on my TODO list, so I hope to submit a v8 upstream next week.
> I've requested to patch this on the Arch Linux kernel too, but have little hope as patches are often rejected: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/113 The patch is on its way to Linus' master branch and has a Cc: stable, so it should show up in a 6.12.y and/or 6.13.y release soon anyways.
Good news there now is a Fedora kernel with the fix: https://koji.fedoraproject.org/koji/buildinfo?buildID=2662670 This is going to show up in updates-testing soon, or you can grab it directly from koji to test the fix right away, see: https://docs.fedoraproject.org/en-US/quick-docs/kernel-installing-from-koji/
> The kernel / ipu6-driver has found the sensor, but there is no driver in the mainline kernel for that sensor yet. FYI getting that driver merged is being tracked in bug 2333347 you may want to add yourself to the Cc there. Thanks for pointing this bug out, I CC-ed myself. > There is a v7 posting of the driver upstream which you can try adding to your local kernel build For others with a Dell XPS9640, this (v7) patch works and enabled the camera with libcamera (image quality is subpar, but that seems similar to others here). Hans, thanks a lot for your work on this. I guess we'll see each other in the other bug page for more testing when/if needed.
Included in Arch 6.13.4-arch1 Thanks to everybody that worked on this
Patch is applied on the official Arch Linux kernel image 6.13.4-arch1. Do we close this issue or keep it open until the fix is merged upstream?
Hi, Any idea when (or if?) the patch will be applied upstream to 6.12 LTS? I didn't see it in the latest patch release changelogs :/
(In reply to Victor from comment #79) > Hi, > > Any idea when (or if?) the patch will be applied upstream to 6.12 LTS? I > didn't see it in the latest patch release changelogs :/ Appears to be queued for 6.12.19: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.12?id=bde148ba5d443cb6f7d8957e26cdb7adeacc799e
Thank you Thomas! And now I learned where to look next time :)
The patch fixing this has been in the Fedora kernels for a while now and has now also landed in various stable kernel series upstream. So I believe that it is time to close this bug now.
I do not know if makes sense to open a new one... but I see this bug again on 6.13.8-arch1-1 on a xps 9320 but... work fine on another. all story here https://github.com/intel/ipu6-drivers/issues/288#issuecomment-2785817062 . happy to provide more debug if needed or even open a new bug report.
(In reply to alin from comment #83) > I do not know if makes sense to open a new one... but I see this bug again > on 6.13.8-arch1-1 on a xps 9320 but... work fine on another. all story here > https://github.com/intel/ipu6-drivers/issues/288#issuecomment-2785817062 . > happy to provide more debug if needed or even open a new bug report. Still works on my 9315, so I advise you to open a new bug report if it doesn't work on 9320.
thanks yap, I will open a new one, since I confirmed the issue on fedora also... is not is not working on 9320, is not working on one specific model.