All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	torvalds@osdl.org, linux-kernel@vger.kernel.org,
	discuss@x86-64.org
Subject: Re: [1/3] Add 4GB DMA32 zone
Date: Mon, 12 Sep 2005 13:51:59 +0200	[thread overview]
Message-ID: <200509121352.00530.ak@suse.de> (raw)
In-Reply-To: <547AF3BD0F3F0B4CBDC379BAC7E4189F01919BC3@otce2k03.adaptec.com>

Thanks Mark for the corrections.

On Monday 12 September 2005 13:44, Salyzyn, Mark wrote:
> Andi Kleen writes:
> >> Adaptec AACRAID is one offender
> >
> > 4GB limit is really common and the oddballs like
> >these have to use the same workarounds (custom bounce buffer in low
>
> GFP_DMA
>
> >memory) they always did on machines with enough memory.
>
> The 2GB limit is to deal with allocation of hardware command frames
> (FIB) and thus only during initialization,
> all the adapters deliver DMA 
> to the full address range at 'run time' and the driver does open the
> limit up at that point. The reason for this strangeness is the inability
> of the Firmware to work around the Intel ATU when doing memcpy, where
> the DMA engine had no such limits.

Ok that makes a lot of sense.  You should probably be really using 
pci_alloc_consistent() instead of GFP_DMA directly here, but other than
that it should just work.

(pci_alloc_consistent has some hacks to first try the higher zones
and only use the lower zones if the allocation didn't succeed here -
on a 2GB machine you have a 50% chance that a normal allocation 
ends up below 1GB -  which make this all a bit more reliable) 

That probably explains the lack of reports about this issue
which I mistakenly assumed was because of the cards getting scarce.

Anyways, it shows the aacraid doesn't need GFP_DMA32 at all, which
is good.

I hope there are no other concerns about the patch and Linus 
could just merge it now? 

-Andi


  reply	other threads:[~2005-09-12 11:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 11:44 [1/3] Add 4GB DMA32 zone Salyzyn, Mark
2005-09-12 11:51 ` Andi Kleen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-09-12 12:08 Salyzyn, Mark
2005-09-11 16:59 Andi Kleen
2005-09-12 10:28 ` Alan Cox
2005-09-12 10:42   ` Andi Kleen
2005-09-12 11:33     ` Alan Cox
2005-09-12 11:22       ` Andi Kleen
2005-09-12 12:34         ` Alan Cox
2005-09-12 18:18       ` Jeff Garzik
2005-09-12 22:02         ` Bart Hartgers
2005-09-13  3:20           ` Andi Kleen
2005-09-12 19:55     ` Mark Lord
2005-09-12 12:45 ` Roman Zippel
2005-09-12 12:46   ` Andi Kleen
2005-09-12 12:50     ` Roman Zippel
2005-09-12 12:54       ` Andi Kleen
2005-09-12 13:01         ` Roman Zippel
2005-09-13  9:15     ` Roman Zippel
2005-10-03 15:46 ` Coywolf Qi Hunt

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=200509121352.00530.ak@suse.de \
    --to=ak@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=discuss@x86-64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark_salyzyn@adaptec.com \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.