Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos  wrote:

> Yes, VT-x and VT-d are both enabled from BIOS setup.

Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with intel_iommu=off and make sure that's stable.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2022/64855acd/attachment.pgp>

[Bug 42683] [r300g] GPU lockup while playing WoW

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42683

--- Comment #4 from Chris Rankin  2011-11-22 
12:57:56 PST ---
Created attachment 53788
  --> https://bugs.freedesktop.org/attachment.cgi?id=53788
Two GPU resets while playing WoW

These two GPU resets happened in quick succession, although the kernel managed
to recover each time. (Small comfort, I suppose).

The kernel is 3.1.2, with Mesa HEAD at:

commit 034e63b9f8ee23cfac769b1a2c431bdd2307a6c4
Author: Marek Ol??k 
Date:   Tue Nov 22 20:48:23 2011 +0100

r600g: handle all remaining CAPs

This does not bode well for RV350 support with Mesa 7.12.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Matthew Garrett]

On Tue, Nov 22, 2011 at 06:46:21PM -0200, Eugeni Dodonov wrote:
> On Tue, Nov 22, 2011 at 18:15, Matthew Garrett  wrote:
> 
> > On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
> >
> > > + /*
> > > +  * Only enable RC6 if all dma remapping is disabled, or if
> > > +  * there's no iommu present in the machine.
> > > +  */
> > > + if (INTEL_INFO(dev)->gen == 6)
> > > + return no_iommu || dmar_disabled;
> >
> > So the user has to choose between 5W of power saving or having dmar? And
> > we default to giving them dmar?
> 
> 
> From the latest investigations, it is either this, or random gpu hangs and
> crashes when both are enabled :(.

So blacklist dmar on sandybridge. The power saving is going to be more 
important for most users.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Matthew Garrett]

On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:

> + /*
> +  * Only enable RC6 if all dma remapping is disabled, or if
> +  * there's no iommu present in the machine.
> +  */
> + if (INTEL_INFO(dev)->gen == 6)
> + return no_iommu || dmar_disabled;

So the user has to choose between 5W of power saving or having dmar? And 
we default to giving them dmar? I think that's going to come as a 
surprise to people.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

No subject

When the root cause will be discovered, we should allow both of course. But
so far, all the attempts on this weren't successful.

-- 
Eugeni Dodonov


--bcaec54306ded2a5b704b258e725
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 18:15, Matthew Garrett <=
span dir=3D"ltr">mailto:mjg at redhat.com">mjg at 
redhat.com=
t; wrote:

On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard w=
rote:

 + =A0 =A0 /*
 + =A0 =A0 =A0* Only enable RC6 if all dma remapping is disabled, or if=

 + =A0 =A0 =A0* theres no iommu present in the machine.
 + =A0 =A0 =A0*/
 + =A0 =A0 if (INTEL_INFO(dev)-gen =3D=3D 6)
 + =A0 =A0 =A0 =A0 =A0 =A0 return no_iommu || dmar_disabled;

So the user has to choose between 5W of power saving or having dmar? =
And
we default to giving them dmar?From the latest invest=
igations, it is either this, or random gpu hangs and crashes when both are =
enabled :(.When the root cause will be discovered, we should allow =
both of course. But so far, all the attempts on this werent successful=
.

-- Eugeni Dodonovhttp://eugeni.dodonov.net/"=
 target=3D"_blank">

--bcaec54306ded2a5b704b258e725--

i915: hangcheck timer elapsed

[Keith Packard]

On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds  wrote:

> X is hung, but I can at least switch VT's and send this from a text 
> terminal..

Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the GPU which isn't moving.

Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
driver, and yes, I'm trying to fix this (by deleting code, which is
always the best way).

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2022/cd97d91f/attachment-0001.pgp>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett  wrote:

> So the user has to choose between 5W of power saving or having dmar? And 
> we default to giving them dmar? I think that's going to come as a 
> surprise to people.

You'd have to go into the BIOS to turn this on for most machines at
least?

But, yeah, it seems like we should be turning DMAR off unless explicitly
requested; I can't understand how you'd ever need this running native on
the hardware. Not exactly an area I care about deeply; I've always
worked hard to make sure all virtualization garbage is disabled on every
machine I use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2022/6c8c595b/attachment.pgp>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Eugeni Dodonov]

On Tue, Nov 22, 2011 at 18:15, Matthew Garrett  wrote:

> On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
>
> > + /*
> > +  * Only enable RC6 if all dma remapping is disabled, or if
> > +  * there's no iommu present in the machine.
> > +  */
> > + if (INTEL_INFO(dev)->gen == 6)
> > + return no_iommu || dmar_disabled;
>
> So the user has to choose between 5W of power saving or having dmar? And
> we default to giving them dmar?

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

> > The X environment will eventually call mode_set when the user
> > environment decides to use the monitor. Any audio bits can, and should,
> > await the user's choice of a video mode before choosing the audio format
> > to use. We should not be adding eld information until the monitor is in
> > use.
> 
> Yeah. I just tested the full gnome desktop and find it behave like the
> KMS console:
> 
> 1) ->mode_set will be called
> 2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there
> 
> So the v3 patch will behave equally well on KMS console, gnome desktop
> and bare X. Shall we just use it, or go back and use the original
> ->hot_remove patch?

Here is the patch with updated comments and changelog to reflect the
new findings.

---
Subject: drm/i915: hot plug/unplug notification to HDMI audio driver
Date: Fri Nov 11 13:49:04 CST 2011

On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

A new callback ->hotplug() is added to struct drm_connector_funcs which
will be called immediately after ->detect() knowing that the monitor is
either plugged or unplugged.

It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in ->hotplug.

The call sequence on hot plug is
(the difference part lies in ->mode_set vs ->hotplug)

- KMS console
->detect
  drm_edid_to_eld
->mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
->detect
  drm_edid_to_eld
->hotplug
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

->hotplug
  clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/drm_crtc_helper.c  |6 +++
 drivers/gpu/drm/i915/intel_dp.c|   44 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   31 +++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 include/drm/drm_crtc.h |1 
 5 files changed, 72 insertions(+), 12 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-21 11:26:09.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-21 14:12:21.0 
+0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;

-   if (intel_dp->force_audio) {
-   intel_dp->has_audio = intel_dp->force_audio > 0;
-   } else {
-   edid = intel_dp_get_edid(connector, _dp->adapter);
-   if (edid) {
-   intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, _dp->adapter);
+   if (edid) {
+   intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
+   connector->display_info.raw_edid = NULL;
+   kfree(edid);
}

+   if (intel_dp->force_audio)
+   intel_dp->has_audio = intel_dp->force_audio > 0;
+
return connector_status_connected;
 }

+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = intel_dp->base.base.crtc;
+
+   DRM_DEBUG_DRIVER("DisplayPort hotplug status %d crtc %p eld %#x\n",
+connector->status,
+crtc,
+(unsigned int)connector->eld[0]);
+
+   if (connector->status == connector_status_disconnected) {
+   intel_dp->DP &= ~DP_AUDIO_OUTPUT_ENABLE;
+   } else if (connector->status == connector_status_connected && crtc) {
+   intel_write_eld(_dp->base.base, >mode);
+   intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else {
+   return;
+   }
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs 
.detect = intel_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = 

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On Tue, Nov 22, 2011 at 12:55:43AM +0800, Keith Packard wrote:
> On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang  
> wrote:
> > On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> > or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
> > receive hot plug events and take action to refresh its device state and
> > ELD contents.
> > 
> > A new callback ->hotplug() is added to struct drm_connector_funcs which
> > will be called immediately after ->detect() knowing that the monitor is
> > either plugged or unplugged.
> > 
> > It's noticed that X may not call ->mode_set() at monitor hot plug, so it's
> > necessary to call drm_edid_to_eld() earlier at ->detect() time rather than
> > in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
> > in ->hotplug.
> 
> The X environment will eventually call mode_set when the user
> environment decides to use the monitor. Any audio bits can, and should,
> await the user's choice of a video mode before choosing the audio format
> to use. We should not be adding eld information until the monitor is in
> use.

Yeah. I just tested the full gnome desktop and find it behave like the
KMS console:

1) ->mode_set will be called
2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there

So the v3 patch will behave equally well on KMS console, gnome desktop
and bare X. Shall we just use it, or go back and use the original
->hot_remove patch?

Thanks,
Fengguang

i915 screen corruption

[Udo Steinberg]

0x63/0x6e
 [] ? ring_write_tail+0x39/0x48
 [] ? blt_ring_flush+0xdb/0xe4
 [] ? i915_gem_flush_ring+0x24/0xdc
 [] ? i915_gem_do_execbuffer.clone.8+0xc6d/0x11cf
 [] ? __hrtimer_start_range_ns+0x2c6/0x2d9
 [] ? i915_gem_execbuffer2+0x12b/0x1ac
 [] ? drm_ioctl+0x251/0x306
 [] ? i915_gem_execbuffer+0x360/0x360
 [] ? fpu_finit+0xe/0x1d
 [] ? init_fpu+0x10b/0x124
 [] ? check_for_xstate+0x1c/0x71
 [] ? do_vfs_ioctl+0x404/0x445
 [] ? sys_rt_sigreturn+0x196/0x1c5
 [] ? vfs_read+0x118/0x126
 [] ? sys_ioctl+0x3c/0x5e
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace e2c97bffad4061d7 ]---
[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_drv.c:387 
__gen6_gt_wait_for_fifo+0x63/0x6e()
Hardware name: 4290W4H
Modules linked in: iwlagn [last unloaded: iwlagn]
Pid: 1693, comm: X Tainted: GW   3.1.0 #1
Call Trace:
 [] ? warn_slowpath_common+0x78/0x8c
 [] ? __gen6_gt_wait_for_fifo+0x63/0x6e
 [] ? gen6_ring_get_irq+0x79/0xbe
 [] ? i915_wait_request+0x176/0x3b9
 [] ? blt_ring_flush+0xdb/0xe4
 [] ? i915_gem_flush_ring+0x24/0xdc
 [] ? i915_gem_do_execbuffer.clone.8+0xd7b/0x11cf
 [] ? __hrtimer_start_range_ns+0x2c6/0x2d9
 [] ? i915_gem_execbuffer2+0x12b/0x1ac
 [] ? drm_ioctl+0x251/0x306
 [] ? i915_gem_execbuffer+0x360/0x360
 [] ? fpu_finit+0xe/0x1d
 [] ? init_fpu+0x10b/0x124
 [] ? check_for_xstate+0x1c/0x71
 [] ? do_vfs_ioctl+0x404/0x445
 [] ? sys_rt_sigreturn+0x196/0x1c5
 [] ? vfs_read+0x118/0x126
 [] ? sys_ioctl+0x3c/0x5e
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace e2c97bffad4061d8 ]---
[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_drv.c:387 
__gen6_gt_wait_for_fifo+0x63/0x6e()
Hardware name: 4290W4H
Modules linked in: iwlagn [last unloaded: iwlagn]
Pid: 1693, comm: X Tainted: GW   3.1.0 #1
Call Trace:
 [] ? warn_slowpath_common+0x78/0x8c
 [] ? __gen6_gt_wait_for_fifo+0x63/0x6e
 [] ? gen6_ring_put_irq+0x66/0xa6
 [] ? i915_wait_request+0x2e0/0x3b9
 [] ? wake_up_bit+0x23/0x23
 [] ? i915_gem_flush_ring+0x24/0xdc
 [] ? i915_gem_do_execbuffer.clone.8+0xd7b/0x11cf
 [] ? __hrtimer_start_range_ns+0x2c6/0x2d9
 [] ? i915_gem_execbuffer2+0x12b/0x1ac
 [] ? drm_ioctl+0x251/0x306
 [] ? i915_gem_execbuffer+0x360/0x360
 [] ? fpu_finit+0xe/0x1d
 [] ? init_fpu+0x10b/0x124
 [] ? check_for_xstate+0x1c/0x71
 [] ? do_vfs_ioctl+0x404/0x445
 [] ? sys_rt_sigreturn+0x196/0x1c5
 [] ? vfs_read+0x118/0x126
 [] ? sys_ioctl+0x3c/0x5e
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace e2c97bffad4061d9 ]---
[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_drv.c:387 
__gen6_gt_wait_for_fifo+0x63/0x6e()
Hardware name: 4290W4H
Modules linked in: iwlagn [last unloaded: iwlagn]
Pid: 1693, comm: X Tainted: GW   3.1.0 #1
Call Trace:
 [] ? warn_slowpath_common+0x78/0x8c
 [] ? __gen6_gt_wait_for_fifo+0x63/0x6e
 [] ? ring_write_tail+0x39/0x48
 [] ? blt_ring_flush+0xdb/0xe4
 [] ? i915_gem_flush_ring+0x24/0xdc
 [] ? i915_gem_do_execbuffer.clone.8+0xc6d/0x11cf
 [] ? __hrtimer_start_range_ns+0x2c6/0x2d9
 [] ? i915_gem_execbuffer2+0x12b/0x1ac
 [] ? copy_user_generic_unrolled+0x95/0xb0
 [] ? drm_ioctl+0x251/0x306
 [] ? i915_gem_execbuffer+0x360/0x360
 [] ? input_event_to_user+0xe/0x1f
 [] ? evdev_read+0x179/0x19e
 [] ? init_fpu+0x10b/0x124
 [] ? check_for_xstate+0x1c/0x71
 [] ? do_vfs_ioctl+0x404/0x445
 [] ? sys_rt_sigreturn+0x196/0x1c5
 [] ? vfs_read+0x118/0x126
 [] ? sys_ioctl+0x3c/0x5e
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace e2c97bffad4061da ]---
[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_drv.c:387 
__gen6_gt_wait_for_fifo+0x63/0x6e()
Hardware name: 4290W4H
Modules linked in: iwlagn [last unloaded: iwlagn]
Pid: 1693, comm: X Tainted: GW   3.1.0 #1
Call Trace:
 [] ? warn_slowpath_common+0x78/0x8c
 [] ? __gen6_gt_wait_for_fifo+0x63/0x6e
 [] ? gen6_ring_get_irq+0x79/0xbe
 [] ? i915_wait_request+0x176/0x3b9
 [] ? blt_ring_flush+0xdb/0xe4
 [] ? i915_gem_flush_ring+0x24/0xdc
 [] ? i915_gem_do_execbuffer.clone.8+0xd7b/0x11cf
 [] ? __hrtimer_start_range_ns+0x2c6/0x2d9
 [] ? i915_gem_execbuffer2+0x12b/0x1ac
 [] ? copy_user_generic_unrolled+0x95/0xb0
 [] ? drm_ioctl+0x251/0x306
 [] ? i915_gem_execbuffer+0x360/0x360
 [] ? input_event_to_user+0xe/0x1f
 [] ? evdev_read+0x179/0x19e
 [] ? init_fpu+0x10b/0x124
 [] ? check_for_xstate+0x1c/0x71
 [] ? do_vfs_ioctl+0x404/0x445
 [] ? sys_rt_sigreturn+0x196/0x1c5
 [] ? vfs_read+0x118/0x126
 [] ? sys_ioctl+0x3c/0x5e
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace e2c97bffad4061db ]---
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 2105449 
at 2105448, next 2105450)
-- next part --
A non-text attachment was scrubbed...
Name: i915_error_state.bz2
Type: application/x-bzip
Size: 234095 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111

i915: hangcheck timer elapsed

[Linus Torvalds]

I haven't gotten one of these in a long time..

  [89045.616347] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
elapsed... GPU hung
  [89045.616352] [drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
  [89045.621818] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 
(awaiting 3692400 at 3692395, next 3692401)

Any ideas? Full dmesg and the i915_error_state file content in the 
attachement..

X is hung, but I can at least switch VT's and send this from a text 
terminal..

Linus
-- next part --
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-rc2-00288-gf8f5ed7c996a (torvalds at 
i5.linux-foundation.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) 
#17 SMP PREEMPT Mon Nov 21 12:13:28 PST 2011
[0.00] Command line: ro root=/dev/mapper/vg_i5-lv_root 
rd_LVM_LV=vg_i5/lv_root rd_LVM_LV=vg_i5/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM 
LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009e800 (usable)
[0.00]  BIOS-e820: 0009e800 - 000a (reserved)
[0.00]  BIOS-e820: 000e4000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - bdc7 (usable)
[0.00]  BIOS-e820: bdc7 - bdc88000 (ACPI data)
[0.00]  BIOS-e820: bdc88000 - bdcdc000 (ACPI NVS)
[0.00]  BIOS-e820: bdcdc000 - c000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ff80 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 0001fc00 (usable)
[0.00]  BIOS-e820: 0001fc00 - 0002 (reserved)
[0.00]  BIOS-e820: 0002 - 00024000 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: System manufacturer System Product Name/P7H57D-V EVO, BIOS 
099901/19/2010
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x24 max_arch_pfn = 0x4
[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-E7FFF write-through
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask E write-back
[0.00]   1 base 2 mask FC000 write-back
[0.00]   2 base 0C000 mask FC000 uncachable
[0.00]   3 base 0BDE0 mask FFFE0 uncachable
[0.00]   4 base 0BE00 mask FFE00 uncachable
[0.00]   5 base 1FC00 mask FFC00 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820 update range: bde0 - 0001 (usable) 
==> (reserved)
[0.00] e820 update range: 0001fc00 - 0002 (usable) 
==> (reserved)
[0.00] last_pfn = 0xbdc70 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880ff780] ff780
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8809c000] 9c000 size 8192
[0.00] init_memory_mapping: -bdc7
[0.00]  00 - 00bdc0 page 2M
[0.00]  00bdc0 - 00bdc7 page 4k
[0.00] kernel direct mapping tables up to bdc7 @ 1fffb000-2000
[0.00] init_memory_mapping: 0001-00024000
[0.00]  01 - 024000 page 2M
[0.00] kernel direct mapping tables up to 24000 @ bdc66000-bdc7
[0.00] RAMDISK: 37b09000 - 37ff
[0.00] ACPI: RSDP 000fb910 00024 (v02 ACPIAM)
[0.00] ACPI: XSDT bdc70100 0006C (v01 011910 XSDT1217 20100119 
MSFT 0097)
[0.00] ACPI: FACP bdc70290 000F4 (v03 011910 FACP1217 20100119 
MSFT 0097)
[0.00] ACPI: DSDT bdc704a0 0EEF2 (v01  A1472 A1472001 0001 
INTL 20060113)
[0.00] ACPI: FACS bdc88000 00040
[0.00] ACPI: APIC bdc70390 000CC (v01 011910 APIC1217 20100119 
MSFT 0097)
[0.00] ACPI: MCFG bdc70460 0003C (v01 011910 OEMMCFG  20100119 
MSFT 0097)
[0.00] ACPI: OEMB bdc88040 00072 (v01 011910 OEMB1217 20100119 
MSFT 0097)
[0.00] ACPI: HPET bdc7f4a0 00038 (v01 011910 OEMHPET  

Bug#649448: udev loading radeon drivers garbles screen output

[Touko Korpela]

On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote:
> On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  
> wrote:
> > On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
> >> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
> >> severity 649448 important
> >> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
> >> firmware not installed
> >> tags 649448 + upstream
> >> quit
> >>
> >> Hi Martin,
> >>
> >> Martin von Gagern wrote:
> >>
> >> > Version: 3.0.0-3
> >> [...]
> >> > Just installed a wheezy setup using debootstrap, adding grub-pc and
> >> > linux-image-amd64 after the chroot was created. The kernel boots, the
> >> > initrd seems all right. When the main system boots up, udev gets launced
> >> > pretty early. Soon after it is started, the screen turns into a pretty
> >> > random-looking pattern of pixels, making the console pretty unusable.
> >> > This also happens in "recovery" i.e. single-user mode.
> >> [...]
> >> > Possible workarounds seem to include:
> >> [...]
> >> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
> >> > ? followed by running "depmod -a".
> >> [...]
> >> >> [ ?150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
> >> >> [ ?150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> >> >> [ ?150.125859] radeon :00:01.0: disabling GPU acceleration
> >>
> >> Yes, the radeon driver currently copes poorly when firmware is missing.
> >> Compare [1], [2], [3].
> >>
> >> [...]
> >> > Not having GPU accelleration due to lack of free firmware is acceptable.
> >> > Not having a usable text console can be a real problem.
> >>
> >> Agreed. ?The radeon driver should be bailing out when firmware is
> >> missing for cards that need it, but that is not working for some
> >> reason.
> > [...]
> >
> > At the time I converted the radeon driver to load external firmware, it
> > was apparently only required for 3D acceleration and both KMS and 2D
> > acceleration of X worked without it, at least on those systems I tested
> > (which were quite old, R100-R300 families). ?Therefore failure to load
> > firmware would only result in DRM (3D acceleration support) being
> > disabled.
> >
> > However, it looks like driver support for the R600 family onward now
> > absolutely requires the 'RLC' firmware blobs:
> >
> > commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
> > Author: Alex Deucher 
> > Date: ? Tue Dec 1 13:43:46 2009 -0500
> >
> > ? ?drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
> >
> > And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
> > 'MC' firmware blobs:
> >
> > commit 0af62b0168043896a042b005ff88caa77dd94d04
> > Author: Alex Deucher 
> > Date: ? Thu Jan 6 21:19:31 2011 -0500
> >
> > ? ?drm/radeon/kms: add ucode loader for NI
> >
> > Therefore I think that at least r600_init(), rv770_init(),
> > evergreen_init() and cayman_init() should be treating failure to load
> > firmware as a fatal error.
> >
> 
> R6xx, r7xx should work ok without the RLC ucode, you just won't get
> acceleration.  With chips that require the MC ucode, the driver will
> bail if the MC ucode is not available.

In what kernel versions should that be true?
These bugs are reported that question it (some are reported against older
kernels).
http://bugs.debian.org/607194
http://bugs.debian.org/637943
http://bugs.debian.org/627497
and also my report:
http://bugs.debian.org/646306

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42913

--- Comment #4 from Kai  2011-11-22 05:31:15 PST 
---
The weekend's Piglit run showed the bug with Mesa git/03df791c.

Apart from that I noticed, that this bug was assigned to dri-devel and not
mesa-dev. Is that correct? This is, after all, most likely a bug in r600g and I
thought Gallium driver development happened on mesa-dev.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrea Arcangeli]

On Mon, Nov 21, 2011 at 09:59:18PM -0800, Andrew Morton wrote:
> grr, nothing in that patch's changelog indicates that it fixed a
> regression nor that it fixed an infinite blockage of suspend.

Well it's not a recent thing so I didn't flag it as a regression. It
doesn't infinite block it, suspend works fine almost all the time (or
it would have been noticed before), and if you've bad luck and it
doesn't suspend the first time around like someone experienced, if you
try again a bit later it'll work.

> I moved it to my 3.2 queue, thanks.

Thanks!

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Daniel Vetter]

On Tue, Nov 22, 2011 at 12:15:24PM +0200, Meelis Roos wrote:
> 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
> hangs in random places while using X.
> 
> Core i5 660, lspci below. Running 64-bit Debian unstable.
> 
> lspci -nn
> 
> 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller 
> [8086:0040] (rev 02)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
> Integrated Graphics Controller [8086:0042] (rev 02)
> 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 
> Series Chipset HECI Controller [8086:3b64] (rev 06)
> 00:16.3 Serial controller [0700]: Intel Corporation 5 Series/3400 Series 
> Chipset KT Controller [8086:3b67] (rev 06)
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82578DM Gigabit Network 
> Connection [8086:10ef] (rev 05)
> 00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
> USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
> 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset 
> High Definition Audio [8086:3b56] (rev 05)
> 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
> Express Root Port 1 [8086:3b42] (rev 05)
> 00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
> Express Root Port 5 [8086:3b4a] (rev 05)
> 00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
> Express Root Port 7 [8086:3b4e] (rev 05)
> 00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
> USB2 Enhanced Host Controller [8086:3b34] (rev 05)
> 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] 
> (rev a5)
> 00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface 
> Controller [8086:3b0a] (rev 05)
> 00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series 
> Chipset 6 port SATA AHCI Controller [8086:3b22] (rev 05)
> 3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
> Architecture Generic Non-core Registers [8086:2c61] (rev 05)
> 3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
> Architecture System Address Decoder [8086:2d01] (rev 05)
> 3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 
> [8086:2d10] (rev 05)
> 3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 
> [8086:2d11] (rev 05)
> 3f:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved 
> [8086:2d12] (rev 05)
> 3f:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved 
> [8086:2d13] (rev 05)
> 
> 
> Bisected it to the following commit. Bisection may not be 100% correct 
> because the issue happens at random, and most of the "good" revisions 
> got some usage without problems. The "bad" bisects are the ones that 
> hang.
> 
> 6fbcfb3e467adb414e235eeefaeaf51ad12f2461 is the first bad commit
> commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
> Author: David Woodhouse 
> Date:   Sun Sep 25 19:11:14 2011 -0700
> 
> intel-iommu: Workaround IOTLB hang on Ironlake GPU
> 
> To work around a hardware issue, we have to submit IOTLB flushes while
> the graphics engine is idle. The graphics driver will (we hope) go to
> great lengths to ensure that it gets that right on the affected
> chipset(s)... so let's not screw it over by deferring the unmap and
> doing it later. That wouldn't be very helpful.
> 
> Signed-off-by: David Woodhouse 

Can you retry with Keith's latest drm-intel-fixes, please? This workaround
turned out to be a bit buggy, unfortunately. It's strange though that your
bisect ended up on this commit, so maybe it's something else. Also please
attach the full dmesg of a broken kernel (before it hangs).

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

> 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
> hangs in random places while using X.

Just tested 3.2.0-rc2-00369-gbbbc479 after finishing bisecting, and it 
also freezes.

.config below:

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.2.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_FHANDLE=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_JUMP_LABEL=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
hangs in random places while using X.

Core i5 660, lspci below. Running 64-bit Debian unstable.

lspci -nn

00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller 
[8086:0040] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0042] (rev 02)
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series 
Chipset HECI Controller [8086:3b64] (rev 06)
00:16.3 Serial controller [0700]: Intel Corporation 5 Series/3400 Series 
Chipset KT Controller [8086:3b67] (rev 06)
00:19.0 Ethernet controller [0200]: Intel Corporation 82578DM Gigabit Network 
Connection [8086:10ef] (rev 05)
00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset 
High Definition Audio [8086:3b56] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 1 [8086:3b42] (rev 05)
00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 5 [8086:3b4a] (rev 05)
00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 7 [8086:3b4e] (rev 05)
00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller [8086:3b34] (rev 05)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
a5)
00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface 
Controller [8086:3b0a] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 
6 port SATA AHCI Controller [8086:3b22] (rev 05)
3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
Architecture Generic Non-core Registers [8086:2c61] (rev 05)
3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
Architecture System Address Decoder [8086:2d01] (rev 05)
3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 
[8086:2d10] (rev 05)
3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 
[8086:2d11] (rev 05)
3f:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved 
[8086:2d12] (rev 05)
3f:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved 
[8086:2d13] (rev 05)


Bisected it to the following commit. Bisection may not be 100% correct 
because the issue happens at random, and most of the "good" revisions 
got some usage without problems. The "bad" bisects are the ones that 
hang.

6fbcfb3e467adb414e235eeefaeaf51ad12f2461 is the first bad commit
commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse 
Date:   Sun Sep 25 19:11:14 2011 -0700

intel-iommu: Workaround IOTLB hang on Ironlake GPU

To work around a hardware issue, we have to submit IOTLB flushes while
the graphics engine is idle. The graphics driver will (we hope) go to
great lengths to ensure that it gets that right on the affected
chipset(s)... so let's not screw it over by deferring the unmap and
doing it later. That wouldn't be very helpful.

Signed-off-by: David Woodhouse 

:04 04 3d2943d67945d8321d7aa8faac7497a8e8f1412a 
afaa155acfd1a7111ee607a971013ed615582ac8 M  drivers


git bisect log:

git bisect start
# good: [899e3ee404961a90b828ad527573c39f0ab1] Linux 3.1-rc10
git bisect good 899e3ee404961a90b828ad527573c39f0ab1
# bad: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1
git bisect bad c3b92c8787367a8bb53d57d9789b558f1295cc96
# good: [505f48b53478d3816d1f3b001815703cfd7afa09] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 505f48b53478d3816d1f3b001815703cfd7afa09
# good: [5117cc25fd43add94c04c9d2ace713c69a21bdb1] Merge branch 
'hwmon-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
git bisect good 5117cc25fd43add94c04c9d2ace713c69a21bdb1
# bad: [4399c8bf2b9093696fa8160d79712e7346989c46] intel-iommu: fix superpage 
support in pfn_to_dma_pte()
git bisect bad 4399c8bf2b9093696fa8160d79712e7346989c46
# bad: [c0771df8d5297bfb9c4fbe8ada085a49cb22ec4f] intel-iommu: Export a flag 
indicating that the IOMMU is used for iGFX.
git bisect bad c0771df8d5297bfb9c4fbe8ada085a49cb22ec4f
# bad: [6fbcfb3e467adb414e235eeefaeaf51ad12f2461] intel-iommu: 
Workaround IOTLB hang on Ironlake GPUgit bisect bad 
6fbcfb3e467adb414e235eeefaeaf51ad12f2461
# good: [3e7abe2556b583e87dabda3e0e6178a67b20d06f] intel-iommu: Fix AB-BA 
lockdep report
git bisect good 3e7abe2556b583e87dabda3e0e6178a67b20d06f

-- 
Meelis Roos (mroos at linux.ee)

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Srivatsa S. Bhat]

On 11/22/2011 03:19 AM, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
> 
> If you know of any other unresolved regressions from 3.0 and 3.1, please let 
> us
> know either and we'll add them to the list.  Also, please let us know if any 
> of
> the entries below are invalid.
> 
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
> 
> Subject: iwlagn is getting very shaky
> Submitter  : Norbert Preining 
> Date   : 2011-10-19 6:01
> Message-ID : 20111019060108.GA11588 at gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel=131914553920614=2
> 
> Subject: Regression: "irqpoll" hasn't been working for me since March 16 
> IRQ
> Submitter  : Edward Donovan 
> Date   : 2011-10-19 22:09
> Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel=131914554220679=2
> 
> Subject: Regression in 3.1 causes Xen to use wrong idle routine
> Submitter  : Stefan Bader 
> Date   : 2011-10-26 10:24
> Message-ID : 4EA7DFD1.9060608 at canonical.com
> References : http://marc.info/?l=linux-acpi=131962467924564=2
> 
> Subject: 3.1+ iwlwifi lockup
> Submitter  : Dave Jones 
> Date   : 2011-10-31 14:34
> Message-ID : 20111031143408.GA17152 at redhat.com
> References : http://marc.info/?l=linux-kernel=132007169420160=2
> 
> Subject: hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date   : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel=132018604426692=2
> 
> Subject: Simultaneous cat and external keyboard input causing kernel panic
> Submitter  : Timo Jyrinki 
> Date   : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel=132032253903074=2
> 
> Subject: Linus GIT - INFO: possible circular locking dependency detected
> Submitter  : Miles Lane 
> Date   : 2011-11-03 15:57
> Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel=132033587908426=2
> 
> Subject: lockdep warning after aa6afca5bcab: "proc: fix races against 
> execve() of /proc/PID/fd**"
> Submitter  : Ari Savolainen 
> Date   : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-kernel=132072413125099=2
> 
> Subject: DMA-API check_sync errors with 3.2
> Submitter  : Josh Boyer 
> Date   : 2011-11-08 17:31
> Message-ID : 2008173153.GE14216 at zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel=132077357608797=2
> 
> Subject: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
> suspending
> Submitter  : Rafa? Mi?ecki 
> Date   : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at 
> mail.gmail.com
> References : http://marc.info/?l=linux-netdev=13208398088=4
> 
> Subject: 3.2-rc1 doesn't boot on dual socket opteron without swap
> Submitter  : Niklas Schnelle 
> Date   : 2011-11-10 20:09
> Message-ID : 1320955769.1718.8.camel at jupiter
> References : http://marc.info/?l=linux-kernel=132095583501767=2
> 
> Subject: Sparc-32 doesn't work in 3.1.
> Submitter  : Rob Landley 
> Date   : 2011-11-12 11:22
> Message-ID : 4EBEAB5A.5020809 at landley.net
> References : http://www.spinics.net/lists/kernel/msg1260383.html
> 
> Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> Submitter  : Sergei Trofimovich 
> Date   : 2011-11-12 10:48
> Message-ID : 2012104859.7744b282 at sf.home
> References : https://lkml.org/lkml/2011/11/12/11
> 

Andrea's patch already fixes this issue, which was reported first by
Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
I remember Andrew Morton taking this patch in his -mm tree. But it is
not in mainline yet. So can we consider this closed or not?

Thanks,
Srivatsa S. Bhat

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang  
wrote:

> So the v3 patch will behave equally well on KMS console, gnome desktop
> and bare X. Shall we just use it, or go back and use the original
> ->hot_remove patch?

I'm not sure why we need any change to the core DRM code. The HDMI and
DP drivers will be told when to turn the monitors on and off, and that's
the appropriate time to control whether audio is routed to them. Hotplug
is considered simply a notification to user space that something has
changed -- user space is in charge of configuring which outputs are in
use.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2022/5940197c/attachment.pgp>

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos  wrote:

> > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
> > hangs in random places while using X.

Do you have VT-d enabled in the BIOS?

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2022/d8b431f7/attachment-0001.pgp>

Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela  wrote:
> On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote:
>> On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  
>> wrote:
>> > On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
>> >> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
>> >> severity 649448 important
>> >> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
>> >> firmware not installed
>> >> tags 649448 + upstream
>> >> quit
>> >>
>> >> Hi Martin,
>> >>
>> >> Martin von Gagern wrote:
>> >>
>> >> > Version: 3.0.0-3
>> >> [...]
>> >> > Just installed a wheezy setup using debootstrap, adding grub-pc and
>> >> > linux-image-amd64 after the chroot was created. The kernel boots, the
>> >> > initrd seems all right. When the main system boots up, udev gets launced
>> >> > pretty early. Soon after it is started, the screen turns into a pretty
>> >> > random-looking pattern of pixels, making the console pretty unusable.
>> >> > This also happens in "recovery" i.e. single-user mode.
>> >> [...]
>> >> > Possible workarounds seem to include:
>> >> [...]
>> >> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
>> >> > ? followed by running "depmod -a".
>> >> [...]
>> >> >> [ ?150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
>> >> >> [ ?150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
>> >> >> [ ?150.125859] radeon :00:01.0: disabling GPU acceleration
>> >>
>> >> Yes, the radeon driver currently copes poorly when firmware is missing.
>> >> Compare [1], [2], [3].
>> >>
>> >> [...]
>> >> > Not having GPU accelleration due to lack of free firmware is acceptable.
>> >> > Not having a usable text console can be a real problem.
>> >>
>> >> Agreed. ?The radeon driver should be bailing out when firmware is
>> >> missing for cards that need it, but that is not working for some
>> >> reason.
>> > [...]
>> >
>> > At the time I converted the radeon driver to load external firmware, it
>> > was apparently only required for 3D acceleration and both KMS and 2D
>> > acceleration of X worked without it, at least on those systems I tested
>> > (which were quite old, R100-R300 families). ?Therefore failure to load
>> > firmware would only result in DRM (3D acceleration support) being
>> > disabled.
>> >
>> > However, it looks like driver support for the R600 family onward now
>> > absolutely requires the 'RLC' firmware blobs:
>> >
>> > commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
>> > Author: Alex Deucher 
>> > Date: ? Tue Dec 1 13:43:46 2009 -0500
>> >
>> > ? ?drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
>> >
>> > And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
>> > 'MC' firmware blobs:
>> >
>> > commit 0af62b0168043896a042b005ff88caa77dd94d04
>> > Author: Alex Deucher 
>> > Date: ? Thu Jan 6 21:19:31 2011 -0500
>> >
>> > ? ?drm/radeon/kms: add ucode loader for NI
>> >
>> > Therefore I think that at least r600_init(), rv770_init(),
>> > evergreen_init() and cayman_init() should be treating failure to load
>> > firmware as a fatal error.
>> >
>>
>> R6xx, r7xx should work ok without the RLC ucode, you just won't get
>> acceleration. ?With chips that require the MC ucode, the driver will
>> bail if the MC ucode is not available.
>
> In what kernel versions should that be true?
> These bugs are reported that question it (some are reported against older
> kernels).
> http://bugs.debian.org/607194
> http://bugs.debian.org/637943
> http://bugs.debian.org/627497
> and also my report:
> http://bugs.debian.org/646306
>

Should work and well tested are different things.

Alex

[Bug 42514] [r300g] EVE online: some shaders are failing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42514

Pavel Ondra?ka  changed:

   What|Removed |Added

 AssignedTo|dri-devel at lists.freedesktop |idr at freedesktop.org
   |.org|
  Component|Drivers/Gallium/r300|glsl-compiler

--- Comment #6 from Pavel Ondra?ka  2011-11-22 
01:38:28 PST ---
Reassigning per comment 5.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real

[Jean Delvare]

On Mon, 21 Nov 2011 12:10:14 -0500, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
> 
> Fixes i2c test failures when i2c_algo_bit.bit_test=1.
> 
> The hw doesn't actually require a mask, so just set it
> to the default mask bits for r1xx-r4xx radeon ddc.
> 
> I missed this part the first time through.
> 
> Signed-off-by: Alex Deucher 
> Cc: stable at kernel.org
> Cc: Jean Delvare 

Acked-by: Jean Delvare 

And the fix was tested successfully by one openSUSE 11.4 user, see:
https://bugzilla.novell.com/show_bug.cgi?id=691052#c37

Thanks Alex!

Note for stable: now that this missing part is ready, the first part
(6c47e5c23aa2a7c54ad7ac13af4bd56cd9e703bf) can finally find its way to
stable trees too.

> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/radeon_atombios.c |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
> b/drivers/gpu/drm/radeon/radeon_atombios.c
> index fecd705..933a2cd 100644
> --- a/drivers/gpu/drm/radeon/radeon_atombios.c
> +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
> @@ -181,6 +181,18 @@ void radeon_atombios_i2c_init(struct radeon_device *rdev)
>   gpio = _info->asGPIO_Info[i];
>   i2c.valid = false;
>  
> + /* r4xx mask is technically not used by the hw, so 
> patch in the legacy mask bits */
> + if ((rdev->family == CHIP_R420) ||
> + (rdev->family == CHIP_R423) ||
> + (rdev->family == CHIP_RV410)) {
> + if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
> == 0x0018) ||
> + (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
> == 0x0019) ||
> + (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
> == 0x001a)) {
> + gpio->ucClkMaskShift = 0x19;
> + gpio->ucDataMaskShift = 0x18;
> + }
> + }
> +
>   /* some evergreen boards have bad data for this entry */
>   if (ASIC_IS_DCE4(rdev)) {
>   if ((i == 7) &&


-- 
Jean Delvare

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

> Subject: Regression in 3.1 causes Xen to use wrong idle routine
> Submitter  : Stefan Bader 
> Date   : 2011-10-26 10:24
> Message-ID : 4EA7DFD1.9060608 at canonical.com
> References : http://marc.info/?l=linux-acpi=131962467924564=2

The patch mentioned in http://mid.gmane.org/2015144004.GE22675 at 
phenom.dumpdata.com 
should do it. But the patch needs an Ack from ACPI/x86 folks.

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Ari Savolainen]

2011/11/22 Linus Torvalds :
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject ? ?: lockdep warning after aa6afca5bcab: "proc: fix races against 
>> execve() of /proc/PID/fd**"
>> Submitter ?: Ari Savolainen 
>> Date ? ? ? : 2011-11-08 3:47
>> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw at 
>> mail.gmail.com
>> References : http://marc.info/?l=linux-kernel=132072413125099=2
>
> Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
> is presumably stale.
>
> ? ? ? ? ? ? ? ? ? ? ?Linus

Yes, this went away after the reversion.

Ari

[REGRESSION]: hibernate/sleep regression w/ bisection

[Andrew Watts]

On Mon, Nov 21, 2011 at 04:29:23PM -0500, Jerome Glisse wrote:
> On Mon, Nov 21, 2011 at 4:09 PM, Tejun Heo  wrote:
> >
> > Out of curiosity, did it get somewhere?
> >
> > Thanks.
> >
> > --
> > tejun
> >
> 
> Yeah i am pretty sure i know what's going wrong but there is no easy
> fix, there is a deadlock in the kernel when gem wait ioctl is call on
> scanout buffer and that a gpu reset happen
> 
> Cheers,
> Jerome

Tejun, I was about to send a similar email asking about this; many thanks
for sharing my interest.

Jerome, sounds encouraging that you think you know what the issue is. What
are the next steps? Please let me know how I can assist on my end (code 
validation, etc.).

~ Andy

max PWM is zero

[Lucas De Marchi]

On Mon, Nov 21, 2011 at 23:40, Keith Packard  wrote:
> On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic 
> manual page), Marcos Paulo de Souza  wrote:
>
>> My max_brightness is 1, and my brightness is 0.
>
> Right, we've prevented the internal backlight driver from exposing a max
> value of 0 as that's just confusing.
>
>> But, my acpi_video0 have a
>> max_brightness value = 9...
>
> Right, sounds like your device is just using some other backlight
> controller, which is perfectly reasonable.
>
>> So, what can I do to silence this warning...? Change the driver of
>> backlight?
>
> If your backlight keys work correctly, then things are fine and perhaps
> we should just remove the warning from the driver, or disable the
> internal driver when we discover this situation.
>
> This is the first time I've heard of this warning appearing...

It appears here as well. I think it was since 2.6.39 or 3.0, I'm not sure.

Same card:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 02bb
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f640 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 02bb
Flags: bus master, fast devsel, latency 0
Memory at f610 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3

My kernel log has:

[drm] Driver supports precise vblank timestamp query.
composite sync not supported
fixme: max PWM is zero.
composite sync not supported


Is this "composite sync not supported" related to this issue?


Lucas De Marchi

Re: [PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real

[Jean Delvare]

On Mon, 21 Nov 2011 12:10:14 -0500, alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com
 
 Fixes i2c test failures when i2c_algo_bit.bit_test=1.
 
 The hw doesn't actually require a mask, so just set it
 to the default mask bits for r1xx-r4xx radeon ddc.
 
 I missed this part the first time through.
 
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc: sta...@kernel.org
 Cc: Jean Delvare kh...@linux-fr.org

Acked-by: Jean Delvare kh...@linux-fr.org

And the fix was tested successfully by one openSUSE 11.4 user, see:
https://bugzilla.novell.com/show_bug.cgi?id=691052#c37

Thanks Alex!

Note for stable: now that this missing part is ready, the first part
(6c47e5c23aa2a7c54ad7ac13af4bd56cd9e703bf) can finally find its way to
stable trees too.

 
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/radeon_atombios.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
 b/drivers/gpu/drm/radeon/radeon_atombios.c
 index fecd705..933a2cd 100644
 --- a/drivers/gpu/drm/radeon/radeon_atombios.c
 +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
 @@ -181,6 +181,18 @@ void radeon_atombios_i2c_init(struct radeon_device *rdev)
   gpio = i2c_info-asGPIO_Info[i];
   i2c.valid = false;
  
 + /* r4xx mask is technically not used by the hw, so 
 patch in the legacy mask bits */
 + if ((rdev-family == CHIP_R420) ||
 + (rdev-family == CHIP_R423) ||
 + (rdev-family == CHIP_RV410)) {
 + if ((le16_to_cpu(gpio-usClkMaskRegisterIndex) 
 == 0x0018) ||
 + (le16_to_cpu(gpio-usClkMaskRegisterIndex) 
 == 0x0019) ||
 + (le16_to_cpu(gpio-usClkMaskRegisterIndex) 
 == 0x001a)) {
 + gpio-ucClkMaskShift = 0x19;
 + gpio-ucDataMaskShift = 0x18;
 + }
 + }
 +
   /* some evergreen boards have bad data for this entry */
   if (ASIC_IS_DCE4(rdev)) {
   if ((i == 7) 


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

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

  The X environment will eventually call mode_set when the user
  environment decides to use the monitor. Any audio bits can, and should,
  await the user's choice of a video mode before choosing the audio format
  to use. We should not be adding eld information until the monitor is in
  use.
 
 Yeah. I just tested the full gnome desktop and find it behave like the
 KMS console:
 
 1) -mode_set will be called
 2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there
 
 So the v3 patch will behave equally well on KMS console, gnome desktop
 and bare X. Shall we just use it, or go back and use the original
 -hot_remove patch?

Here is the patch with updated comments and changelog to reflect the
new findings.

---
Subject: drm/i915: hot plug/unplug notification to HDMI audio driver
Date: Fri Nov 11 13:49:04 CST 2011

On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly.  So that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

A new callback -hotplug() is added to struct drm_connector_funcs which
will be called immediately after -detect() knowing that the monitor is
either plugged or unplugged.

It's noticed that X may not call -mode_set() at monitor hot plug, so it's
necessary to call drm_edid_to_eld() earlier at -detect() time rather than
in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD
in -hotplug.

The call sequence on hot plug is
(the difference part lies in -mode_set vs -hotplug)

- KMS console
-detect
  drm_edid_to_eld
-mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- X
-detect
  drm_edid_to_eld
-hotplug
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

-hotplug
  clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c  |6 +++
 drivers/gpu/drm/i915/intel_dp.c|   44 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   31 +++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 include/drm/drm_crtc.h |1 
 5 files changed, 72 insertions(+), 12 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-21 11:26:09.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-21 14:12:21.0 
+0800
@@ -28,6 +28,7 @@
 #include linux/i2c.h
 #include linux/slab.h
 #include linux/export.h
+#include drm/drm_edid.h
 #include drmP.h
 #include drm.h
 #include drm_crtc.h
@@ -1970,20 +1971,44 @@ intel_dp_detect(struct drm_connector *co
if (status != connector_status_connected)
return status;
 
-   if (intel_dp-force_audio) {
-   intel_dp-has_audio = intel_dp-force_audio  0;
-   } else {
-   edid = intel_dp_get_edid(connector, intel_dp-adapter);
-   if (edid) {
-   intel_dp-has_audio = drm_detect_monitor_audio(edid);
-   connector-display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, intel_dp-adapter);
+   if (edid) {
+   intel_dp-has_audio = drm_detect_monitor_audio(edid);
+   drm_edid_to_eld(connector, edid);
+   connector-display_info.raw_edid = NULL;
+   kfree(edid);
}
 
+   if (intel_dp-force_audio)
+   intel_dp-has_audio = intel_dp-force_audio  0;
+
return connector_status_connected;
 }
 
+static void intel_dp_hotplug(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_crtc *crtc = intel_dp-base.base.crtc;
+
+   DRM_DEBUG_DRIVER(DisplayPort hotplug status %d crtc %p eld %#x\n,
+connector-status,
+crtc,
+(unsigned int)connector-eld[0]);
+
+   if (connector-status == connector_status_disconnected) {
+   intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+   } else if (connector-status == connector_status_connected  crtc) {
+   intel_write_eld(intel_dp-base.base, crtc-mode);
+   intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else {
+   return;
+   }
+   I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+   POSTING_READ(intel_dp-output_reg);
+}
+
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_dp *intel_dp = intel_attached_dp(connector);
@@ -2143,6 +2168,7 @@ static const struct drm_connector_funcs 
.detect = intel_dp_detect,
.fill_modes = 

[Bug 42514] [r300g] EVE online: some shaders are failing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=42514

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

 AssignedTo|dri-devel@lists.freedesktop |i...@freedesktop.org
   |.org|
  Component|Drivers/Gallium/r300|glsl-compiler

--- Comment #6 from Pavel Ondračka pavel.ondra...@email.cz 2011-11-22 
01:38:28 PST ---
Reassigning per comment 5.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
hangs in random places while using X.

Core i5 660, lspci below. Running 64-bit Debian unstable.

lspci -nn

00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller 
[8086:0040] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0042] (rev 02)
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series 
Chipset HECI Controller [8086:3b64] (rev 06)
00:16.3 Serial controller [0700]: Intel Corporation 5 Series/3400 Series 
Chipset KT Controller [8086:3b67] (rev 06)
00:19.0 Ethernet controller [0200]: Intel Corporation 82578DM Gigabit Network 
Connection [8086:10ef] (rev 05)
00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset 
High Definition Audio [8086:3b56] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 1 [8086:3b42] (rev 05)
00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 5 [8086:3b4a] (rev 05)
00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
Express Root Port 7 [8086:3b4e] (rev 05)
00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
USB2 Enhanced Host Controller [8086:3b34] (rev 05)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
a5)
00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface 
Controller [8086:3b0a] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 
6 port SATA AHCI Controller [8086:3b22] (rev 05)
3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
Architecture Generic Non-core Registers [8086:2c61] (rev 05)
3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
Architecture System Address Decoder [8086:2d01] (rev 05)
3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 
[8086:2d10] (rev 05)
3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 
[8086:2d11] (rev 05)
3f:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved 
[8086:2d12] (rev 05)
3f:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved 
[8086:2d13] (rev 05)


Bisected it to the following commit. Bisection may not be 100% correct 
because the issue happens at random, and most of the good revisions 
got some usage without problems. The bad bisects are the ones that 
hang.

6fbcfb3e467adb414e235eeefaeaf51ad12f2461 is the first bad commit
commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
Author: David Woodhouse dw...@infradead.org
Date:   Sun Sep 25 19:11:14 2011 -0700

intel-iommu: Workaround IOTLB hang on Ironlake GPU

To work around a hardware issue, we have to submit IOTLB flushes while
the graphics engine is idle. The graphics driver will (we hope) go to
great lengths to ensure that it gets that right on the affected
chipset(s)... so let's not screw it over by deferring the unmap and
doing it later. That wouldn't be very helpful.

Signed-off-by: David Woodhouse david.woodho...@intel.com

:04 04 3d2943d67945d8321d7aa8faac7497a8e8f1412a 
afaa155acfd1a7111ee607a971013ed615582ac8 M  drivers


git bisect log:

git bisect start
# good: [899e3ee404961a90b828ad527573c39f0ab1] Linux 3.1-rc10
git bisect good 899e3ee404961a90b828ad527573c39f0ab1
# bad: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1
git bisect bad c3b92c8787367a8bb53d57d9789b558f1295cc96
# good: [505f48b53478d3816d1f3b001815703cfd7afa09] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 505f48b53478d3816d1f3b001815703cfd7afa09
# good: [5117cc25fd43add94c04c9d2ace713c69a21bdb1] Merge branch 
'hwmon-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
git bisect good 5117cc25fd43add94c04c9d2ace713c69a21bdb1
# bad: [4399c8bf2b9093696fa8160d79712e7346989c46] intel-iommu: fix superpage 
support in pfn_to_dma_pte()
git bisect bad 4399c8bf2b9093696fa8160d79712e7346989c46
# bad: [c0771df8d5297bfb9c4fbe8ada085a49cb22ec4f] intel-iommu: Export a flag 
indicating that the IOMMU is used for iGFX.
git bisect bad c0771df8d5297bfb9c4fbe8ada085a49cb22ec4f
# bad: [6fbcfb3e467adb414e235eeefaeaf51ad12f2461] intel-iommu: 
Workaround IOTLB hang on Ironlake GPUgit bisect bad 
6fbcfb3e467adb414e235eeefaeaf51ad12f2461
# good: [3e7abe2556b583e87dabda3e0e6178a67b20d06f] intel-iommu: Fix AB-BA 
lockdep report
git bisect good 3e7abe2556b583e87dabda3e0e6178a67b20d06f

-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION]: hibernate/sleep regression w/ bisection

[Andrew Watts]

On Mon, Nov 21, 2011 at 04:29:23PM -0500, Jerome Glisse wrote:
 On Mon, Nov 21, 2011 at 4:09 PM, Tejun Heo t...@kernel.org wrote:
 
  Out of curiosity, did it get somewhere?
 
  Thanks.
 
  --
  tejun
 
 
 Yeah i am pretty sure i know what's going wrong but there is no easy
 fix, there is a deadlock in the kernel when gem wait ioctl is call on
 scanout buffer and that a gpu reset happen
 
 Cheers,
 Jerome

Tejun, I was about to send a similar email asking about this; many thanks
for sharing my interest.

Jerome, sounds encouraging that you think you know what the issue is. What
are the next steps? Please let me know how I can assist on my end (code 
validation, etc.).

~ Andy

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

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Daniel Vetter]

On Tue, Nov 22, 2011 at 12:15:24PM +0200, Meelis Roos wrote:
 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
 hangs in random places while using X.
 
 Core i5 660, lspci below. Running 64-bit Debian unstable.
 
 lspci -nn
 
 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller 
 [8086:0040] (rev 02)
 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
 Integrated Graphics Controller [8086:0042] (rev 02)
 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 
 Series Chipset HECI Controller [8086:3b64] (rev 06)
 00:16.3 Serial controller [0700]: Intel Corporation 5 Series/3400 Series 
 Chipset KT Controller [8086:3b67] (rev 06)
 00:19.0 Ethernet controller [0200]: Intel Corporation 82578DM Gigabit Network 
 Connection [8086:10ef] (rev 05)
 00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
 USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset 
 High Definition Audio [8086:3b56] (rev 05)
 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
 Express Root Port 1 [8086:3b42] (rev 05)
 00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
 Express Root Port 5 [8086:3b4a] (rev 05)
 00:1c.6 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI 
 Express Root Port 7 [8086:3b4e] (rev 05)
 00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset 
 USB2 Enhanced Host Controller [8086:3b34] (rev 05)
 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] 
 (rev a5)
 00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC Interface 
 Controller [8086:3b0a] (rev 05)
 00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series 
 Chipset 6 port SATA AHCI Controller [8086:3b22] (rev 05)
 3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
 Architecture Generic Non-core Registers [8086:2c61] (rev 05)
 3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath 
 Architecture System Address Decoder [8086:2d01] (rev 05)
 3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 
 [8086:2d10] (rev 05)
 3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 
 [8086:2d11] (rev 05)
 3f:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved 
 [8086:2d12] (rev 05)
 3f:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved 
 [8086:2d13] (rev 05)
 
 
 Bisected it to the following commit. Bisection may not be 100% correct 
 because the issue happens at random, and most of the good revisions 
 got some usage without problems. The bad bisects are the ones that 
 hang.
 
 6fbcfb3e467adb414e235eeefaeaf51ad12f2461 is the first bad commit
 commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
 Author: David Woodhouse dw...@infradead.org
 Date:   Sun Sep 25 19:11:14 2011 -0700
 
 intel-iommu: Workaround IOTLB hang on Ironlake GPU
 
 To work around a hardware issue, we have to submit IOTLB flushes while
 the graphics engine is idle. The graphics driver will (we hope) go to
 great lengths to ensure that it gets that right on the affected
 chipset(s)... so let's not screw it over by deferring the unmap and
 doing it later. That wouldn't be very helpful.
 
 Signed-off-by: David Woodhouse david.woodho...@intel.com

Can you retry with Keith's latest drm-intel-fixes, please? This workaround
turned out to be a bit buggy, unfortunately. It's strange though that your
bisect ended up on this commit, so maybe it's something else. Also please
attach the full dmesg of a broken kernel (before it hangs).

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

 Subject: Regression in 3.1 causes Xen to use wrong idle routine
 Submitter  : Stefan Bader stefan.ba...@canonical.com
 Date   : 2011-10-26 10:24
 Message-ID : 4ea7dfd1.9060...@canonical.com
 References : http://marc.info/?l=linux-acpim=131962467924564w=2

The patch mentioned in 
http://mid.gmane.org/2015144004.ge22...@phenom.dumpdata.com 
should do it. But the patch needs an Ack from ACPI/x86 folks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Bug#649448: udev loading radeon drivers garbles screen output

[Alex Deucher]

On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela touko.korp...@iki.fi wrote:
 On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote:
 On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings b...@decadent.org.uk wrote:
  On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
  reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
  severity 649448 important
  retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
  firmware not installed
  tags 649448 + upstream
  quit
 
  Hi Martin,
 
  Martin von Gagern wrote:
 
   Version: 3.0.0-3
  [...]
   Just installed a wheezy setup using debootstrap, adding grub-pc and
   linux-image-amd64 after the chroot was created. The kernel boots, the
   initrd seems all right. When the main system boots up, udev gets launced
   pretty early. Soon after it is started, the screen turns into a pretty
   random-looking pattern of pixels, making the console pretty unusable.
   This also happens in recovery i.e. single-user mode.
  [...]
   Possible workarounds seem to include:
  [...]
   - Adding a line blacklist radeon to /etc/modprobe.d/blacklist.conf,
     followed by running depmod -a.
  [...]
   [  150.125768] r600_cp: Failed to load firmware radeon/SUMO2_pfp.bin
   [  150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
   [  150.125859] radeon :00:01.0: disabling GPU acceleration
 
  Yes, the radeon driver currently copes poorly when firmware is missing.
  Compare [1], [2], [3].
 
  [...]
   Not having GPU accelleration due to lack of free firmware is acceptable.
   Not having a usable text console can be a real problem.
 
  Agreed.  The radeon driver should be bailing out when firmware is
  missing for cards that need it, but that is not working for some
  reason.
  [...]
 
  At the time I converted the radeon driver to load external firmware, it
  was apparently only required for 3D acceleration and both KMS and 2D
  acceleration of X worked without it, at least on those systems I tested
  (which were quite old, R100-R300 families).  Therefore failure to load
  firmware would only result in DRM (3D acceleration support) being
  disabled.
 
  However, it looks like driver support for the R600 family onward now
  absolutely requires the 'RLC' firmware blobs:
 
  commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
  Author: Alex Deucher alexdeuc...@gmail.com
  Date:   Tue Dec 1 13:43:46 2009 -0500
 
     drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
 
  And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
  'MC' firmware blobs:
 
  commit 0af62b0168043896a042b005ff88caa77dd94d04
  Author: Alex Deucher alexdeuc...@gmail.com
  Date:   Thu Jan 6 21:19:31 2011 -0500
 
     drm/radeon/kms: add ucode loader for NI
 
  Therefore I think that at least r600_init(), rv770_init(),
  evergreen_init() and cayman_init() should be treating failure to load
  firmware as a fatal error.
 

 R6xx, r7xx should work ok without the RLC ucode, you just won't get
 acceleration.  With chips that require the MC ucode, the driver will
 bail if the MC ucode is not available.

 In what kernel versions should that be true?
 These bugs are reported that question it (some are reported against older
 kernels).
 http://bugs.debian.org/607194
 http://bugs.debian.org/637943
 http://bugs.debian.org/627497
 and also my report:
 http://bugs.debian.org/646306


Should work and well tested are different things.

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

Re: max PWM is zero

[Marcos Paulo de Souza]

Hi Keith,

On Sat, 19 Nov 2011, Keith Packard wrote:


On Sat, 19 Nov 2011 11:26:07 + (Local time zone must be set--see zic manual 
page), Marcos Paulo de Souza marcos.m...@gmail.com wrote:

So, anybody gets the same message?

I'm trying the 3.2-rc2 and it gives the same message.

Again, if you need someone to make tests, or test some patches, I'm
able to do this.


Is your machine even using the intel backlight device? You can test this
by:

# cd /sys/class/backlight/intel_backlight

Then look at 'max_brightness' and try echoing a range of numbers from 0
to max_brightness into the brightness file and see if it changes the
backlight.
My max_brightness is 1, and my brightness is 0. But, my acpi_video0 have a 
max_brightness value = 9...

It's more than possible that your machine is simply using some other
hardware to drive the backlight and that the integrated backlight
controller is simply disabled.
So, what can I do to silence this warning...? Change the driver of 
backlight?

--
keith.pack...@intel.com


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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:34 PM, Andy Lutomirski l...@amacapital.net wrote:
 On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 Subject    : [3.1 REGRESSION] Commit 
 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
 Submitter  : Nix n...@esperi.org.uk
 Date       : 2011-11-14 0:40
 Message-ID : 8762inleno@spindle.srvr.nix
 References : http://marc.info/?l=linux-kernelm=132123396226377w=2


This is apparently fixed in seccompsandbox.  See:

https://code.google.com/p/seccompsandbox/issues/detail?id=17
https://code.google.com/p/seccompsandbox/source/detail?r=178

Unless someone objects, I'll consider this to not be a kernel
regression worth fixing.

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:18 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 Subject    : hugetlb oops on 3.1.0-rc8-devel
 Submitter  : Andy Lutomirski l...@amacapital.net
 Date       : 2011-11-01 22:20
 Message-ID : 
 calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=132018604426692w=2

 Despite the subject line, that's not an oops, it's a BUG_ON().

 And it *should* be fixed by commit ea4039a34c4c (hugetlb: release
 pages in the error path of hugetlb_cow()) although I don't think Andy
 ever confirmed that (since it was hard to trigger).

I haven't seen it again, but that probably doesn't mean anything.
I've also fixed a bug in some userspace software I was running, and
that fix means I'm probably not stressing that part of the kernel
anymore.  (Even without the fix, it took two weeks to hit this.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 Subject    : [3.1 REGRESSION] Commit 
 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
 Submitter  : Nix n...@esperi.org.uk
 Date       : 2011-11-14 0:40
 Message-ID : 8762inleno@spindle.srvr.nix
 References : http://marc.info/?l=linux-kernelm=132123396226377w=2

 So this should be fixed by commit 2b666859ec32 (x86: Default to
 vsyscall=native for now), since we disabled the vsyscall emulation
 because it broken UML too.

I don't think so.  I think the issue is that the chromium sandbox is
trying to use getcpu, time, or gettimeofday from seccomp mode and the
kernel is (IMO correctly) sending it SIGKILL.  Nix can trigger the bug
in vsyscall=native mode, so it's not the emulation.  (If it's
gettimeofday, then it's definitely not a regression.  vgettimeofday
would SIGKILL in seccomp mode with any timing source other than rdtsc
or hpet even on old kernels.)

I sent a patch to show which syscall is causing SIGKILL and haven't
heard back.  Meanwhile, I'm downloading the 1.1GB (!) tarball to see
if I can reproduce it here.  Fedora's build didn't trigger it for me,
probably because the sandbox was disabled.

To try to reduce the incidence of this stuff in the future, and to
make vsyscall=none and UML more useful, I filed this bug:

http://sourceware.org/bugzilla/show_bug.cgi?id=13425

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

Re: max PWM is zero

[Lucas De Marchi]

On Mon, Nov 21, 2011 at 23:40, Keith Packard kei...@keithp.com wrote:
 On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic 
 manual page), Marcos Paulo de Souza marcos.m...@gmail.com wrote:

 My max_brightness is 1, and my brightness is 0.

 Right, we've prevented the internal backlight driver from exposing a max
 value of 0 as that's just confusing.

 But, my acpi_video0 have a
 max_brightness value = 9...

 Right, sounds like your device is just using some other backlight
 controller, which is perfectly reasonable.

 So, what can I do to silence this warning...? Change the driver of
 backlight?

 If your backlight keys work correctly, then things are fine and perhaps
 we should just remove the warning from the driver, or disable the
 internal driver when we discover this situation.

 This is the first time I've heard of this warning appearing...

It appears here as well. I think it was since 2.6.39 or 3.0, I'm not sure.

Same card:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 02bb
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f640 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 02bb
Flags: bus master, fast devsel, latency 0
Memory at f610 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3

My kernel log has:

[drm] Driver supports precise vblank timestamp query.
composite sync not supported
fixme: max PWM is zero.
composite sync not supported


Is this composite sync not supported related to this issue?


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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Srivatsa S. Bhat]

On 11/22/2011 03:19 AM, Rafael J. Wysocki wrote:
 This message contains a list of some regressions from 3.0 and 3.1
 for which there are no fixes in the mainline known to the tracking team.
 If any of them have been fixed already, please let us know.
 
 If you know of any other unresolved regressions from 3.0 and 3.1, please let 
 us
 know either and we'll add them to the list.  Also, please let us know if any 
 of
 the entries below are invalid.
 
 The entries below are simplified and the statistics are not present due to the
 continuing Bugzilla outage.
 
 Subject: iwlagn is getting very shaky
 Submitter  : Norbert Preining prein...@logic.at
 Date   : 2011-10-19 6:01
 Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
 References : http://marc.info/?l=linux-kernelm=131914553920614w=2
 
 Subject: Regression: irqpoll hasn't been working for me since March 16 
 IRQ
 Submitter  : Edward Donovan edward.dono...@numble.net
 Date   : 2011-10-19 22:09
 Message-ID : 
 CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=aaz...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=131914554220679w=2
 
 Subject: Regression in 3.1 causes Xen to use wrong idle routine
 Submitter  : Stefan Bader stefan.ba...@canonical.com
 Date   : 2011-10-26 10:24
 Message-ID : 4ea7dfd1.9060...@canonical.com
 References : http://marc.info/?l=linux-acpim=131962467924564w=2
 
 Subject: 3.1+ iwlwifi lockup
 Submitter  : Dave Jones da...@redhat.com
 Date   : 2011-10-31 14:34
 Message-ID : 20111031143408.ga17...@redhat.com
 References : http://marc.info/?l=linux-kernelm=132007169420160w=2
 
 Subject: hugetlb oops on 3.1.0-rc8-devel
 Submitter  : Andy Lutomirski l...@amacapital.net
 Date   : 2011-11-01 22:20
 Message-ID : 
 calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=132018604426692w=2
 
 Subject: Simultaneous cat and external keyboard input causing kernel panic
 Submitter  : Timo Jyrinki timo.jyri...@gmail.com
 Date   : 2011-11-03 12:14
 Message-ID : 
 CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jv...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=132032253903074w=2
 
 Subject: Linus GIT - INFO: possible circular locking dependency detected
 Submitter  : Miles Lane miles.l...@gmail.com
 Date   : 2011-11-03 15:57
 Message-ID : 
 CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2d-xmqt...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=132033587908426w=2
 
 Subject: lockdep warning after aa6afca5bcab: proc: fix races against 
 execve() of /proc/PID/fd**
 Submitter  : Ari Savolainen ari.m.savolai...@gmail.com
 Date   : 2011-11-08 3:47
 Message-ID : 
 caebykaxyzefhtgwmm2afawq2saxyuo_yptnw+6avwscoysc...@mail.gmail.com
 References : http://marc.info/?l=linux-kernelm=132072413125099w=2
 
 Subject: DMA-API check_sync errors with 3.2
 Submitter  : Josh Boyer jwbo...@redhat.com
 Date   : 2011-11-08 17:31
 Message-ID : 2008173153.ge14...@zod.bos.redhat.com
 References : http://marc.info/?l=linux-kernelm=132077357608797w=2
 
 Subject: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
 suspending
 Submitter  : Rafał Miłecki zaj...@gmail.com
 Date   : 2011-11-09 11:46
 Message-ID : 
 CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
 References : http://marc.info/?l=linux-netdevm=13208398088w=4
 
 Subject: 3.2-rc1 doesn't boot on dual socket opteron without swap
 Submitter  : Niklas Schnelle nik...@komani.de
 Date   : 2011-11-10 20:09
 Message-ID : 1320955769.1718.8.camel@jupiter
 References : http://marc.info/?l=linux-kernelm=132095583501767w=2
 
 Subject: Sparc-32 doesn't work in 3.1.
 Submitter  : Rob Landley r...@landley.net
 Date   : 2011-11-12 11:22
 Message-ID : 4ebeab5a.5020...@landley.net
 References : http://www.spinics.net/lists/kernel/msg1260383.html
 
 Subject: khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
 Submitter  : Sergei Trofimovich sly...@gmail.com
 Date   : 2011-11-12 10:48
 Message-ID : 2012104859.7744b...@sf.home
 References : https://lkml.org/lkml/2011/11/12/11
 

Andrea's patch already fixes this issue, which was reported first by
Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
I remember Andrew Morton taking this patch in his -mm tree. But it is
not in mainline yet. So can we consider this closed or not?

Thanks,
Srivatsa S. Bhat

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrea Arcangeli]

On Mon, Nov 21, 2011 at 09:59:18PM -0800, Andrew Morton wrote:
 grr, nothing in that patch's changelog indicates that it fixed a
 regression nor that it fixed an infinite blockage of suspend.

Well it's not a recent thing so I didn't flag it as a regression. It
doesn't infinite block it, suspend works fine almost all the time (or
it would have been noticed before), and if you've bad luck and it
doesn't suspend the first time around like someone experienced, if you
try again a bit later it'll work.

 I moved it to my 3.2 queue, thanks.

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

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos mr...@linux.ee wrote:

  3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
  hangs in random places while using X.

Do you have VT-d enabled in the BIOS?

-- 
keith.pack...@intel.com


pgpDDQsjBrQss.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang fengguang...@intel.com wrote:

 So the v3 patch will behave equally well on KMS console, gnome desktop
 and bare X. Shall we just use it, or go back and use the original
 -hot_remove patch?

I'm not sure why we need any change to the core DRM code. The HDMI and
DP drivers will be told when to turn the monitors on and off, and that's
the appropriate time to control whether audio is routed to them. Hotplug
is considered simply a notification to user space that something has
changed -- user space is in charge of configuring which outputs are in
use.

-- 
keith.pack...@intel.com


pgpYH4pomV8WR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Matthew Garrett]

On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:

 + /*
 +  * Only enable RC6 if all dma remapping is disabled, or if
 +  * there's no iommu present in the machine.
 +  */
 + if (INTEL_INFO(dev)-gen == 6)
 + return no_iommu || dmar_disabled;

So the user has to choose between 5W of power saving or having dmar? And 
we default to giving them dmar? I think that's going to come as a 
surprise to people.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Eugeni Dodonov]

On Tue, Nov 22, 2011 at 18:15, Matthew Garrett m...@redhat.com wrote:

 On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:

  + /*
  +  * Only enable RC6 if all dma remapping is disabled, or if
  +  * there's no iommu present in the machine.
  +  */
  + if (INTEL_INFO(dev)-gen == 6)
  + return no_iommu || dmar_disabled;

 So the user has to choose between 5W of power saving or having dmar? And
 we default to giving them dmar?


From the latest investigations, it is either this, or random gpu hangs and
crashes when both are enabled :(.

When the root cause will be discovered, we should allow both of course. But
so far, all the attempts on this weren't successful.

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Matthew Garrett]

On Tue, Nov 22, 2011 at 06:46:21PM -0200, Eugeni Dodonov wrote:
 On Tue, Nov 22, 2011 at 18:15, Matthew Garrett m...@redhat.com wrote:
 
  On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard wrote:
 
   + /*
   +  * Only enable RC6 if all dma remapping is disabled, or if
   +  * there's no iommu present in the machine.
   +  */
   + if (INTEL_INFO(dev)-gen == 6)
   + return no_iommu || dmar_disabled;
 
  So the user has to choose between 5W of power saving or having dmar? And
  we default to giving them dmar?
 
 
 From the latest investigations, it is either this, or random gpu hangs and
 crashes when both are enabled :(.

So blacklist dmar on sandybridge. The power saving is going to be more 
important for most users.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42683] [r300g] GPU lockup while playing WoW

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=42683

--- Comment #4 from Chris Rankin ranki...@googlemail.com 2011-11-22 12:57:56 
PST ---
Created attachment 53788
  -- https://bugs.freedesktop.org/attachment.cgi?id=53788
Two GPU resets while playing WoW

These two GPU resets happened in quick succession, although the kernel managed
to recover each time. (Small comfort, I suppose).

The kernel is 3.1.2, with Mesa HEAD at:

commit 034e63b9f8ee23cfac769b1a2c431bdd2307a6c4
Author: Marek Olšák mar...@gmail.com
Date:   Tue Nov 22 20:48:23 2011 +0100

r600g: handle all remaining CAPs

This does not bode well for RV350 support with Mesa 7.12.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/14] update exynos drm driver.

[InKi Dae]

Mr. Park. I rebased the drm-fixes tree.
commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc

and you can find patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm

thank you.

2011/11/14 Kyungmin Park kyungmin.p...@samsung.com:
 Hi,

 Also you can find relevant patches at git
 http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/samsung-drm

 To Mr. Dae.
 Can you rebase the latest drm-next tree or mainline to merge easily?

 Thank you,
 Kyungmin Park

 On 11/12/11, Inki Dae inki@samsung.com wrote:
 Hello, Dave. sorry but please, ignor previous patch sets posted
 by Seung-Woo Kim. I am seding patch sets again.

 this patch sets are as the following.
 - add kms poll to handle hdp event.
 - fix converting between display mode and timing.
 - fix connector and crtc callbacks to call proper display driver.
 - fix vblank bug that manager-pipe could be -1 at vsync interrupt handler.
 - add exynos_drm_gem_init() that is used commonly.
 - change buffer structure to support IOMMU in the future.
 - add comments and code clean.

 this patch is based on git repository below:
 git://people.freedesktop.org/~airlied/linux.git
 branch name: drm-fixes
 commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc

 Inki Dae (7):
   drm/exynos: added manager object to connector
   drm/exynos: changed exynos_drm_display to exynos_drm_display_ops
   drm/exynos: use gem create function generically
   drm/exynos: removed unnecessary variable.
   drm/exynos: changed buffer structure.
   drm/exynos: fix vblank bug.
   drm/exynos: include linux/module.h

 Joonyoung Shim (2):
   drm/exynos: restored kernel_fb_list when reiniting fb_helper
   drm/exynos: added crtc dpms for disable crtc

 Seung-Woo Kim (5):
   drm/exynos: added kms poll for handling hpd event
   drm/exynos: fixed connector flag with hpd and interlace scan for hdmi
   drm/exynos: fixed converting between display mode and timing
   drm/exynos: removed meaningless parameter from fbdev update
   drm/exynos: checked for null pointer

  drivers/gpu/drm/exynos/exynos_drm_buf.c       |   62 +
  drivers/gpu/drm/exynos/exynos_drm_buf.h       |   21 +-
  drivers/gpu/drm/exynos/exynos_drm_connector.c |   78 +++--
  drivers/gpu/drm/exynos/exynos_drm_crtc.c      |   76 ++--
  drivers/gpu/drm/exynos/exynos_drm_crtc.h      |   25 +++
  drivers/gpu/drm/exynos/exynos_drm_drv.c       |    5 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.h       |   11 ++--
  drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   65 ++---
  drivers/gpu/drm/exynos/exynos_drm_encoder.h   |    1 +
  drivers/gpu/drm/exynos/exynos_drm_fb.c        |   66 ++---
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c     |   44 +++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c      |   62 -
  drivers/gpu/drm/exynos/exynos_drm_gem.c       |   94
 +++--
  drivers/gpu/drm/exynos/exynos_drm_gem.h       |   28 ++--
  include/drm/exynos_drm.h                      |    9 +--
  15 files changed, 416 insertions(+), 231 deletions(-)
 --
 1.7.4.1

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

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

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

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Keith Packard]

On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:

 So the user has to choose between 5W of power saving or having dmar? And 
 we default to giving them dmar? I think that's going to come as a 
 surprise to people.

You'd have to go into the BIOS to turn this on for most machines at
least?

But, yeah, it seems like we should be turning DMAR off unless explicitly
requested; I can't understand how you'd ever need this running native on
the hardware. Not exactly an area I care about deeply; I've always
worked hard to make sure all virtualization garbage is disabled on every
machine I use.

-- 
keith.pack...@intel.com


pgpRsQVpYbb00.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: hangcheck timer elapsed

[Keith Packard]

On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds 
torva...@linux-foundation.org wrote:

 X is hung, but I can at least switch VT's and send this from a text 
 terminal..

Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the GPU which isn't moving.

Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
driver, and yes, I'm trying to fix this (by deleting code, which is
always the best way).

-- 
keith.pack...@intel.com


pgpafhKSqqRa9.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()

[Xi Wang]

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb-funcs-dirty may result
in a memory corruption.

Reported-by: Haogang Chen haogangc...@gmail.com
Signed-off-by: Xi Wang xi.w...@gmail.com
---
 drivers/gpu/drm/drm_crtc.c |4 
 include/drm/drm_mode.h |2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 405c63b..8323fc3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1873,6 +1873,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}
 
if (num_clips  clips_ptr) {
+   if (num_clips  0 || num_clips  DRM_MODE_FB_DIRTY_MAX_CLIPS) {
+   ret = -EINVAL;
+   goto out_err1;
+   }
clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
if (!clips) {
ret = -ENOMEM;
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d30bedf..ddd46db 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -235,6 +235,8 @@ struct drm_mode_fb_cmd {
 #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
 #define DRM_MODE_FB_DIRTY_FLAGS 0x03
 
+#define DRM_MODE_FB_DIRTY_MAX_CLIPS 256
+
 /*
  * Mark a region of a framebuffer as dirty.
  *
-- 
1.7.5.4

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

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

   3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
   hangs in random places while using X.

Also found out that 3.1-rc10 was already bad, will redo the bisect but 
it takes days sinc I'm not at the machine most of the time.

 Do you have VT-d enabled in the BIOS?

Yes, VT-x and VT-d are both enabled from BIOS setup.

Also, bootup dmesg from 3.2-rc2+git from when it failed silently:

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-rc2-00369-gbbbc479 (mroos@prometheus) (gcc 
version 4.6.2 (Debian 4.6.2-4) ) #14 SMP Tue Nov 22 12:41:30 EET 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-rc2-00369-gbbbc479 
root=/dev/sda1 ro
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e8000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - db7ac440 (usable)
[0.00]  BIOS-e820: db7ac440 - db7ae4a0 (ACPI NVS)
[0.00]  BIOS-e820: db7ae4a0 - e000 (reserved)
[0.00]  BIOS-e820: f400 - f800 (reserved)
[0.00]  BIOS-e820: fe00 - fed4 (reserved)
[0.00]  BIOS-e820: fed45000 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 00011800 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 
786H1 v01.05 06/09/2010
[0.00] e820 update range:  - 0001 (usable) 
== (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x118000 max_arch_pfn = 0x4
[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-E3FFF write-protect
[0.00]   E4000-E write-back
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask E write-back
[0.00]   1 base 0DB80 mask FFF80 uncachable
[0.00]   2 base 0DC00 mask FFC00 uncachable
[0.00]   3 base 0E000 mask FE000 uncachable
[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] e820 update range: db80 - 0001 (usable) 
== (reserved)
[0.00] last_pfn = 0xdb7ac max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f9bf0] f9bf0
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8809a000] 9a000 size 20480
[0.00] init_memory_mapping: -db7ac000
[0.00]  00 - 00db60 page 2M
[0.00]  00db60 - 00db7ac000 page 4k
[0.00] kernel direct mapping tables up to db7ac000 @ 1fffa000-2000
[0.00] init_memory_mapping: 0001-00011800
[0.00]  01 - 011800 page 2M
[0.00] kernel direct mapping tables up to 11800 @ db7a6000-db7ac000
[0.00] ACPI: RSDP 000e5210 00014 (v00 COMPAQ)
[0.00] ACPI: RSDT db7d0540 00044 (v01 HPQOEM SLIC-BPC 20100609  
)
[0.00] ACPI: FACP db7d05e8 00074 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI Warning: Optional field Pm2ControlBlock has zero address or 
length: 0x0050/0x0 (20110623/tbfadt-560)
[0.00] ACPI Warning: Invalid length for Pm2ControlBlock: 0, using 
default 8 (20110623/tbfadt-610)
[0.00] ACPI: DSDT db7d0a4f 0A69E (v01 COMPAQ DSDT_PRJ 0001 
MSFT 010E)
[0.00] ACPI: FACS db7d0500 00040
[0.00] ACPI: APIC db7d065c 000BC (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: ASF! db7d0718 00063 (v32 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: MCFG db7d077b 0003C (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: TCPA db7d07b7 00032 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: SLIC db7d07e9 00176 (v01 HPQOEM SLIC-BPC 0001  
)
[0.00] ACPI: HPET db7d095f 00038 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: DMAR db7d0997 000B8 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: Local APIC address 0xfee0
[0.00]  [ea00-ea00045f] PMD - 
[88011380-8801175f] 

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafał Miłecki]

W dniu 21 listopada 2011 23:22 użytkownik Linus Torvalds
torva...@linux-foundation.org napisał:
 On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki r...@sisk.pl wrote:

 Subject    : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
 suspending
 Submitter  : Rafał Miłecki zaj...@gmail.com
 Date       : 2011-11-09 11:46
 Message-ID : 
 CACna6ryTdLcWVYgHu=_mrfga1sfivpe_dyzoy-hmmkggkwa...@mail.gmail.com
 References : http://marc.info/?l=linux-netdevm=13208398088w=4

 This should be fixed by commit 1401a8008a09 (sky2: fix hang on
 shutdown (and other irq issues)) in current -git.

This patch doesn't fix my hang.

However git contains also:
sky2: fix hang in napi_disable
This is the one fixing my case.

So the bug is resolved, however I'm a little disappointed noone
ping-ed me about that patches. I've spent some time on bisecting this
issue, expected to get some response :/

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

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Keith Packard]

On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos mr...@linux.ee wrote:

 Yes, VT-x and VT-d are both enabled from BIOS setup.

Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with intel_iommu=off and make sure that's stable.

-- 
keith.pack...@intel.com


pgpI2xpV2z070.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel