jmatthew@ noticed that i still had this code in here, despite making
it mandatory for pools to specify the IPL they operate at.
ok?
Index: subr_pool.c
===
RCS file: /cvs/src/sys/kern/subr_pool.c,v
retrieving revision 1.205
diff -u -p
The videocore part of the raspberry pi that boots the system and runs
the mailbox interface and other functions afterwards knows about a MAC
address that appears to be derived from a portion of a unique serial
number along with the raspberry pi foundation oui
B827EB (base 16)Raspbe
On 02/06/17 14:44, Joel Sing wrote:
On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:
- What type of public certificate are you using (RSA or ECDSA)?
ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
Must-staple is enabled - that's why I'm also using the ocsp line for
tes
Jeremie Courreges-Anglas writes:
[...]
I've removed the TCPSTAT_INLINE code. If we want to experiment with
inlined/not inlined counters, it is probably more interesting to make
that choice elsewhere.
> Anyway, tcpstat diff below, a bit ugly because that struct is a mix of
> uint32_t and uint64
On Mon, Feb 06, 2017 at 03:54:56PM +0100, Martin Pieuchot wrote:
> tb@ found that another code path needs to be unlocked. Diff below does
> that. These ioctl(2)s are only messing at the driver level, so it is
> safe to drop the NET_LOCK() there as well.
>
> ok?
I am happy with this. OK.
And th
Hi,
The return code of crp_callback is never checked, so it is not
useful to propagate the error. When an error occures in an
asynchronous network path, incrementing a counter is the right
thing. By removing the error handling, I have found 4 places where
an error is not accounted. For now just
On 6 February 2017 at 17:02, Martin Pieuchot wrote:
> PF has its own home-brewed solution for dealing with CPU hogging. It
> has been introduced in r1.88 of net/pf_table.c and I couldn't find any
> explanation why it is different than the idiom we use in other places.
>
The idea was just to be a
On 6 February 2017 at 17:02, Martin Pieuchot wrote:
> PF has its own home-brewed solution for dealing with CPU hogging. It
> has been introduced in r1.88 of net/pf_table.c and I couldn't find any
> explanation why it is different than the idiom we use in other places.
>
> So let's use the same id
guenther@ pointed out during a2k17 that nfsrv_rcv() already has a way to
not re-enter the socket layer. Instead of doing soreceive() directly in
the receiving path, we notify and wakeup nfsd(8) to do it.
I'd like to do that unconditionally to fix one of the blocking
recursions.
I just finished a
PF has its own home-brewed solution for dealing with CPU hogging. It
has been introduced in r1.88 of net/pf_table.c and I couldn't find any
explanation why it is different than the idiom we use in other places.
So let's use the same idiom, I promise to introduce a macro an unify all
of them once
Go for it mpi.. move forward.
ok beck@
On Mon, Feb 6, 2017 at 7:48 AM, Martin Pieuchot wrote:
> On 24/01/17(Tue) 13:35, Martin Pieuchot wrote:
> > Userland threads are preempt()'d when hogging a CPU or when processing
> > an AST. Currently when such a thread is preempted the scheduler looks
>
On 06/02/17(Mon) 12:27, Martin Pieuchot wrote:
> Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> channel scan with iwm(4) and iwn(4) freezes X.
>
> This is a deadlock due to the fact that wireless drivers sleep during
> a long time holding the NET_LOCK() while the X server
On 24/01/17(Tue) 13:35, Martin Pieuchot wrote:
> Userland threads are preempt()'d when hogging a CPU or when processing
> an AST. Currently when such a thread is preempted the scheduler looks
> for an idle CPU and puts it on its run queue. That means the number of
> involuntary context switch oft
On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:
> > - What type of public certificate are you using (RSA or ECDSA)?
>
> ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
> Must-staple is enabled - that's why I'm also using the ocsp line for
> testing.
Ah, this was the miss
Hi,
While changing comments on ssh-key, I saw some vfprintf in log:
Feb 6 14:24:44 clyde ssh-keygen: vfprintf %s NULL in "Key now has comment '%s'
"
Steps to reproduce:
$ ssh-keygen -f test -C ''
Generating public/pr
In icmp6_errcount() we could save a few function calls but I preferred
to keep the conversion as mechanical as possible. Works fine here on
amd64 (I can test armv7 soon).
ok?
Index: netinet/icmp6.h
===
RCS file: /d/cvs/src/sys/net
On 03/02/17(Fri) 11:02, David Hill wrote:
> On Fri, Feb 03, 2017 at 09:50:40AM +0100, Martin Pieuchot wrote:
> > On 02/02/17(Thu) 12:12, David Hill wrote:
> > > On Thu, Feb 02, 2017 at 09:34:07AM +0100, Martin Pieuchot wrote:
> > > > On 01/02/17(Wed) 19:27, David Hill wrote:
> > > > > Hello -
> > >
On 06/02/17(Mon) 12:59, Stefan Sperling wrote:
> On Mon, Feb 06, 2017 at 12:44:52PM +0100, Martin Pieuchot wrote:
> > On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> > > This fixes the issue on my iwn0, but re-introduces the problem on my iwm0.
> >
> > That means another ioctl(2) triggers the proble
On Mon, Feb 06, 2017 at 12:44:52PM +0100, Martin Pieuchot wrote:
> On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> > This fixes the issue on my iwn0, but re-introduces the problem on my iwm0.
>
> That means another ioctl(2) triggers the problem with iwm(4). It would
> help if you could figure out w
On 06/02/17(Mon) 12:39, Theo Buehler wrote:
> On Mon, Feb 06, 2017 at 12:27:15PM +0100, Martin Pieuchot wrote:
> > Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> > channel scan with iwm(4) and iwn(4) freezes X.
> >
> > This is a deadlock due to the fact that wireless drive
On Mon, Feb 06, 2017 at 12:27:15PM +0100, Martin Pieuchot wrote:
> Paul and Antoine reported that, since the NET_LOCK() went in, doing a
> channel scan with iwm(4) and iwn(4) freezes X.
>
> This is a deadlock due to the fact that wireless drivers sleep during
> a long time holding the NET_LOCK() w
Paul and Antoine reported that, since the NET_LOCK() went in, doing a
channel scan with iwm(4) and iwn(4) freezes X.
This is a deadlock due to the fact that wireless drivers sleep during
a long time holding the NET_LOCK() while the X server tries to
communicate with unix sockets, that still need t
On Mon, Feb 06, 2017 at 11:04:02AM +, Raf Czlonka wrote:
> Hi all,
>
> How about doing it throughout the tree[0]?
>
> [0] http://marc.info/?m=142689311221135
Thanks. Most of those are already fixed (or have been removed). I found
and fixed the one in smtpd/table.5 right after fixing this one
Hi all,
How about doing it throughout the tree[0]?
[0] http://marc.info/?m=142689311221135
Cheers,
Raf
On Mon, Feb 06, 2017 at 05:53:22AM GMT, Theo Buehler wrote:
> On Sun, Feb 05, 2017 at 09:47:35PM -0800, Philip Guenther wrote:
> > On Sun, 5 Feb 2017, John McGuigan wrote:
> > > I've noticed
Theo Buehler(t...@math.ethz.ch) on 2017.02.06 08:17:43 +0100:
> ping
>
> On Sat, Jan 28, 2017 at 03:25:53PM +0100, Theo Buehler wrote:
> > The problem:
> >
> > $ mount /dev/tty /tmp
> > Abort trap (core dumped)
> >
> > The relevant kdump snippet:
> >
> > 45441 mountCALL open(0x7f7eb58
25 matches
Mail list logo