I forgot to mention that this was the .x86_64 version of it, but then I realized
I could easily test it on a .i686 notebook with an Nvidia GeForce2 Go card that
was working just fine with the nv driver, but that, after switching to vesa,
breaks in the very same way.  So the problem appears to be architecture- and
video-card-independent.

The vesa driver has not been updated for the CVS head X server which is in
rawhide currently.  Please use the FC5 server/driver for now until rawhide
stabilizes and has all of the drivers updated to work with the server that
is present.

Reassigning to adam for driver updates ...

NEEDINFO_ENG is hate

All drivers were updated in today's rawhide, but it just got worse.  The server
still has corrupted VESA, and now it crashes if I load the vnc driver.  I have
to downgrade vesa, keyboard and mouse in order to get X back to an operational
state, even if I were to comment out the VNC driver load (but then, if I weren't
to use VNC, I might as well switch to the radeon driver...)

VESA driver is still broken with today's X in rawhide.

xorg-x11-server-Xorg-1.0.99.903-1
xorg-x11-drv-vesa-1.1.0-1

I think I know what the VNC problem is; if you could file it as a separate bug
I'd appreciate it.

Regarding comment #4, which version of vesa works for you?

VNC problem is bug 191657, filed yesterday.  I was going to point it out here
but I forgot.

This is the combination that works for vesa:

xorg-x11-server-Xorg-1.0.1-9
xorg-x11-drv-vesa-1.0.1.3-1.2

I have to downgrade the server (and other drivers too, like keyboard, mouse and
synaptics) in order to avoid some binary incompatibility that causes crashes. 
Perhaps that's what the VNC thing is about too, since IIRC VNC used to contain X
sources and might need an update.

can you attach X logs from both the working and non-working configurations?

I've tracked this one down to recent miext/shadow changes.  I've just checked in
my fix upstream, and it should be included in the next driver spin.

Not fixed in 1.1.0-1 :-(

I'll attach the logs momentarily.

Created attachment 130062 [details]
Working VESA logs, with older Xorg release

Created attachment 130063 [details]
Broken VESA logs, with latest Xorg release

This problem appears to have been fixed in 1.2.0, but scrolling of a full-screen
1024x768 firefox are significant slower and my box became crashy after this
update.  The crashes don't seem to be fully repeatable, but they're quite
consistent; it's pretty difficult to avoid a total system freeze after logging
in, getting Firefox to visit a dozen web pages in separate tabs, and then just
going closing each one of them in a row.

Reverting to the old, working X packages gets me fast scrolling and stability
back.  This is on x86_64, if it makes any difference, and the card is an ATI
9200SE.  I haven't tried this on other boxes with different cards; please let me
know whether it would make any sense to do so.

Unfortunately the box becomes totally irresponsible when the problem shows up,
nothing is logged anywhere and I can't even ping it any more :-(

Should I file this as a separate report, or is there any chance it might still
be the same problem?

(In reply to comment #13)
> This problem appears to have been fixed in 1.2.0

So can we close this particular issue now as "RAWHIDE"?

>, but scrolling of a full-screen
> 1024x768 firefox are significant slower and my box became crashy after this
> update.

Sounds like a separate unrelated issue.

> The crashes don't seem to be fully repeatable, but they're quite
> consistent; it's pretty difficult to avoid a total system freeze after logging
> in, getting Firefox to visit a dozen web pages in separate tabs, and then just
> going closing each one of them in a row.

Best to file new individual bugs for each new problem encountered, so they
can be tracked individually.  Best to have new reports rather than cloned
bugs (to avoid a lot of unrelated data being in the bug reports).
 

> Should I file this as a separate report, or is there any chance it might still
> be the same problem?

Separate reports generally always work best.  It's easy to close each issue
out as they vanish, and leave the other ones open to continue tracking them
if they don't also vanish.  Also, it is easy to close a bug as a dupe if
later it is determined they are the same issue, or that they're different
issues both fixed by the same fix.  It is hard to manage 2 or more bugs
that "might" not be the same issue, within a single bug report however,
and if one issue does get fixed, do you then close the report, or leave it
open, and have a bug get more and more different issues added to it?  It
makes bug reports ugly and hard to follow over time as they get longer and
cover 2-5 different issues.

So, my vote is always for separate bug reports for each individual problem
occuring, even if it is related to another problem.  Cross referencing
related or possibly related bugs with URLs to each other and/or using the
bugzilla dependency features (blocks bug #, is blocked by bug #) is a
much better mechanism.

If the original issue here is fixed now though, I'd recommend we close
this one, and start fresh bug reports for remaining issues.

TIA

Cloning bugs is nice because it shows what the bug was taken out of, even though
even that big can be snipped out while cleaning up the submission like I often
do.  Sometimes it's appropriate to keep the dependency, sometimes it's not, but
it's easy enough to take it out when it's not, and generally good to do so after
creating the descendent bug, such that there are bidirectional links between the
possibly-related bugs.  So I've just done that to the other bug (now bugs). 
This one can be closed, indeed.