Re: [EXTERNAL] Re: Btrfs PREEMPT_RT transaction-waiter livelock: experimental mitigation in kernel 6.6.78

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-13 15:29:39 [+0000], Naulls, Peter wrote:
> With apologies for Outlook formatting, it's not my first choice. 
> 
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> 
> > This sort of sounds like the state is TRANS_STATE_SUPER_COMMITTED but is
> > not making progress after that. Are there any tasks involved that run at
> > realtime priority and would block other tasks from making progress?
> 
> I won't say it's impossible, but it's not likely. We have a monolithic app which is disabled for this test. There 
> may be other subsystems writing to the log. To the best of my knowledge though, there's been no adjustment
> of priorities (we are experimenting with this, but it's inside the app and wasn't turned on for this test)  vs default 
> Linux setup - it is Yocto using a largely standard setup. 

in that case ps should report just SCHED_OTHER for most applications and
SCHED_FIFO for the threaded interrupts and a few others.
The tasks that are running during the test-case should be all
SCHED_OTHER.

> > Could you try if you can reproduce this with v7.3-rc7? This one does not
> > require any additional patches.
> > I'm not sure if this report would help the btrfs folks to recognize if
> > this is a solved problem or where the issue might be.
> 
> Trying a later kernel is not impossible, but it somewhat time
> consuming, I will have to strip a number of things from the build, 
> and Yocto doesn't make this particularly straightforward, and might
> even compromise the test. We will update the kernel 
> in due course, but you'll understand I'd prefer not to commit this
> time without some degree of confirmation here.  As things
> stand right now, it may be that we just run without RT, but it would
> be good to at least verify this, and have a record for 
> other people. 

Right. You could try just the bare-kernel and yocto's .config without
anything else. And then just replace the kernel (and modules) on the
target. If this procedure can reproduce the bug on the latest kernel
then it is still around. Otherwise it is either fixed or something
changed and it does not reproduce anymore.

> As for brtfs, yes that was my next follow up, I had been just about to
> do that before your reply. 

I'm not a btrfs guy myself so I kind tell if this gives people enough
clues to as what is going on.

> Regards. 

Sebastian