linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
Date: Mon, 03 Aug 2009 14:14:04 +0100	[thread overview]
Message-ID: <1249305244.15714.3.camel@macbook.infradead.org> (raw)
In-Reply-To: <1249199437.12047.11.camel@pasglop>

On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> > I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> > doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> > _anyway_, surely?
> >
> > So we might as well let the DART keep its existing logic (which is
> > only
> > to bother if we have more than 1GiB of RAM; 
> 
> Ah right, so when do we enable the DART ? Above 1G ? I though it was
> above 2G but we may well have moved that down to 1G just for b43 indeed.

void __init alloc_dart_table(void)
{
        /* Only reserve DART space if machine has more than 1GB of RAM
         * or if requested with iommu=on on cmdline.
         *
         * 1GB of RAM is picked as limit because some default devices
         * (i.e. Airport Extreme) have 30 bit address range limits.
         */

        if (iommu_is_off)
                return;

        if (!iommu_force_on && lmb_end_of_DRAM() <= 0x40000000ull)
                return;


> I definitely agree on the fix to the mask so it only compares to the
> available RAM. I'll check that in when I'm back from the snow fields 
> on tuesday :-)

I see one potential failure mode with this. You need:
 - No IOMMU
 - Crappy devices
 - Hotpluggable memory
 - Boot with only "low" memory, and allow a pci_set_dma_mask() to
   succeed because you don't have that much memory anyway.
 - Hotplug some "high" memory that the crappy device can't reach.

Do we care about that scenario? I think we might be able to "fix" it by
setting the memory_limit when we allow pci_set_dma_mask() to succeed?
That will effectively prevent the addition of memory that our crappy
device can't reach, won't it?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

  reply	other threads:[~2009-08-03 13:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31 19:41 [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway David Woodhouse
2009-07-31 22:25 ` Benjamin Herrenschmidt
2009-08-01  7:54   ` David Woodhouse
2009-08-01  8:00     ` Benjamin Herrenschmidt
2009-08-01  9:00       ` David Woodhouse
2009-08-02  7:50         ` Benjamin Herrenschmidt
2009-08-03 13:14           ` David Woodhouse [this message]
2009-08-03 21:05             ` Benjamin Herrenschmidt
2009-08-10  6:46 ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1249305244.15714.3.camel@macbook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).