Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761357Ab2FEChK (ORCPT ); Mon, 4 Jun 2012 22:37:10 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:43710 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757699Ab2FEChH convert rfc822-to-8bit (ORCPT ); Mon, 4 Jun 2012 22:37:07 -0400 MIME-Version: 1.0 In-Reply-To: References: <1337754877-19759-1-git-send-email-yinghai@kernel.org> <20120525043651.GA1391@google.com> <20120525193716.GA8817@google.com> <4FC50E09.4000204@zytor.com> <4FC51D79.6010804@zytor.com> <4FC536A5.6020600@zytor.com> Date: Mon, 4 Jun 2012 19:37:06 -0700 X-Google-Sender-Auth: 1H0KzPvIVEufduu0yncw6kjb6jQ Message-ID: Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first From: Yinghai Lu To: Bjorn Helgaas Cc: "H. Peter Anvin" , David Miller , Tony Luck , Linus Torvalds , Steven Newbury , Andrew Morton , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2323 Lines: 60 On Sun, Jun 3, 2012 at 6:05 PM, Bjorn Helgaas wrote: > On Fri, Jun 1, 2012 at 4:30 PM, Yinghai Lu wrote: >> On Tue, May 29, 2012 at 1:50 PM, H. Peter Anvin wrote: >>> >>> The bus-side address space should not be more than 32 bits no matter >>> what. ?As Bjorn indicates, you seem to be mixing up bus and cpu >>> addresses all over the place. >> >> please check update patches that is using converted pci bus address >> for boundary checking. > > What problem does this fix? ?There's significant risk that this > allocation change ?will make us trip over something, so it must fix > something to make it worth considering. If we do not enable that, we would not find the problem. On one my test setup that _CRS does state 64bit resource range, but when I clear some device resource manually and let kernel allocate high, just then find out those devices does not work with drivers. It turns out _CRS have more big range than what the chipset setting states. with fixing in BIOS, allocate high is working now on that platform. > > Steve's problem doesn't count because that's a "pci=nocrs" case that > will always require special handling. but pci=nocrs is still supported, even some systems does not work with pci=use_crs >?A general solution is not > possible without a BIOS change (to describe >4GB apertures) or a > native host bridge driver (to discover >4GB apertures from the > hardware). ?These patches only make Steve's machine work by accident > -- they make us put the video device above 4GB, and we're just lucky > that the host bridge claims that region. Some bios looks enabling the non-stated range default to legacy chain. Some bios does not do that. only stated range count. So with pci=nocrs we still have some chance to get allocate high working. > > One possibility is some sort of boot-time option to force a PCI device > to a specified address. ?That would be useful for debugging as well as > for Steve's machine. yeah, how about pci=alloc_high and default to disabled ? Thanks Yinghai -- 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/