Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757098AbYLKQW5 (ORCPT ); Thu, 11 Dec 2008 11:22:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756582AbYLKQWt (ORCPT ); Thu, 11 Dec 2008 11:22:49 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:48536 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756579AbYLKQWt (ORCPT ); Thu, 11 Dec 2008 11:22:49 -0500 Date: Thu, 11 Dec 2008 08:22:21 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Frans Pop cc: Eric Anholt , nix.or.die@googlemail.com, linux-kernel@vger.kernel.org, rjw@sisk.pl Subject: Re: Linux 2.6.28-rc8 In-Reply-To: <200812111707.20857.elendil@planet.nl> Message-ID: References: <49407CE1.9090600@googlemail.com> <49407CE1.9090600@googlemail.com> <1228979963.3254.8.camel@gaiman.anholt.net> <200812111707.20857.elendil@planet.nl> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1738 Lines: 45 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/