Re: [linus:master] [sched/fair] 4823725d9d: INFO:task_blocked_for_more_than#seconds

[Oliver Sang]

hi, Peter Zijlstra,

On Wed, May 06, 2026 at 10:23:01AM +0200, Peter Zijlstra wrote:
> On Wed, May 06, 2026 at 04:09:02PM +0800, Oliver Sang wrote:
> > hi, Peter Zijlstra,
> > 
> > On Wed, May 06, 2026 at 09:48:58AM +0200, Peter Zijlstra wrote:
> > > On Wed, May 06, 2026 at 03:06:13PM +0800, Oliver Sang wrote:
> > > 
> > > > we tested upon below commit:
> > > > 0c0cf14be4909 (tip/sched/urgent) sched/fair: Fix wakeup_preempt_fair() for not waking up task
> > > > 
> > > > found most issues are still existing
> > > 
> > > Moo :-(
> > > 
> > > > =========================================================================================
> > > > compiler/kconfig/rootfs/sleep/tbox_group/testcase:
> > > >   gcc-14/i386-randconfig-2006-20250804/yocto-i386-minimal-20190520.cgz/1/vm-snb/boot
> > > > 
> > > > 9fe89f022c05d99c 4823725d9d1d9cc5b36647e0cb8 0c0cf14be490975a7431e9d49fc
> > > > ---------------- --------------------------- ---------------------------
> > > >        fail:runs  %reproduction    fail:runs  %reproduction    fail:runs
> > > >            |             |             |             |             |
> > > >            :499         13%          64:499          5%          23:1001  last_state.booting
> > > >            :499          6%          29:499          3%          13:1001  dmesg.BUG:kernel_hang_in_boot_stage
> > > >            :499          7%          33:499          2%          10:1001  dmesg.BUG:workqueue_lockup-pool
> > > >            :499          0%           1:499          0%           1:1001  dmesg.EIP:_raw_spin_unlock_irqrestore
> > > >            :499          1%           3:499          0%           1:1001  dmesg.EIP:finish_task_switch
> > > >            :499          0%           1:499          0%            :1001  dmesg.EIP:handle_softirqs
> > > >            :499          0%           2:499          0%           1:1001  dmesg.EIP:lock_acquire
> > > >            :499          0%           1:499          0%           2:1001  dmesg.EIP:lock_release
> > > >            :499          0%           1:499          0%            :1001  dmesg.EIP:on_each_cpu_cond_mask
> > > >            :499          0%           1:499          0%            :1001  dmesg.EIP:rcu_preempt_deferred_qs_irqrestore
> > > >            :499          1%           3:499          0%           1:1001  dmesg.INFO:rcu_preempt_detected_stalls_on_CPUs/tasks
> > > >            :499          3%          14:499          2%          10:1001  dmesg.INFO:task_blocked_for_more_than#seconds
> > > > 
> > > > the config used for 0c0cf14be4909 is attached as config-7.1.0-rc1+
> > > > one dmesg from 0c0cf14be4909 for dmesg.INFO:task_blocked_for_more_than#seconds
> > > > is attached as dmesg-0c0cf14be4.decoded.xz
> > > 
> > > Do you have a URL for that yocto image? git grep yocto on the lkp repo
> > > didn't immediately find me one, and I don't appear to have it in my
> > > .lkp/cache either.
> > 
> > it's here:
> > https://download.01.org/0day-ci/lkp-qemu/osimage/yocto/yocto-i386-minimal-20190520.cgz
> 
> Thanks!, however I'm not seeing boot fails.
> 
> I use:
> 
> qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 8 -m 8G -device e1000,netdev=u1 -netdev user,id=u1  -serial stdio -monitor pty -display none -append "earlyprintk=ttyS0,115200 force_early_printk console=ttyS0,115201 debug systemd.log_level=info sysrq_always_enabled ignore_loglevel nokaslr kgdboc=ttyS0" -virtfs local,path=$PWD/,mount_tag=tmp,security_model=none -kernel i386-build/arch/x86/boot/bzImage -initrd yocto-i386-minimal-20190520.cgz
> 
> and have booted the thing at least 10 times now, each time landing in
> the yocto login without issue. Is there anything I'm not doing right?


sorry for the delay, and please disregard this report as it may be noise.

I attempted to reproduce the issue using the above command approximately
1,000 times, and also tried another 1,000 iterations with our reproducer
https://download.01.org/0day-ci/archive/20260505/202605052050.8156b7e0-lkp@xxxxxxxxx/reproduce
However, I was unable to reproduce the issue locally.

I then conducted further investigation within our cluster, but found little
evidence to confirm the possible root causes.

we will definitely investigate further to either avoid generating less
meaningful reports or provide an easier reproducer.
Thank you for your patience.