Mark Kettenis <[email protected]> wrote: > > Date: Sun, 28 Nov 2021 14:32:34 +0100 > > From: Martin Pieuchot <[email protected]> > > > > On 08/09/21(Wed) 07:33, Anton Lindqvist wrote: > > > On Tue, Sep 07, 2021 at 09:59:22PM -0500, [email protected] wrote: > > > > >Synopsis: ppp panic: locking against myself > > > > >Category: kernel > > > > >Environment: > > > > System : OpenBSD 6.9 > > > > Details : OpenBSD 6.9 (GENERIC) #2: Tue Aug 10 08:12:32 MDT > > > > 2021 > > > > > > > > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC > > > > > > > > Architecture: OpenBSD.i386 > > > > Machine : i386 > > > > >Description: > > > > Running pppd over a serial modem. (What year is it?) > > > > > > > > Ran pkg_add vim--no_x11, came back a half hour later and it had > > > > panicked while installing the last dependency. > > > > > > > > com0: 2 silo overflows, 0 ibuf overflows > > > > com0: 2 silo overflows, 0 ibuf overflows > > > > com0: 2 silo overflows, 0 ibuf overflows > > > > com0: 1 silo overflow, 0 ibuf overflows > > > > com0: 4 silo overflows, 0 ibuf overflows > > > > panic: mtx 0xd14b3054: locking against myself > > > > Stopped at db_enter+0x4: popl %ebp > > > > panic: mtx 0xd14b3054: locking against myself > > > > Stopped at db_enter+0x4: popl %ebp > > > > TID PID UID PRFLAGS PFLAGS CPU COMMAND > > > > > > > > * 67354 3343 0 0x14000 0x200 0 softnet > > > > > > > > db_enter() at db_enter+0x4 > > > > panic(d0bc8c2b) at panic+0xd3 > > > > mtx_enter(d14b3054) at mtx_enter+0x4e > > > > task_add(d14b3040,d0df4d7c) at task_add+0x1d > > > > ppp_restart(d1511800) at ppp_restart+0x3a > > > > pppstart(d17d2200) at pppstart+0x55 > > > > comintr(d14da000) at comintr+0x4a5 > > > > intr_handler(f17d69d8,d14b3740) at intr_handler+0x18 > > > > Xintr_legacy4_untramp() at Xintr_legacy4_untramp+0xfb > > > > taskq_next_work(d14b3040,f17d6a40) at taskq_next_work+0x8d > > > > taskq_thread(d14b3040) at taskq_thread+0x43 > > > > https://www.openbsd.org/ddb.html describes the minimum info required in > > > > bug > > > > reports. Insufficient info makes it difficult to find and fix bugs. > > > > > > Looks like it's trying to schedule a task while already handling one. > > > The mutex associated with each net task queue have their IPL set to > > > IPL_NET whereas IPL_TTY is probably needed here. > > > > This sounds reasonable, or even IPL_HIGH because the same could happen > > in any "real" interrupt handler, no? > > No. ppp(4) is special since it can be used for dialup connections > through a serial port. Interrupt handlers for normal network devices > run at IP_NET. >
So much lore forgotten This is from the deleted if_sl.c, which is where this problem is stated nicely * Note that splimp() is used throughout to block both (tty) input * interrupts and network activity; thus, splimp must be >= spltty. There were many versions of this hack. soft tty interrupts were supposed to help with solving it. The network aspect has to be deferred in a software way. It looks like PPPDISC was overlooked again.
