Created attachment 19154 [details] [review]
Change the order of disables (patch for intel-2.4.1) 

Description of problem:

Using the "intel" driver with a i845G chipset, changing resolution with xrandr 
randomly cause the screen to turn blank .

How reproducible:

The issue occurs randomly, but switching modes continuously triggers the 
problem after a few iterations.

Steps to Reproduce:

1) Use the "intel" driver with a i845 chipset
2) set up a loop tochange resolutions
  $ while $(/bin/true); do 
        for i in 1024x768 800x600 640x480 1280x1024; do 
            xrandr -s ${i} 
            sleep 5
       done 
   done
3) Experience a blackscreen after a few minutes.

Actual results:

The display is black, no image is visible on the monitor.
Switching back to the console works, but no graphical mode is possible. 
Restarting X does not fix the issue, one has to reboot the system to restore 
the display of graphical mode.

Expected results:

The resolution changes and the display remains visible.

Additional info:

I do not have the PRM for the i830, but the Intel 965 Programmer's
Reference Manual, volume 3, is available from Intel website.

Obviously, it is not the same hardware, but reading the code of the
driver, the i830 and the i965 seem have quite a lot in common, so I'll do
a rough extrapolation and try to use that documentation.

In chapter 2.2.2 "Mode Switch Programming Sequence", page 32 of the PDF,
it says the disable sequence prior to do a mode switch should be (among
other things):

 - Disable planes (VGA or hires)
 - Disable pipe
 - Disable VGA display in 0x71400 bit 31

This is not what seems to be done in i830_display.c, i830_crtc_dpms():

 - Disable VGA display
 - Disable planes
 - Disable pipe

Since this functions is called before a mode switch with DPMSModeOff, I
guess the sequence should be as documented. Additionally, I'd add a call
to i830WaitForVblank() because the documentation says we should also wait
for the pipe to be turned off (we cannot really check the status of the
pipe as documented in the PRM because we don't turn it off when
QUIRK_PIPEA_FORCE is set, so we just wait for a vblank like do do
elsewhere in the code).

I made a patch for intel driver 2.4.1 and the customer has tested the patch 
succesfully on more than 50 machines for almost 3 weeks.

I talked to jbarnes on #intel-gfx who suggested to open this BZ to test the 
patch for regression.