Created attachment 61045 [details]
Xorg.log

Renaming libddc.so away worked around the problem.

Does it work without KVM? Please also attach xorg.conf and new logfile without KVM. Thanks.

DDC has worked fine for tens of SUSE installs with this particular KVM (and probably thousands of  X server starts). This means the KVM is not the problem
here.

Nevertheless xorg.conf is still missing.

Created attachment 61320 [details]
xorg.conf

Are you sure the config file matches the logfile?

(II) RADEON(0): Total of 1 CRTC2 modes found for MergedFB------------ 
(II) RADEON(0): Modes for CRT1: ********************
(--) RADEON(0): Virtual size is 1280x1024 (pitch 1280)
(**) RADEON(0): *Default mode "1280x1024": 108.0 MHz, 64.0 kHz, 60.0 Hz
(II) RADEON(0): Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync
(II) RADEON(0): Modes for CRT2: ********************
(--) RADEON(0): Virtual size is 640x480 (pitch 640)
(**) RADEON(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz
(II) RADEON(0): Modeline "640x480"   25.20  640 656 752 800  480 490 492 525 -hsync -vsync

MergedFB should not be the default for the radeon driver. MergedFB seems to mix the primary/secondary vga output. Therefore you get a "640x480" resolution.

I think so, but here's another log to be sure.

Created attachment 61321 [details]
new xorg.log

As additional information the analog VGA KVM is connected using a DVI->VGA adapter.

 

Created attachment 61322 [details]
another x log

The previous log was with disabled libddc - here's one
with it enabled.

Thanks. The last logfile (comment #11) seems to match the config file now whereas the first logfile (comment #1) seem to match a MergedFB configuration.
I can't find any problems in the last logfile. Your monitor is not detected, but the configuration of the config file are used.

(--) RADEON(0): Virtual size is 1280x1024 (pitch 1280)
(**) RADEON(0): *Default mode "1280x1024": 108.0 MHz, 64.0 kHz, 60.0 Hz
(II) RADEON(0): Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync

Probably it did work before by accident. KVMs have always been problematic
and we finally gave up trying to support them. :-( Try

  Option "NoDDC" "on"

as workaround and give me feedback.

Yes it strangely works now.

Ok I will reopen if I can reproduce it later again.

I updated the machine to 10.1beta1 and the problem reappeared. Didn't
get anything more than 640x480 until I added Option "NoDDC"

Created attachment 64379 [details]
Log showing DDC problem

Created attachment 64380 [details]
xorg.conf

Again. Does this also happen without any KVM in use?

DDC works with all other machines on the KVM and even did on the same
machine with 10.0. So I don't believe your assertation that the KVM 
is broken.

This doesn't answer my question!

I double checked and the machine was actually using a direct DVI connection
to the monitor.

Ok. We currently see so many regressions in the radeon driver. Hopefully 
using ' Option "NoDDC" ' will fix this problem and you can live with it.

Looking closer at the xorg.conf I realized that SaX2 didn't generate any modelines. Looks like a SaX2 bug therefore.

if you don't mind call:

 sax2 -r

and send me the log file

 /var/log/SaX.log

PS:
a login would be of great help as well :-)

Thanks

Created attachment 64466 [details]
sax2 -r log

Until I hit cancel.

Login is not possible, sorry.

What is the problem ?

Section "Monitor"
	  DisplaySize  330 270
	  HorizSync    30-83
	  Identifier   "Monitor[0]"
	  ModelName    "L72D D-SUB"
	  Option       "DPMS"
	  VendorName   "HIQ"
	  VertRefresh  43-75
	  UseModes     "Modes[0]"
	EndSection
	
	
	Section "Modes"
	  Identifier   "Modes[0]"
	  Modeline 	"1280x1024" 134.72 1280 1368 1504 1728 1024 1025 1028 1068
	  Modeline 	"1024x768" 79.52 1024 1080 1192 1360 768 769 772 801
	  Modeline 	"800x600" 47.53 800 840 920 1040 600 601 604 626
	EndSection

Everything there even DisplaySize :-)

The result doesn't give more than 640x480 resolution because it tries to compare the modeline to broken DDC data and rejects it. Definitely not a "worksforme"

ok, agreed but definitely not a sax bug because the monitor sections is
correct and the modelines are valid but the radeon driver is a mess

> Section "Modes"
>    Identifier   "Modes[0]"
>     Modeline      "1280x1024" 134.72 1280 1368 1504 1728 1024 1025 1028 1068
>     Modeline      "1024x768" 79.52 1024 1080 1192 1360 768 769 772 801
>     Modeline      "800x600" 47.53 800 840 920 1040 600 601 604 626
> EndSection

This is different from the Modes section Andi gave me above, which was empty.

> Hopefully using ' Option "NoDDC" ' will fix this problem and you can live
> with it.

Does it help?

Yes, i've been using that from the beginning (see comment #14)

The 6.9 log has a working DDC output but something else is strange:
(WW) (640x400,Monitor[0]) mode clock 31.5MHz exceeds DDC maximum 0MHz
This should fix it (the print_edid.c code had it right):
--- programs/Xserver/hw/xfree86/common/xf86Mode.c       13 Sep 2005 10:31:25 -0000      1.1.1.30
+++ programs/Xserver/hw/xfree86/common/xf86Mode.c       30 Jan 2006 11:18:42 -0000
@@ -765,7 +765,7 @@
        }
        if (mon_range) {
            /* mode->Clock in kHz, DDC in MHz */
-           if (mon_range->max_clock < 2550 &&
+           if (mon_range->max_clock != 0 && mon_range->max_clock < 2550 &&
                 mode->Clock / 1000.0 > mon_range->max_clock) {
                xf86Msg(X_WARNING,
                   "(%s,%s) mode clock %gMHz exceeds DDC maximum %dMHz\n",

Thanks. I'll apply the patch. But this will only remove the wrong warning.

Grrr. Yes. But then the log won't contain so much confusing crap.
Andi: I assume you only have one monitor attached but the card allows you to attach two. Because the thing is in merged mode it sets a mode that both displays can handle. Since the second one is not detected - how can it if noone is there? -
it is assumed that it can only handle the 'industry standard VGA mode'.
The monitor in:
(II) RADEON(0): Secondary:
 Monitor   -- CRT
is wrong.
However I don't understand why it is set correctly when DDC isn't initialized as we should use exactly the same code path. 
I assume it is RADEONCrtIsPhysicallyConnected() that sets the monitor type to CRT. However this function should be called also in the case where DDC isn't initialized.
With DDC not running the second arg of RADEONCrtIsPhysicallyConnected() - isCrtDac - is false for the secondary monitor. Therefore it doesn't probe for the physical presence of one. I assume that DACType - which determines the value of isCrtDac - is set to DAC_PRIMARY when DDC is running because ConnectorType of the primary port has been identified to be DVI-I (in which case it is assumed that the CRT is set to the seconarday port).
ConnectorType is initialized to VGA (CRT) for the primary port and DVI-I for the secondary port by the BIOS. I cannot find who is switching this connector type after it has been initialized by the BIOS.
This code is too horrible to debug by reading. Andi, can I access your machine?

Yes it has only one monitor. It uses a DVI connector but with one of these DVI-to-analog-VGA adapters leading to a KVM (which supports DDC fine for other systems and it even worked ok with 10.0)

Accessing it would be difficult sorry. It sits in my home network which
is not really reachable from the internet or the susenet.

Andi, I've tried to reproduce the problem here on my radeon cards. non of them exhibits this behavior. 
Appearantly what happens is that since DDC probing doesn't produce any results for the secondary head (how could it when nothing is connected?) the driver tries to probe if a display is hooked up physically (thru testing some pullup resistors).
Appearantly this code detects a connected display even though non is there.

The strange thing is: with noDDC this detection should be called all the time - but there it works. 
This is hardware behavior and I can only test it with the hardware available.

Assigning to Egbert ...

I've tested this on Andi's machine. The strange thing was that it works under certain conditions. 
If I remember correctly setting up these conditions invovled running the older version of the driver. Getting back to a non-working state involves a reboot.
Anyway it appears to be some hw/BIOS related issue.
I don't know how I should proceed on this because I would need access to this again and there are more pressing issues to be addressed at the moment.
This problem should be filed under 'the radeon driver is broken. period.'
We are likely to see more problems of the same quality.

I suggest to close this one as LATER and reopen to test again when we have a new radeon driver in STABLE.

Andi, I will work on this - however at the moment there seem to be more pressing problems. Do you mind if I change the severity?

Is this only happening for Andi or do we have any other such reports?
If so I would raise the severity, because from the user point of view
it is a regression (feeling as a step back) for the user. We should
then at least put it in the release notes.
I have updated the severity to normal.

Ralf, radeon driver regressions (in general) are already a part of the release notes of SUSE 10.1. :-)

Hmm, it might actually be fixed in RC2. I did an update and removed the NoDDC
and I still get the correct resolution. So from my side fixed for now.