lkml.org 
[lkml]   [2008]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[Regression] Suspend failure on NForce4-based boards due to chanes in stop_machine
Date
Hi,

Current mainline (.28-rc3 at the moment) fails to suspend on at least some
machines with dual-core AMD CPUs and NForce4-based mainboards. The affected
boxes just hang solid during suspend/hibernation, after suspending devices,
probably while the non-boot CPUs are being stopped (I'm able to reproduce this
on two different machines).

Although this is not reproducible 100% of the time, it is reproducible enough
to allow me to carry out bisection, which turned up the following commit as the
source of the problem:

commit c9583e55fa2b08a230c549bd1e3c0bde6c50d9cc
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Mon Oct 13 23:50:10 2008 +0200

stop_machine: use workqueues instead of kernel threads

Convert stop_machine to a workqueue based approach. Instead of using kernel
threads for stop_machine we now use a an rt workqueue to synchronize all
cpus.
This has the advantage that all needed per cpu threads are already created
when stop_machine gets called. And therefore a call to stop_machine won't
fail anymore. This is needed for s390 which needs a mechanism to synchronize
all cpus without allocating any memory.
As Rusty pointed out free_module() needs a non-failing stop_machine interface
as well.

As a side effect the stop_machine code gets simplified.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

With this commit reverted, suspend/hibernation works on the affected machines
without any problems.

Thanks,
Rafael


\
 
 \ /
  Last update: 2008-11-03 01:27    [W:0.030 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site