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
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
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 at kiera linux-git]# git bisect bad
83f45fc360c8e16a3304
On 11.01.2013, Dave Airlie wrote:
> Just intel fixes, including getting the Ironlake systems back to the state
> they were in for 3.6.
> drm/i915: Revert shrinker changes from "Track unbound pages"
I guess it's this one which fixes the ILK hang. Would it be enough for
3.7 to just appy th
On 11.01.2013, Dave Airlie wrote:
> Just intel fixes, including getting the Ironlake systems back to the state
> they were in for 3.6.
> drm/i915: Revert shrinker changes from "Track unbound pages"
I guess it's this one which fixes the ILK hang. Would it be enough for
3.7 to just appy th
On 30.12.2012, Guennadi Liakhovetski wrote:
> Did that and it did work for a while, longer than the average with 3.5. I
> was already about to write a success report, but then it hung again
> yesterday. I'm not using this laptop very intensively, so, it is hard to
> collect statistics.
You co
On 30.12.2012, Guennadi Liakhovetski wrote:
> Did that and it did work for a while, longer than the average with 3.5. I
> was already about to write a success report, but then it hung again
> yesterday. I'm not using this laptop very intensively, so, it is hard to
> collect statistics.
You co
On 17.12.2012, Guennadi Liakhovetski wrote:
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.
I have the same problem, are able to r
On 17.12.2012, Guennadi Liakhovetski wrote:
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.
I have the same problem, are able to r
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"
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"
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 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 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 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 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 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 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
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 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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
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 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 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, 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 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 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:
> 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, 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 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 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..
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..
___
dri-devel mailing list
dri-devel@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 25.10.2012, Pawe? Sikora wrote:
> what is the reason of loading nouveau driver for laptops
> with nvidia optimus and enabling vga switcheroo
> which doesn't work in such (optimus) cases.
You can safely compile a kernel without nouveau, your Nvidia
card will not be used at all since neither
On 25.10.2012, Paweł Sikora wrote:
> what is the reason of loading nouveau driver for laptops
> with nvidia optimus and enabling vga switcheroo
> which doesn't work in such (optimus) cases.
You can safely compile a kernel without nouveau, your Nvidia
card will not be used at all since neither
On 21.10.2012, Marcin Slusarz wrote:
> > > Please attach acpidump output.
> >
> > http://pluto.agmk.net/nv/acpidump.txt
> >
>
> This looks like ACPI bug...
I guess my acpidump didn't make it to the list. Anyway, here it is:
http://www.fritha.org/acpidump.gz
On 21.10.2012, Marcin Slusarz wrote:
> > > Please attach acpidump output.
> >
> > http://pluto.agmk.net/nv/acpidump.txt
> >
>
> This looks like ACPI bug...
I guess my acpidump didn't make it to the list. Anyway, here it is:
http://www.fritha.org/acpidump.gz
_
On 21.10.2012, Paweł Sikora wrote:
> with these both patches applied my laptop boots and gui works fine.
The same here. The two patches together, applied to 3.7-rc1 let my
machine boot again. Here's the relevant dmesg cut:
[3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
[
On 21.10.2012, Marcin Slusarz wrote:
> On 3.6 kernel? (It doesn't exist on 3.7)
> Note that it may be in other directory than "0".
[root@wildsau linux-3.6.2]# cat .config | grep -i "nouveau"
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_NOUVEAU_DEBUG=y
I grepped the whole disk,
On 20.10.2012, Marcin Slusarz wrote:
> Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[3.687784] nouveau [ DEVICE][
On 20.10.2012, Martin Peres wrote:
> Can you test the attached patch too ? I rebased the previous one I sent on
> top on 3.7-rc1 as I accidentally used an older version.
Yes, of course.
Tried it. Unfortunately, the crash remains the same as reported.
___
On 20.10.2012, Linus Torvalds wrote:
> Added more appropriate people to this. Added both i915 and nouveau
> people, since apparently that fine piece of hardware has both.
>
> Guys, any ideas?
Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
thing going on. Reverting
Ben Skeggs
On 21.10.2012, Pawe? Sikora wrote:
> with these both patches applied my laptop boots and gui works fine.
The same here. The two patches together, applied to 3.7-rc1 let my
machine boot again. Here's the relevant dmesg cut:
[3.702671] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
[
On 21.10.2012, Marcin Slusarz wrote:
> On 3.6 kernel? (It doesn't exist on 3.7)
> Note that it may be in other directory than "0".
[root at wildsau linux-3.6.2]# cat .config | grep -i "nouveau"
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_NOUVEAU_DEBUG=y
I grepped the whole di
On 20.10.2012, Marcin Slusarz wrote:
> Try this one.
It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:
[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[3.687784] nouveau [ DEVICE][
On 20.10.2012, Martin Peres wrote:
> Can you test the attached patch too ? I rebased the previous one I sent on
> top on 3.7-rc1 as I accidentally used an older version.
Yes, of course.
Tried it. Unfortunately, the crash remains the same as reported.
On 20.10.2012, Linus Torvalds wrote:
> Added more appropriate people to this. Added both i915 and nouveau
> people, since apparently that fine piece of hardware has both.
>
> Guys, any ideas?
Plese see https://lkml.org/lkml/2012/10/19/371 , this is the same
thing going on. Reverting
Ben Skeggs
49 matches
Mail list logo
