Messages in this thread Patch in this message | | | Date | Fri, 08 Jul 2011 13:13:27 -0700 | From | Dan Williams <> | Subject | Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause OOPS |
| |
On 7/8/2011 10:32 AM, Russell King wrote: > 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.
Not much of a choice but crashing is better than data corruption. Disabling CONFIG_ASYNC_TX_DMA until the mapping violations can be resolved is probably the better course of action. Something like.
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 1c28816..cb254a1 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -247,6 +247,7 @@ config NET_DMA config ASYNC_TX_DMA bool "Async_tx: Offload support for the async_tx api" depends on DMA_ENGINE + depends on !ARM help This allows the async_tx api to take advantage of offload engines for memcpy, memset, xor, and raid6 p+q operations. If your platform has
> > 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. >
This is concerning, I'll see about dusting off my iop34x and reproducing. Might not be for a week or so...
-- Dan
| |