Claudio Jeker wrote:
> Thanks for the details. I suggest to commit this so we can get some tests
> quickly and hopefully it helps to fix some of the wg(4) crashes people
> hit. According to your other mail there are some additional races that
> require fixing.
quickly means now, and we have
On Tue, Mar 05, 2024 at 12:16:37PM +0300, Vitaliy Makkoveev wrote:
> On Mon, Mar 04, 2024 at 01:00:32PM +0100, Claudio Jeker wrote:
> > On Wed, Feb 28, 2024 at 06:03:14PM +0300, Vitaliy Makkoveev wrote:
> > > On Wed, Feb 28, 2024 at 02:45:44PM +0100, Martin Pieuchot wrote:
> > > > > > >
> > > > >
On Mon, Mar 04, 2024 at 01:00:32PM +0100, Claudio Jeker wrote:
> On Wed, Feb 28, 2024 at 06:03:14PM +0300, Vitaliy Makkoveev wrote:
> > On Wed, Feb 28, 2024 at 02:45:44PM +0100, Martin Pieuchot wrote:
> > > > > >
> > > > > > Not only wg(4). Depends on interface queue usage, ifq_start()
> > > > >
On Wed, Feb 28, 2024 at 06:03:14PM +0300, Vitaliy Makkoveev wrote:
> On Wed, Feb 28, 2024 at 02:45:44PM +0100, Martin Pieuchot wrote:
> > > > >
> > > > > Not only wg(4). Depends on interface queue usage, ifq_start()
> > > > > schedules
> > > > > (*if_qstart)() or calls it, so all the interfaces
On Wed, Feb 28, 2024 at 02:45:44PM +0100, Martin Pieuchot wrote:
> > > >
> > > > Not only wg(4). Depends on interface queue usage, ifq_start() schedules
> > > > (*if_qstart)() or calls it, so all the interfaces with use rwlock(9) in
> > > > (*if_qstart)() handler are in risk.
> > > >
> > > >
> > > > > Below is manual transcript of whole screenshot, hopefully no typos.
> > > > >
> > > > > If you have any advice on what should I do if it happens again in
> > > > > order
> > > > > to get as much info for
;
> > > Below is manual transcript of whole screenshot, hopefully no typos.
> > >
> > > If you have any advice on what should I do if it happens again in order
> > > to get as much info for debuggers as possible, please let me know.
> > >
> > >
If you have any advice on what should I do if it happens again in order
> > > > to get as much info for debuggers as possible, please let me know.
> > > >
> > > > splassert: assertwaitok: want 0 have 4
> > > > panic: kernel diagnostic assertion &quo
on what should I do if it happens again in order
> > to get as much info for debuggers as possible, please let me know.
> >
> > splassert: assertwaitok: want 0 have 4
> > panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file
> > "/
subsystems are involved.
> > >
> > > Below is manual transcript of whole screenshot, hopefully no typos.
> > >
> > > If you have any advice on what should I do if it happens again in order
> > > to get as much info for debuggers as possible, please let me know.
&g
ave any advice on what should I do if it happens again in order
> > to get as much info for debuggers as possible, please let me know.
> >
> > splassert: assertwaitok: want 0 have 4
> > panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file
> >
now.
>
> splassert: assertwaitok: want 0 have 4
> panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file
> "/usr/src/sys/kern/kern_sched.c", line 373
> Stopped at db_enter+0x14: popq %rbp
>TIDPID UID PRFLAGS PFLAGS CPU COMMAND
&g
whole screenshot, hopefully no typos.
If you have any advice on what should I do if it happens again in order
to get as much info for debuggers as possible, please let me know.
splassert: assertwaitok: want 0 have 4
panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file
Please try to re-type at least the most important bits from a
screenshot so readers can quickly see which subsystems are involved.
splassert: assertwaitok: want 0 have 4
assertion p->wchan == NULL failed, kern_sched.c line 373
active procs: openvpn wg_handshake softnet0
trace includes
>Synopsis: panic: kernel diagnostic assertion "p->p_wchan == NULL" failed
>Category: kernel
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #359: Sun Jul 19
01:36:17 MDT 2020
dera...@
15 matches
Mail list logo
