2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

Hi,

It looks like there's a probel with the kernel preemption vs swsusp:

Stopping tasks: 
=============================================================================|
Freeing 
memory: ......................................................................................................................|
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x5be].............................................................................swsusp: 
Need to copy 17764 pages
suspend: (pages needed: 17764 + 512 free: 113115)
..<7>[nosave pfn 
0x5be].............................................................................swsusp: 
critical section/: done (1)
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
<ffffffff8059b5a6>{cpu_init+38}
PML4 bc83067 PGD bfe9067 PMD 0
Oops: 0000 [1] PREEMPT
CPU 0
Modules linked in: usbserial parport_pc lp parport ipv6 joydev sg st sd_mod 
sr_mod scsi_mod usbhid snd_seq_oss snd_seq_midi_event snd_d
Pid: 19437, comm: hibernate.sh Not tainted 2.6.9-rc3
RIP: 0010:[<ffffffff8059b5a6>] <ffffffff8059b5a6>{cpu_init+38}
RSP: 0018:000001000fe93e40  EFLAGS: 00010002
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000001000fe93e6c RDI: ffffffff80442f50
RBP: 0000000000000004 R08: 0000000000000000 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff80455d80
R13: 0000000000000002 R14: 0000002a955a4000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff8058fb40(0000) knlGS:0000000057c90bb0
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0
Process hibernate.sh (pid: 19437, threadinfo 000001000fe92000, task 
0000010018cb92d0)
Stack: ffffffff80121b49 0000000000000000 0000000000000004 8000895060002080
       00000000ffffffff ffffffff8050bfa0 ffffffff80121d38 0000000000000000
       ffffffff80166dd3 0000000000000000
Call Trace:<ffffffff80121b49>{fix_processor_context+137} 
<ffffffff80121d38>{__restore_processor_state+120}
       <ffffffff80166dd3>{swsusp_suspend+19} 
<ffffffff8016810a>{pm_suspend_disk+90}
       <ffffffff80165b84>{enter_state+68} 
<ffffffff802ceac5>{acpi_system_write_sleep+100}
       <ffffffff8019cf14>{vfs_write+228} <ffffffff8019d053>{sys_write+83}
       <ffffffff801110da>{system_call+126}

Code: 0a 2b 20 2a 20 46 6f 72 20 65 78 61 6d 70 6c 65 2c 20 6f 6e
RIP <ffffffff8059b5a6>{cpu_init+38} RSP <000001000fe93e40>
CR2: 0000000000000000
 <6>note: hibernate.sh[19437] exited with preempt_count 1
bad: scheduling while atomic!

Call Trace:<ffffffff803d2b7e>{schedule+94} <ffffffff80183982>{unmap_vmas+1666}
       <ffffffff80187915>{exit_mmap+293} <ffffffff8013a960>{mmput+272}
       <ffffffff80143724>{do_exit+820} <ffffffff80112449>{oops_end+201}
       <ffffffff80125a0f>{do_page_fault+1247} <ffffffff8013d66d>{printk+141}
       <ffffffff8013d66d>{printk+141} <ffffffff8011198d>{error_exit+0}
       <ffffffff8059b5a6>{cpu_init+38} 
<ffffffff80121b49>{fix_processor_context+137}
       <ffffffff80121d38>{__restore_processor_state+120} 
<ffffffff80166dd3>{swsusp_suspend+19}
       <ffffffff8016810a>{pm_suspend_disk+90} 
<ffffffff80165b84>{enter_state+68}
       <ffffffff802ceac5>{acpi_system_write_sleep+100} 
<ffffffff8019cf14>{vfs_write+228}
       <ffffffff8019d053>{sys_write+83} <ffffffff801110da>{system_call+126}

The system is an x86-64 box.  Please let me know if you need more information.  
Sorry for the noise if it's a known issue.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Pavel Machek]

Hi!

> It looks like there's a probel with the kernel preemption vs swsusp:

It is not in kernel preemption, see that NULL pointer dereference? Try
this one...

								Pavel

--- clean-suse/kernel/power/swsusp.c	2004-10-05 11:36:23.000000000 +0200
+++ linux-suse/kernel/power/swsusp.c	2004-10-05 22:35:21.000000000 +0200
@@ -568,6 +568,7 @@
 	struct zone *zone;
 	unsigned long zone_pfn;
 	struct pbe * pbe = pagedir_nosave;
+	int pages_copied = 0;
 	
 	for_each_zone(zone) {
 		if (is_highmem(zone))
@@ -576,13 +577,17 @@
 			if (saveable(zone, &zone_pfn)) {
 				struct page * page;
 				page = pfn_to_page(zone_pfn + zone->zone_start_pfn);
+
 				pbe->orig_address = (long) page_address(page);
 				/* copy_page is no usable for copying task structs. */
 				memcpy((void *)pbe->address, (void *)pbe->orig_address, PAGE_SIZE);
 				pbe++;
+				pages_copied++;
 			}
 		}
 	}
+	BUG_ON(pages_copied > nr_copy_pages);
+	nr_copy_pages = pages_copied;
 }
 
 
@@ -863,7 +868,7 @@
 
 asmlinkage int swsusp_restore(void)
 {
-	BUG_ON (nr_copy_pages_check != nr_copy_pages);
+//	BUG_ON (nr_copy_pages_check != nr_copy_pages);
 	BUG_ON (pagedir_order_check != pagedir_order);
 	
 	/* Even mappings of "global" things (vmalloc) need to be fixed */
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

On Tuesday 05 of October 2004 23:27, Pavel Machek wrote:
> Hi!
> 
> > It looks like there's a probel with the kernel preemption vs swsusp:
> 
> It is not in kernel preemption, see that NULL pointer dereference? Try
> this one...
[-- snip --]

Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
manually.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Pavel Machek]

Hi!

> > > It looks like there's a probel with the kernel preemption vs swsusp:
> > 
> > It is not in kernel preemption, see that NULL pointer dereference? Try
> > this one...
> [-- snip --]
> 
> Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
> manually.

It was against -suse... Did it help?
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

On Wednesday 06 of October 2004 10:54, Pavel Machek wrote:
> Hi!
> 
> > > > It looks like there's a probel with the kernel preemption vs swsusp:
> > > 
> > > It is not in kernel preemption, see that NULL pointer dereference? Try
> > > this one...
> > [-- snip --]
> > 
> > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
> > manually.
> 
> It was against -suse... Did it help?

I just can't say it didn't right now.  The Oops was not readily reproducible 
anyway, so I need to do some more suspend/resume testing.  I'll let you 
know. ;-)

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Pavel Machek]

Hi!

> > > > > It looks like there's a probel with the kernel preemption vs swsusp:
> > > > 
> > > > It is not in kernel preemption, see that NULL pointer dereference? Try
> > > > this one...
> > > [-- snip --]
> > > 
> > > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied it 
> > > manually.
> > 
> > It was against -suse... Did it help?
> 
> I just can't say it didn't right now.  The Oops was not readily reproducible 
> anyway, so I need to do some more suspend/resume testing.  I'll let you 
> know. ;-)

Ahha, thats likely another problem, then. The one this fixes is 100%
reproducible...

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc3[+recent swsusp patches]: swsusp kernel-preemption-unfriendly?

[Rafael J. Wysocki]

On Wednesday 06 of October 2004 12:12, Pavel Machek wrote:
> Hi!
> 
> > > > > > It looks like there's a probel with the kernel preemption vs 
swsusp:
> > > > > 
> > > > > It is not in kernel preemption, see that NULL pointer dereference? 
Try
> > > > > this one...
> > > > [-- snip --]
> > > > 
> > > > Is it against -mm?  It does not apply cleanly to -rc3, so I've applied 
it 
> > > > manually.
> > > 
> > > It was against -suse... Did it help?
> > 
> > I just can't say it didn't right now.  The Oops was not readily 
reproducible 
> > anyway, so I need to do some more suspend/resume testing.  I'll let you 
> > know. ;-)
> 
> Ahha, thats likely another problem, then. The one this fixes is 100%
> reproducible...

You are right, it doesn't help.  Here's another trace for a non-preemptible 
kernel with the patch applied:

Stopping tasks: 
=================================================================|
Freeing 
memory: .....................................................................................................................|
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x58c]...................................................................................................swsusp: 
Nees
suspend: (pages needed: 44159 + 512 free: 86720)
..<7>[nosave pfn 
0x58c].....................................................................................................swsusp: 
c)
Unable to handle kernel paging request at 000000ff9f2f9f09 RIP:
<ffffffff805693f7>{syscall_init+7}
PML4 0
Oops: 0000 [1]
CPU 0
Modules linked in: usbserial parport_pc lp parport joydev sg st sd_mod sr_mod 
scsi_mod usbhid snd_seq_oss snd_seq_midi_event snd_seq d
Pid: 16652, comm: hibernate.sh Not tainted 2.6.9-rc3
RIP: 0010:[<ffffffff805693f7>] <ffffffff805693f7>{syscall_init+7}
RSP: 0018:0000010003301e40  EFLAGS: 00010082
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000b1ff96ac RSI: 0000010003301e68 RDI: ffffffff80412190
RBP: 0000000000000004 R08: 0000000000000000 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff80424fc0
R13: 0000000000000002 R14: 0000002a955a4000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff8055eb40(0000) knlGS:0000000056055200
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000ff9f2f9f09 CR3: 0000000000101000 CR4: 00000000000006e0
Process hibernate.sh (pid: 16652, threadinfo 0000010003300000, task 
000001000f35c0f0)
Stack: ffffffff801209b9 0000000000000000 0000000000000004 8000894d50002080
       00000000ffffffff ffffffff804dafa0 ffffffff80120c28 0000000000000000
       ffffffff80161003 0000000000000000
Call Trace:<ffffffff801209b9>{fix_processor_context+137} 
<ffffffff80120c28>{__restore_processor_state+120}
       <ffffffff80161003>{swsusp_suspend+19} 
<ffffffff8016216a>{pm_suspend_disk+90}
       <ffffffff8015fd54>{enter_state+68} 
<ffffffff802adb4d>{acpi_system_write_sleep+100}
       <ffffffff80193854>{vfs_write+228} <ffffffff80193993>{sys_write+83}
       <ffffffff80110c72>{system_call+126}

Code: ff a6 a1 80 ff 9b 9c 75 ff 97 96 74 ff a1 a0 7e ff 9e 9c 7d
RIP <ffffffff805693f7>{syscall_init+7} RSP <0000010003301e40>
CR2: 000000ff9f2f9f09

It seems that I need to run X to reproduce it and it also seems that it's more 
likely to happen if I run some X apps and close them all before suspending.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Fix random crashes in x86-64 swsusp

[Pavel Machek]

Hi!

fix_processor_context was calling functions marked __init on x86-64;
bad idea. Maybe we should memset freed memory to zero so such bugs are
prevented?

Thanks to Rafael for keeping notifying me about this bug, and someone
get me yet another brown paper bag.

Anyway, this should fix it, please apply,
								Pavel

--- clean-suse/arch/x86_64/ia32/syscall32.c	2004-06-22 12:36:00.000000000 +0200
+++ linux-suse/arch/x86_64/ia32/syscall32.c	2004-10-06 23:58:27.000000000 +0200
@@ -76,7 +76,8 @@
 	
 __initcall(init_syscall32); 
 
-void __init syscall32_cpu_init(void)
+/* May not be __init: called during resume */
+void syscall32_cpu_init(void)
 {
 	if (use_sysenter < 0)
  		use_sysenter = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
--- clean-suse/arch/x86_64/kernel/setup64.c	2004-10-05 11:36:21.000000000 +0200
+++ linux-suse/arch/x86_64/kernel/setup64.c	2004-10-06 23:59:08.000000000 +0200
@@ -195,7 +195,8 @@
 char boot_exception_stacks[N_EXCEPTION_STACKS * EXCEPTION_STKSZ] 
 __attribute__((section(".bss.page_aligned")));
 
-void __init syscall_init(void)
+/* May not be marked __init: used by software suspend */
+void syscall_init(void)
 {
 	/* 
 	 * LSTAR and STAR live in a bit strange symbiosis.

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [kernel] Fix random crashes in x86-64 swsusp

[Andi Kleen]

On Thu, Oct 07, 2004 at 12:06:00AM +0200, Pavel Machek wrote:
> Hi!
> 
> fix_processor_context was calling functions marked __init on x86-64;
> bad idea. Maybe we should memset freed memory to zero so such bugs are
> prevented?

It's called CONFIG_INIT_DEBUG. But nobody uses it.

-Andi

Re: Fix random crashes in x86-64 swsusp

[Andrew Morton]

Pavel Machek <pavel@suse.cz> wrote:
>
> Maybe we should memset freed memory to zero so such bugs are
> prevented?

It would make sense to poison these pages, yes.  Zero would not be a good
choice of value, actually - something like 0xbb would cause nice oopses if
someone used a pointer which was backed by __init memory.

CONFIG_DEBUG_PAGEALLOC will pick up this sort of bug, but that's i386-only.

Re: Fix random crashes in x86-64 swsusp

[Pavel Machek]

Hi!

> > Maybe we should memset freed memory to zero so such bugs are
> > prevented?
> 
> It would make sense to poison these pages, yes.  Zero would not be a good
> choice of value, actually - something like 0xbb would cause nice oopses if
> someone used a pointer which was backed by __init memory.
> 
> CONFIG_DEBUG_PAGEALLOC will pick up this sort of bug, but that's i386-only.

Few minutes after that I found out that x86-64 has similar mechanism
under CONFIG_INIT_DEBUG... it uses 0xcc.

I just wonder if it should be configurable, memset over 100KB is not
likely to be noticeable.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

swsusp: 8-order memory allocations problem (was: Re: Fix random crashes in x86-64 swsusp)

[Rafael J. Wysocki]

Hi,

On Thursday 07 of October 2004 00:06, Pavel Machek wrote:
> Hi!
> 
> fix_processor_context was calling functions marked __init on x86-64;
> bad idea. Maybe we should memset freed memory to zero so such bugs are
> prevented?
> 
> Thanks to Rafael for keeping notifying me about this bug, and someone
> get me yet another brown paper bag.
> 
> Anyway, this should fix it, please apply,
[-- snip --]

The patch apparently fixes the problem that I have reported, so thanks a lot, 
Pavel.  After it's been fixed, however, I often get things like that:

PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x58b]...........................................................................
............................................swsusp: Need to copy 31927 pages
suspend: (pages needed: 31927 + 512 free: 98952)
hibernate.sh: page allocation failure. order:8, mode:0x120
Oct  8 14:15:57 albercik kernel:
Call Trace:<ffffffff8016eb2d>{__alloc_pages+749} 
<ffffffff8016ebd1>{__get_free_pages+33}
       <ffffffff80161a23>{suspend_prepare_image+531} 
<ffffffff8026d7a7>{pci_device_suspend+71}
       <ffffffff80161cb6>{swsusp_swap_check+22} 
<ffffffff802ea112>{suspend_device+50}
       <ffffffff80120d0c>{swsusp_arch_suspend+124} 
<ffffffff801610cc>{swsusp_suspend+12}
       <ffffffff8016222a>{pm_suspend_disk+90} 
<ffffffff8015fe04>{enter_state+68}
       <ffffffff802adc0d>{acpi_system_write_sleep+100} 
<ffffffff80193914>{vfs_write+228}
       <ffffffff80193a53>{sys_write+83} <ffffffff80110c72>{system_call+126}
Oct  8 14:16:05 albercik kernel:
suspend: Allocating pagedir failed.

It's sort of strange, because there were 250 meg of RAM available, out of 500, 
at that time.

Anyway I was able to suspend the machine after the above one had happened (I 
stopped an app occupying some memory and then the box suspended), but then I 
got a spectacular crash on resume (unfortunately I was unable to save the 
trace, but I'll try to reproduce it).

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order memory allocations problem (was: Re: Fix random crashes in x86-64 swsusp)

[Pavel Machek]

Hi!

> > fix_processor_context was calling functions marked __init on x86-64;
> > bad idea. Maybe we should memset freed memory to zero so such bugs are
> > prevented?
> > 
> > Thanks to Rafael for keeping notifying me about this bug, and someone
> > get me yet another brown paper bag.
> > 
> > Anyway, this should fix it, please apply,
> [-- snip --]
> 
> The patch apparently fixes the problem that I have reported, so thanks a lot, 
> Pavel.  After it's been fixed, however, I often get things like that:
> 
> PM: snapshotting memory.
> swsusp: critical section:
> ..<7>[nosave pfn 
> 0x58b]...........................................................................
> ............................................swsusp: Need to copy 31927 pages
> suspend: (pages needed: 31927 + 512 free: 98952)
> hibernate.sh: page allocation failure. order:8, mode:0x120
> Oct  8 14:15:57 albercik kernel:
> Call Trace:<ffffffff8016eb2d>{__alloc_pages+749} 
> <ffffffff8016ebd1>{__get_free_pages+33}
>        <ffffffff80161a23>{suspend_prepare_image+531} 
> <ffffffff8026d7a7>{pci_device_suspend+71}
>        <ffffffff80161cb6>{swsusp_swap_check+22} 
> <ffffffff802ea112>{suspend_device+50}
>        <ffffffff80120d0c>{swsusp_arch_suspend+124} 
> <ffffffff801610cc>{swsusp_suspend+12}
>        <ffffffff8016222a>{pm_suspend_disk+90} 
> <ffffffff8015fe04>{enter_state+68}
>        <ffffffff802adc0d>{acpi_system_write_sleep+100} 
> <ffffffff80193914>{vfs_write+228}
>        <ffffffff80193a53>{sys_write+83} <ffffffff80110c72>{system_call+126}
> Oct  8 14:16:05 albercik kernel:
> suspend: Allocating pagedir failed.
> 
> It's sort of strange, because there were 250 meg of RAM available, out of 500, 
> at that time.

Well, you have 250MB free, but apparently not enough contignuous free pages...

You may try this one, it may reduce probability of this kind of
failure...

							Pavel

--- clean/kernel/power/disk.c	2004-10-01 00:30:32.000000000 +0200
+++ linux/kernel/power/disk.c	2004-10-02 19:43:06.000000000 +0200
@@ -85,13 +89,26 @@
 
 static void free_some_memory(void)
 {
-	printk("Freeing memory: ");
-	while (shrink_all_memory(10000))
-		printk(".");
-	printk("|\n");
+	int i;
+	for (i=0; i<5; i++) {
+		int i = 0, tmp;
+		long pages = 0;
+		char *p = "-\\|/";
+
+		printk("Freeing memory...  ");
+		while ((tmp = shrink_all_memory(10000))) {
+			pages += tmp;
+			printk("\b%c", p[i]);
+			i++;
+			if (i > 3)
+				i = 0;
+		}
+		printk("\bdone (%li pages freed)\n", pages);
+		current->state = TASK_INTERRUPTIBLE;
+		schedule_timeout(HZ/5);
+	}
 }
 
-
 static inline void platform_finish(void)
 {
 	if (pm_disk_mode == PM_DISK_PLATFORM) {
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: swsusp: 8-order memory allocations problem (was: Re: Fix random crashes in x86-64 swsusp)

[Andrew Morton]

Pavel Machek <pavel@suse.cz> wrote:
>
> > It's sort of strange, because there were 250 meg of RAM available, out of 500, 
>  > at that time.
> 
>  Well, you have 250MB free, but apparently not enough contignuous free pages...
> 
>  You may try this one, it may reduce probability of this kind of
>  failure...

The chances of successfully finding 256 physically contiguous free
pages are small.  A shrink_all_memory() pass will help of course,
but the chances of failure are still quite high.

Dunno - maybe alloc_pagedir() should use vmalloc()?  That's a non-atomic
allocation but alloc_pagedir() really shouldn't be using GFP_ATOMIC anyway.

Re: swsusp: 8-order memory allocations problem (was: Re: Fix random crashes in x86-64 swsusp)

[Rafael J. Wysocki]

Hi,

On Sunday 10 of October 2004 15:48, Pavel Machek wrote:
[-- snip --] 
> > It's sort of strange, because there were 250 meg of RAM available,
> > out of 500, at that time.
> 
> Well, you have 250MB free, but apparently not enough contignuous free 
pages...
> 
> You may try this one, it may reduce probability of this kind of
> failure...
> 
> 							Pavel
> 
> --- clean/kernel/power/disk.c	2004-10-01 00:30:32.000000000 +0200
> +++ linux/kernel/power/disk.c	2004-10-02 19:43:06.000000000 +0200
> @@ -85,13 +89,26 @@
>  
>  static void free_some_memory(void)
>  {
> -	printk("Freeing memory: ");
> -	while (shrink_all_memory(10000))
> -		printk(".");
> -	printk("|\n");
> +	int i;
> +	for (i=0; i<5; i++) {
> +		int i = 0, tmp;
> +		long pages = 0;
> +		char *p = "-\\|/";
> +
> +		printk("Freeing memory...  ");
> +		while ((tmp = shrink_all_memory(10000))) {
> +			pages += tmp;
> +			printk("\b%c", p[i]);
> +			i++;
> +			if (i > 3)
> +				i = 0;
> +		}
> +		printk("\bdone (%li pages freed)\n", pages);
> +		current->state = TASK_INTERRUPTIBLE;
> +		schedule_timeout(HZ/5);
> +	}
>  }
>  
> -
>  static inline void platform_finish(void)
>  {
>  	if (pm_disk_mode == PM_DISK_PLATFORM) {
> -- 

I'm giving it a try.  Without this patch I get an 8-order allocation failure 
almost every time after using a computer for a day.  This one is pretty 
scary, IMO (there are 5 times more pages free than needed to be copied and 
still it cannot allocate enough memory):

Stopping tasks: ============================================================|
Freeing 
memory: .............................................................................................................|
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
..<7>[nosave pfn 
0x58d].........................................................................................................
..swsusp: Need to copy 21035 pages
suspend: (pages needed: 21035 + 512 free: 109844)
hibernate.sh: page allocation failure. order:8, mode:0x120
Oct 13 17:57:34 albercik kernel:
Call Trace:<ffffffff8016ec2d>{__alloc_pages+749} 
<ffffffff8016ecd1>{__get_free_pages+33}
       <ffffffff80161b93>{suspend_prepare_image+531} 
<ffffffff8026e977>{pci_device_suspend+71}
       <ffffffff80161e26>{swsusp_swap_check+22} 
<ffffffff802eae02>{suspend_device+50}
       <ffffffff80120dec>{swsusp_arch_suspend+124} 
<ffffffff8016123c>{swsusp_suspend+12}
       <ffffffff8016239a>{pm_suspend_disk+90} 
<ffffffff8015ff54>{enter_state+68}
       <ffffffff802aed4d>{acpi_system_write_sleep+100} 
<ffffffff80194b24>{vfs_write+228}
       <ffffffff80194c63>{sys_write+83} <ffffffff80110c72>{system_call+126}
Oct 13 17:57:41 albercik kernel:
suspend: Allocating pagedir failed.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order memory allocations problem (update)

[Rafael J. Wysocki]

On Wednesday 13 of October 2004 19:24, Rafael J. Wysocki wrote:
> Hi,
> 
> On Sunday 10 of October 2004 15:48, Pavel Machek wrote:
> [-- snip --] 
> > > It's sort of strange, because there were 250 meg of RAM available,
> > > out of 500, at that time.
> > 
> > Well, you have 250MB free, but apparently not enough contignuous free 
> pages...
> > 
> > You may try this one, it may reduce probability of this kind of
> > failure...
> > 
> > 							Pavel
> > 
> > --- clean/kernel/power/disk.c	2004-10-01 00:30:32.000000000 +0200
> > +++ linux/kernel/power/disk.c	2004-10-02 19:43:06.000000000 +0200
> > @@ -85,13 +89,26 @@
> >  
> >  static void free_some_memory(void)
> >  {
> > -	printk("Freeing memory: ");
> > -	while (shrink_all_memory(10000))
> > -		printk(".");
> > -	printk("|\n");
> > +	int i;
> > +	for (i=0; i<5; i++) {
> > +		int i = 0, tmp;
> > +		long pages = 0;
> > +		char *p = "-\\|/";
> > +
> > +		printk("Freeing memory...  ");
> > +		while ((tmp = shrink_all_memory(10000))) {
> > +			pages += tmp;
> > +			printk("\b%c", p[i]);
> > +			i++;
> > +			if (i > 3)
> > +				i = 0;
> > +		}
> > +		printk("\bdone (%li pages freed)\n", pages);
> > +		current->state = TASK_INTERRUPTIBLE;
> > +		schedule_timeout(HZ/5);
> > +	}
> >  }
> >  
> > -
> >  static inline void platform_finish(void)
> >  {
> >  	if (pm_disk_mode == PM_DISK_PLATFORM) {
> > -- 
> 
> I'm giving it a try.  Without this patch I get an 8-order allocation failure 
> almost every time after using a computer for a day.  This one is pretty 
> scary, IMO (there are 5 times more pages free than needed to be copied and 
> still it cannot allocate enough memory):

I does not help, apparently.  Below is what I've just got on -rc4 with this 
patch applied.  Please note that there were two attempts to suspend the box 
in a row and I've stopped some memory-consuming apps after the first one.

Now, as I've stopped all of the apps that I wanted/could stop before suspend, 
the box is unsuspendable for practical purposes.

The USB-related stuff in between is retained for completeness.

Oct 14 17:22:31 albercik kernel: Stopping tasks: 
===================================================================|
Oct 14 17:22:31 albercik kernel: Freeing memory...  ^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^
H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\
^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H
\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^
H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-
^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^Hdone (98884 pages freed)
Oct 14 17:22:31 albercik kernel: Freeing memory...  ^H-^Hdone (256 pages 
freed)
Oct 14 17:22:31 albercik kernel: Freeing memory...  ^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^Hdone (2560 pages freed)
Oct 14 17:22:31 albercik kernel: Freeing memory...  ^H-^H\^H|^H/^H-^H\^H|
^H/^H-^Hdone (2048 pages freed)
Oct 14 17:22:31 albercik kernel: Freeing memory...  ^H-^H\^H|^Hdone (656 pages 
freed)
Oct 14 17:22:31 albercik kernel: PM: Attempting to suspend to disk.
Oct 14 17:22:31 albercik kernel: PM: snapshotting memory.
Oct 14 17:22:31 albercik kernel: swsusp: critical section:
Oct 14 17:22:31 albercik kernel: ..<7>[nosave pfn 
0x58d]...................................................................................................
...............swsusp: Need to copy 18926 pages
Oct 14 17:22:31 albercik kernel: suspend: (pages needed: 18926 + 512 free: 
111953)
Oct 14 17:22:31 albercik kernel: hibernate.sh: page allocation failure. 
order:8, mode:0x120
Oct 14 17:22:31 albercik kernel:
Oct 14 17:22:33 albercik kernel: Call 
Trace:<ffffffff8016ec7d>{__alloc_pages+749} 
<ffffffff8016ed21>{__get_free_pages+33}
Oct 14 17:22:35 albercik kernel:        
<ffffffff80161b93>{suspend_prepare_image+531} 
<ffffffff802eae52>{suspend_device+50}
Oct 14 17:22:37 albercik kernel:        
<ffffffff80161e26>{swsusp_swap_check+22} 
<ffffffff802eaf2c>{device_suspend+76}
Oct 14 17:22:38 albercik kernel:        
<ffffffff80120dec>{swsusp_arch_suspend+124} 
<ffffffff8016123c>{swsusp_suspend+12}
Oct 14 17:22:40 albercik kernel:        <ffffffff801623ea>{pm_suspend_disk+90} 
<ffffffff8015ff54>{enter_state+68}
Oct 14 17:22:41 albercik kernel:        
<ffffffff802aed9d>{acpi_system_write_sleep+100} 
<ffffffff80194b74>{vfs_write+228}
Oct 14 17:22:43 albercik kernel:        <ffffffff80194cb3>{sys_write+83} 
<ffffffff80110c72>{system_call+126}
Oct 14 17:22:43 albercik kernel:
Oct 14 17:22:49 albercik kernel: suspend: Allocating pagedir failed.
Oct 14 17:22:50 albercik kernel: ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 
(level, low) -> IRQ 11
Oct 14 17:22:52 albercik kernel: PCI: Setting latency timer of device 
0000:00:02.0 to 64
Oct 14 17:22:54 albercik kernel: ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 
(level, low) -> IRQ 5
Oct 14 17:22:56 albercik kernel: PCI: Setting latency timer of device 
0000:00:02.1 to 64
Oct 14 17:22:57 albercik kernel: PCI: Setting latency timer of device 
0000:00:02.2 to 64
Oct 14 17:22:57 albercik kernel: ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 
(level, low) -> IRQ 5
Oct 14 17:22:57 albercik kernel: PCI: Setting latency timer of device 
0000:00:06.0 to 64
Oct 14 17:22:57 albercik kernel: ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 
(level, low) -> IRQ 11
Oct 14 17:22:57 albercik kernel: ACPI: PCI interrupt 0000:02:01.2[C] -> GSI 11 
(level, low) -> IRQ 11
Oct 14 17:22:57 albercik kernel: Restarting tasks... done
Oct 14 17:22:57 albercik kernel: ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host 
Controller (OHCI) Driver (PCI)
Oct 14 17:22:58 albercik kernel: ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 
(level, low) -> IRQ 11
Oct 14 17:22:59 albercik kernel: ohci_hcd 0000:00:02.0: nVidia Corporation 
nForce3 USB 1.1
Oct 14 17:23:00 albercik kernel: PCI: Setting latency timer of device 
0000:00:02.0 to 64
Oct 14 17:23:00 albercik kernel: ohci_hcd 0000:00:02.0: irq 11, pci mem 
ffffff00000c2000
Oct 14 17:23:00 albercik kernel: ohci_hcd 0000:00:02.0: new USB bus 
registered, assigned bus number 1
Oct 14 17:23:01 albercik kernel: hub 1-0:1.0: USB hub found
Oct 14 17:23:01 albercik kernel: hub 1-0:1.0: 3 ports detected
Oct 14 17:23:01 albercik kernel: ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 
(level, low) -> IRQ 5
Oct 14 17:23:01 albercik kernel: ohci_hcd 0000:00:02.1: nVidia Corporation 
nForce3 USB 1.1 (#2)
Oct 14 17:23:01 albercik kernel: PCI: Setting latency timer of device 
0000:00:02.1 to 64
Oct 14 17:23:01 albercik kernel: ohci_hcd 0000:00:02.1: irq 5, pci mem 
ffffff00000c4000
Oct 14 17:23:01 albercik kernel: ohci_hcd 0000:00:02.1: new USB bus 
registered, assigned bus number 2
Oct 14 17:23:01 albercik kernel: hub 2-0:1.0: USB hub found
Oct 14 17:23:01 albercik kernel: hub 2-0:1.0: 3 ports detected
Oct 14 17:23:01 albercik kernel: usb 2-2: new low speed USB device using 
address 2
Oct 14 17:23:01 albercik kernel: input: USB HID v1.10 Mouse [Logitech Optical 
USB Mouse] on usb-0000:00:02.1-2
Oct 14 17:23:01 albercik kernel: eth0: network connection down
Oct 14 17:23:03 albercik kernel: eth0: network connection up using port A
Oct 14 17:23:03 albercik kernel:     speed:           100
Oct 14 17:23:03 albercik kernel:     autonegotiation: yes
Oct 14 17:23:03 albercik kernel:     duplex mode:     full
Oct 14 17:23:03 albercik kernel:     flowctrl:        symmetric
Oct 14 17:23:03 albercik kernel:     irq moderation:  disabled
Oct 14 17:23:03 albercik kernel:     scatter-gather:  enabled
Oct 14 17:23:12 albercik kernel: eth0: no IPv6 routers present
Oct 14 17:25:13 albercik kernel: SysRq : Emergency Sync
Oct 14 17:25:13 albercik kernel: Emergency Sync complete
Oct 14 17:25:29 albercik kernel: ohci_hcd 0000:00:02.0: remove, state 1
Oct 14 17:25:29 albercik kernel: usb usb1: USB disconnect, address 1
Oct 14 17:25:29 albercik kernel: ohci_hcd 0000:00:02.0: USB bus 1 deregistered
Oct 14 17:25:29 albercik kernel: ohci_hcd 0000:00:02.1: remove, state 1
Oct 14 17:25:29 albercik kernel: usb usb2: USB disconnect, address 1
Oct 14 17:25:29 albercik kernel: usb 2-2: USB disconnect, address 2
Oct 14 17:25:30 albercik kernel: ohci_hcd 0000:00:02.1: USB bus 2 deregistered
Oct 14 17:26:44 albercik kernel: Stopping tasks: 
=============================================================|
Oct 14 17:26:44 albercik kernel: Freeing memory...  ^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^
H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|
^H/^H-^H\
^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^Hdone 
(36196 pages freed)
Oct 14 17:26:44 albercik kernel: Freeing memory...  ^H-^H\^H|^Hdone (531 pages 
freed)
Oct 14 17:26:44 albercik kernel: Freeing memory...  ^H-^Hdone (1 pages freed)
Oct 14 17:26:44 albercik kernel: Freeing memory...  ^H-^Hdone (144 pages 
freed)
Oct 14 17:26:44 albercik kernel: Freeing memory...  ^Hdone (0 pages freed)
Oct 14 17:26:44 albercik kernel: PM: Attempting to suspend to disk.
Oct 14 17:26:44 albercik kernel: PM: snapshotting memory.
Oct 14 17:26:44 albercik kernel: swsusp: critical section:
Oct 14 17:26:44 albercik kernel: ..<7>[nosave pfn 
0x58d]...................................................................................................
............swsusp: Need to copy 24528 pages
Oct 14 17:26:44 albercik kernel: suspend: (pages needed: 24528 + 512 free: 
106351)
Oct 14 17:26:44 albercik kernel: hibernate.sh: page allocation failure. 
order:8, mode:0x120
Oct 14 17:26:44 albercik kernel:
Oct 14 17:26:47 albercik kernel: Call 
Trace:<ffffffff8016ec7d>{__alloc_pages+749} 
<ffffffff8016ed21>{__get_free_pages+33}
Oct 14 17:26:49 albercik kernel:        
<ffffffff80161b93>{suspend_prepare_image+531} 
<ffffffff802eae52>{suspend_device+50}
Oct 14 17:26:50 albercik kernel:        
<ffffffff80161e26>{swsusp_swap_check+22} 
<ffffffff802eaf2c>{device_suspend+76}
Oct 14 17:26:52 albercik kernel:        
<ffffffff80120dec>{swsusp_arch_suspend+124} 
<ffffffff8016123c>{swsusp_suspend+12}
Oct 14 17:26:53 albercik kernel:        <ffffffff801623ea>{pm_suspend_disk+90} 
<ffffffff8015ff54>{enter_state+68}
Oct 14 17:26:53 albercik kernel:        
<ffffffff802aed9d>{acpi_system_write_sleep+100} 
<ffffffff80194b74>{vfs_write+228}
Oct 14 17:26:53 albercik kernel:        <ffffffff80194cb3>{sys_write+83} 
<ffffffff80110c72>{system_call+126}
Oct 14 17:26:53 albercik kernel:
Oct 14 17:26:53 albercik kernel: suspend: Allocating pagedir failed.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"