On Monday, 9 October 2006 01:28, Luca Tettamanti wrote:
> Il Mon, Oct 09, 2006 at 12:24:56AM +0200, Pavel Machek ha scritto:
> > Hi!
> >
> > > > Could it be that the pm_ops->finish(SUSPEND_MEM) is somehow running
> > > > asynchronously? And that something in the hardware forbids accessing
> > > > certain
> > > > memory regions while the AML code is still executed? Just wild guessing
> > > > :-)
> > > >
> > > > Or asked the other way round:
> > > > "What exactly is forbidden while all processes but the suspend program
> > > > are
> > > > frozen?"
> > > > If we know what is forbidden, we might find out what we are doing wrong.
> > > >
> > > > Or: "What conditions can cause the kernel to kill a process with signal
> > > > 11"?
> > >
> > > Since it's somewhat related to memory pressure: maybe (part of) the text
> > > segment of either s2ram or glibc is evicted from memory or not yet
> > > faulted in. Upon resume but before unfreeze() s2ram takes a page fault
> > > but since no I/O can be started it just die. Make sense?
> >
> > No... it would hang waiting for disk to deliver the page...
>
> Hum, pm_sem is held during suspension. Can this confuse the fault
> handler? (I see that do_page_fault checks in_atomic(), but we are using
> a sem so it shouldn't matter).
>
> Stefan says that:
> > it segfaults in the first glibc function used.
>
> It happens on memory pressure, seems timing related, it looks like a
> race... maybe something in the order in which kernel threads and
> processes are unfrozen (shooting in the dark)?
>
> Also (this may be a separate bug), when I added the S2RAM ioctl I used
> the code in enter_state (kernel/power/main.c) as a reference; later
> Linus added suspend_console (557240b48e2dc4f6fa878afc3fc767ad745ca7ed)
> to the codepath used by /sys/power/state but not to the ioctl.
>
> A printf may be involved so (again, shooting in the dark), what about
> this one (against current git):
>
> diff --git a/kernel/power/user.c b/kernel/power/user.c
> index 93b5dd2..c5f329f 100644
> --- a/kernel/power/user.c
> +++ b/kernel/power/user.c
> @@ -20,6 +20,7 @@ #include <linux/swapops.h>
> #include <linux/pm.h>
> #include <linux/fs.h>
> #include <linux/cpu.h>
> +#include <linux/console.h>
>
> #include <asm/uaccess.h>
>
> @@ -288,6 +289,7 @@ static int snapshot_ioctl(struct inode *
> goto OutS3;
> }
>
> + suspend_console();
> /* Put devices to sleep */
> error = device_suspend(PMSG_SUSPEND);
> if (error) {
> @@ -304,6 +306,7 @@ static int snapshot_ioctl(struct inode *
> pm_ops->finish(PM_SUSPEND_MEM);
>
> OutS3:
> + resume_console();
> up(&pm_sem);
> break;
>
>
> >
> > > Can you try this patch:
> >
> > ...but that patch makes lot of sense, anyway. I thought we did that,
> > already?
>
> Yeah, I was surprised too ;)
Well, similar thing has been queued up for merging in -mm for some time
already. :-)
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
