In D33996#769676, @jo_bruelltuete.com wrote:

I think this is a good idea. But I'm not in a position to test this right now. I've also never noticed any cancelations. Does your ggatec get a lot of signals?

Looks OK to me

FTR, the MK_USB checks allow this to build successfully on my test system that has WITHOUT_USB="YES"

In general, this is a definite improvement over fixed size buffers (that are actually liable to subtle overruns).

I have been testing with this code for about a week. Other than the problem I identified in g_gatec_connect(), I haven't had any issues. I haven't specifically tried comparing protocols 0 and 1 but protocol 1 should at worst perform the same as protocol 0 and used only half the TCP connections, making it an overall win.

My comments aside, I believe this is worth committing now. Further improvements are needed but this corrects some clear bugs that are relatively easily triggered.

I have been experimenting with zfs send to geli on ggate and had ggatec processes die reporting "ioctl(/dev/ggctl): Cannot allocate memory." and replaced line ggatec.c:134 with the following:

I did some experiments with ggate in late 2019 and was concerned about the lack of sanity checking - I managed to get the client system to generate a 1GiB read request, which the server choked on. From my notes at the time:
4659 ggatec CALL recvfrom(0x4,0xffffbffddf08,0x3ffbc000,0x40<MSG_WAITALL>,0,0)
4659 ggatec RET recvfrom -1 errno 14 Bad address
Unfortunately, I didn't keep a record of how I had generated that request. (And for other reasons, I lost interest in ggate at that time).

Unidirectional data transfer is definitely the worst case for TCP and a single bidirectional socket should work better than two unidirectional sockets whilst using less resources. That said, have you done any performance comparisons between the protocol versions with recent FreeBSD?

(Sorry for the delay. I thought I'd responded). Then I withdraw my objections. The code itself looks good.

I agree this is only applicable to the RK805. The patch works and provides access to the Rock64 LEDs (pin 0 is red and pin 1 is white, with the LED lit when the output is 0). On the downside, and as noted in the description, there is a LOR with led(9). I'm a bit concerned at adding known new LORs to the code. Are there any options for getting rid of the LOR other than redesigning led(9)?

Update ObsoleteFiles with the deleted files.

Rather than cleaning up a dead macro, remove a collection of dead files. This has passed a "make buildworld buildkernel" on amd64. I'm currently running a "make tinderbox"

I can't find any "amd" port. The only automounter-related ports I can find are sysutils/am-utils, sysutils/automount and sysutils/automounter, none of which seem to reference anything in nfs_common.h. It looks like sys/nfs/nfs_common.h, sys/nfsserver/nfsm_subs.h and sys/nfsclient/nfsm_subs.h are all unreferenced - I shall try another "make universe" to check.

Replace diff to include more context

Added context, no changes.

Updated to account for previous comments:

There hasn't been any response by andrew to previous comments and I have a revised patch.

Since I don't seem to be able to update the patch here, I've created D29140 as a replacement that addresses all the comments above.

In D22692#527481, @mmel wrote:

Most boards don't have a battery connected. What happens in this case? I don't see any validity detection in this code

This patch fixes a reproduceable NFS deadlock (deadlres_td_sleep_q panic) I was getting on my diskless Rock64 with recent kernels.

Based on kib's comments, I'll withdraw this revision. r312984 is similar functionality.

In D9306#192355, @rpokala wrote:

Is there any particular reason not to just put them in the build output directory?

Change "LOGDIR" to "UNIVERSE_LOGDIR" to reduce risk of clashes.

I've been bitten in the past by a buffer size change causing unexpected breakage (bin/144446) and would be wary of making this change without extensive testing. The claimed benefit is improved performance - in which case, I'd expect more justification than a single md5 and sha256 test. What does ministat(1) report on 3-5 runs?