Some users are reporting non working IPU6 cameras on the XPS 9315 caused by the following errors: [ 11.336391] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 11.377183] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 11.415463] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 11.415493] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 11.415502] intel_vsc intel_vsc: reset failed ret = -19 [ 11.415506] intel_vsc intel_vsc: link layer initialization failed. [ 11.415509] intel_vsc intel_vsc: error -ENODEV: init hw failed This appears to be a different issue from the -110 / ETIMEDOUT issue from bug 2316918. I've submitted a patch upstream to add some better error logging for this: https://lore.kernel.org/lkml/20241108151234.36884-1-hdegoede@redhat.com/ Here is a Fedora test kernel which includes this patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=125626930 Testing instructions (unchanged): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt If you are seeing this issue with the -22 errors, please give this a spin, let me know how things go and please collect: dmesg | grep vsc output after booting the new kernel. Reproducible: Always
I tested this kernel and it still fails but shows new debugging logs that Hans added: $ uname -a Linux xps 6.11.6-301.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 8 13:29:16 UTC 2024 x86_64 GNU/Linux $ sudo dmesg | grep intel_vsc [ 13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 13.367970] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 13.367977] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 13.524948] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 13.524955] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 13.524973] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 13.524977] intel_vsc intel_vsc: reset failed ret = -19 [ 13.524978] intel_vsc intel_vsc: link layer initialization failed. [ 13.524980] intel_vsc intel_vsc: error -ENODEV: init hw failed
(In reply to Andrew Gaul from comment #1) > I tested this kernel and it still fails but shows new debugging logs that > Hans added: > > $ uname -a > Linux xps 6.11.6-301.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 8 > 13:29:16 UTC 2024 x86_64 GNU/Linux > > $ sudo dmesg | grep intel_vsc > [ 13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 > [ 13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22 > [ 13.367970] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 > [ 13.367977] intel_vsc intel_vsc: hw_reset failed ret = -22 > [ 13.524948] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 > [ 13.524955] intel_vsc intel_vsc: hw_reset failed ret = -22 > [ 13.524973] intel_vsc intel_vsc: reset: reached maximal consecutive > resets: disabling the device > [ 13.524977] intel_vsc intel_vsc: reset failed ret = -19 > [ 13.524978] intel_vsc intel_vsc: link layer initialization failed. > [ 13.524980] intel_vsc intel_vsc: error -ENODEV: init hw failed Ok, so this is not really where I expected things to fail, but still good to know that this is where it fails. The only reason I can think of why this can happen (but I'm no intel_vsc expert, that code was all written by Intel) is some timing issue with us reading back the answer before the VSC is ready resulting in the unexpected 0 token value. So I have made us wait a bit longer for the VSC to come out of reset when it is reset during probe() and added some short sleeps between the command we send and the CMD_GETCONT follow-up cmd we send after that to get the response. Hopefully this will help. A test kernel with these delays added is now building here: https://koji.fedoraproject.org/koji/taskinfo?taskID=125791183 Note the build typically takes a couple of hours to complete. Testing instructions (unchanged): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Please give this new test-kernel a spin, let me know how things go and please collect: dmesg | grep vsc output again.
This build failed with: drivers/misc/mei/vsc-fw-loader.c:325:9: error: implicit declaration of function ‘msleep’ [-Wimplicit-function-declaration] 325 | msleep(20);
(In reply to Andrew Gaul from comment #3) > This build failed with: > > drivers/misc/mei/vsc-fw-loader.c:325:9: error: implicit declaration of > function ‘msleep’ [-Wimplicit-function-declaration] > 325 | msleep(20); My bad I forgot to do a local test-build of the patch before submitting it to the buildsystem. A new fixed kernel with the delays which hopefully fix things added is now building here: https://koji.fedoraproject.org/koji/taskinfo?taskID=125813843 As usual this should be done in a couple of hours.
The build is done now and this time it did succeed.
I tested the latest kernel but the added sleep doesn't seem to change the outcome: $ uname -a Linux xps 6.11.7-300.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 13 12:18:00 UTC 2024 x86_64 GNU/Linux $ sudo dmesg | grep vsc [ 65.373768] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 65.373775] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 65.780272] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 65.780291] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 66.182195] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 66.182212] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 66.182240] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 66.182249] intel_vsc intel_vsc: reset failed ret = -19 [ 66.182252] intel_vsc intel_vsc: link layer initialization failed. [ 66.182256] intel_vsc intel_vsc: error -ENODEV: init hw failed
Thank you for testing. I'm afraid that I'm all out of ideas. I have asked a couple of people from Intel to take a look at this.
I'm hitting similar issue. On my setup on Dell XP 9340 [ 6.168577] vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22 I'm not entirely sure if it is the same problem, but at least according to this comment: https://github.com/intel/ivsc-driver/issues/51#issuecomment-2399836830 it's diffrent manifestation of the same issue. My full dmesg on 6.12-rc6 kernel is here: https://gist.github.com/sgruszka/b067d7d09baafdec72135cd2d3e2ccc4 The vsc-tp probe fail at request_threaded_irq() because spi->irq is -EPROBE_DEFER. So something is wrong with initializing SPI device from ACPI description.
(In reply to Stanislaw Gruszka from comment #8) > I'm hitting similar issue. On my setup on Dell XP 9340 > > [ 6.168577] vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with > error -22 > > I'm not entirely sure if it is the same problem, but at least according to > this comment: > https://github.com/intel/ivsc-driver/issues/51#issuecomment-2399836830 > > it's diffrent manifestation of the same issue. > > My full dmesg on 6.12-rc6 kernel is here: > https://gist.github.com/sgruszka/b067d7d09baafdec72135cd2d3e2ccc4 > > The vsc-tp probe fail at request_threaded_irq() because spi->irq is > -EPROBE_DEFER. > > So something is wrong with initializing SPI device from ACPI description. Ah that sounds like it is a probe() timing issue rather then what users are seeing on the XPS9315. I think that you are hitting a race where the ljca GPIO driver has not loaded yet at the time that the GPIO lookup (+ IRQ translation) is done in drivers/spi/spi.c in acpi_register_spi_device() when setting spi->irq and there is no check done for -EPROBE_DEFER there. Even if such a check was added there I'm not sure when acpi_register_spi_device() would get re-called then since it is not a normal device probe() function. One possible fix is to check for spi->irq == -EPROBE_DEFER in drivers/misc/mei/vsc-tp.c probe() before requesting the IRQ and then redo the acpi_dev_gpio_irq_get(adev, 0); call there and return -EPROBE_DEFER from vsc_tp_probe() if spi->irq is still -EPROBE_DEFER after that. This is not a nice fix, but I would start with trying that to confirm that this is a probe() ordering issue.
After a second look: in the dt/of case the IRQ lookup is done in spi_probe() so the proper fix would be to move the ACPI acpi_dev_gpio_irq_get(adev, 0) call there too and then return -EPROBE_DEFER there if the lookup returns that just like the dt/of code path does.
Created attachment 2059082 [details] Proposed fix for spi probing issue Tested this patch and camera sensor now is detected on XPS 9340 [ 15.753192] intel-ipu6 0000:00:05.0: FW version: 20230925 [ 15.755880] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 [ 15.756142] intel-ipu6 0000:00:05.0: Connected 1 cameras
(In reply to Stanislaw Gruszka from comment #11) > Created attachment 2059082 [details] > Proposed fix for spi probing issue > > Tested this patch and camera sensor now is detected on XPS 9340 > > [ 15.753192] intel-ipu6 0000:00:05.0: FW version: 20230925 > [ 15.755880] intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00 > [ 15.756142] intel-ipu6 0000:00:05.0: Connected 1 cameras Great, thank you. About the patch with this change you can also drop the acpi_dev_gpio_irq_get() call from acpi_register_spi_device() since spi_probe() now takes care of this. With the dropping of acpi_dev_gpio_irq_get() from acpi_register_spi_device() squashed in I believe this patch is ready for upstream, can you submit it upstream please with me in the Cc ?
Just built a plain 6.12 with just the proposed patch but it doesn't seem to fix it on my 9315 (Arch Linux though) Nov 21 23:21:10 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 Nov 21 23:21:10 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset failed ret = -19 Nov 21 23:21:11 kernel: intel_vsc intel_vsc: link layer initialization failed. Nov 21 23:21:11 kernel: intel_vsc intel_vsc: error -ENODEV: init hw failed
(In reply to Thomas from comment #13) > Just built a plain 6.12 with just the proposed patch but it doesn't seem to > fix it on my 9315 (Arch Linux though) > > Nov 21 23:21:10 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > Nov 21 23:21:10 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 > Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 > Nov 21 23:21:11 kernel: vsc-tp spi-INTC1094:00: wait rom failed ret: -110 > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: hw_reset failed ret = -110 > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset: reached maximal > consecutive resets: disabling the device > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: reset failed ret = -19 > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: link layer initialization > failed. > Nov 21 23:21:11 kernel: intel_vsc intel_vsc: error -ENODEV: init hw failed I just noticed Hans' comment where it's stated that -110 is a different issue.
> I just noticed Hans' comment where it's stated that -110 is a different issue. Right this is being tracked in bug 2316918 instead. I hope (but do not have confirmation yet) that this is fixed by these 2 patches: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=5c5d8eb8af06df615e8b1dc88e5847196c846045 https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=2481af79671a6603fce201cbbc48f31e488e9fae Another patch which might help is: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next&id=49988a7975420eb206c783f8a384458aae85d938 Maybe you can build a kernel with those 3 patches and see if they help ?\ Please report your results in bug 2316918 .
(In reply to Hans de Goede from comment #15) > Right this is being tracked in bug 2316918 instead. Never mind I see that you have already found your way to bug 2316918 and that you have already added the patches.
I have been poking at the ivsc -ETIMEOUT issue tracked in bug 2316918 and I have fix for this now. gkh has queued that 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 that fix is on its way to Linus' tree. I think / hope that the fix might explain this bug too. The fix is about the 'ready' signal from the VSC to the host getting inverted, which means that we could be talking the VSC before it is ready which explains why we're seeing an all 0 reply. I have submitted pull-requests to get the -ETIMEOUT fix added to Fedora kernel builds: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3704 https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3705 And this Fedora kernel already has 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/ For Arch users there is a pkg with the fix added available here: https://github.com/twouters/kernel-images/tree/f83806f6d6c5708d4ddf825340d3c0dbf428bba1/works if you have any questions about the Arch pkg please ask them in bug 2316918 where this pkgbuild was provided by Thomas.
I tested with the suggested kernel but still see an error: $ sudo dmesg | grep vsc [ 21.760792] intel_vsc intel_vsc: silicon stepping version is 0:2 [ 38.503336] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110 $ uname -a Linux xps 6.13.3-201.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Feb 19 18:56:15 UTC 2025 x86_64 GNU/Linux
(In reply to Andrew Gaul from comment #18) > I tested with the suggested kernel but still see an error: > > $ sudo dmesg | grep vsc > [ 21.760792] intel_vsc intel_vsc: silicon stepping version is 0:2 > [ 38.503336] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: > switch camera to host failed: -110 That actually is pretty good news, because this means that we are getting past the -EINVAL errors: [ 13.206867] intel_vsc intel_vsc: CMD_GETCONT error 0 token 0 [ 13.206875] intel_vsc intel_vsc: hw_reset failed ret = -22 which we were seeing before. Can you try if this -ETIMEOUT is a transient error? So try from the camera a second time. Or reboot the machine twice in a row so that the error does not trigger at all ? and then try after the second reboot. Maybe the ivsc was still in a confused state from the problems we were having before. If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines.
Correction the new "switch camera to host failed: -110" error does not happen when trying to start streaming from the camera, but rather at probe() time of the ivsc-ace.ko driver. 2 things to try: 1. Maybe a simple reboot / power-cycle clears the error ? 2. blacklist the ivsc-ace driver / kernel-module and then reboot, so that the ivsc gets initialized + reset on reboot with triggering any errors then reboot a second time and after the second reboot manually probe "ivsc-ace" by running "modprobe ivsc-ace"
I rebooted and tried again a few times with a newer kernel with the same results: $ uname -a Linux xps 6.13.4-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Feb 22 16:09:10 UTC 2025 x86_64 GNU/Linux $ sudo dmesg | grep vsc [ 19.341673] intel_vsc intel_vsc: silicon stepping version is 0:2 [ 35.958641] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110 One interesting thing is that https://mozilla.github.io/webrtc-landing/gum_test.html does not show any cameras but Google Meet actually detects the MIPI camera now (see attachment). The latter starts with "Camera is starting" but times out and displays "Camera is off".
Created attachment 2077889 [details] Google Meet with XPS 9315
Re-reading your comment, I blacklisted the module, rebooted, then modprobed with the same result: $ sudo dmesg | tail [ 29.696550] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 30.199920] fs-verity: sha256 using implementation "sha256-ni" [ 30.965096] rfkill: input handler disabled [ 31.608939] Bluetooth: RFCOMM TTY layer initialized [ 31.608948] Bluetooth: RFCOMM socket layer initialized [ 31.608955] Bluetooth: RFCOMM ver 1.11 [ 31.794614] usb 3-3: reset full-speed USB device number 3 using xhci_hcd [ 37.735787] rfkill: input handler enabled [ 38.925530] rfkill: input handler disabled [ 104.036804] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110
I do have a setup similar to @gaul, an xps 9315 and I do have a similar error message in dmesg: ``` $ sudo dmesg | grep vsc [ 12.383641] intel_vsc intel_vsc: silicon stepping version is 0:2 [ 28.774551] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: switch camera to host failed: -110 ``` I had never been able to setup the camera, but many of my coworkers do have the same laptop and same os configuration and have a perfectly fine camera. I'm using nixos, but I can try a redhat install if required. ``` $ uname -a Linux gecko 6.14.3 #1-NixOS SMP PREEMPT_DYNAMIC Sun Apr 20 08:23:22 UTC 2025 x86_64 GNU/Linux ``` @hdegoede, I've tried a few of the suggestions: - reboot cycle: I've tried rebooting, full `halt` of the machine and immediate boot, `halt` for hours and then boot. reset of the machine in order to reboot (using magic rescue key). Boot from the bios. Boot after a bios "factory reset", and multiples boot after multiples bios upgrades. Always the same error. - I've tried blacklisting the module + boot / reboot cycle, then `modprobe` in multiples context, no success. > If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines. Do you have released a patch that I can apply on my kernel in order to change the timeout? (Or just point me toward the right file so I can actually build the patch myself if I just need to change an hardcoded value. I'm completely OK to test a 20 minutes timeout if it can somehow work. Anyway, thank you for the time you spent on this topic
(In reply to guillaum.bouchard from comment #24) > ``` > $ sudo dmesg | grep vsc > [ 12.383641] intel_vsc intel_vsc: silicon stepping version is 0:2 > [ 28.774551] ivsc_ace intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: > switch camera to host failed: -110 > ``` We had -ETIMEOUT / -110 errors before but those were different, and those are fixed, see bug 2316918. I have only seen one other bug report with your "switch camera to host failed: -110" error I'm afraid and that is the report if the same error in this bug by Andrew Gaul. Andrew seems to be using Fedora so this is not a NixOS specific issue. No idea about what is actually the issue though I'm afraid. One thing you could try is disable the camera in the BIOS, then boot Linux once with the camera disabled and after that power off the laptop. Then wait 30 seconds, power it back on, re-enable the camera in the BIOS and see if that clears the issue. Disabling + re-enableing the camera in the BIOS was reported by one user to clear some iVSC issues. > > If that does not help I guess we should try extending the timeout (I can prepare a test kernel for this). It seems that the ivsc on your machine is a bit slower to respond to the host then on other machines. I looked at the timeout after writing that and the timeout already is quite long, so do not think that that will help. As mentioned already I'm pretty much out of ideas to fix this.
> One thing you could try is disable the camera in the BIOS, then boot Linux once with the camera disabled and after that power off the laptop. Then wait 30 seconds, power it back on, re-enable the camera in the BIOS and see if that clears the issue. Disabling + re-enableing the camera in the BIOS was reported by one user to clear some iVSC issues. Tried and unfortunately, no success. I'm out of patience with this laptop and I think I will admit that camera will never work. Thank you for the time you took trying to understand and fix the issue.
Hans, I finally have more time to look into this. However I see different symptoms using 6.15.9-201.fc42.x86_64. Both cheese and firefox see the Intel MIPI Camera (V4L2) but I no longer see any kind of vsc messages via dmesg. Can you suggest how I could troubleshoot this further? I can probably iterate building my own kernel module if you have some hypotheses I should try.
(In reply to Andrew Gaul from comment #27) > Hans, I finally have more time to look into this. However I see different > symptoms using 6.15.9-201.fc42.x86_64. Both cheese and firefox see the > Intel MIPI Camera (V4L2) but I no longer see any kind of vsc messages via > dmesg. Can you suggest how I could troubleshoot this further? I can > probably iterate building my own kernel module if you have some hypotheses I > should try. Please apply various kernel cmdline debug options and then collect logs as described here: https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement#How_To_Test and then attach the logs here.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Created attachment 2117906 [details] journalctl -b 0 -k
Created attachment 2117907 [details] ls -l /sys/bus/i2c/devices/
Created attachment 2117908 [details] lsusb
Created attachment 2117909 [details] ls -l /sys/bus/spi/devices/
I enabled the extra debugging flags, retested the gUM page which reports success but no video, and attached the requested log files. Note that I cannot change the Fedora version number but tested this on Fedora 43 with kernel 6.17.10-300.fc43.x86_64.
Hi, I'm not seeing any ipu6 related messages in your journalctl output. Did you at some point have the ipu6 drivers from rpmfusion installed ? If so chances are that you've a /etc/modprobe.d/ipu6-driver-select.conf file as left-over from the rpmfusion drivers. Try removing that file and then rebooting. Hmm, even weirder your lsusb output does not show a ljca USB IO expander chip either. Did you maybe disable the camera in the BIOS ?
Created attachment 2118043 [details] journalctl -b 0 -k
Sorry I had blacklisted the kernel module since I was trying to compile my own IPU6 module. I removed this configuration and re-rested with gUM Test Page with the same result. Relevant logs: Dec 08 14:42:56 xps kernel: intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002) Dec 08 14:43:08 xps kernel: pci 0000:00:05.0: deferred probe pending: intel-ipu6: IPU6 bridge init failed
The module being blacklisted explains why there were no ipu6 messages in your kernel logs. But it does not explain why the LJCA USB IO expander which is used on these laptops does not show in the lsusb output (nor are there any LJCA messages in the kernel logs). Did you check if the camera is not disabled in the BIOS? Also have you tried fully turning the laptop off, then waiting 1 minute and then turning it back on again?
I tried turning the laptop off without power for 1 minute and rebooting. Unfortunately I cannot enter the BIOS and just get a black screen, probably some regression from an LVFS upgrade. I understand your comment about the USB IO expander but Firefox *can* see the uninitialized camera, see attached screenshot.
Created attachment 2118324 [details] Firefox trying to access IPU6
The device in firefox is coming from the v4l2-loopback driver from rpmfusion, that will not work without the kernel being able to access the LJCA chip either. Have you tried entering the BIOS through the enter fwsetup option in grub ? And then after that try loading bios default settings or something like that + save and exit, this will hopefully fix your BIOS issues.
Sorry overlooked the rpmfusion packages! I removed via: sudo rpm -e \ ipu6-camera-bins-0.0-19.20250627git30e8766.fc43.x86_64 \ ipu6-camera-hal-0.0-27.20250627gitc933525.fc43.x86_64 \ kmod-intel-ipu6-6.17.11-300.fc43.x86_64-0.0-24.20250909git4bb5b4d.fc43.x86_64 \ gstreamer1-plugins-icamerasrc-0.0-15.20250325git7f90219.fc43.x86_64 After removing these the gUM test page correctly reports "NotFoundError: The object can not be found here." I tried to enter the Dell BIOS via systemctl reboot --firmware-setup but this hangs with a black screen as well. Something is definitely wrong here since the caps lock has 2 orange lights followed by 7 white lights.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.