Hello,
this bug has been found and reported by Hrvoje@ [1].
I took my chance and asked Hrvoje to test a small diff [2].
I would like to ask for OK to commit this fix which makes
Hrvoje's test box happy. Diff below is same to one found
at bugs@. The thing is that pfsync_bulk_update() function
must
Hello,
This diff looks good to me. Though I still have some
doubts about accuracy of comment here:
> return (kn->kn_data > 0);
> @@ -1510,6 +1599,15 @@ bpf_catchpacket(struct bpf_d *d, u_char
> ++d->bd_dcount;
> return;
> }
> +
> +
I noticed there is an issue in openrsync when a port is specified in the
rsync:// URL, the port number ends up becoming part of the path:
$ openrsync -r rsync://rsync.roa.tohunet.com:3873/repo/ /tmp/r
rsync: [sender] change_dir "/3873/repo" (in repo) failed: No such file or
directory (2)
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Sun, 12 Feb 2023 12:47:56 -0500
>>
>> Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout
>> while doing a bus scan as part of attach. Traced it down to the fact we
>> force polling if the global cold==1 even if the device
_mask: stub
xehp_load_dss_mask: stub
intel_slicemask_from_xehp_dssmask: stub
intel_slicemask_from_xehp_dssmask: stub
i915_resize_lmem_bar: stub
uvm_fault(0x825181f8, 0x10, 0, 1) -> e
screen photo at https://thfr.info/tmp/DG2-error-20230212.jpg
>
> Index: sys/dev/pci/drm/drm_linux.c
>
> From: Dave Voutila
> Date: Sun, 12 Feb 2023 12:47:56 -0500
>
> Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout
> while doing a bus scan as part of attach. Traced it down to the fact we
> force polling if the global cold==1 even if the device reports
> supporting interrupt
Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout
while doing a bus scan as part of attach. Traced it down to the fact we
force polling if the global cold==1 even if the device reports
supporting interrupts. This fixes the issue and lets the bus scan
complete without error.
Th
