swsusp hangs on headless resume-from-ram

swsusp hangs on headless resume-from-ram

[Al Boldi]

swsusp is really great, most of the time.  But sometimes it hangs after 
coming out of STR.  I suspect it's got something to do with display access, 
as this problem seems hw related.  So I removed the display card, and it 
positively does not resume from ram on 2.6.16+.

Any easy fix for this?


Thanks!

--
Al

Re: swsusp hangs on headless resume-from-ram

[Rafael J. Wysocki]

On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> 
> swsusp is really great, most of the time.  But sometimes it hangs after 
> coming out of STR.  I suspect it's got something to do with display access, 
> as this problem seems hw related.  So I removed the display card, and it 
> positively does not resume from ram on 2.6.16+.
> 
> Any easy fix for this?

I have one idea, but you'll need a patch to test.  I'll try to prepare it tomorrow.

I guess your box is an i386?

Rafael

Re: swsusp hangs on headless resume-from-ram

[Al Boldi]

Rafael J. Wysocki wrote:
> On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > swsusp is really great, most of the time.  But sometimes it hangs after
> > coming out of STR.  I suspect it's got something to do with display
> > access, as this problem seems hw related.  So I removed the display
> > card, and it positively does not resume from ram on 2.6.16+.
> >
> > Any easy fix for this?
>
> I have one idea, but you'll need a patch to test.  I'll try to prepare it
> tomorrow.
>
> I guess your box is an i386?

That should be assumed by default :)


Thanks for looking into this!


--
Al

Re: swsusp hangs on headless resume-from-ram

[Rafael J. Wysocki]

On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > > swsusp is really great, most of the time.  But sometimes it hangs after
> > > coming out of STR.  I suspect it's got something to do with display
> > > access, as this problem seems hw related.  So I removed the display
> > > card, and it positively does not resume from ram on 2.6.16+.
> > >
> > > Any easy fix for this?
> >
> > I have one idea, but you'll need a patch to test.  I'll try to prepare it
> > tomorrow.
> >
> > I guess your box is an i386?
> 
> That should be assumed by default :)

I had hoped I would be able to test it somewhere, but I couldn't.  I hope
it will compile. :-)

If it does, please send me the output of dmesg after a fresh boot.

Rafael


--
 arch/i386/kernel/setup.c |   34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

Index: linux-2.6.18-rc2/arch/i386/kernel/setup.c
===================================================================
--- linux-2.6.18-rc2.orig/arch/i386/kernel/setup.c	2006-07-28 10:27:44.000000000 +0200
+++ linux-2.6.18-rc2/arch/i386/kernel/setup.c	2006-07-28 10:51:33.000000000 +0200
@@ -1301,14 +1301,33 @@ void __init remapped_pgdat_init(void)
 	}
 }
 
+/* Mark pages corresponding to given address range as nosave */
+static void __init
+e820_mark_nosave_range(unsigned long start, unsigned long end)
+{
+	unsigned long pfn, max_pfn;
+
+	if (start >= end)
+		return;
+
+	printk("Nosave address range: %016lx - %016lx\n", start, end);
+	max_pfn = end >> PAGE_SHIFT;
+	for (pfn = start >> PAGE_SHIFT; pfn < max_pfn; pfn++)
+		if(pfn_valid(pfn))
+			SetPageNosave(pfn_to_page(pfn));
+}
+
 /*
  * Request address space for all standard RAM and ROM resources
  * and also for regions reported as reserved by the e820.
+ *
+ * Mark memory gaps and the reserved regions as nosave.
  */
 static void __init
 legacy_init_iomem_resources(struct resource *code_resource, struct resource *data_resource)
 {
 	int i;
+	unsigned long paddr;
 
 	probe_roms();
 	for (i = 0; i < e820.nr_map; i++) {
@@ -1344,6 +1363,21 @@ legacy_init_iomem_resources(struct resou
 #endif
 		}
 	}
+
+	paddr = (e820.map[0].addr + e820.map[0].size) & ~(PAGE_SIZE - 1);
+	for (i = 1; i < e820.nr_map; i++) {
+		struct e820entry *ei = &e820.map[i];
+		unsigned long base;
+
+		/* Check if we have any nosave pages here */
+		base = (ei->addr + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1);
+		if (paddr < ei->addr)
+			e820_mark_nosave_range(paddr, base);
+
+		paddr = (ei->addr + ei->size) & ~(PAGE_SIZE - 1);
+		if (ei->type != E820_RAM)
+			e820_mark_nosave_range(base, paddr);
+	}
 }
 
 /*

Re: swsusp hangs on headless resume-from-ram

[Al Boldi]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Rafael J. Wysocki wrote:
> On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> > Rafael J. Wysocki wrote:
> > > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > > > swsusp is really great, most of the time.  But sometimes it hangs
> > > > after coming out of STR.  I suspect it's got something to do with
> > > > display access, as this problem seems hw related.  So I removed the
> > > > display card, and it positively does not resume from ram on 2.6.16+.
> > > >
> > > > Any easy fix for this?
> > >
> > > I have one idea, but you'll need a patch to test.  I'll try to prepare
> > > it tomorrow.
> > >
> > > I guess your box is an i386?
> >
> > That should be assumed by default :)
>
> I had hoped I would be able to test it somewhere, but I couldn't.  I hope
> it will compile. :-)
>
> If it does, please send me the output of dmesg after a fresh boot.

See attached.  patched against 2.6.17.

Thanks!

--
Al



[-- Attachment #2: s2r.disp.log --]
[-- Type: text/x-log, Size: 6580 bytes --]

Linux version 2.6.17 (root@localhost) (gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)) #1 Fri Jul 28 15:05:07 AST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 61424 pages, LIFO batch:15
DMI 2.1 present.
ACPI: RSDP (v000 COMPAQ                                ) @ 0x000f7090
ACPI: RSDT (v001 COMPAQ CPQB0B9  0x00000000  0x00000000) @ 0x0fff3000
ACPI: FADT (v001 COMPAQ CPQB0B9  0x00000000  0x00000000) @ 0x0fff3040
ACPI: DSDT (v001 COMPAQ AWRDACPI 0x00001000 MSFT 0x01000007) @ 0x00000000
Allocating PCI resources starting at 20000000 (gap: 10000000:efff0000)
Built 1 zonelists
Kernel command line: root=/dev/nfs ip=bootp nfsroot=rh52 lapic BOOT_IMAGE=grub/v617.s2r 
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to ffffd000 (fee00000)
Enabling fast FPU save and restore... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 432.363 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256600k/262080k available (1770k kernel code, 4988k reserved, 560k data, 212k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 865.63 BogoMIPS (lpj=432815)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183fbff 00000000 00000000 00000040 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 05
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 0k freed
ACPI: setting ELCR to 0200 (from 8c00)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb180, last bus=1
Setting up standard PCI resources
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Nosave address range: 000000000fff0000 - 000000000fff3000
Nosave address range: 000000000fff3000 - 0000000010000000
Nosave address range: 0000000010000000 - 00000000ffff0000
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region 4000-403f claimed by PIIX4 ACPI
PCI quirk: region 5000-500f claimed by PIIX4 SMB
Boot video device is 0000:00:0a.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
ACPI: Power Resource [PFAN] (on)
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: disabled.
  PREFETCH window: disabled.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered (default)
Limiting direct PCI/PCI transfers.
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (35 C)
Real Time Clock Driver v1.12ac
Linux Tulip driver version 1.1.13 (May 11, 2002)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip0:  MII transceiver #0 config 1000 status 782d advertising 01e1.
eth0: Digital DS21140 Tulip rev 34 at 0001e400, 00:80:C8:45:77:A9, IRQ 11.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PCI: Enabling device 0000:00:07.1 (0000 -> 0001)
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
PIIX4: neither IDE port enabled (BIOS)
Probing IDE interface ide0...
Probing IDE interface ide1...
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI wakeup devices: 
USB0 
ACPI: (supports S0 S1 S3 S4 S5)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.2
IP-Config: Complete:
      device=eth0, addr=10.0.0.2, mask=255.0.0.0, gw=10.0.0.1,
     host=10.0.0.2, domain=intranet, nis-domain=(none),
     bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=
Looking up port of RPC 100003/2 on 10.0.0.1
Looking up port of RPC 100005/1 on 10.0.0.1
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 212k freed
eth0: Setting full-duplex based on MII#0 link partner capability of 05e1.
Stopping tasks: =============|
ACPI: PCI interrupt for device 0000:00:08.0 disabled
Back to C!
PM: Writing back config space on device 0000:00:07.1 at offset 1 (was 2800000, writing 2800001)
PM: Writing back config space on device 0000:00:08.0 at offset 1 (was 2800000, writing 2800007)
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
PM: Writing back config space on device 0000:00:0a.0 at offset 1 (was 2000000, writing 2000007)
Restarting tasks... done

[-- Attachment #3: s2r.nodisp.log --]
[-- Type: text/x-log, Size: 6075 bytes --]

Linux version 2.6.17 (root@localhost) (gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)) #1 Fri Jul 28 15:05:07 AST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 61424 pages, LIFO batch:15
DMI 2.1 present.
ACPI: RSDP (v000 COMPAQ                                ) @ 0x000f7090
ACPI: RSDT (v001 COMPAQ CPQB0B9  0x00000000  0x00000000) @ 0x0fff3000
ACPI: FADT (v001 COMPAQ CPQB0B9  0x00000000  0x00000000) @ 0x0fff3040
ACPI: DSDT (v001 COMPAQ AWRDACPI 0x00001000 MSFT 0x01000007) @ 0x00000000
Allocating PCI resources starting at 20000000 (gap: 10000000:efff0000)
Built 1 zonelists
Kernel command line: root=/dev/nfs ip=bootp nfsroot=rh52 lapic BOOT_IMAGE=grub/v617.s2r 
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to ffffd000 (fee00000)
Enabling fast FPU save and restore... done.
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 432.483 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256600k/262080k available (1770k kernel code, 4988k reserved, 560k data, 212k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 865.59 BogoMIPS (lpj=432797)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183fbff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0183fbff 00000000 00000000 00000040 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 05
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 0k freed
ACPI: setting ELCR to 0200 (from 8800)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb180, last bus=1
Setting up standard PCI resources
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Nosave address range: 000000000fff0000 - 000000000fff3000
Nosave address range: 000000000fff3000 - 0000000010000000
Nosave address range: 0000000010000000 - 00000000ffff0000
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region 4000-403f claimed by PIIX4 ACPI
PCI quirk: region 5000-500f claimed by PIIX4 SMB
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
ACPI: Power Resource [PFAN] (on)
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: disabled.
  PREFETCH window: disabled.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered (default)
Limiting direct PCI/PCI transfers.
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (38 C)
Real Time Clock Driver v1.12ac
Linux Tulip driver version 1.1.13 (May 11, 2002)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
tulip0:  MII transceiver #0 config 1000 status 782d advertising 01e1.
eth0: Digital DS21140 Tulip rev 34 at 0001e400, 00:80:C8:45:77:A9, IRQ 11.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PCI: Enabling device 0000:00:07.1 (0000 -> 0001)
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
PIIX4: neither IDE port enabled (BIOS)
Probing IDE interface ide0...
Probing IDE interface ide1...
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI wakeup devices: 
USB0 
ACPI: (supports S0 S1 S3 S4 S5)
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.2
IP-Config: Complete:
      device=eth0, addr=10.0.0.2, mask=255.0.0.0, gw=10.0.0.1,
     host=10.0.0.2, domain=intranet, nis-domain=(none),
     bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=
Looking up port of RPC 100003/2 on 10.0.0.1
Looking up port of RPC 100005/1 on 10.0.0.1
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 212k freed
eth0: Setting full-duplex based on MII#0 link partner capability of 05e1.

Re: swsusp hangs on headless resume-from-ram

[Rafael J. Wysocki]

On Friday 28 July 2006 15:58, Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > > > > swsusp is really great, most of the time.  But sometimes it hangs
> > > > > after coming out of STR.  I suspect it's got something to do with
> > > > > display access, as this problem seems hw related.  So I removed the
> > > > > display card, and it positively does not resume from ram on 2.6.16+.
> > > > >
> > > > > Any easy fix for this?
> > > >
> > > > I have one idea, but you'll need a patch to test.  I'll try to prepare
> > > > it tomorrow.
> > > >
> > > > I guess your box is an i386?
> > >
> > > That should be assumed by default :)
> >
> > I had hoped I would be able to test it somewhere, but I couldn't.  I hope
> > it will compile. :-)
> >
> > If it does, please send me the output of dmesg after a fresh boot.
> 
> See attached.  patched against 2.6.17.

Well, the nosave ranges are the same in both cases, so it doesn't look
very promising.

Have you tried to suspend with the patch applied?

Rafael

Re: swsusp hangs on headless resume-from-ram

[Rafael J. Wysocki]

On Friday 28 July 2006 16:23, Rafael J. Wysocki wrote:
> On Friday 28 July 2006 15:58, Al Boldi wrote:
> > Rafael J. Wysocki wrote:
> > > On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > > > > > swsusp is really great, most of the time.  But sometimes it hangs
> > > > > > after coming out of STR.  I suspect it's got something to do with
> > > > > > display access, as this problem seems hw related.  So I removed the
> > > > > > display card, and it positively does not resume from ram on 2.6.16+.
> > > > > >
> > > > > > Any easy fix for this?
> > > > >
> > > > > I have one idea, but you'll need a patch to test.  I'll try to prepare
> > > > > it tomorrow.
> > > > >
> > > > > I guess your box is an i386?
> > > >
> > > > That should be assumed by default :)
> > >
> > > I had hoped I would be able to test it somewhere, but I couldn't.  I hope
> > > it will compile. :-)
> > >
> > > If it does, please send me the output of dmesg after a fresh boot.
> > 
> > See attached.  patched against 2.6.17.
> 
> Well, the nosave ranges are the same in both cases, so it doesn't look
> very promising.
> 
> Have you tried to suspend with the patch applied?

Ouch, sorry, it won't work.  It will have a chance to work with the appended
patch applied.

However, I've just noticed you said it didn't resume from RAM and these
two patches could only fix the resume from disk. ;-)  As far as the
resume from RAM is concerned, I can only advise you to use a
newest possible kernel and see if the problem is still there.

Greetings,
Rafael


---
 kernel/power/snapshot.c |   62 ++++++++++++++++++++++++------------------------
 1 files changed, 32 insertions(+), 30 deletions(-)

Index: linux-2.6.18-rc1/kernel/power/snapshot.c
===================================================================
--- linux-2.6.18-rc1.orig/kernel/power/snapshot.c	2006-07-09 19:48:05.000000000 +0200
+++ linux-2.6.18-rc1/kernel/power/snapshot.c	2006-07-09 20:26:19.000000000 +0200
@@ -156,7 +156,7 @@ static inline int save_highmem(void) {re
 static inline int restore_highmem(void) {return 0;}
 #endif
 
-static int pfn_is_nosave(unsigned long pfn)
+static inline int pfn_is_nosave(unsigned long pfn)
 {
 	unsigned long nosave_begin_pfn = __pa(&__nosave_begin) >> PAGE_SHIFT;
 	unsigned long nosave_end_pfn = PAGE_ALIGN(__pa(&__nosave_end)) >> PAGE_SHIFT;
@@ -167,43 +167,43 @@ static int pfn_is_nosave(unsigned long p
  *	saveable - Determine whether a page should be cloned or not.
  *	@pfn:	The page
  *
- *	We save a page if it's Reserved, and not in the range of pages
- *	statically defined as 'unsaveable', or if it isn't reserved, and
- *	isn't part of a free chunk of pages.
+ *	We save a page if it isn't Nosave, and is not in the range of pages
+ *	statically defined as 'unsaveable', and it
+ *	isn't a part of a free chunk of pages.
  */
 
-static int saveable(struct zone *zone, unsigned long *zone_pfn)
+static struct page *saveable_page(unsigned long pfn)
 {
-	unsigned long pfn = *zone_pfn + zone->zone_start_pfn;
 	struct page *page;
 
 	if (!pfn_valid(pfn))
-		return 0;
+		return NULL;
 
 	page = pfn_to_page(pfn);
-	BUG_ON(PageReserved(page) && PageNosave(page));
+
 	if (PageNosave(page))
-		return 0;
+		return NULL;
 	if (PageReserved(page) && pfn_is_nosave(pfn))
-		return 0;
+		return NULL;
 	if (PageNosaveFree(page))
-		return 0;
+		return NULL;
 
-	return 1;
+	return page;
 }
 
 unsigned int count_data_pages(void)
 {
 	struct zone *zone;
-	unsigned long zone_pfn;
+	unsigned long pfn, max_zone_pfn;
 	unsigned int n = 0;
 
 	for_each_zone (zone) {
 		if (is_highmem(zone))
 			continue;
 		mark_free_pages(zone);
-		for (zone_pfn = 0; zone_pfn < zone->spanned_pages; ++zone_pfn)
-			n += saveable(zone, &zone_pfn);
+		max_zone_pfn = zone->zone_start_pfn + zone->spanned_pages;
+		for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++)
+			n += !!saveable_page(pfn);
 	}
 	return n;
 }
@@ -211,7 +211,7 @@ unsigned int count_data_pages(void)
 static void copy_data_pages(struct pbe *pblist)
 {
 	struct zone *zone;
-	unsigned long zone_pfn;
+	unsigned long pfn, max_zone_pfn;
 	struct pbe *pbe, *p;
 
 	pbe = pblist;
@@ -224,13 +224,14 @@ static void copy_data_pages(struct pbe *
 			SetPageNosaveFree(virt_to_page(p));
 		for_each_pbe (p, pblist)
 			SetPageNosaveFree(virt_to_page(p->address));
-		for (zone_pfn = 0; zone_pfn < zone->spanned_pages; ++zone_pfn) {
-			if (saveable(zone, &zone_pfn)) {
-				struct page *page;
+		max_zone_pfn = zone->zone_start_pfn + zone->spanned_pages;
+		for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++) {
+			struct page *page = saveable_page(pfn);
+
+			if (page) {
 				long *src, *dst;
 				int n;
 
-				page = pfn_to_page(zone_pfn + zone->zone_start_pfn);
 				BUG_ON(!pbe);
 				pbe->orig_address = (unsigned long)page_address(page);
 				/* copy_page and memcpy are not usable for copying task structs. */
@@ -383,13 +384,14 @@ static struct pbe *alloc_pagedir(unsigne
 void swsusp_free(void)
 {
 	struct zone *zone;
-	unsigned long zone_pfn;
+	unsigned long pfn, max_zone_pfn;
 
 	for_each_zone(zone) {
-		for (zone_pfn = 0; zone_pfn < zone->spanned_pages; ++zone_pfn)
-			if (pfn_valid(zone_pfn + zone->zone_start_pfn)) {
-				struct page *page;
-				page = pfn_to_page(zone_pfn + zone->zone_start_pfn);
+		max_zone_pfn = zone->zone_start_pfn + zone->spanned_pages;
+		for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++)
+			if (pfn_valid(pfn)) {
+				struct page *page = pfn_to_page(pfn);
+
 				if (PageNosave(page) && PageNosaveFree(page)) {
 					ClearPageNosave(page);
 					ClearPageNosaveFree(page);
@@ -598,7 +600,7 @@ int snapshot_read_next(struct snapshot_h
 static int mark_unsafe_pages(struct pbe *pblist)
 {
 	struct zone *zone;
-	unsigned long zone_pfn;
+	unsigned long pfn, max_zone_pfn;
 	struct pbe *p;
 
 	if (!pblist) /* a sanity check */
@@ -606,10 +608,10 @@ static int mark_unsafe_pages(struct pbe 
 
 	/* Clear page flags */
 	for_each_zone (zone) {
-		for (zone_pfn = 0; zone_pfn < zone->spanned_pages; ++zone_pfn)
-			if (pfn_valid(zone_pfn + zone->zone_start_pfn))
-				ClearPageNosaveFree(pfn_to_page(zone_pfn +
-					zone->zone_start_pfn));
+		max_zone_pfn = zone->zone_start_pfn + zone->spanned_pages;
+		for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++)
+			if (pfn_valid(pfn))
+				ClearPageNosaveFree(pfn_to_page(pfn));
 	}
 
 	/* Mark orig addresses */

Re: swsusp hangs on headless resume-from-ram

[Al Boldi]

Rafael J. Wysocki wrote:
> On Friday 28 July 2006 16:23, Rafael J. Wysocki wrote:
> > On Friday 28 July 2006 15:58, Al Boldi wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> > > > > Rafael J. Wysocki wrote:
> > > > > > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
> > > > > > > swsusp is really great, most of the time.  But sometimes it
> > > > > > > hangs after coming out of STR.  I suspect it's got something
> > > > > > > to do with display access, as this problem seems hw related. 
> > > > > > > So I removed the display card, and it positively does not
> > > > > > > resume from ram on 2.6.16+.
> > > > > > >
> > > > > > > Any easy fix for this?
> > > > > >
> > > > > > I have one idea, but you'll need a patch to test.  I'll try to
> > > > > > prepare it tomorrow.
> > > > > >
> > > > > > I guess your box is an i386?
> > > > >
> > > > > That should be assumed by default :)
> > > >
> > > > I had hoped I would be able to test it somewhere, but I couldn't.  I
> > > > hope it will compile. :-)
> > > >
> > > > If it does, please send me the output of dmesg after a fresh boot.
> > >
> > > See attached.  patched against 2.6.17.
> >
> > Well, the nosave ranges are the same in both cases, so it doesn't look
> > very promising.
> >
> > Have you tried to suspend with the patch applied?
>
> Ouch, sorry, it won't work.  It will have a chance to work with the
> appended patch applied.
>
> However, I've just noticed you said it didn't resume from RAM and these
> two patches could only fix the resume from disk. ;-)

Actually, I'm using suspend-to-disk to work around this STR problem, and STD 
seems to work fine.  It's STR that sometimes hangs after resuming.

> As far as the
> resume from RAM is concerned, I can only advise you to use a
> newest possible kernel and see if the problem is still there.

Have there been patches that address this issue?

Thanks!

--
Al

Re: swsusp hangs on headless resume-from-ram

[Rafael J. Wysocki]

On Friday 28 July 2006 23:00, Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Friday 28 July 2006 16:23, Rafael J. Wysocki wrote:
> > > On Friday 28 July 2006 15:58, Al Boldi wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > On Wednesday 26 July 2006 23:34, Al Boldi wrote:
> > > > > > Rafael J. Wysocki wrote:
> > > > > > > On Wednesday 26 July 2006 21:06, Al Boldi wrote:
]--snip--[
> > However, I've just noticed you said it didn't resume from RAM and these
> > two patches could only fix the resume from disk. ;-)
> 
> Actually, I'm using suspend-to-disk to work around this STR problem, and STD 
> seems to work fine.  It's STR that sometimes hangs after resuming.
> 
> > As far as the
> > resume from RAM is concerned, I can only advise you to use a
> > newest possible kernel and see if the problem is still there.
> 
> Have there been patches that address this issue?

Not this specific one, AFAICT, but generally there have been many patches
after 2.6.17 so it's better to check.  If the problem still occurs on
2.6.18-rc2, please create a bugzilla entry for it.

Greetings,
Rafael

Re: swsusp hangs on headless resume-from-ram

[Pavel Machek]

Hi!

> > > > swsusp is really great, most of the time.  But sometimes it hangs after
> > > > coming out of STR.  I suspect it's got something to do with display
                      ~~~

> > > > access, as this problem seems hw related.  So I removed the display
> > > > card, and it positively does not resume from ram on 2.6.16+.
> > > >
> > > > Any easy fix for this?
> > >
> > > I have one idea, but you'll need a patch to test.  I'll try to prepare it
> > > tomorrow.
> > >
> > > I guess your box is an i386?
> > 
> > That should be assumed by default :)
> 
> I had hoped I would be able to test it somewhere, but I couldn't.  I hope
> it will compile. :-)
> 
> If it does, please send me the output of dmesg after a fresh boot.

It seems to me Al is talking suspend-to-RAM (?).

-- 
Thanks for all the (sleeping) penguins.

Re: swsusp hangs on headless resume-from-ram

[Pavel Machek]

On Wed 26-07-06 22:06:48, Al Boldi wrote:
> 
> swsusp is really great, most of the time.  But sometimes it hangs after 
> coming out of STR.  I suspect it's got something to do with display access, 
> as this problem seems hw related.  So I removed the display card, and it 
> positively does not resume from ram on 2.6.16+.
> 
> Any easy fix for this?

Nothing easy.

Can you confirm that it still hangs with init=/bin/bash, then echo 3 >
/proc/acpi/sleep, no acpi_sleep options?

							Pavel

-- 
Thanks for all the (sleeping) penguins.

Re: swsusp hangs on headless resume-from-ram

[Al Boldi]

Pavel Machek wrote:
> On Wed 26-07-06 22:06:48, Al Boldi wrote:
> > swsusp is really great, most of the time.  But sometimes it hangs after
> > coming out of STR.  I suspect it's got something to do with display
> > access, as this problem seems hw related.  So I removed the display
> > card, and it positively does not resume from ram on 2.6.16+.
> >
> > Any easy fix for this?
>
> Nothing easy.
>
> Can you confirm that it still hangs with init=/bin/bash, then echo 3 >
> /proc/acpi/sleep, no acpi_sleep options?

Still hangs.

Thanks for looking into this!

--
Al

Re: swsusp hangs on headless resume-from-ram

[Pavel Machek]

On Wed 2006-08-02 16:46:11, Al Boldi wrote:
> Pavel Machek wrote:
> > On Wed 26-07-06 22:06:48, Al Boldi wrote:
> > > swsusp is really great, most of the time.  But sometimes it hangs after
> > > coming out of STR.  I suspect it's got something to do with display
> > > access, as this problem seems hw related.  So I removed the display
> > > card, and it positively does not resume from ram on 2.6.16+.
> > >
> > > Any easy fix for this?
> >
> > Nothing easy.
> >
> > Can you confirm that it still hangs with init=/bin/bash, then echo 3 >
> > /proc/acpi/sleep, no acpi_sleep options?
> 
> Still hangs.
> 
> Thanks for looking into this!

bugzilla.kernel.org time? Cc me...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html