On Wednesday, 11 April 2007 12:45, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Wednesday, 11 April 2007 09:36, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Monday, 9 April 2007 22:07, Jiri Slaby wrote:
I have bad news for you :(. I thought I had unpatched kernel
On Wednesday, 11 April 2007 15:31, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should be calling try_to_freeze() somewhere anyway
On Wednesday, 11 April 2007 00:20, Venki Pallipadi wrote:
On Mon, Apr 09, 2007 at 07:40:52PM +0200, Rafael J. Wysocki wrote:
On Monday, 9 April 2007 18:14, Pallipadi, Venkatesh wrote:
-Original Message-
From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
Sent: Monday, April
On Wednesday, 11 April 2007 16:36, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
On 04/11, Gautham R Shenoy wrote:
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
It should
On Wednesday, 11 April 2007 17:02, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Wednesday, 11 April 2007 12:45, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Wednesday, 11 April 2007 09:36, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Monday, 9 April 2007 22:07, Jiri Slaby
[appropriate CCs added]
On Friday, 13 April 2007 02:33, Robert P. J. Day wrote:
just something i threw together, not in final form, but it represents
tossing the legacy PM stuff. at the moment, the menuconfig entry for
PM_LEGACY lists it as DEPRECATED, while the help screen calls it
On Friday, 13 April 2007 12:14, Jiri Slaby wrote:
On 4/12/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Wednesday, 11 April 2007 17:02, Jiri Slaby wrote:
Rafael J. Wysocki napsal(a):
On Wednesday, 11 April 2007 12:45, Jiri Slaby wrote:
Rafael J. Wysocki napsal
On Friday, 13 April 2007 14:21, Nigel Cunningham wrote:
Hi.
On Fri, 2007-04-13 at 14:00 +0200, Rafael J. Wysocki wrote:
Shrinking memory... Pages needed: 128103 normal, 0 highmem
Pages needed: 125226 normal, 0 highmem
Pages needed: -5757 normal, 0 highmem
Pages needed: -5757
On Saturday, 14 April 2007 00:10, Pavel Machek wrote:
Hi!
Well, it looks like someone allocated about 6000 pages after we had
freed
enough memory for suspending.
We have a tunable allowance in Suspend2 for this, because fglrx
allocates a lot of pages in its suspend
On Saturday, 14 April 2007 00:45, Nigel Cunningham wrote:
Hi.
On Sat, 2007-04-14 at 00:40 +0200, Pavel Machek wrote:
Hi!
Well, it looks like someone allocated about 6000 pages after we
had freed
enough memory for suspending.
We have a tunable allowance
On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote:
Adrian Bunk wrote:
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
Linus Torvalds wrote:
We should be getting close to a 2.6.21 release, so please update any
regression reports you've done,
For me,
On Saturday, 14 April 2007 01:03, Nigel Cunningham wrote:
Hi.
On Sat, 2007-04-14 at 00:57 +0200, Rafael J. Wysocki wrote:
Well, I'm not sure. First, we don't really know what the value of it
should be
and this alone is a good enough reason for making it tunable, IMHO
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote:
...
Also, would that be feasible for you to use 'shutdown' as a workaround in
case
the source of the problem is difficult to find and/or fix?
One person reporting
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote
Hi,
On Saturday, 14 April 2007 00:35, Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 00:10, Pavel Machek wrote:
[--snip--]
IMO to really fix the problem, we should let the drivers that need much
memory
for suspending allocate it _before_ the memory shrinker is called
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
that the second suspend hangs at i8042 i8042: EARLY
On Sunday, 15 April 2007 17:14, David Brownell wrote:
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
And NVidia southbridge, so
On Sunday, 15 April 2007 20:50, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
With CONFIG_PM_DEBUG=y
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 17:14, David Brownell wrote:
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Yes, it's a Asus M2N-SLI
Hi,
As I said before, we have a problem with using the CPU hotplug for suspending
because of the notifiers that are called from within cpu_up()/cpu_down() and
(sometimes) assume that the system is fully functional.
One obvious solution of this problem would be to make the notifiers behave
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
On 02/20, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 23:41, Oleg Nesterov wrote:
On 02/19, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 21:23, Oleg Nesterov wrote:
@@ -199,6 +189,10 @@ static void
On Monday, 19 February 2007 12:45, Michal Piotrowski wrote:
On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 19 February 2007 01:00, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL
PROTECTED] wrote:
netconsole is good.
I
On Monday, 19 February 2007 01:00, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later
On Tuesday, 20 February 2007 01:50, Oleg Nesterov wrote:
On 02/20, Rafael J. Wysocki wrote:
BTW, what do you think of the updated patch I sent two messages ago?
Ah, sorry, I just forgot... I think it is nice.
Thanks. :-)
I've started to collect the refrigerator-related patches posted
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
On 02/20, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 23:41, Oleg Nesterov wrote:
On 02/19, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 21
On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Looks like reiserfs has some locking problems:
On Monday, 19 February 2007 06:13, David Brownell wrote:
On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:32:08 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
One more thing:
rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
Unable
On Tuesday, 20 February 2007 01:04, Rafael J. Wysocki wrote:
On Monday, 19 February 2007 12:45, Michal Piotrowski wrote:
On 19/02/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 19 February 2007 01:00, Andrew Morton wrote:
On Mon, 19 Feb 2007 00:25:48 +0100 Rafael J. Wysocki
On Tuesday, 20 February 2007 07:31, Andrew Morton wrote:
On Tue, 20 Feb 2007 02:20:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
On Sun, 18 Feb 2007 13:44:54 +0100 Rafael J. Wysocki [EMAIL
PROTECTED] wrote
On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
Hm. In the case discussed above we have
On Wednesday, 21 February 2007 21:03, Oleg Nesterov wrote:
On 02/21, Rafael J. Wysocki wrote:
On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote
On Wednesday, 21 February 2007 22:06, Paul E. McKenney wrote:
On Wed, Feb 21, 2007 at 11:03:14PM +0300, Oleg Nesterov wrote:
On 02/21, Rafael J. Wysocki wrote:
On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki
On Thursday, 22 February 2007 00:58, Andrew Morton wrote:
On Thu, 22 Feb 2007 00:36:22 +0100
Oleg Verych [EMAIL PROTECTED] wrote:
From: Andrew Morton
Newsgroups: gmane.linux.raid,gmane.linux.kernel
Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
Date: Wed, 21
On Thursday, 22 February 2007 04:57, David Brownell wrote:
On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote:
Plus, I'd guess, the old rtc driver statically linked.
Yes (mistakenly).
Until someone merges the BSOD-for-Linux patch, I'll continue to
assume that oopsing
On Thursday, 22 February 2007 11:47, Oleg Nesterov wrote:
On 02/22, Rafael J. Wysocki wrote:
Okay, below is what I have right now (compilation tested on x86_64):
This patch fixes the vfork problem by adding the PF_FREEZER_SKIP flag that
can be used by tasks to tell the freezer
On Thursday, 22 February 2007 18:44, Oleg Nesterov wrote:
On 02/22, Rafael J. Wysocki wrote:
Okay, attached. The first one closes the race between thaw_tasks() and the
refrigerator that can occurs if the freezing fails. The second one fixes
the
vfork problem (should go on top
Hi,
On Friday, 23 February 2007 00:04, Lukas Hejtmanek wrote:
Hello,
after some time I've tried to suspend to disk. It basically works but it
complains into log with the following message:
Tejun says it is known and he's going to fix it.
BUG: at drivers/pci/pci.c:823 pcim_enable_device()
Hi,
The following series of patches implements the changes to the task freezer
that should close the remaining races in it and harden it before it's used for
the CPU hotplugging.
Not all of the patches are from me, but I've decided to make the series out
of all freezer-related patches that have
arch/i386/kernel/apm.c |2 ++
drivers/block/loop.c|2 ++
drivers/char/apm-emulation.c|3 +++
drivers/ieee1394/ieee1394_core.c|3 +++
drivers/md/md.c |2 ++
drivers/mmc/card/queue.c|3 +++
Sorry, this has been sent by mistake, please ignore.
On Friday, 23 February 2007 11:01, Rafael J. Wysocki wrote:
Hi,
The following series of patches implements the changes to the task freezer
that should close the remaining races in it and harden it before it's used for
the CPU hotplugging
Sorry, this has been sent by mistake, please ignore.
On Friday, 23 February 2007 11:02, Rafael J. Wysocki wrote:
arch/i386/kernel/apm.c |2 ++
drivers/block/loop.c|2 ++
drivers/char/apm-emulation.c|3 +++
drivers/ieee1394/ieee1394_core.c
From: Oleg Nesterov [EMAIL PROTECTED]
refrigerator() can miss a wakeup, wait event loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/power/process.c |6
From: Rafael J. Wysocki [EMAIL PROTECTED]
If the freezing of tasks fails and a task is preempted in refrigerator() before
calling frozen_process(), then thaw_tasks() may run before this task is frozen.
In that case the task will freeze and no one will thaw it.
To fix this race we can call
From: Rafael J. Wysocki [EMAIL PROTECTED]
Currently try_to_freeze_tasks() has to wait until all of the vforked processes
exit and for this reason every user can make it fail. To fix this problem
we can introduce the additional process flag PF_FREEZER_SKIP to be used by tasks
that do not want
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/rcutorture.c |3 ++-
1 file changed, 2
From: Rafael J. Wysocki [EMAIL PROTECTED]
The reading of PF_BORROWED_MM in is_user_space() without task_lock() is racy.
Fix it.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/power/process.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6.20-mm2
From: Rafael J. Wysocki [EMAIL PROTECTED]
Add try_to_freeze() calls to the remaining kernel threads that do not call
try_to_freeze() already, although they set PF_NOFREEZE.
In the future we are going to replace PF_NOFREEZE with a set of flags that will
be set to indicate in which situations
Hi,
The following series of patches implements the changes to the task freezer
that should close the remaining races in it and harden it before it's used for
the CPU hotplugging.
Not all of the patches are from me, but I've decided to make the series out
of all freezer-related patches that have
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove PF_NOFREEZE from the bluetooth threads, adding try_to_freeze() calls as
required.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
net/bluetooth/bnep/core.c |6 --
net/bluetooth/cmtp/core.c |4 +++-
net/bluetooth/hidp/core.c
. :-)
Greetings,
Rafael
-Original Message-
From: Alexey Starikovskiy [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 10:49 PM
To: Rafael J. Wysocki
Cc: Karasyov, Konstantin A; Andrey Borzenkov;
linux-acpi@vger.kernel.org; Lebedev, Vladimir P
Subject: Re
From: Stefan Seyfried [EMAIL PROTECTED]
Fix the Oops occuring when SNAPSHOT_PMOPS or SNAPSHOT_S2RAM ioctl is called on
a system without pm_ops defined (eg. a non-ACPI kernel on x86 PC).
Signed-off-by: Stefan Seyfried [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED
On Saturday, 24 February 2007 23:06, Rafael J. Wysocki wrote:
From: Stefan Seyfried [EMAIL PROTECTED]
Fix the Oops occuring when SNAPSHOT_PMOPS or SNAPSHOT_S2RAM ioctl is called on
a system without pm_ops defined (eg. a non-ACPI kernel on x86 PC).
Signed-off-by: Stefan Seyfried [EMAIL
On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
Hi,
On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote:
On Вторник 13 февраля 2007, Andrey Borzenkov wrote:
On Четверг 07 декабря 2006, Lebedev, Vladimir P wrote
such a task freezes with
PF_FREEZER_SKIP set, refrigerator() clears this flag for the current task
before
calling frozen_process(current) to avoid having both PF_FREEZER_SKIP and
PF_FROZEN set at the same time.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
@@ -1393,7 +1394,9
On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
On Sunday, 25 February 2007 00:26, Andrey Borzenkov wrote:
On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
Hi,
On Saturday, 24 February 2007 10:55, Andrey
On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
Hi,
On Sunday, 25 February 2007 11:46, Pavel Machek wrote:
Hi!
Currently try_to_freeze_tasks() has to wait until all of the vforked
processes
exit and for this reason every user can make it fail. To fix this problem
-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
@@ -1393,7 +1394,9 @@ long do_fork(unsigned long clone_flags,
tracehook_report_clone_complete(clone_flags, nr, p);
if (clone_flags CLONE_VFORK) {
+ freezer_do_not_count
On Sunday, 25 February 2007 15:33, Aneesh Kumar wrote:
On 2/25/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 25 February 2007 11:45, Rafael J. Wysocki wrote:
Hi,
=
--- linux-2.6.20-mm2.orig/kernel/power/process.c2007-02-22
23:44:04.0 +0100
On Sunday, 25 February 2007 16:40, Aneesh Kumar wrote:
On 2/25/07, Aneesh Kumar [EMAIL PROTECTED] wrote:
On 2/25/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 25 February 2007 15:33, Aneesh Kumar wrote:
On 2/25/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
[--snip
On Sunday, 25 February 2007 21:31, Oleg Nesterov wrote:
On 02/25, Rafael J. Wysocki wrote:
On Sunday, 25 February 2007 16:40, Aneesh Kumar wrote:
On 2/25/07, Aneesh Kumar [EMAIL PROTECTED] wrote:
On 2/25/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 25 February 2007 15
On Sunday, 25 February 2007 18:14, Andrey Borzenkov wrote:
On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
On Sunday, 25 February 2007 11:37, Andrey Borzenkov wrote:
On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
On Sunday, 25 February 2007 00:26, Andrey Borzenkov
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove PF_NOFREEZE from the bluetooth threads, adding try_to_freeze() calls as
required.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
---
net/bluetooth/bnep
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel
From: Oleg Nesterov [EMAIL PROTECTED]
refrigerator() can miss a wakeup, wait event loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel/power/process.c |6
From: Rafael J. Wysocki [EMAIL PROTECTED]
Add try_to_freeze() calls to the remaining kernel threads that do not call
try_to_freeze() already, although they set PF_NOFREEZE.
In the future we are going to replace PF_NOFREEZE with a set of flags that will
be set to indicate in which situations
From: Rafael J. Wysocki [EMAIL PROTECTED]
The reading of PF_BORROWED_MM in is_user_space() without task_lock() is racy.
Fix it.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
kernel/power/process.c |8 +++-
1 file changed, 7 insertions
Hi,
The following series of patches contains modifications of the task freezer that
harden it and prepare it to be used in the CPU hotplug.
Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
From: Rafael J. Wysocki [EMAIL PROTECTED]
If the freezing of tasks fails and a task is preempted in refrigerator() before
calling frozen_process(), then thaw_tasks() may run before this task is frozen.
In that case the task will freeze and no one will thaw it.
To fix this race we can call
Hi,
I have separated the patch supposed to fix the freezer's vfork problem from the
previous series, because it seems to be controversial. Moreover, I have one
more patch on top of it and a related, also a bit controversial one.
Please have a look and advise.
Greetings,
Rafael
--
If you
being frozen where they don't want to.
Well, vatsa seems to think that calling try_to_freeze() in freezer_count() is
not a good idea anyway, but I don't see anything wrong in freezing the user
space processes here.
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Currently try_to_freeze_tasks() has
NOTE: Alternatively, we can just drop flush_signals() from there, but I'm not
sure that's the right thing to do.
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Since call_usermodehelper() calls flush_signals(current), the task that
enters it may miss a freezing request. However
From: Rafael J. Wysocki [EMAIL PROTECTED]
Kernel threads can become userland processes by calling kernel_execve(). In
particular, this may happen right after try_to_freeze_tasks(FREEZER_USER_SPACE)
has returned, so try_to_freeze_tasks() needs to take userspace processes
into consideration even
On Monday, 26 February 2007 17:11, Oleg Nesterov wrote:
On 02/26, Srivatsa Vaddagiri wrote:
On Mon, Feb 26, 2007 at 03:00:43PM +0300, Oleg Nesterov wrote:
In that case we should also modify call_usermodehelper(), otherwise
we have
the same deadlock if it is frozen. But this is
On Monday, 26 February 2007 12:58, Aneesh Kumar wrote:
On 2/26/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
NOTE: Alternatively, we can just drop flush_signals() from there, but I'm
not
sure that's the right thing to do.
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Since
On Monday, 26 February 2007 21:35, Andrey Borzenkov wrote:
On Воскресенье 25 февраля 2007, Rafael J. Wysocki wrote:
The patch looks good, but the changelog does not. First, AFAICT, the
x86_64 code doesn't touch anything outside the e820 map. Why do you think
it does?
the following
On Monday, 26 February 2007 22:25, Oleg Nesterov wrote:
On 02/26, Rafael J. Wysocki wrote:
On Monday, 26 February 2007 17:11, Oleg Nesterov wrote:
On 02/26, Srivatsa Vaddagiri wrote:
On Mon, Feb 26, 2007 at 03:00:43PM +0300, Oleg Nesterov wrote:
In that case we should also
vatsa suggested in previous mail is
better.
Not only better, but correct. This is very simple: if we set PF_FREEZER_SKIP,
we must call try_to_freeze(), otherwise we confuse the freezer.
Okay, patch updated, appended.
Rafael
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Currently
Hi,
We have a problem with freezable workqueues in 2.6.21-rc1 and in -mm
(there are only two of them, in XFS, but still). Namely, their worker threads
deadlock with workqueue_cpu_callback() that gets called during the CPU hotplug,
becuase workqueue_cpu_callback() tries to stop these threads
Hi,
On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
Hi.
PROBLEM: BUG: when resumimg from suspend-to-ram
My laptop have a problem with resuming from suspend-to-ram.
It does not occur every time - most of the time, resume works without
any problem.at all.
On Tuesday, 27 February 2007 23:23, Kristian Grønfeldt Sørensen wrote:
On Tue, 2007-02-27 at 23:04 +0100, Rafael J. Wysocki wrote:
Hi,
On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
Hi.
PROBLEM: BUG: when resumimg from suspend-to-ram
My laptop
On Tuesday, 27 February 2007 23:04, Rafael J. Wysocki wrote:
Hi,
On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
Hi.
PROBLEM: BUG: when resumimg from suspend-to-ram
My laptop have a problem with resuming from suspend-to-ram.
It does not occur every
On Wednesday, 28 February 2007 00:28, Oleg Nesterov wrote:
On 02/27, Rafael J. Wysocki wrote:
We have a problem with freezable workqueues in 2.6.21-rc1 and in -mm
(there are only two of them, in XFS, but still). Namely, their worker
threads
deadlock with workqueue_cpu_callback
On Wednesday, 28 February 2007 00:36, Johannes Berg wrote:
On Wed, 2007-02-28 at 02:28 +0300, Oleg Nesterov wrote:
Ugh. I know nothing, nothing, nothing about suspend. I'll try to guess.
Commit: ed746e3b18f4df18afa3763155972c5835f284c5
Yes? with the patch above, _cpu_down() called
On Wednesday, 28 February 2007 00:12, Kristian Grønfeldt Sørensen wrote:
On Tue, 2007-02-27 at 23:34 +0100, Rafael J. Wysocki wrote:
On Tuesday, 27 February 2007 23:23, Kristian Grønfeldt Sørensen wrote:
On Tue, 2007-02-27 at 23:04 +0100, Rafael J. Wysocki wrote:
Hi,
On Tuesday
On Wednesday, 28 February 2007 01:01, Johannes Berg wrote:
On Wed, 2007-02-28 at 00:57 +0100, Rafael J. Wysocki wrote:
Okay, in that case I'd suggest removing create_freezeable_workqueue() and
make all workqueues nonfreezable once again for 2.6.21 (as far as I know,
only
the two XFS
On Wednesday, 28 February 2007 02:23, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 12:53:14AM +0300, Oleg Nesterov wrote:
I think it is good. Srivatsa?
Maybe additional comments on why we don't skip vfork kernel tasks may be
good.
Which is because we don't want the kernel threads to
On Wednesday, 28 February 2007 02:14, Nigel Cunningham wrote:
Hi.
On Wed, 2007-02-28 at 01:08 +0100, Rafael J. Wysocki wrote:
On Wednesday, 28 February 2007 01:01, Johannes Berg wrote:
On Wed, 2007-02-28 at 00:57 +0100, Rafael J. Wysocki wrote:
Okay, in that case I'd suggest
On Wednesday, 28 February 2007 10:10, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 11:48:59AM +0300, Oleg Nesterov wrote:
On 02/28, Srivatsa Vaddagiri wrote:
We can just thaw the worker thread selectively before kthread_stopping
them. This will let us freeze all worker threads (which
On Wednesday, 28 February 2007 04:51, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 08:31:13AM +0530, Srivatsa Vaddagiri wrote:
This problem (of kthread_stopping a frozen thread) was there when we
implemented freezer-based cpu hotplug. We worked around that in the
callbacks by thawing
On Wednesday, 28 February 2007 14:17, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 12:11:03PM +0100, Rafael J. Wysocki wrote:
In addition to thawing worker thread before kthread_stopping it, there
are minor changes required in worker threads, to check for
is_cpu_offline(bind_cpu
On Wednesday, 28 February 2007 14:27, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 06:47:21PM +0530, Srivatsa Vaddagiri wrote:
--- workqueue.c.org 2007-02-28 18:32:48.0 +0530
+++ workqueue.c 2007-02-28 18:44:23.0 +0530
@@ -718,6 +718,8 @@ static void
On Wednesday, 28 February 2007 01:27, Kristian Grønfeldt Sørensen wrote:
On Tue, 2007-02-27 at 23:30 +0100, Rafael J. Wysocki wrote:
On Tuesday, 27 February 2007 23:04, Rafael J. Wysocki wrote:
Hi,
On Tuesday, 27 February 2007 19:45, Kristian Grønfeldt Sørensen wrote:
Hi
On Wednesday, 28 February 2007 19:17, Gautham R Shenoy wrote:
On Wed, Feb 28, 2007 at 08:37:26AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..good point. So can we assume that disable/enable_nonboot_cpus() are
called
with processes frozen already?
Gautham, you need to take this into
On Wednesday, 28 February 2007 14:17, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 12:11:03PM +0100, Rafael J. Wysocki wrote:
In addition to thawing worker thread before kthread_stopping it, there
are minor changes required in worker threads, to check for
is_cpu_offline(bind_cpu
On Wednesday, 28 February 2007 12:00, Oleg Nesterov wrote:
On 02/28, Rafael J. Wysocki wrote:
On Wednesday, 28 February 2007 02:23, Srivatsa Vaddagiri wrote:
On Wed, Feb 28, 2007 at 12:53:14AM +0300, Oleg Nesterov wrote:
I think it is good. Srivatsa?
Maybe additional comments
On Wednesday, 28 February 2007 20:32, Oleg Nesterov wrote:
On 02/28, Rafael J. Wysocki wrote:
--- workqueue.c.org 2007-02-28 18:32:48.0 +0530
+++ workqueue.c 2007-02-28 18:44:23.0 +0530
@@ -718,6 +718,8 @@ static void cleanup_workqueue_thread(str
201 - 300 of 29242 matches
Mail list logo
