Bug 186442 - xorg-x11-server-Xorg-1.0.99-1 breaks vesa driver
xorg-x11-server-Xorg-1.0.99-1 breaks vesa driver
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-23 11:44 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-07 09:55:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Working VESA logs, with older Xorg release (61.33 KB, text/plain)
2006-05-27 05:09 EDT, Alexandre Oliva
no flags Details
Broken VESA logs, with latest Xorg release (61.48 KB, text/plain)
2006-05-27 05:11 EDT, Alexandre Oliva
no flags Details

  None (edit)
Description Alexandre Oliva 2006-03-23 11:44:54 EST
Description of problem:
Ater upgrading to yesterday's rawhide and rebooting, X wouldn't set up the local
display (ATI Radeon 9200SE, running with vesa driver because of bug 181736),
even though connecting through VNC it was perfectly functional.  The problem is
that the local display is pure noise, so the display is unusable.  Reverting to
xorg-x11-server-Xorg-1.0.1-9 fixed the problem.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.0.99-1

How reproducible:
Every time

Steps to Reproduce:
1.Upgrade to xorg-x11-server-Xorg-1.0.99-1
2.Restart X using the vesa driver

Actual results:
Noise on the local display; X otherwise functional over vnc

Expected results:
X functional for local and remote

Additional info:
Using the radeon driver the local display is good.  I haven't tested connecting
over vnc to see whether the other bug was fixed.
Comment 1 Alexandre Oliva 2006-03-23 11:52:47 EST
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.
Comment 2 Mike A. Harris 2006-03-24 18:28:08 EST
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 ...
Comment 3 Adam Jackson 2006-03-24 19:16:59 EST
NEEDINFO_ENG is hate
Comment 4 Alexandre Oliva 2006-04-10 20:57:14 EDT
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...)
Comment 5 Alexandre Oliva 2006-05-14 14:59:03 EDT
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
Comment 6 Adam Jackson 2006-05-15 10:21:08 EDT
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?
Comment 7 Alexandre Oliva 2006-05-15 11:25:45 EDT
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.
Comment 8 Adam Jackson 2006-05-15 14:31:51 EDT
can you attach X logs from both the working and non-working configurations?
Comment 9 Kevin E. Martin 2006-05-18 17:17:56 EDT
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.
Comment 10 Alexandre Oliva 2006-05-27 05:06:24 EDT
Not fixed in 1.1.0-1 :-(

I'll attach the logs momentarily.
Comment 11 Alexandre Oliva 2006-05-27 05:09:19 EDT
Created attachment 130062 [details]
Working VESA logs, with older Xorg release
Comment 12 Alexandre Oliva 2006-05-27 05:11:37 EDT
Created attachment 130063 [details]
Broken VESA logs, with latest Xorg release
Comment 13 Alexandre Oliva 2006-06-02 05:31:35 EDT
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?
Comment 14 Mike A. Harris 2006-06-07 03:35:30 EDT
(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
Comment 15 Alexandre Oliva 2006-06-07 09:55:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.