linux-kernel - Re: [PATCH] drm/i915/sdvo: If at first we don't succeed in reading the response, wait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Jan 2011 23:01:45 +0100
From:	Knut Petersen <Knut_Petersen@...nline.de>
To:	Chris Wilson <chris@...is-wilson.co.uk>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915/sdvo: If at first we don't succeed in reading
 the response, wait

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@...is-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

View attachment "2Chris" of type "text/plain" (2773 bytes)