On Wed, Jul 08, 2026 at 03:54:28PM +0200, Guido Falsi wrote: > On 7/8/26 15:03, Guido Falsi wrote: > > On 7/8/26 14:52, Guido Falsi wrote: > > > On 7/8/26 14:18, David Wolfskill wrote: > > > > In-place source-based update from: > > > > > > > > FreeBSD 16.0-CURRENT #626 main-n287257-849a51ac8371: Tue Jul 7 > > > > 11:55:43 UTC 2026 > > > > [email protected]:/common/S4/obj/ > > > > usr/src/amd64.amd64/sys/GENERIC amd64 1600019 1600019 > > > > > > > > to: > > > > > > > > FreeBSD 16.0-CURRENT #627 main-n287304-8a14fcd23a20: Wed Jul 8 > > > > 11:08:41 UTC 2026 > > > > [email protected]:/common/S4/obj/ > > > > usr/src/amd64.amd64/sys/GENERIC amd64 1600019 1600019 > > > > > > > > seemed to be uneventful. > > > > > > > > But then, after having run "make delete-old-libs", I tried to use scp to > > > > copy some files over to my Web server (for reference); the copy started, > > > > then stalled (without actually copying anything), and eventually timed > > > > out. This machine uses a wired NIC (em(4)), which has been ... boringly > > > > reliable in the past years.... > > > > > > > > And then a laptop (that I was updating in parallel, and which uses a > > > > wireless (iwn(4)) NIC, exhibited similar (the same?) symptoms. And in > > > > its case (as well as another laptop), it claims xdm is running (as it > > > > should be), but the screen is either blank or black-on-black. Using > > > > Ctl-Alt-F2 gets to a login prompt on ttyv1, as usual. > > > > > > > > I just tried using scp on another (smaller) file, which worked. > > > > And a third file, which started, then reported "scp: Connection > > > > closed" without actualy copying anything. > > > > > > > > So... I just set up an odd little test: I copied /etc/rc.conf (1062 > > > > bytes) to /tmp/test (& chmod u+w), then: > > > > > > > > freebeast(16.0-C)[1] foreach i (`jot 10`) > > > > foreach? ls -lT test && scp test albert:/tmp && cp test{,1} && > > > > cp test{,2} && cat test{1,2} >test > > > > foreach? end > > > > -rw-r--r-- 1 david wheel 1062 Jul 8 04:59:42 2026 test > > > > test 100% 1062 > > > > 2.7MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 2124 Jul 8 05:02:44 2026 test > > > > test 100% 2124 > > > > 2.5MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 4248 Jul 8 05:02:45 2026 test > > > > test 100% 4248 > > > > 3.8MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 8496 Jul 8 05:02:45 2026 test > > > > test 100% 8496 > > > > 8.3MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 16992 Jul 8 05:02:45 2026 test > > > > test 100% 17KB > > > > 20.4MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 33984 Jul 8 05:02:46 2026 test > > > > test 100% 33KB > > > > 30.5MB/s 00:00 > > > > -rw-r--r-- 1 david wheel 67968 Jul 8 05:02:46 2026 test > > > > test 0% 0 > > > > 0.0KB/s - stalled - > > > > > > > > Then I tried again, making "test" smaller (by stripping the full-line > > > > comments), so it started at 667 bytes. It got as far as the 21344-byte > > > > copy OK, but stalled on 42688. > > > > > > > > OK, so then I had the notion to use ktrace to see where it was hanging: > > > > > > > > freebeast(16.0-C)[44] ls -lT test* > > > > -rw-r--r-- 1 david wheel 42688 Jul 8 05:09:45 2026 test > > > > -rw-r--r-- 1 david wheel 21344 Jul 8 05:09:45 2026 test1 > > > > -rw-r--r-- 1 david wheel 21344 Jul 8 05:09:45 2026 test2 > > > > freebeast(16.0-C)[45] ktrace -di scp test albert:/tmp > > > > test 100% 42KB > > > > 24.5MB/s 00:00 > > > > freebeast(16.0-C)[46] scp test albert:/tmp > > > > test 0% 0 > > > > 0.0KB/s --:-- ETA^Cfreebeast(16.0-C)[47] > > > > > > > > Right: so it *works* under ktrace. Of course. OK; I think I'm out of > > > > my depth here: anyone have a clue to offer? > > > > > > > > > > Hi, > > > > > > I'm experiencing the same with head > > > 8a14fcd23a201944f3eb5086403d10cfe1fc128f > > > > > > I don't have any clue (except the ones I already rules out) > > > > > > I'm almost sure this happened recently though, since it was working > > > yesterday with head from a few days ago. > > > > > > I'm also seeing graphic glitches using tmux via ssh to that host > > > that I have never experienced, so I guess they could be correlated. > > > > > > > I'm almost sure 2de20c5c77cf8d5b2059054cff0e0c1fc124739d was good for > > me. I'm now trying to bisect, but I don't know if I have time to > > complete the operation this afternoon. > > > > > > (in advance, not pointing fingers, only reporting findings) > > I performed a bisect on the kernel and the commit breaking it is > dfad790c8ccad05ff603ceaa5b2efe4205b38e1c from kib, sendfile: stop abusing > kern_writev() > > I am unable to provide any insights on why this is the case. > > After bisecting as a further test, I rebuild kernel with the latest commit > but reverting locally only dfad790c8cca and everything is fine again. > > > Hope this helps finding a fix!
Try this commit 6c34a1e68116cfcebd327fbe93bcf0428dec1ae1 Author: Konstantin Belousov <[email protected]> Date: Wed Jul 8 17:54:25 2026 +0300 kern_filewrite(): unconditionally calculate cnt Fixes: dfad790c8cca ("sendfile: stop abusing kern_writev()") diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c index 079bd7b347d7..d5145d6cf322 100644 --- a/sys/kern/sys_generic.c +++ b/sys/kern/sys_generic.c @@ -595,9 +595,9 @@ kern_filewrite(struct thread *td, int fd, struct file *fp, struct uio *auio, #endif cnt = auio->uio_resid; error = fo_write(fp, auio, td->td_ucred, flags, td); + cnt -= auio->uio_resid; #ifdef KTRACE if (ktruio != NULL) { - cnt -= auio->uio_resid; if (error == 0) ktruio->uio_resid = cnt; ktrgenio(fd, UIO_WRITE, ktruio, error);
