* windfarm got signal
@ 2006-06-20 23:51 ` Johannes Berg
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-20 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 627 bytes --]
Hey,
after cpu hotplug I decided to write some fake suspend routines for
ppc64 that always fail to see what all the drivers would say... The
first thing I saw was during the phase where all threads are stopped,
that windfarm got a signal!
Shortly after that, the fans were revved up fully but I guess that's
expected if the wf control loop exits.
So now I'm trying to see *why* it got a signal there. Any ideas? Is that
expected with pm and windfarm just does the wrong thing there by taking
the signal as a reason to exit the control thread?
[code in question is windfarm_core.c:wf_thread_func]
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* windfarm got signal
@ 2006-06-20 23:51 ` Johannes Berg
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-20 23:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linux-pm
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hey,
after cpu hotplug I decided to write some fake suspend routines for
ppc64 that always fail to see what all the drivers would say... The
first thing I saw was during the phase where all threads are stopped,
that windfarm got a signal!
Shortly after that, the fans were revved up fully but I guess that's
expected if the wf control loop exits.
So now I'm trying to see *why* it got a signal there. Any ideas? Is that
expected with pm and windfarm just does the wrong thing there by taking
the signal as a reason to exit the control thread?
[code in question is windfarm_core.c:wf_thread_func]
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: windfarm got signal
2006-06-20 23:51 ` Johannes Berg
(?)
@ 2006-06-22 6:02 ` Benjamin Herrenschmidt
2006-06-22 11:03 ` [linux-pm] " Rafael J. Wysocki
-1 siblings, 1 reply; 18+ messages in thread
From: Benjamin Herrenschmidt @ 2006-06-22 6:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, linux-pm
On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> Hey,
>
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
I think it's the way the freezer works ... it sends a pseudo signal to
all kernel threads who are then supposed to do something like test for
PF_FREEZE or something like that.
Ben.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: windfarm got signal
2006-06-22 6:02 ` Benjamin Herrenschmidt
@ 2006-06-22 11:03 ` Rafael J. Wysocki
0 siblings, 0 replies; 18+ messages in thread
From: Rafael J. Wysocki @ 2006-06-22 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Johannes Berg, linux-pm
On Thursday 22 June 2006 08:02, Benjamin Herrenschmidt wrote:
> On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> > Hey,
> >
> > after cpu hotplug I decided to write some fake suspend routines for
> > ppc64 that always fail to see what all the drivers would say... The
> > first thing I saw was during the phase where all threads are stopped,
> > that windfarm got a signal!
> >
> > Shortly after that, the fans were revved up fully but I guess that's
> > expected if the wf control loop exits.
> >
> > So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> > expected with pm and windfarm just does the wrong thing there by taking
> > the signal as a reason to exit the control thread?
> >
> > [code in question is windfarm_core.c:wf_thread_func]
>
> I think it's the way the freezer works ... it sends a pseudo signal to
> all kernel threads who are then supposed to do something like test for
> PF_FREEZE or something like that.
Yes. More precisely, they are supposed to use try_to_freeze().
Please see Documentation/power/kernel_threads.txt.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
@ 2006-06-22 11:03 ` Rafael J. Wysocki
0 siblings, 0 replies; 18+ messages in thread
From: Rafael J. Wysocki @ 2006-06-22 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Johannes Berg, linux-pm
On Thursday 22 June 2006 08:02, Benjamin Herrenschmidt wrote:
> On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> > Hey,
> >
> > after cpu hotplug I decided to write some fake suspend routines for
> > ppc64 that always fail to see what all the drivers would say... The
> > first thing I saw was during the phase where all threads are stopped,
> > that windfarm got a signal!
> >
> > Shortly after that, the fans were revved up fully but I guess that's
> > expected if the wf control loop exits.
> >
> > So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> > expected with pm and windfarm just does the wrong thing there by taking
> > the signal as a reason to exit the control thread?
> >
> > [code in question is windfarm_core.c:wf_thread_func]
>
> I think it's the way the freezer works ... it sends a pseudo signal to
> all kernel threads who are then supposed to do something like test for
> PF_FREEZE or something like that.
Yes. More precisely, they are supposed to use try_to_freeze().
Please see Documentation/power/kernel_threads.txt.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
2006-06-22 11:03 ` [linux-pm] " Rafael J. Wysocki
@ 2006-06-22 11:13 ` Johannes Berg
-1 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-22 11:13 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linuxppc-dev list
[-- Attachment #1.1: Type: text/plain, Size: 496 bytes --]
On Thu, 2006-06-22 at 13:03 +0200, Rafael J. Wysocki wrote:
> > I think it's the way the freezer works ... it sends a pseudo signal to
> > all kernel threads who are then supposed to do something like test for
> > PF_FREEZE or something like that.
>
> Yes. More precisely, they are supposed to use try_to_freeze().
>
> Please see Documentation/power/kernel_threads.txt.
Thanks, I'll look and submit a patch. It does try_to_freeze() but also
checks for pending signals.
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
@ 2006-06-22 11:13 ` Johannes Berg
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-22 11:13 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Thu, 2006-06-22 at 13:03 +0200, Rafael J. Wysocki wrote:
> > I think it's the way the freezer works ... it sends a pseudo signal to
> > all kernel threads who are then supposed to do something like test for
> > PF_FREEZE or something like that.
>
> Yes. More precisely, they are supposed to use try_to_freeze().
>
> Please see Documentation/power/kernel_threads.txt.
Thanks, I'll look and submit a patch. It does try_to_freeze() but also
checks for pending signals.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
2006-06-22 11:13 ` Johannes Berg
@ 2006-06-22 11:34 ` Johannes Berg
-1 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-22 11:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 457 bytes --]
On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> checks for pending signals.
Ah. The code is just in the wrong order:
while (!kthread_should_stop()) {
try_to_freeze();
...
schedule_timeout_interruptible(...);
if (signal_pending())
break;
}
Would it be correct to just move the try_to_freeze() before the
signal_pending() statement?
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [linux-pm] windfarm got signal
@ 2006-06-22 11:34 ` Johannes Berg
0 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-22 11:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, linux-pm
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> checks for pending signals.
Ah. The code is just in the wrong order:
while (!kthread_should_stop()) {
try_to_freeze();
...
schedule_timeout_interruptible(...);
if (signal_pending())
break;
}
Would it be correct to just move the try_to_freeze() before the
signal_pending() statement?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: windfarm got signal
2006-06-22 11:34 ` Johannes Berg
@ 2006-06-22 12:33 ` Nigel Cunningham
-1 siblings, 0 replies; 18+ messages in thread
From: Nigel Cunningham @ 2006-06-22 12:33 UTC (permalink / raw)
To: linux-pm; +Cc: linuxppc-dev list, Johannes Berg
[-- Attachment #1.1: Type: text/plain, Size: 1028 bytes --]
Hi.
On Thursday 22 June 2006 21:34, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
>
> Ah. The code is just in the wrong order:
> while (!kthread_should_stop()) {
> try_to_freeze();
> ...
> schedule_timeout_interruptible(...);
> if (signal_pending())
> break;
> }
>
> Would it be correct to just move the try_to_freeze() before the
> signal_pending() statement?
Hmm. Will kthread_should_stop() be set if it should really exit? If so,
perhaps you can just remove the signal_pending() check. Otherwise, you'd want
to change the signal_pending() test to something like the "if
(signal_pending() && !try_to_freeze())" to avoid any possibility of a race.
(In this case, you should be able to remove the try_to_freeze() from above).
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [linux-pm] windfarm got signal
@ 2006-06-22 12:33 ` Nigel Cunningham
0 siblings, 0 replies; 18+ messages in thread
From: Nigel Cunningham @ 2006-06-22 12:33 UTC (permalink / raw)
To: linux-pm; +Cc: Rafael J. Wysocki, linuxppc-dev list, Johannes Berg
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hi.
On Thursday 22 June 2006 21:34, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
>
> Ah. The code is just in the wrong order:
> while (!kthread_should_stop()) {
> try_to_freeze();
> ...
> schedule_timeout_interruptible(...);
> if (signal_pending())
> break;
> }
>
> Would it be correct to just move the try_to_freeze() before the
> signal_pending() statement?
Hmm. Will kthread_should_stop() be set if it should really exit? If so,
perhaps you can just remove the signal_pending() check. Otherwise, you'd want
to change the signal_pending() test to something like the "if
(signal_pending() && !try_to_freeze())" to avoid any possibility of a race.
(In this case, you should be able to remove the try_to_freeze() from above).
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
2006-06-22 11:34 ` Johannes Berg
(?)
(?)
@ 2006-06-27 7:44 ` Benjamin Herrenschmidt
2006-06-27 18:17 ` [PATCH] fix windfarm core thread wrt. signal handling Johannes Berg
-1 siblings, 1 reply; 18+ messages in thread
From: Benjamin Herrenschmidt @ 2006-06-27 7:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rafael J. Wysocki, linuxppc-dev list, linux-pm
On Thu, 2006-06-22 at 13:34 +0200, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
>
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
>
> Ah. The code is just in the wrong order:
The code should be
while (!kthread_should_stop()) {
try_to_freeze();
...
schedule_timeout_interruptible(...);
}
That is, I think we just don't care about the signal stuff.
Care to do a new patch ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH] fix windfarm core thread wrt. signal handling
2006-06-27 7:44 ` Benjamin Herrenschmidt
@ 2006-06-27 18:17 ` Johannes Berg
2006-06-27 22:07 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 18+ messages in thread
From: Johannes Berg @ 2006-06-27 18:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Rafael J. Wysocki, linuxppc-dev list, linux-pm
This patch removes the signal_pending() from the windfarm core thread
loop as it isn't necessary and messes up when there actually *is* a
signal pending because we should enter the freezer.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
index ab3faa7..c05a838 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -116,12 +116,6 @@ static int wf_thread_func(void *data)
delay = next - jiffies;
if (delay <= HZ)
schedule_timeout_interruptible(delay);
-
- /* there should be no signal, but oh well */
- if (signal_pending(current)) {
- printk(KERN_WARNING "windfarm: thread got sigl !\n");
- break;
- }
}
DBG("wf: thread stopped\n");
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH] fix windfarm core thread wrt. signal handling
2006-06-27 18:17 ` [PATCH] fix windfarm core thread wrt. signal handling Johannes Berg
@ 2006-06-27 22:07 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 18+ messages in thread
From: Benjamin Herrenschmidt @ 2006-06-27 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, linux-pm
On Tue, 2006-06-27 at 20:17 +0200, Johannes Berg wrote:
> This patch removes the signal_pending() from the windfarm core thread
> loop as it isn't necessary and messes up when there actually *is* a
> signal pending because we should enter the freezer.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
> index ab3faa7..c05a838 100644
> --- a/drivers/macintosh/windfarm_core.c
> +++ b/drivers/macintosh/windfarm_core.c
> @@ -116,12 +116,6 @@ static int wf_thread_func(void *data)
> delay = next - jiffies;
> if (delay <= HZ)
> schedule_timeout_interruptible(delay);
> -
> - /* there should be no signal, but oh well */
> - if (signal_pending(current)) {
> - printk(KERN_WARNING "windfarm: thread got sigl !\n");
> - break;
> - }
> }
>
> DBG("wf: thread stopped\n");
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] fix windfarm core thread wrt. signal handling
@ 2006-06-27 22:07 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 18+ messages in thread
From: Benjamin Herrenschmidt @ 2006-06-27 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rafael J. Wysocki, linuxppc-dev list, linux-pm
On Tue, 2006-06-27 at 20:17 +0200, Johannes Berg wrote:
> This patch removes the signal_pending() from the windfarm core thread
> loop as it isn't necessary and messes up when there actually *is* a
> signal pending because we should enter the freezer.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
> index ab3faa7..c05a838 100644
> --- a/drivers/macintosh/windfarm_core.c
> +++ b/drivers/macintosh/windfarm_core.c
> @@ -116,12 +116,6 @@ static int wf_thread_func(void *data)
> delay = next - jiffies;
> if (delay <= HZ)
> schedule_timeout_interruptible(delay);
> -
> - /* there should be no signal, but oh well */
> - if (signal_pending(current)) {
> - printk(KERN_WARNING "windfarm: thread got sigl !\n");
> - break;
> - }
> }
>
> DBG("wf: thread stopped\n");
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: windfarm got signal
2006-06-20 23:51 ` Johannes Berg
@ 2006-06-22 13:12 ` Pavel Machek
-1 siblings, 0 replies; 18+ messages in thread
From: Pavel Machek @ 2006-06-22 13:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-pm, linuxppc-dev list
Hi!
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
See kernel/power/process.c
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [linux-pm] windfarm got signal
@ 2006-06-22 13:12 ` Pavel Machek
0 siblings, 0 replies; 18+ messages in thread
From: Pavel Machek @ 2006-06-22 13:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-pm, linuxppc-dev list
Hi!
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
See kernel/power/process.c
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] windfarm: proper try_to_freeze / signal_pending handling
2006-06-20 23:51 ` Johannes Berg
` (2 preceding siblings ...)
(?)
@ 2006-06-23 10:05 ` Johannes Berg
-1 siblings, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2006-06-23 10:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linux-pm
This seems to work for me:
---
This patch makes windfarm handle signal_pending()/try_to_freeze()
better.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- linux-2.6-git.orig/drivers/macintosh/windfarm_core.c 2006-06-22 16:41:18.182172154 +0200
+++ linux-2.6-git/drivers/macintosh/windfarm_core.c 2006-06-22 16:42:49.045354378 +0200
@@ -93,8 +93,6 @@ static int wf_thread_func(void *data)
DBG("wf: thread started\n");
while(!kthread_should_stop()) {
- try_to_freeze();
-
if (time_after_eq(jiffies, next)) {
wf_notify(WF_EVENT_TICK, NULL);
if (wf_overtemp) {
@@ -117,8 +115,8 @@ static int wf_thread_func(void *data)
if (delay <= HZ)
schedule_timeout_interruptible(delay);
- /* there should be no signal, but oh well */
- if (signal_pending(current)) {
+ /* there should be no non-suspend signal, but oh well */
+ if (signal_pending(current) && !try_to_freeze()) {
printk(KERN_WARNING "windfarm: thread got sigl !\n");
break;
}
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2006-06-27 22:07 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-20 23:51 windfarm got signal Johannes Berg
2006-06-20 23:51 ` Johannes Berg
2006-06-22 6:02 ` Benjamin Herrenschmidt
2006-06-22 11:03 ` Rafael J. Wysocki
2006-06-22 11:03 ` [linux-pm] " Rafael J. Wysocki
2006-06-22 11:13 ` Johannes Berg
2006-06-22 11:13 ` Johannes Berg
2006-06-22 11:34 ` Johannes Berg
2006-06-22 11:34 ` Johannes Berg
2006-06-22 12:33 ` Nigel Cunningham
2006-06-22 12:33 ` [linux-pm] " Nigel Cunningham
2006-06-27 7:44 ` Benjamin Herrenschmidt
2006-06-27 18:17 ` [PATCH] fix windfarm core thread wrt. signal handling Johannes Berg
2006-06-27 22:07 ` Benjamin Herrenschmidt
2006-06-27 22:07 ` Benjamin Herrenschmidt
2006-06-22 13:12 ` windfarm got signal Pavel Machek
2006-06-22 13:12 ` [linux-pm] " Pavel Machek
2006-06-23 10:05 ` [PATCH] windfarm: proper try_to_freeze / signal_pending handling Johannes Berg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.