I asked a simple question. Does the control program *work ok* with
this proposed change.
With the socket to nowhere:
ldpctl show
ldpctl: connect: /var/run/ldpd.sock: Connection refused
Delete it, and retry:
ldpctl show
ldpctl: connect: /var/run/ldpd.sock: No such file or directory
Yes it
On 2020-06-19, Mark Kettenis wrote:
> I'm talking about *skew*, not drift. If there is a significant drift
> you already knock out the TSC.
>
> What's needed is:
>
> 1. A bit of research of what an acceptable skew is. My hypothesis is
>that on many machines with a single socket the TSCs
Klemens Nanni wrote:
> On Fri, Jun 19, 2020 at 11:19:24PM +0100, Ricardo Mestre wrote:
> > this is getting in my nerves, I made a wrong assumption here and I
> > prefer to commit this than backout my previous commit so I'm asking for
> > commits for the below.
> Wasn't there another daemon as
Opposed to all other (single CPU) machines I have encountered so far,
the T4-2 has two instead of one PCIe root complexes.
ldomctl already accounts for this and iterates over them but lacks a
simple skip condition when iterating over subdevices to avoid linking
devices in one root complex to
On Fri, Jun 19, 2020 at 11:19:24PM +0100, Ricardo Mestre wrote:
> this is getting in my nerves, I made a wrong assumption here and I
> prefer to commit this than backout my previous commit so I'm asking for
> commits for the below.
Wasn't there another daemon as well that stopped unlinking the
this is getting in my nerves, I made a wrong assumption here and I
prefer to commit this than backout my previous commit so I'm asking for
commits for the below.
On 14:43 Fri 19 Jun , Ricardo Mestre wrote:
> mea culpa, but I'd rather just remove the unlink of the socket.
>
> OK?
>
> Index:
> On Jun 19, 2020, at 12:40, Paul Irofti wrote:
>
> [...]
>
> +
> +static inline void
> +bintimeaddfrac(const struct bintime *bt, uint64_t x, struct bintime *ct)
> +{
> +ct->sec = bt->sec;
> +if (bt->frac > bt->frac + x)
> +ct->sec++;
> +ct->frac = bt->frac + x;
> +}
> +
>
On 2020/06/19 20:28, Paul Irofti wrote:
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > I don't expect userland processes to call CLOCK_UPTIME in a loop like
> > they tend to do do for CLOCK_MONOTONIC and CLOCK_REALTIME. Linux
> > doesn't have it ;).
>
> I don't care
> Date: Fri, 19 Jun 2020 16:14:45 +1000
> From: David Gwynne
>
> the network stack doesnt really block timeouts from firing anymore. this
> is especially true on MP systems, because timeouts fire on cpu0 and the
> nettq thread could be somewhere else entirely. this means network
> activity
În 19 iunie 2020 23:37:28 EEST, Mark Kettenis a scris:
>> Date: Fri, 19 Jun 2020 23:16:26 +0300
>> From: Paul Irofti
>>
>> În 19 iunie 2020 22:49:32 EEST, Mark Kettenis
> a scris:
>> >> Date: Fri, 19 Jun 2020 20:28:58 +0300
>> >> From: Paul Irofti
>> >>
>> >> On Fri, Jun 19, 2020 at
> Date: Fri, 19 Jun 2020 23:16:26 +0300
> From: Paul Irofti
>
> În 19 iunie 2020 22:49:32 EEST, Mark Kettenis a
> scris:
> >> Date: Fri, 19 Jun 2020 20:28:58 +0300
> >> From: Paul Irofti
> >>
> >> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> >> > > Date: Fri, 19 Jun 2020
În 19 iunie 2020 22:49:32 EEST, Mark Kettenis a scris:
>> Date: Fri, 19 Jun 2020 20:28:58 +0300
>> From: Paul Irofti
>>
>> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
>> > > Date: Fri, 19 Jun 2020 14:31:17 +0300
>> > > From: Paul Irofti
>> > >
>> > > Hi,
>> > >
>> > >
> Date: Fri, 19 Jun 2020 20:28:58 +0300
> From: Paul Irofti
>
> On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 19 Jun 2020 14:31:17 +0300
> > > From: Paul Irofti
> > >
> > > Hi,
> > >
> > > Here is another iteration of the diff that addresses all issues raised
> From: "Todd C. Miller"
> Date: Fri, 19 Jun 2020 12:24:33 -0600
>
> On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote:
>
> > There is one other issue that I wanted to raise. An that is whether
> > we really need to implement CLOCK_UPTINME as a userland clock. If we
> > don't do that we
On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote:
> There is one other issue that I wanted to raise. An that is whether
> we really need to implement CLOCK_UPTINME as a userland clock. If we
> don't do that we can drop tk_naptime from the shared struct. I
> mention this because
On Fri, 19 Jun 2020 14:42:54 +0200
Theo Buehler :
> On Fri, Jun 19, 2020 at 11:42:44AM -, Christian Weisgerber wrote:
> [...]
> [...]
> [...]
>
> Yes, jsing wanted to take a closer look. I will commit the diff
> tonight UTC unless I hear an objection (I have an ok beck).
>
I
On Fri, Jun 19, 2020 at 06:52:40PM +0200, Mark Kettenis wrote:
> > Date: Fri, 19 Jun 2020 14:31:17 +0300
> > From: Paul Irofti
> >
> > Hi,
> >
> > Here is another iteration of the diff that addresses all issues raised
> > in the meantime:
> >
> > - Switch tc to uint
>
> The request was to
> Date: Fri, 19 Jun 2020 14:31:17 +0300
> From: Paul Irofti
>
> Hi,
>
> Here is another iteration of the diff that addresses all issues raised
> in the meantime:
>
> - Switch tc to uint
The request was to use u_int, like we de in the kernel. The uint type
should not be used in OpenBSD
Well... they something in ports might still look at them in
Can someone from ports speak about this?
Visa Hankala wrote:
> The header has been unhooked from /
> for a while, and no one has complained. Nothing seems to
> reference any longer, so the following files should
> be ready for
The header has been unhooked from /
for a while, and no one has complained. Nothing seems to
reference any longer, so the following files should
be ready for removal:
sys/arch/alpha/include/stdarg.h
sys/arch/amd64/include/stdarg.h
sys/arch/arm/include/stdarg.h
sys/arch/arm64/include/stdarg.h
Hi
Running -current on a Lenovo G500 (dmesg below) recent snaps give the
following error messages on boot:
Jun 18 22:11:37 alegreya /bsd: drm:pid80480:ivb_set_fifo_underrun_reporting *ERR
OR* [drm] *ERROR* uncleared fifo underrun on pipe A
Jun 18 22:11:37 alegreya /bsd:
On Fri, Jun 19, 2020 at 05:20:24PM +0300, Paul Irofti wrote:
> Hi Lucas,
>
> Will reply inline.
>
> > As a matter of syntax, there are quite some places with functions
> > without parameters defined as `f()` instead of `f(void)`.
>
> Sure. Good catch.
>
> > > + if (tc == NULL || tk_user < 1 ||
Hi Lucas,
Will reply inline.
As a matter of syntax, there are quite some places with functions
without parameters defined as `f()` instead of `f(void)`.
Sure. Good catch.
+ if (tc == NULL || tk_user < 1 || tk_user > TC_LAST)
Shouldn't you check for >= TC_LAST in here? Otherwise
mea culpa, but I'd rather just remove the unlink of the socket.
OK?
Index: control.c
===
RCS file: /cvs/src/usr.sbin/ldpd/control.c,v
retrieving revision 1.29
diff -u -p -u -r1.29 control.c
--- control.c 3 Mar 2017 23:30:57 -
Hi Paul,
I'm just a bystander that likes to read diffs. I can't speak about how
the diff fits in the kernel, but I can do some basic checks of
correctness.
As a matter of syntax, there are quite some places with functions
without parameters defined as `f()` instead of `f(void)`.
Paul Irofti
The problems is that ldpd exits with a pledge violation. However, it happens
when ldpd is terminating during ldpe_shutdown().
OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
A demonstration of the problem
On Fri, Jun 19, 2020 at 11:42:44AM -, Christian Weisgerber wrote:
> On 2020-06-18, Marc Espie wrote:
>
> > What pkg_add does internally is a pipeline:
> >
> > ftp | signify|internal gunzip
> >
> > closing the end file handle should kill the whole chain.
> > So I need to figure out where it
Ricardo Mestre(ser...@helheim.mooo.com) on 2020.06.18 23:40:54 +0100:
> Hi,
>
> Yes, this is a really broad permission to give but it's needed in order to
> read
> the config file (and those ones included from it) and also to exec the "check
> script(s)" which I missed in my last attempt to
Fix length specification for 2GHz band information element (IE) data in
the iwx(4) probe request template. The value that was being written
previously is too short so some IEs weren't included in the probe
request frame.
The active scanning code path is currently disabled in-tree, so this
fixes a
Do not copy an SSID into the probe request template because hardware
will add the SSID by itself.
I have verified that probe requests transmitted by the device still
look good and contain the SSID configured by ifconfig.
Note that the in-tree driver does not send probe requests right now
because
On 2020-06-18, Marc Espie wrote:
> What pkg_add does internally is a pipeline:
>
> ftp | signify|internal gunzip
>
> closing the end file handle should kill the whole chain.
> So I need to figure out where it goes wrong, what's the
> part that doesn't die "instantly".
That's ftp(1). Our SSL
This fixes a wrong unconditional write to a field of the scan command.
The scan command struct is a hell of a union of structs which represent
different versions of the scan command. This coding style makes it easy to
write to a wrong offset by accident. I intend to eventually clean this up
but
Hi,
Here is another iteration of the diff that addresses all issues raised
in the meantime:
- Switch tc to uint
- Check for version at init and switch to machite/timetc.h defs
- Remove tk_nclocks
- Switch to single version and ditch minor/major
- Do not enable user TSC for large skew
iwx(4) hardware can monitor device temperature and notify the driver when
a critical temperature has been reached.
This patch enables the mechanism. The driver will now turn the device off
and print a message to dmesg if the firmware signals critical temperature.
Comments in Linux source code
the network stack doesnt really block timeouts from firing anymore. this
is especially true on MP systems, because timeouts fire on cpu0 and the
nettq thread could be somewhere else entirely. this means network
activity doesn't make the softclock lose ticks, which means we aren't
scaling rx ring
On Wed, Jun 17, 2020 at 01:17:37PM +0200, Hrvoje Popovski wrote:
> On 17.6.2020. 13:13, Jonathan Matthew wrote:
> > On Wed, Jun 17, 2020 at 12:50:46PM +0200, Hrvoje Popovski wrote:
> >> On 17.6.2020. 12:45, Hrvoje Popovski wrote:
> >>> On 17.6.2020. 11:27, Hrvoje Popovski wrote:
> On
36 matches
Mail list logo
