[BUG] intel KMS bug on i915

[BUG] intel KMS bug on i915

[Mathieu Taillefumier]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

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%.

Best regards

Mathieu



[-- Attachment #2: dmesg.gz --]
[-- Type: application/gzip, Size: 13717 bytes --]

Re: [BUG] intel KMS bug on i915

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

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)

-- 
Eric Anholt
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [BUG] intel KMS bug on i915

[Mathieu Taillefumier]

Hello,
> 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)
>    
Thanks for the reply.

I will try to bissect the problem (I have to start from the first rc1 
and go backward from that) but it might take some time since I am not an 
expert in git. What I can say is that the problem occur since the first 
rc of the kernel (and whatever recent version of libdrm). Moreover, I 
have this after a cold boot. Another person reported the same problem on 
the xorg list, so I am not alone :-).

regards

Mathieu

Re: [BUG] intel KMS bug on i915

[Mathieu Taillefumier]

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

Re: [BUG] intel KMS bug on i915

[Mathieu Taillefumier]

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)
>    
the result of the bisect section gave me this :

git bisect start 'drivers/gpu/'
# bad: [66b00a7c93ec782d118d2c03bd599cfd041e80a1] Merge branch 'fixes' 
of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq
git bisect bad 66b00a7c93ec782d118d2c03bd599cfd041e80a1
# good: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31
git bisect good 74fca6a42863ffacaf7ba6f1936a9f228950f657
# good: [e7d40b9a0a7c857383ef50db9766354bd3be1bf3] drm/radeon/kms: 
R600/RV770 remove dead code and print message for wrong BIOS
git bisect good e7d40b9a0a7c857383ef50db9766354bd3be1bf3
# bad: [c1176d6f03e1085797ce83648a2c76ae15a2b515] Merge branch 
'drm-next' of ../drm-next into drm-linus
git bisect bad c1176d6f03e1085797ce83648a2c76ae15a2b515
# good: [cd0b9fb400ba775737bdc3874c4cbee4047e66d8] drm/i915: Check that 
the relocation points to within the target
git bisect good cd0b9fb400ba775737bdc3874c4cbee4047e66d8
# bad: [94e0fb086fc5663c38bbc0fe86d698be8314f82f] Merge branch 
'drm-intel-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
git bisect bad 94e0fb086fc5663c38bbc0fe86d698be8314f82f
# good: [bb6baf76f45708dbba651ed76a7ad94462f30c0b] drm/i915: Track 
purged state.
git bisect good bb6baf76f45708dbba651ed76a7ad94462f30c0b
# bad: [a419aef8b858a2bdb98df60336063d28df4b272f] trivial: remove 
unnecessary semicolons
git bisect bad a419aef8b858a2bdb98df60336063d28df4b272f
# good: [6ac3bd527007eeecb148b67ca47b21731fd8a503] PCI/vgaarb: cleanup 
some warnings + cleanup some comments.
git bisect good 6ac3bd527007eeecb148b67ca47b21731fd8a503
# bad: [e454cea20bdcff10ee698d11b8882662a0153a47] Driver-Core: extend 
devnode callbacks to provide permissions
git bisect bad e454cea20bdcff10ee698d11b8882662a0153a47

with this for the very last one :

e454cea20bdcff10ee698d11b8882662a0153a47 is first bad commit
commit e454cea20bdcff10ee698d11b8882662a0153a47
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Fri Sep 18 23:01:12 2009 +0200

     Driver-Core: extend devnode callbacks to provide permissions

     This allows subsytems to provide devtmpfs with non-default permissions
     for the device node. Instead of the default mode of 0600, null, zero,
     random, urandom, full, tty, ptmx now have a mode of 0666, which allows
     non-privileged processes to access standard device nodes in case no
     other userspace process applies the expected permissions.

     This also fixes a wrong assignment in pktcdvd and a checkpatch.pl 
complain.

     Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

:040000 040000 a7c571fcd15ab134c2ce044e126d64aa94fabea3 
36c869e56350eb7ee74f4a0b46a0e3c2a454cc6c M      arch
:040000 040000 898c549d5a6f6be2534a01f2a5b22d8ed6aafd61 
79460f4129649fc404f7c3db73724b857b2ec548 M      block
:040000 040000 134d28af2f21517bf631c6b19a3775bb4ca294a3 
2411f973ce46c918379186c6c33364f33a5a079a M      drivers
:040000 040000 0ee311c5555b70843faa9a76651e353d811d9bc0 
35d7bfd19a5adec988386cac47d2d2ed2a72e5de M      include
:040000 040000 3a5e775fcc8b211a550cfa994a30a300236e0219 
9f0e3371fb2d5dcbdbf029db686ad212ef302dc9 M      sound

I should indicate that each time that the bisect is bad, I obtain either 
a black screen and I have to reboot with the magic keys or a graphical 
corruption. I can give more explicit details about which bad bisect 
gives a black screen or a graphics corruption but I have to start the 
session again.

regards

Mathieu