Re: Resume from swsusp stopped working with 2.6.14 and 2.6.15-rc1

[Bjørn Mork]

Pavel Machek <pavel@xxxxxx> writes:

>> I don't think so.  The example said
>> 
>>  "Strange, kseriod not stopped"
>> 
>> This names a process that admittedly took a long time to stop, but not
>> the real *cause* of the failure.  There was nothing wrong with kseriod.
>> 
>> FWIW, debugging this was way out of my league.  I might have had a
>> better chance if it mentioned a short, fixed timeout.  I also noticed
>> that it wasn't very obvious to you either at first.  The first thought
>> was a failing serio driver, although that admittedly might be because
>> I mislead you in my attempt to pinpoint the failure.
>
> Ok, can you suggest better wording?

maybe something like 

--- linux-2.6.15-rc1/kernel/power/process.c.orig	2005-11-18 10:15:12.000000000 +0100
+++ linux-2.6.15-rc1/kernel/power/process.c	2005-11-23 13:38:41.000000000 +0100
@@ -83,7 +83,7 @@
 		yield();			/* Yield is okay here */
 		if (todo && time_after(jiffies, start_time + TIMEOUT)) {
 			printk( "\n" );
-			printk(KERN_ERR " stopping tasks failed (%d tasks remaining)\n", todo );
+			printk(KERN_ERR " stopping tasks timed out after %d seconds (%d tasks remaining)\n", TIMEOUT/HZ, todo );
 			break;
 		}
 	} while(todo);


?

Or basically any text that makes it clear that we didn't really try
that hard to stop the task.  We just gave up early.

I thought about adding /sys/power/timeout too, but realised that it is
way overkill for this.  Ideally, the default should never need to be
changed by anynoe.

I'd really prefer Dmitry's approach with an indefinite timeout on
resume, but I also understand your wish to avoid letting this code
know whether it's suspending or resuming.  No, I don't know how to
satisfy both of those requirements either.  Increasing the default
TIMEOUT to a pretty-sure-to-never-be-reached value is probably an
acceptable workaround.



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