From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Roland Dreier <rdreier@cisco.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: SCSI breakage on non-cache coherent architectures
Date: Tue, 20 Nov 2007 08:55:20 +1100 [thread overview]
Message-ID: <1195509320.6970.9.camel@pasglop> (raw)
In-Reply-To: <adapry5ykps.fsf@cisco.com>
On Mon, 2007-11-19 at 13:43 -0800, Roland Dreier wrote:
> > I've been debugging various issues on the PowerPC 44x embedded
> > architecture which happens to have non-coherent PCI DMA.
> >
> > One of the problem I'm hitting is that one really need to enforce
> > kmalloc alignement to cache lines or bad things will happen (among
> > others with USB), for some reasons, powerpc failed to do so, I fixed it.
>
> Heh... I hit the same problem literally 5 years ago:
> http://lwn.net/Articles/1783/
>
> I implemented the __dma_buffer annotation:
> http://lwn.net/Articles/2269/
>
> But DaveM said we should just use the PCI pool code instead:
> http://lwn.net/Articles/2270/
Heh, well...
In this case, DaveM just proposed something akin to your
__dma_buffer :-)
On the other hand, after discussing with James, it looks like we'll just
be reverting the patch that removed the kmalloc of the sense buffer
since non cache-coherent archs are supposed to enforce kmalloc alignment
to cache lines.
__dma_buffer still seems like a good thing to have if too many other
drivers are hitting that but for this specific problem, it's not the
approach that we'll be taking.
Cheers,
Ben.
prev parent reply other threads:[~2007-11-19 21:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 5:35 SCSI breakage on non-cache coherent architectures Benjamin Herrenschmidt
2007-11-19 8:38 ` David Miller
2007-11-19 19:51 ` Benjamin Herrenschmidt
2007-11-19 22:31 ` David Miller
2007-11-20 0:34 ` Benjamin Herrenschmidt
2007-11-20 0:46 ` David Miller
2007-11-20 0:55 ` Benjamin Herrenschmidt
2007-11-20 0:57 ` David Miller
2007-11-20 2:10 ` Roland Dreier
2007-11-20 2:35 ` Benjamin Herrenschmidt
2007-11-20 3:14 ` Benjamin Herrenschmidt
2007-11-20 19:35 ` James Bottomley
2007-11-20 8:29 ` Thomas Bogendoerfer
2007-11-20 14:36 ` James Bottomley
2007-11-20 20:05 ` Roland Dreier
2007-11-20 21:10 ` James Bottomley
2007-11-20 22:39 ` Benjamin Herrenschmidt
2007-11-20 23:09 ` James Bottomley
2007-11-19 12:32 ` Matthew Wilcox
2007-11-19 15:09 ` James Bottomley
2007-11-19 19:54 ` Benjamin Herrenschmidt
2007-11-19 19:55 ` Benjamin Herrenschmidt
2007-11-19 19:53 ` Benjamin Herrenschmidt
2007-11-19 21:43 ` Roland Dreier
2007-11-19 21:55 ` Benjamin Herrenschmidt [this message]
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=1195509320.6970.9.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=rmk@arm.linux.org.uk \
/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