Re: Something seems weird at main-n287304-8a14fcd23a20
Date: Wed, 08 Jul 2026 14:55:56 UTC
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
> > > > root@freebeast.catwhisker.org:/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
> > > > root@freebeast.catwhisker.org:/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 <kib@FreeBSD.org>
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);