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 
> 
> 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: sta...@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 = &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 
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, &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 = drm_helper_probe_single_connector_modes,
.

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

[bugzilla-daemon]

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

Pavel Ondračka  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  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 
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 (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  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 
> 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: 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

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

[bugzilla-daemon]

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.
___
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 
> Date   : 2011-10-26 10:24
> Message-ID : 4ea7dfd1.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=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  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
___
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  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  wrote:
> On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
>  wrote:
>> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>>
>>> Subject    : [3.1 REGRESSION] Commit 
>>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>>> Submitter  : Nix 
>>> Date       : 2011-11-14 0:40
>>> Message-ID : 8762inleno@spindle.srvr.nix
>>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : hugetlb oops on 3.1.0-rc8-devel
>> Submitter  : Andy Lutomirski 
>> Date       : 2011-11-01 22:20
>> Message-ID : 
>> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : [3.1 REGRESSION] Commit 
>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter  : Nix 
>> Date       : 2011-11-14 0:40
>> Message-ID : 8762inleno@spindle.srvr.nix
>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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  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
___
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 
> Date   : 2011-10-19 6:01
> Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=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=aaz...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=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.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
> 
> Subject: 3.1+ iwlwifi lockup
> Submitter  : Dave Jones 
> Date   : 2011-10-31 14:34
> Message-ID : 20111031143408.ga17...@redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
> 
> Subject: hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date   : 2011-11-01 22:20
> Message-ID : 
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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=jv...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=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-xmqt...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=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+6avwscoysc...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
> 
> Subject: DMA-API check_sync errors with 3.2
> Submitter  : Josh Boyer 
> Date   : 2011-11-08 17:31
> Message-ID : 2008173153.ge14...@zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=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-hmmkggkwa...@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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@jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
> 
> Subject: Sparc-32 doesn't work in 3.1.
> Submitter  : Rob Landley 
> 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 
> 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: 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
___
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  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  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  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

___
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  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  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.
___
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 :
> 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  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 00/14] update exynos drm driver.

[InKi Dae]

Hello, Dave.

I had posted DRM Driver patchsets for Exsynos SoC but there is no any
feedback. could you please review them? and if the patchsets have any
problem, please give me your advice anytime. and also we are ready for
next patchsets.

the next patchsets include the followings:
- fix some previous patchset bugs.
- add power managerment featrue based on runtim-pm.

from next patchset, I would request GIT PULL if you are ok.

Thank you,
Inki Dae.

2011/11/12 Inki Dae :
> 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

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  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 
 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 
Signed-off-by: Xi Wang 
---
 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-880117

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
 napisał:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> 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-hmmkggkwa...@mail.gmail.com
>> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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  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

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 
> 
> 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: sta...@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 = &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 
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, &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 = drm_helper_probe_single_connector_modes,
.

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

[bugzilla-daemon]

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

Pavel Ondračka  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  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 
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 (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  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 
> 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: 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

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

[bugzilla-daemon]

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.
___
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 
> Date   : 2011-10-26 10:24
> Message-ID : 4ea7dfd1.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=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  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
___
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  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  wrote:
> On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
>  wrote:
>> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>>
>>> Subject    : [3.1 REGRESSION] Commit 
>>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>>> Submitter  : Nix 
>>> Date       : 2011-11-14 0:40
>>> Message-ID : 8762inleno@spindle.srvr.nix
>>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : hugetlb oops on 3.1.0-rc8-devel
>> Submitter  : Andy Lutomirski 
>> Date       : 2011-11-01 22:20
>> Message-ID : 
>> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : [3.1 REGRESSION] Commit 
>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter  : Nix 
>> Date       : 2011-11-14 0:40
>> Message-ID : 8762inleno@spindle.srvr.nix
>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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  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
___
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 
> Date   : 2011-10-19 6:01
> Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=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=aaz...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=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.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
> 
> Subject: 3.1+ iwlwifi lockup
> Submitter  : Dave Jones 
> Date   : 2011-10-31 14:34
> Message-ID : 20111031143408.ga17...@redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
> 
> Subject: hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date   : 2011-11-01 22:20
> Message-ID : 
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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=jv...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=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-xmqt...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=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+6avwscoysc...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
> 
> Subject: DMA-API check_sync errors with 3.2
> Submitter  : Josh Boyer 
> Date   : 2011-11-08 17:31
> Message-ID : 2008173153.ge14...@zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=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-hmmkggkwa...@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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@jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
> 
> Subject: Sparc-32 doesn't work in 3.1.
> Submitter  : Rob Landley 
> 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 
> 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: 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
___
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  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  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  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

___
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  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  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.
___
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 :
> 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  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 00/14] update exynos drm driver.

[InKi Dae]

Hello, Dave.

I had posted DRM Driver patchsets for Exsynos SoC but there is no any
feedback. could you please review them? and if the patchsets have any
problem, please give me your advice anytime. and also we are ready for
next patchsets.

the next patchsets include the followings:
- fix some previous patchset bugs.
- add power managerment featrue based on runtim-pm.

from next patchset, I would request GIT PULL if you are ok.

Thank you,
Inki Dae.

2011/11/12 Inki Dae :
> 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

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  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 
 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 
Signed-off-by: Xi Wang 
---
 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-880117

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
 napisał:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> 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-hmmkggkwa...@mail.gmail.com
>> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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  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

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 
> 
> 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: sta...@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 = &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 
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, &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 = drm_helper_probe_single_connector_modes,
.

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

[bugzilla-daemon]

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

Pavel Ondračka  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  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 
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 (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  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 
> 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: 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

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

[bugzilla-daemon]

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.
___
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 
> Date   : 2011-10-26 10:24
> Message-ID : 4ea7dfd1.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=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  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
___
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  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  wrote:
> On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
>  wrote:
>> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>>
>>> Subject    : [3.1 REGRESSION] Commit 
>>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>>> Submitter  : Nix 
>>> Date       : 2011-11-14 0:40
>>> Message-ID : 8762inleno@spindle.srvr.nix
>>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : hugetlb oops on 3.1.0-rc8-devel
>> Submitter  : Andy Lutomirski 
>> Date       : 2011-11-01 22:20
>> Message-ID : 
>> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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
 wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject    : [3.1 REGRESSION] Commit 
>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter  : Nix 
>> Date       : 2011-11-14 0:40
>> Message-ID : 8762inleno@spindle.srvr.nix
>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=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  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
___
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 
> Date   : 2011-10-19 6:01
> Message-ID : 20111019060108.ga11...@gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=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=aaz...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=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.9060...@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
> 
> Subject: 3.1+ iwlwifi lockup
> Submitter  : Dave Jones 
> Date   : 2011-10-31 14:34
> Message-ID : 20111031143408.ga17...@redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
> 
> Subject: hugetlb oops on 3.1.0-rc8-devel
> Submitter  : Andy Lutomirski 
> Date   : 2011-11-01 22:20
> Message-ID : 
> calcetrw1mpvcz2to5roaz1r6vnno+srhr-dha6_pkri2qic...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=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=jv...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=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-xmqt...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=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+6avwscoysc...@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
> 
> Subject: DMA-API check_sync errors with 3.2
> Submitter  : Josh Boyer 
> Date   : 2011-11-08 17:31
> Message-ID : 2008173153.ge14...@zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=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-hmmkggkwa...@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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@jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
> 
> Subject: Sparc-32 doesn't work in 3.1.
> Submitter  : Rob Landley 
> 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 
> 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: 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
___
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  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  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  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

___
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  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  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.
___
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 :
> 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  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 00/14] update exynos drm driver.

[InKi Dae]

Hello, Dave.

I had posted DRM Driver patchsets for Exsynos SoC but there is no any
feedback. could you please review them? and if the patchsets have any
problem, please give me your advice anytime. and also we are ready for
next patchsets.

the next patchsets include the followings:
- fix some previous patchset bugs.
- add power managerment featrue based on runtim-pm.

from next patchset, I would request GIT PULL if you are ok.

Thank you,
Inki Dae.

2011/11/12 Inki Dae :
> 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

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  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 
 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 
Signed-off-by: Xi Wang 
---
 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-880117

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
 napisał:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> 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-hmmkggkwa...@mail.gmail.com
>> References : http://marc.info/?l=linux-netdev&m=13208398088&w=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  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

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 
> 
> 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: sta...@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 = &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 
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, &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 = drm_helper_probe_single_connector_modes,
.

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

[bugzilla-daemon]

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

Pavel Ondračka  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  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 
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 (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  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 
> 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: 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

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

[bugzilla-daemon]

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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel