-
Ravi K. Nittala authored
The RTAS firmware flash update is conducted using an RTAS call that is serialized by lock_rtas() which uses spin_lock. While the flash is in progress, rtasd performs scan for any RTAS events that are generated by the system. rtasd keeps scanning for the RTAS events generated on the machine. This is performed via workqueue mechanism. The rtas_event_scan() also uses an RTAS call to scan the events, eventually trying to acquire the spin_lock before issuing the request. The flash update takes a while to complete and during this time, any other RTAS call has to wait. In this case, rtas_event_scan() waits for a long time on the spin_lock resulting in a soft lockup. Fix: Just before the flash update is performed, the queued rtas_event_scan() work item is cancelled from the work queue so that there is no other RTAS call issued while the flash is in progress. After the flash completes, the system reboots and the rtas_event_scan() is rescheduled. Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com> Signed-off-by: Ravi Nittala <ravi.nittala@in.ibm.com> Reported-by: Divya Vikas <divya.vikas@in.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
df17f56d