On 03.12.2012, devendra.aaru wrote:
> Add more CC's
Thanks!
This is a real showstopper for me, it occurs in every session now.
Booting with "i915.i915_enable_rc6=0" doesn't help either..
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing
On 04.12.2012, Lekensteyn wrote:
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
> Date: Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable
Ok, b
On 04.12.2012, Daniel Vetter wrote:
> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.
A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a
On 05.12.2012, Lekensteyn wrote:
> > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
> > compositor. Now I'm trying to hit the bug again...
> Do you have a reliable reproduce method? As you can see in the linked bug it
> was caused by relatively low memory pressure combined wi
On 05.12.2012, Daniel Vetter wrote:
> Nope, we could only reproduce quickly with rc6 enabled :(
Could reproduce it today this way:
dd if=/dev/zero of=deleteme bs=1M count=5
while watching several HD videos on Youtube. Just tried once, so I'm
not shure if this will work all the way. Will tr
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
While writing a big file with dd and watching high resolution videos
on youtube, I've managed to reproduce the hang. Unfortunately, it
doesn't occur within seconds. Some playing around is neccessary, and
i
On 06.12.2012, Heinz Diehl wrote:
[]
Here are some more error-logs, inkl. dmesg after booting with drm
debug options turned on:
http://www.fritha.org/i915/gpu-hang.tar.bz2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On 06.12.2012, Heinz Diehl wrote:
[]
Ok, the last one for today. After extensive testing with heavy load
and I/O while watching HD videos, I can almost safely conclude with
the following:
1.) The hang does *never* occur with 3.6.9 vanilla
2.) The hang does *always* occur with 3.7-rc8
On 07.12.2012, Daniel Vetter wrote:
[]
I did a "git bisect" betweeb 3.6 and 3.7-rc8 and ended up with
this. Unfortunately, git can't revert this patch on top of master, sp
I have not been able to test if a revert will cure the problem.
After reading on the net that Peter (Lekensteyn) alread
On 08.12.2012, Chris Wilson wrote:
> One thing you can try is SNA, which packs its
> batches differently with the advantage that more auxiliary state is
> included in the error-state. It also packs all the kernels into a
> single buffer which will reduce the frequency at which it is paged
> out/i
On 11.12.2012, Chris Wilson wrote:
> Can you confirm one thing: are you able to reproduce the hangs at all on
> 3.7-rc8, using your original setup?
I can reproduce the hang with both 3.7-rc8 and 3.7 final inkl. latest
Linus-git. All with i915.i915_enable_rc6=0.
Heinz
__
On 11.12.2012, Daniel Vetter wrote:
> Can you please test the patch at
>
> https://bugs.freedesktop.org/attachment.cgi?id=70111
>
> That one should disable all effects of the unbound tracking, since a
> revert of the below commit conflicts.
I applied this patch to Linus' git from today. "Boom"
Hi,
since kernel 3.18 I'm no longer able to run X on my machine. While
3.17.6 is fine, 3.18 leaves me with a black screen when starting
X. Booting into runlevel 1/3 is fine.
I did a "git bisect", and the offending commit is this one:
[root@kiera linux-git]# git bisect bad
83f45fc360c8e16a3304748
On 15.12.2014, Daniel Vetter wrote:
> Can you please boot with drm.debug=0xf on both good and bad kernels and
> then grab dmesg from each?
The output is attached. The dmesg log stops after runlevel 3 for the
3.18 kernel, because I'm not able to do anything in runlevel 5 with a
black screen.
> T
On 14.12.2014, Emmanuel Benisty wrote:
> >>> The following commit permanently turns my screen off when x server is
> >>> started (i3 330M Ironlake):
> >>>
> >>> [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb
> >>> reference for the idr
> >>>
> >>> Reverting this commit fixed
16 matches
Mail list logo
