[Regression] 83f45fc turns machine's screen off

2014-12-16 Thread Heinz Diehl 
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 the issue.

Haven't seen your mail until now. Seems to be the same bug that I'm 
encountering.

https://bugs.freedesktop.org/show_bug.cgi?id=87330
https://lkml.org/lkml/2014/12/14/26

[Regression] 3.18 black screen after boot (bisected)

2014-12-15 Thread Heinz Diehl 
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.

> To make sure we don't forget this please file the above summary plus dmesg
> files as a new bug against dri -> drm(intel) on bugs.freedesktop.org.
> Please add "[ilk bisected]" to the bug summary so it shows up in all the
> right searches for us.

Will do.

-- next part --
A non-text attachment was scrubbed...
Name: dmesg-3.17.6.good.txt.xz
Type: application/octet-stream
Size: 36192 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: dmesg-3.18.bad.txt.xz
Type: application/octet-stream
Size: 19708 bytes
Desc: not available
URL:

[Regression] 3.18 black screen after boot (bisected)

2014-12-14 Thread Heinz Diehl 
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
83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter 
Date:   Wed Aug 6 09:10:18 2014 +0200

drm: Don't grab an fb reference for the idr

[]

I double-checked, and 3.18 is fine with this commit reverted.

My machine is an Asus U45JC laptop, and the CPU is an Intel i450M
(Ironlake). Please contact me if I can help in any way (I'm subscribed
to lkml, but not to other X or kernel related lists).

Thanks,
 Heinz.

[git pull] drm intel fixes

2013-01-11 Thread Heinz Diehl 
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 this patch to get the problem fixed?

Re: [git pull] drm intel fixes

2013-01-11 Thread Heinz Diehl 
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 this patch to get the problem fixed?

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: GPU hang

2012-12-31 Thread Heinz Diehl 
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 could try to reproduce the error by writing a big file e.g.

 dd if=/dev/zero of=deleteme bs=1M count=8

or similar and watching high definition video on Youtube (1080p) or running a 
few
instances of glxgears. That triggers a gpu hang in my case after
just a couple of seconds.

In my case, the hang doesn't occur when using SNA (or a kernel  3.7,
which isn't the case with your bug). I have this in my
xorg.conf:

Section Device
   Identifier Card0
   Driver intel
   Option AccelMethod SNA
EndSection

Without this, every 3.7 kernel produces a gpu hang within max. 1 min.

 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915: GPU hang

2012-12-30 Thread Heinz Diehl 
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 could try to reproduce the error by writing a big file e.g.

 dd if=/dev/zero of=deleteme bs=1M count=8

or similar and watching high definition video on Youtube (1080p) or running a 
few
instances of glxgears. That triggers a gpu hang in my case after
just a couple of seconds.

In my case, the hang doesn't occur when using SNA (or a kernel < 3.7,
which isn't the case with your bug). I have this in my
xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

Without this, every 3.7 kernel produces a gpu hang within max. 1 min.

i915: GPU hang

2012-12-18 Thread Heinz Diehl 
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 reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root at wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson 
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages


This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with "i915.i915_enable_rc6=0" and switch to SNA in your
Xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

There are tons of this "GPU hangcheck timer elapsed"
messages on the net...

Good luck!

Re: i915: GPU hang

2012-12-17 Thread Heinz Diehl 
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 reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages


This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with i915.i915_enable_rc6=0 and switch to SNA in your
Xorg.conf:

Section Device
   Identifier Card0
   Driver intel
   Option AccelMethod SNA
EndSection

There are tons of this GPU hangcheck timer elapsed
messages on the net...

Good luck!

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 freakout with latest 3.7 git

2012-12-11 Thread Heinz Diehl 
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" after about 1
min.

The errorstate file is here:

http://www.fritha.org/i915/errorstate3.tar.bz2

Heinz

i915 freakout with latest 3.7 git

2012-12-11 Thread Heinz Diehl 
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

Re: i915 freakout with latest 3.7 git

2012-12-11 Thread Heinz Diehl 
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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-11 Thread Heinz Diehl 
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 after about 1
min.

The errorstate file is here:

http://www.fritha.org/i915/errorstate3.tar.bz2

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 freakout with latest 3.7 git

2012-12-08 Thread Heinz Diehl 
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/in. So if you can reproduce with SNA (use Option "AccelMethod"
> "SNA" in a device section of your xorg.conf snippet) I expect the
> error-state to be quite different and hopefully shed some more light on
> the issue.

I tried this with latest 3.7-rc8 git, but no matter how hard I try, I
can't get the gpu to hang (with i915.915_enable_rc6=0). Will use this 
as my default kernel the next few days and see if the hang occurs by
chance.

Heinz

i915 freakout with latest 3.7 git

2012-12-08 Thread Heinz Diehl 
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) already ended up with
bisecting the same patch and it didn't work for him reverting it on
top of 3-7-rc4, I'm somewhat clueless..

What else can I do to help finding the cause?

Heinz


[root at wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson 
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages

When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with
evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush penalty for rebinding.

To avoid having to clflush on rebinding, we can track the pages as
they
are evicted from the GTT and only relinquish those pages on memory
pressure.

As usual, if it were not for the handling of out-of-memory
condition and
having to manually shrink our own bo caches, it would be a net
reduction
of code. Alas.

Note: The patch also contains a few changes to the last-hope
evict_everything logic in i916_gem_execbuffer.c - we no longer try
to
only evict the purgeable stuff in a first try (since that's
superflous
and only helps in OOM corner-cases, not fragmented-gtt trashing
situations).

Also, the extraction of the get_pages retry loop from bind_to_gtt
(and
other callsites) to get_pages should imo have been a separate
patch.

v2: Ditch the newly added put_pages (for unbound objects only) in
i915_gem_reset. A quick irc discussion hasn't revealed any
important
reason for this, so if we need this, I'd like to have a git
blame'able
explanation for it.

v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris
noticed.

Signed-off-by: Chris Wilson 
[danvet: Split out code movements and rant a bit in the commit
message
with a few Notes. Done v2]
Signed-off-by: Daniel Vetter 

:04 04 c4f02e0d05a570d0baf9d2f19a6c276c06a55142
df93a56308637e3840353c3c9425ec96c3422dcc M  drivers
[root at wildsau linux-git]#

Re: i915 freakout with latest 3.7 git

2012-12-08 Thread Heinz Diehl 
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) already ended up with
bisecting the same patch and it didn't work for him reverting it on
top of 3-7-rc4, I'm somewhat clueless..

What else can I do to help finding the cause?

Heinz


[root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages

When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with
evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush penalty for rebinding.

To avoid having to clflush on rebinding, we can track the pages as
they
are evicted from the GTT and only relinquish those pages on memory
pressure.

As usual, if it were not for the handling of out-of-memory
condition and
having to manually shrink our own bo caches, it would be a net
reduction
of code. Alas.

Note: The patch also contains a few changes to the last-hope
evict_everything logic in i916_gem_execbuffer.c - we no longer try
to
only evict the purgeable stuff in a first try (since that's
superflous
and only helps in OOM corner-cases, not fragmented-gtt trashing
situations).

Also, the extraction of the get_pages retry loop from bind_to_gtt
(and
other callsites) to get_pages should imo have been a separate
patch.

v2: Ditch the newly added put_pages (for unbound objects only) in
i915_gem_reset. A quick irc discussion hasn't revealed any
important
reason for this, so if we need this, I'd like to have a git
blame'able
explanation for it.

v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris
noticed.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
[danvet: Split out code movements and rant a bit in the commit
message
with a few Notes. Done v2]
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

:04 04 c4f02e0d05a570d0baf9d2f19a6c276c06a55142
df93a56308637e3840353c3c9425ec96c3422dcc M  drivers
[root@wildsau linux-git]# 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-08 Thread Heinz Diehl 
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/in. So if you can reproduce with SNA (use Option AccelMethod
 SNA in a device section of your xorg.conf snippet) I expect the
 error-state to be quite different and hopefully shed some more light on
 the issue.

I tried this with latest 3.7-rc8 git, but no matter how hard I try, I
can't get the gpu to hang (with i915.915_enable_rc6=0). Will use this 
as my default kernel the next few days and see if the hang occurs by
chance.

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-07 Thread Heinz Diehl 
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+ / latest git

3.) The hang doesn't occur with 3.7/latest git when 

 Driver Intel
 Options NoAccel True 

in Xorg.xonf is set (with all the drawbacks this introduces). Maybe
this rings a bell for someone..

In all cases, the machine is booted with i915.i915_enable_rc6=0.

Please contact me if you think I can help to debug this further.

Thanks,
Heinz.






___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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+ / latest git

3.) The hang doesn't occur with 3.7/latest git when 

 Driver "Intel"
 Options "NoAccel" "True" 

in Xorg.xonf is set (with all the drawbacks this introduces). Maybe
this rings a bell for someone..

In all cases, the machine is booted with "i915.i915_enable_rc6=0".

Please contact me if you think I can help to debug this further.

Thanks,
Heinz.

i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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

i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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
it takes between 30 sec. and 20 min.

> > Btw: which kernel is known to be the "last good one"?

> If it's the ilk one we only know that 3.6.x series seems to be solid, and
> something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

I tried 3.6.9 several times over a few hours and could not trigger the
hang, which clearly adds evidence to this statement. I don't want to
scream out too loud, but 3.6.9 seems not to be affected. Will try
some more hours to get a 3.6.9 box to hang, though.. Just in case..

Heinz

i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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 try again now.

My "i915_error_state" is here:

http://www.fritha.org/i915/error-01.tar.bz2

Heinz

Re: i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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 try again now.

My i915_error_state is here:

http://www.fritha.org/i915/error-01.tar.bz2

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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
it takes between 30 sec. and 20 min.

  Btw: which kernel is known to be the last good one?

 If it's the ilk one we only know that 3.6.x series seems to be solid, and
 something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

I tried 3.6.9 several times over a few hours and could not trigger the
hang, which clearly adds evidence to this statement. I don't want to
scream out too loud, but 3.6.9 seems not to be affected. Will try
some more hours to get a 3.6.9 box to hang, though.. Just in case..

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-06 Thread Heinz Diehl 
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://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 freakout with latest 3.7 git

2012-12-05 Thread Heinz Diehl 
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 with high I/O (caching?
> delays? Who knows).

No, unfortunately not. I will do my very best to find out how to
trigger it. For   now, I'm trying with a script which produces
max. I/O. Will also try by replaying a lot of high resolution videos and
similar.

> It is unlikely that Optimus has anything to do with this.

Ok.

Heinz

i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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 kernel hacker..).

i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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, but in comment 11 in the same thread you mention that reverting
this patch didn't fix the issue for you:

"Reverting that commit on top of 3.7-rc4 did not fix the hang issue."

> i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 

Yes, you're right, my bad! Don't know what I was thinking as I wrote that. I
don't have any i5-420M either, but an i5-450M. It was clearly not my
day..

[htd at wildsau ~]$ cat /proc/cpuinfo | grep model
model: 37
model name   : Intel(R) Core(TM) i5 CPU   M 450  @ 2.40GHz
[]

> i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
> probably hit another bug.

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

Heinz

i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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 absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the "last good one"?

> (you need to disable rc6 on ilk to not hit another issue which seems much 
> easier to
> hit) 

Ilk? If this stands for "Ironlake": I'm on Sandybridge.

> and bisect it, this would be _very_ much appreciated - we've
> pretty much tested all possible "disable stuff" and "revert random
> patch" we could thing of, and we can't reproduce these hangs no matter
> how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

> Atm we're trying to come up with ways to dump more debug
> information, >but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

Heinz

i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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..

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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 absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the last good one?

 (you need to disable rc6 on ilk to not hit another issue which seems much 
 easier to
 hit) 

Ilk? If this stands for Ironlake: I'm on Sandybridge.

 and bisect it, this would be _very_ much appreciated - we've
 pretty much tested all possible disable stuff and revert random
 patch we could thing of, and we can't reproduce these hangs no matter
 how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

 Atm we're trying to come up with ways to dump more debug
 information, but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
On 04.12.2012, Lekensteyn wrote: 

 As mentioned in the linked bug [1], I bisected it to:
 
 commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
 Author: Chris Wilson ch...@chris-wilson.co.uk
 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, but in comment 11 in the same thread you mention that reverting
this patch didn't fix the issue for you:

Reverting that commit on top of 3.7-rc4 did not fix the hang issue.

 i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 

Yes, you're right, my bad! Don't know what I was thinking as I wrote that. I
don't have any i5-420M either, but an i5-450M. It was clearly not my
day..

[htd@wildsau ~]$ cat /proc/cpuinfo | grep model
model: 37
model name   : Intel(R) Core(TM) i5 CPU   M 450  @ 2.40GHz
[]

 i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
 probably hit another bug.

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

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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 kernel hacker..).




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 freakout with latest 3.7 git

2012-12-04 Thread Heinz Diehl 
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 with high I/O (caching?
 delays? Who knows).

No, unfortunately not. I will do my very best to find out how to
trigger it. For   now, I'm trying with a script which produces
max. I/O. Will also try by replaying a lot of high resolution videos and
similar.

 It is unlikely that Optimus has anything to do with this.

Ok.

Heinz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-25 Thread Heinz Diehl 
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 Linux nor the 
proprietary nvidia driver does support optimus at this time
(and frankly, I won't buy any further machines with opticrap).
So having nouveau compiled and loaded seems like a waste of ressources
in this case.

For me it's important to have nouveau working, because I try/use
Bumblebee and optirun: 

http://bumblebee-project.org/
https://fedoraproject.org/wiki/Bumblebee

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-25 Thread Heinz Diehl 
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 Linux nor the 
proprietary nvidia driver does support optimus at this time
(and frankly, I won't buy any further machines with opticrap).
So having nouveau compiled and loaded seems like a waste of ressources
in this case.

For me it's important to have nouveau working, because I try/use
Bumblebee and optirun: 

http://bumblebee-project.org/
https://fedoraproject.org/wiki/Bumblebee

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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
[3.704643] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.707003] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.711393] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.712793] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.714147] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.715578] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.716969] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[4.207512] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[4.209711] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[4.212469] nouveau  [   VBIOS][:01:00.0] BIT signature found
[4.214855] nouveau  [   VBIOS][:01:00.0] version 70.18.5d.00
[4.217554] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[4.219922] nouveau  [   VBIOS][:01:00.0] running init tables
[4.342202] nouveau  [ MXM][:01:00.0] no VBIOS data, nothing to do
[4.343590] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[4.344916] nouveau  [ PFB][:01:00.0] RAM size: 1024 MiB
[4.991887] vga_switcheroo: enabled
[4.993495] [TTM] Zone  kernel: Available graphics memory: 1917720 kiB
[4.994911] [TTM] Initializing pool allocator
[4.996228] [TTM] Initializing DMA pool allocator
[4.998915] nouveau  [ DRM] VRAM: 1024 MiB
[5.000251] nouveau  [ DRM] GART: 512 MiB
[5.001579] nouveau  [ DRM] BIT BIOS found
[5.002904] nouveau  [ DRM] Bios version 70.18.5d.00
[5.004229] nouveau  [ DRM] TMDS table version 2.0
[5.005545] nouveau  [ DRM] DCB version 4.0
[5.006810] nouveau  [ DRM] DCB outp 00: 02014300 
[5.008115] nouveau  [ DRM] DCB conn 00: 0040
[5.009441] nouveau  [ DRM] DCB conn 01: 00410146
[5.010745] nouveau  [ DRM] DCB conn 02: 1261
[5.012019] nouveau  [ DRM] DCB conn 03: 2330
[5.013255] nouveau  [ DRM] DCB conn 04: 0400
[5.014452] nouveau  [ DRM] DCB conn 05: 0560
[5.052344] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[5.053486] [drm] No driver support for vblank timestamp query.
[5.054590] nouveau  [ DRM] ACPI backlight interface available,not 
registering our own
[5.356822] nouveau  [ DRM] 3 available performance level(s)
[5.358682] nouveau  [ DRM] 0: core 135MHz shader 270MHz memory 135MHz 
voltage 850mV
[5.360442] nouveau  [ DRM] 1: core 405MHz shader 810MHz memory 405MHz 
voltage 850mV
[5.362215] nouveau  [ DRM] 3: core 606MHz shader 1468MHz memory 667MHz 
voltage 1000mV
[5.363998] nouveau  [ DRM] c: core 405MHz shader 810MHz memory 405MHz
[5.404143] nouveau  [ DRM] MM: using COPY for buffer copies
[5.481593] No connectors reported connected with modes
[5.482667] [drm] Cannot find any crtc or sizes - going 1024x768
[5.517932] nouveau  [ DRM] allocated 1024x768 fb: 0x7, bo 
88013a6d3400
[5.519236] fb1: nouveaufb frame buffer device
[5.520368] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on 
minor 1
[5.527378] dracut: Starting plymouth daemon

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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 disk, there's no vbios.rom at all.

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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][:01:00.0] BOOT0  : 0x0a8800b1
[3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end 
of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution 
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT 
(20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
[3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
-22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon

And here's the same output with plain vanilla 3.6.2:

[3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x0a8800b1)
[3.599783] vga_switcheroo: enabled
[3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
[3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
[3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
[3.856854] [drm] nouveau :01:00.0: ... appears to be valid
[3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
[3.861907] [drm] nouveau :01:00.0: BIT BIOS found
[3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
[3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
[3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
[3.870871] [drm] nouveau :01:00.0: DCB version 4.0
[3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
[3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
[3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
[3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
[3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
[3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
[3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
[3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
VBIOS init tables.
[3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDECD
[3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
[3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE378
[3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEF4B
[3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xEF64
[3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xF04B
[3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xF0B0
[4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
[4.019438] [TTM] Initializing pool allocator
[4.020694] [TTM] Initializing DMA pool allocator
[4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
[4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.084909] [drm] No driver support for vblank timestamp query.
[4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
[4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 
135MHz voltage 850mV
[4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 
405MHz voltage 850mV
[4.249807] [drm] nouveau :01:00.0: 3: core 606MHz shader 1468MHz memory 
667MHz voltage 1000mV
[4.250946] [drm] nouveau :01:00.0: c: core 405MHz shader 810MHz memory 
405MHz
[

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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 bske...@redhat.com
 drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB

fixes the problem.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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][:01:00.0] BOOT0  : 0x0a8800b1
[3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end 
of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution 
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT 
(20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
[3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
-22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon

And here's the same output with plain vanilla 3.6.2:

[3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x0a8800b1)
[3.599783] vga_switcheroo: enabled
[3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
[3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
[3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
[3.856854] [drm] nouveau :01:00.0: ... appears to be valid
[3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
[3.861907] [drm] nouveau :01:00.0: BIT BIOS found
[3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
[3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
[3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
[3.870871] [drm] nouveau :01:00.0: DCB version 4.0
[3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
[3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
[3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
[3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
[3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
[3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
[3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
[3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
VBIOS init tables.
[3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDECD
[3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
[3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE378
[3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEF4B
[3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xEF64
[3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xF04B
[3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xF0B0
[4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
[4.019438] [TTM] Initializing pool allocator
[4.020694] [TTM] Initializing DMA pool allocator
[4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
[4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.084909] [drm] No driver support for vblank timestamp query.
[4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
[4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 
135MHz voltage 850mV
[4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 
405MHz voltage 850mV
[4.249807] [drm] nouveau :01:00.0: 3: core 606MHz shader 1468MHz memory 
667MHz voltage 1000mV
[4.250946] [drm] nouveau :01:00.0: c: core 405MHz shader 810MHz memory 
405MHz
[

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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, there's no vbios.rom at all.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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
[3.704643] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.707003] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.711393] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.712793] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.714147] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.715578] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.716969] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[4.207512] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[4.209711] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[4.212469] nouveau  [   VBIOS][:01:00.0] BIT signature found
[4.214855] nouveau  [   VBIOS][:01:00.0] version 70.18.5d.00
[4.217554] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[4.219922] nouveau  [   VBIOS][:01:00.0] running init tables
[4.342202] nouveau  [ MXM][:01:00.0] no VBIOS data, nothing to do
[4.343590] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[4.344916] nouveau  [ PFB][:01:00.0] RAM size: 1024 MiB
[4.991887] vga_switcheroo: enabled
[4.993495] [TTM] Zone  kernel: Available graphics memory: 1917720 kiB
[4.994911] [TTM] Initializing pool allocator
[4.996228] [TTM] Initializing DMA pool allocator
[4.998915] nouveau  [ DRM] VRAM: 1024 MiB
[5.000251] nouveau  [ DRM] GART: 512 MiB
[5.001579] nouveau  [ DRM] BIT BIOS found
[5.002904] nouveau  [ DRM] Bios version 70.18.5d.00
[5.004229] nouveau  [ DRM] TMDS table version 2.0
[5.005545] nouveau  [ DRM] DCB version 4.0
[5.006810] nouveau  [ DRM] DCB outp 00: 02014300 
[5.008115] nouveau  [ DRM] DCB conn 00: 0040
[5.009441] nouveau  [ DRM] DCB conn 01: 00410146
[5.010745] nouveau  [ DRM] DCB conn 02: 1261
[5.012019] nouveau  [ DRM] DCB conn 03: 2330
[5.013255] nouveau  [ DRM] DCB conn 04: 0400
[5.014452] nouveau  [ DRM] DCB conn 05: 0560
[5.052344] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[5.053486] [drm] No driver support for vblank timestamp query.
[5.054590] nouveau  [ DRM] ACPI backlight interface available,not 
registering our own
[5.356822] nouveau  [ DRM] 3 available performance level(s)
[5.358682] nouveau  [ DRM] 0: core 135MHz shader 270MHz memory 135MHz 
voltage 850mV
[5.360442] nouveau  [ DRM] 1: core 405MHz shader 810MHz memory 405MHz 
voltage 850mV
[5.362215] nouveau  [ DRM] 3: core 606MHz shader 1468MHz memory 667MHz 
voltage 1000mV
[5.363998] nouveau  [ DRM] c: core 405MHz shader 810MHz memory 405MHz
[5.404143] nouveau  [ DRM] MM: using COPY for buffer copies
[5.481593] No connectors reported connected with modes
[5.482667] [drm] Cannot find any crtc or sizes - going 1024x768
[5.517932] nouveau  [ DRM] allocated 1024x768 fb: 0x7, bo 
88013a6d3400
[5.519236] fb1: nouveaufb frame buffer device
[5.520368] [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on 
minor 1
[5.527378] dracut: Starting plymouth daemon

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-21 Thread Heinz Diehl 
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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-20 Thread Heinz Diehl 
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.

Linux 3.7-rc1 (nouveau_bios_score oops).

2012-10-20 Thread Heinz Diehl 
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 
 drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB

fixes the problem.