> Date: Tue, 7 Nov 2017 22:58:39 +0100
> From: Edgar =?iso-8859-1?B?RnXf?=
>
> I got the following panic on a mostly idle 6.1/amd64:
>
> Mutex error: mutex_vector_enter: locking against myself
> [...]
> mutex_vector_enter() at netbsd:mutex_vector_enter+0x3df
> filt_rndread() at netbsd:filt_rndre
> Date: Tue, 7 Nov 2017 22:58:39 +0100
> From: Edgar Fuß
>
> I got the following panic on a mostly idle 6.1/amd64:
>
> Mutex error: mutex_vector_enter: locking against myself
>
> and then the machine got stuck. It's a development server, so I can
> leave it stuck until tomorrow in case someone
> Not surprising: cprng locking was completely hosed in netbsd-6 until
> it got rewritten for netbsd-7.
So I can expect all of my servers to panic at any time?
Can I mitigate the probability of the panic?
> Date: Wed, 8 Nov 2017 11:22:26 +0100
> From: Edgar Fuß
>
> > Not surprising: cprng locking was completely hosed in netbsd-6 until
> > it got rewritten for netbsd-7.
> So I can expect all of my servers to panic at any time?
> Can I mitigate the probability of the panic?
If you can guarantee eit
Short: Your patch seems to work.
Long: I don't quite understand the behaviour, but at least, it doesn't panic.
I wrote a test programm (my first encounter with kqueue, so probably wrong)
to exercise EVFILT_READ.
I created a named pipe and it did approximately what I expected (on start,
it hung
> Date: Fri, 10 Nov 2017 13:58:51 +0100
> From: Edgar Fuß
>
> Short: Your patch seems to work.
Pullup request submitted:
https://releng.netbsd.org/cgi-bin/req-6.cgi?show=1512
> Long: I don't quite understand the behaviour, but at least, it doesn't panic.
>
> I wrote a test programm (my first e