lkml.org 
[lkml]   [2008]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.28-rc8


On Thu, 11 Dec 2008, Frans Pop wrote:

> Eric Anholt wrote:
> > My recommended solution, of course, is to remove vesafb.
>
> How is taking away useful functionality from users a better option than
> just fixing the bug?

Well, just to clarify: it's not a _bug_. It's a benign warnign that two
subsystems are trying to map the same memory differently.

In this case, we have:

resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb

and what it means is that the caller (which is i915_gem_entervt_ioctl) is
trying to apparently ioremap the _whole_ graphics card MMIO resource
(0xd0000000-0xdfffffff), but the vesafb driver has already registered the
fact that it uses _part_ of that resource (0xd0000000-0xd07effff).

There's no bug there. It's a warning. It's usually a very odd situation
when somebody tries to ioremap something that crosses resource reservation
boundaries, but the thing is, in this case it's not really a problem.

It's triggered by a couple of oddities:

- fbcon (vesafb) is odd and only requests a partial resource, because it
only uses part of the MMIO window.

- the interaction between fbcon and X is odd to begin with, since they
both use the same physical resource.

so it's a generic warning that triggers because these things _shouldn't_
happen, but it's not actually an error in this case. We could just remove
the warning. Or leave it in, in case it finds other (real) issues, and
just ignore it.

Linus


\
 
 \ /
  Last update: 2008-12-11 17:25    [W:0.080 / U:0.396 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site