Re: Linux 2.6.28-rc8

[Linus Torvalds <torvalds@linux-foundation.org>]

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