https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234576
Trenton Hensley changed:
What|Removed |Added
CC||childrenlopside...@gmail.co
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271259
Neil Phillips changed:
What|Removed |Added
CC||tensepeb...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #10 from Rick Macklem ---
I believe the EINTR would be coming from the I/O
operation done by sshfs. For the NFS mounts, it
occurs for "soft" mounts when the NFS server takes
too long to reply to an RPC.
- It was returned by the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277677
--- Comment #1 from Henrich Hartzer ---
Opened a pull request for this:
https://github.com/freebsd/freebsd-src/pull/1161
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278295
Bug ID: 278295
Summary: add net 128.0.0.0: gateway 10.8.1.1 fib 1: Invalid
argument
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235136
Michael Osipov changed:
What|Removed |Added
CC||micha...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #9 from Ivan Rozhuk ---
I suspect that more correct is ignore EINTR error limited times and only then
fallback to generic copy.
So IMHO usage pattern must be one of:
size_t ntry;
const size_t max_ntry = 5;
for (ntry = 0; ntr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #8 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #7)
According to man copy_file_range [1] EINTR also may happen "for files on some
NFS mounts.", so it is not new problem, it is documented behavior.
You may ask au
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #7 from Mark Johnston ---
(In reply to Ivan Rozhuk from comment #6)
Well, I'm not going to commit a patch that works around an unknown problem in
just one utility that happens to use copy_file_range().
I'm not asking you to deb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #6 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #5)
I have no idea why this happen.
I do not try to run cp under ktrace and have no plans to debug whole kernel fs
stack.
My investigation was: "what happen with c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #8 from Vlad Biley ---
(In reply to feh from comment #7)
Hi Erwin,
Thanks for your reply. Here's my story in detail:
https://www.reddit.com/r/freebsd/comments/1b80lpi/gpu_has_fallen_off_the_bus_a_sad_story_about_my/
I wrote t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #7 from f...@fehcom.de ---
Hi Vlad,
thanks for your comment. On my side, there is a bit more history:
a) Before I used the current MiniPC with AMD Ryzen 5, I had a similar device
with Ryzen 7, a Gigabyte BRR7-4800.
b) Here, I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #6 from Vlad Biley ---
(In reply to feh from comment #4)
>finally, there is a pattern: The crash happens moving objects (files) by means
>of Gnome's nemo on the desktop (copy/move files).
Unfortunately (or fortunately?), I ca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #5 from Vlad Biley ---
Created attachment 249875
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249875&action=edit
core.txt
Hi. This is a follow-up to my comment #3. On my previous RX 560 GPU, crashes
happened freque
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
f...@fehcom.de changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
--- Comment #4
15 matches
Mail list logo
