On Sun, 26 Sep 2021 12:16:55 -0400 Alexander Motin <m...@freebsd.org> wrote:
> Thank you for the notification. 08063e9f98a should fix the hang. Thanks for the fix! Rebuilt, Several reboots with varying 0, 1, commented out whole line for kern.sched.steal_thresh and all went fine. > I just want to add that lowering kern.sched.steal_thresh below 2 should > not be a proper fix for any problem, but only a workaround. I guess > either some CPU can't wake up from sleep for too long, or the wakeup > interrupt is not properly sent to it when the load is assigned. In such > case stealing makes other CPU to do the work instead. It would be good > to find and fix the real problem. For me (with Core i7-8750H), lowering kern.sched.steal_thresh didn't made significant improvement but had no reason to go back to default. *As sched_ule got modified now, I'm trying default kern.sched.steal_thresh value now. In the other hand, at least some Ryzen users seem to have much more severe problem than me and the workaround make significant imrovement. > On 25.09.2021 21:47, Konstantin Belousov wrote: > > On Sun, Sep 26, 2021 at 10:23:47AM +0900, Tomoaki AOKI wrote: > >> On Sat, 25 Sep 2021 23:46:48 +0300 > >> Andriy Gapon <a...@freebsd.org> wrote: > >> > >>> On 25/09/2021 19:10, Johan Hendriks wrote: > >>>> For me i had kern.sched.steal_thresh=1 in my sysctl as i use this > >>>> machine mainly > >>>> for tests and so on. > >>>> By removing this sysctl the system boots again. I already used the > >>>> latest > >>>> snapshot and that booted fine. > >>> > >>> Might have something to do with > >>> https://cgit.FreeBSD.org/src/commit/?id=bd84094a51c4648a7c97ececdaccfb30bc832096 > >>> > >>> -- > >>> Andriy Gapon > >> > >> Commenting out kern.sched.steal_thresh=0 line in /etc/sysctl.conf let > >> me boot fine. No other setting of kern.sched.* affected. > >> I've introduced the setting by reading posts [1] and [2] on > >> freebsd-current ML. Thanks for the hint, Jan! > >> > >> Andriy, I took time to bi-sect and determined the commit triggered > >> this issue was e745d729be60. [3] > >> Worked OK even with kern.sched.steal_thresh=0 at a342ecd326ee. [4] > >> > >> Tested commits are as below (tested order, not using git bisect): > >> 0b79a76f8487: [Known to be OK] > >> 8db1669959ce: [Problematic rev I first encountered] > >> 0f6829488ef3: OK > >> df8dd6025af8: OK > >> 4f917847c903: OK > >> e745d729be60: NG! > >> bd84094a51c4: OK > >> a342ecd326ee: OK > >> > >> Konstantin, no more chance to get into ddb on hang up until my previous > >> post. ^T never worked on hang up situation. Sory. But does info above > >> help? > > Let the author of the commit look. > > > >> > >> > >> [1] > >> https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079237.html > >> > >> [2] > >> https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079240.html > >> > >> [3] > >> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007513.html > >> > >> [4] > >> https://lists.freebsd.org/pipermail/dev-commits-src-main/2021-September/007512.html > >> > >> -- > >> Tomoaki AOKI <junch...@dec.sakura.ne.jp> > > -- > Alexander Motin > -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
