XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Control: tags -1 + moreinfo upstream   
      
   Hi Benoît,   
      
   On Thu, Dec 18, 2025 at 09:37:32PM +0100, Benoît Rouits wrote:   
   > Package: src:linux   
   > Version: 6.17.11-1   
   > Severity: normal   
   > File: /usr/share/bug/linux-image-6.17.11+deb14-amd64/presubj   
   > X-Debbugs-Cc: debian-amd64@lists.debian.org, brouits@free.fr   
   > User: debian-amd64@lists.debian.org   
   > Usertags: amd64   
   >   
   > Dear Maintainer,   
   >   
   > I am experiencing a regression in linux image 6.17.11 (works with image   
   6.17.9)   
   >   
   >    * What led up to the situation?   
   >   
   > Trying to use the webcam with e.g. firefox (or qv4l2 for testing purpose)   
   >   
   >    * What exactly did you do (or not do) that was effective (or   
   >      ineffective)?   
   >   
   > Went to a video chat site (medical in my case).   
   >   
   >    * What was the outcome of this action?   
   >   
   > firefox did not ask permissions for integrated webcam video capture, and no   
   > capture was possible.   
   >   
   >    * What outcome did you expect instead?   
   >   
   > firefox to display a popup for accepting webcam capture, and use the webcam.   
   >   
   >   
   > When using qv4l2, the capture is a black screen.   
   >   
   > various CLI checks:   
   >   
   > $ lsusb | grep -i uvc   
   > Bus 002 Device 003: ID 13d3:5205 IMC Networks USB2.0 UVC 2M WebCam   
   >   
   > $ sudo dmesg | grep uvcvideo   
   > [    7.733171] usbcore: registered new interface driver uvcvideo   
   > [ 1027.557731] uvcvideo 2-1.2:1.1: Failed to resubmit video URB (-1).   
   > [ 1027.557798] uvcvideo 2-1.2:1.1: Failed to resubmit video URB (-1).   
   >   
   > $ v4l2-compliance | grep -5 "fail:"   
   >   
   > Control ioctls (Input 0):   
   >         test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK   
   >         test VIDIOC_QUERYCTRL: OK   
   >         test VIDIOC_G/S_CTRL: OK   
   >                 fail: v4l2-test-controls.cpp(980): ret != EINVAL (got 13)   
   >         test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL   
   >         test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK   
   >         test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)   
   >         Standard Controls: 12 Private Controls: 0   
   >   
   > If you need the same CLI output on the working linux image 6.17.9 for   
   > comparison, or other CLI outputs, just ask me.   
      
   First of all as we will upload soon the last version from the 6.17.y   
   series, 6.17.13 and then move to 6.18.y there is no much point into   
   analyzing if the issue is gone with 6.18.2. Thus, can you please test   
   6.18.2-1~exp1 as uploaded to experimental and check if the problem   
   persist?   
      
   If yes, and given you are able to reproduce the behaviour   
   consistently, it would be great if you can bisect the problem between   
   the two good and bad versions. Then we can report the problem upstream   
   (and know it affects still 6.18.2). So that would involve compiling   
   and testing a few kernels:   
      
       git clone --single-branch -b linux-6.17.y https://git.kernel   
   org/pub/scm/linux/kernel/git/stable/linux-stable.git   
       cd linux-stable   
       git checkout v6.17.9   
       cp /boot/config-$(uname -r) .config   
       yes '' | make localmodconfig   
       make savedefconfig   
       mv defconfig arch/x86/configs/my_defconfig   
      
       # test 6.17.9 to ensure this is "good"   
       make my_defconfig   
       make -j $(nproc) bindeb-pkg   
       ... install the resulting .deb package and confirm problem does not exist   
      
       # test 6.17.11 to ensure this is "bad"   
       git checkout v6.17.11   
       make my_defconfig   
       make -j $(nproc) bindeb-pkg   
       ... install the resulting .deb package and confirm problem exists   
      
   With that confirmed, the bisection can start:   
      
       git bisect start   
       git bisect good v6.17.9   
       git bisect bad v6.17.11   
      
   In each bisection step git checks out a state between the oldest   
   known-bad and the newest known-good commit. In each step test using:   
      
       make my_defconfig   
       make -j $(nproc) bindeb-pkg   
       ... install, verify if problem exists   
      
   and if the problem is hit run:   
      
       git bisect bad   
      
   and if the problem doesn't trigger run:   
      
       git bisect good   
      
   . Please pay attention to always select the just built kernel for   
   booting, it won't always be the default kernel picked up by grub.   
      
   Iterate until git announces to have identified the first bad commit.   
      
   Then provide the output of   
      
       git bisect log   
      
   In the course of the bisection you might have to uninstall previous   
   kernels again to not exhaust the disk space in /boot. Also in the end   
   uninstall all self-built kernels again.   
      
   Let us know on both first 6.18.2 (and then you can actually stop) or   
   if it still present, if you can identify a breaking commit with the   
   bisect procedure.   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)