Messages in this thread | | | Subject | Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon)) | From | Nigel Cunningham <> | Date | Fri, 04 Feb 2005 13:51:55 +1100 |
| |
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/
| |