Bug 6787
Summary: | suspend to ram fails when process is being debugged | ||
---|---|---|---|
Product: | Power Management | Reporter: | Jeremy Fitzhardinge (jeremy) |
Component: | Other | Assignee: | Rafael J. Wysocki (rjwysocki) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | pavel, rjwysocki |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.17-mm6 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
Debug patch
Fix candidate Better fix |
Description
Jeremy Fitzhardinge
2006-07-03 14:49:44 UTC
It would be nice to get rjw@sisk.pl to Cc, but he apparently does not have bugzilla account (or has it under different name?) Okay, I can reproduce it on fairly recent 2.6.17-git. I think the "freeze" signal is catched due to ptrace() before the process has a chance to go to the refrigerator. Then the parent is supposed to do something, but if it's already frozen, it can't. If that's what really happens, the signal-handling code will need a fix. Created attachment 8555 [details]
Debug patch
More precisely, if the ptraced task has already hit a breakpoint, it is in the
TASK_TRACED state and we can't deliver any signals directly to it until the
parent decides what to do with it. However, if the parent is frozen, it can't
do anything and the ptraced task becomes unfreezeable. Thus it seems we should
treat it as such in kernel/power/process.c#freezeable(). If that really is the
case, this patch should help, so please try it.
Created attachment 8561 [details]
Fix candidate
This patch should fix the problem (works on my box).
I believe it won't break any other corner cases related to the tracing of
tasks. :-)
Created attachment 8625 [details]
Better fix
This patch fixes the problem on my box.
|