[PATCH] 2.5.64 ACPI suspend/resume locking fix

• Next message: Andrea Arcangeli: "Re: [PATCH 2.5.64 2/2] i_size atomic access"
• Previous message: Ed Tomlinson: "Re: 2.5.64-mm2->4 hangs on contest"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

doing an
echo 1 >/proc/acpi/sleep
caused quite some trouble on resume, such as
bad: scheduling while atomic!
Call Trace:
 [<c011d4c0>] schedule+0x220/0x230
 [<c0140608>] __pdflush+0x98/0x1e0
 [<c0140750>] pdflush+0x0/0x20
 [<c0140761>] pdflush+0x11/0x20
 [<c010826d>] kernel_thread_helper+0x5/0x18

(see BugZilla #455).

Turned out that the suspend handling in __pdflush() was abusing
pdflush_lock, by not relocking before going back up the loop (which then
unlocked again --> refcount -1 --> haywire!).

With the locking fix below,
doing
echo 1 >/proc/acpi/sleep
now suspends/resumes beautifully without giving further errors.

Note that my machine still gets killed completely if I do
echo 3 >/proc/acpi/sleep
, however. Any ideas? How to debug this?

Thanks,

Andreas Mohr

--- mm/pdflush.c.org 2003-03-10 14:04:00.000000000 +0100
+++ mm/pdflush.c 2003-03-10 13:14:57.000000000 +0100
@@ -106,6 +106,7 @@
                 schedule();
                 if (current->flags & PF_FREEZE) {
                         refrigerator(PF_IOTHREAD);
+ spin_lock_irq(&pdflush_lock);
                         continue;
                 }
 

-- 
Andreas Mohr                        Stauferstr. 6, D-71272 Renningen, Germany
-
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/

• Next message: Andrea Arcangeli: "Re: [PATCH 2.5.64 2/2] i_size atomic access"
• Previous message: Ed Tomlinson: "Re: 2.5.64-mm2->4 hangs on contest"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:21 EST