On Sun, Nov 05, 2006 at 04:50:13PM -0500, Jason Lunz wrote:
On Sun, Nov 05, 2006 at 10:22:24PM +0100, Pavel Machek wrote:
Well, having some default scripts in suspend.sf.net package... would
not be that bad. Not all the stuff is done best in C.
hibernate supports swsusp, ususpend, and
On Sun, Nov 05, 2006 at 12:46:37PM +0100, Rafael J. Wysocki wrote:
As far as the interruptible freeing is concerned, is it _really_ that
important? Currently the shrinking of memory is common code and I don't think
the interruptibility is a good enough reason to make things more complicated
On Sun, Nov 05, 2006 at 12:40:37PM +0100, Pavel Machek wrote:
s2ram works perfectly both in console mode than in X with -f -s -p
options, but _only_ if framebuffer (vesa or radeonfb) is disabled in
kernel config.
NOTE: framebuffer _must_ be disabled in config: if it's only disabled
On Sun, Nov 05, 2006 at 11:41:50PM +0100, Rafael J. Wysocki wrote:
Hi,
On Sunday, 5 November 2006 23:17, Pavel Machek wrote:
Hi!
This patch adds some command line options to s2disk/s2both and resume so
that
they are a bit more script-friendly and sets up the infrastructure to
Hi.
On 11/6/06, Stefan Seyfried [EMAIL PROTECTED] wrote:
On Sat, Nov 04, 2006 at 01:00:30PM +0100, Fabio Comolli wrote:
...
BTW (from the rest of this thread): radeonfb ignoring vga=0 seems like
a bug worth reporting to me.
As Carl-Daniel explained it seems that radeonfb recognizes only the
On Mon, Nov 06, 2006 at 09:35:34AM +0100, Fabio Comolli wrote:
Hi.
On 11/6/06, Stefan Seyfried [EMAIL PROTECTED] wrote:
On Sat, Nov 04, 2006 at 01:00:30PM +0100, Fabio Comolli wrote:
...
BTW (from the rest of this thread): radeonfb ignoring vga=0 seems like
a bug worth reporting to me.
Hi!
Could memory freeing be separated into separate ioctl()? That would
allow us to do interruptible freeing (in small hunks), and allow
timing done from userland...
Well, I prefer the timing being done by the kernel, because it's easliy
grepable in the dmesg output and it can be done
On Mon 2006-11-06 09:42:50, Stefan Seyfried wrote:
On Mon, Nov 06, 2006 at 09:35:34AM +0100, Fabio Comolli wrote:
Hi.
On 11/6/06, Stefan Seyfried [EMAIL PROTECTED] wrote:
On Sat, Nov 04, 2006 at 01:00:30PM +0100, Fabio Comolli wrote:
...
BTW (from the rest of this thread): radeonfb
Hi!
But maybe we should do the release, first? This is likely to break
some strange combinations, I'd say...
It's designed not to break anything.
Currently we support only one command-line option, -f, which is still
supported with the patch and we can read the resume device file
Hi,
currently, i am using this diff in my package, it basically deals with not
yet existing $SUSPEND_DIR (e.g. in a chrooted build environment) by using
install -D on the first binary put there:
--- Makefile
+++ Makefile
@@ -124,26 +124,26 @@
$(CC) $(CFLAGS) -DHAVE_INTTYPES_H
On Monday, 6 November 2006 10:48, Pavel Machek wrote:
Hi!
But maybe we should do the release, first? This is likely to break
some strange combinations, I'd say...
It's designed not to break anything.
Currently we support only one command-line option, -f, which is still
Hi!
currently, i am using this diff in my package, it basically deals with not
yet existing $SUSPEND_DIR (e.g. in a chrooted build environment) by using
install -D on the first binary put there:
Ok, but:
- install --mode=755 $(S2DISK) $(DESTDIR)$(SUSPEND_DIR)
- if [ -f
On Mon, Nov 06, 2006 at 02:36:43PM +0100, Pavel Machek wrote:
Hi!
currently, i am using this diff in my package, it basically deals with not
yet existing $SUSPEND_DIR (e.g. in a chrooted build environment) by using
install -D on the first binary put there:
Ok, but:
- install
Hi,
i had a problem on one machine, where a missing platform_finish in the
atomic_snapshot() error-path leads to an endless-blinking suspend LED.
This was detected as a fallout of
https://bugzilla.novell.com/show_bug.cgi?id=218377
Funny thing is, that it does not help on that machine, the LED
Hi,
when investigating a suspend problem, i noticed that it is not paticlularly
useful to switch to the console where the kernel messages are redirected to:
After resume, you see nothing of the suspend messages, because everything
is pushed off the screen by the drivers chatting about suspend and
On Monday, 6 November 2006 08:14, Stefan Seyfried wrote:
On Sun, Nov 05, 2006 at 12:46:37PM +0100, Rafael J. Wysocki wrote:
As far as the interruptible freeing is concerned, is it _really_ that
important? Currently the shrinking of memory is common code and I don't
think
the
On Mon, Nov 06, 2006 at 08:08:59AM +0100, Stefan Seyfried wrote:
Well, the common upstream solution will soon be pm-utils, so maybe
the hibernate users should start looking at that, so that it does
what they want :-)
Why wouldn't the pm-utils authors start with hibernate as a base? It
looks
On Mon, Nov 06, 2006 at 12:08:23PM -0500, Jason Lunz wrote:
Why wouldn't the pm-utils authors start with hibernate as a base? It
Ask them :-)
looks nearly identical, only far less developed. hibernate's shell
plugin system is quite capable.
Maybe too capable. I don't know. I did not design
sure, here's an updated patch.
Jason
---
Add a pointer to hibernate scripts to the ususpend README.
---
README | 13 +
1 file changed, 13 insertions(+)
Index: suspend/README
===
--- suspend.orig/README
+++
On Monday, 6 November 2006 17:34, Stefan Seyfried wrote:
Hi,
when investigating a suspend problem, i noticed that it is not paticlularly
useful to switch to the console where the kernel messages are redirected to:
After resume, you see nothing of the suspend messages, because everything
is
On Monday, 6 November 2006 23:51, Matthew Garrett wrote:
On Thu, Nov 02, 2006 at 04:26:21PM +0100, Rafael J. Wysocki wrote:
OTOH some people reported that Ubuntu kernels successfully suspended (and
resumed) machines which the kernel.org kernels failed to suspend (or resume)
so it looks
21 matches
Mail list logo
