On Tue, Feb 18, 2020 at 11:16:54PM +, Stuart Henderson wrote:
> On 2020/02/18 13:40, Gerhard Roth wrote:
> > > > Yes, I tried MBIM_CONTEXT_IPTYPE_IPV4ANDV6 myself first but to no
> > > > avail. The switched to MBIM_CONTEXT_IPTYPE_IPV4V6 and everything
> > > > was fine.
> > >
> > > Obviously
On 2020/02/18 13:40, Gerhard Roth wrote:
> > > Yes, I tried MBIM_CONTEXT_IPTYPE_IPV4ANDV6 myself first but to no
> > > avail. The switched to MBIM_CONTEXT_IPTYPE_IPV4V6 and everything
> > > was fine.
> >
> > Obviously it needs to switch based on INET6, but with the current
> > mechanism used for
On Mon, Feb 17, 2020 at 05:41:15PM +0100, Stefan Sperling wrote:
> On Mon, Feb 17, 2020 at 05:07:42PM +0100, Claudio Jeker wrote:
> > As already done on iwm(4) and one of the athn(4), there is no need to pass
> > the radio tap structure to bpf_mtap by faking up an mbuf. The code can
> > just use bp
Hi Andrew,
ironically, the patch did not apply for me because you sent it with
Content-Type: text/plain; charset=iso-8859-1
so when i saved it to disk, it remained in ISO-Latin-1.
In the license comment you are changing, there is a U+00A9 COPYRIGHT
SIGN encoded as UTF-8. I suggest you change
Right; the keysym is "question" (M-question), not "slash" with a
shiftmask (MS-slash).
On Tue 2020.02.18 at 07:09 +, Ryan Lennox wrote:
> Good point! I retract the diff, please ignore.
>
> ? Original Message ?
> On Tuesday, February 18, 2020 12:36 AM, M
The following diff makes finishdup() release the file descriptor table
lock before calling closef(). This makes the order of operations similar
to that of fdrelease().
The dup* code still has an issue with file closing that this diff does
not address. If fdalloc() fails in dodup3(), sys_dup() or s
Ingo Schwarze wrote in
<20200218160703.gb27...@athene.usta.de>:
|Hi,
|
|Steffen Nurpmeso wrote on Tue, Feb 18, 2020 at 04:52:48PM +0100:
|
|> i just want to add that there is still the mdocmx mdoc macro
|> extension available, and is working fine for more than half
|> a decade. I have not p
Hi,
Steffen Nurpmeso wrote on Tue, Feb 18, 2020 at 04:52:48PM +0100:
> i just want to add that there is still the mdocmx mdoc macro
> extension available, and is working fine for more than half
> a decade. I have not ported that to groff 1.22.4, but it is
> available for groff 1.22.3. It can mu
Hello.
I have not followed this thread but
Ingo Schwarze wrote in
<20200218153053.ga27...@athene.usta.de>:
|Klemens Nanni wrote on Mon, Feb 17, 2020 at 05:19:27PM +0100:
|
|> I'd like to commit this soon, it allows me to jump to the command I'm
|> looking for, e.g. ":tx509" shows me the synop
> Date: Tue, 18 Feb 2020 15:08:49 +0100
> From: Martin Pieuchot
>
> ends up being included by 532 files. On amd64 this
> represents almost 1/3 of the 1674 kernel source files. So any change
> in a header it includes will result in a large number of rebuild.
>
> is one of these headers. In d
Hi Klemens,
Klemens Nanni wrote on Mon, Feb 17, 2020 at 05:19:27PM +0100:
> I'd like to commit this soon, it allows me to jump to the command I'm
> looking for, e.g. ":tx509" shows me the synopsis right away.
>
> FWIW, some Linux distributions ship with separate manuals, e.g. x509(1SSL).
Yes, t
On Mon, Feb 17, 2020 at 07:40:40PM -0500, Kenneth R Westerback wrote:
> On Mon, Feb 17, 2020 at 06:23:01PM -0600, Scott Cheloha wrote:
> > On Sat, Jan 11, 2020 at 02:57:14AM -0600, Scott Cheloha wrote:
> > > The sleep duration is in milliseconds. We can rip out the timeval and
> > > tvtohz(9) and
ends up being included by 532 files. On amd64 this
represents almost 1/3 of the 1674 kernel source files. So any change
in a header it includes will result in a large number of rebuild.
is one of these headers. In drm land it is necessary to
make some scheduling decision based on the states o
On 18/02/20(Tue) 22:39, Jonathan Matthew wrote:
> On Fri, Feb 14, 2020 at 06:28:20PM +0100, Martin Pieuchot wrote:
> > @@ -2597,13 +2635,6 @@ em_initialize_receive_unit(struct em_sof
> > E1000_WRITE_REG(&sc->hw, ITR, DEFAULT_ITR);
> > }
> >
> > - /* Setup the Base and Length of
On Tue, 18 Feb 2020 12:11:05 + Stuart Henderson
wrote:
> On 2020/02/18 08:25, Gerhard Roth wrote:
> > > > @@ -2393,6 +2581,11 @@ umb_send_connect(struct umb_softc *sc, i
> > > > c->authprot = htole32(MBIM_AUTHPROT_NONE);
> > > > c->compression = htole32(MBIM_COMPRESSION_NONE);
On Fri, Feb 14, 2020 at 06:28:20PM +0100, Martin Pieuchot wrote:
> This diff introduces the concept of "queue" in the em(4) driver. The
> logic present in ix(4) has been matched for coherency.
>
> Currently the driver uses a single queue and the diff below doesn't
> change anything in that regard
On 2020/02/18 08:25, Gerhard Roth wrote:
> > > @@ -2393,6 +2581,11 @@ umb_send_connect(struct umb_softc *sc, i
> > > c->authprot = htole32(MBIM_AUTHPROT_NONE);
> > > c->compression = htole32(MBIM_COMPRESSION_NONE);
> > > c->iptype = htole32(MBIM_CONTEXT_IPTYPE_IPV4);
> > > +#ifdef INET6
> > >
> I like the idea!
I agree.
> To me it would be more logical to put .Tg above .Sh, but that is a minor
> thing.
I also think that it would better to place .Tg above .Sh .
On Mon, Feb 17, 2020 at 11:20:34PM +0100, Remi Locherer wrote:
> On Mon, Feb 17, 2020 at 05:19:27PM +0100, Klemens Nanni wro
Hi,
here is an update of the last diff rebased onto current with minor fixes. There
were some problems when multiple transport and non-transport policies were
configured, which should now be fixed.
I also have a test case for the new regression test which runs successfully.
ok?
diff --git a/sbin
Hi.
I've got a bunch of things that have static reservations by MAC address in
dhcpd.conf. I also have the MAC addresses in /etc/ethers for tcpdumping.
This duplication and potential inconsistency annoys me.
Is there any reason we can't have dhcpd look up names in /etc/ethers?
Index: usr.sbin/d
On Mon, Feb 17, 2020 at 11:42:48PM +0100, Theo Buehler wrote:
> Without tags I currently achieve pretty much the same by doing "/^X509"
> or "/^S_CLIENT" etc. However, having to know the special trick for each
> page (if there is one) is annoying, so I think this is an improvement.
This is not sema
* Adam Steen [2020-02-18 04:56:57 +]:
Hi
Please see the patch below to handle invalid writes to cr0 as per the
Intel SDM Volume 3.
The 3 cases i am handling with this change are
1. CR0.PG: Setting the PG flag when the PE flag is clear causes a
general-protection exception (#GP). (Intel
22 matches
Mail list logo
