Re: Something seems weird at main-n287304-8a14fcd23a20

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!


-- 
Guido Falsi <[email protected]>