Bug 191636 - vesa no longer works on Radeon x700
vesa no longer works on Radeon x700
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
7
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-14 05:59 EDT by Stas Sergeev
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2007-07-11updates
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-11 12:54:52 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)
a config (2.87 KB, text/plain)
2006-05-14 05:59 EDT, Stas Sergeev
no flags Details
the log (96.07 KB, text/plain)
2006-05-14 06:00 EDT, Stas Sergeev
no flags Details
new log (97.24 KB, text/plain)
2007-05-26 15:34 EDT, Stas Sergeev
no flags Details

  None (edit)
Description Stas Sergeev 2006-05-14 05:59:56 EDT
Description of problem:
The VESA driver that used to work on FC4 and previous versions,
now no longer works. An attempt to use it gets a "no signal" on
the monitor. The machine is still alive though - I can ssh to it.
However, any attempt to kill an X server (Ctrl-Alt-BkSp or via
the remote connection) locks up the PC entirely.

Version-Release number of selected component (if applicable):
xorg-x11-drv-vesa-1.0.1.3-1.2

How reproducible:
Use the config that is attached and "startx".

Steps to Reproduce:
1. Install the PCIe Radeon x700 of ASUS
2. Connect it to an LCD monitor with the DVI cable
3. Select the VESA driver in xorg.conf
4. Try to run an X server

Actual results:
"no signal" message on monitor. Any attempt to kill an X server
or a reboot cleanly, just causes a hard deadlock.

Expected results:
X server running with the monitor displaying the more appealing
pictures than just the "no signal" message. An attempt to shut
down an X server doesn't crash the machine.

Additional info:
Below is the lspci -v snip. I'll also attach the log and the
config. Unfortunately, it doesn't look like the log contains
any error information.
---
05:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700
(PCIE)] (prog-if 00 [VGA])
        Subsystem: ASUSTeK Computer Inc. Unknown device 010e
        Flags: bus master, fast devsel, latency 0, IRQ 3
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at fd7f0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at 6c00 [size=256]
        [virtual] Expansion ROM at fd700000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Express Endpoint IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
        Capabilities: [100] Advanced Error Reporting

05:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 (PCIE)]
(Secondary)
        Subsystem: ASUSTeK Computer Inc. Unknown device 010f
        Flags: fast devsel
        Memory at fd7e0000 (64-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Express Endpoint IRQ 0
---
Comment 1 Stas Sergeev 2006-05-14 05:59:56 EDT
Created attachment 128999 [details]
a config
Comment 2 Stas Sergeev 2006-05-14 06:00:41 EDT
Created attachment 129000 [details]
the log
Comment 3 Mike A. Harris 2006-05-23 10:22:38 EDT
Why are you not using the "radeon" driver for this hardware?

Comment 4 Stas Sergeev 2006-05-23 12:35:47 EDT
> Why are you not using the "radeon" driver for this hardware?
Why not - I do. I wasn't able to get DRI working (guess it
is not implemented for that card yet - or should I try harder?),
but other than that, the "radeon" driver works. (except that I
had to disable MergedFB, or it would work only in 640x480 for
some unknown to me reasons)
Would be nice to have VESA working too though. :)
Comment 5 Mike A. Harris 2006-05-25 13:06:55 EDT
(In reply to comment #4)
> > Why are you not using the "radeon" driver for this hardware?
> Why not - I do. I wasn't able to get DRI working (guess it
> is not implemented for that card yet - or should I try harder?),

DRI support for R300 and newer (Radeon 9500 and newer) is experimental only
upstream, and not included with Fedora Core 5.  Of course you wont get DRI
with the vesa driver either - on any hardware.  ;o)

> but other than that, the "radeon" driver works. (except that I
> had to disable MergedFB, or it would work only in 640x480 for
> some unknown to me reasons)

Please report that issue to X.Org by filing a bug report against the
radeon driver at http://bugs.freedesktop.org in the "xorg" component.

> Would be nice to have VESA working too though. :)

Your X server log shows an X server that has started up ok.  There is no
fatal error or backtrace present in the log.  Is this the log from the
problematic invocation, or did you start the X server up again after
it crashed, but before you attached the log?  (Starting the X server after
a crash will overwrite the log from the crash)

Please install the debuginfo packages for the X server, and video driver
and attach a backtrace to the report if the server is crashing.


Ajax: Do you have access to a Radeon X700?
Comment 6 Stas Sergeev 2006-05-25 13:48:46 EDT
> DRI support for R300 and newer (Radeon 9500 and newer) is experimental
> only upstream, and not included with Fedora Core 5.
Thanks for explanation.

>> had to disable MergedFB, or it would work only in 640x480 for
>> some unknown to me reasons)
> Please report that issue to X.Org by filing a bug report against the
> radeon driver at http://bugs.freedesktop.org in the "xorg" component.
But I am not entirely sure if it is a bug or just my inability to
configure the MergedFB properly. But what I do know is that getting
something above 640x480 on FC5 was not possible without manually editing
xorg.conf to disable MergedFB.

> Your X server log shows an X server that has started up ok.
Yes, as I said in my initial report, the error is not in the log.

> Please install the debuginfo packages for the X server, and video driver
> and attach a backtrace to the report if the server is crashing.
But, as said in my initial report, the server doesn't crash initially -
it starts up fine and works, only the monitor displays "no signal". :)
And if I am trying to shut it down, then it locks up the machine
completely (even to the remote connections), so again the stack trace
is not possible.
I am not sure if I can provide any info at that point. The only hope
is for someone to reproduce that.
Comment 7 Stas Sergeev 2006-05-29 13:21:39 EDT
> Of course you wont get DRI
> with the vesa driver either - on any hardware.  ;o)
I actually finally recalled why I wanted VESA to work. :)
Yes, I won't get DRI, but previously I was able to still get mesa
to work. It was very slow but it worked. Now with the radeon driver
it doesn't work at all. The programs like tuxracer, glxgears etc -
they all simply crash with the
X Error of failed request: GLXBadContext
message. So I want VESA to get them working, albeit slow.
Or, am I missing something? Is it possible to get them working with
the radeon driver anyhow? If it is then indeed I don't need VESA at all.
Comment 8 Mike A. Harris 2006-05-30 14:01:46 EDT
(In reply to comment #6)
> >> had to disable MergedFB, or it would work only in 640x480 for
> >> some unknown to me reasons)
> > Please report that issue to X.Org by filing a bug report against the
> > radeon driver at http://bugs.freedesktop.org in the "xorg" component.
> But I am not entirely sure if it is a bug or just my inability to
> configure the MergedFB properly. But what I do know is that getting
> something above 640x480 on FC5 was not possible without manually editing
> xorg.conf to disable MergedFB.

The xorg@lists.freedesktop.org mailing list may be able to help you getting
MergedFB configured properly and/or determine if you've encountered a bug.
 
> > Please install the debuginfo packages for the X server, and video driver
> > and attach a backtrace to the report if the server is crashing.
> But, as said in my initial report, the server doesn't crash initially -
> it starts up fine and works, only the monitor displays "no signal". :)
> And if I am trying to shut it down, then it locks up the machine
> completely (even to the remote connections), so again the stack trace
> is not possible.
> I am not sure if I can provide any info at that point. The only hope
> is for someone to reproduce that.

Sounds like a radeon driver bug to me.  I don't have the right hardware to
attempt to reproduce this problem locally.  It is probably best to report
each of these problems directly to X.Org bugzilla (both the vesa one and
the radeon one), to increase the likelyhood someone has the correct
hardware and can reproduce the problem directly, as it is probably going
to need a direct reproducer to diagnose.  The GLXBadContext issue is a
Mesa problem, and there are lots of other bug reports filed for it already
IIRC.  I've pinged our Mesa maintainer to see what the status of the
GL/x86_64 issue is.



(In reply to comment #7)
> > Of course you wont get DRI
> > with the vesa driver either - on any hardware.  ;o)
> I actually finally recalled why I wanted VESA to work. :)
> Yes, I won't get DRI, but previously I was able to still get mesa
> to work. It was very slow but it worked. Now with the radeon driver
> it doesn't work at all. The programs like tuxracer, glxgears etc -
> they all simply crash with the
> X Error of failed request: GLXBadContext
> message. So I want VESA to get them working, albeit slow.
> Or, am I missing something? Is it possible to get them working with
> the radeon driver anyhow? If it is then indeed I don't need VESA at all.

I believe that is a bug in Mesa on x86_64.  To the best of my knowledge,
Mesa does not compile properly on x86_64 at all, and is totally broken in
Fedora Core 5 on x86_64.
Comment 9 Stas Sergeev 2006-05-30 14:37:38 EDT
> The xorg@lists.freedesktop.org mailing list may be able to help you getting
> MergedFB configured properly and/or determine if you've encountered a bug.
Today I've figured out that it is specific to the DVI output (does not
happen to the VGA output), so then it is definitely a bug and should be
reported. I'll do that within a few days.
For now, just beware that you can't even install the FC5 if you use the
RadeonX700 and the DVI output. I tried that on 2 machines already. The
installer wants 800x600 while you get 640x480, so you don't see the bottom
of the screen where all the buttons are, and you can't install. Very bad.
(the text-mode installer is the last resort)

> Sounds like a radeon driver bug to me.
Well, that was a VESA driver bug, not radeon. So I was hoping it would
be possible to reproduce, maybe you just need to use the DVI output on
"any" video card.
Anyway, I can fill that upstream. (unless the FC code is patched to the
level where the upstream will say "distro-specific bug, please report to
RedHat" :)

> Mesa does not compile properly on x86_64 at all, and is totally broken in
> Fedora Core 5 on x86_64.
OK, thanks for the info.
Comment 10 Stas Sergeev 2006-05-31 15:00:55 EDT
OK, it turned out the VESA bug is already filled:
https://bugs.freedesktop.org/show_bug.cgi?id=6865

As for the MergedFB problem - it looks like being an FC issue after all.
After reading this:
https://bugs.freedesktop.org/show_bug.cgi?id=2035
and adding the CRT2HSync/CRT2VRefresh options into xorg.conf, the problem
goes away. So it looks like a misconfiguration caused by the FC5 installer.
Note that this bug prevents an FC5's graphical installer from being usable
at all - you can't install in 640x480 as you don't see the buttons.
In fact I think MergedFB should never be enabled by default. I wonder
if it is only radeon has it enabled, or the other drivers too?
Comment 11 Mike A. Harris 2006-07-11 03:08:49 EDT
(In reply to comment #10)
> OK, it turned out the VESA bug is already filled:
> https://bugs.freedesktop.org/show_bug.cgi?id=6865
> 
> As for the MergedFB problem - it looks like being an FC issue after all.
> After reading this:
> https://bugs.freedesktop.org/show_bug.cgi?id=2035
> and adding the CRT2HSync/CRT2VRefresh options into xorg.conf, the problem
> goes away. So it looks like a misconfiguration caused by the FC5 installer.
> Note that this bug prevents an FC5's graphical installer from being usable
> at all - you can't install in 640x480 as you don't see the buttons.
> In fact I think MergedFB should never be enabled by default. I wonder
> if it is only radeon has it enabled, or the other drivers too?

It's not a bug in the installer.  If it is possible to be able to
detect which hardware chip and specific board make/model needs a
specific set of custom configuration options to work properly,
that would need to be detectable via software probing to isolate
the specific set of circumstances in which to enable specific
options.

In that case, the video driver itself should be doing this, not the
installer or configuration tools.  The video driver is the /only/
thing that knows the intricate detailed inner workings of each
video card.  The installer and configuration utilities do nothing
more than detect the PCI ID and assign the driver.  From that point
on, it is up to the driver to do the right thing.

So that is a video driver/X server issue.
Comment 12 Stas Sergeev 2006-07-11 05:04:14 EDT
> The installer and configuration utilities do nothing
> more than detect the PCI ID and assign the driver.
But they also create the default xorg.conf, which in my case
is not valid. But I agree they must not need a deep knowledge
of the hardware to create the right config.
As I said, IMHO, the right fix would be to simply make the
MergedFB disabled by default. My guess is that the other drivers
have it disabled, most likely they don't event implement one. So
why "radeon" has it enabled? That makes FC5 non-installable on both
the home and the work machines of mine, unless I use the VGA
connector instead of the DVI.
Comment 13 Mike A. Harris 2006-07-11 12:19:23 EDT
(In reply to comment #12)
> > The installer and configuration utilities do nothing
> > more than detect the PCI ID and assign the driver.
> But they also create the default xorg.conf, which in my case
> is not valid. But I agree they must not need a deep knowledge
> of the hardware to create the right config.
> As I said, IMHO, the right fix would be to simply make the
> MergedFB disabled by default.

The "default" is what the driver does.  If that is wrong, then the
driver's default needs to be changed.  

> My guess is that the other drivers have it disabled, most likely they
> don't event implement one.

It only makes sense on dualhead hardware that is actually capable of
doing it.  Currently it is implemented in the Radeon, Matrox and
SiS drivers.  There is no need to make any guesses however, the source
code doesn't lie.

The driver maintainers ultimately decide what the defaults are in the
drivers they maintain.  The problem is not wether or not MergedFb is
a default setting or not.  The problem is that some users (not all
users) experience a problem with the driver.  That problem needs to
be isolated and fixed.  I strongly recommend reporting this upstream
to X.Org at http://bugs.freedesktop.org in the "xorg" component, against
the 'radeon' driver, so that it has a stronger chance of being fixed
sooner rather than later though.


> So why "radeon" has it enabled?

That sounds like a fantastic question to post to the xorg@lists.freedesktop.org
mailing list, where the maintainers of the driver can provide you with
an answer which reflects the rationale behind why they made it the default.


> That makes FC5 non-installable on both the home and the work machines
> of mine, unless I use the VGA connector instead of the DVI.

It works as-is for some people, and not for other people.  Changing the
defaults to hide the problem for those people that it causes an issue for,
to end up possibly creating a new problem for those people who did not have
a problem before, is not a viable solution.  The only viable solution, is
for the actual problem to be reproduced and isolated, then fixed properly
in the driver source.

Until there is a proper solution to this issue, at least there is a
viable workaround which users can configure to get working video, which
is a big plus.

Comment 14 Stas Sergeev 2006-07-11 15:03:51 EDT
> The "default" is what the driver does.  If that is wrong, then the
> driver's default needs to be changed.
Yes, that's what I mean - disable it by default in the driver.

> The problem is that some users (not all
> users) experience a problem with the driver.
According to the URL I posted above, that may depend on the monitor DCC.
I have that on the 2 completely different monitors, one is by NEC, another
is Fujitsu.

> That problem needs to
> be isolated and fixed.  I strongly recommend reporting this upstream
> to X.Org at http://bugs.freedesktop.org in the "xorg" component, against
> the 'radeon' driver, so that it has a stronger chance of being fixed
> sooner rather than later though.
What's the use? It was opened there many times and closed as notabug.
See the URL I was posting before, as an example. Or here it is again:
https://bugs.freedesktop.org/show_bug.cgi?id=2035
Since the Xorg people do not seem to consider it a bug, maybe something
on the RH side can be done.

> Changing the
> defaults to hide the problem for those people that it causes an issue for,
> to end up possibly creating a new problem for those people who did not have
> a problem before, is not a viable solution.
But after reading the xorg bugs, I have the different view. Why is it
enabled by default is still unknown to me (do the Matrox and SiS have it
enabled too?), but the consequences are as expected and are based on the
fact that (as far as I understand) the DCC info is incomplete and so the
safest resolution is chosen.

> Until there is a proper solution to this issue, at least there is a
> viable workaround
But I think it is the proper solution to simply disable the MergedFB
by default. According the Xorg people it is not a bug, just a reaction
to an incomplete DCC info, and therefore nothing is going to be changed.
I wonder: is it really *ever* needed to have MergedFB during the install
process? Someone who needs it, can just enable it later. But not being
able to install, leaves you without any choices at all.

So, to summarize: you think it is a bug in the driver, but the Xorg people
seem to think it is not, and they close the reports. I don't think it is
a bug too, but I think the radeon driver simply have the unsafe defaults
that backfire for me on 2 different machines. Changing them to the safe
defaults look like the right solution to me, not a workaround at all.
I agree that it is better to be done by an Xorg people, but as they do
not seem to be willing - what's the deal doing it for FC first and then
submit to upstream?
Comment 15 Adam Jackson 2007-03-28 13:24:55 EDT
Does this work better with the vesa driver in FC6 or FC7?  There have been quite
a few fixes there.
Comment 16 Stas Sergeev 2007-03-28 14:05:16 EDT
> Does this work better with the vesa driver in FC6 or FC7?
With xorg-x11-drv-vesa-1.2.1-4 its still the same.
However, the bug with Radeon mentioned above, seem
to have been fixed.
Comment 17 Adam Jackson 2007-05-03 14:54:55 EDT
Try this one instead:

http://people.redhat.com/ajackson/xorg-x11-drv-vesa-1.3.0-5.fc6.x86_64.rpm
Comment 18 Stas Sergeev 2007-05-03 15:24:49 EDT
Same.
And I think the probability was rather
low anyway because both the libint10.so
and libvbe.so are not in that package.
Comment 19 Adam Jackson 2007-05-26 14:26:13 EDT
What's the log file look like with vesa 1.3.0-5 or newer?
Comment 20 Stas Sergeev 2007-05-26 15:34:48 EDT
Created attachment 155505 [details]
new log

> What's the log file look like with vesa 1.3.0-5 or newer?
It looks very good, without any indecations
of a problem.
Comment 21 Adam Jackson 2007-05-29 08:11:13 EDT
So, you're saying 1.3.0-5 does _not_ work?
Comment 22 Stas Sergeev 2007-05-29 12:59:29 EDT
> So, you're saying 1.3.0-5 does _not_ work?
Yes. Please see the original description of the problem:
there is no hang or crash or anything that can affect the
log. Instead, its just that the monitor says "no signal".
But the system is alive, I can hear the sound that gnome
plays, etc.
The machine only freezes if I try to either shutdown an
X server (Ctrl-Alt-Backspace), or switch to the console
(Ctrl-Alt-F1).
So the log won't help at all.

I was trying to build an Xorg from git, but the build
fails somewhere on an input drivers. And if I fix the
problem and try to continue the build, it instead starts
to compile from scratch (starting from autoreconf).
That's horrible.
Comment 23 Matěj Cepl 2007-07-03 09:51:06 EDT
Fedora Core 5 is no longer supported, please, could you reproduce this bug with
the updated version of the currently supported distribution (Fedora Core 6, or
Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please
let us know in this bug report.  If after a month's time we have not heard back
from you, we will have to close this bug as CANTFIX/INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 24 Stas Sergeev 2007-07-11 12:54:52 EDT
Wow, this appeared to have been fixed!
The bug _is_ present in F7, because I tried,
but some update fixed it recently. Or at least
I can't reproduce it any more, for some unknown
reason.

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