On Mon, 17 Dec 2007 19:25:27 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> Looks like a commit that I can't find in git due to the arch merge
> has broken PCI address assignment. This patch by Richard Henderson
> against 2.6.23 fixes it for x86_64:
>
> --- linux-2.6.23.x86_64/arch/x86_64/kernel
On Sat, 22 Dec 2007 01:12:18 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Dec 2007 11:46:16 +0300 Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
>
> > PCI: do respect full 64-bit address for bridge prefetch window
> >
> > Prevent the prefetch window from being programmed with a bogus
On Thu, 20 Dec 2007 11:46:16 +0300 Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> PCI: do respect full 64-bit address for bridge prefetch window
>
> Prevent the prefetch window from being programmed with a bogus address
> when its respective resource gets allocated above the 4G mark.
>
> Note that
> So in your case, it should *result* in the exact same situation that your
> patch did, but at the same time, when dealing with the (more common) case
> of smaller allocations, we still continue to try to avoid being too close
> to the top-of-memory.
>
> So it's not perfect, but perhaps it is
On Thu, 20 Dec 2007, Richard Henderson wrote:
>
> 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.
No,
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
On Thu, 20 Dec 2007, Richard Henderson wrote:
> On Tue, Dec 18, 2007 at 05:38:58PM -0800, Linus Torvalds wrote:
> > That
> >
> > PCI: Cannot allocate resource region 9 of bridge :00:01.0
> > PCI: Cannot allocate resource region 1 of device :01:00.0
> >
> > thing is really start
On Tue, Dec 18, 2007 at 05:38:58PM -0800, Linus Torvalds wrote:
> That
>
> PCI: Cannot allocate resource region 9 of bridge :00:01.0
> PCI: Cannot allocate resource region 1 of device :01:00.0
>
> thing is really starting to bug me.
>
> I bet that is the real problem here, bu
Another turd is pci_scan_device() which can't cope with 64 bits BARs on
32 bits platforms even when they have 64 bits resources. I'll send a fix
for that.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> That won't work, because PCI_BASE_ADDRESS_MEM_TYPE_64 controls how
> many bits need to be written back to the BAR. If we changed that
> to PCI_BASE_ADDRESS_MEM_TYPE_32, we wouldn't clear the high 32-bits
> of the BAR.
>
> > ... and that would be an X server issue!).
>
> Of course, fixing the
On Tue, Dec 18, 2007 at 01:46:56PM -0800, Linus Torvalds wrote:
> Heh, indeed. Good catch - that
>
> Prefetchable memory behind bridge: -0fff
>
> on device 00:01.0 does look totally broken, and it would make more sense
> if it matched what the device has (and wh
On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> Heh.
>
> PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
> PCI: Not using MMCONFIG.
Well, that at least confirms that e000 is indeed the mmconfig area.
One of these days we'll trust the ACPI resource data enough that we can
use m
On Tue, 2007-12-18 at 13:09 -0800, Linus Torvalds wrote:
> It's not like 256MB is even as large as they come, half-gig graphics cards
> are getting to be fairly common at the high end, and X absolutely _has_ to
> be able to handle a 64-bit address for those.
We're now using a system-dependent
On Tue, 18 Dec 2007, Linus Torvalds wrote:
>
> That question also brings up another issue: how come did we actually
> choose address 0xc000 with the original patch you sent in? If we can't
> find it in the parent resources, we shouldn't have accepted it even if it
> had room for it!
That
On Tue, Dec 18, 2007 at 07:55:37PM -0500, Chuck Ebbert wrote:
> You can boot with "pci=mmconf" to enable it.
Heh.
PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
PCI: Not using MMCONFIG.
r~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On 12/18/2007 07:11 PM, Robert Hancock wrote:
>> However, I wonder about that
>>
>> e000-efff : pnp 00:0b
>>
>> thing. I actually suspect that that whole allocation is literally
>> *meant* for that 256MB graphics aperture, but the kernel explicitly
>> avoids it because it's listed in th
Linus Torvalds wrote:
On Mon, 17 Dec 2007, Chuck Ebbert wrote:
Looks like a commit that I can't find in git due to the arch merge
has broken PCI address assignment. This patch by Richard Henderson
against 2.6.23 fixes it for x86_64:
--- linux-2.6.23.x86_64/arch/x86_64/kernel/e820.c 2007-
On Tuesday 18 December 2007 02:09:15 pm Linus Torvalds wrote:
>
> On Tue, 18 Dec 2007, Richard Henderson wrote:
> >
> > I've added dmesg, /proc/iomem, and lspci -v output to that bug.
> >
> > Basically, we have
> >
> > c000-cfff : free
> > ddf0-dfef : PCI Bus #04
> >
Linus Torvalds wrote:
On Tue, 18 Dec 2007, Chuck Ebbert wrote:
On 12/18/2007 04:09 PM, Linus Torvalds wrote:
I wonder what the heck is the point of that pnp entry. Just for fun, can
you try to just disable CONFIG_PNP, and see if it all works then?
pnpacpi=off should work.
PnP is also trying
Linus Torvalds wrote:
On Tue, 18 Dec 2007, Richard Henderson wrote:
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
Basically, we have
c000-cfff : free
ddf0-dfef : PCI Bus #04
e000-efff : pnp 00:0b
f000-fedf : les
On Tue, Dec 18, 2007 at 04:46:09PM -0500, Chuck Ebbert wrote:
> pnpacpi=off should work.
This does result in the graphics bar being placed at e000,
and does result in a system lockup when X starts. So it appears
as if there's really something there.
r~
--
To unsubscribe from this list: send
On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> Another way to look at this is that the graphics BAR came in from
> the BIOS allocated at c000, and we ignored that.
We did?
> Perhaps there's a way to give weight to the BIOS settings when
> consdering where the PCI region is supposed to
On Tue, 18 Dec 2007, Chuck Ebbert wrote:
> On 12/18/2007 04:09 PM, Linus Torvalds wrote:
> >
> > I wonder what the heck is the point of that pnp entry. Just for fun, can
> > you try to just disable CONFIG_PNP, and see if it all works then?
>
> pnpacpi=off should work.
>
> PnP is also trying
On Tue, Dec 18, 2007 at 01:09:15PM -0800, Linus Torvalds wrote:
> However, I wonder about that
>
> e000-efff : pnp 00:0b
>
> thing. I actually suspect that that whole allocation is literally *meant*
> for that 256MB graphics aperture, but the kernel explicitly avoids it
> because
On Wed, 19 Dec 2007, Ivan Kokshaysky wrote:
>
> Doh. Let's fix the kernel first...
>
> Does this make any difference? (the patch is self explaining ;-)
Heh, indeed. Good catch - that
Prefetchable memory behind bridge: -0fff
on device 00:01.0 does look tota
On 12/18/2007 04:09 PM, Linus Torvalds wrote:
>
> I wonder what the heck is the point of that pnp entry. Just for fun, can
> you try to just disable CONFIG_PNP, and see if it all works then?
>
pnpacpi=off should work.
PnP is also trying (and failing) to reserve all physical memory.
--
To unsub
On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote:
> On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > ... and that would be an X server issue!).
>
> Of course, fixing the X server to *handle* 64-bit BARs is the correct
> solution. I've no idea how involved that
On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=425794#c0
>
> That bugzilla entry doesn't even have a dmesg output or anything like
> that. I'd really like to see what the
I've added dmesg, /proc/iomem, and lspci -v output to that
On Tue, 18 Dec 2007, Richard Henderson wrote:
>
> I've added dmesg, /proc/iomem, and lspci -v output to that bug.
>
> Basically, we have
>
> c000-cfff : free
> ddf0-dfef : PCI Bus #04
> e000-efff : pnp 00:0b
> f000-fedf : less than 256MB
On Tue, 18 Dec 2007, Chuck Ebbert wrote:
> >
> > So why do you want them to be close, anyway?
>
> Because otherwise some video adapters with 256MB of memory end up with their
> resources allocated above 4GB, and that doesn't work very well.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=4257
On 12/17/2007 07:57 PM, Linus Torvalds wrote:
>
> On Mon, 17 Dec 2007, Chuck Ebbert wrote:
>> Looks like a commit that I can't find in git due to the arch merge
>> has broken PCI address assignment. This patch by Richard Henderson
>> against 2.6.23 fixes it for x86_64:
>>
>> --- linux-2.6.23.x86_6
On Mon, 17 Dec 2007, Chuck Ebbert wrote:
>
> Looks like a commit that I can't find in git due to the arch merge
> has broken PCI address assignment. This patch by Richard Henderson
> against 2.6.23 fixes it for x86_64:
>
> --- linux-2.6.23.x86_64/arch/x86_64/kernel/e820.c 2007-10-09
> 13:31
32 matches
Mail list logo
