general protection fault on ttm_init()

... The missed kconfig. On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote: > Hi Thomas, > > I got this error while running kvm boot tests on linux-next. > Attached is the kconfig. > > [7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri > [7.067443] general

general protection fault on ttm_init()

Hi Thomas, I got this error while running kvm boot tests on linux-next. Attached is the kconfig. [7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri [7.067443] general protection fault: [#1] PREEMPT [7.068713] CPU 0 [7.068713] Pid: 1, comm: swapper Not tainted

general protection fault on ttm_init()

part -- A non-text attachment was scrubbed... Name: 0001-drm-fail-gracefully-when-proc-isn-t-setup.patch Type: application/octet-stream Size: 892 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120706/5915005f/attachment.obj>

Suspend/resume/suspend broken in Linux 3.5-rc5

Hi, I'm sorry having to report that I'm only able to suspend once with Linux 3.5-rc5; any subsequent attempts fail. This is a regression from 3.4 where suspend/resume worked flawlessly and arbitrarily often on my machine. Bisection show that the problem was introduced in commit c420b2dc8dc:

[PATCH 2/2] drm/exynos: Modifying exynos drm fimd to support exynos5

From: Prathyush K The name of the exynos drm fimd device is renamed to exynos-drm-fimd and two ids are created for exynos4-fb and exynos5-fb. Signed-off-by: Prathyush K diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c

[PATCH 1/2] video: drm: exynos: Add device tree support

Add device tree based discovery support for DRM-FIMD driver. Signed-off-by: Leela Krishna Amudala diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 29fdbfe..37769cf 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++

[PATCH 0/2] video: drm: Add Device tree support to DRM-FIMD

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. It includes parsing platform data from dts file. This patchset is based and tested on top of v3.5-rc4. Leela Krishna Amudala (1): video: drm: exynos: Add device tree support Prathyush K (1): drm/exynos: Modifying

general protection fault on ttm_init()

On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote: > ... The missed kconfig. > > On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote: >> Hi Thomas, Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it looks like the error path is failing to dtrt. Dave.

Linux 3.2: After resume screen only turned on after switching terminals

Am Freitag, den 06.07.2012, 17:34 +0200 schrieb Paul Menzel: > Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher: > > On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote: > > > Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher: > > >> On Wed, Jul 4, 2012 at 9:41 AM, Paul

Linux 3.2: After resume screen only turned on after switching terminals

:08 debian-host acpid: client connected from > >> >> 8677[0:0] > >> >> Jun 29 19:45:08 debian-host acpid: 1 client rule loaded > >> > > >> > Does someone have an idea what the problem might be and how to fix it? > >> > >> Is this a regression? If so can you bisect? > > > > I do not think so. But the problem is I just got that board, have only > > used it with Linux 3.2.x (from Debian Sid/unstable) and this issue is > > not reproducible, that means, it happens in less then 5(?) percent of > > the suspend and resume cycles. > > > > Any idea what these acpid messages could mean? It just happened again. This time with the monitor not getting any signal. Switching to other virtual terminals does not work. What debug levels should I increase? Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120706/a1cf625c/attachment.pgp>

[RFC 2/2] drm: Add SoC skeleton driver

soc_ioctl, + .release = drm_soc_release, +}; + +static struct drm_driver soc_drm = { + .driver_features = DRIVER_MODESET | DRIVER_GEM, + .load = soc_drm_load, + .unload = soc_drm_unload, + .open = soc_drm_open, + .preclose = soc_drm_preclose, + .lastclose = soc_drm_las

[RFC 1/2] drm: Add SoC framework

This commit adds an initial framework that can be used to plug SoC graphics devices into the DRM/KMS subsystem. SoCs often don't have a dedicated device to which a DRM driver can bind, but instead the graphics complex typically consists of several platform- type devices that work together. The

[RFC 0/2] Add DRM SoC framework

This series adds an initial framework that allows to register a graphics complex as found on many SoCs with the DRM/KMS subsystem. Patch 1 adds the actual framework and patch 2 implements a very rudimentary skeleton driver on top of it. It's really just to show off how to use the DRM/SoC API and

[PATCH, RFC] i.MX DRM support

On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote: > On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: > > Hi All, > > > > The following is the state-of-the-art i.MX IPU (Image Processing Unit) > > DRM support. > > > > This code is around for quite some time now and has

[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #1 from Michel D?nzer 2012-07-06 08:25:03 PDT --- FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex shaders. Possibly related to constantly changing fixed-function emulation shaders, UT2004 seems to burn

[Bug 51787] New: performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 Bug #: 51787 Summary: performance regression with llvm shader compiler in ut2004 Classification: Unclassified Product: Mesa Version: git Platform: Other

Tegra DRM device tree bindings

On 07/05/2012 06:15 AM, Thierry Reding wrote: > Here's a new proposal that should address all issues collected > during the discussion of the previous one: > > From tegra20.dtsi: ... At a quick glance, that all seems pretty reasonable now. > One problem I've come across when trying to get some

Tegra DRM device tree bindings

> From: linux-tegra-owner at vger.kernel.org [mailto:linux-tegra- > owner at vger.kernel.org] On Behalf Of Thierry Reding > Sent: Thursday, July 05, 2012 8:15 PM > To: linux-tegra at vger.kernel.org > Cc: devicetree-discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org > Subject: Re:

[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450

https://bugzilla.kernel.org/show_bug.cgi?id=44121 --- Comment #15 from Alex Deucher 2012-07-06 13:13:17 --- That's the problem with GPU drivers. It's impossible to test every combination of userspace and kernel drivers and there can be very subtle bugs with certain combinations like this

[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450

https://bugzilla.kernel.org/show_bug.cgi?id=44121 Jean Delvare changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450

https://bugzilla.kernel.org/show_bug.cgi?id=44121 Jean Delvare changed: What|Removed |Added Attachment #74771|0 |1 is obsolete|

[PATCH] drm/radeon: add an exclusive lock for GPU reset v2

On 02.07.2012 18:45, j.glisse at gmail.com wrote: > From: Jerome Glisse > > GPU reset need to be exclusive, one happening at a time. For this > add a rw semaphore so that any path that trigger GPU activities > have to take the semaphore as a reader thus allowing concurency. > > The GPU reset path

[PATCH 1/2] video: drm: exynos: Add device tree support

Hi, On Fri, Jul 6, 2012 at 5:28 AM, Leela Krishna Amudala wrote: > > Add device tree based discovery support for DRM-FIMD driver. > > Signed-off-by: Leela Krishna Amudala This also needs to be sent to devicetree-discuss at lists.ozlabs.org, and the device tree bindings need to be documented

Re: [bisected] nouveau: Failed to idle channel x after resume

On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote: after resuming from suspend nouveau starts writing Failed to idle channel x (where x is 2 or 3) to the log and X appears to stop and then restart only to stop again. Starting Firefox after resuming triggers the bugs every time, and

[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450

https://bugzilla.kernel.org/show_bug.cgi?id=44121 Jean Delvare kh...@linux-fr.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450

https://bugzilla.kernel.org/show_bug.cgi?id=44121 --- Comment #15 from Alex Deucher alexdeuc...@gmail.com 2012-07-06 13:13:17 --- That's the problem with GPU drivers. It's impossible to test every combination of userspace and kernel drivers and there can be very subtle bugs with certain

[RFC 0/2] Add DRM SoC framework

This series adds an initial framework that allows to register a graphics complex as found on many SoCs with the DRM/KMS subsystem. Patch 1 adds the actual framework and patch 2 implements a very rudimentary skeleton driver on top of it. It's really just to show off how to use the DRM/SoC API and

[RFC 1/2] drm: Add SoC framework

This commit adds an initial framework that can be used to plug SoC graphics devices into the DRM/KMS subsystem. SoCs often don't have a dedicated device to which a DRM driver can bind, but instead the graphics complex typically consists of several platform- type devices that work together. The

[RFC 2/2] drm: Add SoC skeleton driver

, + .name = soc-drm, + .desc = SoC DRM driver, + .date = 20120706, + .major = 0, + .minor = 0, + .patchlevel = 0, +}; + +static int __init soc_drm_init(void) +{ + int ret = 0; + + pr_debug( %s()\n, __func__); + + ret = drm_soc_init(soc_drm, soc

[Bug 51787] New: performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 Bug #: 51787 Summary: performance regression with llvm shader compiler in ut2004 Classification: Unclassified Product: Mesa Version: git Platform: Other

general protection fault on ttm_init()

Hi Thomas, I got this error while running kvm boot tests on linux-next. Attached is the kconfig. [7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri [7.067443] general protection fault: [#1] PREEMPT [7.068713] CPU 0 [7.068713] Pid: 1, comm: swapper Not tainted

[Bug 51787] performance regression with llvm shader compiler in ut2004

https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-07-06 08:25:03 PDT --- FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex shaders. Possibly related to constantly changing fixed-function emulation shaders,

Re: Linux 3.2: After resume screen only turned on after switching terminals

Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher: On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote: Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher: On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote: Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul

Suspend/resume/suspend broken in Linux 3.5-rc5

Hi, I'm sorry having to report that I'm only able to suspend once with Linux 3.5-rc5; any subsequent attempts fail. This is a regression from 3.4 where suspend/resume worked flawlessly and arbitrarily often on my machine. Bisection show that the problem was introduced in commit c420b2dc8dc:

Re: general protection fault on ttm_init()

On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu fengguang...@intel.com wrote: ... The missed kconfig. On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote: Hi Thomas, Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it looks like the error path is failing to dtrt.

Re: general protection fault on ttm_init()

On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie airl...@gmail.com wrote: On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu fengguang...@intel.com wrote: ... The missed kconfig. On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote: Hi Thomas, Wierd, I'm sorta tempted to just depend drm on

[PATCH] gma500: move the ASLE enable

From: Alan Cox a...@linux.intel.com Otherwise we end up getting the masks wrong, can get events before we are doing power control and other ungood things. Signed-off-by: Alan Cox a...@linux.intel.com --- drivers/gpu/drm/gma500/opregion.c |8 +++- drivers/gpu/drm/gma500/opregion.h |

[PATCH 0/2] video: drm: Add Device tree support to DRM-FIMD

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. It includes parsing platform data from dts file. This patchset is based and tested on top of v3.5-rc4. Leela Krishna Amudala (1): video: drm: exynos: Add device tree support Prathyush K (1): drm/exynos: Modifying

[PATCH 1/2] video: drm: exynos: Add device tree support

Add device tree based discovery support for DRM-FIMD driver. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 29fdbfe..37769cf 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c

[PATCH 2/2] drm/exynos: Modifying exynos drm fimd to support exynos5

From: Prathyush K prathyus...@samsung.com The name of the exynos drm fimd device is renamed to exynos-drm-fimd and two ids are created for exynos4-fb and exynos5-fb. Signed-off-by: Prathyush K prathyus...@samsung.com diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c

Re: [PATCH 1/2] video: drm: exynos: Add device tree support

Hi, On Fri, Jul 6, 2012 at 5:28 AM, Leela Krishna Amudala l.kris...@samsung.com wrote: Add device tree based discovery support for DRM-FIMD driver. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com This also needs to be sent to devicetree-disc...@lists.ozlabs.org, and the device

Re: Tegra DRM device tree bindings

On 07/05/2012 06:15 AM, Thierry Reding wrote: Here's a new proposal that should address all issues collected during the discussion of the previous one: From tegra20.dtsi: ... At a quick glance, that all seems pretty reasonable now. One problem I've come across when trying to get some

Re: [PATCH, RFC] i.MX DRM support

On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote: On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote: Hi All, The following is the state-of-the-art i.MX IPU (Image Processing Unit) DRM support. This code is around for quite some time now and has been posted

Re: general protection fault on ttm_init()

On Fri, Jul 06, 2012 at 06:09:20PM +0100, Dave Airlie wrote: On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie airl...@gmail.com wrote: On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu fengguang...@intel.com wrote: ... The missed kconfig. On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu

Re: [PATCH 1/2] video: drm: exynos: Add device tree support

Hi, On Fri, Jul 6, 2012 at 9:28 PM, Leela Krishna Amudala l.kris...@samsung.com wrote: Add device tree based discovery support for DRM-FIMD driver. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c