Skip to content
This repository has been archived by the owner on Nov 8, 2024. It is now read-only.

Camera reset fails on Dell XPS 9315 #51

Open
gaul opened this issue Oct 7, 2024 · 9 comments
Open

Camera reset fails on Dell XPS 9315 #51

gaul opened this issue Oct 7, 2024 · 9 comments

Comments

@gaul
Copy link

gaul commented Oct 7, 2024

I tried to follow the Hans de Goede's instructions but the driver cannot reset the hardware:

[   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

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?

@twouters
Copy link

twouters commented Oct 8, 2024

Same, but slightly different output on my XPS 9315

# dmesg -T | grep vsc
[Tue Oct  8 13:14:23 2024] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
[Tue Oct  8 13:14:23 2024] intel_vsc intel_vsc: hw_reset failed ret = -110
[Tue Oct  8 13:14:24 2024] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: hw_reset failed ret = -110
[Tue Oct  8 13:14:24 2024] vsc-tp spi-INTC1094:00: wait rom failed ret: -110
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: hw_reset failed ret = -110
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: reset failed ret = -19
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: link layer initialization failed.
[Tue Oct  8 13:14:24 2024] intel_vsc intel_vsc: error -ENODEV: init hw failed

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

[   12.665856] vsc-tp spi-INTC1094:00: probe with driver vsc-tp failed with error -22

@jwrdegoede
Copy link
Contributor

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 ?

@twouters
Copy link

For me, it happens every reboot.

I did boot from Ubuntu in between, and the camera works/worked in Ubuntu 24.04.
I'm not able to troubleshoot at this time and forgot the last successful Ubuntu kernel version I've booted. I'll post an update on this later.

@jwrdegoede
Copy link
Contributor

For me, it happens every reboot.

Ah I just noticed this bit in your prior comment:

On Arch Linux there's much less info, maybe Fedora patched the kernel with some additional debugging

[ 12.665856] vsc-tp spi-INTC1094:00: probe with driver vsc-tp failed with error -22

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?

@twouters
Copy link

twouters commented Oct 16, 2024

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.

dmesg.ubuntu.txt

Rebooted into Fedora afterwards and it still shows the same errors.

@gaul
Copy link
Author

gaul commented Oct 16, 2024

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.

jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Oct 17, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Oct 23, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Oct 25, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Oct 25, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 3, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 4, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 4, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 5, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 6, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 6, 2024
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]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this issue Nov 6, 2024
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]>
jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Nov 7, 2024
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]>
@jwrdegoede
Copy link
Contributor

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 on Fedora 41 please give this kernel a try and report back here if this helps with the VSC not probing issue.

@jwrdegoede
Copy link
Contributor

The test kernel has completed building and is available for download here now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=125591567

@gaul
Copy link
Author

gaul commented Nov 7, 2024

I installed the new kernel and rebooted but the error remains:

$ uname -a
Linux xps 6.11.6-300.ipu6.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov  7 14:45:32 UTC 2024 x86_64 GNU/Linux

$ sudo dmesg | grep vsc
[   10.949657] intel_vsc intel_vsc: hw_reset failed ret = -22
[   10.988899] intel_vsc intel_vsc: hw_reset failed ret = -22
[   11.027140] intel_vsc intel_vsc: hw_reset failed ret = -22
[   11.027151] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device
[   11.027155] intel_vsc intel_vsc: reset failed ret = -19
[   11.027157] intel_vsc intel_vsc: link layer initialization failed.
[   11.027159] intel_vsc intel_vsc: error -ENODEV: init hw failed

Can I share any other useful debugging info?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants