arm/160431: [patch] Disable interrupts during busdma cache
sync operations.
Ian Lepore
freebsd at damnhippie.dyndns.org
Sat Sep 3 20:00:24 UTC 2011
The following reply was made to PR arm/160431; it has been noted by GNATS.
From: Ian Lepore <freebsd at damnhippie.dyndns.org>
To: Mark Tinguely <marktinguely at gmail.com>
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache
sync operations.
Date: Sat, 03 Sep 2011 13:43:38 -0600
On Sat, 2011-09-03 at 14:05 -0500, Mark Tinguely wrote:
> On 9/3/2011 12:19 PM, Ian Lepore wrote:
> > [bug report]
>
> Which processor are you using (for my curiosity)?
>
> If this is easily reproducible, would you please put the interrupt
> disable/restore just around the BUS_DMASYNC_POSTREAD option? (for my
> curiosity again).
>
> Thank-you
>
> --Mark.
It's an Atmel at91rm9200. It's been weeks since we were actively
working this problem (I'm just way behind on submitting fixes back to
the community), so it would be pretty hard at this point to get back to
where the problem is easily reproducible. But when we were still
investigating it, I remember instrumenting the code to conclusively
prove it was the handling of partially-overlapping cache lines within
the POSTREAD block that was leading to the ih_need flag of the nearby
intr_handler struct getting reset to zero.
We actually discovered all this on code that was mostly 6.2 with some
6.4 stuff merged in. We're now almost up and running on 8.2 on our
embedded arm products, so the whole 6.2 thing is feeling like a bad
nightmare that won't quite fade from memory. :)
My putting the intr_disable() at the next-outer layer of code is just an
abundance of caution. But given that the pmap code and the busdma code
can both lead to writeback and/or invalidate activity, and that those
two pieces of code don't know what each other are doing, I've had a
growing quesy feeling about this stuff for a while. For example, the
pmap code can decide to do a writeback that could overwrite
DMA-in-progress data, especially in the cases of partial overlap of a
DMA operation with a cache line. But I didn't want to start raising any
alarms until I've learned more about the code in its current form, and
I'm still working on learning that.
-- Ian
More information about the freebsd-arm
mailing list