yes :D
> On 29 May 2019, at 15:05, Remi Locherer wrote:
>
> Hi David,
>
> are you going to commit this?
>
> Remi
>
>
> On Thu, May 16, 2019 at 11:14:55PM +0200, Remi Locherer wrote:
>> On Thu, May 16, 2019 at 09:39:37AM +0200, Sebastian Benoit wrote:
>>>
>>>
>>>
>>> Remi
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_TIMESTAMP socket option instead of a
call to microtime().
this implements
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 stack can potentially gobble up large amounts
> of memory, this means
On Thu, Jun 06, 2019 at 11:41:07PM +0200, Mark Kettenis wrote:
[...]
> It seems to work fine on my Intel Broadwell laptop. I haven't tested
> this on radeon(4) yet. So further testing, especially on systems with
> 4GB of memory or more is necessary.
>
> Please test.
Tested on a desktop with
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 stack can potentially gobble up large amounts
of memory, this means we can run out of dma memory which makes other
parts of our kernel quite
> From: David Hill
> Date: Thu, 6 Jun 2019 09:55:00 -0400
>
> On 6/6/19 8:49 AM, Mark Kettenis wrote:
> >> From: David Hill
> >> Date: Thu, 6 Jun 2019 08:22:06 -0400
> >>
> >> On 6/6/19 6:56 AM, Scott Cheloha wrote:
> >>> On Wed, Jun 05, 2019 at 08:33:56PM -0400, David Hill wrote:
> Hello
On 02/06/19(Sun) 16:41, Martin Pieuchot wrote:
> On 01/06/19(Sat) 18:55, Martin Pieuchot wrote:
> > Diff below exists mainly for documentation and test purposes. If
> > you're not interested about how to break the scheduler internals in
> > pieces, don't read further and go straight to testing!
>
On Thu, Jun 06, 2019 at 02:55:35PM +0100, Stuart Henderson wrote:
> I'm testing the "pump my sched" and read/write unlock diffs and ran into
> the panic below. Seems more likely that it would be connected with the
> sched diff rather than anything else. I'll build a WITNESS kernel and
> see if I
On 2019/06/06 14:55, Stuart Henderson wrote:
> I'm testing the "pump my sched" and read/write unlock diffs and ran into
> the panic below. Seems more likely that it would be connected with the
> sched diff rather than anything else. I'll build a WITNESS kernel and
> see if I can get more details
This switches acme-client(1) from draft-03 to the final standard.
Let's Encrypt claims - and this seems to be true in my testing - that
accounts created on the v01 api (the draf one) work on the v02 api
(rfc).
This drops support for v01, thinks got shuffled around too much to
support both.
Le 2019-06-05 12:06, Mark Kettenis a écrit :
Date: Wed, 5 Jun 2019 10:16:25 +0200
From: Sebastien Marie
Hi,
I would like to have feedback and testing on this diff. The initial
work
was done by ian@.
Don't forget to run "make syscalls" in sys/kern when building your own
kernel with this
I'm testing the "pump my sched" and read/write unlock diffs and ran into
the panic below. Seems more likely that it would be connected with the
sched diff rather than anything else. I'll build a WITNESS kernel and
see if I can get more details if it hapens again.
ddb{1}> show panic
kernel
On 6/6/19 8:49 AM, Mark Kettenis wrote:
From: David Hill
Date: Thu, 6 Jun 2019 08:22:06 -0400
On 6/6/19 6:56 AM, Scott Cheloha wrote:
On Wed, Jun 05, 2019 at 08:33:56PM -0400, David Hill wrote:
Hello -
I noticed some negative roundtrip times when running traceroute, which uses
the
> From: David Hill
> Date: Thu, 6 Jun 2019 08:22:06 -0400
>
> On 6/6/19 6:56 AM, Scott Cheloha wrote:
> > On Wed, Jun 05, 2019 at 08:33:56PM -0400, David Hill wrote:
> >> Hello -
> >>
> >> I noticed some negative roundtrip times when running traceroute, which uses
> >> the monotonic clock to
On 6/6/19 6:56 AM, Scott Cheloha wrote:
On Wed, Jun 05, 2019 at 08:33:56PM -0400, David Hill wrote:
Hello -
I noticed some negative roundtrip times when running traceroute, which uses
the monotonic clock to calculate the RTT.
If I run the following code, it eventually bombs.?? It bombs
Björn Ketelaars:
> Diff below is based on the latest diff from naddy@. Changes:
> - reallocarray likes type_t, as such changes type of nxdev and i;
> - use reallocarray instead of malloc as xdev is initialised as NULL.
ok naddy@
--
Christian "naddy" Weisgerber
On Wed, Jun 05, 2019 at 08:33:56PM -0400, David Hill wrote:
> Hello -
>
> I noticed some negative roundtrip times when running traceroute, which uses
> the monotonic clock to calculate the RTT.
>
> If I run the following code, it eventually bombs.?? It bombs quick if I
> launch Firefox.
>
>
On Thu 06/06/2019 00:37, Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > > To reproduce:
> > >
> > > mkdir -p /tmp/test /tmp/plop
> > > openrsync -rx /tmp/test/ /tmp/plop/
> > >
> > > Result:
> > >
> > > openrsync(3470) in free(): bogus pointer (double free?) 0x7f7dcdc8
> >
Don't start a background scan while we're waiting for a response from
the AP to a management frame we have sent.
In particular, the logic which tries to detect dead APs might be waiting
for a probe response from the AP. Starting a background scan in this state
won't do any good. In case of iwn(4)
On 6/6/19 10:10 AM, Florian Obser wrote:
On Wed, Jun 05, 2019 at 05:37:51PM +0200, Gilles Chehade wrote:
On Wed, Jun 05, 2019 at 08:39:51AM +0200, Renaud Allard wrote:
On 6/5/19 8:20 AM, Gilles Chehade wrote:
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
On 6/3/19
On Wed, Jun 05, 2019 at 05:37:51PM +0200, Gilles Chehade wrote:
> On Wed, Jun 05, 2019 at 08:39:51AM +0200, Renaud Allard wrote:
> >
> >
> > On 6/5/19 8:20 AM, Gilles Chehade wrote:
> > > On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
> > > >
> > > >
> > > > On 6/3/19 11:53 AM,
OK
On Thu, Jun 06, 2019 at 12:37:13AM +0200, Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > > To reproduce:
> > >
> > > mkdir -p /tmp/test /tmp/plop
> > > openrsync -rx /tmp/test/ /tmp/plop/
> > >
> > > Result:
> > >
> > > openrsync(3470) in free(): bogus pointer (double
On Thu, Jun 06, 2019 at 12:37:13AM +0200, Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > > To reproduce:
> > >
> > > mkdir -p /tmp/test /tmp/plop
> > > openrsync -rx /tmp/test/ /tmp/plop/
> > >
> > > Result:
> > >
> > > openrsync(3470) in free(): bogus pointer (double free?)
23 matches
Mail list logo
