[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110708173251.GA9561@flint.arm.linux.org.uk>
Date: Fri, 8 Jul 2011 18:32:52 +0100
From: Russell King <rmk@....linux.org.uk>
To: Qin Dehua <qindehua@...il.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
linux-kernel@...r.kernel.org, santosh.shilimkar@...com,
neilb@...e.de
Subject: Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause
OOPS
On Fri, Jul 08, 2011 at 09:07:51AM +0100, Russell King wrote:
> On Fri, Jul 08, 2011 at 12:38:38PM +0800, Qin Dehua wrote:
> > After doing the above changes, the kernel just report BUG_ON(dir ==
> > DMA_BIDIRECTIONAL):
>
> That's really unfortunate.
>
> The only other thing I can think which may help is to enable all the
> raid5, async_tx and dmaengine debug code. And I hope you have
> DMA_API_DEBUG enabled in your .config ?
I'm really grasping at straws here...
I'll add to this that I'm out of ideas at the moment (I don't know the
RAID5 nor the async offload code), and the only way I can think of
resolving this is to revert the commit.
While that sounds like a good thing to do, it means people using ARMv6
and later CPUs will be risking data corruption, which I don't think is
that desirable either - and will in itself cause a regression there.
So we really need to the bottom of what's going on (which I suspect
may be due to DMA API abuse by the async offload stuff - mapping the
same buffer multiple times with differing attributes.) Why that would
impact sh->count I've no idea.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
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