Hello,
suspending to disk is not supported on CONFIG_HIGHMEM64G setups
(http://suspend2.net/features). Also suspend to ram doesn't work. This patch
fixes Kconfig to disallow such combination. I'm not 100% sure about the
ACPI_SLEEP part, as it might be disabling some working setup - but i think
that s2r and s2d are the only acpi sleeps allowed, no?
Bye,
spity
PS: I didn't know that this is not supported so I had some nice oops after
resume (from ram) and s2d didn't resume at all :-)
--
Jan Spitalnik
[email protected]
On Fri 06-01-06 19:45:09, Jan Spitalnik wrote:
> Hello,
>
> suspending to disk is not supported on CONFIG_HIGHMEM64G setups
> (http://suspend2.net/features). Also suspend to ram doesn't work. This patch
NAK. suspend2.net describes very different code.
> fixes Kconfig to disallow such combination. I'm not 100% sure about the
> ACPI_SLEEP part, as it might be disabling some working setup - but i think
> that s2r and s2d are the only acpi sleeps allowed, no?
s2ram probably works. Try getting it working without highmem64,
then turn it on.
Dne p?tek 06 leden 2006 00:43 Pavel Machek napsal(a):
> On Fri 06-01-06 19:45:09, Jan Spitalnik wrote:
> > Hello,
> >
> > suspending to disk is not supported on CONFIG_HIGHMEM64G setups
> > (http://suspend2.net/features). Also suspend to ram doesn't work. This
> > patch
>
> NAK. suspend2.net describes very different code.
Well, I was using suspend2.net's page just as reference, to point out the fact
that HIGHMEM is on both suspend "platforms" supported only up to 4G.
I was not refering to suspend2's actual features, but rather swsusp's
(or what's the proper name for suspend1 code). So i guess the patch still
holds, no?
>
> > fixes Kconfig to disallow such combination. I'm not 100% sure about the
> > ACPI_SLEEP part, as it might be disabling some working setup - but i
> > think that s2r and s2d are the only acpi sleeps allowed, no?
>
> s2ram probably works. Try getting it working without highmem64,
> then turn it on.
It works with HIGHMEM but not HIGHMEM64G. You can find the oops from
HIGHMEM64G below. It crashes very reliably on little stress after resume.
Jan 5 20:12:47 hathor Unable to handle kernel paging request at virtual address dc025000
Jan 5 20:12:47 hathor printing eip:
Jan 5 20:12:47 hathor c013edcc
Jan 5 20:12:47 hathor *pde = 00000000
Jan 5 20:12:47 hathor Oops: 0002 [#3]
Jan 5 20:12:47 hathor Modules linked in: usbmouse i915 drm autofs4 bridge snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss pcspkr parport_pc\
parport irtty_sir sir_dev irda crc_ccitt 8250_pnp snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd usbhid uhc\
i_hcd intel_agp agpgart usbcore binfmt_misc nls_iso8859_2 nls_cp852 vfat fat nls_base tg3 evdev thermal fan 8250_acpi 8250 serial_core tun loop yenta_socket rsrc_nonstatic \
pcmcia pcmcia_core firmware_class rfcomm l2cap bluetooth
Jan 5 20:12:47 hathor CPU: 0
Jan 5 20:12:47 hathor EIP: 0060:[<c013edcc>] Not tainted VLI
Jan 5 20:12:47 hathor EFLAGS: 00010296 (2.6.15)
Jan 5 20:12:47 hathor EIP is at buffered_rmqueue+0x1bc/0x230
Jan 5 20:12:47 hathor eax: 00000000 ebx: c13804a0 ecx: 00000400 edx: dc025000
Jan 5 20:12:47 hathor esi: 00000000 edi: dc025000 ebp: 00000000 esp: de021e64
Jan 5 20:12:47 hathor ds: 007b es: 007b ss: 0068
Jan 5 20:12:47 hathor Process konqueror (pid: 11756, threadinfo=de020000 task=ed4600b0)
Jan 5 20:12:47 hathor Stack: c13804a0 00000003 0000001f c0319690 000081a4 00000001 00000000 c13804a0
Jan 5 20:12:47 hathor c03198ec 00000044 00000000 00000003 c013efda c0319660 00000000 000280d2
Jan 5 20:12:47 hathor 00000003 00000044 c03198e8 000280d2 ed4600b0 df0b4320 c013f05f 000280d2
Jan 5 20:12:47 hathor Call Trace:
Jan 5 20:12:47 hathor [<c013efda>] get_page_from_freelist+0xba/0xe0
Jan 5 20:12:47 hathor [<c013f05f>] __alloc_pages+0x5f/0x320
Jan 5 20:12:47 hathor [<c0150557>] anon_vma_prepare+0x17/0xa0
Jan 5 20:12:47 hathor [<c014b4e4>] do_anonymous_page+0x54/0x1e0
Jan 5 20:12:47 hathor [<c014baec>] __handle_mm_fault+0x12c/0x330
Jan 5 20:12:47 hathor [<c02cf5f5>] notifier_call_chain+0x25/0x50
Jan 5 20:12:47 hathor [<c02cf0c3>] do_page_fault+0x1c3/0x6d0
Jan 5 20:12:47 hathor [<c0159f33>] sys_close+0x53/0x70
Jan 5 20:12:47 hathor [<c02cef00>] do_page_fault+0x0/0x6d0
Jan 5 20:12:47 hathor [<c0103b03>] error_code+0x4f/0x54
Jan 5 20:12:47 hathor Code: fb 00 7e 44 89 5c 24 14 8b 5c 24 1c 31 f6 90 89 1c 24 ba 03 00 00 00 89 54 24 04 e8 6f 8a fd ff 89 c2 89 c7 b9 00 04 00 00 89 f0 <f3> ab 89 14 \
24 b8 03 00 00 00 45 89 44 24 04 e8 10 8b fd ff 83
Jan 5 20:12:47 hathor <6>note: konqueror[11756] exited with preempt_count 1
--
Jan Spitalnik
[email protected]
On Sat 07-01-06 16:04:03, Jan Spitalnik wrote:
> Dne p?tek 06 leden 2006 00:43 Pavel Machek napsal(a):
> > On Fri 06-01-06 19:45:09, Jan Spitalnik wrote:
> > > Hello,
> > >
> > > suspending to disk is not supported on CONFIG_HIGHMEM64G setups
> > > (http://suspend2.net/features). Also suspend to ram doesn't work. This
> > > patch
> >
> > NAK. suspend2.net describes very different code.
>
> Well, I was using suspend2.net's page just as reference, to point out the fact
> that HIGHMEM is on both suspend "platforms" supported only up to 4G.
> I was not refering to suspend2's actual features, but rather swsusp's
> (or what's the proper name for suspend1 code). So i guess the patch still
> holds, no?
No.
> > > fixes Kconfig to disallow such combination. I'm not 100% sure about the
> > > ACPI_SLEEP part, as it might be disabling some working setup - but i
> > > think that s2r and s2d are the only acpi sleeps allowed, no?
> >
> > s2ram probably works. Try getting it working without highmem64,
> > then turn it on.
>
> It works with HIGHMEM but not HIGHMEM64G. You can find the oops from
> HIGHMEM64G below. It crashes very reliably on little stress after resume.
>
s2ram should not depend on ammount of memory. Try debugging
it, but do not disable feature just because it does not work
for you. I'd start with minimum drivers...
--
Thanks, Sharp!
Dne p?tek 06 leden 2006 05:30 Pavel Machek napsal(a):
> On Sat 07-01-06 16:04:03, Jan Spitalnik wrote:
> > Dne p?tek 06 leden 2006 00:43 Pavel Machek napsal(a):
> > > On Fri 06-01-06 19:45:09, Jan Spitalnik wrote:
> > > > Hello,
> > > >
> > > > suspending to disk is not supported on CONFIG_HIGHMEM64G setups
> > > > (http://suspend2.net/features). Also suspend to ram doesn't work.
> > > > This patch
> > >
> > > NAK. suspend2.net describes very different code.
> >
> > Well, I was using suspend2.net's page just as reference, to point out the
> > fact that HIGHMEM is on both suspend "platforms" supported only up to 4G.
> > I was not refering to suspend2's actual features, but rather swsusp's (or
> > what's the proper name for suspend1 code). So i guess the patch still
> > holds, no?
>
> No.
Could you be please more specific? Is there some list of swsusp's features?
swsusp.txt says that it "A: It should work okay with highmem." Does that mean
both possible highmem configurations?
>
> > > > fixes Kconfig to disallow such combination. I'm not 100% sure about
> > > > the ACPI_SLEEP part, as it might be disabling some working setup -
> > > > but i think that s2r and s2d are the only acpi sleeps allowed, no?
> > >
> > > s2ram probably works. Try getting it working without highmem64,
> > > then turn it on.
> >
> > It works with HIGHMEM but not HIGHMEM64G. You can find the oops from
> > HIGHMEM64G below. It crashes very reliably on little stress after resume.
>
> s2ram should not depend on ammount of memory. Try debugging
> it, but do not disable feature just because it does not work
> for you. I'd start with minimum drivers...
Well, I've tried it with the bare minimum that was needed to run the system,
but it did the same. I'm sorry but i lack the knowledge to properly debug it
on source level. Do you see something that perhaps i don't see in the oops?
Maybe some clues as what might be going wrong?
Thanks,
--
Jan Spitalnik
[email protected]
> > > > > fixes Kconfig to disallow such combination. I'm not 100% sure about
> > > > > the ACPI_SLEEP part, as it might be disabling some working setup -
> > > > > but i think that s2r and s2d are the only acpi sleeps allowed, no?
> > > >
> > > > s2ram probably works. Try getting it working without highmem64,
> > > > then turn it on.
> > >
> > > It works with HIGHMEM but not HIGHMEM64G. You can find the oops from
> > > HIGHMEM64G below. It crashes very reliably on little stress after resume.
> >
> > s2ram should not depend on ammount of memory. Try debugging
> > it, but do not disable feature just because it does not work
> > for you. I'd start with minimum drivers...
>
> Well, I've tried it with the bare minimum that was needed to run the system,
> but it did the same. I'm sorry but i lack the knowledge to properly debug it
> on source level. Do you see something that perhaps i don't see in the oops?
> Maybe some clues as what might be going wrong?
I tried highmem64 on -mm2 here, and machine did not even boot :-(. I
may try it again on latest -git a bit later.
Pavel
--- clean-mm/.config 2006-01-08 13:55:53.000000000 +0100
+++ linux-mm/.config 2006-01-08 14:18:22.000000000 +0100
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15-mm2
-# Sun Jan 8 13:55:53 2006
+# Sun Jan 8 14:18:22 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
@@ -165,9 +165,10 @@
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
+# CONFIG_HIGHMEM4G is not set
+CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
+CONFIG_X86_PAE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
@@ -179,7 +180,7 @@
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
-# CONFIG_HIGHPTE is not set
+CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
--
Thanks, Sharp!
> > > > s2ram probably works. Try getting it working without highmem64,
> > > > then turn it on.
> > >
> > > It works with HIGHMEM but not HIGHMEM64G. You can find the oops from
> > > HIGHMEM64G below. It crashes very reliably on little stress after resume.
> >
> > s2ram should not depend on ammount of memory. Try debugging
> > it, but do not disable feature just because it does not work
> > for you. I'd start with minimum drivers...
>
> Well, I've tried it with the bare minimum that was needed to run the system,
> but it did the same. I'm sorry but i lack the knowledge to properly debug it
> on source level. Do you see something that perhaps i don't see in the oops?
> Maybe some clues as what might be going wrong?
HIGHMEM64G breaks boot on my thinkpad (pretty recent git). I guess I'm
not solving this one.
Pavel
--
Thanks, Sharp!
Hi!
I tried pretty recent -git, and selecting HIGHMEM64 breaks boot,
too. I guess I'm giving up for now.
Pavel
--
Thanks, Sharp!
> > > Well, I was using suspend2.net's page just as reference, to point out the
> > > fact that HIGHMEM is on both suspend "platforms" supported only up to 4G.
> > > I was not refering to suspend2's actual features, but rather swsusp's (or
> > > what's the proper name for suspend1 code). So i guess the patch still
> > > holds, no?
> >
> > No.
>
> Could you be please more specific? Is there some list of swsusp's features?
> swsusp.txt says that it "A: It should work okay with highmem." Does that mean
> both possible highmem configurations?
It should work in all configurations. I'd like to try fixing
it before disabling it in config.
> > s2ram should not depend on ammount of memory. Try debugging
> > it, but do not disable feature just because it does not work
> > for you. I'd start with minimum drivers...
>
> Well, I've tried it with the bare minimum that was needed to run the system,
> but it did the same. I'm sorry but i lack the knowledge to properly debug it
> on source level. Do you see something that perhaps i don't see in the oops?
> Maybe some clues as what might be going wrong?
No clues :-(. I'll try reproducing it locally.
--
Thanks, Sharp!