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 l
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 like Ubuntu has fixed some suspend-related driver problems. I
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 susp
On Mon 2006-11-06 16:10:40, Stefan Seyfried wrote:
> 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
> > > inst
On Mon 2006-11-06 21:06:43, Rafael J. Wysocki wrote:
> On Monday, 6 November 2006 18:14, Jason Lunz wrote:
> >
> > sure, here's an updated patch.
> >
> > Jason
> >
> > ---
> >
> > Add a pointer to hibernate scripts to the ususpend README.
> >
> > ---
> > README | 13 +
> > 1 fil
On Monday, 6 November 2006 18:14, Jason Lunz wrote:
>
> 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
> ==
On Monday, 6 November 2006 16:55, Stefan Seyfried wrote:
> 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=21
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
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
+++ suspend/
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 desi
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 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
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
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 bli
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:
>
> > -
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 $(DESTDI
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, -
On Sun, Oct 29, 2006 at 01:39:30AM +1000, Jim wrote:
> Hi Stefan
>
> I've been using your program for disk and ram suspend and it works
> beautifully. I am so pleased. Thank you!
>
> s2ram -f works fine on my machine, but it is not in the whitelist, so
> you might want to add it:
Yes. Just one
On Mon, Oct 30, 2006 at 01:31:35PM +0200, sir_j wrote:
> hi, Stefan.
> Thanks for your answer.
If you keep the suspend-devel list cc-ed, you might even get faster answers
:-)
> Here is my another output
>
> --
>
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 -DHAVE_STDIN
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 res
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 thr
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 b
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
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
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 di
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 infra
On Sat, Nov 04, 2006 at 01:00:30PM +0100, Fabio Comolli wrote:
> Believe me or not, this is what happens.
I believe you, that's not the problem... :-)
> I use Fedora Core 6 and vga=0 is entered via grub, as usual.
... e.g. the suse graphical grub screen always appends options to
the configured o
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:21:37PM +0100, Pavel Machek wrote:
> Hi!
> > Bootsplash only drops to verbose mode on escape and F2 as far as I can
> > see. At least the kernel has something like this:
> >
> > ---
> > #ifdef CONFIG_BOOTSPLASH
> > /* This code has to be redone for some non-x86 plat
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, an
31 matches
Mail list logo