Nicholas Piggin <npig...@gmail.com> writes: > Currently powernv reboot and shutdown requests just leave secondaries > to do their own things. This is undesirable because they can trigger > any number of watchdogs while waiting for reboot, but also we don't > know what else they might be doing, or they might be stuck somewhere > causing trouble. > > The opal scheduled flash update code already ran into watchdog problems > due to flashing taking a long time, but it's possible for regular > reboots to trigger problems too (this is with watchdog_thresh set to 1, > but I have seen it with watchdog_thresh at the default value once too): > > reboot: Restarting system > [ 360.038896709,5] OPAL: Reboot request... > Watchdog CPU:0 Hard LOCKUP > Watchdog CPU:44 detected Hard LOCKUP other CPUS:16 > Watchdog CPU:16 Hard LOCKUP > watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0] > > So remove the special case for flash update, and unconditionally do > smp_send_stop before rebooting. > > Return the CPUs to Linux stop loops rather than OPAL. The reason for > this is that the path to firmware is longer, and the CPUs may have > been interrupted from firmware, which may cause problems to re-enter > it. It's better to put them into a simple spin loop to maximize the > chance of a successful reboot.
I always assumed we had to send the CPUs back to OPAL for the flashing procedure. Is it OK to leave them in Linux? cheers
