XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Hi Maik,   
      
   On Mon, Feb 23, 2026 at 03:39:36PM +0100, Maik Nergert wrote:   
   > Package: src:linux   
   > Version: 6.1.162-1   
   > Severity: normal   
   >   
   > Dear Maintainer,   
   >   
   > after upgrading from Linux 6.1.158 to 6.1.162, NFS client writes fail with   
   input/output errors (EIO).   
   >   
   > Environment:   
   > - Debian Bookworm   
   > - Kernel: 6.1.0-43-amd64 (6.1.162-1)   
   > - NFSv4.2 (also reproducible with 4.1)   
   > - Default mount options include rsize=1048576,wsize=1048576   
   >   
   > Reproducer:   
   > dd if=/dev/zero of=~/testfile bs=1M count=500   
   > or   
   > dd if=/dev/zero of=~/testfile bs=4k count=100000   
   >   
   > On different computers and VMs!   
   >   
   >   
   > Result:   
   > dd: closing output file: Input/output error   
   >   
   > Workaround:   
   > Mount with:   
   > rsize=65536,wsize=65536   
   >   
   > With reduced I/O size, the issue disappears completely.   
   >   
   > Impact:   
   > - File writes fail (file >1M)   
   > - KDE Plasma crashes due to corrupted cache/config writes   
   >   
   > The issue does NOT occur on kernel 6.1.0-42 (6.1.158).   
      
   Thanks for your report. I'm currently not able to reproduce it with:   
      
   # echo 1048576 > /proc/fs/nfsd/max_block_size   
   # systemctl restart nfs-server.service   
   # mount -t nfs -o rsize=1048576,wsize=1048576 127.0.0.1:/srv/data /mnt   
      
   127.0.0.1:/srv/data /mnt nfs4 rw,relatime,vers=4.2,rsize=1048576   
   wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=   
   ys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1 0 0   
      
   root@bookworm-amd64:/mnt# dd if=/dev/zero of=testfile bs=4k count=100000   
   100000+0 records in   
   100000+0 records out   
   409600000 bytes (410 MB, 391 MiB) copied, 0.861692 s, 475 MB/s   
   root@bookworm-amd64:/mnt# dd if=/dev/zero of=testfile bs=1M count=500   
   500+0 records in   
   500+0 records out   
   524288000 bytes (524 MB, 500 MiB) copied, 0.907189 s, 578 MB/s   
   root@bookworm-amd64:/mnt# uname -a   
   Linux bookworm-amd64 6.1.0-43-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1   
   (2026-02-08) x86_64 GNU/Linux   
   root@bookworm-amd64:/mnt#   
      
   Is automounting involved in your case?   
      
   I will try bit harder to reproduce, since it seems reliably for you,   
   might you be able to bisect the issue please?   
      
       git clone --single-branch -b linux-6.1.y https://git.kernel.   
   rg/pub/scm/linux/kernel/git/stable/linux-stable.git   
       cd linux-stable   
       git checkout v6.1.158   
       cp /boot/config-$(uname -r) .config   
       yes '' | make localmodconfig   
       make savedefconfig   
       mv defconfig arch/x86/configs/my_defconfig   
      
       # test 6.1.158 to ensure this is "good"   
       make my_defconfig   
       make -j $(nproc) bindeb-pkg   
       ... install the resulting .deb package and confirm the problem does not   
   exists.   
      
       # test 6.1.162 to ensure this is "bad"   
       git checkout v6.1.162   
       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.1.158   
       git bisect bad v6.1.162   
      
   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.   
      
   Thank you already!   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)