From: rschwarzkopf@mathematik.uni-marburg.de   
      
   This is a multi-part message in MIME format.   
   Hi Salvatore,   
      
   On 12/17/25 20:28, Salvatore Bonaccorso wrote:   
   > Hi Roland,   
   >   
   > I'm CC'ing Ben Hutchings directly as well as he takes care of the   
   > Debian LTS kernel updates. Idellly we make this as well a proper bug   
   > for easier tracking.   
   >   
   > On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote:   
   >> Hi there,   
   >>   
   >> after upgrading to the latest kernel on Debian 11   
   >> (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm   
   >> virtual machines and macvtap networking. When a machine is shut down,   
   >> libvirt can not delete the corresponding macvtap device. Thus, starting the   
   >> machine again is not possible. After manually removing the macvtap device   
   >> using `ip link delete` the vm can be started again.   
   >>   
   >> In the journal the following message is shown:   
   >>   
   >> Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device   
   macvtap0: Operation not supported   
   >>   
   >> After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem   
   >> disappears. I tested this on a fresh minimal install of Debian 11 - to   
   >> exclude that anything else on my production machines is causing this issue.   
   >>   
   >> Since the older kernel does not have this issue, I assume this is related to   
   >> the kernel and not to libvirt?   
   >>   
   >> I tried to check for bug reports of the kernel package, but the bug tracker   
   >> finds no reports and even states that the package does not exist (I used the   
   >> "Bug reports" link on   
   >> https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This left   
   >> me a bit puzzled. Since I don't have experience with the debian bug   
   >> reporting process, I had no other idea than writing to this list.   
   > You would need to search for inhttps://bugs.debian.org/src:linux ,   
   > but that said I'm not aware of any bug reports in that direction.   
   >   
   > Would you be in the position of bisecting the problem as you can say   
   > that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do   
   > that that would involve compiling a couple of kernels to narrow down   
   > where the problem is introduced:   
   >   
   >      git clone --single-branch -b linux-5.10.yhttps://git.kern   
   l.org/pub/scm/linux/kernel/git/stable/linux-stable.git   
   >      cd linux-stable   
   >      git checkout v5.10.244   
   >      cp /boot/config-$(uname -r) .config   
   >      yes '' | make localmodconfig   
   >      make savedefconfig   
   >      mv defconfig arch/x86/configs/my_defconfig   
   >   
   >      # test 5.10.244 to ensure this is "good"   
   >      make my_defconfig   
   >      make -j $(nproc) bindeb-pkg   
   >      ... install the resulting .deb package and confirm it successfully   
   boots / problem does not exist   
   >   
   >      # test 5.10.247 to ensure this is "bad"   
   >      git checkout v5.10.247   
   >      make my_defconfig   
   >      make -j $(nproc) bindeb-pkg   
   >      ... install the resulting .deb package and confirm it fails to boot /   
   problem exists   
   >   
   > With that confirmed, the bisection can start:   
   >   
   >      git bisect start   
   >      git bisect good v5.10.244   
   >      git bisect bad v5.10.247   
   >   
   > 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, try to boot / 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.   
      
   I just did my first bisection \o/ (sorry)   
      
   Here are the results:   
      
   git bisect start   
   # bad: [f964b940099f9982d723d4c77988d4b0dda9c165] Linux 5.10.247   
   git bisect bad f964b940099f9982d723d4c77988d4b0dda9c165   
   # good: [863b76df7d1e327979946a2d3893479c3275bfa4] Linux 5.10.244   
   git bisect good f52ee6ea810273e527a5d319e5f400be8c8424c1   
   # good: [dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1] net: usb: lan78xx: Add   
   error handling to lan78xx_init_mac_address   
   git bisect good dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1   
   # bad: [2272d5757ce5d3fb416d9f2497b015678eb85c0d] phy: cadence: cdns-dphy:   
   Enable lower resolutions in dphy   
   git bisect bad 2272d5757ce5d3fb416d9f2497b015678eb85c0d   
   # bad: [547539f08b9e3629ce68479889813e58c8087e70] ALSA: usb-audio: fix control   
   pipe direction   
   git bisect bad 547539f08b9e3629ce68479889813e58c8087e70   
   # bad: [3509c748e79435d09e730673c8c100b7f0ebc87c] most: usb: hdm_probe: Fix   
   calling put_device() before device initialization   
   git bisect bad 3509c748e79435d09e730673c8c100b7f0ebc87c   
   # bad: [a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0] net: add ndo_fdb_del_bulk   
   git bisect bad a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)