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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Nov 2009 13:54:17 +0100
From:	Mathieu Taillefumier <mathieu.taillefumier@...e.fr>
To:	Eric Anholt <eric@...olt.net>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [BUG] intel KMS bug on i915

On 11/17/2009 05:54 AM, Eric Anholt wrote:
> On Wed, 2009-11-11 at 12:44 +0100, Mathieu Taillefumier wrote:
>    
>> Hello,
>>
>> I recently switched to the last git kernel (the rc6) and have a serious
>> problem with KMS and xorg. I reported it to the xorg list but after some
>> research it seems that this problem is caused by some recent change in
>> the intel KMS stack. Some warnings and errors are reported by the
>> kernel. they are the following (only a small part of it):
>>
>> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
>> render error detected, EIR: 0x00000000
>> i915: Waking up sleeping processes
>> [drm:i915_wait_request] *ERROR* i915_wait_request returns -5 (awaiting 2
>> at 1)
>> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
>> render error detected, EIR: 0x00000000
>>
>> This problem is recurrent with all 2.6.32-rc versions and gives rise to
>> an unusable xorg (independent of the version), while the same xorg stack
>> works pretty well with the 2.6.31 kernel. The hardware is a sony laptop
>> with a intel 965 chipset and the bug can be reproduced at 100%
>>      
> Could you bisect the problem?  I don't think I've seen reports of this
> (fails at a time other than resume)
>    
I finished my first bisect session but I obtain nothing that can be of 
any help so far. I think I just did a mistake somewhere in the process. 
I should point that I obtained some back screen during the process but 
no messages from the kernel nor xorg that I validated as wrong.

I am also wondering if the first drm commit that implement the dynamic 
clock setting is not responsible for it. Is there a way to deactivate it 
from the kernel command line or should i revert the commit to test that ?

best

Mathieu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ