On Tue, Nov 14, 2006 at 12:25:00PM +1100, Jim wrote:
> On Mon, Nov 06, 2006 at 12:05:06PM +0100, Stefan Seyfried wrote:
> > Yes. Just one question: does it also work from the console or only
> > from X?
>
> Works from both.
>
> Hiccup on the console. When it resumes, the console is double space
On Sun, Nov 26, 2006 at 08:35:37PM +0100, Pavel Machek wrote:
> I do not think we have that machine in whitelist. (Stefan?)
> Can you do s2ram (as root) so that we know DMI strings to whitelist?
Yes, please do (as root):
s2ram -n
and post the complete output of this command. Then we know if it
On Mon, Nov 06, 2006 at 06:24:10PM +0200, sir_j wrote:
> hi Stephan.
> >If you keep the suspend-devel list cc-ed, you might even get faster answers
> >:-)
> >
> Could show me full string for suspend-devel list ?
suspend-devel@lists.sourceforge.net
> > Hm, this looks like either you are not runn
On Sun, Nov 26, 2006 at 04:12:43PM -0800, Ross Patterson wrote:
> Thanks so much for uswsusp! I couldn't get "acpitool -s" to work
> because the mouse/pointer cursor would be invisible after suspend to
> RAM, but "s2ram -f -a3" as suggested under the Intel chipsets hint
> works great.
>
> Also, I
On Mon, 27 Nov 2006, Pavel Machek wrote:
> Hi!
>
> > > If frozen is atomic_t, do we need memory barrier?
> >
> > I think so. For example on x86-64 atomic_read() is just a read.
>
> I'm not sure, but for x86-64 barriers are nops, anyway, IIRC.
atomic_read() does not include its own memory barr
On 11/26/06, Pavel Machek <[EMAIL PROTECTED]> wrote:
===
> > --- linux-2.6.19-rc6-mm1.orig/include/linux/sched.h
> > +++ linux-2.6.19-rc6-mm1/include/linux/sched.h
> > @@ -1065,6 +1065,9 @@ struct task_struct {
> > #ifdef CONFIG
Hi!
> > Maybe we should add SNAPSHOT_WITH_FLAGS (uint)
> > RESTORE_WITH_FLAGS (uint)
> >
> > with one of those flags being USE_PLATFORM_MODE? We may need more
> > flags in future...
>
> Sure, we can do that.
Okay, that works for me ;-).
> > ...or maybe have ioctl(fd, USE_PL
Hi!
> > If frozen is atomic_t, do we need memory barrier?
>
> I think so. For example on x86-64 atomic_read() is just a read.
I'm not sure, but for x86-64 barriers are nops, anyway, IIRC.
> > > @@ -128,6 +135,21 @@ static unsigned int try_to_freeze_tasks(
> > > } while_each_thread(g,
Hi,
On Sunday, 26 November 2006 22:31, Pavel Machek wrote:
> Hi!
>
> > > > SMP boxes (especially on i386 ones), please do so and tell me if there
> > > > are
> > > > any problems.
> > > >
> > > > The last patch is untested.
> > >
> > > I guess I should fix s2ram enough that it works for you...
Hi,
On Sunday, 26 November 2006 20:51, Pavel Machek wrote:
> Hi!
>
> > Since pm_ops->finish() has to be called after enable_nonboot_cpus() and
> > before
> > device_resume(), from the userland interface perspective it should be
> > treated
> > as a part of the atomic suspend and resume operatio
Hi,
On Sunday, 26 November 2006 20:48, Pavel Machek wrote:
> Hi!
>
> > Index: linux-2.6.19-rc6-mm1/kernel/power/process.c
> > ===
> > --- linux-2.6.19-rc6-mm1.orig/kernel/power/process.c2006-11-25
> > 21:26:52.0 +010
I had the same problem with my hp compaq nx7400 notebook. Same errors!
With my old acer 2012wlmi I had no problems with hdd password, perhaps
the bios doesn't lock the disk on suspend to ram...
-
Take Surveys. Earn Cash. Influ
I have solved the keyboard problem compiling as module i8042, and
unloading it before suspend to ram.
In addition I have found that without unloading the i8042 (or using it
as builtin), if the network card is not connected, the IRQ associated
to keyboard and touchpad (controlled by i8042) are lost.
Hi!
> > > SMP boxes (especially on i386 ones), please do so and tell me if there are
> > > any problems.
> > >
> > > The last patch is untested.
> >
> > I guess I should fix s2ram enough that it works for you... What is the
> > primary notebook you are using?
>
> HPC nx6325. Someone has report
Hi!
> Since pm_ops->finish() has to be called after enable_nonboot_cpus() and before
> device_resume(), from the userland interface perspective it should be treated
> as a part of the atomic suspend and resume operations. For this reason we
> need two additional ioctls to be called instead of ATO
Hi!
> Index: linux-2.6.19-rc6-mm1/kernel/power/process.c
> ===
> --- linux-2.6.19-rc6-mm1.orig/kernel/power/process.c 2006-11-25
> 21:26:52.0 +0100
> +++ linux-2.6.19-rc6-mm1/kernel/power/process.c 2006-11-26
> 14:17:
Hi!
> > Okay, I'll use atomic_t.
>
> Patch with atomic_t follows.
>
> The atomic_set(..., 0) are used to avoid the (theoretical) situation in which
> freezing might be decreased twice in a row and I've decided to explicitly
> initialize freezing in fork.c for clarity.
Looks okay to me, but I'm
Hi,
On Sunday, 26 November 2006 12:15, Rafael J. Wysocki wrote:
> On Sunday, 26 November 2006 11:02, Rafael J. Wysocki wrote:
> > On Sunday, 26 November 2006 08:47, Pavel Machek wrote:
<--snip-->
> > Okay, I'll use atomic_t.
>
> Patch with atomic_t follows.
>
> The atomic_set(..., 0) are used t
Hi,
On Sunday, 26 November 2006 11:02, Rafael J. Wysocki wrote:
> On Sunday, 26 November 2006 08:47, Pavel Machek wrote:
> > Hi!
> >
> > > Currently, the PF_FREEZE process flag is used to indicate that the process
> > > should enter the refrigerator as soon as possible. Unfortunately it is
> >
Hi,
On Sunday, 26 November 2006 08:44, Pavel Machek wrote:
> Hi!
>
> > The discussion in a recent thread on Linux-PM has indicated that it's
> > necessary to call pm_ops->finish() before devce_resume(),
> > but enable_nonboot_cpus() has to be called before pm_ops->finish()
> > (cf. http://lists.o
Hi,
On Sunday, 26 November 2006 08:47, Pavel Machek wrote:
> Hi!
>
> > Currently, the PF_FREEZE process flag is used to indicate that the process
> > should enter the refrigerator as soon as possible. Unfortunately it is set
> > by
> > the freezer while the process may be changing its flags for
21 matches
Mail list logo
