From owner-freebsd-arm@FreeBSD.ORG Sat Sep 3 20:00:23 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DFB106566B for ; Sat, 3 Sep 2011 20:00:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BABD68FC13 for ; Sat, 3 Sep 2011 20:00:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p83K0N4u021253 for ; Sat, 3 Sep 2011 20:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p83K0N75021242; Sat, 3 Sep 2011 20:00:23 GMT (envelope-from gnats) Date: Sat, 3 Sep 2011 20:00:23 GMT Message-Id: <201109032000.p83K0N75021242@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Ian Lepore Cc: Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache sync operations. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 20:00:24 -0000 The following reply was made to PR arm/160431; it has been noted by GNATS. From: Ian Lepore To: Mark Tinguely Cc: FreeBSD-gnats-submit@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