On Wed, Nov 27, 2019 at 05:07:36AM +0100, Klemens Nanni wrote:
> As I've already done with pfctl and bgpd, this is the first diff to
> convert iked to a more AF agnostic address parsing.
>
> This diff introduces the copy_satoipa() wrapper and makes set_ipmask()
> handle the -1 mask case which
On Tue, 26 Nov 2019 16:17:46 -0800, Ayaka Koshibe wrote:
> Currently, we assume that OpenFlow 1.3 set_field actions can contain
> multiple header match fields (OXMs). According to specification, a
> set_field action contains exactly one OXM, followed by padding to align
> the action field in a
As I've already done with pfctl and bgpd, this is the first diff to
convert iked to a more AF agnostic address parsing.
This diff introduces the copy_satoipa() wrapper and makes set_ipmask()
handle the -1 mask case which will be used in the future.
No functional change.
OK?
Index: parse.y
Currently, we assume that OpenFlow 1.3 set_field actions can contain
multiple header match fields (OXMs). According to specification, a
set_field action contains exactly one OXM, followed by padding to align
the action field in a OpenFlow message to 64 bits.
This diff changes how we handle
On Tue, Nov 26, 2019 at 11:54:10PM +, Jason McIntyre wrote:
> but hey:
>
> Halt the primary domain and reset the hardware:
> .Bd -literal -offset indent
> # halt
> sc> reset -c# ALOM
> -> reset /SYS # ILOM
> .Ed
Even better, thanks.
OK?
Index:
On Wed, Nov 27, 2019 at 12:43:26AM +0100, Klemens Nanni wrote:
> On Tue, Nov 26, 2019 at 11:09:39PM +0100, Klemens Nanni wrote:
> > My mdoc(7) wasn't strong enough, but perhaps someone can help me
> > displaying this as table instead?
> >
> > ALOMreset -c
> > ILOMreset /SYS
> I
>This strtoll() version has less error checking, does not work with
>addresses >=3D 0x8000, but reduces stripped boot size by
>64 bytes.
easier to read.
that type of compromise is very common in the bootblocks.
ok with me
On Tue, Nov 26, 2019 at 04:05:34PM -0700, Theo de Raadt wrote:
> >On Tue, Nov 26, 2019 at 05:27:03PM -0500, Ted Unangst wrote:
> >> why not use strtol here?
> >
> >Basically I was not aware that it is available in the boot loader.
> >And I need an unsigned long. Should I change the diff anyway?
>
On Tue, Nov 26, 2019 at 11:09:39PM +0100, Klemens Nanni wrote:
> My mdoc(7) wasn't strong enough, but perhaps someone can help me
> displaying this as table instead?
>
> ALOMreset -c
> ILOMreset /SYS
I sat down, here's proper markup that yields
...
Reset the
> Date: Tue, 26 Nov 2019 23:22:14 +0100
> From: Alexander Bluhm
>
> Hi,
>
> I am currently debugging an UEFI boot problem. A hexdump in the
> boot loader would be convenient.
>
> boot> hexdump 0x10 20
> 0010 53 ff 00 f0 54 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...T...S...S...|
> 0020
>On Tue, Nov 26, 2019 at 05:27:03PM -0500, Ted Unangst wrote:
>> why not use strtol here?
>
>Basically I was not aware that it is available in the boot loader.
>And I need an unsigned long. Should I change the diff anyway?
bootblocks can be tight on some media, so use the smallest code.
On Tue, Nov 26, 2019 at 05:27:03PM -0500, Ted Unangst wrote:
> why not use strtol here?
Basically I was not aware that it is available in the boot loader.
And I need an unsigned long. Should I change the diff anyway?
bluhm
Alexander Bluhm wrote:
> +
> + for (n = 1; n < cmd.argc; n++) {
> + p = cmd.argv[n];
> + if (*p == '0') {
> + p++;
> + if (*p == 'x' || *p == 'X') {
> + p++;
> + b = 16;
> +
Hi,
I am currently debugging an UEFI boot problem. A hexdump in the
boot loader would be convenient.
boot> hexdump 0x10 20
0010 53 ff 00 f0 54 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...T...S...S...|
0020 a5 fe 00 f0 ||
0024
Do we want such
Probably most of the machines being in use ship with ILOM instead of
ALOM, so lets document the slightly different command in order to pick
up new LDOM configuration.
My mdoc(7) wasn't strong enough, but perhaps someone can help me
displaying this as table instead?
ALOMreset -c
We use CIRCQs in timeouts because updating a TAILQ_HEAD pointer
on each timeout in a bucket during hardclock(9) is too costly.
However, that doesn't mean CIRCQs cannot resemble TAILQs. They
perform functionally equivalent jobs and have equivalent macros.
So, this diff:
- CIRCQ_APPEND is
Sebastian Benoit(be...@openbsd.org) on 2019.11.26 18:46:11 +0100:
>
> remove include statement and unveil() rad.
>
> ok?
diff --git usr.sbin/rad/parse.y usr.sbin/rad/parse.y
index bb18c3d9c9c..443cff66065 100644
--- usr.sbin/rad/parse.y
+++ usr.sbin/rad/parse.y
@@ -112,7 +112,7 @@ typedef
On Tue, Nov 26, 2019 at 10:42:42AM +0100, Joerg Goltermann wrote:
> I think I found the problem inside pf_ioctl.c, it looks like
> the problem was introduced with a "mechanical" patch which
> replaced all "breaks;" with "PF_UNLOCK(); break;" This seems
> to be wrong in this particular case:
I
I suppose this is the least worst way to handle it.
OK
On Sun, Nov 24, 2019 at 10:03:57PM +0100, Klemens Nanni wrote:
> On Tue, Nov 19, 2019 at 03:53:16AM +0100, Florian Obser wrote:
> > I think the file doesn't exist but it's fine check is in the wrong
> > place. It's also stupid that it doesn't
Hi,
I found another issue with the calculation of the actual length on short
xfers. On e.g. bulk transfers with multiple TRBs the first short TRB
will give us a short event. We will then calculate the actual length
and return. So far this is good.
The last TRB in the TD is marked as IOC
slaacd does not have include statements
open the control socket earlier, then unveil().
diff --git sbin/slaacd/slaacd.c sbin/slaacd/slaacd.c
index 9c3f64f407d..990614df734 100644
--- sbin/slaacd/slaacd.c
+++ sbin/slaacd/slaacd.c
@@ -179,6 +179,16 @@ main(int argc, char *argv[])
if
remove include statement and unveil() rad.
ok?
diff --git usr.sbin/rad/parse.y usr.sbin/rad/parse.y
index bb18c3d9c9c..443cff66065 100644
--- usr.sbin/rad/parse.y
+++ usr.sbin/rad/parse.y
@@ -112,7 +112,7 @@ typedef struct {
%}
-%token RA_IFACE YES NO INCLUDE ERROR
+%token RA_IFACE YES NO
On Tue, Nov 26, 2019 at 07:44:26AM +0100, Gilles Chehade wrote:
> The first step towards that is this diff.
OK kn
Hello Joerg,
your patch looks OK. thank you for testing & fixing.
thanks and
regard
sashan
On Tue, Nov 26, 2019 at 10:42:42AM +0100, Joerg Goltermann wrote:
> Hello,
>
> I tested a kernel with WITH_PF_LOCK and NET_TASKQ > 1 and got a
> kernel panic during switching between the pf statics
Hello,
I have this patch in production for more than 2 weeks without any
problems. Please try to put it in.
- Joerg
On 13.08.2019 15:51, Tobias Heider wrote:
Update: Having the use_transport_mode flag attached to the SA is
not the best idea, so now it is given down to the child SA as soon as
Hello,
I tested a kernel with WITH_PF_LOCK and NET_TASKQ > 1 and got a
kernel panic during switching between the pf statics inside systat.
I think I found the problem inside pf_ioctl.c, it looks like
the problem was introduced with a "mechanical" patch which
replaced all "breaks;" with
26 matches
Mail list logo
