-
Notifications
You must be signed in to change notification settings - Fork 19
Camera reset fails on Dell XPS 9315 #51
Comments
Same, but slightly different output on my XPS 9315
Maybe the difference is caused by booting from an F41 nightly built live image (Fedora-Workstation-Live-x86_64-41-20241006.n.0.iso) On Arch Linux there's much less info, maybe Fedora patched the kernel with some additional debugging
|
I have been trying to reproduce this on a Dell XPS 13 9320, but I only hit this sporadically and only when doing a cold boot (boot after poweroff and then wait 15 min before powering up again). For me a reboot pretty much always clears these errors. Note I'm not saying that we should not fix them , but without a good reproducer this is going to be hard to fix. @gaul, @twouters does this always happen to you, as in you get these errors every boot even if you reboot a couple of times ? |
For me, it happens every reboot. I did boot from Ubuntu in between, and the camera works/worked in Ubuntu 24.04. |
Ah I just noticed this bit in your prior comment:
Yeah so that is a different error. -22 is -EINVAL. I'm not sure where that is coming from, but I guess it has something to do with some other needed driver not being enabled in Arch's kernel config. Can you attach Arch's kernel config here? |
I've shutdown my laptop for 15 minutes, with detached AC adapter and booted Fedora from a USB flash drive a few times and the above errors occurred on every boot. Eventually rebooted into Ubuntu with 6.8.0-47.47-generic where the webcam works, but I'm not sure if this version uses the upstream ivsc driver. Rebooted into Fedora afterwards and it still shows the same errors. |
My understanding is that the 9315 and 9320 have different cameras despite being released around the same time. I can provide more debugging info from Fedora 41 if it helps. |
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: intel/ivsc-driver#51 Signed-off-by: Hans de Goede <[email protected]>
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: 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): If you are on Fedora 41 please give this kernel a try and report back here if this helps with the VSC not probing issue. |
The test kernel has completed building and is available for download here now: |
I installed the new kernel and rebooted but the error remains:
Can I share any other useful debugging info? |
I tried to follow the Hans de Goede's instructions but the driver cannot reset the hardware:
I am using the upstream version of the driver using kernel 6.11.2-300.fc41.x86_64. Previously I installed the closed-source driver but I believe that I removed all traces of this. Any suggestions on how I can address this problem?
The text was updated successfully, but these errors were encountered: