On Fri, Jun 07, 2019 at 07:29:19PM +0900, Naoki Fukaumi wrote:
> hi tech@,
>
> here is another patch for another issue for ipmi(4).
>
> ipmi_sendcmd() and ipmi_recvcmd() are always called in order/pairs as a
> single task of a single-threaded taskq, remove mutex from there. this
> avoids interrup
On Fri, Jun 07, 2019 at 07:36:36PM -0500, Scott Cheloha wrote:
> [...]
>
> > +
> > +static uint64_t
> > +mcx_timer(struct mcx_softc *sc)
> > +{
> > + uint32_t hi, lo, ni;
> > +
> > + hi = mcx_rd(sc, MCX_INTERNAL_TIMER_H);
> > + for (;;) {
> > + lo = mcx_rd(sc, MCX_INTERNAL_TIMER_L)
On Fri, Jun 07, 2019 at 02:34:20PM +1000, David Gwynne wrote:
> nics are starting to offer the ability to timestamp packets when
> they're received. other systems (eg linux and freebsd) have support
> for recording that timestamp on mbufs and then using it as the
> backend for at least the SO_TIMES
i did that and for some for reason i didn't get it! it tries to open
timezone so it kinda looks like a red flag right there...
apart from /dev do we need to look into TZ on this one as well? if TZ
var needs to be looked at then all bets are off :/
On 01:01 Sat 08 Jun , Consus wrote:
> On 18:1
Florian Obser(flor...@openbsd.org) on 2019.06.07 19:52:21 +0200:
>
>
> Remove A and D flag, they are superfluous.
> One could always use them on the command line and acme-client would do
> the right thing.
>
> IIRC this is a leftover from when we moved to the config file and we
> never mopped th
On 18:14 Fri 07 Jun, Ricardo Mestre wrote:
> Hi,
>
> My eyes may be cheating me in plain sight, but sysctl(8) doesn't seem to
> require fs access at all.
>
> Comments? OK?
>
> Index: sysctl.c
> ===
> RCS file: /cvs/src/sbin/sysctl/s
OK, here’s an updated diff. Sorry for the delay, I’ve been having network
problems. Boots up and gets detected immediately by OpenBSD, no delays.
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 4ffb2ff899f..7de38facc78 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/a
Good day.
The attached patch fixes incoming interface for pf(4) processing
in the case of bridging of multiple VLAN interfaces which have
the same parent iface and unicast packets destined to the bridge
member: we can't rely solely on the destination MAC in determining
proper incoming interface.
Good day.
With the hints from Martin Pieuchot had found out that the current
handling of IFT_ETHER for bridge(4) /and nowadays, after de-introduction
of IFT_MPLSTUNNEL/mpw(4) type interfaces, only IFT_ETHER ones can
be attached to the bridge(4)/
- isn't uniform across both ADD ioctls,
- has some
Remove A and D flag, they are superfluous.
One could always use them on the command line and acme-client would do
the right thing.
IIRC this is a leftover from when we moved to the config file and we
never mopped this up.
It's kinda getting in the way and kinda an itch I have to scratch.
OK?
Hi,
My eyes may be cheating me in plain sight, but sysctl(8) doesn't seem to
require fs access at all.
Comments? OK?
Index: sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.242
diff -u -p -u -r1.242 sysct
> Date: Fri, 7 Jun 2019 13:06:22 +1000
> From: Jonathan Gray
>
> On Thu, Jun 06, 2019 at 11:41:07PM +0200, Mark Kettenis wrote:
> > As a result of a recent discussion with jsg@, I realized that the
> > graphics drivers are (mostly) allocating memory from the dma region.
> > Since the the graphics
> Date: Fri, 7 Jun 2019 17:00:24 +1000
> From: David Gwynne
> Cc: kette...@openbsd.org
> Content-Type: text/plain; charset="utf-8"
> Content-Disposition: inline
>
> currently mem bars and the rom address conflict lines in dmesg look
> the same, which is a bit confusing. this makes rom conflicts l
On Mon, 03 Jun 2019 at 23:44:37 -0400, Cody Cutler wrote:
> Hi jcs and tech, the following is a patch which implements jcs's feedback and
> adds a man page.
Thanks Cody, I've imported your driver.
This diff allows mg to log its internal status to a file. At the moment it
only logs line information like front and back pointers in the linked
list, how many characters are used and where the cursor is placed in the
file, but I am finding it incredibly useful debugging mg at the moment.
Belo
On 6/7/19 2:28 PM, Florian Obser wrote:
On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencry
On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:
>
>
> On 6/6/19 10:46 AM, Renaud Allard wrote:
> >
> >
> > On 6/6/19 10:10 AM, Florian Obser wrote:
> >
> > > I currently don't have time to review this. I'm busy switching
> > > acme-client to the rfc 8555 / letsencrypt v2 api. Do
On 6/7/19 10:40 AM, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts too badly with my w
This also seems good to me.
ok?
On Fri, 07 Jun 2019 19:23:57 +0900 (JST)
Naoki Fukaumi wrote:
> hi tech@,
>
> here is patch for ipmi(4).
>
> watchdog timer on ipmi(4) is 16bit, and unit is 100ms. round down a
> value greater than (UINT16_MAX / 10) to the maximum value.
>
> --
> FUKAUMI Naoki
The diff seems good to me.
ok?
On Fri, 07 Jun 2019 19:20:35 +0900 (JST)
Naoki Fukaumi wrote:
> hi tech@,
>
> setting kern.watchdog.period to negative value is currently allowed,
> but many watchdog device drivers don't handle it properly. it will
> enable timer with uninteded period without aut
hi tech@,
here is another patch for another issue for ipmi(4).
ipmi_sendcmd() and ipmi_recvcmd() are always called in order/pairs as a
single task of a single-threaded taskq, remove mutex from there. this
avoids interrupts blocked long time.
task for watchdog can be long lived, use own taskq ins
hi tech@,
here is patch for ipmi(4).
watchdog timer on ipmi(4) is 16bit, and unit is 100ms. round down a
value greater than (UINT16_MAX / 10) to the maximum value.
--
FUKAUMI Naoki
Index: sys/dev/ipmi.c
===
RCS file: /cvs/src/sys/d
hi tech@,
setting kern.watchdog.period to negative value is currently allowed,
but many watchdog device drivers don't handle it properly. it will
enable timer with uninteded period without auto refreshing, so machine
will be rebooted at some point.
some drivers handle negative value, but results
On Tue, May 28, 2019 at 03:53:11PM +0200, Claudio Jeker wrote:
> On Tue, May 14, 2019 at 12:37:25AM +0200, Claudio Jeker wrote:
> > This diff changes the way communites are stored and modified in bgpd.
> > The current implementation was showing that community_*_delete() consumed
> > a lot of CPU ti
On 6/7/19 10:45 AM, Martijn van Duren wrote:
> On 6/7/19 10:41 AM, Gerhard Roth wrote:
>> On 6/7/19 9:52 AM, Martijn van Duren wrote:
>>> On 6/7/19 9:50 AM, Martijn van Duren wrote:
Hello tech@,
I managed to get SHA-2 support working for snmpd, based on RFC7860 and
tested with
On 6/7/19 10:41 AM, Gerhard Roth wrote:
> On 6/7/19 9:52 AM, Martijn van Duren wrote:
>> On 6/7/19 9:50 AM, Martijn van Duren wrote:
>>> Hello tech@,
>>>
>>> I managed to get SHA-2 support working for snmpd, based on RFC7860 and
>>> tested with net-snmp commandline tools.
>>>
>>> I split the diff
On 6/7/19 9:52 AM, Martijn van Duren wrote:
> On 6/7/19 9:50 AM, Martijn van Duren wrote:
>> Hello tech@,
>>
>> I managed to get SHA-2 support working for snmpd, based on RFC7860 and
>> tested with net-snmp commandline tools.
>>
>> I split the diff up in 2 steps for readability.
> Step 2: Impleme
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts too badly with my work, but I'd appreciate it if we
could hold
On 6/7/19 9:50 AM, Martijn van Duren wrote:
> Hello tech@,
>
> I managed to get SHA-2 support working for snmpd, based on RFC7860 and
> tested with net-snmp commandline tools.
>
> I split the diff up in 2 steps for readability.
> Step 1: Don't assume the digestlength is always 12 bytes. This is
On 6/7/19 9:50 AM, Martijn van Duren wrote:
> Hello tech@,
>
> I managed to get SHA-2 support working for snmpd, based on RFC7860 and
> tested with net-snmp commandline tools.
>
> I split the diff up in 2 steps for readability.
Step 2: Implement the SHA-2 values.
>
> OK?
>
> martijn@
diff --
Hello tech@,
I managed to get SHA-2 support working for snmpd, based on RFC7860 and
tested with net-snmp commandline tools.
I split the diff up in 2 steps for readability.
Step 1: Don't assume the digestlength is always 12 bytes. This is only
true for MD5 and SHA-1.
OK?
martijn@
diff
currently mem bars and the rom address conflict lines in dmesg look
the same, which is a bit confusing. this makes rom conflicts lines say
"rom conflict" instead.
that looks like this:
dlg@r6415 pci$ dmesg | grep -A4 conflict
129:0:0: rom address conflict 0xfffc/0x4
129:0:1: rom address
32 matches
Mail list logo
