Re: SMP suspend broken due to "swsusp: Change code ordering in disk.c" et al.

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2445 bytes --]

Hi,

> In that case the fastest fix would be to revert the commit in question (and
> some others too),

Yeah, the same thing exists for uswsusp and regular suspend-to-ram
afaict.

> but I don't think it will be satisfactory for the people with
> the ACPI issues related to the resume code ordering.  Moreover, it really
> is more reasonable to disable nonboot CPUs after tasks have been frozen
> (I think it's also necessary for the CPU hotplugging with the help of the
> freezer; see below).
> 
> I'll try to find a better solution later today.

Great.

> [Why, o why people don't test -mm kernels???  The patch that causes the problem
> has been in -mm since 2.6.20-rc2-mm1 and _nobody_ has reported any problem
> with it until now.  Sigh.]

Sorry. It's hard enough to follow powerpc.git and keep my suspend
patches working on top of that.

> The idea is to freeze tasks every time before CPUs are hot(un)plugged.  This
> way we can avoid nasty locking-related issues that have been haunting us
> for some time.  And yes, we are going to freeze all tasks for this purpose,
> although it seems inefficient at first sight.

It's not like CPU hotplug is very frequent so that's perfectly fine to
me.

> Of course if we do it, the suspend code will have to be changed so that the
> freezing of tasks related to the CPU hotplug doesn't interfere with the
> freezing of tasks related to the suspend in a destructive way.  Then, probably,
> the problem you have discovered will go away automatically.

Yeah, I agree that would probably fix it, but the freezer guarantee
becomes slightly less, you have some (most) tasks frozen and some then
need to exit the freezer again to cleanly exit. I'm not sure you can do
that w/o getting into possible trouble with locking, i.e. imagine the
cleanup-path needing to wait for completion of some other event from a
thread that's frozen... (not that I'm sure whether that's legal or not
anyway)

> For this reason I'd like to keep the ordering of code in disk.c as it is now,
> because something like

[...]

> seems to be more logical than any other ordering.

I used to think of CPU hotplug as a simple mechanism to avoid multi-CPU
problems so I was perfectly fine with disabling them very early during
suspend. I can't really see what problems ACPI might have with that
since the user can anyway do echo 0 > cpu3/online before suspend, no?

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]