On 2020-04-08 01:23, Mark Johnston wrote:
On Mon, Apr 06, 2020 at 02:34:50PM -0700, Eric Joyner wrote:
On Mon, Apr 6, 2020 at 2:29 PM Mark Johnston <ma...@freebsd.org> wrote:
On Mon, Apr 06, 2020 at 02:19:25PM -0700, Eric Joyner wrote:
Mark,
I think I was mistaken about the backtrace looking the same. I was
looking
at it from within ddb, and I think I focused on the
epoch_block_handler_preempt line and didn't notice that it only stopped
there this time. Here's the new one I've got from kgdb:
Thanks. Could you try to print "td->td_name" from frame 4? It should
also be available as er->er_blockedtd. Basically, I'm trying to verify
that the interrupt thread itself isn't the one that we're waiting for,
else there is another bug to be fixed.
If you can provide kernel symbols and vmcore, I'd be happy to look at it
myself.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Here's what I get:
(kgdb) frame 4
#4 epoch_block_handler_preempt (global=0xfffff80003de0100,
cr=0xfffffe00dee85900, arg=0x0) at /usr/src/sys/kern/subr_epoch.c:507
507 }
(kgdb) print td->td_name
$1 = "if_io_tqg_31\000\000\000\000\000\000\000"
(kgdb) print er->er_blockedtd
$2 = (struct thread *) 0x0
I spent some time looking at the core. It looks like we have yet
another problem: the gtaskqueue code won't exit the net epoch if it is
constantly running a net task. Could you please retry with the patches
from before, and this one included?
There is the same issue in kern_intr.c (FYI).
--HPS
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
