From owner-freebsd-current@FreeBSD.ORG Tue Aug 3 09:39:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CA5A16A4CE for ; Tue, 3 Aug 2004 09:39:00 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF18043D5E for ; Tue, 3 Aug 2004 09:38:59 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk ([192.168.0.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i739cr6Q061394; Tue, 3 Aug 2004 11:38:58 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <410F5D2D.4080305@DeepCore.dk> Date: Tue, 03 Aug 2004 11:38:53 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ville-Pertti Keinonen References: <410E688D.7020709@will.iki.fi> <410E74F7.1070000@will.iki.fi> <20040802132802.3d7kgoow0c80ss0s@www.sweetdreamsracing.biz> <410E7B8B.3080407@will.iki.fi> <410E81B8.1000206@DeepCore.dk> <410E8594.7070600@will.iki.fi> <410EA92C.6090506@DeepCore.dk> <410F3DD0.5030104@will.iki.fi> <410F4F66.8040201@DeepCore.dk> <410F5A99.8070005@will.iki.fi> In-Reply-To: <410F5A99.8070005@will.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-current@freebsd.org Subject: Re: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2004 09:39:00 -0000 Ville-Pertti Keinonen wrote: > Søren Schmidt wrote: > >> We dont want to disable interrupts, ever. > > That makes avoiding races difficult for some hardware... Only on HW broken by design :) >> I have one change in a tree here that you could try, but as long as >> the hardware doesn't support proper interrupt status its impossible to >> close the race window completely. Please remember that this is part of >> a bigger patchset, so I might have edited it too much, YMMV,, > > It introduces the same race as my patch - if the interrupt occurs after > ATA_DMA_ACTIVE is set but before running is set, the interrupt may be > acknowledged (I assume that's what writing BMSTAT_PORT does) but ignored > (because running == NULL). Right, I have a change for that as well, but its a bit more work to sort out, but basically it makes DMA_ACTIVE into two flags, one for having loaded the DMA table though busdma, and one for having started the DMA engine. I'll try to sort that one out, but its entangled deeply in other changes so it needs a bit more work... > It seems to me that reliable solutions would all involve atomically > (from an interrupt perspective) performing the final activation of the > transaction and marking the transaction active for the interrupt handler > to check. What the correct way to ensure such atomicity in -current is, > I don't know. Reliable solutions needs reliable HW, we can narrow down the race window here, but without HW support we cannot close it completely unless we serialises access to the channels (what lots of OS's does btw).. -- -Søren