Am 25.01.2011 16:06, schrieb Chris Wilson:
> We were not pausing after detecting the response was pending and so did
> not allow the hardware sufficient time to complete before aborting. This
> lead to transient failures whilst probing SDVO devices.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>
> Knut, this should fix one of the failures in the log:
>
> [  680.371855] [drm:intel_sdvo_debug_write], SDVOC: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS)
> [  680.417190] [drm:intel_sdvo_write_cmd], command returns response Pending [4]
>
> which caused the detect routine to return connector_status_unknown.
>
> However, there is still immediately following that:
>
> [  680.419880] [drm:intel_sdvo_debug_write], SDVOC: W: 11 00 00 (SDVO_CMD_SET_TARGET_OUTPUT)
> [  680.450190] [drm:intel_sdvo_write_cmd], command returns response Invalid arg 
> [3]
>
> which implies that we are mishandling that odd VGA-2 connector.
> -Chris
>
>   

Well, you are great, better than you thought yourself ;-)

The floating VGA-2 status is rock solid now, both problems solved.

The machine idles at 800Mhz, load increases speed to 1860 MHz. The code had
actually less time to execute under load, time became to short without
the delay ...

I think that patch also should be a candidate for 2.6.37.1 as it fixes a
regression
introduced in 2.6.37.

Something new:

Have a look at the attached new log.  I connected a 2nd monitor, so
there is a monitor attached to both
the VGA-1 and DVI-1 connectors. At the framebuffer console prompt (no X
running)
I changed to console 2 and back to console 1. The log starts at the
point of switching
back to console 1. Now ... shouldn't I read something about a
output_poll_execute for VGA-1?

Knut