[git pull] drm for rc1

[Pavel Machek]

Hi!

> > > >>> Highlights:
> > > >>> core/drivers: add support for high precision vblank timestamps
> > > >>> radeon: pageflipping support, Gen2 PCIE support
> > > >>> nouveau: reworked VRAM and VM support
> > > >>> intel: better ILK/SNB powersaving support, Full GTT support
> > > >>
> > > >> Lowlights: it's broken.
> > 
> > Heh, at this point I expected Linus to complain about milion merges in
> > changelog...

(Ok, I chould have put a smiley there :-).

> > > Arg.  It's been ok on my ILK systems, but Chris has found some
> > >issues with out watermarking code iirc; apparently we're underflowing
> > >the display FIFO, causing all sorts of trouble.  If it works before
> > >the pull of Dave's tree, can you bisect?
> > 
> > Watermarking code? What goes on there?
> 
> FIFO watermarks, they determine when the display fetches from the scanout
> buffer to fill the pipe. If we run out of FIFO entries then the display
> flickers at best, at worst we may hard hang the machine.

Thanks for info. I was afraid it was trying to do some watermarks on
video signal, to catch evil videotapers or something like that...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [git pull] drm for rc1

[Pavel Machek]

Hi!

Highlights:
core/drivers: add support for high precision vblank timestamps
radeon: pageflipping support, Gen2 PCIE support
nouveau: reworked VRAM and VM support
intel: better ILK/SNB powersaving support, Full GTT support
   
Lowlights: it's broken.
  
  Heh, at this point I expected Linus to complain about milion merges in
  changelog...

(Ok, I chould have put a smiley there :-).

   Arg.  It's been ok on my ILK systems, but Chris has found some
  issues with out watermarking code iirc; apparently we're underflowing
  the display FIFO, causing all sorts of trouble.  If it works before
  the pull of Dave's tree, can you bisect?
  
  Watermarking code? What goes on there?
 
 FIFO watermarks, they determine when the display fetches from the scanout
 buffer to fill the pipe. If we run out of FIFO entries then the display
 flickers at best, at worst we may hard hang the machine.

Thanks for info. I was afraid it was trying to do some watermarks on
video signal, to catch evil videotapers or something like that...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm for rc1

[Alex Riesen]

On Mon, Jan 10, 2011 at 23:59, Dave Airlie  wrote:
> The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:
>
> ?Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)
>
> are available in the git repository at:
>
> ?ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-core-next
>
...
> ? ? ?drm/i915: Completely disable fence pipelining.

Reverting this commit helps in v2.6.38-rc5+ when screen is not fully updated,
or has a corrupted picture like horizontal black or white stripes. Using a
compositor like compiz may help to avoid the problem.

See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572

Re: [git pull] drm for rc1

[Alex Riesen]

On Mon, Jan 10, 2011 at 23:59, Dave Airlie airl...@linux.ie wrote:
 The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:

  Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)

 are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
 drm-core-next

...
      drm/i915: Completely disable fence pipelining.

Reverting this commit helps in v2.6.38-rc5+ when screen is not fully updated,
or has a corrupted picture like horizontal black or white stripes. Using a
compositor like compiz may help to avoid the problem.

See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

P.S. My laptop: radeon 3470 works perfect.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

On Thu, 13 Jan 2011, Anca Emanuel wrote:

 On Thu, Jan 13, 2011 at 7:55 PM, James Simmons jsimm...@infradead.org wrote:
 
With your patch, I can boot the system. But nouveau is not loaded.
dmesg attached.
   
  
   Forget to mention: the revert makes first steps of boot look the same
   (change the resolution of the text)
   but with your patch, I see a big ugly ununtu logo, (I think that is
   because nouveau is not loaded)
 
  Okay, can you do one more experiment for me. Since you already reverted
  the patch to get it booting I like to ask you to add
 
  drm_fb_helper_fill_fix(info, fb_helper-fb);
 
  back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have
  something like this:
 
         mutex_lock(dev-mode_config.mutex);
         for (i = 0; i  fb_helper-crtc_count; i++) {
                 crtc = fb_helper-crtc_info[i].mode_set.crtc;
                 ret = 
  crtc-funcs-set_config(fb_helper-crtc_info[i].mode_set);
                 if (ret) {
                         mutex_unlock(dev-mode_config.mutex);
                         return ret;
                 }
                 drm_fb_helper_fill_fix(info, fb_helper-fb);
         }
         mutex_unlock(dev-mode_config.mutex);
 
  Tell me if your system is still usable after that. Thanks for testing for
  me.
 
 
 after
 
 git revert dfe63bb0ad9810db13aab0058caba97866e0a681
 
 and
 
 
 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index 5c4f9b9..2aad663 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
 mutex_unlock(dev-mode_config.mutex);
 return ret;
 }
 +   drm_fb_helper_fill_fix(info, fb_helper-fb-pitch, 
 fb_helper-fb
 }
 mutex_unlock(dev-mode_config.mutex);
 
 I get an working system. ( the boot screen is not ok )
 Tested suspend/resume. Dmesg attached.

Just as I thought. Even this breaks the nouveau driver.

Could you now add also in the drm_fb_helper_fill_fix function

DRM_INFO(pitch %d, depth %d\n, fb_helper-fb-pitch, 
  fb_helper-fb-depth);
 
I have a feeling the values are not right. Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 6:38 PM, James Simmons jsimm...@infradead.org wrote:

 On Thu, 13 Jan 2011, Anca Emanuel wrote:

 On Thu, Jan 13, 2011 at 7:55 PM, James Simmons jsimm...@infradead.org 
 wrote:
 
With your patch, I can boot the system. But nouveau is not loaded.
dmesg attached.
   
  
   Forget to mention: the revert makes first steps of boot look the same
   (change the resolution of the text)
   but with your patch, I see a big ugly ununtu logo, (I think that is
   because nouveau is not loaded)
 
  Okay, can you do one more experiment for me. Since you already reverted
  the patch to get it booting I like to ask you to add
 
  drm_fb_helper_fill_fix(info, fb_helper-fb);
 
  back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have
  something like this:
 
         mutex_lock(dev-mode_config.mutex);
         for (i = 0; i  fb_helper-crtc_count; i++) {
                 crtc = fb_helper-crtc_info[i].mode_set.crtc;
                 ret = 
  crtc-funcs-set_config(fb_helper-crtc_info[i].mode_set);
                 if (ret) {
                         mutex_unlock(dev-mode_config.mutex);
                         return ret;
                 }
                 drm_fb_helper_fill_fix(info, fb_helper-fb);
         }
         mutex_unlock(dev-mode_config.mutex);
 
  Tell me if your system is still usable after that. Thanks for testing for
  me.
 

 after

 git revert dfe63bb0ad9810db13aab0058caba97866e0a681

 and


 diff --git a/drivers/gpu/drm/drm_fb_helper.c 
 b/drivers/gpu/drm/drm_fb_helper.c
 index 5c4f9b9..2aad663 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
                         mutex_unlock(dev-mode_config.mutex);
                         return ret;
                 }
 +               drm_fb_helper_fill_fix(info, fb_helper-fb-pitch, 
 fb_helper-fb
         }
         mutex_unlock(dev-mode_config.mutex);

 I get an working system. ( the boot screen is not ok )
 Tested suspend/resume. Dmesg attached.

 Just as I thought. Even this breaks the nouveau driver.

 Could you now add also in the drm_fb_helper_fill_fix function

 DRM_INFO(pitch %d, depth %d\n, fb_helper-fb-pitch,
          fb_helper-fb-depth);

 I have a feeling the values are not right. Thanks.


Please make an patch to test.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

  Just as I thought. Even this breaks the nouveau driver.
 
  Could you now add also in the drm_fb_helper_fill_fix function
 
  DRM_INFO(pitch %d, depth %d\n, fb_helper-fb-pitch,
           fb_helper-fb-depth);
 
  I have a feeling the values are not right. Thanks.
 
 
 Please make an patch to test.

Done. I had to test the patch myself. No need to do a revert. Just apply 
this patch to linus tree. Then send the dmesg to me. Thanks.

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
 
 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO(pitch %d, depth %d\n, fb-pitch, fb-depth);
info-fix.type = FB_TYPE_PACKED_PIXELS;
info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
*fb_helper,
 
if (new_fb) {
info-var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper-fb);
if (register_framebuffer(info)  0) {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index a26d047..fe87319 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
info-screen_size = size;
 
+   drm_fb_helper_fill_fix(info, fb);
drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
sizes-fb_height);
 
/* Set aperture base/size for vesafb takeover */___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:26 PM, James Simmons jsimm...@infradead.org wrote:

  Just as I thought. Even this breaks the nouveau driver.
 
  Could you now add also in the drm_fb_helper_fill_fix function
 
  DRM_INFO(pitch %d, depth %d\n, fb_helper-fb-pitch,
           fb_helper-fb-depth);
 
  I have a feeling the values are not right. Thanks.
 

 Please make an patch to test.

 Done. I had to test the patch myself. No need to do a revert. Just apply
 this patch to linus tree. Then send the dmesg to me. Thanks.

 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index 0307d60..beded14 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

  void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
  {
 +       DRM_INFO(pitch %d, depth %d\n, fb-pitch, fb-depth);
        info-fix.type = FB_TYPE_PACKED_PIXELS;
        info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
                FB_VISUAL_TRUECOLOR;
 @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
 *fb_helper,

        if (new_fb) {
                info-var.pixclock = 0;
 -               drm_fb_helper_fill_fix(info, fb_helper-fb);
                if (register_framebuffer(info)  0) {
                        return -EINVAL;
                }
 diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
 b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 index a26d047..fe87319 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
        info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
        info-screen_size = size;

 +       drm_fb_helper_fill_fix(info, fb);
        drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
 sizes-fb_height);

        /* Set aperture base/size for vesafb takeover */

I will test it, but first, I will need to disable the cassini driver,
because it can not compile.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:40 PM, Anca Emanuel anca.eman...@gmail.com wrote:
 On Fri, Jan 14, 2011 at 8:26 PM, James Simmons jsimm...@infradead.org wrote:

  Just as I thought. Even this breaks the nouveau driver.
 
  Could you now add also in the drm_fb_helper_fill_fix function
 
  DRM_INFO(pitch %d, depth %d\n, fb_helper-fb-pitch,
           fb_helper-fb-depth);
 
  I have a feeling the values are not right. Thanks.
 

 Please make an patch to test.

 Done. I had to test the patch myself. No need to do a revert. Just apply
 this patch to linus tree. Then send the dmesg to me. Thanks.

 diff --git a/drivers/gpu/drm/drm_fb_helper.c 
 b/drivers/gpu/drm/drm_fb_helper.c
 index 0307d60..beded14 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

  void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer 
 *fb)
  {
 +       DRM_INFO(pitch %d, depth %d\n, fb-pitch, fb-depth);
        info-fix.type = FB_TYPE_PACKED_PIXELS;
        info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
                FB_VISUAL_TRUECOLOR;
 @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
 *fb_helper,

        if (new_fb) {
                info-var.pixclock = 0;
 -               drm_fb_helper_fill_fix(info, fb_helper-fb);
                if (register_framebuffer(info)  0) {
                        return -EINVAL;
                }
 diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
 b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 index a26d047..fe87319 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
 @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
        info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
        info-screen_size = size;

 +       drm_fb_helper_fill_fix(info, fb);
        drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
 sizes-fb_height);

        /* Set aperture base/size for vesafb takeover */

 I will test it, but first, I will need to disable the cassini driver,
 because it can not compile.


I will test this first:

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO(pitch %d, depth %d\n, fb-pitch, fb-depth);
info-fix.type = FB_TYPE_PACKED_PIXELS;
info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info-var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper-fb);
if (register_framebuffer(info)  0) {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/n
index a26d047..3896771 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO(pitch %d, depth %d\n, fb-pitch, fb-depth);
info-fix.type = FB_TYPE_PACKED_PIXELS;
info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info-var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper-fb);
if (register_framebuffer(info)  0) {
return -EINVAL;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

   With your patch, I can boot the system. But nouveau is not loaded.
   dmesg attached.
  
  
  Forget to mention: the revert makes first steps of boot look the same
  (change the resolution of the text)
  but with your patch, I see a big ugly ununtu logo, (I think that is
  because nouveau is not loaded)

Okay, can you do one more experiment for me. Since you already reverted 
the patch to get it booting I like to ask you to add 

drm_fb_helper_fill_fix(info, fb_helper-fb);

back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have 
something like this:

mutex_lock(dev-mode_config.mutex);
for (i = 0; i  fb_helper-crtc_count; i++) {
crtc = fb_helper-crtc_info[i].mode_set.crtc;
ret = 
crtc-funcs-set_config(fb_helper-crtc_info[i].mode_set);
if (ret) {
mutex_unlock(dev-mode_config.mutex);
return ret;
}
drm_fb_helper_fill_fix(info, fb_helper-fb);
}
mutex_unlock(dev-mode_config.mutex);
 
Tell me if your system is still usable after that. Thanks for testing for 
me.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:40 PM, James Simmons  
wrote:
>
>> >>> I tested the revert: the boot screen did change the resolution
>> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>> >>
>> >> Try my most recent patch. Where does it hang at? Any logs?
>> >>
>> >
>> > With your patch, I can boot the system. But nouveau is not loaded.
>> > dmesg attached.
>> >
>>
>> Forget to mention: the revert makes first steps of boot look the same
>> (change the resolution of the text)
>> but with your patch, I see a big ugly ununtu logo, (I think that is
>> because nouveau is not loaded)
>
> Is nouveau a module? Does X run? From my understanding is the xorg driver

I didn't modified any option, from the standard Ubuntu 10.10

> need KMS to run. I didn't see nouveau at all in your dmesg.

Exact. I mentioned this when I tested 'next' versions from last year.
The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681.

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel  wrote:
> On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
> wrote:
>>
>>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>>  wrote:
>>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>> >>  wrote:
>>> >>>
>>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev 
>>> >>> a1))
>>> >>> During startup the framebuffer shows only stripes and a blank
>>> >>> screen after suspend/resume.
>>> >>> I also see lots of TRAP messages. (see below).
>>> >>> X11 seems to work fine though...
>>> >>
>>> >> Can you try to bisect?
>>> >
>>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>>> > Author: James Simmons 
>>> > Date: ? Thu Dec 23 16:40:37 2010 +
>>> >
>>> > ? ?drm: Update fbdev fb_fix_screeninfo
>>> >
>>> >
>>> > Reverting this on top of todays git also fixes my problem.
>>> >
>>> > Christian
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> > the body of a message to majordomo at vger.kernel.org
>>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>> > Please read the FAQ at ?http://www.tux.org/lkml/
>>> >
>>>
>>> I tested the revert: the boot screen did change the resolution
>>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>>
>> Try my most recent patch. Where does it hang at? Any logs?
>>
>
> With your patch, I can boot the system. But nouveau is not loaded.
> dmesg attached.
>

Forget to mention: the revert makes first steps of boot look the same
(change the resolution of the text)
but with your patch, I see a big ugly ununtu logo, (I think that is
because nouveau is not loaded)

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
wrote:
>
>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>  wrote:
>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>> >>  wrote:
>> >>>
>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> >>> During startup the framebuffer shows only stripes and a blank
>> >>> screen after suspend/resume.
>> >>> I also see lots of TRAP messages. (see below).
>> >>> X11 seems to work fine though...
>> >>
>> >> Can you try to bisect?
>> >
>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>> > Author: James Simmons 
>> > Date: ? Thu Dec 23 16:40:37 2010 +
>> >
>> > ? ?drm: Update fbdev fb_fix_screeninfo
>> >
>> >
>> > Reverting this on top of todays git also fixes my problem.
>> >
>> > Christian
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majordomo at vger.kernel.org
>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at ?http://www.tux.org/lkml/
>> >
>>
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
>

With your patch, I can boot the system. But nouveau is not loaded.
dmesg attached.
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.37-patch+ (root at ubuntu) (gcc version 4.4.5 
(Ubuntu/Linaro 4.4.4-14ubuntu5) ) #1 SMP Wed Jan 12 16:18:26 EET 2011
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e3000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7ffb (usable)
[0.00]  BIOS-e820: 7ffb - 7ffbe000 (ACPI data)
[0.00]  BIOS-e820: 7ffbe000 - 7fff (ACPI NVS)
[0.00]  BIOS-e820: 7fff - 8000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ffb0 - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] DMI present.
[0.00] DMI: MS-7360/MS-7360, BIOS V1.10 11/11/2008
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0x7ffb0 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [c00ff780] ff780
[0.00] Scanning 0 areas for low memory corruption
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -377fe000
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ bfb000-c0
[0.00] RAMDISK: 3758a000 - 37ff
[0.00] Allocated new RAMDISK: 36b24000 - 375899bd
[0.00] Move RAMDISK from 3758a000 - 37fef9bc to 
36b24000 - 375899bc
[0.00] ACPI: RSDP 000f9bb0 00014 (v00 ACPIAM)
[0.00] ACPI: RSDT 7ffb 00040 (v01 08 RSDT0906 2008 MSFT 
0097)
[0.00] ACPI: FACP 7ffb0200 00084 (v01 08 FACP0906 2008 MSFT 
0097)
[0.00] ACPI: DSDT 7ffb0440 05595 (v01  0 0000  INTL 
20051117)
[0.00] ACPI: FACS 7ffbe000 00040
[0.00] ACPI: APIC 7ffb0390 0006C (v01 08 APIC0906 2008 MSFT 
0097)
[0.00] ACPI: MCFG 7ffb0400 0003C (v01 08 OEMMCFG  2008 MSFT 
0097)
[0.00] ACPI: OEMB 7ffbe040 00071 (v01 08 OEMB0906 2008 MSFT 
0097)
[0.00] ACPI: HPET 7ffb59e0 00038 (v01 

[git pull] drm for rc1

[James Simmons]

> Am 12.01.2011 14:45, schrieb James Simmons:
> >> I tested the revert: the boot screen did change the resolution
> >> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
> > 
> > Try my most recent patch. Where does it hang at? Any logs?
> 
> FYI, I just want to mention that with the latest git+the fix 
> X11 sometimes consumes 100% cpu for a long time. Dont know if
> this is a related problem or not.

I doubt they are related.

[git pull] drm for rc1

[James Simmons]

> IOW, I'm inclined to just do the revert. The "fix" clearly breaks
> things, and now you're adding random parts of the function back rather
> than just calling the "fill_fix()" function like things used to. Why?

Its not the final patch. I'm trying to get feedback on what broke exactly.

> The commit message in dfe63bb0ad98 doesn't support any of these hacks
> - it just seems to say that drm_fb_helper_fill_fix() should also have
> been called from setcolreg().
>
> So why don't we just revert the commit and instead add that
> drm_fb_helper_fill_fix() to setcolreg()?

Fine by me. The real problem is the nouveau driver is using the 
framebuffer device (fb_fillrect) before set_par is ever called.
Before calling set_par the framebuffer state is not defined.

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
wrote:
>
>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>  wrote:
>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>> >>  wrote:
>> >>>
>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> >>> During startup the framebuffer shows only stripes and a blank
>> >>> screen after suspend/resume.
>> >>> I also see lots of TRAP messages. (see below).
>> >>> X11 seems to work fine though...
>> >>
>> >> Can you try to bisect?
>> >
>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>> > Author: James Simmons 
>> > Date: ? Thu Dec 23 16:40:37 2010 +
>> >
>> > ? ?drm: Update fbdev fb_fix_screeninfo
>> >
>> >
>> > Reverting this on top of todays git also fixes my problem.
>> >
>> > Christian
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majordomo at vger.kernel.org
>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at ?http://www.tux.org/lkml/
>> >
>>
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
>

My keyboard is not working, I can not make an log.
I see 'something' on the screen, I hear the boot song sometimes.

I will test it your parch, but for me it will take over 1 hour.

[git pull] drm for rc1

[James Simmons]

> >>> I tested the revert: the boot screen did change the resolution
> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
> >>
> >> Try my most recent patch. Where does it hang at? Any logs?
> >>
> >
> > With your patch, I can boot the system. But nouveau is not loaded.
> > dmesg attached.
> >
> 
> Forget to mention: the revert makes first steps of boot look the same
> (change the resolution of the text)
> but with your patch, I see a big ugly ununtu logo, (I think that is
> because nouveau is not loaded)

Is nouveau a module? Does X run? From my understanding is the xorg driver 
need KMS to run. I didn't see nouveau at all in your dmesg.

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 wrote:
> Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>  wrote:
>>>
>>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>>> During startup the framebuffer shows only stripes and a blank
>>> screen after suspend/resume.
>>> I also see lots of TRAP messages. (see below).
>>> X11 seems to work fine though...
>>
>> Can you try to bisect?
>
> dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> commit dfe63bb0ad9810db13aab0058caba97866e0a681
> Author: James Simmons 
> Date: ? Thu Dec 23 16:40:37 2010 +
>
> ? ?drm: Update fbdev fb_fix_screeninfo
>
>
> Reverting this on top of todays git also fixes my problem.
>
> Christian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

I tested the revert: the boot screen did change the resolution
(without it don't), but my PC still hangs. (using an nvidia 8800GT).

[git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 14:45, schrieb James Simmons:
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
> 
> Try my most recent patch. Where does it hang at? Any logs?

FYI, I just want to mention that with the latest git+the fix 
X11 sometimes consumes 100% cpu for a long time. Dont know if
this is a related problem or not.

Christian

[git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 14:32, schrieb James Simmons:
> Okay. The nouveau driver also uses the pitch as well. It 
> really should be using the pitch field from drm_framebuffer instead of the 
> line_length from fb_fix_screeninfo. This patch is just to make sure this 
> is the issue. I will submit another patch later that uses 
> drm_fb_framebuffer's pitch field. As for the visual unfortunely their is 
> no real mapping between drm and fbdev.
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index a26d047..de3b067 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
>   info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
>   info->screen_size = size;
> 
> + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
> +FB_VISUAL_TRUECOLOR;
> + info->fix.line_length = fb->pitch;
>   drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
> sizes->fb_height);
> 
>   /* Set aperture base/size for vesafb takeover */

That fixes _my_ nouveau frame buffer regression. 

[git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 13:49, schrieb James Simmons:
> I see the problem. Nouveau for some hardware does a accelerated 
> clearing of the screen before we register the framebuffer. The above patch 
> does fix a real issue so please don't revert it. Can you try this patch.
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index a26d047..4ef24d6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
>   info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
>   info->screen_size = size;
> 
> + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
> +FB_VISUAL_TRUECOLOR;
>   drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
> sizes->fb_height);
> 
>   /* Set aperture base/size for vesafb takeover */

Hmm, does not seem to work. Any more initialization missing?

[git pull] drm for rc1

[James Simmons]

> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>  wrote:
> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
> >>  wrote:
> >>>
> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> >>> During startup the framebuffer shows only stripes and a blank
> >>> screen after suspend/resume.
> >>> I also see lots of TRAP messages. (see below).
> >>> X11 seems to work fine though...
> >>
> >> Can you try to bisect?
> >
> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
> > Author: James Simmons 
> > Date: ? Thu Dec 23 16:40:37 2010 +
> >
> > ? ?drm: Update fbdev fb_fix_screeninfo
> >
> >
> > Reverting this on top of todays git also fixes my problem.
> >
> > Christian
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at ?http://www.tux.org/lkml/
> >
> 
> I tested the revert: the boot screen did change the resolution
> (without it don't), but my PC still hangs. (using an nvidia 8800GT).

Try my most recent patch. Where does it hang at? Any logs?

[git pull] drm for rc1

[James Simmons]

> Am 12.01.2011 13:49, schrieb James Simmons:
> > I see the problem. Nouveau for some hardware does a accelerated 
> > clearing of the screen before we register the framebuffer. The above patch 
> > does fix a real issue so please don't revert it. Can you try this patch.
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> > index a26d047..4ef24d6 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
> > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
> > info->screen_size = size;
> > 
> > +   info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
> > +FB_VISUAL_TRUECOLOR;
> > drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
> > sizes->fb_height);
> > 
> > /* Set aperture base/size for vesafb takeover */
> 
> Hmm, does not seem to work. Any more initialization missing?

Okay. The nouveau driver also uses the pitch as well. It 
really should be using the pitch field from drm_framebuffer instead of the 
line_length from fb_fix_screeninfo. This patch is just to make sure this 
is the issue. I will submit another patch later that uses 
drm_fb_framebuffer's pitch field. As for the visual unfortunely their is 
no real mapping between drm and fbdev.

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index a26d047..de3b067 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
info->screen_size = size;

+   info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+FB_VISUAL_TRUECOLOR;
+   info->fix.line_length = fb->pitch;
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);

/* Set aperture base/size for vesafb takeover */

[git pull] drm for rc1

[James Simmons]

> Am 12.01.2011 00:28, schrieb Linus Torvalds:
> > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
> >  wrote:
> >>
> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
> >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> >> During startup the framebuffer shows only stripes and a blank
> >> screen after suspend/resume.
> >> I also see lots of TRAP messages. (see below).
> >> X11 seems to work fine though...
> > 
> > Can you try to bisect?
> 
> dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> commit dfe63bb0ad9810db13aab0058caba97866e0a681
> Author: James Simmons 
> Date:   Thu Dec 23 16:40:37 2010 +
> 
> drm: Update fbdev fb_fix_screeninfo
> 
> 
> Reverting this on top of todays git also fixes my problem.

I see the problem. Nouveau for some hardware does a accelerated 
clearing of the screen before we register the framebuffer. The above patch 
does fix a real issue so please don't revert it. Can you try this patch.

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index a26d047..4ef24d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
info->screen_size = size;

+   info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+FB_VISUAL_TRUECOLOR;
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);

/* Set aperture base/size for vesafb takeover */

[git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 00:28, schrieb Linus Torvalds:
> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>  wrote:
>>
>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> During startup the framebuffer shows only stripes and a blank
>> screen after suspend/resume.
>> I also see lots of TRAP messages. (see below).
>> X11 seems to work fine though...
> 
> Can you try to bisect?

dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
commit dfe63bb0ad9810db13aab0058caba97866e0a681
Author: James Simmons 
Date:   Thu Dec 23 16:40:37 2010 +

drm: Update fbdev fb_fix_screeninfo


Reverting this on top of todays git also fixes my problem.

Christian

[git pull] drm for rc1

[Dave Airlie]

On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds
 wrote:
> On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
>  wrote:
>>
>> ?... I'll test that drm-intel-staging commit.
>
> Initial testing _seems_ to confirm that merging drm-intel-staging gets
> rid of the problem. But I haven't spent a whole lot of time in the
> screen saver. Will start driving kids around now, so more intense
> screen saver testing is coming up..

Its looking good here, I've pushed a drm-fixes branch with what Chris
sent me + a couple of i915/iommu fixes to my repo,

I'm going to run it on my laptop for a few more hours then I'll send
you a pull req, but none of the triggers I had yesterday seem to take
it down.

Dave.

>
> ? ? ? ? ? ? ? ? ? Linus
>

[git pull] drm for rc1

[Linus Torvalds]

On Wed, Jan 12, 2011 at 5:32 AM, James Simmons  
wrote:
>
> Okay. The nouveau driver also uses the pitch as well. It
> really should be using the pitch field from drm_framebuffer instead of the
> line_length from fb_fix_screeninfo. This patch is just to make sure this
> is the issue. I will submit another patch later that uses
> drm_fb_framebuffer's pitch field. As for the visual unfortunely their is
> no real mapping between drm and fbdev.

Why do you want to remove the drm_fb_helper_fill_fix() call? Quite
frankly, you're then replacing it with open-coding the function
partially:

> + ? ? ? info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
> + ? ? ? ? ? ? ? ?FB_VISUAL_TRUECOLOR;
> + ? ? ? info->fix.line_length = fb->pitch;
> ? ? ? ?drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
> sizes->fb_height);

Which seems to be just a regression. Why not just call
"drm_fb_helper_fill_fix()" here like we used to?

IOW, I'm inclined to just do the revert. The "fix" clearly breaks
things, and now you're adding random parts of the function back rather
than just calling the "fill_fix()" function like things used to. Why?

The commit message in dfe63bb0ad98 doesn't support any of these hacks
- it just seems to say that drm_fb_helper_fill_fix() should also have
been called from setcolreg().

So why don't we just revert the commit and instead add that
drm_fb_helper_fill_fix() to setcolreg()?

Linus

[git pull] drm for rc1

[Christian Borntraeger]

Am 10.01.2011 23:59, schrieb Dave Airlie:
> 
> Hi Linus,
> 
> non-drm changes:
> one kref change we needed that went on list with no comments
> 
> New hardware:
> radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
> nouveau: Fermi acceleration support (requires external fw for now)
> 
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support
> 
> There are also some switcheroo patches to further improve it, though I 
> have a later patch blocking on an x86 platform driver for the nvidia/intel 
> switcher.
> 
> Dave.

Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible 
controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
During startup the framebuffer shows only stripes and a blank
screen after suspend/resume.
I also see lots of TRAP messages. (see below).
X11 seems to work fine though...

$ dmesg | grep drm
[0.520906] [drm] Initialized drm 1.1.0 20060810
[0.521200] [drm] radeon defaulting to kernel modesetting.
[0.521416] [drm] radeon kernel modesetting enabled.
[0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp 
module!
[0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x084c00a2)
[0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from 
PRAMIN
[0.641884] [drm] nouveau :01:00.0: ... appears to be valid
[0.642058] [drm] nouveau :01:00.0: BIT BIOS found
[0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00
[0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0   


[0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found  


[0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block 
version 4.0 
   
[0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034   


[0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028   


[0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030   


[0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e    


[0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 
2   
 
[0.643836] [drm] nouveau :01:00.0:   0: 0x0040: type 0x40 idx 0 tag 
0xff
[0.644089] [drm] nouveau :01:00.0:   1: 0x0100: type 0x00 idx 1 tag 
0xff
[0.644317] [drm] nouveau :01:00.0:   2: 0x1231: type 0x31 idx 2 tag 
0x07
[0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDEBB
[0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE208
[0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEC55
[0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xED47
[0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xEF7A
[0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xEFDF
[0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met 
after 20ms, skipping following opcodes
[0.775483] [drm] nouveau :01:00.0: 3 available performance level(s)
[0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 
338MHz voltage 1150mV fanspeed 100%
[0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 
550MHz voltage 1150mV fanspeed 100%
[0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 
950MHz voltage 1200mV fanspeed 100%
[0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 
550MHz voltage 1150mV
[0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM
[0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.889565] [drm] No driver support for vblank timestamp query.
[0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, 
bo 88013af63400
[1.071842] [drm] nouveau 

Re: [git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 00:28, schrieb Linus Torvalds:
 On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
 borntrae...@de.ibm.com wrote:

 Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
 compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
 During startup the framebuffer shows only stripes and a blank
 screen after suspend/resume.
 I also see lots of TRAP messages. (see below).
 X11 seems to work fine though...
 
 Can you try to bisect?

dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
commit dfe63bb0ad9810db13aab0058caba97866e0a681
Author: James Simmons jsimm...@infradead.org
Date:   Thu Dec 23 16:40:37 2010 +

drm: Update fbdev fb_fix_screeninfo


Reverting this on top of todays git also fixes my problem.

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

Re: [git pull] drm for rc1

[James Simmons]

 Am 12.01.2011 00:28, schrieb Linus Torvalds:
  On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
  borntrae...@de.ibm.com wrote:
 
  Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
  compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
  During startup the framebuffer shows only stripes and a blank
  screen after suspend/resume.
  I also see lots of TRAP messages. (see below).
  X11 seems to work fine though...
  
  Can you try to bisect?
 
 dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
 commit dfe63bb0ad9810db13aab0058caba97866e0a681
 Author: James Simmons jsimm...@infradead.org
 Date:   Thu Dec 23 16:40:37 2010 +
 
 drm: Update fbdev fb_fix_screeninfo
 
 
 Reverting this on top of todays git also fixes my problem.

I see the problem. Nouveau for some hardware does a accelerated 
clearing of the screen before we register the framebuffer. The above patch 
does fix a real issue so please don't revert it. Can you try this patch.

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index a26d047..4ef24d6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
info-screen_size = size;
 
+   info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+FB_VISUAL_TRUECOLOR;
drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
sizes-fb_height);
 
/* Set aperture base/size for vesafb takeover */



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

Re: [git pull] drm for rc1

[James Simmons]

 Am 12.01.2011 13:49, schrieb James Simmons:
  I see the problem. Nouveau for some hardware does a accelerated 
  clearing of the screen before we register the framebuffer. The above patch 
  does fix a real issue so please don't revert it. Can you try this patch.
  
  diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
  b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
  index a26d047..4ef24d6 100644
  --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
  +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
  @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
  info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
  info-screen_size = size;
  
  +   info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
  +FB_VISUAL_TRUECOLOR;
  drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
  sizes-fb_height);
  
  /* Set aperture base/size for vesafb takeover */
 
 Hmm, does not seem to work. Any more initialization missing?

Okay. The nouveau driver also uses the pitch as well. It 
really should be using the pitch field from drm_framebuffer instead of the 
line_length from fb_fix_screeninfo. This patch is just to make sure this 
is the issue. I will submit another patch later that uses 
drm_fb_framebuffer's pitch field. As for the visual unfortunely their is 
no real mapping between drm and fbdev.

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index a26d047..de3b067 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
info-screen_size = size;
 
+   info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+FB_VISUAL_TRUECOLOR;
+   info-fix.line_length = fb-pitch;
drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
sizes-fb_height);
 
/* Set aperture base/size for vesafb takeover */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
borntrae...@de.ibm.com wrote:
 Am 12.01.2011 00:28, schrieb Linus Torvalds:
 On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
 borntrae...@de.ibm.com wrote:

 Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
 compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
 During startup the framebuffer shows only stripes and a blank
 screen after suspend/resume.
 I also see lots of TRAP messages. (see below).
 X11 seems to work fine though...

 Can you try to bisect?

 dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
 commit dfe63bb0ad9810db13aab0058caba97866e0a681
 Author: James Simmons jsimm...@infradead.org
 Date:   Thu Dec 23 16:40:37 2010 +

    drm: Update fbdev fb_fix_screeninfo


 Reverting this on top of todays git also fixes my problem.

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


I tested the revert: the boot screen did change the resolution
(without it don't), but my PC still hangs. (using an nvidia 8800GT).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

 On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 borntrae...@de.ibm.com wrote:
  Am 12.01.2011 00:28, schrieb Linus Torvalds:
  On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
  borntrae...@de.ibm.com wrote:
 
  Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
  compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
  During startup the framebuffer shows only stripes and a blank
  screen after suspend/resume.
  I also see lots of TRAP messages. (see below).
  X11 seems to work fine though...
 
  Can you try to bisect?
 
  dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
  commit dfe63bb0ad9810db13aab0058caba97866e0a681
  Author: James Simmons jsimm...@infradead.org
  Date:   Thu Dec 23 16:40:37 2010 +
 
     drm: Update fbdev fb_fix_screeninfo
 
 
  Reverting this on top of todays git also fixes my problem.
 
  Christian
  --
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 
 
 I tested the revert: the boot screen did change the resolution
 (without it don't), but my PC still hangs. (using an nvidia 8800GT).

Try my most recent patch. Where does it hang at? Any logs?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons jsimm...@infradead.org wrote:

 On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 borntrae...@de.ibm.com wrote:
  Am 12.01.2011 00:28, schrieb Linus Torvalds:
  On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
  borntrae...@de.ibm.com wrote:
 
  Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
  compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
  During startup the framebuffer shows only stripes and a blank
  screen after suspend/resume.
  I also see lots of TRAP messages. (see below).
  X11 seems to work fine though...
 
  Can you try to bisect?
 
  dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
  commit dfe63bb0ad9810db13aab0058caba97866e0a681
  Author: James Simmons jsimm...@infradead.org
  Date:   Thu Dec 23 16:40:37 2010 +
 
     drm: Update fbdev fb_fix_screeninfo
 
 
  Reverting this on top of todays git also fixes my problem.
 
  Christian
  --
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 

 I tested the revert: the boot screen did change the resolution
 (without it don't), but my PC still hangs. (using an nvidia 8800GT).

 Try my most recent patch. Where does it hang at? Any logs?


My keyboard is not working, I can not make an log.
I see 'something' on the screen, I hear the boot song sometimes.

I will test it your parch, but for me it will take over 1 hour.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Christian Borntraeger]

Am 12.01.2011 14:45, schrieb James Simmons:
 I tested the revert: the boot screen did change the resolution
 (without it don't), but my PC still hangs. (using an nvidia 8800GT).
 
 Try my most recent patch. Where does it hang at? Any logs?

FYI, I just want to mention that with the latest git+the fix 
X11 sometimes consumes 100% cpu for a long time. Dont know if
this is a related problem or not.

Christian

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

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel anca.eman...@gmail.com wrote:
 On Wed, Jan 12, 2011 at 3:45 PM, James Simmons jsimm...@infradead.org wrote:

 On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 borntrae...@de.ibm.com wrote:
  Am 12.01.2011 00:28, schrieb Linus Torvalds:
  On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
  borntrae...@de.ibm.com wrote:
 
  Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
  compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev 
  a1))
  During startup the framebuffer shows only stripes and a blank
  screen after suspend/resume.
  I also see lots of TRAP messages. (see below).
  X11 seems to work fine though...
 
  Can you try to bisect?
 
  dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
  commit dfe63bb0ad9810db13aab0058caba97866e0a681
  Author: James Simmons jsimm...@infradead.org
  Date:   Thu Dec 23 16:40:37 2010 +
 
     drm: Update fbdev fb_fix_screeninfo
 
 
  Reverting this on top of todays git also fixes my problem.
 
  Christian
  --
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 

 I tested the revert: the boot screen did change the resolution
 (without it don't), but my PC still hangs. (using an nvidia 8800GT).

 Try my most recent patch. Where does it hang at? Any logs?


 With your patch, I can boot the system. But nouveau is not loaded.
 dmesg attached.


Forget to mention: the revert makes first steps of boot look the same
(change the resolution of the text)
but with your patch, I see a big ugly ununtu logo, (I think that is
because nouveau is not loaded)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

  I tested the revert: the boot screen did change the resolution
  (without it don't), but my PC still hangs. (using an nvidia 8800GT).
 
  Try my most recent patch. Where does it hang at? Any logs?
 
 
  With your patch, I can boot the system. But nouveau is not loaded.
  dmesg attached.
 
 
 Forget to mention: the revert makes first steps of boot look the same
 (change the resolution of the text)
 but with your patch, I see a big ugly ununtu logo, (I think that is
 because nouveau is not loaded)

Is nouveau a module? Does X run? From my understanding is the xorg driver 
need KMS to run. I didn't see nouveau at all in your dmesg.

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

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:40 PM, James Simmons jsimm...@infradead.org wrote:

  I tested the revert: the boot screen did change the resolution
  (without it don't), but my PC still hangs. (using an nvidia 8800GT).
 
  Try my most recent patch. Where does it hang at? Any logs?
 
 
  With your patch, I can boot the system. But nouveau is not loaded.
  dmesg attached.
 

 Forget to mention: the revert makes first steps of boot look the same
 (change the resolution of the text)
 but with your patch, I see a big ugly ununtu logo, (I think that is
 because nouveau is not loaded)

 Is nouveau a module? Does X run? From my understanding is the xorg driver

I didn't modified any option, from the standard Ubuntu 10.10

 need KMS to run. I didn't see nouveau at all in your dmesg.

Exact. I mentioned this when I tested 'next' versions from last year.
The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Wed, Jan 12, 2011 at 5:32 AM, James Simmons jsimm...@infradead.org wrote:

 Okay. The nouveau driver also uses the pitch as well. It
 really should be using the pitch field from drm_framebuffer instead of the
 line_length from fb_fix_screeninfo. This patch is just to make sure this
 is the issue. I will submit another patch later that uses
 drm_fb_framebuffer's pitch field. As for the visual unfortunely their is
 no real mapping between drm and fbdev.

Why do you want to remove the drm_fb_helper_fill_fix() call? Quite
frankly, you're then replacing it with open-coding the function
partially:

 +       info-fix.visual = fb-depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
 +                FB_VISUAL_TRUECOLOR;
 +       info-fix.line_length = fb-pitch;
        drm_fb_helper_fill_var(info, nfbdev-helper, sizes-fb_width, 
 sizes-fb_height);

Which seems to be just a regression. Why not just call
drm_fb_helper_fill_fix() here like we used to?

IOW, I'm inclined to just do the revert. The fix clearly breaks
things, and now you're adding random parts of the function back rather
than just calling the fill_fix() function like things used to. Why?

The commit message in dfe63bb0ad98 doesn't support any of these hacks
- it just seems to say that drm_fb_helper_fill_fix() should also have
been called from setcolreg().

So why don't we just revert the commit and instead add that
drm_fb_helper_fill_fix() to setcolreg()?

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

Re: [git pull] drm for rc1

[James Simmons]

 IOW, I'm inclined to just do the revert. The fix clearly breaks
 things, and now you're adding random parts of the function back rather
 than just calling the fill_fix() function like things used to. Why?

Its not the final patch. I'm trying to get feedback on what broke exactly.

 The commit message in dfe63bb0ad98 doesn't support any of these hacks
 - it just seems to say that drm_fb_helper_fill_fix() should also have
 been called from setcolreg().

 So why don't we just revert the commit and instead add that
 drm_fb_helper_fill_fix() to setcolreg()?

Fine by me. The real problem is the nouveau driver is using the 
framebuffer device (fb_fillrect) before set_par is ever called.
Before calling set_par the framebuffer state is not defined.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[James Simmons]

 Am 12.01.2011 14:45, schrieb James Simmons:
  I tested the revert: the boot screen did change the resolution
  (without it don't), but my PC still hangs. (using an nvidia 8800GT).
  
  Try my most recent patch. Where does it hang at? Any logs?
 
 FYI, I just want to mention that with the latest git+the fix 
 X11 sometimes consumes 100% cpu for a long time. Dont know if
 this is a related problem or not.

I doubt they are related.

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

[git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds  wrote:
> The BUG_ON() that triggers is appended. And as mentioned, the jerky
> thing really seems to start happening in the exact same circumstance
> when this BUG_ON triggered.

Yes, that is the race in IRQ refcounting that I have an outstanding fix
for.

I've put the patches up on drm-intel-staging as I begin retesting them
before sending the pull request. In particular you need
01a03331e5fe91861937f8b8e72c259f5e9eae67.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes  
wrote:
> On Tue, 11 Jan 2011 11:25:39 -0800
> Linus Torvalds  wrote:
> 
> > On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes  > virtuousgeek.org> wrote:
> > >
> > > Have you tried reproducing it using xset dpms force off or similar?
> > 
> > That doesn't seem to do anything bad.
> > 
> > In fact, I think the second time it happened the screen never went
> > black - just the random photo thing was on. But no, forcing the screen
> > saver on doesn't do it either (ie pressing the "lock screen" icon and
> > waiting for a few pictures to cycle).
> > 
> > Maybe the screen just has to be inactive for a longer time: do you do
> > some dynamic "let's power things down if nothing is changing"?
> 
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh timers are much smaller though so it should
> be active anytime the CPU enters a deep sleep state.  The clock
> frequency changes in millisecond time too, you can check the status of
> that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
> 
> I wonder if re-enabling rc6 may have caused your issues?  That would be:
> 
> commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
> Author: Jesse Barnes 
> Date:   Wed Jan 5 12:01:24 2011 -0800
> 
> drm/i915: re-enable rc6 support for Ironlake+

We haven't actually got as far as that patch yet, that's waiting for a
suitable juncture to send the request. Now that the trees have converged I
can pick which patches need to go for rc1 and which can wait for -next.

Looking at the set of outstanding patch, my suspect would be the ring irq
refcounting which needed a fix and seems implicated by the error message.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Anca Emanuel]

Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others

[git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel  wrote:
> Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
> until is more stable ?

What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.

[git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
 wrote:
> On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes  
> wrote:
>>
>> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with 
>> out watermarking code iirc; apparently we're underflowing the display FIFO, 
>> causing all sorts of trouble. ?If it works before the pull of Dave's tree, 
>> can you bisect?
>
> There's no way to bisect this thing - it started happening after 2
> hours (first message at 8287.139375 seconds from boot, to be exact).
> So far only once, but that's possibly because I've been asleep for the
> last eight hours ;)
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
>
> And as mentioned, this is a regular machine, not one of my
> preproduction things that tend to have odd silicon or BIOSes.
> Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
> part of that machine is the silent case ;)
>
> Chris wrote:
>> Linus, is anything else kicked off upon powersaving? A screen saver or is
>> it just the blanking that triggers the mess?
>
> So I don't _know_ that it was the screen saver that triggered, but I
> do know that it started happening while I was out to pick up a kid
> from gymnastics. So the screen saver was pretty much the only thing
> going on apart from an idle desktop with a few terminals and chrome.
>
> And it's not even a 3D screen saver or anything graphically fancy,
> it's just the "show random photos" one (it eventually does blank too,
> but I think I've set the blanking interval to an hour or something).
> But compiz was on.
>
> ? ? ? ? ? ? ? ? ? ? ? ? Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
 wrote:
>
>  ... I'll test that drm-intel-staging commit.

Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kids around now, so more intense
screen saver testing is coming up..

   Linus

[git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 4:28 PM, Dave Airlie  wrote:
> On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes  
> wrote:
>> "Dave Airlie"  wrote:
>>
>>>On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
>>> wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie 
>>>wrote:
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

 ?...
 ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938],
>>>missed
 IRQ?
 ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068],
>>>missed
 IRQ?
 ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129],
>>>missed
 IRQ?
 ?...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have
>>>nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen
>>>saver,
 but who knows?) ?and have been happening constantly since. The
>>>machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.
>>>
>>>Okay I'll try and reproduce and curse Chris and Jesse, does booting
>>>with
>>>i915.powersave=0 help any?
>>>
>>>Dave.
>>
>> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with 
>> out watermarking code iirc; apparently we're underflowing the display FIFO, 
>> causing all sorts of trouble. ?If it works before the pull of Dave's tree, 
>> can you bisect?
>>
>
> I think he'd fixed them in the tree I pulled locally to test, I'm
> guessing this might be that we are running the Fedora userspace driver
> and you guys are all on master or something, which would mean some ABI
> guarantee got busted.
>
> I'm going to try a local test upgrade to 2.14.0 just to see.

Okay that didn't help, dead in similar times, evince with a few flood
maps from Brisbane seem to be a good trigger.

I'm not sure I'll be in a good place for bisection, need laptop to
keep track of disaster.

Dave.

[git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes  
wrote:
> "Dave Airlie"  wrote:
>
>>On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
>> wrote:
>>> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie 
>>wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support
>>>
>>> Lowlights: it's broken.
>>>
>>> I get millions of messages like:
>>>
>>> ?...
>>> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 30938, at 30938],
>>missed
>>> IRQ?
>>> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 31068, at 31068],
>>missed
>>> IRQ?
>>> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>>> timer elapsed... render ring idle [waiting on 31129, at 31129],
>>missed
>>> IRQ?
>>> ?...
>>>
>>> and everything is very choppy. I assume it's the power saving thing
>>> that broke again, but that's just a total random guess, I have
>>nothing
>>> to actually back that up with.
>>>
>>> It worked fine after boot, but those problems began at 8287.139375
>>> (about two hours after boot - it may have coincided with screen
>>saver,
>>> but who knows?) ?and have been happening constantly since. The
>>machine
>>> is not really usable, I'm writing this with annoying 2-second pauses
>>> every once in a while.
>>
>>Okay I'll try and reproduce and curse Chris and Jesse, does booting
>>with
>>i915.powersave=0 help any?
>>
>>Dave.
>
> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with 
> out watermarking code iirc; apparently we're underflowing the display FIFO, 
> causing all sorts of trouble. ?If it works before the pull of Dave's tree, 
> can you bisect?
>

I think he'd fixed them in the tree I pulled locally to test, I'm
guessing this might be that we are running the Fedora userspace driver
and you guys are all on master or something, which would mean some ABI
guarantee got busted.

I'm going to try a local test upgrade to 2.14.0 just to see.

Dave.

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
 wrote:
>
> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
> During startup the framebuffer shows only stripes and a blank
> screen after suspend/resume.
> I also see lots of TRAP messages. (see below).
> X11 seems to work fine though...

Can you try to bisect?

It's a *bit* easier to do if you start out at the drm merge, and only
bisect that part, ie

  MERGE=5b2eef966cb2ae307aa4ef1767f7307774bc96ca
  git bisect start
  git bisect bad $MERGE^2
  git bisect good $MERGE^1

(the above assumes that the merge itself isn't what caused the
problems) and that way you should only need to bisect through the
actual new DRM commits.

   Linus

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
 wrote:
>
> I'll test the merge, but I thought I'd send out this note already at
> this point, because I'm pretty sure this is it.

Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it wasn't actually the polling patch that turned the
BUG_ON() into a jerky experience. But I'll test that drm-intel-staging
commit.

  Linus

[git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie  wrote:
> On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
>  wrote:
>> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie  wrote:
>>> Highlights:
>>> core/drivers: add support for high precision vblank timestamps
>>> radeon: pageflipping support, Gen2 PCIE support
>>> nouveau: reworked VRAM and VM support
>>> intel: better ILK/SNB powersaving support, Full GTT support
>>
>> Lowlights: it's broken.
>>
>> I get millions of messages like:
>>
>> ?...
>> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
>> IRQ?
>> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
>> IRQ?
>> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
>> IRQ?
>> ?...
>>
>> and everything is very choppy. I assume it's the power saving thing
>> that broke again, but that's just a total random guess, I have nothing
>> to actually back that up with.
>>
>> It worked fine after boot, but those problems began at 8287.139375
>> (about two hours after boot - it may have coincided with screen saver,
>> but who knows?) ?and have been happening constantly since. The machine
>> is not really usable, I'm writing this with annoying 2-second pauses
>> every once in a while.
>
> Okay I'll try and reproduce and curse Chris and Jesse, does booting with
> i915.powersave=0 help any?

I've also noticed Chris has some more patches in drm-intel-next I
haven't got in this pull request.

I don't think he's sent me a pull request though so not telling how
stable they are.

Dave.

[git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
 wrote:
> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie  wrote:
>> Highlights:
>> core/drivers: add support for high precision vblank timestamps
>> radeon: pageflipping support, Gen2 PCIE support
>> nouveau: reworked VRAM and VM support
>> intel: better ILK/SNB powersaving support, Full GTT support
>
> Lowlights: it's broken.
>
> I get millions of messages like:
>
> ?...
> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
> IRQ?
> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
> IRQ?
> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
> IRQ?
> ?...
>
> and everything is very choppy. I assume it's the power saving thing
> that broke again, but that's just a total random guess, I have nothing
> to actually back that up with.
>
> It worked fine after boot, but those problems began at 8287.139375
> (about two hours after boot - it may have coincided with screen saver,
> but who knows?) ?and have been happening constantly since. The machine
> is not really usable, I'm writing this with annoying 2-second pauses
> every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting with
i915.powersave=0 help any?

Dave.

[git pull] drm for rc1

[Pavel Machek]

Hi!

> >>> Highlights:
> >>> core/drivers: add support for high precision vblank timestamps
> >>> radeon: pageflipping support, Gen2 PCIE support
> >>> nouveau: reworked VRAM and VM support
> >>> intel: better ILK/SNB powersaving support, Full GTT support
> >>
> >> Lowlights: it's broken.

Heh, at this point I expected Linus to complain about milion merges in
changelog...

> Arg.  It's been ok on my ILK systems, but Chris has found some
>issues with out watermarking code iirc; apparently we're underflowing
>the display FIFO, causing all sorts of trouble.  If it works before
>the pull of Dave's tree, can you bisect?

Watermarking code? What goes on there?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
 wrote:
>
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?

So since this is _almost_ reproducible for me, I tried bisecting it.

The bisection is a bit iffy, since it's not entirely clear how long I
need to wait for the screen saver to cause the problem, but sine I hit
a very similar issue while bisecting, I think it's a pretty solid
(partial) bisect.

What _seems_ to go on is that after commit b5ba177d8d71 ("drm/i915:
Poll for seqno completion if IRQ is disabled") I get that "very chunky
behavior". And _before_ that commit I actually get a BUG_ON(), and in
fact that bug-on does not happen during normal use, but does trigger
when the screen saver runs. So I think the old BUG_ON() is actually
the exact same case that then causes the jerky problem for me.

NOTE! I didn't do a full bisect. I did verify that commit b5ba177d8d71
does expose the bad behavior, and I also verified that a few commits
before that gets the BUG_ON, but there's something like three or four
commits in between that I didn't test. But we're literally talking
just three commits or so (eg commit 8d5203ca6253 gets that BUG_ON(),
and 71f4566084eb is marked as "good" too for me, so the only untested
commits are 9097eef024db and b13c2b96bf15).

I'll test the merge, but I thought I'd send out this note already at
this point, because I'm pretty sure this is it.

The BUG_ON() that triggers is appended. And as mentioned, the jerky
thing really seems to start happening in the exact same circumstance
when this BUG_ON triggered.

Linus

---
[  330.023447] [ cut here ]
[  330.025136] kernel BUG at drivers/gpu/drm/i915/intel_ringbuffer.c:354!
[  330.026758] invalid opcode:  [#1] PREEMPT SMP
[  330.028396] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[  330.030040] CPU 2
[  330.030049] Modules linked in: [last unloaded: scsi_wait_scan]
[  330.033313]
[  330.034929] Pid: 2723, comm: Xorg Not tainted
2.6.37-rc4-00295-g0cdab21 #16 P7H57D-V EVO/System Product Name
[  330.036581] RIP: 0010:[]  []
render_ring_put_irq+0x20/0x88
[  330.038266] RSP: 0018:88023e001cf8  EFLAGS: 00010246
[  330.039937] RAX:  RBX: 88023fcdc030 RCX: 
[  330.041607] RDX: 3736 RSI: 0001 RDI: 88023fcdc030
[  330.043277] RBP: 88023e001d18 R08: 88023fcdd84c R09: 
[  330.044917] R10: 88023e001cb8 R11: 88023e001cc8 R12: 88023fcdc000
[  330.046571] R13: 88023ff69000 R14: 88023fcdd84c R15: 88023fcdc118
[  330.048193] FS:  7fe1b6342860() GS:8800bd90()
knlGS:
[  330.049822] CS:  0010 DS:  ES:  CR0: 80050033
[  330.051450] CR2: 7f4379961000 CR3: 000229d41000 CR4: 06e0
[  330.053088] DR0:  DR1:  DR2: 
[  330.054726] DR3:  DR6: 0ff0 DR7: 0400
[  330.056364] Process Xorg (pid: 2723, threadinfo 88023e00,
task 880229db2c40)
[  330.057991] Stack:
[  330.059610]  88023fcdc030 88023fcdc000 26b7
88023fcdd84c
[  330.061255]  88023e001d98 812da704 88023e001e18
8802
[  330.062908]   880229db2c40 81051e35
88023e001d50
[  330.064566] Call Trace:
[  330.066202]  [] i915_gem_throttle_ioctl+0x163/0x1ac
[  330.067863]  [] ? autoremove_wake_function+0x0/0x34
[  330.069510]  [] drm_ioctl+0x290/0x35c
[  330.071136]  [] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.072769]  [] ? i915_gem_throttle_ioctl+0x0/0x1ac
[  330.074397]  [] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.076025]  [] ? _raw_spin_unlock_irq+0x2b/0x53
[  330.077651]  [] do_vfs_ioctl+0x4c1/0x502
[  330.079252]  [] ? fget_light+0x13a/0x31a
[  330.080845]  [] ? sysret_check+0x27/0x62
[  330.082416]  [] sys_ioctl+0x51/0x76
[  330.083964]  [] system_call_fastpath+0x16/0x1b
[  330.085501] Code: d7 f3 ab 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41
56 41 55 41 54 53 4c 8b 6f 18 41 83 bd e0 02 00 00 00 74 66 8b 47 60
85 c0 75 02 <0f> 0b ff c8 89 47 60 85 c0 75 54 49 8b 9d 98 05 00 00 4c
8d a3
[  330.087351] RIP  [] render_ring_put_irq+0x20/0x88
[  330.089039]  RSP 
[  330.099760] ---[ end trace acfb1e4669bf8ace ]---
[  330.376659] [drm:drm_release] *ERROR* Device busy: 1

[git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek  wrote:
> Hi!
> 
> > >>> Highlights:
> > >>> core/drivers: add support for high precision vblank timestamps
> > >>> radeon: pageflipping support, Gen2 PCIE support
> > >>> nouveau: reworked VRAM and VM support
> > >>> intel: better ILK/SNB powersaving support, Full GTT support
> > >>
> > >> Lowlights: it's broken.
> 
> Heh, at this point I expected Linus to complain about milion merges in
> changelog...

Applying bug fixes to one tree and pushing those to 2.6.37 and doing
feature work in another which also depend upon those same bug fixes...
The merges I felt were fairly infrequent, either after a pull request and
subsequent fast-forward of -fixes (so that -next was always a superset of
the current upstream rc) or I applied a patch to -fixes that would
conflict with -next. After those, I did an immediate merge to resolve the
conflict whilst the code was still fresh.

The whole point of trying to keep two trees intact is to be able to
perform continuous testing on both. No matter how hard I try not to, it
seems I always break Linus's machine.

> > Arg.  It's been ok on my ILK systems, but Chris has found some
> >issues with out watermarking code iirc; apparently we're underflowing
> >the display FIFO, causing all sorts of trouble.  If it works before
> >the pull of Dave's tree, can you bisect?
> 
> Watermarking code? What goes on there?

FIFO watermarks, they determine when the display fetches from the scanout
buffer to fill the pipe. If we run out of FIFO entries then the display
flickers at best, at worst we may hard hang the machine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Anca Emanuel]

With kernel 2.6.37-git5, my PC hangs.
( I have an nvidia 8800GT and nouveau )

Foto attached.
-- next part --
A non-text attachment was scrubbed...
Name: screen.JPG
Type: image/jpeg
Size: 106271 bytes
Desc: not available
URL: 

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes  
wrote:
>>
>> Maybe the screen just has to be inactive for a longer time: do you do
>> some dynamic "let's power things down if nothing is changing"?
>
> There are some timeouts, the FBC engine will recompress about once
> every 15s; the self-refresh timers are much smaller though so it should
> be active anytime the CPU enters a deep sleep state. ?The clock
> frequency changes in millisecond time too, you can check the status of
> that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I assume you meant "info", not "status". If so, that doesn't look all
that interesting:

  [torvalds at i5 linux]$ cat /sys/kernel/debug/dri/0/i915_drpc_info
  HD boost: no
  Boost freq: 0
  HW control enabled: no
  SW control enabled: no
  Gated voltage change: no
  Starting frequency: P0
  Max P-state: P0
  Min P-state: P0
  RS1 VID: 0
  RS2 VID: 38
  Render standby enabled: yes
  [torvalds at i5 linux]$ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo
  Requested P-state: 0
  Requested VID: 0
  Current VID: 37
  Current P-state: 0

(This is in the "working state" - I rebooted because I can't stand
working with a machine that feels like a 110baud terminal).

> I wonder if re-enabling rc6 may have caused your issues? ?That would be:
>
> commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a

I don't have this commit at all, it wasn't part of the merged series.

Linus

[git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds  wrote:

> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes  
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
> 
> That doesn't seem to do anything bad.
> 
> In fact, I think the second time it happened the screen never went
> black - just the random photo thing was on. But no, forcing the screen
> saver on doesn't do it either (ie pressing the "lock screen" icon and
> waiting for a few pictures to cycle).
> 
> Maybe the screen just has to be inactive for a longer time: do you do
> some dynamic "let's power things down if nothing is changing"?

There are some timeouts, the FBC engine will recompress about once
every 15s; the self-refresh timers are much smaller though so it should
be active anytime the CPU enters a deep sleep state.  The clock
frequency changes in millisecond time too, you can check the status of
that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I wonder if re-enabling rc6 may have caused your issues?  That would be:

commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
Author: Jesse Barnes 
Date:   Wed Jan 5 12:01:24 2011 -0800

drm/i915: re-enable rc6 support for Ironlake+

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes  
wrote:
>
> Have you tried reproducing it using xset dpms force off or similar?

That doesn't seem to do anything bad.

In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the screen
saver on doesn't do it either (ie pressing the "lock screen" icon and
waiting for a few pictures to cycle).

Maybe the screen just has to be inactive for a longer time: do you do
some dynamic "let's power things down if nothing is changing"?

   Linus

[git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:00:13 -0800
Linus Torvalds  wrote:

> On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
>  wrote:
> >
> > But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> > this message on this machine before.
> 
> .. and it's not a fluke. It happened again, and once more while I was
> away from the machine and the screen saver was running. So it does
> seem to have something to do with power-saving modes or something.

Have you tried reproducing it using xset dpms force off or similar?

Chris, what are you using to trigger the watermark related issues
you've found?

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
 wrote:
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.

.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen saver was running. So it does
seem to have something to do with power-saving modes or something.

 Linus

[git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:51:40 +1000, Dave Airlie  wrote:
> On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie  wrote:
> > On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
> >  wrote:
> >> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie  wrote:
> >>> Highlights:
> >>> core/drivers: add support for high precision vblank timestamps
> >>> radeon: pageflipping support, Gen2 PCIE support
> >>> nouveau: reworked VRAM and VM support
> >>> intel: better ILK/SNB powersaving support, Full GTT support
> >>
> >> Lowlights: it's broken.
> >>
> >> I get millions of messages like:
> >>
> >> ??...
> >> ??[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 30938, at 30938], missed
> >> IRQ?
> >> ??[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 31068, at 31068], missed
> >> IRQ?
> >> ??[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
> >> timer elapsed... render ring idle [waiting on 31129, at 31129], missed
> >> IRQ?
> >> ??...
> >>
> >> and everything is very choppy. I assume it's the power saving thing
> >> that broke again, but that's just a total random guess, I have nothing
> >> to actually back that up with.
> >>
> >> It worked fine after boot, but those problems began at 8287.139375
> >> (about two hours after boot - it may have coincided with screen saver,
> >> but who knows?) ??and have been happening constantly since. The machine
> >> is not really usable, I'm writing this with annoying 2-second pauses
> >> every once in a while.
> >
> > Okay I'll try and reproduce and curse Chris and Jesse, does booting with
> > i915.powersave=0 help any?
> 
> I've also noticed Chris has some more patches in drm-intel-next I
> haven't got in this pull request.
> 
> I don't think he's sent me a pull request though so not telling how
> stable they are.

Yes, there are a few pending fixes. I've been waiting on feedback from
testing for some more before asking for a pull. In part because we have
some more eDP fixes, courtesy of Jesse, that makes everyone but Jim Getty
happy.

However, I've not seen anything like this so I doubt that d-i-n contains
the fix.

Dave, is yours related to the DMAR errors that is plaguing your systems?

Linus, is anything else kicked off upon powersaving? A screen saver or is
it just the blanking that triggers the mess?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm for rc1

[Linus Torvalds]

On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes  
wrote:
>
> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with 
> out watermarking code iirc; apparently we're underflowing the display FIFO, 
> causing all sorts of trouble. ?If it works before the pull of Dave's tree, 
> can you bisect?

There's no way to bisect this thing - it started happening after 2
hours (first message at 8287.139375 seconds from boot, to be exact).
So far only once, but that's possibly because I've been asleep for the
last eight hours ;)

But yes, it worked before pulling Dave's tree, IOW, I haven't seen
this message on this machine before.

And as mentioned, this is a regular machine, not one of my
preproduction things that tend to have odd silicon or BIOSes.
Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
part of that machine is the silent case ;)

Chris wrote:
> Linus, is anything else kicked off upon powersaving? A screen saver or is
> it just the blanking that triggers the mess?

So I don't _know_ that it was the screen saver that triggered, but I
do know that it started happening while I was out to pick up a kid
from gymnastics. So the screen saver was pretty much the only thing
going on apart from an idle desktop with a few terminals and chrome.

And it's not even a 3D screen saver or anything graphically fancy,
it's just the "show random photos" one (it eventually does blank too,
but I think I've set the blanking interval to an hour or something).
But compiz was on.

 Linus

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:51:40 +1000, Dave Airlie airl...@gmail.com wrote:
 On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie airl...@gmail.com wrote:
  On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
  torva...@linux-foundation.org wrote:
  On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie wrote:
  Highlights:
  core/drivers: add support for high precision vblank timestamps
  radeon: pageflipping support, Gen2 PCIE support
  nouveau: reworked VRAM and VM support
  intel: better ILK/SNB powersaving support, Full GTT support
 
  Lowlights: it's broken.
 
  I get millions of messages like:
 
   ...
   [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 30938, at 30938], missed
  IRQ?
   [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 31068, at 31068], missed
  IRQ?
   [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
  timer elapsed... render ring idle [waiting on 31129, at 31129], missed
  IRQ?
   ...
 
  and everything is very choppy. I assume it's the power saving thing
  that broke again, but that's just a total random guess, I have nothing
  to actually back that up with.
 
  It worked fine after boot, but those problems began at 8287.139375
  (about two hours after boot - it may have coincided with screen saver,
  but who knows?)  and have been happening constantly since. The machine
  is not really usable, I'm writing this with annoying 2-second pauses
  every once in a while.
 
  Okay I'll try and reproduce and curse Chris and Jesse, does booting with
  i915.powersave=0 help any?
 
 I've also noticed Chris has some more patches in drm-intel-next I
 haven't got in this pull request.
 
 I don't think he's sent me a pull request though so not telling how
 stable they are.

Yes, there are a few pending fixes. I've been waiting on feedback from
testing for some more before asking for a pull. In part because we have
some more eDP fixes, courtesy of Jesse, that makes everyone but Jim Getty
happy.

However, I've not seen anything like this so I doubt that d-i-n contains
the fix.

Dave, is yours related to the DMAR errors that is plaguing your systems?

Linus, is anything else kicked off upon powersaving? A screen saver or is
it just the blanking that triggers the mess?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Pavel Machek]

Hi!

  Highlights:
  core/drivers: add support for high precision vblank timestamps
  radeon: pageflipping support, Gen2 PCIE support
  nouveau: reworked VRAM and VM support
  intel: better ILK/SNB powersaving support, Full GTT support
 
  Lowlights: it's broken.

Heh, at this point I expected Linus to complain about milion merges in
changelog...

 Arg.  It's been ok on my ILK systems, but Chris has found some
issues with out watermarking code iirc; apparently we're underflowing
the display FIFO, causing all sorts of trouble.  If it works before
the pull of Dave's tree, can you bisect?

Watermarking code? What goes on there?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:33:29 +0100, Pavel Machek pa...@ucw.cz wrote:
 Hi!
 
   Highlights:
   core/drivers: add support for high precision vblank timestamps
   radeon: pageflipping support, Gen2 PCIE support
   nouveau: reworked VRAM and VM support
   intel: better ILK/SNB powersaving support, Full GTT support
  
   Lowlights: it's broken.
 
 Heh, at this point I expected Linus to complain about milion merges in
 changelog...

Applying bug fixes to one tree and pushing those to 2.6.37 and doing
feature work in another which also depend upon those same bug fixes...
The merges I felt were fairly infrequent, either after a pull request and
subsequent fast-forward of -fixes (so that -next was always a superset of
the current upstream rc) or I applied a patch to -fixes that would
conflict with -next. After those, I did an immediate merge to resolve the
conflict whilst the code was still fresh.

The whole point of trying to keep two trees intact is to be able to
perform continuous testing on both. No matter how hard I try not to, it
seems I always break Linus's machine.

  Arg.  It's been ok on my ILK systems, but Chris has found some
 issues with out watermarking code iirc; apparently we're underflowing
 the display FIFO, causing all sorts of trouble.  If it works before
 the pull of Dave's tree, can you bisect?
 
 Watermarking code? What goes on there?

FIFO watermarks, they determine when the display fetches from the scanout
buffer to fill the pipe. If we run out of FIFO entries then the display
flickers at best, at worst we may hard hang the machine.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:

 Arg.  It's been ok on my ILK systems, but Chris has found some issues with 
 out watermarking code iirc; apparently we're underflowing the display FIFO, 
 causing all sorts of trouble.  If it works before the pull of Dave's tree, 
 can you bisect?

There's no way to bisect this thing - it started happening after 2
hours (first message at 8287.139375 seconds from boot, to be exact).
So far only once, but that's possibly because I've been asleep for the
last eight hours ;)

But yes, it worked before pulling Dave's tree, IOW, I haven't seen
this message on this machine before.

And as mentioned, this is a regular machine, not one of my
preproduction things that tend to have odd silicon or BIOSes.
Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
part of that machine is the silent case ;)

Chris wrote:
 Linus, is anything else kicked off upon powersaving? A screen saver or is
 it just the blanking that triggers the mess?

So I don't _know_ that it was the screen saver that triggered, but I
do know that it started happening while I was out to pick up a kid
from gymnastics. So the screen saver was pretty much the only thing
going on apart from an idle desktop with a few terminals and chrome.

And it's not even a 3D screen saver or anything graphically fancy,
it's just the show random photos one (it eventually does blank too,
but I think I've set the blanking interval to an hour or something).
But compiz was on.

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

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:

 Arg.  It's been ok on my ILK systems, but Chris has found some issues with 
 out watermarking code iirc; apparently we're underflowing the display FIFO, 
 causing all sorts of trouble.  If it works before the pull of Dave's tree, 
 can you bisect?

 There's no way to bisect this thing - it started happening after 2
 hours (first message at 8287.139375 seconds from boot, to be exact).
 So far only once, but that's possibly because I've been asleep for the
 last eight hours ;)

 But yes, it worked before pulling Dave's tree, IOW, I haven't seen
 this message on this machine before.

 And as mentioned, this is a regular machine, not one of my
 preproduction things that tend to have odd silicon or BIOSes.
 Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
 part of that machine is the silent case ;)

 Chris wrote:
 Linus, is anything else kicked off upon powersaving? A screen saver or is
 it just the blanking that triggers the mess?

 So I don't _know_ that it was the screen saver that triggered, but I
 do know that it started happening while I was out to pick up a kid
 from gymnastics. So the screen saver was pretty much the only thing
 going on apart from an idle desktop with a few terminals and chrome.

 And it's not even a 3D screen saver or anything graphically fancy,
 it's just the show random photos one (it eventually does blank too,
 but I think I've set the blanking interval to an hour or something).
 But compiz was on.

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


Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel anca.eman...@gmail.com wrote:
 Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
 until is more stable ?

What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 But yes, it worked before pulling Dave's tree, IOW, I haven't seen
 this message on this machine before.

.. and it's not a fluke. It happened again, and once more while I was
away from the machine and the screen saver was running. So it does
seem to have something to do with power-saving modes or something.

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

Re: [git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:00:13 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Tue, Jan 11, 2011 at 8:01 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 
  But yes, it worked before pulling Dave's tree, IOW, I haven't seen
  this message on this machine before.
 
 .. and it's not a fluke. It happened again, and once more while I was
 away from the machine and the screen saver was running. So it does
 seem to have something to do with power-saving modes or something.

Have you tried reproducing it using xset dpms force off or similar?

Chris, what are you using to trigger the watermark related issues
you've found?

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:

 Have you tried reproducing it using xset dpms force off or similar?

That doesn't seem to do anything bad.

In fact, I think the second time it happened the screen never went
black - just the random photo thing was on. But no, forcing the screen
saver on doesn't do it either (ie pressing the lock screen icon and
waiting for a few pictures to cycle).

Maybe the screen just has to be inactive for a longer time: do you do
some dynamic let's power things down if nothing is changing?

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

Re: [git pull] drm for rc1

[Jesse Barnes]

On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds torva...@linux-foundation.org wrote:

 On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 
  Have you tried reproducing it using xset dpms force off or similar?
 
 That doesn't seem to do anything bad.
 
 In fact, I think the second time it happened the screen never went
 black - just the random photo thing was on. But no, forcing the screen
 saver on doesn't do it either (ie pressing the lock screen icon and
 waiting for a few pictures to cycle).
 
 Maybe the screen just has to be inactive for a longer time: do you do
 some dynamic let's power things down if nothing is changing?

There are some timeouts, the FBC engine will recompress about once
every 15s; the self-refresh timers are much smaller though so it should
be active anytime the CPU enters a deep sleep state.  The clock
frequency changes in millisecond time too, you can check the status of
that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I wonder if re-enabling rc6 may have caused your issues?  That would be:

commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Wed Jan 5 12:01:24 2011 -0800

drm/i915: re-enable rc6 support for Ironlake+

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:45 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:

 Maybe the screen just has to be inactive for a longer time: do you do
 some dynamic let's power things down if nothing is changing?

 There are some timeouts, the FBC engine will recompress about once
 every 15s; the self-refresh timers are much smaller though so it should
 be active anytime the CPU enters a deep sleep state.  The clock
 frequency changes in millisecond time too, you can check the status of
 that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.

I assume you meant info, not status. If so, that doesn't look all
that interesting:

  [torva...@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_drpc_info
  HD boost: no
  Boost freq: 0
  HW control enabled: no
  SW control enabled: no
  Gated voltage change: no
  Starting frequency: P0
  Max P-state: P0
  Min P-state: P0
  RS1 VID: 0
  RS2 VID: 38
  Render standby enabled: yes
  [torva...@i5 linux]$ cat /sys/kernel/debug/dri/0/i915_cur_delayinfo
  Requested P-state: 0
  Requested VID: 0
  Current VID: 37
  Current P-state: 0

(This is in the working state - I rebooted because I can't stand
working with a machine that feels like a 110baud terminal).

 I wonder if re-enabling rc6 may have caused your issues?  That would be:

 commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a

I don't have this commit at all, it wasn't part of the merged series.

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

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 11:45:05 -0800, Jesse Barnes jbar...@virtuousgeek.org 
wrote:
 On Tue, 11 Jan 2011 11:25:39 -0800
 Linus Torvalds torva...@linux-foundation.org wrote:
 
  On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org 
  wrote:
  
   Have you tried reproducing it using xset dpms force off or similar?
  
  That doesn't seem to do anything bad.
  
  In fact, I think the second time it happened the screen never went
  black - just the random photo thing was on. But no, forcing the screen
  saver on doesn't do it either (ie pressing the lock screen icon and
  waiting for a few pictures to cycle).
  
  Maybe the screen just has to be inactive for a longer time: do you do
  some dynamic let's power things down if nothing is changing?
 
 There are some timeouts, the FBC engine will recompress about once
 every 15s; the self-refresh timers are much smaller though so it should
 be active anytime the CPU enters a deep sleep state.  The clock
 frequency changes in millisecond time too, you can check the status of
 that in /sys/kernel/debug/dri/0/i915_drpc_status and i915_cur_delayinfo.
 
 I wonder if re-enabling rc6 may have caused your issues?  That would be:
 
 commit 29a15061ff5df5bf9bf49c05c17f41eb2807a55a
 Author: Jesse Barnes jbar...@virtuousgeek.org
 Date:   Wed Jan 5 12:01:24 2011 -0800
 
 drm/i915: re-enable rc6 support for Ironlake+

We haven't actually got as far as that patch yet, that's waiting for a
suitable juncture to send the request. Now that the trees have converged I
can pick which patches need to go for rc1 and which can wait for -next.

Looking at the set of outstanding patch, my suspect would be the ring irq
refcounting which needed a fix and seems implicated by the error message.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 11:25 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 Maybe the screen just has to be inactive for a longer time: do you do
 some dynamic let's power things down if nothing is changing?

So since this is _almost_ reproducible for me, I tried bisecting it.

The bisection is a bit iffy, since it's not entirely clear how long I
need to wait for the screen saver to cause the problem, but sine I hit
a very similar issue while bisecting, I think it's a pretty solid
(partial) bisect.

What _seems_ to go on is that after commit b5ba177d8d71 (drm/i915:
Poll for seqno completion if IRQ is disabled) I get that very chunky
behavior. And _before_ that commit I actually get a BUG_ON(), and in
fact that bug-on does not happen during normal use, but does trigger
when the screen saver runs. So I think the old BUG_ON() is actually
the exact same case that then causes the jerky problem for me.

NOTE! I didn't do a full bisect. I did verify that commit b5ba177d8d71
does expose the bad behavior, and I also verified that a few commits
before that gets the BUG_ON, but there's something like three or four
commits in between that I didn't test. But we're literally talking
just three commits or so (eg commit 8d5203ca6253 gets that BUG_ON(),
and 71f4566084eb is marked as good too for me, so the only untested
commits are 9097eef024db and b13c2b96bf15).

I'll test the merge, but I thought I'd send out this note already at
this point, because I'm pretty sure this is it.

The BUG_ON() that triggers is appended. And as mentioned, the jerky
thing really seems to start happening in the exact same circumstance
when this BUG_ON triggered.

Linus

---
[  330.023447] [ cut here ]
[  330.025136] kernel BUG at drivers/gpu/drm/i915/intel_ringbuffer.c:354!
[  330.026758] invalid opcode:  [#1] PREEMPT SMP
[  330.028396] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[  330.030040] CPU 2
[  330.030049] Modules linked in: [last unloaded: scsi_wait_scan]
[  330.033313]
[  330.034929] Pid: 2723, comm: Xorg Not tainted
2.6.37-rc4-00295-g0cdab21 #16 P7H57D-V EVO/System Product Name
[  330.036581] RIP: 0010:[812f1cbd]  [812f1cbd]
render_ring_put_irq+0x20/0x88
[  330.038266] RSP: 0018:88023e001cf8  EFLAGS: 00010246
[  330.039937] RAX:  RBX: 88023fcdc030 RCX: 
[  330.041607] RDX: 3736 RSI: 0001 RDI: 88023fcdc030
[  330.043277] RBP: 88023e001d18 R08: 88023fcdd84c R09: 
[  330.044917] R10: 88023e001cb8 R11: 88023e001cc8 R12: 88023fcdc000
[  330.046571] R13: 88023ff69000 R14: 88023fcdd84c R15: 88023fcdc118
[  330.048193] FS:  7fe1b6342860() GS:8800bd90()
knlGS:
[  330.049822] CS:  0010 DS:  ES:  CR0: 80050033
[  330.051450] CR2: 7f4379961000 CR3: 000229d41000 CR4: 06e0
[  330.053088] DR0:  DR1:  DR2: 
[  330.054726] DR3:  DR6: 0ff0 DR7: 0400
[  330.056364] Process Xorg (pid: 2723, threadinfo 88023e00,
task 880229db2c40)
[  330.057991] Stack:
[  330.059610]  88023fcdc030 88023fcdc000 26b7
88023fcdd84c
[  330.061255]  88023e001d98 812da704 88023e001e18
8802
[  330.062908]   880229db2c40 81051e35
88023e001d50
[  330.064566] Call Trace:
[  330.066202]  [812da704] i915_gem_throttle_ioctl+0x163/0x1ac
[  330.067863]  [81051e35] ? autoremove_wake_function+0x0/0x34
[  330.069510]  [812ba08f] drm_ioctl+0x290/0x35c
[  330.071136]  [81054f24] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.072769]  [812da5a1] ? i915_gem_throttle_ioctl+0x0/0x1ac
[  330.074397]  [81054f24] ? lock_hrtimer_base.clone.29+0x24/0x48
[  330.076025]  [8153c02c] ? _raw_spin_unlock_irq+0x2b/0x53
[  330.077651]  [810d2ed9] do_vfs_ioctl+0x4c1/0x502
[  330.079252]  [810c56cd] ? fget_light+0x13a/0x31a
[  330.080845]  [8100202c] ? sysret_check+0x27/0x62
[  330.082416]  [810d2f6b] sys_ioctl+0x51/0x76
[  330.083964]  [81001ffb] system_call_fastpath+0x16/0x1b
[  330.085501] Code: d7 f3 ab 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41
56 41 55 41 54 53 4c 8b 6f 18 41 83 bd e0 02 00 00 00 74 66 8b 47 60
85 c0 75 02 0f 0b ff c8 89 47 60 85 c0 75 54 49 8b 9d 98 05 00 00 4c
8d a3
[  330.087351] RIP  [812f1cbd] render_ring_put_irq+0x20/0x88
[  330.089039]  RSP 88023e001cf8
[  330.099760] ---[ end trace acfb1e4669bf8ace ]---
[  330.376659] [drm:drm_release] *ERROR* Device busy: 1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Chris Wilson]

On Tue, 11 Jan 2011 14:16:54 -0800, Linus Torvalds 
torva...@linux-foundation.org wrote:
 The BUG_ON() that triggers is appended. And as mentioned, the jerky
 thing really seems to start happening in the exact same circumstance
 when this BUG_ON triggered.

Yes, that is the race in IRQ refcounting that I have an outstanding fix
for.

I've put the patches up on drm-intel-staging as I begin retesting them
before sending the pull request. In particular you need
01a03331e5fe91861937f8b8e72c259f5e9eae67.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:

 I'll test the merge, but I thought I'd send out this note already at
 this point, because I'm pretty sure this is it.

Hmm. The merge already has the *ERROR* Hangcheck (together with jerky
behavior), so it wasn't actually the polling patch that turned the
BUG_ON() into a jerky experience. But I'll test that drm-intel-staging
commit.

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

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
borntrae...@de.ibm.com wrote:

 Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
 compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
 During startup the framebuffer shows only stripes and a blank
 screen after suspend/resume.
 I also see lots of TRAP messages. (see below).
 X11 seems to work fine though...

Can you try to bisect?

It's a *bit* easier to do if you start out at the drm merge, and only
bisect that part, ie

  MERGE=5b2eef966cb2ae307aa4ef1767f7307774bc96ca
  git bisect start
  git bisect bad $MERGE^2
  git bisect good $MERGE^1

(the above assumes that the merge itself isn't what caused the
problems) and that way you should only need to bisect through the
actual new DRM commits.

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

Re: [git pull] drm for rc1

[Christian Borntraeger]

Am 10.01.2011 23:59, schrieb Dave Airlie:
 
 Hi Linus,
 
 non-drm changes:
 one kref change we needed that went on list with no comments
 
 New hardware:
 radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
 nouveau: Fermi acceleration support (requires external fw for now)
 
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support
 
 There are also some switcheroo patches to further improve it, though I 
 have a later patch blocking on an x86 platform driver for the nvidia/intel 
 switcher.
 
 Dave.

Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible 
controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
During startup the framebuffer shows only stripes and a blank
screen after suspend/resume.
I also see lots of TRAP messages. (see below).
X11 seems to work fine though...

$ dmesg | grep drm
[0.520906] [drm] Initialized drm 1.1.0 20060810
[0.521200] [drm] radeon defaulting to kernel modesetting.
[0.521416] [drm] radeon kernel modesetting enabled.
[0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp 
module!
[0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x084c00a2)
[0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from 
PRAMIN
[0.641884] [drm] nouveau :01:00.0: ... appears to be valid
[0.642058] [drm] nouveau :01:00.0: BIT BIOS found
[0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00
[0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0   


[0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found  


[0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block 
version 4.0 
   
[0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034   


[0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028   


[0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030   


[0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e    


[0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 
2   
 
[0.643836] [drm] nouveau :01:00.0:   0: 0x0040: type 0x40 idx 0 tag 
0xff
[0.644089] [drm] nouveau :01:00.0:   1: 0x0100: type 0x00 idx 1 tag 
0xff
[0.644317] [drm] nouveau :01:00.0:   2: 0x1231: type 0x31 idx 2 tag 
0x07
[0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDEBB
[0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE208
[0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEC55
[0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xED47
[0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xEF7A
[0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xEFDF
[0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met 
after 20ms, skipping following opcodes
[0.775483] [drm] nouveau :01:00.0: 3 available performance level(s)
[0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 
338MHz voltage 1150mV fanspeed 100%
[0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 
550MHz voltage 1150mV fanspeed 100%
[0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 
950MHz voltage 1200mV fanspeed 100%
[0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 
550MHz voltage 1150mV
[0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM
[0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.889565] [drm] No driver support for vblank timestamp query.
[0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, 
bo 88013af63400
[1.071842] [drm] nouveau :01:00.0: PGRAPH 

Re: [git pull] drm for rc1

[Linus Torvalds]

On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
torva...@linux-foundation.org wrote:

  ... I'll test that drm-intel-staging commit.

Initial testing _seems_ to confirm that merging drm-intel-staging gets
rid of the problem. But I haven't spent a whole lot of time in the
screen saver. Will start driving kids around now, so more intense
screen saver testing is coming up..

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

Re: [git pull] drm for rc1

[Dave Airlie]

On Wed, Jan 12, 2011 at 11:36 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Tue, Jan 11, 2011 at 3:01 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:

  ... I'll test that drm-intel-staging commit.

 Initial testing _seems_ to confirm that merging drm-intel-staging gets
 rid of the problem. But I haven't spent a whole lot of time in the
 screen saver. Will start driving kids around now, so more intense
 screen saver testing is coming up..

Its looking good here, I've pushed a drm-fixes branch with what Chris
sent me + a couple of i915/iommu fixes to my repo,

I'm going to run it on my laptop for a few more hours then I'll send
you a pull req, but none of the triggers I had yesterday seem to take
it down.

Dave.


                   Linus

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

[git pull] drm for rc1

[Dave Airlie]

Hi Linus,

non-drm changes:
one kref change we needed that went on list with no comments

New hardware:
radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
nouveau: Fermi acceleration support (requires external fw for now)

Highlights:
core/drivers: add support for high precision vblank timestamps
radeon: pageflipping support, Gen2 PCIE support
nouveau: reworked VRAM and VM support
intel: better ILK/SNB powersaving support, Full GTT support

There are also some switcheroo patches to further improve it, though I 
have a later patch blocking on an x86 platform driver for the nvidia/intel 
switcher.

Dave.

The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:

  Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (63):
  drm/radeon/kms: add pageflip ioctl support (v3)
  drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
  drm/radeon/kms: upstream ObjectID.h updates
  drm/radeon/kms: upstream atombios.h updates
  drm/radeon/kms: upstream power table updates
  drm/radeon/kms: add new family id for AMD Ontario APUs
  drm/radeon/kms: atom changes for DCE4.1 devices
  drm/radeon/kms: Add support for external encoders on fusion APUs
  drm/radeon/kms: add support for ss overrides on Fusion APUs
  drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
  drm/radeon/kms: MC setup changes for fusion APUs
  drm/radeon/kms: evergreen.c updates for fusion
  drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
  drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
  drm/radeon/kms: add thermal sensor support for fusion APUs
  drm/radeon/kms: add bo blit support for Ontario fusion APUs
  drm/radeon/kms: refactor atombios power state fetching
  drm/radeon/kms: add power table parsing support for Ontario fusion APUs
  drm/radeon/kms: enable MSIs on fusion APUs
  drm/radeon/kms: add Ontario Fusion APU pci ids
  drm/radeon/kms: add Ontario APU ucode loading support
  drm/radeon/kms: improve pflip precision on r1xx-r4xx
  drm/radeon/kms: fix vram start calculation on ontario (v2)
  drm/radeon/kms: properly print ontario chip id
  drm/radeon/kms: fix DCE4.1 dig routing (v2)
  drm/radeon/kms/atom: clean up op_mask handler
  drm/radeon/kms: use LCD physical size from vbios tables if available
  drm/radeon/kms: parse the extended LCD info block
  drm/radeon/kms: disable bo moves using the blitter
  drm/radeon/kms: implement gpu lockup check for evergreen
  drm/radeon/kms: adjust quirk for acer laptop
  drm/radeon/kms: add quirk for Mac Radeon HD 2600 card
  drm/radeon/kms: add pcie get/set lane support for r6xx/r7xx/evergreen
  drm/radeon/kms: add support for gen2 pcie link speeds
  drm/radeon/kms: set the MSB of the HDP slice size
  drm/radeon/kms: fix some typos in evergreen pm4 defines
  drm/radeon/kms: clean up ASIC_IS_DCE41() macro
  drm/radeon/kms: add NI chip families
  drm/radeon/kms: update display watermark calculations for DCE5
  drm/radeon/kms: DCE5 supports 16k display surfaces
  drm/radeon/kms: DCE5 atom SetPixelClock updates
  drm/radeon/kms: DCE5 atom spread spectrum updates
  drm/radeon/kms: DCE5 atom transmitter control updates
  drm/radeon/kms: DCE5 atom dig encoder updates
  drm/radeon/kms: dac dpms updates for DCE5
  drm/radeon/kms: dvo dpms updates for DCE5
  drm/radeon/kms: parse DCE5 encoder caps when setting up encoders
  drm/radeon/kms: handle NI thermal controller
  drm/radeon/kms: add disabled vbios accessor for NI asics
  drm/radeon/kms: fill gpu init for NI asics
  drm/radeon/kms: add backend map workaround for barts
  drm/radeon/kms: adjust default clock/vddc tracking for pm on DCE5
  drm/radeon/kms: always use writeback/events for fences on NI
  drm/radeon/kms: add bo blit support for NI
  drm/radeon/kms: add ni_reg.h
  drm/radeon/kms: add support for DCE5 display LUTs
  drm/radeon/kms: add ucode loader for NI
  drm/radeon/kms/ni: load default sclk/mclk/vddc at pm init
  drm/radeon/kms: add radeon_asic struct for NI asics
  drm/radeon/kms: don't enable pcie gen2 on NI yet
  drm/radeon/kms: add NI pci ids
  drm/radeon/kms: only enable hdmi features if the monitor supports audio
  drm/radeon/kms: disable underscan by default

Ben Hutchings (1):
  drm/nouveau: Only select ACPI_VIDEO if its dependencies are met

Ben Skeggs (91):
  drm/nouveau: tidy fifo swmthd handler a little
  drm/nouveau: disallow fbcon accel if running in interrupt context
  drm/nouveau: add per-channel mutex, use to lock access to drm's channel
  drm/nouveau: add more fine-grained locking to channel list + structures
  

[git pull] drm for rc1

[Jesse Barnes]

"Dave Airlie"  wrote:

>On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
> wrote:
>> On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie 
>wrote:
>>> Highlights:
>>> core/drivers: add support for high precision vblank timestamps
>>> radeon: pageflipping support, Gen2 PCIE support
>>> nouveau: reworked VRAM and VM support
>>> intel: better ILK/SNB powersaving support, Full GTT support
>>
>> Lowlights: it's broken.
>>
>> I get millions of messages like:
>>
>> ?...
>> ?[ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 30938, at 30938],
>missed
>> IRQ?
>> ?[ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31068, at 31068],
>missed
>> IRQ?
>> ?[ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
>> timer elapsed... render ring idle [waiting on 31129, at 31129],
>missed
>> IRQ?
>> ?...
>>
>> and everything is very choppy. I assume it's the power saving thing
>> that broke again, but that's just a total random guess, I have
>nothing
>> to actually back that up with.
>>
>> It worked fine after boot, but those problems began at 8287.139375
>> (about two hours after boot - it may have coincided with screen
>saver,
>> but who knows?) ?and have been happening constantly since. The
>machine
>> is not really usable, I'm writing this with annoying 2-second pauses
>> every once in a while.
>
>Okay I'll try and reproduce and curse Chris and Jesse, does booting
>with
>i915.powersave=0 help any?
>
>Dave.

Arg.  It's been ok on my ILK systems, but Chris has found some issues with out 
watermarking code iirc; apparently we're underflowing the display FIFO, causing 
all sorts of trouble.  If it works before the pull of Dave's tree, can you 
bisect?

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm for rc1

[Linus Torvalds]

On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie  wrote:
> Highlights:
> core/drivers: add support for high precision vblank timestamps
> radeon: pageflipping support, Gen2 PCIE support
> nouveau: reworked VRAM and VM support
> intel: better ILK/SNB powersaving support, Full GTT support

Lowlights: it's broken.

I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 30938, at 30938], missed
IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 31068, at 31068], missed
IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 31129, at 31129], missed
IRQ?
  ...

and everything is very choppy. I assume it's the power saving thing
that broke again, but that's just a total random guess, I have nothing
to actually back that up with.

It worked fine after boot, but those problems began at 8287.139375
(about two hours after boot - it may have coincided with screen saver,
but who knows?)  and have been happening constantly since. The machine
is not really usable, I'm writing this with annoying 2-second pauses
every once in a while.

This is a regular Core i5-670 with up-to-date Fedora-14, fwiw. Not my
sandybridge.

  Linus

[git pull] drm for rc1

[Dave Airlie]

Hi Linus,

non-drm changes:
one kref change we needed that went on list with no comments

New hardware:
radeon: add support for Fusion APUs and Radeon HD6xxx chipsets
nouveau: Fermi acceleration support (requires external fw for now)

Highlights:
core/drivers: add support for high precision vblank timestamps
radeon: pageflipping support, Gen2 PCIE support
nouveau: reworked VRAM and VM support
intel: better ILK/SNB powersaving support, Full GTT support

There are also some switcheroo patches to further improve it, though I 
have a later patch blocking on an x86 platform driver for the nvidia/intel 
switcher.

Dave.

The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:

  Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (63):
  drm/radeon/kms: add pageflip ioctl support (v3)
  drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
  drm/radeon/kms: upstream ObjectID.h updates
  drm/radeon/kms: upstream atombios.h updates
  drm/radeon/kms: upstream power table updates
  drm/radeon/kms: add new family id for AMD Ontario APUs
  drm/radeon/kms: atom changes for DCE4.1 devices
  drm/radeon/kms: Add support for external encoders on fusion APUs
  drm/radeon/kms: add support for ss overrides on Fusion APUs
  drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function
  drm/radeon/kms: MC setup changes for fusion APUs
  drm/radeon/kms: evergreen.c updates for fusion
  drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
  drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs
  drm/radeon/kms: add thermal sensor support for fusion APUs
  drm/radeon/kms: add bo blit support for Ontario fusion APUs
  drm/radeon/kms: refactor atombios power state fetching
  drm/radeon/kms: add power table parsing support for Ontario fusion APUs
  drm/radeon/kms: enable MSIs on fusion APUs
  drm/radeon/kms: add Ontario Fusion APU pci ids
  drm/radeon/kms: add Ontario APU ucode loading support
  drm/radeon/kms: improve pflip precision on r1xx-r4xx
  drm/radeon/kms: fix vram start calculation on ontario (v2)
  drm/radeon/kms: properly print ontario chip id
  drm/radeon/kms: fix DCE4.1 dig routing (v2)
  drm/radeon/kms/atom: clean up op_mask handler
  drm/radeon/kms: use LCD physical size from vbios tables if available
  drm/radeon/kms: parse the extended LCD info block
  drm/radeon/kms: disable bo moves using the blitter
  drm/radeon/kms: implement gpu lockup check for evergreen
  drm/radeon/kms: adjust quirk for acer laptop
  drm/radeon/kms: add quirk for Mac Radeon HD 2600 card
  drm/radeon/kms: add pcie get/set lane support for r6xx/r7xx/evergreen
  drm/radeon/kms: add support for gen2 pcie link speeds
  drm/radeon/kms: set the MSB of the HDP slice size
  drm/radeon/kms: fix some typos in evergreen pm4 defines
  drm/radeon/kms: clean up ASIC_IS_DCE41() macro
  drm/radeon/kms: add NI chip families
  drm/radeon/kms: update display watermark calculations for DCE5
  drm/radeon/kms: DCE5 supports 16k display surfaces
  drm/radeon/kms: DCE5 atom SetPixelClock updates
  drm/radeon/kms: DCE5 atom spread spectrum updates
  drm/radeon/kms: DCE5 atom transmitter control updates
  drm/radeon/kms: DCE5 atom dig encoder updates
  drm/radeon/kms: dac dpms updates for DCE5
  drm/radeon/kms: dvo dpms updates for DCE5
  drm/radeon/kms: parse DCE5 encoder caps when setting up encoders
  drm/radeon/kms: handle NI thermal controller
  drm/radeon/kms: add disabled vbios accessor for NI asics
  drm/radeon/kms: fill gpu init for NI asics
  drm/radeon/kms: add backend map workaround for barts
  drm/radeon/kms: adjust default clock/vddc tracking for pm on DCE5
  drm/radeon/kms: always use writeback/events for fences on NI
  drm/radeon/kms: add bo blit support for NI
  drm/radeon/kms: add ni_reg.h
  drm/radeon/kms: add support for DCE5 display LUTs
  drm/radeon/kms: add ucode loader for NI
  drm/radeon/kms/ni: load default sclk/mclk/vddc at pm init
  drm/radeon/kms: add radeon_asic struct for NI asics
  drm/radeon/kms: don't enable pcie gen2 on NI yet
  drm/radeon/kms: add NI pci ids
  drm/radeon/kms: only enable hdmi features if the monitor supports audio
  drm/radeon/kms: disable underscan by default

Ben Hutchings (1):
  drm/nouveau: Only select ACPI_VIDEO if its dependencies are met

Ben Skeggs (91):
  drm/nouveau: tidy fifo swmthd handler a little
  drm/nouveau: disallow fbcon accel if running in interrupt context
  drm/nouveau: add per-channel mutex, use to lock access to drm's channel
  drm/nouveau: add more fine-grained locking to channel list + structures
  

Re: [git pull] drm for rc1

[Linus Torvalds]

On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

Lowlights: it's broken.

I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 30938, at 30938], missed
IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 31068, at 31068], missed
IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
timer elapsed... render ring idle [waiting on 31129, at 31129], missed
IRQ?
  ...

and everything is very choppy. I assume it's the power saving thing
that broke again, but that's just a total random guess, I have nothing
to actually back that up with.

It worked fine after boot, but those problems began at 8287.139375
(about two hours after boot - it may have coincided with screen saver,
but who knows?)  and have been happening constantly since. The machine
is not really usable, I'm writing this with annoying 2-second pauses
every once in a while.

This is a regular Core i5-670 with up-to-date Fedora-14, fwiw. Not my
sandybridge.

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

Re: [git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938], missed
 IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068], missed
 IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129], missed
 IRQ?
  ...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen saver,
 but who knows?)  and have been happening constantly since. The machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting with
i915.powersave=0 help any?

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

Re: [git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 2:48 PM, Dave Airlie airl...@gmail.com wrote:
 On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938], missed
 IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068], missed
 IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129], missed
 IRQ?
  ...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen saver,
 but who knows?)  and have been happening constantly since. The machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.

 Okay I'll try and reproduce and curse Chris and Jesse, does booting with
 i915.powersave=0 help any?

I've also noticed Chris has some more patches in drm-intel-next I
haven't got in this pull request.

I don't think he's sent me a pull request though so not telling how
stable they are.

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

Re: [git pull] drm for rc1

[Jesse Barnes]

Dave Airlie airl...@gmail.com wrote:

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie
wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
 IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
 IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
 IRQ?
  ...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have
nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen
saver,
 but who knows?)  and have been happening constantly since. The
machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting
with
i915.powersave=0 help any?

Dave.

Arg.  It's been ok on my ILK systems, but Chris has found some issues with out 
watermarking code iirc; apparently we're underflowing the display FIFO, causing 
all sorts of trouble.  If it works before the pull of Dave's tree, can you 
bisect?

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 Dave Airlie airl...@gmail.com wrote:

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie
wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
 IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
 IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
 IRQ?
  ...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have
nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen
saver,
 but who knows?)  and have been happening constantly since. The
machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting
with
i915.powersave=0 help any?

Dave.

 Arg.  It's been ok on my ILK systems, but Chris has found some issues with 
 out watermarking code iirc; apparently we're underflowing the display FIFO, 
 causing all sorts of trouble.  If it works before the pull of Dave's tree, 
 can you bisect?


I think he'd fixed them in the tree I pulled locally to test, I'm
guessing this might be that we are running the Fedora userspace driver
and you guys are all on master or something, which would mean some ABI
guarantee got busted.

I'm going to try a local test upgrade to 2.14.0 just to see.

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

Re: [git pull] drm for rc1

[Dave Airlie]

On Tue, Jan 11, 2011 at 4:28 PM, Dave Airlie airl...@gmail.com wrote:
 On Tue, Jan 11, 2011 at 4:06 PM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 Dave Airlie airl...@gmail.com wrote:

On Tue, Jan 11, 2011 at 2:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Jan 10, 2011 at 2:59 PM, Dave Airlie airl...@linux.ie
wrote:
 Highlights:
 core/drivers: add support for high precision vblank timestamps
 radeon: pageflipping support, Gen2 PCIE support
 nouveau: reworked VRAM and VM support
 intel: better ILK/SNB powersaving support, Full GTT support

 Lowlights: it's broken.

 I get millions of messages like:

  ...
  [ 8482.000414] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 30938, at 30938],
missed
 IRQ?
  [ 8485.918124] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31068, at 31068],
missed
 IRQ?
  [ 8487.926963] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck
 timer elapsed... render ring idle [waiting on 31129, at 31129],
missed
 IRQ?
  ...

 and everything is very choppy. I assume it's the power saving thing
 that broke again, but that's just a total random guess, I have
nothing
 to actually back that up with.

 It worked fine after boot, but those problems began at 8287.139375
 (about two hours after boot - it may have coincided with screen
saver,
 but who knows?)  and have been happening constantly since. The
machine
 is not really usable, I'm writing this with annoying 2-second pauses
 every once in a while.

Okay I'll try and reproduce and curse Chris and Jesse, does booting
with
i915.powersave=0 help any?

Dave.

 Arg.  It's been ok on my ILK systems, but Chris has found some issues with 
 out watermarking code iirc; apparently we're underflowing the display FIFO, 
 causing all sorts of trouble.  If it works before the pull of Dave's tree, 
 can you bisect?


 I think he'd fixed them in the tree I pulled locally to test, I'm
 guessing this might be that we are running the Fedora userspace driver
 and you guys are all on master or something, which would mean some ABI
 guarantee got busted.

 I'm going to try a local test upgrade to 2.14.0 just to see.

Okay that didn't help, dead in similar times, evince with a few flood
maps from Brisbane seem to be a good trigger.

I'm not sure I'll be in a good place for bisection, need laptop to
keep track of disaster.

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