[lkml]   [2005]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: swsusp console change/userspace hang
On Mon, 2005-08-29 at 01:26 +0100, Matthew Garrett wrote:
> Hi!
> I'm currently working on an entirely userspace bootsplash program. It
> works quite happily, except in the case of resuming from hibernation.
> The splash program is launched at the start of initramfs, and at the
> end of initramfs (after the disk modules have been loaded) we attempt to
> trigger resume from userspace.
> The code registers a signal that's fired on VT change. If a console
> change is requested when it's currently drawing, it disables drawing and
> schedules an alarm to fire 0.1 seconds later in order to avoid switching
> the console when part-way through a framebuffer operation.
> The problem seems to be that swsusp tries to change the console and then
> immediately freezes userspace. For reasons I don't entirely understand,
> this freezes the machine. If I remove the pm_prepare_console call from
> pm_prepare_processes, resume functions correctly.

Hrm.. it uses pm_prepare_console(), which should wait for the console to
become active... However, it calls vt_waitactive without dealing with
-EINTR. You might be getting a signal or something, can you check what's
going on inside pm_prepare_console ?

> For now I'll probably just work around this by removing the console
> change from our kernels (we can do that in userspace scripting instead),
> but this still seems to be a less than ideal situation - I'm guessing
> that the same would happen if we were displaying the splash on suspend.
> Any ideas what might be causing this, and how to rectify it?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-29 02:56    [W:0.026 / U:11.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site