> From: "Constantine A. Murenin"
> Date: Wed, 2 Dec 2020 14:04:52 -0800
>
> Not sure if you've seen it, but ipmi(4) has been disabled for over 12
> years, because it's broken on some machines, so, this code is not
> necessarily guaranteed to be correct as-is.
>
> http://cvsweb.openbsd.org/cgi-bi
On Wed, 2 Dec 2020 at 14:36, Martin Pieuchot wrote:
>
> On 02/12/20(Wed) 14:22, jungle Boogie wrote:
> > Hi All,
> >
> > Getting this kernel panic on my machine with the latest amd64 snapshot
> > (13:13 timestamp)
> >
> > ddb{1}> bt
> > spllower(821b8cb4) at spllower+0x21
> > single_thread
On 02/12/20(Wed) 14:22, jungle Boogie wrote:
> Hi All,
>
> Getting this kernel panic on my machine with the latest amd64 snapshot
> (13:13 timestamp)
>
> ddb{1}> bt
> spllower(821b8cb4) at spllower+0x21
> single_thread_check_locked(80002030,0) at
> single_thread_check_locked+0x
>
On 2020/12/02 14:04, Constantine A. Murenin wrote:
> Not sure if you've seen it, but ipmi(4) has been disabled for over 12
> years, because it's broken on some machines, so, this code is not
> necessarily guaranteed to be correct as-is.
yes I have a recollection that it may have not worked on some
Hi All,
Getting this kernel panic on my machine with the latest amd64 snapshot
(13:13 timestamp)
ddb{1}> bt
spllower(821b8cb4) at spllower+0x21
single_thread_check_locked(80002030,0) at single_thread_check_locked+0x
f4
userret(80002030) at userret+0x187
syscall(ff80003
Not sure if you've seen it, but ipmi(4) has been disabled for over 12
years, because it's broken on some machines, so, this code is not
necessarily guaranteed to be correct as-is.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/conf/GENERIC#rev1.632
http://cvsweb.openbsd.org/cgi-bin/cvs
Hi,
ipmi(4) is one of the few remaining callers of tsleep(9). I want to
convert it to use tsleep_nsec(9) but I need some clarification on what
the code in question is doing.
In ipmi_poll_thread() we initialize all the sensors in a loop.
Between each get_sdr() call we tsleep(9) for 1 tick.
So, I
On 02/12/2020 05:08, George Koehler wrote:
On Wed, 2 Dec 2020 01:59:00 +0100
Noth wrote:
Disk: sd0 Usable LBA: 34 to 4000797326 [4000797360 Sectors]
#: type [ start: size ]
--
On Wed, Dec 02, 2020 at 11:41:04AM -0300, Martin Pieuchot wrote:
> On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> > On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > > [...]
> > > > Did you run a make build with that smr_ba
Tests, OKs?
diff --git doc/ChangeLog doc/ChangeLog
index 9bcf7de6ab6..018c484aac3 100644
--- doc/ChangeLog
+++ doc/ChangeLog
@@ -1,3 +1,45 @@
+24 November 2020: Wouter
+ - Merge PR #141: ZONEMD RR type.
+ - tag for 4.3.4rc1.
+
+23 November 2020: Wouter
+ - Fix #142: NODATA answ
Hi,
I'd like to convert all of the wait loops in hvn(4) and hyperv(4) from
using ticks to using real units of time.
Most of them use tsleep(9), so let's do tsleep(9) -> tsleep_nsec(9)
conversions first.
In every case there is an adjacent delay(9) call we use if the kernel
is cold. I assume it's
On Wed, 02 Dec 2020, Claudio Jeker wrote:
> Be stricter in what we accept as URL. Nobody should use silly encodings
> like UTF-8 or other crap in the embedded URLs. I also consider any kind of
> space as a failure (use %20 instead if that is really needed).
Really? So ȓþʞí.idna2008.example.net is
On 01/12/20(Tue) 18:23, Mark Kettenis wrote:
> > Date: Tue, 1 Dec 2020 13:18:59 -0300
> > From: Martin Pieuchot
> >
> > On 01/12/20(Tue) 15:18, Mark Kettenis wrote:
> > > > Date: Tue, 1 Dec 2020 11:08:50 -0300
> > > > From: Martin Pieuchot
> > > >
> > > > As recently pointed out by jmatthew@ th
On Wed, 02 Dec 2020 17:18:49 +0100, Theo Buehler wrote:
> Should this also check isascii() to ensure that this works as intended
> in the -portable version? The ENVIRONMENT section of the isalnum() and
> ispunct() manuals suggests that the characters satisfying this could be
> locale-dependent on
On Wed, Dec 02, 2020 at 03:17:43PM +0100, Claudio Jeker wrote:
> Be stricter in what we accept as URL. Nobody should use silly encodings
> like UTF-8 or other crap in the embedded URLs. I also consider any kind of
> space as a failure (use %20 instead if that is really needed).
>
> This makes late
rpki-client passes both empty strings and NULL strings as zero length
objects. The unmarshal code then allocates memory in any case and so a
NULL string is unmarshalled as empty string. This is not great, currently
there are no empty strings but a fair amount of NULL strings.
This diff changes the
On Wed, 02 Dec 2020 15:17:43 +0100, Claudio Jeker wrote:
> Be stricter in what we accept as URL. Nobody should use silly encodings
> like UTF-8 or other crap in the embedded URLs. I also consider any kind of
> space as a failure (use %20 instead if that is really needed).
>
> This makes later hand
On 02/12/20(Wed) 17:27, Jonathan Matthew wrote:
> On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > [...]
> > > Did you run a make build with that smr_barrier() in it and checked that it
> > > does not cause a slow down? I am sc
Be stricter in what we accept as URL. Nobody should use silly encodings
like UTF-8 or other crap in the embedded URLs. I also consider any kind of
space as a failure (use %20 instead if that is really needed).
This makes later handling of URLs a lot safer (e.g. rpki-client prints
part of URLs in l
On Wed, Dec 02, 2020 at 06:49:38AM -0700, Todd C. Miller wrote:
> On Wed, 02 Dec 2020 12:19:11 +0100, Claudio Jeker wrote:
>
> > The overflow check for the relative metric adjustments of filtersets
> > assumes a certain overflow behaviour of signed integers. I think it is
> > better to write this
On Wed, 02 Dec 2020 12:19:11 +0100, Claudio Jeker wrote:
> The overflow check for the relative metric adjustments of filtersets
> assumes a certain overflow behaviour of signed integers. I think it is
> better to write this in a way that does not involve an overflow.
OK millert@ though I think >
The overflow check for the relative metric adjustments of filtersets
assumes a certain overflow behaviour of signed integers. I think it is
better to write this in a way that does not involve an overflow.
OK?
--
:wq Claudio
Index: rde_filter.c
On Wed, Dec 02, 2020 at 05:27:59PM +1000, Jonathan Matthew wrote:
> On Tue, Dec 01, 2020 at 02:35:18PM -0300, Martin Pieuchot wrote:
> > On 01/12/20(Tue) 15:30, Claudio Jeker wrote:
> > > [...]
> > > Did you run a make build with that smr_barrier() in it and checked that it
> > > does not cause a
On Tue, Dec 1, 2020 at 5:48 AM Martin Pieuchot wrote:
...
> exit1() for a multi-threaded process does the following:
>
> atomic_setbits_int(&p->p_flag, P_WEXIT);
> single_thread_check(p, 0); // directly or via single_thread_set()
> SMR_TAILQ_REMOVE_LOCKED(&pr->ps_threads,
24 matches
Mail list logo
