Date: Tue, 23 Mar 2021 20:56:21 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 254514] vnet: /sbin/ifconfig epair10b vnet $name getting stuck if one CPU is busy Message-ID: <bug-254514-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254514 Bug ID: 254514 Summary: vnet: /sbin/ifconfig epair10b vnet $name getting stuck if one CPU is busy Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: me@igalic.co This bug bubbled up as a side-effect to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254513 jail startup is stuck at: /sbin/ifconfig epair10b vnet $name when we run procstat kstack, we see for the different jails: 913 100682 ifconfig - mi_switch _sx_xlock_ha= rd epoch_drain_callbacks if_detach_internal if_vmove ifhwioctl ifioctl kern_io= ctl sys_ioctl amd64_syscall fast_syscall_common=20 835 100475 ifconfig - mi_switch sched_bind epoch_drain_callbacks if_detach_internal if_vmove ifhwioctl ifioctl kern_io= ctl sys_ioctl amd64_syscall fast_syscall_common=20 similarly, trying to destroy an epair also gets stuck: 1119 100988 ifconfig - mi_switch _sx_xlock_ha= rd epoch_drain_callbacks if_detach_internal if_detach epair_clone_destroy if_clone_destroyif if_clone_destroy ifioctl kern_ioctl sys_ioctl amd64_sysc= all fast_syscall_common=20 given that this is a side-effect of 1 CPU core being 100% busy, does this m= ean that draining callbacks needs all CPUs? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254514-227>