[lkml]   [2008]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.


 \ /
  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