> sds.total_pwr is the sum of the power of all CPUs in the scheduling domain. This sum ends up being zero and that’s what causing the crash – division by zero.
> The “CPU power” is used to take into account how much calculating capabilities a CPU has compared to the other CPUs and the main factors for calculating it are:
> 1. Whether the CPU is shared, for example by using multithreading.
> 2. How many real-time tasks the CPU is processing.
> 3. In newer kernels, how much time the CPU had spent processing IRQs.
> The current suggested fix for this bug is relying on the theory that while taking into account the real-time tasks (#2 above), scale_rt_power() could return negative value, and thus the sum of all CPU powers may end up being zero.
The author doesn't really describe how this panic is related to uptime. Do long running kernels collect a lot of real-time tasks, is it a leak of some kind?
The suggested fix link doesn't provide any extra context as to why its uptime related either.
> The “CPU power” is used to take into account how much calculating capabilities a CPU has compared to the other CPUs and the main factors for calculating it are:
> 1. Whether the CPU is shared, for example by using multithreading.
> 2. How many real-time tasks the CPU is processing.
> 3. In newer kernels, how much time the CPU had spent processing IRQs.
> The current suggested fix for this bug is relying on the theory that while taking into account the real-time tasks (#2 above), scale_rt_power() could return negative value, and thus the sum of all CPU powers may end up being zero.
The author doesn't really describe how this panic is related to uptime. Do long running kernels collect a lot of real-time tasks, is it a leak of some kind?
The suggested fix link doesn't provide any extra context as to why its uptime related either.