Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765564AbXLUAlv (ORCPT ); Thu, 20 Dec 2007 19:41:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756603AbXLUAlm (ORCPT ); Thu, 20 Dec 2007 19:41:42 -0500 Received: from are.twiddle.net ([64.81.246.98]:40834 "EHLO are.twiddle.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753733AbXLUAll (ORCPT ); Thu, 20 Dec 2007 19:41:41 -0500 Date: Thu, 20 Dec 2007 16:39:13 -0800 From: Richard Henderson To: Linus Torvalds Cc: Chuck Ebbert , linux-kernel , Ivan Kokshaysky , Daniel Ritz , Greg KH , Keith Packard , Bjorn Helgaas Subject: Re: PCI resource problems caused by improper address rounding Message-ID: <20071221003913.GA6220@twiddle.net> Mail-Followup-To: Linus Torvalds , Chuck Ebbert , linux-kernel , Ivan Kokshaysky , Daniel Ritz , Greg KH , Keith Packard , Bjorn Helgaas References: <47680489.6040809@redhat.com> <20071218202234.GA24525@twiddle.net> <20071218215143.GA24769@twiddle.net> <20071220215204.GA5636@twiddle.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1322 Lines: 28 On Thu, Dec 20, 2007 at 02:24:48PM -0800, Linus Torvalds wrote: > I'm not exactly 100% happy with it, but it does mean that if we need a big > area, we'll relax the suggested starting point by that amount. It's not > wonderful, but it essentially admits that the minimum for the allocations > is really just a hint, and if we need lots of space for a resource, we'll > relax the minimum point appropriately. This breaks in odd cases where the amount of memory in the system is not a nice round number. Like throwing two 128MB sticks into a system that already has 2gb. A 512MB allocation will get placed back at 2gb, on top of the end of ram. In order to get this kind of thing to work, you'd have to have a hard and a soft minimum. Even then, any random large allocation is going to ignore that buffer that you added. It'd be better if we could still tie this ignoring of the buffer to whether the bios placed the resource there in the first place. Perhaps this is one of those things that just aren't going to be solved properly without an xserver upgrade... r~ -- 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/