Bug 25052

Created attachment 40572 [details]
/var/log/messages with some graphics mode initilialization problems

Unfortunately I can not provide you with the /var/log/messages of the time when X crashed. I think there were some OOPSes. Why don`t you provide a /var/log/messages.old like there is an Xorg.0.log.old? Otherwise it will be practically impossible for me to always get the messages file after a hang or crash (Alt-PrnScr-S-U-B worked however).

Created attachment 40602 [details]
hwinfo --gfxcard

I recategorised this to video/dri-other.  That's probably not correct but it gets us a bit closer to here we should be ;)

Created attachment 42382 [details]
add edid strict option

The drm EDID checker is pretty strict about what EDIDs it will accept.  Try this patch and add drm.edid_strict=0 to your kernel command line.

Thanks a lot. That has resolved my issue (as far as I can see).
X can now boot into graphics mode and both monitors will stay alive.
However after using xrandr (by disabling the integrated monitor) my Xorg started to hang by an overflow of the event queue (see: https://bugs.freedesktop.org/show_bug.cgi?id=32393) which I would however presume having nothing to do with the kernel. 
  ((tested with 2.6.36-rc8 / 2.6.37.-7.99.2.2948ffa))

 Oops; it had only worked because the drm.edid_strict option made the still unchanged radeon module refuse to load. The external screen however is only blackened as soon as radeon is modprobed.
 If you apply the patch correctly and get the changed module shipped (which didn`t work in first place for whatever reason) the following happens if you specify drm.edid_strict on the kernel command line:
  integrated screen: whitened (fully white)
  external screen: black, no response

 At first it was still possible to switch back to vt01-03 and text modes were displayed correctly. Then suddenly everything was black and only a Ctrl-Alt-Delete could help me out.

  Somehow looks as if it was not beneficial to use the EDID data of that screen or do you see another possibility?

make sure you remove the vga= from your kernel command line.

 Without the vga= option the integrated screen becomes colorfully vertical lined and the mouse appears as pixel-soup-box. The external screen does however stay dark as well.

 The monitor works well if I can plug it in via its DVI-interface (instead of HDMI). Then it suddenly sends a correct EDID.
 
  Is there any way to force the usage of the EDID sent via DVI even if it is plugged in via HDMI?

Make sure your kernel has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9453d621186426500aa50049dfa0a8b15c86201d
then boot with radeon.audio=0 on the kernel command line in grub.

 Well; it has worked with kernel-2.6.38-rc2-0.0.7.4bf0e68 via DVI.
With kernel 2.6.38-0.0.12 it does not work any more.

Which kernel version should I use to test the patch?

(In reply to comment #11)
>  Well; it has worked with kernel-2.6.38-rc2-0.0.7.4bf0e68 via DVI.
> With kernel 2.6.38-0.0.12 it does not work any more.

Can you bisect between kernel-2.6.38-rc2-0.0.7.4bf0e68 and 2.6.38-0.0.12 and see what broke it?  I'm not sure what those versions refer to.

> 
> Which kernel version should I use to test the patch?

It was included in the kernel:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9453d621186426500aa50049dfa0a8b15c86201d

  Well; I possibly know now why it has worked with 0.0.7: 
The radeonhd driver wrote 'KMS is disabled.' under this particular kernel version - and it started up correctly: evidence enough that something does not work with KMS in this kernel version.- and UMS is known to work.
  I will try to re-test if it inspite possibly also worked with HDMI under the 0.0.7 version (though I had always been believing it was not - however I am no more absolutely sure now). However that will hardly be possible since the radeon driver or the dri xorg code now overflows the event loop as soon as i just try to boot into X (https://bugs.freedesktop.org/show_bug.cgi?id=32393).

p.s.: Will git auto-apply the patch that I can view under the given http address on the right kernel version if I invoke git with it in the right way?
One more thx. for the patch! (I will now test it after having been away for some time).

 Great! Your patch works for kernel 2.6.38-rc2-0.0.7.4bf0e68-desktop.
I can start an X-server over HDMI with radeon.audio=0 but not without.
However this may be of not too great use to us since this specific kernel version triggers a fallback to UMS as KMS is broken there (and bisecting it won`t make sense either since it is a bug not an antibug). Nonetheless taking the DVI-edid is a definite improvement. Tomorrow I will re-test with drm.edid_strict=0 on this particular kernel version and commence tests per VGA connector.
 There also still seems to be a bug in KMS itself not only in the EDID the monitor gives us (Your patches won`t do the job on kernels where it doesn`t work with DVI either; as far as I can see that, so that testing them there won`t be of use.).

 Unfortunately the tests of Comment #14 were not significant. I have tested the patches with the same kernel but a different Xorg namely xorg-x11-server-7.6_1.9.3-122.1 and xorg-x11-driver-video-7.6-180.1 which however now does resolve UMS for radeon so that everything does again work without any patch and kernel option.
 With a full KMS kernel like 2.6.38-0.0.12 on the other hand unfortunately video mode initializtion does at me currently not work at all under any configuration: neither with the integrated monitor nor with my external one over any of the ports DVI, HDMI or VGA. Here are the exact results:

VGA: itg: colored vertical lines; ext: c.v.l.(the same), mouse: pixelry
HDMI: itg & ext: colored lines; this time brighter with more white, mouse: same
DVI: itg: 1st: colored lines; 2nd: sparse colored lines ahead of white bg,
     ext 1&2: at first 'no signal'-dark then the same as for itg, mouse: same

 As the screen output for DVI has differed between two consecutive test runs I presume that there is no substantial difference in the result between different monitors and ports (always vertical colorful lines). The mouse did at first never appear until you moved it into the upper left screen area where there would normally appear an xterm by xinit. From then on the mouse pointer was represented by a rectangular pixel surrogate. Rebooting was the only escape though the system was still reactive (no crash or hang): changing the virtual terminal (chvt) or exiting X from an exit typed into xterm both resulted in a fully blackened screen with no more output.

 As Comment #15 shows there is currently something more fundamentally messed up with KMS (which is apparently not EDID-related). Actually the situation has rather deteriorated instead of improving: 
2.6.34-12.1 & -9.3: itg: works, ext: dark
2.6.36.1-1, Comment #1: non-deterministic, once it worked for both monitors
2.6.38-0.0.12: both monitors: vertical pixelry, nothing works
 (results completed by downstream report from openSuSE as linked by Comment #1.)
If it works for other cards KMS does probably have a problem with ATI or just ATI Mobility 2xxx cards (I am planning to make a request to the oS core test team in this regard and will tell you as soon as results should become available.).

 Concerning your patches I believe that they will be valuable for many users (although I could not verify them for me yet.). As I have found out flawed EDIDs are a known problem and thatways f.i. already addressed by the proprietary fglrx driver through letting the user select out of a prewritten list of artificial EDIDs for known monitor types. Nonetheless just using the EDID of another port of the same monitor or just suppressing the checksum test promises to be a more gracile way of resolving such an issue. That is basically why I want to make a commit request for these patches to be acquired in the final openSuSE 11.4 release within 15 days so that more people can test these options (mentioning them in the release notes with a demand to report the results for finally acquiring the patches into the mainline kernel.). 
  As far as now I would also issue the following additional feature requests for an in future comprehensively EDID relied graphics system:
(1) kernel option for using a user supplied EDID (instead of the hw. supplied ED.)
(2) option(s) for Xorg or the radeon kernel module to achieve the same: rebooting is painful and the typical user will have to test different things. If Xorg quits without success in modesetting (as so often by 2.6.36.1-1) or detects a wrong EDID checksum then it should point the user on the fgconsole to try them.
  by the way: Do you know whether the nouveau driver does already fully rely on KMS?

 Well; I have asked a bit around and found out that KMS does already
work with the Intel 945 and Nvidia 7700 Go graphics cards while there
have been problems with ATI Radeon HD 3450 (Bernhard M. Wiedemann,
i586), ATI Mobility Radeon HD 2700/2600 XT (me, x86_64) and the nVidia
GeForce 6150SE (Larry Finger, x86_64). All test were conducted under a
2.6.37.1-1.2.2 kernel.
 The actual result for the ATI cards was a 'garbeled screen
(pixelry/vertical colorful lines)' (bmwiedemann: this appeared so
quickly that even framebuffer might be affected) while for the nVidia
GeForce the 'lwfinger: main screen looked sheared horizontally as
though the number of pixels per line is wrong' (entire screen was
unreadable though in contrast to the ATI cards it was possible
perceive that something is there e.g. f.i. whether a console has been
launched or not.). For the nVidia Gforce the bootsplash screen was
additionally displayed much too narrow ('lwfinger: The left-hand side
is about in the middle of the screen and there is a 3-4 cm empty strip
at the right.').

 ( Unfortunately the original more elaborate message I wanted to post
here was lost due to a bugzilla crash:
http://ati.cchtml.com/show_bug.cgi?id=66. )

Created attachment 50072 [details]
lwfinger: hwinfo + monitor + Xorg.0.log

Created attachment 50082 [details]
bmwiedemann: hwinfo + monitor.txt

Nothing better for kernel 2.6.39-0.0.71.da138d8.x86_64.

Any work in progress on this issue? Many people have to fall back to the proprietary drivers if KMS is not avaiable or functional.

Does a newer kernel/ddx/mesa help?  KMS works fine for the vast majority of radeon users.

  I am going to leave in about two weeks and currently can`t test any further. However I have asked at opensuse-testing for someone else to do so in the meantime. - Elmar.

I retried last week with linux-3.0 and found nomodeset to be necessary to get not just to framebuffer console but into KDE4.7 without the system hanging
with a
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x06fd "Quadro NVS 295"
  SubVendor: pci 0x10de "nVidia Corporation"
  SubDevice: pci 0x062e 


and similar on my
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x0641 "GeForce 9400 GT"
  SubVendor: pci 0x1462 "Micro-Star International Co., Ltd."
  SubDevice: pci 0x133a 

could be a nouveau bug.

  Works great with kernel 3.1.0-1.2!

 - & the 3D experience with the new radeon driver is a real joy!

confirmed for kernel 3.4.6-1.1-desktop. Getting pixel soup on both displays with KMS (integrated and external): FS Amilo Xi 2550, ATI Mobility Radeon HD 2700, Scaleoview Q26W-1 (ext.mon.).

If it works with 3.1.0-1.2 can you bisect against something newer that doesn't work to identify what commit broke things for you?  Also please attach your xorg log and dmesg output with KMS enabled and a picture of the problem.

Please excuse the inconvenience. I forgot some old modelines in my xorg.conf. In deed everything is working perfectly with kernel 3.4.6-1.1-desktop (even the external monitor)!