Created attachment 128999 [details]
a config

Created attachment 129000 [details]
the log

Why are you not using the "radeon" driver for this hardware?

> 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. :)

(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?

> 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.

> 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.

(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.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.

> The xorg.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.

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?

(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.

> 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.

(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.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.

> 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?

Does this work better with the vesa driver in FC6 or FC7?  There have been quite
a few fixes there.

> 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.

Try this one instead:

http://people.redhat.com/ajackson/xorg-x11-drv-vesa-1.3.0-5.fc6.x86_64.rpm

Same.
And I think the probability was rather
low anyway because both the libint10.so
and libvbe.so are not in that package.

What's the log file look like with vesa 1.3.0-5 or newer?

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.

So, you're saying 1.3.0-5 does _not_ work?

> 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.

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.

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.