On Fri 30/04/2021 00:03, Stefan Sperling wrote:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been identified and fixed i
On Thu, 22 Apr 2021 17:06:00 -0400, Scott Bennett
wrote:
> On Thu, 22 Apr 2021 15:38:53 +0200, Martin Pieuchot wrote:
> > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> > both amd64 and sparc64. That means the kernel lock will only be taken
> > for lower faults and so
Stefan Sperling writes:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been identified and fixed in this version.
> In p
> Date: Tue, 27 Apr 2021 13:34:01 +
> From: Visa Hankala
>
> On Mon, Apr 26, 2021 at 05:25:18PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 26 Apr 2021 14:19:38 +
> > > From: Visa Hankala
> > >
> > > The following diff adds a preliminary driver for the system-level
> > > control regist
On Thu, Apr 29, 2021 at 03:24:42PM -0400, Dave Voutila wrote:
> Found this while running ctags(1)... vioqcow2.c has struct qcheader
> already defined at L53 (which stylistically is where it should be).
>
> This diff just removes the duplicate definition inside
> virtio_qcow2_create().
>
> OK?
>
>
>
This is another patch for Tx aggregation support in iwm(4).
I have tested 7265, 8265, and 9560, and they seem to work.
Causes of various fatal firmware errors from my earlier attempts at
getting this to work have been identified and fixed in this version.
In particular, the AP starting and stoppin
On Thu, Apr 29, 2021 at 09:31:57AM -0700, Greg Steuck wrote:
> Alexander Bluhm writes:
> >> I like this too. I somehow got the impression that macros are severely
> >> frowned upon and didn't offer this kind of interface before.
> >>
> >> If you get this submitted, I can do a pass through the cod
On Tue, Apr 27, 2021 at 01:11:03PM +0200, Stefan Sperling wrote:
> Christian Ehrhardt reported an issue where changes in the ERP protection
> settings in beacons caused noticeable packet loss on iwm(4).
>
> I've found that there are a few parameters in beacons which can change at
> run-time but do
On Tue, Apr 27, 2021 at 03:46:56PM +0200, Stefan Sperling wrote:
> Refactor softraid crypto code to allow use of a discipline-specific data
> structure for RAID1C volumes, as requested by jsing@ during review of my
> initial RAID1C patch.
>
> This patch should effectively be a cosmetic change.
> T
On Tue, Apr 27, 2021 at 03:03:10PM +0200, Stefan Sperling wrote:
> This patch tweaks the heuristic RA is using to decide whether enough
> statistics have been gathered for a candidate Tx rate. The goal is to
> avoid Tx rate choices that might turn out to be too optimistic.
>
> In my testing RA now
Found this while running ctags(1)... vioqcow2.c has struct qcheader
already defined at L53 (which stylistically is where it should be).
This diff just removes the duplicate definition inside
virtio_qcow2_create().
OK?
Index: vioqcow2.c
===
Vincent Lee writes:
> I wasn't aware relative redirects were a thing now! In that case,
> I think this is a better solution than reading X-Forwarded-Proto.
> Thanks for the discussion!
Committed with OK claudio@ off-list. Thanks for pointing this out,
Vincent.
-dv
> Q: would the introduction of SYSCTL_BOOL be considered an improvement
> over "0, 1"?
Absolutely gross and unneccessary.
0-1 is not neccessarily boolean. It remains entirely possible that range
of values is a count.
Alexander Bluhm writes:
>> I like this too. I somehow got the impression that macros are severely
>> frowned upon and didn't offer this kind of interface before.
>>
>> If you get this submitted, I can do a pass through the codebase to be
>> sure we catch them all.
Vitaliy, I volunteer to do a se
On Thu, Apr 22, 2021 at 03:38:53PM +0200, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
> I'd be intereste
Like for rsync repos files in the RRDP repos should be delayed until after
the validation finished. As with anything RPKI related there is little
trust in the repositories and their abilities to not botch an update.
One thing I'm not sure is what should happen if a file is supposed to be
removed b
16 matches
Mail list logo
