> > From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
> > Date: Tue, 23 Jun 1998 16:10:43 -0700 (PDT)
> > Subject: Re: Resume/Suspend (was Re: LVM / Filesystems / High availabil=
> > ity)
> >
> > On Wed, 24 Jun 1998, Magnus Redin wrote:
> >
> > >=20
> > > > Hey, there's a thought! That is a good idea.Almost mainframe like in
> > > > recovery... X is a no-go with this, though. You need to save the
> > > > complete state of a SVGA card. Thoughts?
>
> > > It should be enough to ask the X-server to redraw the screen.
>
> > Nope, that is not enough with most SVGA cards. Since many VGA
> > registers are write-only, X has to keep softcopies of those regs in order
> > to be kept aware of exactly what state the video hardware is in. If you
> > checkpoint the X server, run some other video card banging program like
> > SVGALib or Suid-KGI or even another X server, and then restart the old
> > X
> > server, its register softcopies may not any longer correspond to the
> > actual state of the hardware = problems.
>
> I frequently have X sitting in the background, accessing it a couple
> of times a day, and occasionally a SVGAlib program crashes badly,
> totally screwing up the VC's.
> However, when I switch back to X, it all sorts it'self out.
SVGALib and X cooperate somehow to avoid stepping on each other's
toes.
> So, either X is storing state in a write-only part of the card, and
> using some sort of "switch registers", to switch to alternate registers,
I don't know of any SVGA cards that support register switching.
AFAIK that is only seen on workstation graphics hardware.
> or
> it's keeping track of what state it thinks the card is in, and rewriting
> that when it restarts.
What do you mean restarts? X is always running in the background
in your scenario above.
> I don't see how checkpointing is any different to the X server than
> starting an SVGAlib app that eats all memory, causes the X server to get
> totally swapped out, and then crashes without restoring the state.
What difference does it make if the X server is swapped out or not?
>
> > There is also the issue of atomicity of accelerator commands - a
> > lot of cards don't take well to being interrupted whilst their accel
> > command FIFOs are half full of command words. Even if the next bit of
>
> Again, AFAIK, you can still run SVGAlib programs on accellerated X
> servers, without totally crashing it, so something must be there.
You mean SVGALib-in-a-window on an AccelX server? I wasn't aware
that this was possible, but even if it is the SVGALib program will not be
hitting the hardware itself. X is set up to maintain hardware state
across VT switches when it is still running, where accel commands won't be
fired by SVGALib or X unless their VC has the focus and hence control of
the video card. If you crash SVGALib as described above and then switch
to X, X may restore the registers to a known state and everything will be
fine, but there are timing-sensetive sets of register writes in both X and
SVGALib that are in critical sections which cannot be jumped out of. It
wouldn't be a big deal for the checkpointer to force a VT switch on the X
server to avoid this problem for either X or SVGALib, but it would be a
special case that would need to be taken into account.
> I can only assume from this that when X is asked to redraw the screen from
> cold, as in when switching to that VC, it rewrites all the write-only
> registers.
Yeah. It has a good known state saved because of the VT switch.
Which is why you would need to force a VT switch.
> This would seem to be supported by the fact that changing text mode settings
> (SVGAtextmode), switching to the X server, and back again leaves you with
> the original settings when the X server was started.
OK, so now SVGATextMode and X don't cooperate. Great |-<. Will
this be a checkpoint problem? SVGATextMode assumes the same textmode
resolution for all textmode VCs. One nice thing about EvStack's VC
substacks is that they can save arbitrary context for each VC separately.
Textmode resolution, font, palette, graphics mode, etc.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu