lkml.org 
[lkml]   [2005]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
    From
    Date
    Hi.

    On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote:
    > Can we use call_usermodehelper at this early resume stage (before any
    > video access)? Calling vm86 directly is probably not going to fly
    > because we want to be shielded from any misbehaviour in the bios code
    > and it may be necessary to kill the process running the bios code.
    >
    > Cases in point: My bios will cause the POSTing application to segfault.
    > Others have reported the POSTing application just hangs, but the
    > important things are done before the hang, so killing it after maybe
    > 5 seconds would be ok.

    Yuckkkkk!

    > Rough outline how to do that without adding tons of code:
    > We need a call_usermodehelper_from_ram_with_timeout for that.
    >
    > Kernel: Userspace:
    > User wants to enter S3
    > init_mutex_locked(s3_sem)
    > call_usermodehelper("vesaposter")
    > vesaposter calls LRMI_init
    > vesaposter mlocks all its memory
    > vesaposter calls into kernel
    > and down(s3_sem)
    > suspend vesafb
    >
    > User has triggered resume
    > run wakeup.S
    > thaw essential threads
    > set a timer of 5 seconds
    > up(s3_sem)
    > thaw and schedule vesaposter
    > wait for timer or vesaposter termination
    > vesaposter returns from kernel
    > vesaposter posts video card
    > vesaposter terminates
    > resume vesafb
    > continue resume
    >
    > Problems with that approach:
    > - vesaposter has to be locked in memory to avoid disk accesses

    That's no biggie.

    > - vesafb has to refrain from touching video until after POST

    Which is why I think we should do the post asap (as you have). What is
    counted as an essential thread?

    > - the vesaposter thread has to be the first unfrozen and
    > scheduled and completed thread. Only after that we can resume
    > vesafb and other threads

    All other threads will be frozen, and we don't have scheduler hooks that
    will hang up our new kiddie, so we should be right there.

    > - the locking will be tricky

    But also simplified by the fact that everything else is frozen.

    > Advantages:
    > - the problems all seem to be solvable easily
    > - security and stability are similar to the current userspace code
    > - we can use vesafb on such machines
    > - the kernel code won't be much more than two dozen lines
    > - the userspace POSTing code can be upgraded without the need
    > for kernel updates (no policy in the kernel)
    >
    > What do you think?

    Show us some code :>

    Nigel
    --
    Nigel Cunningham
    Software Engineer, Canberra, Australia
    http://www.cyclades.com

    Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:3.847 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site