Re: Linux 2.6.28-rc8

Ingo Molnar
2008-12-11T16:36:30Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
>
> 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.

hm, the warning caught a couple of real bugs already. (one in some cpq
driver, another was in some networking driver iirc)

Ingo