swsusp doesn't suspend devices

[Pierre Ossman <drzeus-list@drzeus.cx>]

It would seem that swsusp doesn't properly suspend devices, or more
precisely it wakes them up again before suspending the machine.

The problem is in swsusp_suspend(). It is designed as if
swsusp_arch_suspend() would suspend the hardware, when in fact all it
does is prepare for a suspend. The effect is that devices are brought
back up because swsusp_suspend() believes it is resuming.

Below is a patch that uses the same system as kernel/power/disk.c to
determine if it's suspending or resuming. The patch brings up a new
problem though, disk writes generate a huge amount of "scheduling while
atomic".

---

Index: linux-wbsd/kernel/power/swsusp.c
===================================================================
--- linux-wbsd/kernel/power/swsusp.c    (revision 165)
+++ linux-wbsd/kernel/power/swsusp.c    (working copy)
@@ -84,6 +84,8 @@
 /* Local variables that should not be affected by save */
 static unsigned int nr_copy_pages __nosavedata = 0;

+static int in_suspend __nosavedata = 0;
+
 /* Suspend pagedir is allocated before final copy, therefore it
    must be freed after resume

@@ -897,15 +899,18 @@
                return error;
        }

+       in_suspend = 1;
        save_processor_state();
        if ((error = swsusp_arch_suspend()))
                printk("Error %d suspending\n", error);
-       /* Restore control flow magically appears here */
-       restore_processor_state();
-       BUG_ON (nr_copy_pages_check != nr_copy_pages);
-       restore_highmem();
-       device_power_up();
-       local_irq_enable();
+       if (!in_suspend || error) {
+               /* Restore control flow magically appears here */
+               restore_processor_state();
+               BUG_ON (nr_copy_pages_check != nr_copy_pages);
+               restore_highmem();
+               device_power_up();
+               local_irq_enable();
+       }
        return error;
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/