This bug is awaiting verification that the linux-
bluefield/5.15.0-1012.14 kernel in -proposed solves the problem. Please
test the kernel and update this bug with the results. If the problem is
solved, change the tag 'verification-needed-jammy' to 'verification-
done-jammy'. If the problem still exists, change the tag 'verification-
needed-jammy' to 'verification-failed-jammy'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See for documentation how
to enable and use -proposed. Thank you!

** Tags added: kernel-spammed-jammy-linux-bluefield verification-needed-jammy

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.

  tick/rcu: Stop allowing RCU_SOFTIRQ in idle

Status in linux-bluefield package in Ubuntu:
Status in linux-bluefield source package in Focal:
  Fix Committed
Status in linux-bluefield source package in Jammy:
  Fix Committed

Bug description:
  * Explain the bug
      RCU_SOFTIRQ used to be special in that it could be raised on purpose
      within the idle path to prevent from stopping the tick. Some code still
      prevents from unnecessary warnings related to this specific behaviour
      while entering in dynticks-idle mode.

      However the nohz layout has changed quite a bit in ten years, and the
      removal of CONFIG_RCU_FAST_NO_HZ has been the final straw to this
      safe-conduct. Now the RCU_SOFTIRQ vector is expected to be raised from
      sane places.

  * Brief explanation of fixes
  Stop allowing RCU_SOFTIRQ in idle
  * How to test
  In boot dmesg, the warning should be gone.
  * What it could break.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to