[PATCH 01/11] drm: add drm_send_vblank_event() helper
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
>
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_irq.c | 65
> +
> include/drm/drmP.h|2 ++
> 2 files changed, 44 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 076c4a8..7a00d94 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -802,6 +802,43 @@ u32 drm_vblank_count_and_time(struct drm_device *dev,
> int crtc,
> }
> EXPORT_SYMBOL(drm_vblank_count_and_time);
>
> +static void send_vblank_event(struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now)
> +{
> + e->event.sequence = seq;
> + e->event.tv_sec = now->tv_sec;
> + e->event.tv_usec = now->tv_usec;
> +
> + list_add_tail(&e->base.link,
> + &e->base.file_priv->event_list);
> + wake_up_interruptible(&e->base.file_priv->event_wait);
> + trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> + e->event.sequence);
> +}
> +
> +/**
> + * drm_send_vblank_event - helper to send vblank event after pageflip
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + * @e: the event to send
> + *
> + * Updates sequence # and timestamp on event, and sends it to userspace.
> + */
> +void drm_send_vblank_event(struct drm_device *dev, int crtc,
> + struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> + if (crtc >= 0) {
> + seq = drm_vblank_count_and_time(dev, crtc, &now);
> + } else {
> + seq = 0;
> + do_gettimeofday(&now);
> + }
> + send_vblank_event(e, seq, &now);
> +}
> +EXPORT_SYMBOL(drm_send_vblank_event);
> +
> /**
> * drm_update_vblank_count - update the master vblank counter
> * @dev: DRM device
> @@ -955,15 +992,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> DRM_DEBUG("Sending premature vblank event on disable: \
> wanted %d, current %d\n",
> e->event.sequence, seq);
> -
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->event.sequence);
> + send_vblank_event(e, seq, &now);
> }
>
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> @@ -1107,15 +1138,8 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, int pipe,
>
> e->event.sequence = vblwait->request.sequence;
> if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> drm_vblank_put(dev, pipe);
> - list_add_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - vblwait->reply.sequence = seq;
D?j? vu
http://lists.freedesktop.org/archives/dri-devel/2011-April/010693.html
:)
> - trace_drm_vblank_event_delivered(current->pid, pipe,
> - vblwait->request.sequence);
> + send_vblank_event(e, seq, &now);
> } else {
> /* drm_handle_vblank_events will call drm_vblank_put */
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> @@ -1256,14 +1280,9 @@ static void drm_handle_vblank_events(struct drm_device
> *dev, int crtc)
> DRM_DEBUG("vblank event on %d, current %d\n",
> e->event.sequence, seq);
>
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->even
[PATCH 00/11] page-flip cleanups and fixes
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote: > From: Rob Clark > > Add a helper fxn to send vblank event after pageflip, plus a handful > of fixes for other issues that I noticed in the process. FWIW, patches 1-5 and 7 (with a fix to 1st) are: Reviewed-by: Marcin Slusarz > > Other than OMAP, the changes are just compile tested, so would be > good to get a quick look from the maintainers of various drivers. > > Rob Clark (11): > drm: add drm_send_vblank_event() helper > drm/i915: use drm_send_vblank_event() helper > drm/nouveau: use drm_send_vblank_event() helper > drm/radeon: use drm_send_vblank_event() helper > drm/exynos: use drm_send_vblank_event() helper > drm/exynos: page flip fixes > drm/shmob: use drm_send_vblank_event() helper > drm/imx: use drm_send_vblank_event() helper > drm/imx: page flip fixes > drm/omap: use drm_send_vblank_event() helper > drm/omap: page-flip fixes > > drivers/gpu/drm/drm_irq.c | 65 > +++-- > drivers/gpu/drm/exynos/exynos_drm_crtc.c |1 - > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 + > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 + > drivers/gpu/drm/exynos/exynos_mixer.c |9 +--- > drivers/gpu/drm/i915/intel_display.c | 15 +-- > drivers/gpu/drm/nouveau/nouveau_display.c | 13 +- > drivers/gpu/drm/radeon/radeon_display.c | 13 ++ > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 19 ++--- > drivers/staging/imx-drm/ipuv3-crtc.c | 32 -- > drivers/staging/omapdrm/omap_crtc.c | 37 > include/drm/drmP.h|2 + > 12 files changed, 78 insertions(+), 148 deletions(-) > > --
[PATCH 01/11] drm: add drm_send_vblank_event() helper (v3)
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
>
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
>
> v1: original
> v2: add back 'vblwait->reply.sequence = seq' which should not have
> been deleted
> v3: add WARN_ON() in case lock is not held and comments
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_irq.c | 74
> +++--
> include/drm/drmP.h|2 ++
> 2 files changed, 54 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 076c4a8..d623a06 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev,
> int crtc,
> }
> EXPORT_SYMBOL(drm_vblank_count_and_time);
>
> +static void send_vblank_event(struct drm_device *dev,
> + struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now)
> +{
> + WARN_ON(!spin_is_locked(&dev->event_lock));
This should be WARN_ON_SMP - on !SMP && !DEBUG_SPINLOCK spin_is_locked always
returns 0.
> + e->event.sequence = seq;
> + e->event.tv_sec = now->tv_sec;
> + e->event.tv_usec = now->tv_usec;
> +
> + list_add_tail(&e->base.link,
> + &e->base.file_priv->event_list);
> + wake_up_interruptible(&e->base.file_priv->event_wait);
> + trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> + e->event.sequence);
> +}
> +
> +/**
> + * drm_send_vblank_event - helper to send vblank event after pageflip
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + * @e: the event to send
> + *
> + * Updates sequence # and timestamp on event, and sends it to userspace.
> + * Caller must hold event lock.
> + */
> +void drm_send_vblank_event(struct drm_device *dev, int crtc,
> + struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> + if (crtc >= 0) {
> + seq = drm_vblank_count_and_time(dev, crtc, &now);
> + } else {
> + seq = 0;
> + do_gettimeofday(&now);
> + }
> + send_vblank_event(dev, e, seq, &now);
> +}
> +EXPORT_SYMBOL(drm_send_vblank_event);
> +
> /**
> * drm_update_vblank_count - update the master vblank counter
> * @dev: DRM device
> @@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> }
> EXPORT_SYMBOL(drm_vblank_put);
>
> +/**
> + * drm_vblank_off - disable vblank events on a CRTC
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + *
> + * Caller must hold event lock.
> + */
> void drm_vblank_off(struct drm_device *dev, int crtc)
> {
> struct drm_pending_vblank_event *e, *t;
> @@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> DRM_DEBUG("Sending premature vblank event on disable: \
> wanted %d, current %d\n",
> e->event.sequence, seq);
> -
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->event.sequence);
> + send_vblank_event(dev, e, seq, &now);
> }
>
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> @@ -1107,15 +1148,9 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, int pipe,
>
> e->event.sequence = vblwait->request.sequence;
> if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> drm_vblank_put(dev, pipe);
> - list_add_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> + send_vblank_event(dev, e, seq, &now);
> vblwait->reply.sequence = seq;
> - trace_drm_vblank_event_delivered(current->pid, pipe,
> - vblwait->request.sequence);
> } else {
> /* drm_handle_vblank_events will call drm_vblank_put */
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> @@ -125
[PATCH] drm/debugfs: remove redundant info from gem_names
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs", which wrongly converted DRM_INFO + sprintf to 2 seq_printfs. Signed-off-by: Marcin Slusarz Cc: Ben Gamari Cc: Eric Anholt --- drivers/gpu/drm/drm_info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index 8928edb..d498ec7 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -204,8 +204,6 @@ static int drm_gem_one_name_info(int id, void *ptr, void *data) struct drm_gem_object *obj = ptr; struct seq_file *m = data; - seq_printf(m, "name %d size %zd\n", obj->name, obj->size); - seq_printf(m, "%6d %8zd %7d %8d\n", obj->name, obj->size, atomic_read(&obj->handle_count), -- 1.7.12
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote:
>
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
>
> Yes, of course.
>
> Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
---
From: Marcin Slusarz
Subject: [PATCH] drm/nouveau: validate vbios size
Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.
Reported-by: Heinz Diehl
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
data = of_get_property(dn, "NVDA,BMP", &size);
- if (data) {
+ if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
bios->size = nv_rd08(bios, 0x72) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+ if (!bios->size)
+ return;
bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
static int
nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
{
- if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+ if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+ bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}
- if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+ if (nvbios_checksum(bios->data,
+ min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
--
1.7.12
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote:
> >
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> >
> > Yes, of course.
> >
> > Tried it. Unfortunately, the crash remains the same as reported.
>
> Try this one.
>
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
>
> ---
> From: Marcin Slusarz
> Subject: [PATCH] drm/nouveau: validate vbios size
>
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
>
> Reported-by: Heinz Diehl
And of course:
Reported-by: Pawe? Sikora
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
> }
>
> data = of_get_property(dn, "NVDA,BMP", &size);
> - if (data) {
> + if (data && size) {
> bios->size = size;
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
> goto out;
>
> bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>
> /* read entire bios image to system memory */
> bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> bios->size = 0;
> if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
> static int
> nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
> {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
> nv_info(bios, "... signature not found\n");
> return 0;
> }
>
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
> nv_info(bios, "... checksum invalid\n");
> /* if a ro image is somewhat bad, it's probably all rubbish */
> return writeable ? 2 : 1;
> --
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > On 20.10.2012, Marcin Slusarz wrote: > > > Try this one. > > It works, now I can boot again. However, nouveau seems to be dead now. > The dmesg output with your patch on top of 3.7-rc1 is: > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > end of region [VROM] (length 24) (20120913/exfldio-210) > [3.704139] ACPI Error: Method parse/execution > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > AE_AML_REGION_LIMIT (20120913/psparse-536) > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... > [3.724111] nouveau :01:00.0: Invalid ROM contents > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, > -22 > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > [3.740523] dracut: Starting plymouth daemon > > And here's the same output with plain vanilla 3.6.2: > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > (0x0a8800b1) > [3.599783] vga_switcheroo: enabled > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > VBIOS init tables. > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > offset 0xDECD > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > offset 0xE378 > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > offset 0xEF4B > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > offset 0xEF64 > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > offset 0xF04B > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset > 0xF0B0 > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > [4.019438] [TTM] Initializing pool allocator > [4.020694] [TTM] Initializing DMA pool allocator > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [4.084909] [drm] No driver support for vblank timestamp query. > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface > available, not register
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote: > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > > On 20.10.2012, Marcin Slusarz wrote: > > > > > Try this one. > > > > It works, now I can boot again. However, nouveau seems to be dead now. > > The dmesg output with your patch on top of 3.7-rc1 is: > > > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for > > image... > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > > end of region [VROM] (length 24) (20120913/exfldio-210) > > [3.704139] ACPI Error: Method parse/execution > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > > AE_AML_REGION_LIMIT (20120913/psparse-536) > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for > > image... > > [3.724111] nouveau :01:00.0: Invalid ROM contents > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable > > image > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create > > 0x1001, -22 > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > > [3.740523] dracut: Starting plymouth daemon > > > > And here's the same output with plain vanilla 3.6.2: > > > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > > (0x0a8800b1) > > [3.599783] vga_switcheroo: enabled > > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > > VBIOS init tables. > > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > > offset 0xDECD > > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > > offset 0xE378 > > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > > offset 0xEF4B > > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > > offset 0xEF64 > > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > > offset 0xF04B > > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at > > offset 0xF0B0 > > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > > [4.019438] [TTM] Initializing p
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> minor 0
> [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001,
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios->size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+ kfree(data);
if (!bios->size)
return;
---
Please attach acpidump output.
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Pawe? Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.90
Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin
[PATCH] libkms: link against libdrm
Signed-off-by: Marcin Slusarz --- libkms/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libkms/Makefile.am b/libkms/Makefile.am index fa379a4..215450a 100644 --- a/libkms/Makefile.am +++ b/libkms/Makefile.am @@ -6,7 +6,7 @@ AM_CFLAGS = \ libkms_la_LTLIBRARIES = libkms.la libkms_ladir = $(libdir) libkms_la_LDFLAGS = -version-number 1:0:0 -no-undefined -libkms_la_LIBADD = +libkms_la_LIBADD = ../libdrm.la #if HAVE_LIBUDEV #libkms_la_LIBADD += $(LIBUDEV_LIBS) -- 1.7.12
[PATCH 1/3] fbmem: fix aperture overlapping check
fb_do_apertures_overlap is returning wrong value when one aperture
is completely whithin the other. Add generic ranges_overlap macro
(probably kernel.h candidate) and use it here.
Signed-off-by: Marcin Slusarz
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
drivers/video/fbmem.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index a15b44e..41f2e5e 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1468,15 +1468,25 @@ static int fb_check_foreignness(struct fb_info *fi)
return 0;
}
+/**
+ * ranges_overlap - check whether two ranges overlap (their intersection is
not empty)
+ * @start1: start of the first range
+ * @size1: length of the first range
+ * @start2: start of the second range
+ * @size2: length of the second range
+ */
+#define ranges_overlap(start1, size1, start2, size2) ({\
+ typeof(start1) __start1 = (start1); \
+ typeof(size1) __size1 = (size1); \
+ typeof(start2) __start2 = (start2); \
+ typeof(size2) __size2 = (size2); \
+ __start1 < __start2 + __size2 && __start1 + __size1 > __start2; \
+})
+
static bool fb_do_apertures_overlap(struct fb_info *gen, struct fb_info *hw)
{
- /* is the generic aperture base the same as the HW one */
- if (gen->aperture_base == hw->aperture_base)
- return true;
- /* is the generic aperture base inside the hw base->hw base+size */
- if (gen->aperture_base > hw->aperture_base && gen->aperture_base <=
hw->aperture_base + hw->aperture_size)
- return true;
- return false;
+ return ranges_overlap(gen->aperture_base, gen->aperture_size,
+ hw->aperture_base, hw->aperture_size);
}
/**
* register_framebuffer - registers a frame buffer device
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] fbmem, drm/nouveau: kick firmware framebuffers as soon as possible
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.
Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 19 +-
drivers/gpu/drm/nouveau/nouveau_state.c | 43 +++
drivers/video/fbmem.c | 43 ++-
include/linux/fb.h |1 +
5 files changed, 72 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index cb16a1b..a1f61f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -621,6 +621,8 @@ struct drm_nouveau_private {
struct {
struct dentry *channel_root;
} debugfs;
+
+ struct apertures_struct *apertures;
};
static inline struct drm_nouveau_private *
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 206368b..5e4367b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -195,7 +195,6 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
struct drm_mode_fb_cmd mode_cmd;
struct pci_dev *pdev = dev->pdev;
struct device *device = &pdev->dev;
- struct apertures_struct *aper;
int size, ret;
mode_cmd.width = surface_width;
@@ -282,28 +281,12 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
info->fix.mmio_len = pci_resource_len(pdev, 1);
/* Set aperture base/size for vesafb takeover */
- aper = info->apertures = alloc_apertures(3);
+ info->apertures = dev_priv->apertures;
if (!info->apertures) {
ret = -ENOMEM;
goto out_unref;
}
- aper->ranges[0].base = pci_resource_start(pdev, 1);
- aper->ranges[0].size = pci_resource_len(pdev, 1);
- aper->count = 1;
-
- if (pci_resource_len(pdev, 2)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
- aper->count++;
- }
-
- if (pci_resource_len(pdev, 3)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
- aper->count++;
- }
-
info->pixmap.size = 64*1024;
info->pixmap.buf_align = 8;
info->pixmap.access_align = 32;
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c
index a9e9cf3..cfa3239 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,6 +636,43 @@ static void nouveau_OF_copy_vbios_to_ramin(struct
drm_device *dev)
#endif
}
+static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
+{
+ struct pci_dev *pdev = dev->pdev;
+ struct apertures_struct *aper = alloc_apertures(3);
+ if (!aper)
+ return NULL;
+
+ aper->ranges[0].base = pci_resource_start(pdev, 1);
+ aper->ranges[0].size = pci_resource_len(pdev, 1);
+ aper->count = 1;
+
+ if (pci_resource_len(pdev, 2)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
+ aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
+ aper->count++;
+ }
+
+ if (pci_resource_len(pdev, 3)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
+ aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
+ aper->count++;
+ }
+
+ return aper;
+}
+
+static int nouveau_remove_conflicting_drivers(struct drm_device *dev)
+{
+ struct drm_nouveau_private *dev_priv = dev->dev_private;
+ dev_priv->apertures = nouveau_get_apertures(dev);
+ if (!dev_priv->apertures)
+ return -ENOMEM;
+
+ remove_conflicting_framebuffers(dev_priv->apertures, "nouveaufb");
+ return 0;
+}
+
int nouveau_load(struct drm_device *dev, unsigned long flags)
{
struct drm_nouveau_private *dev_priv;
@@ -723,6 +760,12 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
NV_INFO(dev, "Detected an NV%2x generation
[PATCH 2/3] fbdev: allow passing more than one aperture for handoff
It simplifies nouveau code by removal of detection which
region to pass to kick vesafb/efifb.
Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
---
drivers/gpu/drm/i915/intel_fb.c | 11 +++-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 84 +-
drivers/gpu/drm/radeon/radeon_fb.c |9 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 10 +++-
drivers/video/efifb.c | 11 +++-
drivers/video/fbmem.c | 20 +++-
drivers/video/fbsysfs.c |1 +
drivers/video/offb.c| 28 ++
drivers/video/vesafb.c | 11 +++-
include/linux/fb.h | 16 +-
10 files changed, 114 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8cd791d..a9192ab 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -192,11 +192,16 @@ static int intelfb_create(struct drm_device *dev,
uint32_t fb_width,
/* setup aperture base/size for vesafb takeover */
- info->aperture_base = dev->mode_config.fb_base;
+ info->apertures = alloc_apertures(1);
+ if (!info->apertures) {
+ ret = -ENOMEM;
+ goto out_unpin;
+ }
+ info->apertures->ranges[0].base = dev->mode_config.fb_base;
if (IS_I9XX(dev))
- info->aperture_size = pci_resource_len(dev->pdev, 2);
+ info->apertures->ranges[0].size = pci_resource_len(dev->pdev,
2);
else
- info->aperture_size = pci_resource_len(dev->pdev, 0);
+ info->apertures->ranges[0].size = pci_resource_len(dev->pdev,
0);
info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
info->fix.smem_len = size;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 68cedd9..206368b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -161,44 +161,6 @@ static struct drm_fb_helper_funcs
nouveau_fbcon_helper_funcs = {
.gamma_get = nouveau_fbcon_gamma_get
};
-#if defined(__i386__) || defined(__x86_64__)
-static bool
-nouveau_fbcon_has_vesafb_or_efifb(struct drm_device *dev)
-{
- struct pci_dev *pdev = dev->pdev;
- int ramin;
-
- if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB &&
- screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
- return false;
-
- if (screen_info.lfb_base < pci_resource_start(pdev, 1))
- goto not_fb;
-
- if (screen_info.lfb_base + screen_info.lfb_size >=
- pci_resource_start(pdev, 1) + pci_resource_len(pdev, 1))
- goto not_fb;
-
- return true;
-not_fb:
- ramin = 2;
- if (pci_resource_len(pdev, ramin) == 0) {
- ramin = 3;
- if (pci_resource_len(pdev, ramin) == 0)
- return false;
- }
-
- if (screen_info.lfb_base < pci_resource_start(pdev, ramin))
- return false;
-
- if (screen_info.lfb_base + screen_info.lfb_size >=
- pci_resource_start(pdev, ramin) + pci_resource_len(pdev, ramin))
- return false;
-
- return true;
-}
-#endif
-
void
nouveau_fbcon_zfill(struct drm_device *dev)
{
@@ -231,7 +193,9 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
struct nouveau_framebuffer *nouveau_fb;
struct nouveau_bo *nvbo;
struct drm_mode_fb_cmd mode_cmd;
- struct device *device = &dev->pdev->dev;
+ struct pci_dev *pdev = dev->pdev;
+ struct device *device = &pdev->dev;
+ struct apertures_struct *aper;
int size, ret;
mode_cmd.width = surface_width;
@@ -314,28 +278,30 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
drm_fb_helper_fill_var(info, fb, fb_width, fb_height);
/* FIXME: we really shouldn't expose mmio space at all */
- info->fix.mmio_start = pci_resource_start(dev->pdev, 1);
- info->fix.mmio_len = pci_resource_len(dev->pdev, 1);
+ info->fix.mmio_start = pci_resource_start(pdev, 1);
+ info->fix.mmio_len = pci_resource_len(pdev, 1);
/* Set aperture base/size for vesafb takeover */
-#if defined(__i386__) || defined(__x86_64__)
- if (nouveau_fbcon_has_vesafb_or_efifb(dev)) {
- /* Some NVIDIA VBIOS' are stupid and decide to put the
-* framebuffer in the middle of the PRAMIN BAR for
-* whatever reason. We need to know the exact lfb_base
-* to get vesafb kicked off, and the only reliable way
-
Re: [PATCH 3/3] fbmem, drm/nouveau: kick firmware framebuffers as soon as possible
On Sat, Apr 10, 2010 at 09:55:34PM +0200, marcin.slus...@gmail.com wrote: > Currently vesafb/efifb/... is kicked when hardware driver is registering > framebuffer. To do it hardware must be fully functional, so there's a short > window between start of initialisation and framebuffer registration when > two drivers touch the hardware. Unfortunately sometimes it breaks nouveau > initialisation. > > Fix it by kicking firmware driver(s) before we start touching the hardware. > > Reported-by: Didier Spaier > Signed-off-by: Marcin Slusarz > Cc: Ben Skeggs > Cc: Dave Airlie > Cc: Peter Jones > Cc: Andrew Morton > --- With this little patch below: Tested-by: Didier Spaier --- diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index f5297a0..42ae782 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1524,6 +1524,7 @@ void remove_conflicting_framebuffers(struct apertures_struct *a, const char *nam } } } +EXPORT_SYMBOL(remove_conflicting_framebuffers); /** * register_framebuffer - registers a frame buffer device ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] fbmem: fix aperture overlapping check
On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> On Sat, 2010-04-10 at 21:55 +0200, marcin.slus...@gmail.com wrote:
> > fb_do_apertures_overlap is returning wrong value when one aperture
> > is completely whithin the other. Add generic ranges_overlap macro
> > (probably kernel.h candidate) and use it here.
> >
>
> That doesn't seem right.
>
> The rules are:
>
> the generic aperture has to be equal or smaller than the hw aperture,
> otherwise the generic driver will be trashing random hw pieces on the
> machine.
Why "it has to"? Why generic aperture can't start one byte before hw?
> So with that in mind, the check makes sure the generic aperture starts
> somewhere inside the hw aperture, which the test clearly gets right.
So your only objection is that it's impossible with the current code?
> Have you got a pointer to a machine where it fails?
No, it failed with an artifical test while I was working on vga16fb handoff
(unfinished).
> Dave.
>
>
> > Signed-off-by: Marcin Slusarz
> > Cc: Dave Airlie
> > Cc: Peter Jones
> > Cc: Andrew Morton
> > ---
> > drivers/video/fbmem.c | 24 +---
> > 1 files changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> > index a15b44e..41f2e5e 100644
> > --- a/drivers/video/fbmem.c
> > +++ b/drivers/video/fbmem.c
> > @@ -1468,15 +1468,25 @@ static int fb_check_foreignness(struct fb_info *fi)
> > return 0;
> > }
> >
> > +/**
> > + * ranges_overlap - check whether two ranges overlap (their intersection
> > is not empty)
> > + * @start1: start of the first range
> > + * @size1: length of the first range
> > + * @start2: start of the second range
> > + * @size2: length of the second range
> > + */
> > +#define ranges_overlap(start1, size1, start2, size2) ({\
> > + typeof(start1) __start1 = (start1); \
> > + typeof(size1) __size1 = (size1); \
> > + typeof(start2) __start2 = (start2); \
> > + typeof(size2) __size2 = (size2); \
> > + __start1 < __start2 + __size2 && __start1 + __size1 > __start2; \
> > +})
> > +
> > static bool fb_do_apertures_overlap(struct fb_info *gen, struct fb_info
> > *hw)
> > {
> > - /* is the generic aperture base the same as the HW one */
> > - if (gen->aperture_base == hw->aperture_base)
> > - return true;
> > - /* is the generic aperture base inside the hw base->hw base+size */
> > - if (gen->aperture_base > hw->aperture_base && gen->aperture_base <=
> > hw->aperture_base + hw->aperture_size)
> > - return true;
> > - return false;
> > + return ranges_overlap(gen->aperture_base, gen->aperture_size,
> > + hw->aperture_base, hw->aperture_size);
> > }
> > /**
> > * register_framebuffer - registers a frame buffer device
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] fbmem: fix aperture overlapping check
On Tue, Apr 13, 2010 at 06:28:21AM +1000, Dave Airlie wrote: > On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote: > > On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote: > > > On Sat, 2010-04-10 at 21:55 +0200, marcin.slus...@gmail.com wrote: > > > > fb_do_apertures_overlap is returning wrong value when one aperture > > > > is completely whithin the other. Add generic ranges_overlap macro > > > > (probably kernel.h candidate) and use it here. > > > > > > > > > > That doesn't seem right. > > > > > > The rules are: > > > > > > the generic aperture has to be equal or smaller than the hw aperture, > > > otherwise the generic driver will be trashing random hw pieces on the > > > machine. > > > Why "it has to"? Why generic aperture can't start one byte before hw? > > Think about how it works a bit more, the answer is obvious. > > The hw aperture is defined by the actual hardware, not by the OS or my > code. The PCI apertures are well defined. Now for a generic driver like > vesa or offb to access the hardware it needs to access the hw apertures. > > It can't go accessing one byte before the hw aperture, as that will > crash the machine, or write to some other devices hw. Ok, thanks for explanation. I'll drop this patch and rebase the others. > > > So with that in mind, the check makes sure the generic aperture starts > > > somewhere inside the hw aperture, which the test clearly gets right. > > > > So your only objection is that it's impossible with the current code? > > > > > Have you got a pointer to a machine where it fails? > > > > No, it failed with an artifical test while I was working on vga16fb handoff > > (unfinished). > > You won't be able to make this work for vga16fb from what I can see > since it access 0xa000 directly, not via any of the defined apertures > that vesafb/offb use. vga16fb will need a different approach I suspect. Yeah, there's an idea to claim 0xa as an aperture of vga16fb and then do the same in KMS driver but only if it's the primary card. (You hinted to use SHADOW resource bit to check whether card is primary) I think I'll try this approach soon. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 2/2] fbmem, drm/nouveau: kick firmware framebuffers as soon as possible
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.
Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: Didier Spaier
Tested-by: Didier Spaier
Signed-off-by: Marcin Slusarz
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
v2 - rebase after drop of patch 1/3 + compile fix
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 19 +-
drivers/gpu/drm/nouveau/nouveau_state.c | 43 +++
drivers/video/fbmem.c | 43 ++-
include/linux/fb.h |1 +
5 files changed, 72 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index cb16a1b..a1f61f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -621,6 +621,8 @@ struct drm_nouveau_private {
struct {
struct dentry *channel_root;
} debugfs;
+
+ struct apertures_struct *apertures;
};
static inline struct drm_nouveau_private *
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 206368b..5e4367b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -195,7 +195,6 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
struct drm_mode_fb_cmd mode_cmd;
struct pci_dev *pdev = dev->pdev;
struct device *device = &pdev->dev;
- struct apertures_struct *aper;
int size, ret;
mode_cmd.width = surface_width;
@@ -282,28 +281,12 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
info->fix.mmio_len = pci_resource_len(pdev, 1);
/* Set aperture base/size for vesafb takeover */
- aper = info->apertures = alloc_apertures(3);
+ info->apertures = dev_priv->apertures;
if (!info->apertures) {
ret = -ENOMEM;
goto out_unref;
}
- aper->ranges[0].base = pci_resource_start(pdev, 1);
- aper->ranges[0].size = pci_resource_len(pdev, 1);
- aper->count = 1;
-
- if (pci_resource_len(pdev, 2)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
- aper->count++;
- }
-
- if (pci_resource_len(pdev, 3)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
- aper->count++;
- }
-
info->pixmap.size = 64*1024;
info->pixmap.buf_align = 8;
info->pixmap.access_align = 32;
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c
index a9e9cf3..cfa3239 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,6 +636,43 @@ static void nouveau_OF_copy_vbios_to_ramin(struct
drm_device *dev)
#endif
}
+static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
+{
+ struct pci_dev *pdev = dev->pdev;
+ struct apertures_struct *aper = alloc_apertures(3);
+ if (!aper)
+ return NULL;
+
+ aper->ranges[0].base = pci_resource_start(pdev, 1);
+ aper->ranges[0].size = pci_resource_len(pdev, 1);
+ aper->count = 1;
+
+ if (pci_resource_len(pdev, 2)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
+ aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
+ aper->count++;
+ }
+
+ if (pci_resource_len(pdev, 3)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
+ aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
+ aper->count++;
+ }
+
+ return aper;
+}
+
+static int nouveau_remove_conflicting_drivers(struct drm_device *dev)
+{
+ struct drm_nouveau_private *dev_priv = dev->dev_private;
+ dev_priv->apertures = nouveau_get_apertures(dev);
+ if (!dev_priv->apertures)
+ return -ENOMEM;
+
+ remove_conflicting_framebuffers(dev_priv->apertures, "nouveaufb");
+ return 0;
+}
+
int nouveau_load(struct drm_device *dev, unsigned long flags)
{
struct drm_nouveau_private *dev_priv;
@@ -723,6 +760,12 @@ int nouveau_load(struct drm_device *dev, unsig
[PATCHv2 1/2] fbdev: allow passing more than one aperture for handoff
It simplifies nouveau code by removal of detection which
region to pass to kick vesafb/efifb.
Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
---
v2 - rebase after drop of patch 1/3
---
drivers/gpu/drm/i915/intel_fb.c | 11 +++-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 84 +-
drivers/gpu/drm/radeon/radeon_fb.c |9 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 10 +++-
drivers/video/efifb.c | 11 +++-
drivers/video/fbmem.c | 29 ++-
drivers/video/fbsysfs.c |1 +
drivers/video/offb.c| 28 ++
drivers/video/vesafb.c | 11 +++-
include/linux/fb.h | 16 +-
10 files changed, 122 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8cd791d..a9192ab 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -192,11 +192,16 @@ static int intelfb_create(struct drm_device *dev,
uint32_t fb_width,
/* setup aperture base/size for vesafb takeover */
- info->aperture_base = dev->mode_config.fb_base;
+ info->apertures = alloc_apertures(1);
+ if (!info->apertures) {
+ ret = -ENOMEM;
+ goto out_unpin;
+ }
+ info->apertures->ranges[0].base = dev->mode_config.fb_base;
if (IS_I9XX(dev))
- info->aperture_size = pci_resource_len(dev->pdev, 2);
+ info->apertures->ranges[0].size = pci_resource_len(dev->pdev,
2);
else
- info->aperture_size = pci_resource_len(dev->pdev, 0);
+ info->apertures->ranges[0].size = pci_resource_len(dev->pdev,
0);
info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
info->fix.smem_len = size;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 68cedd9..206368b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -161,44 +161,6 @@ static struct drm_fb_helper_funcs
nouveau_fbcon_helper_funcs = {
.gamma_get = nouveau_fbcon_gamma_get
};
-#if defined(__i386__) || defined(__x86_64__)
-static bool
-nouveau_fbcon_has_vesafb_or_efifb(struct drm_device *dev)
-{
- struct pci_dev *pdev = dev->pdev;
- int ramin;
-
- if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB &&
- screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
- return false;
-
- if (screen_info.lfb_base < pci_resource_start(pdev, 1))
- goto not_fb;
-
- if (screen_info.lfb_base + screen_info.lfb_size >=
- pci_resource_start(pdev, 1) + pci_resource_len(pdev, 1))
- goto not_fb;
-
- return true;
-not_fb:
- ramin = 2;
- if (pci_resource_len(pdev, ramin) == 0) {
- ramin = 3;
- if (pci_resource_len(pdev, ramin) == 0)
- return false;
- }
-
- if (screen_info.lfb_base < pci_resource_start(pdev, ramin))
- return false;
-
- if (screen_info.lfb_base + screen_info.lfb_size >=
- pci_resource_start(pdev, ramin) + pci_resource_len(pdev, ramin))
- return false;
-
- return true;
-}
-#endif
-
void
nouveau_fbcon_zfill(struct drm_device *dev)
{
@@ -231,7 +193,9 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
struct nouveau_framebuffer *nouveau_fb;
struct nouveau_bo *nvbo;
struct drm_mode_fb_cmd mode_cmd;
- struct device *device = &dev->pdev->dev;
+ struct pci_dev *pdev = dev->pdev;
+ struct device *device = &pdev->dev;
+ struct apertures_struct *aper;
int size, ret;
mode_cmd.width = surface_width;
@@ -314,28 +278,30 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t
fb_width,
drm_fb_helper_fill_var(info, fb, fb_width, fb_height);
/* FIXME: we really shouldn't expose mmio space at all */
- info->fix.mmio_start = pci_resource_start(dev->pdev, 1);
- info->fix.mmio_len = pci_resource_len(dev->pdev, 1);
+ info->fix.mmio_start = pci_resource_start(pdev, 1);
+ info->fix.mmio_len = pci_resource_len(pdev, 1);
/* Set aperture base/size for vesafb takeover */
-#if defined(__i386__) || defined(__x86_64__)
- if (nouveau_fbcon_has_vesafb_or_efifb(dev)) {
- /* Some NVIDIA VBIOS' are stupid and decide to put the
-* framebuffer in the middle of the PRAMIN BAR for
-* whatever reason. We need to know the exact lfb_base
-* to get vesafb ki
[PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff
On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > Have you got a pointer to a machine where it fails?
> > >
> > > No, it failed with an artifical test while I was working on vga16fb
> > > handoff
> > > (unfinished).
> >
> > You won't be able to make this work for vga16fb from what I can see
> > since it access 0xa000 directly, not via any of the defined apertures
> > that vesafb/offb use. vga16fb will need a different approach I suspect.
>
> Yeah, there's an idea to claim 0xa as an aperture of vga16fb and then
> do the same in KMS driver but only if it's the primary card.
> (You hinted to use SHADOW resource bit to check whether card is primary)
> I think I'll try this approach soon.
Patch below works for me, but I couldn't test the case when nvidia card is
secondary.
---
From: Marcin Slusarz
Date: Tue, 13 Apr 2010 09:20:53 +0200
Subject: [PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff
let vga16fb claim 0xA+0x1 region as its aperture;
nouveau does not use it, so we need to lie to kick vga16fb,
but only if it's driving the primary card (by checking
IORESOURCE_ROM_SHADOW resource flag)
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_state.c | 11 ++-
drivers/video/vga16fb.c | 26 +++---
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c
index cfa3239..a101861 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,10 +636,12 @@ static void nouveau_OF_copy_vbios_to_ramin(struct
drm_device *dev)
#endif
}
+#define VGA_FB_PHYS 0xA
+#define VGA_FB_PHYS_LEN 65536
static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
{
struct pci_dev *pdev = dev->pdev;
- struct apertures_struct *aper = alloc_apertures(3);
+ struct apertures_struct *aper = alloc_apertures(4);
if (!aper)
return NULL;
@@ -658,6 +660,13 @@ static struct apertures_struct
*nouveau_get_apertures(struct drm_device *dev)
aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
aper->count++;
}
+
+ /* if it's the primary card, claim 0xa as ours to kick vga16fb */
+ if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW) {
+ aper->ranges[aper->count].base = VGA_FB_PHYS;
+ aper->ranges[aper->count].size = VGA_FB_PHYS_LEN;
+ aper->count++;
+ }
return aper;
}
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 76d8dae..45d7a3d 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1264,10 +1264,19 @@ static void vga16fb_imageblit(struct fb_info *info,
const struct fb_image *image
vga_imageblit_color(info, image);
}
+static void vga16fb_destroy(struct fb_info *info)
+{
+ iounmap(info->screen_base);
+ fb_dealloc_cmap(&info->cmap);
+ /* XXX unshare VGA regions */
+ framebuffer_release(info);
+}
+
static struct fb_ops vga16fb_ops = {
.owner = THIS_MODULE,
.fb_open= vga16fb_open,
.fb_release = vga16fb_release,
+ .fb_destroy = vga16fb_destroy,
.fb_check_var = vga16fb_check_var,
.fb_set_par = vga16fb_set_par,
.fb_setcolreg = vga16fb_setcolreg,
@@ -1307,6 +1316,11 @@ static int __devinit vga16fb_probe(struct
platform_device *dev)
ret = -ENOMEM;
goto err_fb_alloc;
}
+ info->apertures = alloc_apertures(1);
+ if (!info->apertures) {
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
@@ -1336,7 +1350,7 @@ static int __devinit vga16fb_probe(struct platform_device
*dev)
info->fix = vga16fb_fix;
/* supports rectangles with widths of multiples of 8 */
info->pixmap.blit_x = 1 << 7 | 1 << 15 | 1 << 23 | 1 << 31;
- info->flags = FBINFO_FLAG_DEFAULT |
+ info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
FBINFO_HWACCEL_YPAN;
i = (info->var.bits_per_pixel == 8) ? 256 : 16;
@@ -1355,6 +1369,9 @@ static int __devinit vga16fb_probe(struct platform_device
*dev)
vga16fb_update_fix(info);
+ info->apertures->ranges[0].base = VGA_FB_PHYS;
+ info->apertures->ranges[0].size = VGA_FB_PHYS_LEN;
+
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "vga16fb: unable
Re: DRM NOUVEAU: cannot boot with kernel >=3.7
On Mon, Dec 24, 2012 at 09:26:17PM +0100, baldu...@units.it wrote:
> hello everybody,
>
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
>
> Starting with kernel-3.7 I am not able to boot any more in KMS: as
> soon as the screen resolution changes in the very early stage of the
> boot, the machine freezes and the only option I'm left with is to
> press a physical reset button.
>
> I am on an athlon64 dual core machine and using DRM/NOUVEAU with a
> NVIDIA GeForce 6200 LE GPU
>
> Here are some facts:
>
> => while kernel-3.7.x gives the problems mentioned above,
>kernel-3.6.{8-10} boots just fine (and X11 works nicely)
> => if it can be of any use: if I reboot from a running 3.6.x kernel
>into a 3.7.x, the obtained freezed console screen shows the (somewhat
>misplaced) lines which were printed during the shutdown phase of
>the reboot process (I can send a screen photo, if needed)
> => kernel-3.7.x boots just fine on another box (another athlon64 dual core
> with
>a GeForce 6150SE nForce 430 (rev a2) GPU); kernel is 32bit there,
>if it matters
>
> I am attaching lspci output and my kernel config below.
>
> I will warmly appreciate any hint and will be more than happy to send
> in any other information which might be useful
Thanks for reporting.
Please follow instructions from http://nouveau.freedesktop.org/wiki/Bugs and
open new bug report. You may need to compile nouveau as module to catch full
kernel log.
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error seen on G5 iMac:
>
> nouveau E[ DRM] failed to create kernel channel, -12
>
> Reviewed-by: Michel Dänzer
> Signed-off-by: Aaro Koskinen
> ---
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
so cc'ing stable@vger seems to be appropriate.
> drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5614c89..69d7b1d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> if (drm->agp.stat == ENABLED) {
> mem->bus.offset = mem->start << PAGE_SHIFT;
> mem->bus.base = drm->agp.base;
> - mem->bus.is_iomem = true;
> + mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> break;
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resume regression with nouveau 3.8rc1 (bisected)
On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > Hi, > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > The kernel is alive because I can switch to VT1 and reboot with > ctrl-alt-delete. > > I bisected the problem down to this commit: > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > > Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. There's already open bug report for that: https://bugs.freedesktop.org/show_bug.cgi?id=58729 And my nv92 does not resume too, with similar symptoms, since nouveau display rework hit the tree. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resume regression with nouveau 3.8rc1 (bisected)
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > On Wed, Jan 02, 2013 at 04:19:35PM +0100, Pontus Fuchs wrote: > > Hi, > > > > Starting with 3.8rc1 I get a black screen when resuming after suspend. > > The kernel is alive because I can switch to VT1 and reboot with > > ctrl-alt-delete. > > > > I bisected the problem down to this commit: > > > > 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > > > > Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. > > There's already open bug report for that: > https://bugs.freedesktop.org/show_bug.cgi?id=58729 Yay, a bug fix was just posted there ;). Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Resume regression with nouveau 3.8rc1 (bisected)
On Sat, Jan 05, 2013 at 10:10:06AM +0100, Pontus Fuchs wrote: > On 01/03/2013 08:12 PM, Marcin Slusarz wrote: > > On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote: > >> I bisected the problem down to this commit: > >> > >> 186ecad21: drm/nv50/disp: move remaining interrupt handling into core > >> > >> Hardware is 8400M GS (10de:0427) in a Dell XPS M1330. > >> There's already open bug report for that: > >> https://bugs.freedesktop.org/show_bug.cgi?id=58729 > > Yay, a bug fix was just posted there ;). > > Hi, I tried that patch but it didn't help :( > > I see this in my kernel log after resume: > > nouveau E[ PFB][:01:00.0] trapped read at 0x002001a020 on > channel 0x7b23 SEMAPHORE_BG/PFIFO_READ/00 reason: PAGE_NOT_PRESENT > nouveau E[1177] failed to idle channel 0x > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction > [TTM] Failed to expire sync object before buffer eviction Sigh, this seems to be another issue :/ Please follow http://nouveau.freedesktop.org/wiki/Bugs and open new bug report. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libkms: link against libdrm
Signed-off-by: Marcin Slusarz --- libkms/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libkms/Makefile.am b/libkms/Makefile.am index fa379a4..215450a 100644 --- a/libkms/Makefile.am +++ b/libkms/Makefile.am @@ -6,7 +6,7 @@ AM_CFLAGS = \ libkms_la_LTLIBRARIES = libkms.la libkms_ladir = $(libdir) libkms_la_LDFLAGS = -version-number 1:0:0 -no-undefined -libkms_la_LIBADD = +libkms_la_LIBADD = ../libdrm.la #if HAVE_LIBUDEV #libkms_la_LIBADD += $(LIBUDEV_LIBS) -- 1.7.12 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add drm_send_vblank_event() helper
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
>
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_irq.c | 65
> +
> include/drm/drmP.h|2 ++
> 2 files changed, 44 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 076c4a8..7a00d94 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -802,6 +802,43 @@ u32 drm_vblank_count_and_time(struct drm_device *dev,
> int crtc,
> }
> EXPORT_SYMBOL(drm_vblank_count_and_time);
>
> +static void send_vblank_event(struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now)
> +{
> + e->event.sequence = seq;
> + e->event.tv_sec = now->tv_sec;
> + e->event.tv_usec = now->tv_usec;
> +
> + list_add_tail(&e->base.link,
> + &e->base.file_priv->event_list);
> + wake_up_interruptible(&e->base.file_priv->event_wait);
> + trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> + e->event.sequence);
> +}
> +
> +/**
> + * drm_send_vblank_event - helper to send vblank event after pageflip
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + * @e: the event to send
> + *
> + * Updates sequence # and timestamp on event, and sends it to userspace.
> + */
> +void drm_send_vblank_event(struct drm_device *dev, int crtc,
> + struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> + if (crtc >= 0) {
> + seq = drm_vblank_count_and_time(dev, crtc, &now);
> + } else {
> + seq = 0;
> + do_gettimeofday(&now);
> + }
> + send_vblank_event(e, seq, &now);
> +}
> +EXPORT_SYMBOL(drm_send_vblank_event);
> +
> /**
> * drm_update_vblank_count - update the master vblank counter
> * @dev: DRM device
> @@ -955,15 +992,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> DRM_DEBUG("Sending premature vblank event on disable: \
> wanted %d, current %d\n",
> e->event.sequence, seq);
> -
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->event.sequence);
> + send_vblank_event(e, seq, &now);
> }
>
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> @@ -1107,15 +1138,8 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, int pipe,
>
> e->event.sequence = vblwait->request.sequence;
> if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> drm_vblank_put(dev, pipe);
> - list_add_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - vblwait->reply.sequence = seq;
Déjà vu
http://lists.freedesktop.org/archives/dri-devel/2011-April/010693.html
:)
> - trace_drm_vblank_event_delivered(current->pid, pipe,
> - vblwait->request.sequence);
> + send_vblank_event(e, seq, &now);
> } else {
> /* drm_handle_vblank_events will call drm_vblank_put */
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> @@ -1256,14 +1280,9 @@ static void drm_handle_vblank_events(struct drm_device
> *dev, int crtc)
> DRM_DEBUG("vblank event on %d, current %d\n",
> e->event.sequence, seq);
>
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->even
Re: [PATCH 00/11] page-flip cleanups and fixes
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote: > From: Rob Clark > > Add a helper fxn to send vblank event after pageflip, plus a handful > of fixes for other issues that I noticed in the process. FWIW, patches 1-5 and 7 (with a fix to 1st) are: Reviewed-by: Marcin Slusarz > > Other than OMAP, the changes are just compile tested, so would be > good to get a quick look from the maintainers of various drivers. > > Rob Clark (11): > drm: add drm_send_vblank_event() helper > drm/i915: use drm_send_vblank_event() helper > drm/nouveau: use drm_send_vblank_event() helper > drm/radeon: use drm_send_vblank_event() helper > drm/exynos: use drm_send_vblank_event() helper > drm/exynos: page flip fixes > drm/shmob: use drm_send_vblank_event() helper > drm/imx: use drm_send_vblank_event() helper > drm/imx: page flip fixes > drm/omap: use drm_send_vblank_event() helper > drm/omap: page-flip fixes > > drivers/gpu/drm/drm_irq.c | 65 > +++-- > drivers/gpu/drm/exynos/exynos_drm_crtc.c |1 - > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 + > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 + > drivers/gpu/drm/exynos/exynos_mixer.c |9 +--- > drivers/gpu/drm/i915/intel_display.c | 15 +-- > drivers/gpu/drm/nouveau/nouveau_display.c | 13 +- > drivers/gpu/drm/radeon/radeon_display.c | 13 ++ > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 19 ++--- > drivers/staging/imx-drm/ipuv3-crtc.c | 32 -- > drivers/staging/omapdrm/omap_crtc.c | 37 > include/drm/drmP.h|2 + > 12 files changed, 78 insertions(+), 148 deletions(-) > > -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: add drm_send_vblank_event() helper (v3)
On Thu, Oct 11, 2012 at 07:29:15PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
>
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
>
> v1: original
> v2: add back 'vblwait->reply.sequence = seq' which should not have
> been deleted
> v3: add WARN_ON() in case lock is not held and comments
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_irq.c | 74
> +++--
> include/drm/drmP.h|2 ++
> 2 files changed, 54 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 076c4a8..d623a06 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -802,6 +802,46 @@ u32 drm_vblank_count_and_time(struct drm_device *dev,
> int crtc,
> }
> EXPORT_SYMBOL(drm_vblank_count_and_time);
>
> +static void send_vblank_event(struct drm_device *dev,
> + struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now)
> +{
> + WARN_ON(!spin_is_locked(&dev->event_lock));
This should be WARN_ON_SMP - on !SMP && !DEBUG_SPINLOCK spin_is_locked always
returns 0.
> + e->event.sequence = seq;
> + e->event.tv_sec = now->tv_sec;
> + e->event.tv_usec = now->tv_usec;
> +
> + list_add_tail(&e->base.link,
> + &e->base.file_priv->event_list);
> + wake_up_interruptible(&e->base.file_priv->event_wait);
> + trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> + e->event.sequence);
> +}
> +
> +/**
> + * drm_send_vblank_event - helper to send vblank event after pageflip
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + * @e: the event to send
> + *
> + * Updates sequence # and timestamp on event, and sends it to userspace.
> + * Caller must hold event lock.
> + */
> +void drm_send_vblank_event(struct drm_device *dev, int crtc,
> + struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> + if (crtc >= 0) {
> + seq = drm_vblank_count_and_time(dev, crtc, &now);
> + } else {
> + seq = 0;
> + do_gettimeofday(&now);
> + }
> + send_vblank_event(dev, e, seq, &now);
> +}
> +EXPORT_SYMBOL(drm_send_vblank_event);
> +
> /**
> * drm_update_vblank_count - update the master vblank counter
> * @dev: DRM device
> @@ -936,6 +976,13 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> }
> EXPORT_SYMBOL(drm_vblank_put);
>
> +/**
> + * drm_vblank_off - disable vblank events on a CRTC
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + *
> + * Caller must hold event lock.
> + */
> void drm_vblank_off(struct drm_device *dev, int crtc)
> {
> struct drm_pending_vblank_event *e, *t;
> @@ -955,15 +1002,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
> DRM_DEBUG("Sending premature vblank event on disable: \
> wanted %d, current %d\n",
> e->event.sequence, seq);
> -
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(&e->base.link);
> drm_vblank_put(dev, e->pipe);
> - list_move_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> - e->event.sequence);
> + send_vblank_event(dev, e, seq, &now);
> }
>
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> @@ -1107,15 +1148,9 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, int pipe,
>
> e->event.sequence = vblwait->request.sequence;
> if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> drm_vblank_put(dev, pipe);
> - list_add_tail(&e->base.link, &e->base.file_priv->event_list);
> - wake_up_interruptible(&e->base.file_priv->event_wait);
> + send_vblank_event(dev, e, seq, &now);
> vblwait->reply.sequence = seq;
> - trace_drm_vblank_event_delivered(current->pid, pipe,
> - vblwait->request.sequence);
> } else {
> /* drm_handle_vblank_events will call drm_vblank_put */
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> @@ -125
[PATCH] drm/debugfs: remove redundant info from gem_names
It's a relic of "drm: Convert proc files to seq_file and introduce debugfs", which wrongly converted DRM_INFO + sprintf to 2 seq_printfs. Signed-off-by: Marcin Slusarz Cc: Ben Gamari Cc: Eric Anholt --- drivers/gpu/drm/drm_info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index 8928edb..d498ec7 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -204,8 +204,6 @@ static int drm_gem_one_name_info(int id, void *ptr, void *data) struct drm_gem_object *obj = ptr; struct seq_file *m = data; - seq_printf(m, "name %d size %zd\n", obj->name, obj->size); - seq_printf(m, "%6d %8zd %7d %8d\n", obj->name, obj->size, atomic_read(&obj->handle_count), -- 1.7.12 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote:
>
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
>
> Yes, of course.
>
> Tried it. Unfortunately, the crash remains the same as reported.
Try this one.
Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
---
From: Marcin Slusarz
Subject: [PATCH] drm/nouveau: validate vbios size
Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.
Reported-by: Heinz Diehl
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
data = of_get_property(dn, "NVDA,BMP", &size);
- if (data) {
+ if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
bios->size = nv_rd08(bios, 0x72) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+ if (!bios->size)
+ goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+ if (!bios->size)
+ return;
bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
static int
nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
{
- if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+ if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+ bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}
- if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+ if (nvbios_checksum(bios->data,
+ min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
--
1.7.12
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote:
> >
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> >
> > Yes, of course.
> >
> > Tried it. Unfortunately, the crash remains the same as reported.
>
> Try this one.
>
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
>
> ---
> From: Marcin Slusarz
> Subject: [PATCH] drm/nouveau: validate vbios size
>
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
>
> Reported-by: Heinz Diehl
And of course:
Reported-by: Paweł Sikora
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
> }
>
> data = of_get_property(dn, "NVDA,BMP", &size);
> - if (data) {
> + if (data && size) {
> bios->size = size;
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
> goto out;
>
> bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>
> /* read entire bios image to system memory */
> bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> if (bios->data) {
> for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> bios->size = 0;
> if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>
> bios->data = kmalloc(bios->size, GFP_KERNEL);
> for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
> static int
> nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
> {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
> nv_info(bios, "... signature not found\n");
> return 0;
> }
>
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
> nv_info(bios, "... checksum invalid\n");
> /* if a ro image is somewhat bad, it's probably all rubbish */
> return writeable ? 2 : 1;
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > On 20.10.2012, Marcin Slusarz wrote: > > > Try this one. > > It works, now I can boot again. However, nouveau seems to be dead now. > The dmesg output with your patch on top of 3.7-rc1 is: > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > end of region [VROM] (length 24) (20120913/exfldio-210) > [3.704139] ACPI Error: Method parse/execution > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > AE_AML_REGION_LIMIT (20120913/psparse-536) > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image... > [3.724111] nouveau :01:00.0: Invalid ROM contents > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001, > -22 > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > [3.740523] dracut: Starting plymouth daemon > > And here's the same output with plain vanilla 3.6.2: > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > (0x0a8800b1) > [3.599783] vga_switcheroo: enabled > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > VBIOS init tables. > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > offset 0xDECD > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > offset 0xE378 > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > offset 0xEF4B > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > offset 0xEF64 > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > offset 0xF04B > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset > 0xF0B0 > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > [4.019438] [TTM] Initializing pool allocator > [4.020694] [TTM] Initializing DMA pool allocator > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3) > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture) > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [4.084909] [drm] No driver support for vblank timestamp query. > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface > available, not register
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote: > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote: > > On 20.10.2012, Marcin Slusarz wrote: > > > > > Try this one. > > > > It works, now I can boot again. However, nouveau seems to be dead now. > > The dmesg output with your patch on top of 3.7-rc1 is: > > > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1 > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8) > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50 > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for > > image... > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image... > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image... > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond > > end of region [VROM] (length 24) (20120913/exfldio-210) > > [3.704139] ACPI Error: Method parse/execution > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), > > AE_AML_REGION_LIMIT (20120913/psparse-536) > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for > > image... > > [3.724111] nouveau :01:00.0: Invalid ROM contents > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable > > image > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create > > 0x1001, -22 > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22 > > [3.736097] nouveau: probe of :01:00.0 failed with error -22 > > [3.740523] dracut: Starting plymouth daemon > > > > And here's the same output with plain vanilla 3.6.2: > > > > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card > > (0x0a8800b1) > > [3.599783] vga_switcheroo: enabled > > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS > > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS > > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found > > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS > > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid > > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI > > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found > > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00 > > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0 > > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do > > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0 > > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 > > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040 > > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146 > > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261 > > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330 > > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400 > > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560 > > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running > > VBIOS init tables. > > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at > > offset 0xDECD > > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6 > > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at > > offset 0xE378 > > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at > > offset 0xEF4B > > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at > > offset 0xEF64 > > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at > > offset 0xF04B > > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at > > offset 0xF0B0 > > [4.018084] [TTM] Zone kernel: Available graphics memory: 1917766 kiB > > [4.019438] [TTM] Initializing p
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote:
>
> > Try this one.
>
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
>
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> minor 0
> [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create 0x1001,
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
Hmm, maybe we can't fetch 3 bytes only...
Let's check this:
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
{
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
- u8 data[3];
+ u8 *data;
if (!nouveau_acpi_rom_supported(pdev))
return;
bios->size = 0;
- if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+ data = kmalloc(4096, GFP_KERNEL);
+ if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+ kfree(data);
if (!bios->size)
return;
---
Please attach acpidump output.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 08:58:07AM +0200, Paweł Sikora wrote:
> On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> > On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > > On 20.10.2012, Marcin Slusarz wrote:
> > >
> > > > Try this one.
> > >
> > > It works, now I can boot again. However, nouveau seems to be dead now.
> > > The dmesg output with your patch on top of 3.7-rc1 is:
> > >
> > > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
> > > minor 0
> > > [3.687784] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0a8800b1
> > > [3.689960] nouveau [ DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > > [3.692471] nouveau [ DEVICE][:01:00.0] Family : NV50
> > > [3.695716] nouveau [ VBIOS][:01:00.0] checking PRAMIN for
> > > image...
> > > [3.697087] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.698471] nouveau [ VBIOS][:01:00.0] checking PROM for
> > > image...
> > > [3.699838] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.701223] nouveau [ VBIOS][:01:00.0] checking ACPI for
> > > image...
> > > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is
> > > beyond end of region [VROM] (length 24) (20120913/exfldio-210)
> > > [3.704139] ACPI Error: Method parse/execution
> > > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8),
> > > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > > [3.718776] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.721349] nouveau [ VBIOS][:01:00.0] checking PCIROM for
> > > image...
> > > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > > [3.726663] nouveau [ VBIOS][:01:00.0] ... signature not found
> > > [3.729159] nouveau E[ VBIOS][:01:00.0] unable to locate usable
> > > image
> > > [3.731677] nouveau E[ DEVICE][:01:00.0] failed to create
> > > 0x1001, -22
> > > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > > [3.740523] dracut: Starting plymouth daemon
> >
> > Hmm, maybe we can't fetch 3 bytes only...
> >
> > Let's check this:
> >
> > ---
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > index 824eea0..8bd71aa 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> > @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
> > {
> > struct pci_dev *pdev = nv_device(bios)->pdev;
> > int ret, cnt, i;
> > - u8 data[3];
> > + u8 *data;
> >
> > if (!nouveau_acpi_rom_supported(pdev))
> > return;
> >
> > bios->size = 0;
> > - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> > + data = kmalloc(4096, GFP_KERNEL);
> > + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
> > bios->size = data[2] * 512;
> > + kfree(data);
> > if (!bios->size)
> > return;
>
> with these both patches applied my laptop boots and gui works fine.
> here's dmesg:
>
> (...)
> [8.751795] nouveau [ VBIOS][:01:00.0] ... appears to be valid
> [8.751798] nouveau [ VBIOS][:01:00.0] using image from ACPI
> [8.751895] nouveau [ VBIOS][:01:00.0] BIT signature found
> [8.751898] nouveau [ VBIOS][:01:00.0] version 70.08.45.00
> [8.752366] nouveau [ DEVINIT][:01:00.0] adaptor not initialised
> [8.752368] nouveau [ VBIOS][:01:00.0] running init tables
> [8.867660] nouveau [ MXM][:01:00.0] no VBIOS data, nothing to do
> [8.867690] nouveau [ PFB][:01:00.0] RAM type: DDR3
> [8.867692] nouveau [ PFB][:01:00.0] RAM size: 512 MiB
> [8.901523] vga_switcheroo: enabled
> [8.901979] [TTM] Zone kernel: Available graphics memory: 6104282 kiB
> [8.901980] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
> [8.901982] [TTM] Initializing pool allocator
> [8.902014] [TTM] Initializing DMA pool allocator
> [8.902180] mtrr: type mismatch for c000,1000 old: write-back new:
> write-combining
> [8.90
Re: Linux 3.7-rc1 (nouveau_bios_score oops).
On Sun, Oct 21, 2012 at 07:38:58AM -0700, Linus Torvalds wrote: > On Sun, Oct 21, 2012 at 5:09 AM, Marcin Slusarz > wrote: > > > > This looks like ACPI bug... > > I'm _shocked_ to hear that firmware would be fragile. > > Anyway, here's the #1 thing to keep in mind about firmware: > > - firmware is *always* buggy. I know. But this bug is not about broken firmware. It's about Linux kernel ACPI implementation, which (I think) wrongly interprets ACPI script. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/ttm: remove ttm_buffer_object->buffer_start
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 8 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
include/drm/ttm/ttm_bo_api.h | 9 -
9 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 1a026ac..0a54f65 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -356,7 +356,7 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
ttm_bo_type_device, &astbo->placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
NULL, ast_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bc83f83..90d7701 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int
align,
ret = ttm_bo_init(&cirrus->ttm.bdev, &cirrusbo->bo, size,
ttm_bo_type_device, &cirrusbo->placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 1504699..49d60a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int
align,
ret = ttm_bo_init(&mdev->ttm.bdev, &mgabo->bo, size,
ttm_bo_type_device, &mgabo->placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35ac57f..3cbf1a8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -225,7 +225,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
ret = ttm_bo_init(&drm->ttm.bdev, &nvbo->bo, size,
type, &nvbo->placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size, sg,
+ align >> PAGE_SHIFT, false, NULL, acc_size, sg,
nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index b91118c..0665845 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -140,7 +140,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* Kernel allocation are uninterruptible */
down_read(&rdev->pm.mclk_lock);
r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
- &bo->placement, page_align, 0, !kernel, NULL,
+ &bo->placement, page_align, !kernel, NULL,
acc_size, sg, &radeon_ttm_bo_destroy);
up_read(&rdev->pm.mclk_lock);
if (unlikely(r != 0)) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..27a2d3f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1179,7 +1179,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
enum ttm_bo_type type,
struct ttm_placement *placement,
uint32_t page_alignment,
- unsigned long buffer_start,
bool interruptible,
struct file *persistent_swap_storage,
size_t acc_size,
@@ -1200,7 +1199,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
return -ENOMEM;
}
- size += buffer_start & ~PAGE_MASK;
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (num_pages == 0) {
pr_err("Illegal
[PATCH 2/4] drm/ttm: remove persistent_swap_storage argument from ttm_bo_init/ttm_bo_create
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 7 +++
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 +++
drivers/gpu/drm/radeon/radeon_object.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 8 +++-
include/drm/ttm/ttm_bo_api.h | 16 +++-
9 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 0a54f65..c6dcc84 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -354,10 +354,9 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
acc_size = ttm_bo_dma_acc_size(&ast->ttm.bdev, size,
sizeof(struct ast_bo));
- ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, ast_bo_ttm_destroy);
+ ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size, ttm_bo_type_device,
+ &astbo->placement, align >> PAGE_SHIFT, false,
+ acc_size, NULL, ast_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 90d7701..65e665f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int
align,
ret = ttm_bo_init(&cirrus->ttm.bdev, &cirrusbo->bo, size,
ttm_bo_type_device, &cirrusbo->placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 49d60a6..be121d1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int
align,
ret = ttm_bo_init(&mdev->ttm.bdev, &mgabo->bo, size,
ttm_bo_type_device, &mgabo->placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3cbf1a8..82f0f3c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -223,10 +223,9 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
acc_size = ttm_bo_dma_acc_size(&drm->ttm.bdev, size,
sizeof(struct nouveau_bo));
- ret = ttm_bo_init(&drm->ttm.bdev, &nvbo->bo, size,
- type, &nvbo->placement,
- align >> PAGE_SHIFT, false, NULL, acc_size, sg,
- nouveau_bo_del_ttm);
+ ret = ttm_bo_init(&drm->ttm.bdev, &nvbo->bo, size, type,
+ &nvbo->placement, align >> PAGE_SHIFT, false,
+ acc_size, sg, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 0665845..834b291 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -139,9 +139,9 @@ int radeon_bo_create(struct radeon_device *rdev,
radeon_ttm_placement_from_domain(bo, domain);
/* Kernel allocation are uninterruptible */
down_read(&rdev->pm.mclk_lock);
- r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
- &bo->placement, page_align, !kernel, NULL,
- acc_size, sg, &radeon_ttm_bo_destroy);
+ r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type, &bo->placement,
+ page_align, !kernel, acc_size, sg,
+ &radeon_ttm_bo_destroy);
up_read(&rdev->pm.mclk_lock);
[PATCH 3/4] drm/ttm: remove ttm_bo_device->nice_mode
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1570,7 +1570,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
goto out_no_addr_mm;
INIT_DELAYED_WORK(&bdev->wq, ttm_bo_delayed_workqueue);
- bdev->nice_mode = true;
INIT_LIST_HEAD(&bdev->ddestroy);
bdev->dev_mapping = NULL;
bdev->glob = glob;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d803b92..95628e7 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -521,8 +521,6 @@ struct ttm_bo_global {
* lru_lock: Spinlock that protects the buffer+device lru lists and
* ddestroy lists.
* @val_seq: Current validation sequence.
- * @nice_mode: Try nicely to wait for buffer idle when cleaning a manager.
- * If a GPU lockup has been detected, this is forced to 0.
* @dev_mapping: A pointer to the struct address_space representing the
* device address space.
* @wq: Work queue structure for the delayed delete workqueue.
@@ -556,7 +554,6 @@ struct ttm_bo_device {
* Protected by load / firstopen / lastclose /unload sync.
*/
- bool nice_mode;
struct address_space *dev_mapping;
/*
--
1.7.12
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/ttm: remove ttm_mem_global->queue
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_memory.c | 1 -
include/drm/ttm/ttm_memory.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -367,7 +367,6 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
spin_lock_init(&glob->lock);
glob->swap_queue = create_singlethread_workqueue("ttm_swap");
INIT_WORK(&glob->work, ttm_shrink_work);
- init_waitqueue_head(&glob->queue);
ret = kobject_init_and_add(
&glob->kobj, &ttm_mem_glob_kobj_type, ttm_get_kobj(),
"memory_accounting");
if (unlikely(ret != 0)) {
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index d6d1da4..72dcbe8 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -60,7 +60,6 @@ struct ttm_mem_shrink {
* for the GPU, and this will otherwise block other workqueue tasks(?)
* At this point we use only a single-threaded workqueue.
* @work: The workqueue callback for the shrink queue.
- * @queue: Wait queue for processes suspended waiting for memory.
* @lock: Lock to protect the @shrink - and the memory accounting members,
* that is, essentially the whole structure with some exceptions.
* @zones: Array of pointers to accounting zones.
@@ -80,7 +79,6 @@ struct ttm_mem_global {
struct ttm_mem_shrink *shrink;
struct workqueue_struct *swap_queue;
struct work_struct work;
- wait_queue_head_t queue;
spinlock_t lock;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
--
1.7.12
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: Fix crash after D3
On Tue, Nov 06, 2012 at 10:03:40PM +0800, Daniel J Blueman wrote:
> In 3.7-rc4, when starting X with the integrated GPU and suspending the
> discrete GPU,
> after one or more 32-bit applications are used (eg Skype) and X is stopped,
> we hit a panic.
>
> Prevent this by testing if the fini function is valid.
It's a bit weird. Can you explain better what is going on?
Why do we try to destroy this object (with NULL fini) only when GPU is
suspended? Maybe it means we are leaking this object on normal close/destroy?
Did you test what happens when you resume nv GPU after stopping X?
> Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
> Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
> Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt
>
> Signed-off-by: Daniel J Blueman
> ---
> drivers/gpu/drm/nouveau/core/core/object.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/object.c
> b/drivers/gpu/drm/nouveau/core/core/object.c
> index 0daab62..3da3525 100644
> --- a/drivers/gpu/drm/nouveau/core/core/object.c
> +++ b/drivers/gpu/drm/nouveau/core/core/object.c
> @@ -354,12 +354,16 @@ static int
> nouveau_object_decf(struct nouveau_object *object)
> {
> int ret;
> + struct nouveau_ofuncs *pfuncs;
>
> nv_trace(object, "stopping...\n");
>
> - ret = nv_ofuncs(object)->fini(object, false);
> - if (ret)
> - nv_warn(object, "failed fini, %d\n", ret);
> + pfuncs = nv_ofuncs(object);
> + if (pfuncs->fini) {
> + ret = nv_ofuncs(object)->fini(object, false);
> + if (ret)
> + nv_warn(object, "failed fini, %d\n", ret);
> + }
>
> if (object->engine) {
> mutex_lock(&nv_subdev(object->engine)->mutex);
> --
> 1.7.10.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fix for vblank on nvc0
On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote: > > > Op 06-11-12 15:48, Kelly Doran schreef: > > The vblank on nvc0 was not working correctly and would freeze X, I managed > > to track it down and fix it with some help from m.b.lankhorst, see > > https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details. > > > Reviewed-by: Maarten Lankhorst > > I recommended the bar flush since nvd0 does as well, and there might be a > small race > otherwise. > > Can this still get in before final 3.7 release? This patch breaks vblank here (nv92) completely. [ 6879.200427] Console: switching to colour VGA+ 80x25 [ 6879.202884] drm: unregistered panic notifier [ 6879.334278] [TTM] Finalizing pool allocator [ 6879.334518] [TTM] Finalizing DMA pool allocator [ 6879.334765] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 6879.335004] [TTM] Zone dma32: Used memory at exit: 0 kiB [ 6879.340472] [drm] Module unloaded [ 6879.397744] [drm] Initialized drm 1.1.0 20060810 [ 6879.408149] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x092a00a2 [ 6879.408401] nouveau [ DEVICE][:02:00.0] Chipset: G92 (NV92) [ 6879.408641] nouveau [ DEVICE][:02:00.0] Family : NV50 [ 6879.409752] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [ 6879.409997] nouveau [ VBIOS][:02:00.0] ... signature not found [ 6879.410236] nouveau [ VBIOS][:02:00.0] checking PROM for image... [ 6879.549018] nouveau [ VBIOS][:02:00.0] ... appears to be valid [ 6879.549259] nouveau [ VBIOS][:02:00.0] using image from PROM [ 6879.549640] nouveau [ VBIOS][:02:00.0] BIT signature found [ 6879.549879] nouveau [ VBIOS][:02:00.0] version 62.92.63.00 [ 6879.570275] nouveau [ MXM][:02:00.0] no VBIOS data, nothing to do [ 6879.572488] nouveau [ PFB][:02:00.0] RAM type: GDDR3 [ 6879.572726] nouveau [ PFB][:02:00.0] RAM size: 512 MiB [ 6879.572964] nouveau [ PFB][:02:00.0]ZCOMP: 4032 tags [ 6879.597652] [TTM] Zone kernel: Available graphics memory: 3047140 kiB [ 6879.597892] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 6879.598130] [TTM] Initializing pool allocator [ 6879.598367] [TTM] Initializing DMA pool allocator [ 6879.602860] nouveau [ DRM] VRAM: 512 MiB [ 6879.603102] nouveau [ DRM] GART: 512 MiB [ 6879.603339] nouveau [ DRM] BIT BIOS found [ 6879.603575] nouveau [ DRM] Bios version 62.92.63.00 [ 6879.603813] nouveau [ DRM] TMDS table version 2.0 [ 6879.604050] nouveau [ DRM] DCB version 4.0 [ 6879.604287] nouveau [ DRM] DCB outp 00: 02000300 0028 [ 6879.604524] nouveau [ DRM] DCB outp 01: 01000302 00020030 [ 6879.604763] nouveau [ DRM] DCB outp 02: 04011310 0028 [ 6879.605000] nouveau [ DRM] DCB outp 03: 02011312 00020030 [ 6879.605238] nouveau [ DRM] DCB conn 00: 1030 [ 6879.605516] nouveau [ DRM] DCB conn 01: 2130 [ 6879.648012] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 6879.648257] [drm] No driver support for vblank timestamp query. [ 6879.648708] nouveau [ DRM] 1 available performance level(s) [ 6879.648953] nouveau [ DRM] 3: core 650MHz shader 1625MHz memory 1000MHz voltage 1050mV fanspeed 100% [ 6879.649391] nouveau [ DRM] c: core 399MHz shader 810MHz memory 399MHz voltage 1050mV fanspeed 34% [ 6879.693947] nouveau [ DRM] MM: using CRYPT for buffer copies [ 6879.791680] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo 880018f20800 [ 6879.792175] fbcon: nouveaufb (fb0) is primary device [ 6879.850216] Console: switching to colour frame buffer device 240x67 [ 6879.897075] fb0: nouveaufb frame buffer device [ 6879.897075] drm: registered panic notifier [ 6879.897078] [drm] Initialized nouveau 1.1.0 20120801 for :02:00.0 on minor 0 I'm starting glxgears here xorg hangs, with occasional mouse movement [ 6907.054696] nouveau [ PFIFO][:02:00.0] unknown intr 0x0040, ch 2 pkill glxgears from fbcon [ 6963.987969] nouveau E[ 15318] failed to idle channel 0x xorg still hangs [ 7034.713069] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_2D - TP 0 - Unknown fault at address 002006 [ 7034.713167] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_2D - TP 0 - e0c: , e18: , e1c: , e20: 0037, e24: 0c03 [ 7034.713286] nouveau [ PGRAPH][:02:00.0] TRAP [ 7034.713353] nouveau E[ PGRAPH][:02:00.0] ch 2 [0x001faf9000] subc 2 class 0x502d mthd 0x060c data 0x000b [ 7034.713454] nouveau E[ PFB][:02:00.0] trapped write at 0x00 on channel 0x0001fea0 PEEPHOLE/PFIFO_WRITE/00 reason: NULL_DMAOBJ [ 7034.713624] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_RT - TP 0 - Unknown fault at address 002006 [ 7034.713713] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_RT - TP 0 - e0c: , e18: , e1c: 0002, e20: 3b00, e24: 0003 [ 7034.713834] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_RT - TP 1 - Unknown faul
Re: Fix for vblank on nvc0
On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote: > On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote: > > > > > > Op 06-11-12 15:48, Kelly Doran schreef: > > > The vblank on nvc0 was not working correctly and would freeze X, I managed > > > to track it down and fix it with some help from m.b.lankhorst, see > > > https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details. > > > > > Reviewed-by: Maarten Lankhorst > > > > I recommended the bar flush since nvd0 does as well, and there might be a > > small race > > otherwise. > > > > Can this still get in before final 3.7 release? > > This patch breaks vblank here (nv92) completely. > > [ 6879.200427] Console: switching to colour VGA+ 80x25 > [ 6879.202884] drm: unregistered panic notifier > [ 6879.334278] [TTM] Finalizing pool allocator > [ 6879.334518] [TTM] Finalizing DMA pool allocator > [ 6879.334765] [TTM] Zone kernel: Used memory at exit: 0 kiB > [ 6879.335004] [TTM] Zone dma32: Used memory at exit: 0 kiB > [ 6879.340472] [drm] Module unloaded > [ 6879.397744] [drm] Initialized drm 1.1.0 20060810 > [ 6879.408149] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x092a00a2 > [ 6879.408401] nouveau [ DEVICE][:02:00.0] Chipset: G92 (NV92) > [ 6879.408641] nouveau [ DEVICE][:02:00.0] Family : NV50 > [ 6879.409752] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... > [ 6879.409997] nouveau [ VBIOS][:02:00.0] ... signature not found > [ 6879.410236] nouveau [ VBIOS][:02:00.0] checking PROM for image... > [ 6879.549018] nouveau [ VBIOS][:02:00.0] ... appears to be valid > [ 6879.549259] nouveau [ VBIOS][:02:00.0] using image from PROM > [ 6879.549640] nouveau [ VBIOS][:02:00.0] BIT signature found > [ 6879.549879] nouveau [ VBIOS][:02:00.0] version 62.92.63.00 > [ 6879.570275] nouveau [ MXM][:02:00.0] no VBIOS data, nothing to do > [ 6879.572488] nouveau [ PFB][:02:00.0] RAM type: GDDR3 > [ 6879.572726] nouveau [ PFB][:02:00.0] RAM size: 512 MiB > [ 6879.572964] nouveau [ PFB][:02:00.0]ZCOMP: 4032 tags > [ 6879.597652] [TTM] Zone kernel: Available graphics memory: 3047140 kiB > [ 6879.597892] [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [ 6879.598130] [TTM] Initializing pool allocator > [ 6879.598367] [TTM] Initializing DMA pool allocator > [ 6879.602860] nouveau [ DRM] VRAM: 512 MiB > [ 6879.603102] nouveau [ DRM] GART: 512 MiB > [ 6879.603339] nouveau [ DRM] BIT BIOS found > [ 6879.603575] nouveau [ DRM] Bios version 62.92.63.00 > [ 6879.603813] nouveau [ DRM] TMDS table version 2.0 > [ 6879.604050] nouveau [ DRM] DCB version 4.0 > [ 6879.604287] nouveau [ DRM] DCB outp 00: 02000300 0028 > [ 6879.604524] nouveau [ DRM] DCB outp 01: 01000302 00020030 > [ 6879.604763] nouveau [ DRM] DCB outp 02: 04011310 0028 > [ 6879.605000] nouveau [ DRM] DCB outp 03: 02011312 00020030 > [ 6879.605238] nouveau [ DRM] DCB conn 00: 1030 > [ 6879.605516] nouveau [ DRM] DCB conn 01: 2130 > [ 6879.648012] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [ 6879.648257] [drm] No driver support for vblank timestamp query. > [ 6879.648708] nouveau [ DRM] 1 available performance level(s) > [ 6879.648953] nouveau [ DRM] 3: core 650MHz shader 1625MHz memory > 1000MHz voltage 1050mV fanspeed 100% > [ 6879.649391] nouveau [ DRM] c: core 399MHz shader 810MHz memory 399MHz > voltage 1050mV fanspeed 34% > [ 6879.693947] nouveau [ DRM] MM: using CRYPT for buffer copies > [ 6879.791680] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo > 880018f20800 > [ 6879.792175] fbcon: nouveaufb (fb0) is primary device > [ 6879.850216] Console: switching to colour frame buffer device 240x67 > [ 6879.897075] fb0: nouveaufb frame buffer device > [ 6879.897075] drm: registered panic notifier > [ 6879.897078] [drm] Initialized nouveau 1.1.0 20120801 for :02:00.0 on > minor 0 > I'm starting glxgears here > xorg hangs, with occasional mouse movement > [ 6907.054696] nouveau [ PFIFO][:02:00.0] unknown intr 0x0040, ch 2 > pkill glxgears from fbcon > [ 6963.987969] nouveau E[ 15318] failed to idle channel 0x > xorg still hangs > [ 7034.713069] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_2D - TP 0 - > Unknown fault at address 002006 > [ 7034.713167] nouveau E[ PGRAPH][:02:00.0] TRAP_TPDMA_2D - TP 0 - e0c: > , e18: , e1c: , e20: 0037, e24: 0c03 > [ 7034.713286] nouveau [ PGRAPH][:02:00.0] TRAP > [ 7034.713353] nouveau E[ PGRAPH][:02:00.0] ch 2 [0x001
Re: Fix for vblank on nvc0
On Mon, Nov 12, 2012 at 06:14:05AM -0600, Kelly Doran wrote: > Okay I have added two patches, one of them should fix the problem... > vblank-fix1.patch works, thanks. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fix messages about failed procfs/debugfs file registration
It printed garbage from stack:
[drm:drm_debugfs_create_files] *ERROR* Cannot create
/sys/kernel/debug/dri/!.wy/2
Reported-by: Daniel Yek
Signed-off-by: Marcin Slusarz
Cc: sta...@kernel.org
---
drivers/gpu/drm/drm_debugfs.c |3 +--
drivers/gpu/drm/drm_proc.c|3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d8c892..b9dc262 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -90,7 +90,6 @@ int drm_debugfs_create_files(struct drm_info_list *files, int
count,
struct drm_device *dev = minor->dev;
struct dentry *ent;
struct drm_info_node *tmp;
- char name[64];
int i, ret;
for (i = 0; i < count; i++) {
@@ -109,7 +108,7 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
root, tmp, &drm_debugfs_fops);
if (!ent) {
DRM_ERROR("Cannot create /sys/kernel/debug/dri/%s/%s\n",
- name, files[i].name);
+ root->d_name.name, files[i].name);
kfree(tmp);
ret = -1;
goto fail;
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..0f3c4e3 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -95,7 +95,6 @@ int drm_proc_create_files(struct drm_info_list *files, int
count,
struct drm_device *dev = minor->dev;
struct proc_dir_entry *ent;
struct drm_info_node *tmp;
- char name[64];
int i, ret;
for (i = 0; i < count; i++) {
@@ -118,7 +117,7 @@ int drm_proc_create_files(struct drm_info_list *files, int
count,
&drm_proc_fops, tmp);
if (!ent) {
DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
- name, files[i].name);
+ root->name, files[i].name);
list_del(&tmp->list);
kfree(tmp);
ret = -1;
--
1.7.6.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: fix error message about failed procfs file registration
It printed garbage.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_proc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 9e5b07e..0f3c4e3 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -95,7 +95,6 @@ int drm_proc_create_files(struct drm_info_list *files, int
count,
struct drm_device *dev = minor->dev;
struct proc_dir_entry *ent;
struct drm_info_node *tmp;
- char name[64];
int i, ret;
for (i = 0; i < count; i++) {
@@ -118,7 +117,7 @@ int drm_proc_create_files(struct drm_info_list *files, int
count,
&drm_proc_fops, tmp);
if (!ent) {
DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
- name, files[i].name);
+ root->name, files[i].name);
list_del(&tmp->list);
kfree(tmp);
ret = -1;
--
1.7.6.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: simplify error printing in drm_debugfs_create_files
There's no need to copy d_name.name.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..b9dc262 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -107,11 +107,8 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
ent = debugfs_create_file(files[i].name, S_IFREG | S_IRUGO,
root, tmp, &drm_debugfs_fops);
if (!ent) {
- char name[64];
- strncpy(name, root->d_name.name,
- min(root->d_name.len, 64U));
DRM_ERROR("Cannot create /sys/kernel/debug/dri/%s/%s\n",
- name, files[i].name);
+ root->d_name.name, files[i].name);
kfree(tmp);
ret = -1;
goto fail;
--
1.7.6.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: serialize access to debugs_nodes.list
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c |5 +
include/drm/drmP.h|1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..1144fbe 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -120,7 +120,9 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = &files[i];
+ mutex_lock(&minor->debugfs_nodes.mutex);
list_add(&(tmp->list), &(minor->debugfs_nodes.list));
+ mutex_unlock(&minor->debugfs_nodes.mutex);
}
return 0;
@@ -149,6 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
int ret;
INIT_LIST_HEAD(&minor->debugfs_nodes.list);
+ mutex_init(&minor->debugfs_nodes.mutex);
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
if (!minor->debugfs_root) {
@@ -194,6 +197,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
struct drm_info_node *tmp;
int i;
+ mutex_lock(&minor->debugfs_nodes.mutex);
for (i = 0; i < count; i++) {
list_for_each_safe(pos, q, &minor->debugfs_nodes.list) {
tmp = list_entry(pos, struct drm_info_node, list);
@@ -204,6 +208,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
}
}
}
+ mutex_unlock(&minor->debugfs_nodes.mutex);
return 0;
}
EXPORT_SYMBOL(drm_debugfs_remove_files);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..c70c943 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -970,6 +970,7 @@ struct drm_info_list {
* debugfs node structure. This structure represents a debugfs file.
*/
struct drm_info_node {
+ struct mutex mutex;
struct list_head list;
struct drm_minor *minor;
struct drm_info_list *info_ent;
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: serialize access to debugs_nodes.list
On Mon, Oct 31, 2011 at 09:06:57AM +0100, Daniel Vetter wrote: > This is just ugly, you're adding a mutex to every drm_info_node, but only > use the one embedded into the minor. On a quick grep we're only ever using > the list in there, so I suggest to > - replace minor->debugfs_node.list with minor->debugfs_list and kill > ->debugfs_node > - add the mutex as minor->debugfs_lock > That way it's clear what's going on. Yes, you are right. I don't know what the heck I was thinking. > Also, you've forgotten to add the locking to i915/i915_debugfs.c Yeah. Will fix it too. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: serialize access to list of debugfs files
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_debugfs.c | 12 +---
drivers/gpu/drm/i915/i915_debugfs.c |5 -
include/drm/drmP.h |4 +++-
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d2668a..d34d4fc 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -120,7 +120,10 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = &files[i];
- list_add(&(tmp->list), &(minor->debugfs_nodes.list));
+
+ mutex_lock(&minor->debugfs_lock);
+ list_add(&tmp->list, &minor->debugfs_list);
+ mutex_unlock(&minor->debugfs_lock);
}
return 0;
@@ -148,7 +151,8 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
char name[64];
int ret;
- INIT_LIST_HEAD(&minor->debugfs_nodes.list);
+ INIT_LIST_HEAD(&minor->debugfs_list);
+ mutex_init(&minor->debugfs_lock);
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
if (!minor->debugfs_root) {
@@ -194,8 +198,9 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
struct drm_info_node *tmp;
int i;
+ mutex_lock(&minor->debugfs_lock);
for (i = 0; i < count; i++) {
- list_for_each_safe(pos, q, &minor->debugfs_nodes.list) {
+ list_for_each_safe(pos, q, &minor->debugfs_list) {
tmp = list_entry(pos, struct drm_info_node, list);
if (tmp->info_ent == &files[i]) {
debugfs_remove(tmp->dent);
@@ -204,6 +209,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
}
}
}
+ mutex_unlock(&minor->debugfs_lock);
return 0;
}
EXPORT_SYMBOL(drm_debugfs_remove_files);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3c395a5..fdad293 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1505,7 +1505,10 @@ drm_add_fake_info_node(struct drm_minor *minor,
node->minor = minor;
node->dent = ent;
node->info_ent = (void *) key;
- list_add(&node->list, &minor->debugfs_nodes.list);
+
+ mutex_lock(&minor->debugfs_lock);
+ list_add(&node->list, &minor->debugfs_list);
+ mutex_unlock(&minor->debugfs_lock);
return 0;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b7c2bb..40e9ea3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -989,7 +989,9 @@ struct drm_minor {
struct proc_dir_entry *proc_root; /**< proc directory entry */
struct drm_info_node proc_nodes;
struct dentry *debugfs_root;
- struct drm_info_node debugfs_nodes;
+
+ struct list_head debugfs_list;
+ struct mutex debugfs_lock; /* Protects debugfs_list. */
struct drm_master *master; /* currently active master for this node */
struct list_head master_list;
--
1.7.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: serialize access to list of debugfs files
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz
Reviewed-by: Daniel Vetter
---
Updated changelog.
---
drivers/gpu/drm/drm_debugfs.c | 12 +---
drivers/gpu/drm/i915/i915_debugfs.c |5 -
include/drm/drmP.h |4 +++-
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index d067c12..1c7a1c0 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -118,7 +118,10 @@ int drm_debugfs_create_files(struct drm_info_list *files,
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = &files[i];
- list_add(&(tmp->list), &(minor->debugfs_nodes.list));
+
+ mutex_lock(&minor->debugfs_lock);
+ list_add(&tmp->list, &minor->debugfs_list);
+ mutex_unlock(&minor->debugfs_lock);
}
return 0;
@@ -146,7 +149,8 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
char name[64];
int ret;
- INIT_LIST_HEAD(&minor->debugfs_nodes.list);
+ INIT_LIST_HEAD(&minor->debugfs_list);
+ mutex_init(&minor->debugfs_lock);
sprintf(name, "%d", minor_id);
minor->debugfs_root = debugfs_create_dir(name, root);
if (!minor->debugfs_root) {
@@ -192,8 +196,9 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
struct drm_info_node *tmp;
int i;
+ mutex_lock(&minor->debugfs_lock);
for (i = 0; i < count; i++) {
- list_for_each_safe(pos, q, &minor->debugfs_nodes.list) {
+ list_for_each_safe(pos, q, &minor->debugfs_list) {
tmp = list_entry(pos, struct drm_info_node, list);
if (tmp->info_ent == &files[i]) {
debugfs_remove(tmp->dent);
@@ -202,6 +207,7 @@ int drm_debugfs_remove_files(struct drm_info_list *files,
int count,
}
}
}
+ mutex_unlock(&minor->debugfs_lock);
return 0;
}
EXPORT_SYMBOL(drm_debugfs_remove_files);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d14b44e..4f40f1c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1506,7 +1506,10 @@ drm_add_fake_info_node(struct drm_minor *minor,
node->minor = minor;
node->dent = ent;
node->info_ent = (void *) key;
- list_add(&node->list, &minor->debugfs_nodes.list);
+
+ mutex_lock(&minor->debugfs_lock);
+ list_add(&node->list, &minor->debugfs_list);
+ mutex_unlock(&minor->debugfs_lock);
return 0;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cf39949..1f9e951 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -990,7 +990,9 @@ struct drm_minor {
struct proc_dir_entry *proc_root; /**< proc directory entry */
struct drm_info_node proc_nodes;
struct dentry *debugfs_root;
- struct drm_info_node debugfs_nodes;
+
+ struct list_head debugfs_list;
+ struct mutex debugfs_lock; /* Protects debugfs_list. */
struct drm_master *master; /* currently active master for this node */
struct list_head master_list;
--
1.7.7.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915_driver_irq_handler: irq 42: nobody cared
On Tue, Apr 10, 2012 at 10:52:06AM +0200, Jiri Slaby wrote:
> On 04/06/2012 11:31 PM, Jiri Slaby wrote:
> > On 03/30/2012 02:24 PM, Chris Wilson wrote:
> >> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote:
> >>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby wrote:
> > I don't know what to dump more, because iir is obviously zero too. What
> > other sources of interrupts are on the (G33) chip?
>
> IIR is the master interrupt, with chained secondary interrupt statuses.
> If IIR is 0, the interrupt wasn't raised by the GPU.
> >>>
> >>> This does not make sense, the handler does something different. Even if
> >>> IIR is 0, it still takes a look at pipe stats.
> >>
> >> That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close
> >> a race where the pipestat triggered an interrupt after we processed the
> >> secondary registers and before reseting the primary.
> >>
> >> But the basic premise that we should only enter the interrupt handler
> >> with IIR!=0 holds (presuming non-shared interrupt lines such as MSI).
> >
> > Ok, this behavior is definitely new. I get several "nobody cared" about
> > this interrupt a week. This never used to happen. And something weird
> > emerges in /proc/interrupts when this happens:
> > 42:10032921212890 PCI-MSI-edge �s::00:02.0
> > instead of
> > 42:10067151218472 PCI-MSI-edge i915@pci::00:02.0
>
> See the difference of drm_device->devname:
>
> Before:
> 20 34 32 3a 20 20 20 20 31 34 30 35 34 36 32 20 | 42:1405462 |
> 20 20 20 31 37 32 38 33 30 32 20 20 20 50 43 49 | 1728302 PCI|
> 2d 4d 53 49 2d 65 64 67 65 20 20 20 20 20 20 69 |-MSI-edge i|
> 39 31 35 40 70 63 69 3a 30 30 30 30 3a 30 30 3a |915@pci::00:|
> 30 32 2e 30 0a|02.0.|
>
> After:
> 20 34 32 3a 20 20 20 20 31 30 30 33 32 39 32 20 | 42:1003292 |
> 20 20 20 31 32 31 32 38 39 30 20 20 20 50 43 49 | 1212890 PCI|
> 2d 4d 53 49 2d 65 64 67 65 20 20 20 20 20 20 ef |-MSI-edge .|
> bf bd 73 ef bf bd ef bf bd ef bf bd ef bf bd 3a |..s:|
> 30 30 30 30 3a 30 30 3a 30 32 2e 30 0a |:00:02.0.|
>
> Any idea what "ef bf bd" pattern could be? And who *shifts* the
> ":00:02.0" string?
>
Maybe this patch will help catch it:
---
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index cf85155..2f9717c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -69,7 +69,7 @@ static void
drm_unset_busid(struct drm_device *dev,
struct drm_master *master)
{
- kfree(dev->devname);
+ free_pages((unsigned long)dev->devname, 0);
dev->devname = NULL;
kfree(master->unique);
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 13f3d93..d788b78 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -177,9 +177,7 @@ int drm_pci_set_busid(struct drm_device *dev, struct
drm_master *master)
} else
master->unique_len = len;
- dev->devname =
- kmalloc(strlen(pdriver->name) +
- master->unique_len + 2, GFP_KERNEL);
+ dev->devname = (void *)__get_free_pages(GFP_KERNEL, 0);
if (dev->devname == NULL) {
ret = -ENOMEM;
@@ -188,6 +186,7 @@ int drm_pci_set_busid(struct drm_device *dev, struct
drm_master *master)
sprintf(dev->devname, "%s@%s", pdriver->name,
master->unique);
+ set_memory_ro((unsigned long)dev->devname, 1);
return 0;
err:
@@ -217,8 +216,7 @@ int drm_pci_set_unique(struct drm_device *dev,
master->unique[master->unique_len] = '\0';
bus_name = dev->driver->bus->get_name(dev);
- dev->devname = kmalloc(strlen(bus_name) +
- strlen(master->unique) + 2, GFP_KERNEL);
+ dev->devname = (void *)__get_free_pages(GFP_KERNEL, 0);
if (!dev->devname) {
ret = -ENOMEM;
goto err;
@@ -226,6 +224,7 @@ int drm_pci_set_unique(struct drm_device *dev,
sprintf(dev->devname, "%s@%s", bus_name,
master->unique);
+ set_memory_ro((unsigned long)dev->devname, 1);
/* Return error if the busid submitted doesn't match the device's actual
* busid.
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 82431dc..aa0acec 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -148,9 +148,7 @@ static int drm_platform_set_busid(struct drm_device *dev,
struct drm_master *mas
goto err;
}
- dev->devname =
- kmalloc(strlen(dev->platformdev->name) +
- master->unique_len + 2, GFP_KERNEL);
+ dev->devname = (void *)__get_free_pages(GFP_KERNEL, 0);
if (dev->devname == NULL) {
ret
[PATCH 1/5] drm: add optional per device rwsem for all ioctls
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming "gpu reset" code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_drv.c |6 ++
drivers/gpu/drm/drm_stub.c |2 ++
include/drm/drmP.h |4
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6116e3b..c54e9f8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -464,6 +464,9 @@ long drm_ioctl(struct file *filp,
} else
memset(kdata, 0, usize);
+ if (dev->driver->ioctls_need_rwsem)
+ down_read(&dev->ioctls_rwsem);
+
if (ioctl->flags & DRM_UNLOCKED)
retcode = func(dev, kdata, file_priv);
else {
@@ -472,6 +475,9 @@ long drm_ioctl(struct file *filp,
mutex_unlock(&drm_global_mutex);
}
+ if (dev->driver->ioctls_need_rwsem)
+ up_read(&dev->ioctls_rwsem);
+
if (cmd & IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
usize) != 0)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index aa454f8..4af3227 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -275,6 +275,8 @@ int drm_fill_in_dev(struct drm_device *dev,
mutex_init(&dev->struct_mutex);
mutex_init(&dev->ctxlist_mutex);
+ init_rwsem(&dev->ioctls_rwsem);
+
if (drm_ht_create(&dev->map_hash, 12)) {
return -ENOMEM;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index dd73104..527dca5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -954,6 +954,8 @@ struct drm_driver {
int dev_priv_size;
struct drm_ioctl_desc *ioctls;
int num_ioctls;
+ bool ioctls_need_rwsem;
+
const struct file_operations *fops;
union {
struct pci_driver *pci;
@@ -1070,6 +1072,8 @@ struct drm_device {
/*@{ */
spinlock_t count_lock; /**< For inuse, drm_device::open_count,
drm_device::buf_use */
struct mutex struct_mutex; /**< For others */
+
+ struct rw_semaphore ioctls_rwsem;
/*@} */
/** \name Usage Counters */
--
1.7.8.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/nouveau: base fence timeout on time of emission
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index a22b9ad..59f92e9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -44,6 +44,7 @@ struct nouveau_fence {
uint32_t sequence;
bool signalled;
+ unsigned long emitted_at;
void (*work)(void *priv, bool signalled);
void *priv;
@@ -172,6 +173,7 @@ nouveau_fence_emit(struct nouveau_fence *fence)
}
OUT_RING (chan, fence->sequence);
FIRE_RING(chan);
+ fence->emitted_at = jiffies;
return 0;
}
@@ -230,7 +232,8 @@ __nouveau_fence_signalled(void *sync_obj, void *sync_arg)
int
__nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr)
{
- unsigned long timeout = jiffies + (3 * DRM_HZ);
+ struct nouveau_fence *fence = nouveau_fence(sync_obj);
+ unsigned long timeout = fence->emitted_at + 3 * DRM_HZ;
unsigned long sleep_time = NSEC_PER_MSEC / 1000;
ktime_t t;
int ret = 0;
--
1.7.8.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/nouveau: propagate errors from vm flushes
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18 +-
drivers/gpu/drm/nouveau/nv50_fifo.c |4 ++--
drivers/gpu/drm/nouveau/nv50_graph.c | 12
drivers/gpu/drm/nouveau/nv50_mpeg.c |4 ++--
drivers/gpu/drm/nouveau/nv50_vm.c | 30 --
drivers/gpu/drm/nouveau/nv84_crypt.c |4 ++--
drivers/gpu/drm/nouveau/nva3_copy.c |4 ++--
drivers/gpu/drm/nouveau/nvc0_vm.c |3 ++-
11 files changed, 67 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 638ae32..5b0dc50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1230,10 +1230,15 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
return ret;
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
- nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
+ ret = nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else
if (nvbo->bo.mem.mem_type == TTM_PL_TT)
- nouveau_vm_map_sg(vma, 0, size, node);
+ ret = nouveau_vm_map_sg(vma, 0, size, node);
+
+ if (ret) {
+ nouveau_vm_put(vma);
+ return ret;
+ }
list_add_tail(&vma->head, &nvbo->vma_list);
vma->refcount = 1;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 2f8e80a..d120baf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -320,7 +320,7 @@ struct nouveau_exec_engine {
int (*object_new)(struct nouveau_channel *, int engine,
u32 handle, u16 class);
void (*set_tile_region)(struct drm_device *dev, int i);
- void (*tlb_flush)(struct drm_device *, int engine);
+ int (*tlb_flush)(struct drm_device *, int engine);
};
struct nouveau_instmem_engine {
@@ -387,7 +387,7 @@ struct nouveau_fifo_engine {
void (*destroy_context)(struct nouveau_channel *);
int (*load_context)(struct nouveau_channel *);
int (*unload_context)(struct drm_device *);
- void (*tlb_flush)(struct drm_device *dev);
+ int (*tlb_flush)(struct drm_device *dev);
};
struct nouveau_display_engine {
@@ -1246,7 +1246,7 @@ extern int nv50_fifo_create_context(struct
nouveau_channel *);
extern void nv50_fifo_destroy_context(struct nouveau_channel *);
extern int nv50_fifo_load_context(struct nouveau_channel *);
extern int nv50_fifo_unload_context(struct drm_device *);
-extern void nv50_fifo_tlb_flush(struct drm_device *dev);
+extern int nv50_fifo_tlb_flush(struct drm_device *dev);
/* nvc0_fifo.c */
extern int nvc0_fifo_init(struct drm_device *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.c
b/drivers/gpu/drm/nouveau/nouveau_vm.c
index 2bf6c03..e2d4853 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.c
@@ -27,7 +27,7 @@
#include "nouveau_mm.h"
#include "nouveau_vm.h"
-void
+int
nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
{
struct nouveau_vm *vm = vma->vm;
@@ -67,16 +67,16 @@ nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta,
struct nouveau_mem *node)
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_map(struct nouveau_vma *vma, struct nouveau_mem *node)
{
- nouveau_vm_map_at(vma, 0, node);
+ return nouveau_vm_map_at(vma, 0, node);
}
-void
+int
nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
struct nouveau_mem *mem)
{
@@ -110,10 +110,10 @@ nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64
length,
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, u64 length)
{
struct nouveau_vm *vm = vma->vm;
@@ -144,13 +144,13 @@ nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta,
u64 length)
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_unmap(struct nouveau_vma *vma)
{
- nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
+ return nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
}
static void
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.h
b/drivers/gpu/drm/nouveau/nouveau_vm.h
index 4fb6e72..59dc206 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.h
@@ -73,7 +73,7 @@ struct nouveau_vm {
void (*map_sg)(struct
[PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
if ((tmp & 7) == 1)
idle = false;
}
+
+ if (fatal_signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
} while (!idle && !(timeout = ptimer->read(dev) - start > 20));
if (timeout) {
--
1.7.8.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/5] drm/nouveau: gpu lockup recovery
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits
Signed-off-by: Marcin Slusarz
---
Tested only on nv92.
---
drivers/gpu/drm/nouveau/Makefile |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
drivers/gpu/drm/nouveau/nouveau_drv.c |3 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 33 ++-
drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++-
drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
drivers/gpu/drm/nouveau/nouveau_object.c |6 +
drivers/gpu/drm/nouveau/nouveau_reset.c| 144
drivers/gpu/drm/nouveau/nouveau_state.c|5 +
drivers/gpu/drm/nouveau/nv50_graph.c | 11 +-
12 files changed, 221 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 03860f5..77d0c33 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o
nouveau_mem.o \
nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
- nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
+ nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
nv04_timer.o \
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5b0dc50..7de6cad 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
bool intr,
}
/* Software copy if the card isn't up and running yet. */
- if (!dev_priv->channel) {
+ if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev))
{
ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve,
no_wait_gpu, new_mem);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 846afb0..c0fa5a7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
init->fb_ctxdma_handle,
init->tt_ctxdma_handle);
if (ret)
- return ret;
+ goto out;
init->channel = chan->id;
if (nouveau_vram_pushbuf == 0) {
@@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
if (ret == 0)
atomic_inc(&chan->users); /* userspace reference */
nouveau_channel_put(&chan);
+out:
+ if (ret == -EIO)
+ ret = nouveau_reset_device(dev);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 090fff6..22c435f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -237,7 +237,7 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t
pm_state)
if (!dev_priv->eng[e])
continue;
- ret = dev_priv->eng[e]->fini(dev, e, true);
+ ret = dev_priv->eng[e]->fini(dev, e,
!nouveau_gpu_reset_in_progress(dev));
if (ret) {
NV_ERROR(dev, "... engine %d failed: %d\n", e, ret);
goto out_abort;
@@ -483,6 +483,7 @@ static struct drm_driver driver = {
.disable_vblank = nouveau_vblank_disable,
.reclaim_buffers = drm_core_reclaim_buffers,
.ioctls = nouveau_ioctls,
+ .ioctls_need_rwsem = true,
.fops = &nouveau_driver_fops,
.gem_init_object = nouveau_gem_object_new,
.gem_free_object = nouveau_gem_object_del,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index d120baf..01500e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -708,6 +708,10 @@ struct drm_nouveau_private {
struct drm_device *dev;
bool noaccel;
+ struct mutex reset_lock;
+ atomic_t gpureset_in_progress;
+ unsigned long last_gpu_reset
Re: [RFC PATCH 5/5] drm/nouveau: gpu lockup recovery
On Mon, Apr 23, 2012 at 10:43:08AM +0200, Martin Peres wrote: > Le 23/04/2012 00:18, Marcin Slusarz a écrit : > > Overall idea: > > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, > > handle them at ioctl level, reset the GPU and repeat last ioctl. > > > > GPU reset is done by doing suspend / resume cycle with few tweaks: > > - CPU-only bo eviction > > - ignoring vm flush / fence timeouts > > - shortening waits > > > > Signed-off-by: Marcin Slusarz > > --- > > Tested only on nv92. > Hi Marcin, > > I'm really busy at the moment but I'm glad to see such patches coming out. > I'll try them out ASAP! > > Do you have a recommended way to test your patch set? Just run piglit. Even "quick" tests can cause ~5 lockups (it eventually messes up DDX channel, but this patchset can't fix this case). You can run fs-discard-exit-2 test first - for me it causes instant GPU lockup. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: add optional per device rwsem for all ioctls
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote: > On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote: > > Nouveau, in normal circumstances, does not need device lock for every ioctl, > > but incoming "gpu reset" code needs exclusive access to the device. > > This commit adds drm_driver flag which turns on read lock ioctl > > encapsulation. > > > > Signed-off-by: Marcin Slusarz > > Why can't we just move this down to nouveau driver code? I can't wrap drm core ioctls this way and adding locks at driver entry points would be at best unmaintainable, at worst - impossible (some of them are probably called in atomic context). > I really hate adding random stuff to drm core that other drivers can't opt > out of - all the dri1 nightmares are made of these essentially. It's enabled only when driver requested it. I'm not sure what dri1 nightmares you are talking about - I wasn't involved in dri1. Can you elaborate? > And radeon > and i915 seem to be able to reset without adding anything to drm core. Both radeon and i915 take per-device locks (radeon_device->cs_mutex for radeon, drm_device->struct_mutex for i915), which nouveau does not need. They might be bottlenecks some day. > So why can't nouveau do the same? Also, if this is indeed necessary and we > add this as some mandatory core infrastructure, it's not good enough: In > i915 we go to great lengths to ensure that all processes waiting for gpu > reset are still interruptible, in case the gpu reset dies unexpectedly > (which happens), so this would need to be improved. Well, I don't like non-interruptability of rwsems too, but I don't see any other locking primitive which is both interruptible and have read-write semantics. I was hoping someone would point me at one. How gpu reset can "die unexpectedly"? Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed
On Mon, Apr 23, 2012 at 07:09:57PM +0200, Martin Peres wrote:
> Le 23/04/2012 00:18, Marcin Slusarz a écrit :
> > Signed-off-by: Marcin Slusarz
> > ---
> > drivers/gpu/drm/nouveau/nv50_graph.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
> > b/drivers/gpu/drm/nouveau/nv50_graph.c
> > index 6899547..a61853f 100644
> > --- a/drivers/gpu/drm/nouveau/nv50_graph.c
> > +++ b/drivers/gpu/drm/nouveau/nv50_graph.c
> > @@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int
> > engine)
> > if ((tmp& 7) == 1)
> > idle = false;
> > }
> > +
> > + if (fatal_signal_pending(current)) {
> > + ret = -ERESTARTSYS;
> > + break;
> > + }
> > } while (!idle&& !(timeout = ptimer->read(dev) - start> 20));
> >
> > if (timeout) {
> Good, but who should send the kill signal in the first place?
>
> Shouldn't nouveau drm terminate the process(es) associated with the
> channel that generated the lockup ?
Well, this patch is not necessary for gpu reset - it's just "let's be nice"
change.
Currently application is unkillable when hanging on vm flush
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 5/5] drm/nouveau: gpu lockup recovery
On Mon, Apr 23, 2012 at 06:46:41PM +0200, Martin Peres wrote:
> Hey,
>
> Just a minor mistake spotted while skimming through the patch.
>
> Le 23/04/2012 00:18, Marcin Slusarz a écrit :
> > +static inline uint64_t nv_timeout(struct drm_device *dev)
> > +{
> > + uint64_t tm = 20ULL;
> > + if (nouveau_gpu_reset_in_progress(dev))
> > + tm /= 40; /* 50ms */
> This will cause a problem on 32 bit kernels. You should use do_div.
>
Thanks. I'll fix this later.
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 2/5] drm/nouveau: base fence timeout on time of emission
On Tue, Apr 24, 2012 at 12:37:34PM +1000, Ben Skeggs wrote: > On Mon, 2012-04-23 at 00:18 +0200, Marcin Slusarz wrote: > > Wait loop can be interrupted by signal, so if signals are raised > > periodically (e.g. SIGALRM) this loop may never finish. Use > > emission time as a base for fence timeout. > Ah, thanks for tackling this issue. It's been long on my list of things > to do, but never quite made it to the top. > > Rather than hardcoding the timeout in fence_wait(), I think perhaps > storing "fence->timeout = jiffies + (whatever * HZ);" is a better plan. > I can forsee us wanting longer timeouts for certain operations > (particularly long compute operations) in the future. Yeah, good idea. Later, we will probably need to add code which will keep extending this timeout as long as gpu is progressing. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: add optional per device rwsem for all ioctls
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote: > On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote: > > Nouveau, in normal circumstances, does not need device lock for every ioctl, > > but incoming "gpu reset" code needs exclusive access to the device. > > This commit adds drm_driver flag which turns on read lock ioctl > > encapsulation. > > > > Signed-off-by: Marcin Slusarz > > Why can't we just move this down to nouveau driver code? Ok, I think it's easily possible by wrapping drm_ioctl. > So why can't nouveau do the same? Also, if this is indeed necessary and we > add this as some mandatory core infrastructure, it's not good enough: In > i915 we go to great lengths to ensure that all processes waiting for gpu > reset are still interruptible, in case the gpu reset dies unexpectedly > (which happens), so this would need to be improved. I came up with a scheme where down_read can be made interruptible. I'll post both changes in a few days. (Unfortunately adding proper down_read_interruptible / down_write_interruptible require a bit of unfunny work - 8 architectures have their own code for rwsems) Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 5/5] drm/nouveau: gpu lockup recovery
On Mon, Apr 23, 2012 at 06:56:44PM +0200, Martin Peres wrote: > Le 23/04/2012 18:32, Marcin Slusarz a écrit : > > > > Just run piglit. Even "quick" tests can cause ~5 lockups (it eventually > > messes > > up DDX channel, but this patchset can't fix this case). > > You can run fs-discard-exit-2 test first - for me it causes instant GPU > > lockup. > > > > Marcin > Great, Thanks. > > Did you have a look at > https://bugs.freedesktop.org/show_bug.cgi?id=40886 and > http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas ? Yeah, I've seen them some time ago. > The Ubuntu xorg devs were looking for something like this, but they also > wanted a lockup report. Are you also interested on working on it ? Yes, when this patchset will be applied, I'm going to work on improving error reporting. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/nouveau: base fence timeout on time of emission
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index a22b9ad..41ee17d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -44,6 +44,7 @@ struct nouveau_fence {
uint32_t sequence;
bool signalled;
+ unsigned long timeout;
void (*work)(void *priv, bool signalled);
void *priv;
@@ -172,6 +173,7 @@ nouveau_fence_emit(struct nouveau_fence *fence)
}
OUT_RING (chan, fence->sequence);
FIRE_RING(chan);
+ fence->timeout = jiffies + 3 * DRM_HZ;
return 0;
}
@@ -230,7 +232,8 @@ __nouveau_fence_signalled(void *sync_obj, void *sync_arg)
int
__nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr)
{
- unsigned long timeout = jiffies + (3 * DRM_HZ);
+ struct nouveau_fence *fence = nouveau_fence(sync_obj);
+ unsigned long timeout = fence->timeout;
unsigned long sleep_time = NSEC_PER_MSEC / 1000;
ktime_t t;
int ret = 0;
--
1.7.8.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/nouveau: propagate errors from vm flushes
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18 +-
drivers/gpu/drm/nouveau/nv50_fifo.c |4 ++--
drivers/gpu/drm/nouveau/nv50_graph.c | 12
drivers/gpu/drm/nouveau/nv50_mpeg.c |4 ++--
drivers/gpu/drm/nouveau/nv50_vm.c | 30 --
drivers/gpu/drm/nouveau/nv84_crypt.c |4 ++--
drivers/gpu/drm/nouveau/nva3_copy.c |4 ++--
drivers/gpu/drm/nouveau/nvc0_vm.c |3 ++-
11 files changed, 67 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 638ae32..5b0dc50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1230,10 +1230,15 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
return ret;
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
- nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
+ ret = nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else
if (nvbo->bo.mem.mem_type == TTM_PL_TT)
- nouveau_vm_map_sg(vma, 0, size, node);
+ ret = nouveau_vm_map_sg(vma, 0, size, node);
+
+ if (ret) {
+ nouveau_vm_put(vma);
+ return ret;
+ }
list_add_tail(&vma->head, &nvbo->vma_list);
vma->refcount = 1;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 2f8e80a..d120baf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -320,7 +320,7 @@ struct nouveau_exec_engine {
int (*object_new)(struct nouveau_channel *, int engine,
u32 handle, u16 class);
void (*set_tile_region)(struct drm_device *dev, int i);
- void (*tlb_flush)(struct drm_device *, int engine);
+ int (*tlb_flush)(struct drm_device *, int engine);
};
struct nouveau_instmem_engine {
@@ -387,7 +387,7 @@ struct nouveau_fifo_engine {
void (*destroy_context)(struct nouveau_channel *);
int (*load_context)(struct nouveau_channel *);
int (*unload_context)(struct drm_device *);
- void (*tlb_flush)(struct drm_device *dev);
+ int (*tlb_flush)(struct drm_device *dev);
};
struct nouveau_display_engine {
@@ -1246,7 +1246,7 @@ extern int nv50_fifo_create_context(struct
nouveau_channel *);
extern void nv50_fifo_destroy_context(struct nouveau_channel *);
extern int nv50_fifo_load_context(struct nouveau_channel *);
extern int nv50_fifo_unload_context(struct drm_device *);
-extern void nv50_fifo_tlb_flush(struct drm_device *dev);
+extern int nv50_fifo_tlb_flush(struct drm_device *dev);
/* nvc0_fifo.c */
extern int nvc0_fifo_init(struct drm_device *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.c
b/drivers/gpu/drm/nouveau/nouveau_vm.c
index 2bf6c03..e2d4853 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.c
@@ -27,7 +27,7 @@
#include "nouveau_mm.h"
#include "nouveau_vm.h"
-void
+int
nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
{
struct nouveau_vm *vm = vma->vm;
@@ -67,16 +67,16 @@ nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta,
struct nouveau_mem *node)
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_map(struct nouveau_vma *vma, struct nouveau_mem *node)
{
- nouveau_vm_map_at(vma, 0, node);
+ return nouveau_vm_map_at(vma, 0, node);
}
-void
+int
nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
struct nouveau_mem *mem)
{
@@ -110,10 +110,10 @@ nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64
length,
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, u64 length)
{
struct nouveau_vm *vm = vma->vm;
@@ -144,13 +144,13 @@ nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta,
u64 length)
}
}
- vm->flush(vm);
+ return vm->flush(vm);
}
-void
+int
nouveau_vm_unmap(struct nouveau_vma *vma)
{
- nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
+ return nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
}
static void
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.h
b/drivers/gpu/drm/nouveau/nouveau_vm.h
index 4fb6e72..59dc206 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.h
@@ -73,7 +73,7 @@ struct nouveau_vm {
void (*map_sg)(struct
[PATCH v2 3/4] drm/nv50: let applications hanging on vm flush to be killed
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
if ((tmp & 7) == 1)
idle = false;
}
+
+ if (fatal_signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
} while (!idle && !(timeout = ptimer->read(dev) - start > 20));
if (timeout) {
--
1.7.8.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/nouveau: gpu lockup recovery
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/Makefile |2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |5 +-
drivers/gpu/drm/nouveau/nouveau_drv.c | 56 ++-
drivers/gpu/drm/nouveau/nouveau_drv.h | 45 -
drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++-
drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
drivers/gpu/drm/nouveau/nouveau_object.c |6 +
drivers/gpu/drm/nouveau/nouveau_reset.c| 148
drivers/gpu/drm/nouveau/nouveau_state.c|6 +
drivers/gpu/drm/nouveau/nv50_graph.c | 11 +-
12 files changed, 290 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 03860f5..77d0c33 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o
nouveau_mem.o \
nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
- nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
+ nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
nv04_timer.o \
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5b0dc50..7de6cad 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
bool intr,
}
/* Software copy if the card isn't up and running yet. */
- if (!dev_priv->channel) {
+ if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev))
{
ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve,
no_wait_gpu, new_mem);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 846afb0..c0fa5a7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
init->fb_ctxdma_handle,
init->tt_ctxdma_handle);
if (ret)
- return ret;
+ goto out;
init->channel = chan->id;
if (nouveau_vram_pushbuf == 0) {
@@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
if (ret == 0)
atomic_inc(&chan->users); /* userspace reference */
nouveau_channel_put(&chan);
+out:
+ if (ret == -EIO)
+ ret = nouveau_reset_device(dev);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 090fff6..261e1f5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -237,7 +237,7 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t
pm_state)
if (!dev_priv->eng[e])
continue;
- ret = dev_priv->eng[e]->fini(dev, e, true);
+ ret = dev_priv->eng[e]->fini(dev, e,
!nouveau_gpu_reset_in_progress(dev));
if (ret) {
NV_ERROR(dev, "... engine %d failed: %d\n", e, ret);
goto out_abort;
@@ -443,11 +443,63 @@ nouveau_pci_resume(struct pci_dev *pdev)
return 0;
}
+void intr_rwsem_init(struct intr_rwsem *r)
+{
+ init_rwsem(&r->rwsem);
+ mutex_init(&r->mutex);
+}
+
+int intr_rwsem_down_read_interruptible(struct intr_rwsem *r)
+{
+ while (down_read_trylock(&r->rwsem) == 0) {
+ int ret = mutex_lock_interruptible(&r->mutex);
+ if (ret)
+ return ret;
+ mutex_unlock(&r->mutex);
+ }
+ return 0;
+}
+
+void intr_rwsem_up_read(struct intr_rwsem *r)
+{
+ up_read(&r->rwsem);
+}
+
+void intr_rwsem_down_write(struct intr_rwsem *r)
+{
+ mutex_lock(&r->mutex);
+ down_write(&r->rwsem);
+}
+
+void intr_rwsem_up_write(struct intr_
Re: [PATCH v2 4/4] drm/nouveau: gpu lockup recovery
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote: > Overall idea: > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, > handle them at ioctl level, reset the GPU and repeat last ioctl. > > GPU reset is done by doing suspend / resume cycle with few tweaks: > - CPU-only bo eviction > - ignoring vm flush / fence timeouts > - shortening waits > > Signed-off-by: Marcin Slusarz > --- What changed from v1: - moved ioctl locking from drm core to nouveau - made down_reads interruptible - fixed build bug on 32-bit systems ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v2 4/4] drm/nouveau: gpu lockup recovery
On Thu, Apr 26, 2012 at 05:32:29PM +1000, Ben Skeggs wrote: > On Wed, 2012-04-25 at 23:20 +0200, Marcin Slusarz wrote: > > Overall idea: > > Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, > > handle them at ioctl level, reset the GPU and repeat last ioctl. > > > > GPU reset is done by doing suspend / resume cycle with few tweaks: > > - CPU-only bo eviction > > - ignoring vm flush / fence timeouts > > - shortening waits > Okay. I've thought about this a bit for a couple of days and think I'll > be able to coherently share my thoughts on this issue now :) > > Firstly, while I agree that we need to become more resilient to errors, > I don't think that following in the radeon/intel footsteps with > something (imo, hackish) like this is the right choice for us > necessarily. This is not only radeon/intel way. Windows, since Vista SP1, does the same - see http://msdn.microsoft.com/en-us/windows/hardware/gg487368. It's funny how similar it is to this patch (I haven't seen this page earlier). If you fear people will stop reporting bugs - don't. GPU reset is painfully slow and can take up to 50 seconds (BO eviction is the most time consuming part), so people will be annoyed enough to report them. Currently, GPU lockups make users so angry, they frequently switch to blob without even thinking about reporting anything. > The *vast* majority of "lockups" we have are as a result of us badly > mishandling exceptions reported to us by the GPU. There are a couple of > exceptions, however, they're very rare.. > A very common example is where people gain DMA_PUSHERs for whatever > reason, and things go haywire eventually. Nope, I had tens of lockups during testing, and only once I had DMA_PUSHER before detecting GPU lockup. > To handle a DMA_PUSHER > sanely, generally you have to drop all pending commands for the channel > (set GET=PUT, etc) and continue on. However, this leaves us with fences > and semaphores unsignalled etc, causing issues further up the stack with > perfectly good channels hanging on attempting to sync with the crashed > channel etc. > > The next most common example I can think of is nv4x hardware, getting a > LIMIT_COLOR/ZETA exception from PGRAPH, and then a hang. The solution > is simple, learn how to handle the exception, log it, and PGRAPH > survives. > > I strongly believe that if we focused our efforts on dealing with what > the GPU reports to us a lot better, we'll find we really don't need such > "lockup recovery". While I agree we need to improve on error handling to make "lockup recovery" not needed, the reality is we can't predict everything and driver needs to cope with its own bugs. > I am, however, considering pulling the vm flush timeout error > propagation and break-out-of-waits-on-signals that builds on it. As we > really do need to become better at having killable processes if things > go wrong :) Good :) Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: add vmap interface (v2)
On Thu, May 17, 2012 at 06:32:19AM -0600, Rob Clark wrote:
> On Thu, May 17, 2012 at 4:31 AM, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > The main requirement I have for this interface is for scanning out
> > using the USB gpu devices. Since these devices have to read the
> > framebuffer on updates and linearly compress it, using kmaps
> > is a major overhead for every update.
> >
> > v2: fix warn issues pointed out by Sylwester Nawrocki.
> >
> > Signed-off-by: Dave Airlie
> > ---
> > drivers/base/dma-buf.c | 34 ++
> > include/linux/dma-buf.h | 14 ++
> > 2 files changed, 48 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> > index 07cbbc6..750f92c 100644
> > --- a/drivers/base/dma-buf.c
> > +++ b/drivers/base/dma-buf.c
> > @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned
> > long page_num,
> > dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> > }
> > EXPORT_SYMBOL_GPL(dma_buf_kunmap);
> > +
> > +/**
> > + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel
> > address space. The same restrictions as for vmap and friends apply.
> > + * @dma_buf: [in] buffer to vmap
> > + *
> > + * This call may fail due to lack of virtual mapping address space.
> > + * These calls are optional in drivers. The intended use for them
> > + * is for mapping objects linear in kernel space for high use objects.
> > + * Please attempt to use kmap/kunmap before thinking about these
> > interfaces.
> > + */
> > +void *dma_buf_vmap(struct dma_buf *dmabuf)
> > +{
> > + if (WARN_ON(!dmabuf))
> > + return NULL;
> > +
> > + if (dmabuf->ops->vmap)
> > + return dmabuf->ops->vmap(dmabuf);
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL(dma_buf_vmap);
> > +
> > +/**
> > + * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
> > + * @dma_buf: [in] buffer to vmap
> > + */
> > +void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> > +{
> > + if (WARN_ON(!dmabuf))
> > + return;
> > +
> > + if (dmabuf->ops->vunmap)
> > + dmabuf->ops->vunmap(dmabuf, vaddr);
> > +}
> > +EXPORT_SYMBOL(dma_buf_vunmap);
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 3efbfc2..b92b6de 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -92,6 +92,9 @@ struct dma_buf_ops {
> > void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *);
> > void *(*kmap)(struct dma_buf *, unsigned long);
> > void (*kunmap)(struct dma_buf *, unsigned long, void *);
> > +
> > + void *(*vmap)(struct dma_buf *);
> > + void (*vunmap)(struct dma_buf *, void *vaddr);
> > };
> >
> > /**
> > @@ -167,6 +170,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned
> > long);
> > void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
> > void *dma_buf_kmap(struct dma_buf *, unsigned long);
> > void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
> > +
> > +void *dma_buf_vmap(struct dma_buf *);
> > +void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> > #else
> >
> > static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> > *dmabuf,
> > @@ -248,6 +254,14 @@ static inline void dma_buf_kunmap(struct dma_buf
> > *dmabuf,
> > unsigned long pnum, void *vaddr)
> > {
> > }
> > +
> > +static inline void *dma_buf_vmap(struct dma_buf *)
> > +{
> > +}
> > +
> > +static inline void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> > +{
> > +}
>
> I think these two will cause compile issues for
> !CONFIG_DMA_SHARED_BUFFER case due to no parameter name for first arg.
And because of ";" between ) and { :)
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: do not expose vblank data before drm_vblank_init completes
On Thu, May 24, 2012 at 08:09:41PM +0200, Bruno Prémont wrote:
> I can easily trigger a crash in nouveau interrupt handler by unbinding
> and rebinding the GPU.
>
> The command used:
> echo $pci_device > nouveau/unbind && \
> sleep 5 && \
> echo $pci_device > nouveau/bind
>
>
> Kernel is 3.4.0 with modular drm/nouveau.
> GPU is NVidia nForce IGP (NV11)
>
>
> Unbinding seems to work fine, display switching back to VGA text mode.
> Rebinding the GPU slightly later causes the below trace:
>
> (...)
It crashed because Nouveau failed to disable vblank interrupt on unbind
and this interrupt triggered while drm was initializing vblank data.
Nouveau side was fixed by "drm/nv04/disp: disable vblank interrupts when
disabling display" by Ben Skeggs (3.5 merge window), drm side can be fixed
by this:
---
From: Marcin Slusarz
Subject: [PATCH] drm: do not expose vblank data before drm_vblank_init completes
It fixes oops in drm_handle_vblank when vblank interrupt triggers before
drm_vblank_init completes. Driver side should not let this happen, but let's
be on the safe side and handle this case.
Reported-by: Bruno Prémont
Tested-by: Bruno Prémont
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_irq.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c869436..7dda18c 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -183,12 +183,8 @@ static void vblank_disable_fn(unsigned long arg)
}
}
-void drm_vblank_cleanup(struct drm_device *dev)
+static void __drm_vblank_cleanup(struct drm_device *dev)
{
- /* Bail if the driver didn't call drm_vblank_init() */
- if (dev->num_crtcs == 0)
- return;
-
del_timer(&dev->vblank_disable_timer);
vblank_disable_fn((unsigned long)dev);
@@ -201,6 +197,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
kfree(dev->last_vblank_wait);
kfree(dev->vblank_inmodeset);
kfree(dev->_vblank_time);
+}
+
+void drm_vblank_cleanup(struct drm_device *dev)
+{
+ /* Bail if the driver didn't call drm_vblank_init() */
+ if (dev->num_crtcs == 0)
+ return;
+
+ __drm_vblank_cleanup(dev);
dev->num_crtcs = 0;
}
@@ -215,8 +220,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
spin_lock_init(&dev->vbl_lock);
spin_lock_init(&dev->vblank_time_lock);
- dev->num_crtcs = num_crtcs;
-
dev->vbl_queue = kmalloc(sizeof(wait_queue_head_t) * num_crtcs,
GFP_KERNEL);
if (!dev->vbl_queue)
@@ -268,10 +271,12 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
}
dev->vblank_disable_allowed = 0;
+ dev->num_crtcs = num_crtcs;
+
return 0;
err:
- drm_vblank_cleanup(dev);
+ __drm_vblank_cleanup(dev);
return ret;
}
EXPORT_SYMBOL(drm_vblank_init);
--
1.7.8.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: do not expose vblank data before drm_vblank_init completes
On Sun, May 27, 2012 at 10:25:21PM +0200, Marcin Slusarz wrote:
> On Thu, May 24, 2012 at 08:09:41PM +0200, Bruno Prémont wrote:
> > I can easily trigger a crash in nouveau interrupt handler by unbinding
> > and rebinding the GPU.
> >
> > The command used:
> > echo $pci_device > nouveau/unbind && \
> > sleep 5 && \
> > echo $pci_device > nouveau/bind
> >
> >
> > Kernel is 3.4.0 with modular drm/nouveau.
> > GPU is NVidia nForce IGP (NV11)
> >
> >
> > Unbinding seems to work fine, display switching back to VGA text mode.
> > Rebinding the GPU slightly later causes the below trace:
> >
> > (...)
>
> It crashed because Nouveau failed to disable vblank interrupt on unbind
> and this interrupt triggered while drm was initializing vblank data.
>
> Nouveau side was fixed by "drm/nv04/disp: disable vblank interrupts when
> disabling display" by Ben Skeggs (3.5 merge window), drm side can be fixed
> by this:
>
> ---
> From: Marcin Slusarz
> Subject: [PATCH] drm: do not expose vblank data before drm_vblank_init
> completes
>
> It fixes oops in drm_handle_vblank when vblank interrupt triggers before
> drm_vblank_init completes. Driver side should not let this happen, but let's
> be on the safe side and handle this case.
>
> Reported-by: Bruno Prémont
> Tested-by: Bruno Prémont
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/drm_irq.c | 21 +
> 1 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c869436..7dda18c 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -183,12 +183,8 @@ static void vblank_disable_fn(unsigned long arg)
> }
> }
>
> -void drm_vblank_cleanup(struct drm_device *dev)
> +static void __drm_vblank_cleanup(struct drm_device *dev)
> {
> - /* Bail if the driver didn't call drm_vblank_init() */
> - if (dev->num_crtcs == 0)
> - return;
> -
> del_timer(&dev->vblank_disable_timer);
>
> vblank_disable_fn((unsigned long)dev);
> @@ -201,6 +197,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
> kfree(dev->last_vblank_wait);
> kfree(dev->vblank_inmodeset);
> kfree(dev->_vblank_time);
> +}
> +
> +void drm_vblank_cleanup(struct drm_device *dev)
> +{
> + /* Bail if the driver didn't call drm_vblank_init() */
> + if (dev->num_crtcs == 0)
> + return;
> +
> + __drm_vblank_cleanup(dev);
>
> dev->num_crtcs = 0;
> }
> @@ -215,8 +220,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
> spin_lock_init(&dev->vbl_lock);
> spin_lock_init(&dev->vblank_time_lock);
>
> - dev->num_crtcs = num_crtcs;
> -
> dev->vbl_queue = kmalloc(sizeof(wait_queue_head_t) * num_crtcs,
>GFP_KERNEL);
> if (!dev->vbl_queue)
> @@ -268,10 +271,12 @@ int drm_vblank_init(struct drm_device *dev, int
> num_crtcs)
> }
>
> dev->vblank_disable_allowed = 0;
> + dev->num_crtcs = num_crtcs;
> +
> return 0;
>
> err:
> - drm_vblank_cleanup(dev);
> + __drm_vblank_cleanup(dev);
> return ret;
> }
> EXPORT_SYMBOL(drm_vblank_init);
> --
Dave?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [libdrm PATCH 4/4] xf86drm.c: Make more code UDEV unrelevant and fix a memory leak.
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
> ---
> xf86drm.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 6ea068f..798f1fd 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -255,6 +255,7 @@ static int drmMatchBusID(const char *id1, const char
> *id2, int pci_domain_ok)
> return 0;
> }
>
> +#if !defined(UDEV)
> /**
> * Handles error checking for chown call.
> *
> @@ -284,6 +285,7 @@ static int chown_check_return(const char *path, uid_t
> owner, gid_t group)
> path, errno, strerror(errno));
> return -1;
> }
> +#endif
>
> /**
> * Open the DRM device, creating it if necessary.
> @@ -303,13 +305,15 @@ static int drmOpenDevice(long dev, int minor, int type)
> stat_t st;
> charbuf[64];
> int fd;
> +
> +sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> +drmMsg("drmOpenDevice: node name is %s\n", buf);
> +
> +#if !defined(UDEV)
> mode_t devmode = DRM_DEV_MODE, serv_mode;
> int isroot = !geteuid();
> uid_t user= DRM_DEV_UID;
> gid_t group = DRM_DEV_GID, serv_group;
> -
> -sprintf(buf, type ? DRM_DEV_NAME : DRM_CONTROL_DEV_NAME, DRM_DIR_NAME,
> minor);
> -drmMsg("drmOpenDevice: node name is %s\n", buf);
>
> if (drm_server_info) {
> drm_server_info->get_perms(&serv_group, &serv_mode);
> @@ -318,7 +322,6 @@ static int drmOpenDevice(long dev, int minor, int type)
> group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> }
>
> -#if !defined(UDEV)
> if (stat(DRM_DIR_NAME, &st)) {
> if (!isroot)
> return DRM_ERR_NOT_ROOT;
You should not mix code with declarations.
However, UDEV and non-UDEV codepaths share very little code. I'm wondering
whether it would be better to organize it like:
static int drmOpenDevice(long dev, int minor, int type)
{
#if defined(UDEV)
...
#else
...
#endif
}
> @@ -1395,8 +1398,10 @@ drm_context_t *drmGetReservedContextList(int fd, int
> *count)
> }
>
> res.contexts = list;
> -if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res))
> +if (drmIoctl(fd, DRM_IOCTL_RES_CTX, &res)) {
> + drmFree(retval);
> return NULL;
> +}
>
> for (i = 0; i < res.count; i++)
> retval[i] = list[i].handle;
> --
This is not enough. list will leak too.
Make it a separate patch please.
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: libdrm: Fix some warnings reported by clang's scan-build tool
On Fri, Jul 13, 2012 at 05:49:12PM +0200, Johannes Obermayr wrote: > > Patches 1 to 4 were sent to mesa-dev. And you chose to ignore most of my comments. Fine. Don't expect further reviews from me. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 23, 2012 at 08:01:14PM +0200, Ortwin Glück wrote: > Hi, > > My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with > 3.4. Bisected to the following commit: > > 20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit > commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e > Author: Ben Skeggs > Date: Mon Apr 30 11:33:43 2012 -0500 > > drm/nouveau: create real execution engine for software object class > > Just a cleanup more or less, and to remove the need for special > handling of > software objects. > > This removes a heap of documentation on dma/graph object formats. > The info > is very out of date with our current understanding, and is far better > documented in rnndb in envytools git. > > Signed-off-by: Ben Skeggs > > lspci: > 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX > 1800M] (rev a2) > Please post the crash log. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Tue, Jul 24, 2012 at 07:22:52PM +0200, Ortwin Glück wrote: > On 24.07.2012 19:00, Marcin Slusarz wrote: > > Please post the crash log. > > Sorry, I was not precise: it boots until drm performs modesetting (so it > seems). The screen goes black and the machine is dead. So there is > nothing I could post here, unfortunately. > > This is a video of 3.5 booting: > http://www.odi.ch/VIDEO0010.3gp Does it work if you boot without X and modprobe nouveau manually? If it does, can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau device section) and recheck with X? Does it work if you disable acceleration (nouveau.noaccel=1 in kernel command line)? Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Wed, Jul 25, 2012 at 10:46:49AM +0200, Ortwin Glück wrote:
> > Does it work if you boot without X and modprobe nouveau manually? If it
> > does,
> > can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> > device section) and recheck with X?
>
> It happens long before X, when the nouveau module is loaded.
>
> > Does it work if you disable acceleration (nouveau.noaccel=1 in kernel
> > command
> > line)?
>
> nouveau.noaccel=1 is already on my cmdline as running X with accel
> enabled never worked anyway.
>
> > Is there anything saved in /var/log/ from previous boot? Can you ssh
> > into and check dmesg? Can you use netconsole and catch full log?
>
> Thanks for the netconsole tip. I have attached the log.
>
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
--
From: Marcin Slusarz
Date: Wed, 25 Jul 2012 20:07:22 +0200
Subject: [PATCH] drm/nouveau: init vblank requests list
Fixes kernel panic when vblank interrupt triggers before first sync to vblank
request.
(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: Ortwin Glück
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org [3.5]
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 --
drivers/gpu/drm/nouveau/nouveau_irq.c |4
drivers/gpu/drm/nouveau/nouveau_software.h |1 +
3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8613cb2..b863a3a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -689,8 +689,6 @@ struct drm_nouveau_private {
void (*irq_handler[32])(struct drm_device *);
bool msi_enabled;
- struct list_head vbl_waiting;
-
struct {
struct drm_global_reference mem_global_ref;
struct ttm_bo_global_ref bo_global_ref;
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 868c7fd..b2c2937 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -41,12 +41,8 @@
void
nouveau_irq_preinstall(struct drm_device *dev)
{
- struct drm_nouveau_private *dev_priv = dev->dev_private;
-
/* Master disable */
nv_wr32(dev, NV03_PMC_INTR_EN_0, 0);
-
- INIT_LIST_HEAD(&dev_priv->vbl_waiting);
}
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_software.h
b/drivers/gpu/drm/nouveau/nouveau_software.h
index e60bc6c..b507a92 100644
--- a/drivers/gpu/drm/nouveau/nouveau_software.h
+++ b/drivers/gpu/drm/nouveau/nouveau_software.h
@@ -38,6 +38,7 @@ static inline void
nouveau_software_context_new(struct nouveau_software_chan *pch)
{
INIT_LIST_HEAD(&pch->flip);
+ INIT_LIST_HEAD(&pch->vblank.list);
}
static inline void
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... I didn't look at it yet, but can you catch panic with maxcpus=1? Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Thu, Jul 26, 2012 at 02:56:22PM +0200, Ortwin Glück wrote: > On 25.07.2012 20:42, Marcin Slusarz wrote: > > Good, below patch should fix this panic. > > > > Note that you can hit an oops in drm_handle_vblank because patch from > > http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html > > has not been applied (yet?). > > After applying your patch, it still crashes, although with a slightly > different stack trace. I then also applied the second patch, but that > doesn't make any difference. New log attached. > > Looks like interrupt occurs before nouveau_software_context_new() is > called? Shouldn't the initialization be done from > nouveau_irq_preinstall() so it is available when the irq occurs? Again, > I am not an expert here. Just guessing... No, the real problem is: with "noaccel" we don't register "software engine", but vblank ISR relies on its existance and happily derefences NULL pointer. Now, this patch should fix it for real... --- From: Marcin Slusarz Subject: [PATCH] drm/nouveau: disable vblank interrupts before registering PDISPLAY ISR Currently, we register vblank IRQ handler and later we disable vblank interrupts. So, for the short amount of time, we rely on vblank ISR to operate correctly, even if vblank interrupts are never going to be used later. In "noaccel" case, software engine - which is used by vblank ISR - is not registered, so if vblank interrupt triggers in a wrong moment, we can hit NULL pointer dereference in nouveau_software_vblank. To fix it, disable vblank interrupts before registering PDISPLAY ISR. Reported-by: Ortwin Glück Signed-off-by: Marcin Slusarz Cc: sta...@vger.kernel.org [3.5] --- drivers/gpu/drm/nouveau/nv04_crtc.c|1 + drivers/gpu/drm/nouveau/nv50_crtc.c|1 + drivers/gpu/drm/nouveau/nvd0_display.c |2 ++ 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c b/drivers/gpu/drm/nouveau/nv04_crtc.c index 4c31c63..38bfe8d 100644 --- a/drivers/gpu/drm/nouveau/nv04_crtc.c +++ b/drivers/gpu/drm/nouveau/nv04_crtc.c @@ -1057,6 +1057,7 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num) } nv04_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, crtc_num); return 0; } diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c b/drivers/gpu/drm/nouveau/nv50_crtc.c index 97a477b..7648f52 100644 --- a/drivers/gpu/drm/nouveau/nv50_crtc.c +++ b/drivers/gpu/drm/nouveau/nv50_crtc.c @@ -792,6 +792,7 @@ nv50_crtc_create(struct drm_device *dev, int index) goto out; nv50_cursor_init(nv_crtc); + nouveau_vblank_disable(dev, index); out: if (ret) nv50_crtc_destroy(&nv_crtc->base); diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c b/drivers/gpu/drm/nouveau/nvd0_display.c index c486d3c..32f8a86 100644 --- a/drivers/gpu/drm/nouveau/nvd0_display.c +++ b/drivers/gpu/drm/nouveau/nvd0_display.c @@ -908,6 +908,8 @@ nvd0_crtc_create(struct drm_device *dev, int index) goto out; nvd0_crtc_lut_load(crtc); + /* uncomment once nvd0 vblank lands */ + /* nouveau_vblank_disable(dev, index); */ out: if (ret) -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Mon, Jul 30, 2012 at 01:16:37PM +0200, Ortwin Glück wrote: > On 29.07.2012 22:15, Marcin Slusarz wrote: > > No, the real problem is: with "noaccel" we don't register "software engine", > > but vblank ISR relies on its existance and happily derefences NULL pointer. > > > > Now, this patch should fix it for real... > > Unfortunately I am still seeing the crash. Without "noaccel" it works though > (until X crashes the machine, but that is a different thing). Are you sure you boot the correct kernel? I'm asking because your panic says its version is "3.5.0 #3" - exactly the same as in previous crash log. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/nouveau: crash regression in 3.5
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
> I have managed to turn the crash into a WARN_ON, by adding this to the
> begin of nouveau_software_vblank():
>
> if (!psw) {
> WARN_ON(1);
> return;
> }
Yes, I know about it, but this change fixes only a symptom. We should not get
into this code at all without enabling vblank.
> And I have also managed to load the module manually instead by udev. So
> I am happy to attach a full log of what's going on here. See also my
> added printk's starting with XXX that mark some interesting points in
> the initialization.
>
> This should give you enough information to track down the cause of the
> problem. To my non-expert eyes it looks like "noaccel" prevents
> registration of NVOBJ_ENGINE_SW or at least delays it too much.
Yes, that's what I wrote in my last patch - with noaccel it's not registered,
which leads to NULL pointer derefence.
I'm currently out of ideas why my patch does not work. But I have some ideas
how to debug it. Can you come to nouveau IRC channel at freenode and do some
additional tests? My nick is "joi" and I'm available on IRC between 6pm and
11pm CEST.
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: add lockdep annotations
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
2) DRM client can be locked under user client lock - tell lockdep to put DRM
client lock in a separate class.
Reported-by: Arend van Spriel
Reported-by: Peter Hurley
Reported-by: Maarten Lankhorst
Reported-by: Daniel J Blueman
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
---
Lightly tested, only on NV4B and NVC1.
---
drivers/gpu/drm/nouveau/core/core/subdev.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/object.h | 7 +--
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/subdev.c
b/drivers/gpu/drm/nouveau/core/core/subdev.c
index f74c30a..48f0637 100644
--- a/drivers/gpu/drm/nouveau/core/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/core/core/subdev.c
@@ -99,7 +99,7 @@ nouveau_subdev_create_(struct nouveau_object *parent,
if (ret)
return ret;
- mutex_init(&subdev->mutex);
+ __mutex_init(&subdev->mutex, subname, &oclass->lock_class_key);
subdev->name = subname;
if (parent) {
diff --git a/drivers/gpu/drm/nouveau/core/include/core/object.h
b/drivers/gpu/drm/nouveau/core/include/core/object.h
index 6a90267..62e68ba 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/object.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/object.h
@@ -50,10 +50,13 @@ int nouveau_object_fini(struct nouveau_object *, bool
suspend);
extern struct nouveau_ofuncs nouveau_object_ofuncs;
+/* Don't allocate dynamically, because lockdep needs lock_class_keys to be in
+ * ".data". */
struct nouveau_oclass {
u32 handle;
- struct nouveau_ofuncs *ofuncs;
- struct nouveau_omthds *omthds;
+ struct nouveau_ofuncs * const ofuncs;
+ struct nouveau_omthds * const omthds;
+ struct lock_class_key lock_class_key;
};
#define nv_oclass(o)nv_object(o)->oclass
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ef1ad21..bc00587 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -245,6 +245,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return 0;
}
+static struct lock_class_key drm_client_lock_class_key;
+
static int
nouveau_drm_load(struct drm_device *dev, unsigned long flags)
{
@@ -256,6 +258,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
if (ret)
return ret;
+ lockdep_set_class(&drm->client.mutex, &drm_client_lock_class_key);
dev->dev_private = drm;
drm->dev = dev;
--
1.8.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
On Sat, Feb 16, 2013 at 12:57:07AM +0200, Denys Fedoryshchenko wrote: > Hi > > Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce > 310M], latest rc, and got this. > Please let me know if you need additional information. It's harmless and already quieted down in Linus' tree (post 3.8-rc7). (Commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55) Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: > Hi, > > we have a report of WARNING from 3.7.6 in nouveau at > drivers/gpu/drm/nouveau/core/core/mm.c:242 here: > https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 > > There is an order 4 allocation failure in nouveau_drm_open -> > nouveau_vm_create, i.e. this one failed: > vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); > > Then, on the error path in still in nouveau_drm_open, it is followed by > a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -> > nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the > warning. > > Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 "drm/nouveau/vm: fix memory corruption when pgt allocation fails". Tomorrow I'll post a patch for page allocation failure. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote: > On 02/19/2013 12:23 AM, Marcin Slusarz wrote: > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> we have a report of WARNING from 3.7.6 in nouveau at > >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here: > >> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 > >> > >> There is an order 4 allocation failure in nouveau_drm_open -> > >> nouveau_vm_create, i.e. this one failed: > >> vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); > >> > >> Then, on the error path in still in nouveau_drm_open, it is followed by > >> a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -> > >> nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the > >> warning. > >> > >> Any ideas? > > > > Crash/warning should be fixed by commit > > cfd376b6bfccf33782a0748a9c70f7f752f8b869 > > "drm/nouveau/vm: fix memory corruption when pgt allocation fails". > > Oh, thanks for the pointer. Could that bug cause real "memory > corruption"? As we're hunting one there... Yes. > Isn't this a stable-3.7 candidate? Should have been :/. > > Tomorrow I'll post a patch for page allocation failure. > > What do you mean -- what kind of patch? A patch which will change pgt allocation to use vmalloc. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix suspend bug in nvc0 fence implementation
On Tue, Feb 19, 2013 at 10:20:55AM +, Maarten Lankhorst wrote:
> Everywhere else the constant is multiplied by 16/4, so it looks like
> nvc0_fence_suspend/resume is buggy here.
>
> Signed-off-by: Maarten Lankhorst
> Cc: sta...@vger.kernel.org [3.7+]
Yay. It will probably fix https://bugs.freedesktop.org/show_bug.cgi?id=59168.
(note: it doesn't apply on top of nouveau/master)
Reviewed-by: Marcin Slusarz
> ---
>
> diff --git a/drivers/gpu/drm/nouveau/nvc0_fence.c
> b/drivers/gpu/drm/nouveau/nvc0_fence.c
> index 85a0e78..4f46d8b 100644
> --- a/drivers/gpu/drm/nouveau/nvc0_fence.c
> +++ b/drivers/gpu/drm/nouveau/nvc0_fence.c
> @@ -161,11 +161,12 @@ nvc0_fence_suspend(struct nouveau_drm *drm)
> struct nouveau_fifo *pfifo = nouveau_fifo(drm->device);
> struct nvc0_fence_priv *priv = drm->fence;
> int i;
> + u32 chan = pfifo->max + 1;
>
> - priv->suspend = vmalloc((pfifo->max + 1) * sizeof(u32));
> + priv->suspend = vmalloc(chan * sizeof(u32));
> if (priv->suspend) {
> - for (i = 0; i <= pfifo->max; i++)
> - priv->suspend[i] = nouveau_bo_rd32(priv->bo, i);
> + for (i = 0; i < chan; i++)
> + priv->suspend[i] = nouveau_bo_rd32(priv->bo, i * 16/4);
> }
>
> return priv->suspend != NULL;
> @@ -177,10 +178,11 @@ nvc0_fence_resume(struct nouveau_drm *drm)
> struct nouveau_fifo *pfifo = nouveau_fifo(drm->device);
> struct nvc0_fence_priv *priv = drm->fence;
> int i;
> + u32 chan = pfifo->max + 1;
>
> if (priv->suspend) {
> - for (i = 0; i <= pfifo->max; i++)
> - nouveau_bo_wr32(priv->bo, i, priv->suspend[i]);
> + for (i = 0; i < chan; i++)
> + nouveau_bo_wr32(priv->bo, i * 16/4, priv->suspend[i]);
> vfree(priv->suspend);
> priv->suspend = NULL;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: fix suspend bug in nvc0 fence implementation
On Tue, Feb 19, 2013 at 10:09:12PM +0100, Michael Weirauch wrote: > 2013/2/19 Marcin Slusarz : > > Yay. It will probably fix > > https://bugs.freedesktop.org/show_bug.cgi?id=59168. > > (note: it doesn't apply on top of nouveau/master) > > Please correct me if I am wrong, but doesn't nv84_fence_[resume,suspend] > on current nouveau-3.8.0_rc7 (master) which is "used" by nvc0_fence.c > "identical" to what this patch does? > > nvc0_fence_create-> > nv84_fence_create sets up: > priv->base.suspend = nv84_fence_suspend; > priv->base.resume = nv84_fence_resume; > > There is no dedicated nvc0_fence_[resume,suspend] impl from what I grasped. > > c.f.: > http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/nv84_fence.c#n178 This patch is only for 3.7 and 3.8 kernels. Nouveau/master contains refactored fence code which will be submitted for 3.9. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
> > On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> > >> Hi,
> > >>
> > >> we have a report of WARNING from 3.7.6 in nouveau at
> > >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
> > >> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11
> > >>
> > >> There is an order 4 allocation failure in nouveau_drm_open ->
> > >> nouveau_vm_create, i.e. this one failed:
> > >> vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
> > >> GFP_KERNEL);
> > >>
> > >> Then, on the error path in still in nouveau_drm_open, it is followed by
> > >> a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref ->
> > >> nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the
> > >> warning.
> > >>
> > >> Any ideas?
> > >
> > > Crash/warning should be fixed by commit
> > > cfd376b6bfccf33782a0748a9c70f7f752f8b869
> > > "drm/nouveau/vm: fix memory corruption when pgt allocation fails".
> >
> > Oh, thanks for the pointer. Could that bug cause real "memory
> > corruption"? As we're hunting one there...
>
> Yes.
>
> > Isn't this a stable-3.7 candidate?
>
> Should have been :/.
>
> > > Tomorrow I'll post a patch for page allocation failure.
> >
> > What do you mean -- what kind of patch?
>
> A patch which will change pgt allocation to use vmalloc.
---
From: Marcin Slusarz
Subject: [PATCH] drm/nouveau: use vmalloc for pgt allocation
Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
Let's use vmalloc.
Signed-off-by: Marcin Slusarz
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 77c67fc..e66fb77 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
vm->fpde = offset >> (vmm->pgt_bits + 12);
vm->lpde = (offset + length - 1) >> (vmm->pgt_bits + 12);
- vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
GFP_KERNEL);
+ vm->pgt = vzalloc((vm->lpde - vm->fpde + 1) * sizeof(*vm->pgt));
if (!vm->pgt) {
kfree(vm);
return -ENOMEM;
@@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
u64 length,
ret = nouveau_mm_init(&vm->mm, mm_offset >> 12, mm_length >> 12,
block >> 12);
if (ret) {
- kfree(vm->pgt);
+ vfree(vm->pgt);
kfree(vm);
return ret;
}
@@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
}
nouveau_mm_fini(&vm->mm);
- kfree(vm->pgt);
+ vfree(vm->pgt);
kfree(vm);
}
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [stable request] fix for nouveau mem corruption [was: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242]
On Wed, Feb 20, 2013 at 03:47:05PM +0100, Jiri Slaby wrote: > On 02/19/2013 08:07 AM, Marcin Slusarz wrote: > >>> Crash/warning should be fixed by commit > >>> cfd376b6bfccf33782a0748a9c70f7f752f8b869 > >>> "drm/nouveau/vm: fix memory corruption when pgt allocation fails". > >> > >> Oh, thanks for the pointer. Could that bug cause real "memory > >> corruption"? As we're hunting one there... > > > > Yes. > > > >> Isn't this a stable-3.7 candidate? > > > > Should have been :/. > > Ok, if you have no objections: stable fellows, please consider the > commit above for stable inclusion. As far as I can tell this is only > applicable for 3.7 -- Marcin? Correct. Please apply it for 3.7.x. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix regression in vblanking
On Tue, Mar 05, 2013 at 02:59:26PM +0100, Maarten Lankhorst wrote:
> nv50_vblank_enable/disable got switched from
> NV50_PDISPLAY_INTR_EN_1_VBLANK_CRTC_0 (4) << head to 1 << head, which is
> wrong.
>
> 4 << head is the correct value.
>
> Fixes regression with vblanking since 1d7c71a3e2f77 "drm/nouveau/disp: port
> vblank handling to event interface"
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> index 5fa1326..02e369f 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> @@ -544,13 +544,13 @@ nv50_disp_curs_ofuncs = {
> static void
> nv50_disp_base_vblank_enable(struct nouveau_event *event, int head)
> {
> - nv_mask(event->priv, 0x61002c, (1 << head), (1 << head));
> + nv_mask(event->priv, 0x61002c, (4 << head), (4 << head));
> }
>
> static void
> nv50_disp_base_vblank_disable(struct nouveau_event *event, int head)
> {
> - nv_mask(event->priv, 0x61002c, (1 << head), (0 << head));
> + nv_mask(event->priv, 0x61002c, (4 << head), 0);
> }
>
> static int
>
It fixes vblank on my NVA8, thanks.
Tested-by: Marcin Slusarz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > ... > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow keywords to match filenames") of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines
On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> Fixes 100% cpu usage when the exit interrupt never got acked.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c
> b/drivers/gpu/drm/nouveau/core/core/falcon.c
> index e05c157..b11c5f3 100644
> --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
> +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
> @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object, bool
> suspend)
> return nouveau_engine_fini(&falcon->base, suspend);
> }
>
> +void
> +nouveau_falcon_intr(struct nouveau_subdev *subdev)
> +{
> + struct nouveau_falcon *falcon = (void*)subdev;
> + u32 intr = nv_ro32(falcon, 0x008);
> +
> + nv_wo32(falcon, 0x004, intr);
> +
> + if (intr & 0x10) {
> + intr &= ~0x10;
> +
> + nv_info(falcon, "Exit interrupt called\n");
Do you really want to print it at "info" level? How frequent it is?
> + }
> +
> + if (intr)
> + nv_error(falcon, "Unhandled interrupt %08x\n", intr);
> +}
> +
> int
> nouveau_falcon_create_(struct nouveau_object *parent,
> struct nouveau_object *engine,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines
On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
> Op 25-03-13 19:14, Marcin Slusarz schreef:
> > On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> >> Fixes 100% cpu usage when the exit interrupt never got acked.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> b/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> index e05c157..b11c5f3 100644
> >> --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object,
> >> bool suspend)
> >>return nouveau_engine_fini(&falcon->base, suspend);
> >> }
> >>
> >> +void
> >> +nouveau_falcon_intr(struct nouveau_subdev *subdev)
> >> +{
> >> + struct nouveau_falcon *falcon = (void*)subdev;
> >> + u32 intr = nv_ro32(falcon, 0x008);
> >> +
> >> + nv_wo32(falcon, 0x004, intr);
> >> +
> >> + if (intr & 0x10) {
> >> + intr &= ~0x10;
> >> +
> >> + nv_info(falcon, "Exit interrupt called\n");
> > Do you really want to print it at "info" level? How frequent it is?
> It shouldn't be often, I want it to run at the error level since that usually
> means the firmware exited prematurely/crashed and things go bad, but it
> happens with the secret scrubber finishing on initialization too. That one
> is harmless though.
Maybe it should say:
nv_error(falcon, "firmware exited prematurely\n");
?
> >> + }
> >> +
> >> + if (intr)
> >> + nv_error(falcon, "Unhandled interrupt %08x\n", intr);
> >> +}
> >> +
> >> int
> >> nouveau_falcon_create_(struct nouveau_object *parent,
> >> struct nouveau_object *engine,
> > ___
> > 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: 2.6.39-rc1 nouveau regression (bisected)
On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > to everyone, but then chose to CC Maciej instead: Would you be so kind and > add this to your regression list? Thanks! > > Since commit 38f1cff > > From: Dave Airlie > Date: Wed, 16 Mar 2011 11:34:41 +1000 > Subject: [PATCH] Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' > into dr > > This commit changed an internal radeon structure, that meant a new driver > in -next had to be fixed up, merge in the commit and fix up the driver. > > Also fixes a trivial nouveau merge. > > Conflicts: > drivers/gpu/drm/nouveau/nouveau_mem.c > > booting my atom/NM10/ION2 system crashes hard during boot, right after > blanking the screen, and before the initramfs gets loaded. I just > re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > just fine, but the merge commit ( 38f1cff ) fails, same as tip ( 85f2e68 ). Can you activate netconsole and check whether kernel spits anything interesting? You might try to load nouveau module after boot - maybe something will be saved to /var/log or you could even ssh into the box and check dmesg... Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) due to oops @ 0x81255081 CPU 6 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System manufacturer System Product Name/P6T SE RIP: 0010:[] [] iowri
Re: 2.6.39-rc1 nouveau regression (bisected)
[Repost with different Nick Piggin's address.] On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > >>> kind and > > > >>> add this to your regression list? Thanks! > > > >>> > > > >>> Since commit 38f1cff > > > >>> > > > >>> From: Dave Airlie > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > >>> Subject: [PATCH] Merge commit > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > >>> > > > >>> This commit changed an internal radeon structure, that meant a > > > >>> new driver > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > >>> driver. > > > >>> > > > >>> Also fixes a trivial nouveau merge. > > > >>> > > > >>> Conflicts: > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > >>> > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > >>> 85f2e68 ). > > > >> Can you activate netconsole and check whether kernel spits anything > > > >> interesting? > > > >> You might try to load nouveau module after boot - maybe something will > > > >> be saved > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > Compiling it as a module seems to work fine. When I do so, no > > > > regression is > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > get > > > > some output: The last message I see is > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > pointer value> > > > > > > > > Then, nothing more. However, it really is quite strange why this error > > > > only > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > causing me an oops at boot, but my bug has been ignored there so far - > > > perhaps I should have posted it here instead. > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > before it > > can write any logs if it's compiled in and the logo is selected, but boots > > fine > > if compiled as a module or the logo is removed. > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > mm/vmalloc.c) > > to be the first bad one in 2.6.38+. This makes me think that it's not a bug > > in > > nouveau, but maybe a bug in the order that things are initialized? > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ > makes my system boot just fine with the nouveau drivers compiled into the > kernel. I've seen some similar looking bugs on LKML that this regression may > or > may not be related to? It works fine on 2.6.38. > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > http://lkml.org/lkml/2011/4/15/194 > > I'm still trying to figure out exactly where the kernel is crashing after > printing > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > Any thoughts on what else I should look for? I reproduced this bug today, and reverting 89699605fe7cfd8611900346f61cb6cbf179b10a does not fix it for me. Here's the backtrace: Entering kdb (current=0x8801becb, pid
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote: > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > > >>> "calm" > > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > > > >>> kind and > > > > > >>> add this to your regression list? Thanks! > > > > > >>> > > > > > >>> Since commit 38f1cff > > > > > >>> > > > > > >>> From: Dave Airlie > > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > > >>> Subject: [PATCH] Merge commit > > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > > >>> > > > > > >>> This commit changed an internal radeon structure, that meant > > > > > >>> a new driver > > > > > >>> in -next had to be fixed up, merge in the commit and fix up > > > > > >>> the driver. > > > > > >>> > > > > > >>> Also fixes a trivial nouveau merge. > > > > > >>> > > > > > >>> Conflicts: > > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > > >>> > > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right > > > > > >>> after > > > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed > > > > > >>> work > > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > > > >>> 85f2e68 ). > > > > > >> Can you activate netconsole and check whether kernel spits > > > > > >> anything interesting? > > > > > >> You might try to load nouveau module after boot - maybe something > > > > > >> will be saved > > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > > regression is > > > > > > obvious from what gets reported in "dmesg". However, somehow I now > > > > > > do get > > > > > > some output: The last message I see is > > > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > > > > > > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > > error only > > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it > > > > > is > > > > > causing me an oops at boot, but my bug has been ignored there so far - > > > > > perhaps I should have posted it here instead. > > > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > > > before it > > > > can write any logs if it's compiled in and the logo is selected, but > > > > boots fine > > > > if compiled as a module or the logo is removed. > > > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > > mm/vmalloc.c) > > > > to be the first bad one in 2.6.38+. This makes me think that it's not a > > > > bug in > > > > nouveau, but maybe a bug in the order that things are initialized? > > > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > > 2.6.39-rc3+ > >
