On Mon, 2021-08-02 at 09:02 +0200, Sebastian Andrzej Siewior wrote: > On 2021-08-01 17:14:49 [+0200], Mike Galbraith wrote: > > On Sun, 2021-08-01 at 05:36 +0200, Mike Galbraith wrote: > > > On Fri, 2021-07-30 at 22:49 +0200, Thomas Gleixner wrote: > > > > > > > > > > First symptom is KDE/Plasma's task manager going comatose. Notice soon > > > > > > > > KDE/Plasma points at the new fangled rtmutex based ww_mutex from > > > > Peter. > > > > > > Seems not. When booting KVM box with nomodeset, there's exactly one > > > early boot ww_mutex lock/unlock, ancient history at the failure point. > > > > As you've probably already surmised given it isn't the ww_mutex bits, > > it's the wake_q bits. Apply the below, 5.14-rt ceases to fail. Take > > perfectly healthy 5.13-rt, apply those bits, and it instantly begins > > failing as 5.14-rt had been. > > Given what you have replied to the locking thread/ > ww_mutex_lock_interruptible() may I assume that the wake_q bits are fine > and it is just the ww_mutex? Nope. Before I even reverted the wake_q bits, I assembled a tree with the ww_mutex changes completely removed to be absolutely certain that they were innocent, and it indeed did retain its lost wakeup woes despite complete loss of newfangled ww_mutex. 5.13-rt acquired those same wakeup woes by receiving ONLY the wake_q bits, and 5.14-rt was cured of those woes by ONLY them being reverted. I'm not seeing the why, but those bits are either the source or the trigger of 5.14-rt lost wakeup woes... they're toxic in some way shape fashion or form. -Mike
