[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo67h_mdZtoEn-W_OOXZ8m7gs3g6Q25kte285ZX=2FKf+A@mail.gmail.com>
Date: Sun, 3 Jun 2012 18:05:46 -0700
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Yinghai Lu <yinghai@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
David Miller <davem@...emloft.net>,
Tony Luck <tony.luck@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Steven Newbury <steve@...wbury.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first
On Fri, Jun 1, 2012 at 4:30 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Tue, May 29, 2012 at 1:50 PM, H. Peter Anvin <hpa@...or.com> 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.
Steve's problem doesn't count because that's a "pci=nocrs" case that
will always require special handling. 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists