[ES1000] Graphical installer fails to start on an HP dl380g5

Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/304588

[Problem]
When starting up X, nothing is displayed to the screen in Intrepid (-ati 6.8.0, xserver 1.5.2); with Hardy (-ati 6.9.0; xserver 1.4.0.90) it had been working properly.

[Discussion]
Comparing the Xorg.0.log's from Hardy and Intrepid, there are some slight differences in how the modelines are generated, and also a message about "Indeterminate output size" but nothing screaming out "error".

This difference does look curious, but I'm not sure what it means:
 (II) RADEON(0): Port1:
  Monitor -- AUTO
  Connector -- VGA
- DAC Type -- Primary
+ DAC Type -- TVDAC/ExtDAC
  TMDS Type -- None
  DDC Type -- 0x6c

[lspci]
01:03.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02)
 Subsystem: Hewlett-Packard Company Device [103c:31fb]

[Original Report]
When attempting an install of Intrepid Ibex (8.10) using the amd64 desktop install CD on an HP dl380g5, the installer goes through the ping-pong stage, then the progress bar loads completely, then nothing is displayed. I've gone back and tried the Hardy Heron (8.04.1) amd64 desktop install CD and it works fine, so this is a regression.

I'll be attaching the Xorg.0.log files from both intrepid and hardy to this bug. Also, I can boot the Intrepid installer using the safe graphics mode and that works for an install.

Created an attachment (id=21787)
Xorg.0.log from hardy (boots successfully)

Created an attachment (id=21788)
Xorg.0.log from intrepid (fails boot)

Created an attachment (id=21790)
patch for hp

please try this patch. maybe you should apply it according to your local code base.

This is an xserver bug. In the case of the es1000 there is one crtc, however, two outputs are connected, and in theory both can be driven with the same crtc. However, in some cases no crtc gets assigned to one of the outputs even though both monitors have at least one common mode. Since there is no crtc, the driver call to enable to second output never happens. Anyway I think the proper fix is to figure out why the xserver fails to assign a crtc to the second output (in xf86PickCrtcs() and xf86InitialConfiguration() in xf86Crtc.c). Unfortunately, I can't seem to reproduce this at the moment on any xserver (I did last time I looked into this, but now it seems to work...).

In the log, you should see:
restore common
restore crtc1
restore pll1
finished PLL1
restore dac
restore dac
"restore dac" should appear twice, once for each dac.

It worked previously since the driver used to ignore the tvdac on es1000 cards. As such it was left on from the bios since the driver didn't touch it.

Created an attachment (id=21800)
possible patch

Actually something like this might work.

Adding myself to the CC list since I was the original reporter of this problem. I'm hoping to test the patches from Alex and cooper this week to see if they resolve this problem.

Thanks,
Bryan

(In reply to comment #5)
> Created an attachment (id=21800) [details]
> possible patch
>
> Actually something like this might work.

I tested this on the installed system and it fixes the problem. Thanks!

Bryan

We've uploaded this patch to Ubuntu for Jaunty. Hopefully this will be included in 6.12?

pushed b1fd883b59b85fed8782e035890098908902f4ce