From owner-freebsd-current@FreeBSD.ORG Mon Aug 2 18:19:28 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 6D22516A4CE for ; Mon, 2 Aug 2004 18:19:28 +0000 (GMT) Received: from will.iki.fi (will.iki.fi [217.169.64.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A97E43D69 for ; Mon, 2 Aug 2004 18:19:28 +0000 (GMT) (envelope-from will+freebsd-current@will.iki.fi) Received: from [10.129.39.131] (b212-54-23-216.elisa-laajakaista.fi [212.54.23.216]) by will.iki.fi (Postfix) with ESMTP id 05BBB61; Mon, 2 Aug 2004 21:19:04 +0300 (EEST) Message-ID: <410E8594.7070600@will.iki.fi> Date: Mon, 02 Aug 2004 21:19:00 +0300 From: Ville-Pertti Keinonen User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040708) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= 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> In-Reply-To: <410E81B8.1000206@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 02 Aug 2004 18:19:28 -0000 Søren Schmidt wrote: > There is no good solution to this *unless* the HW has bits to > determine which channel caused the interrupt. Now all decent > controller has this, but I have no idea about the VIA since they are > not one of those companies that hands out docs. > > The only way to safeguard is to "serialize" access to the channels as > I've done on a few oh so broken chipsets... Ok, I see where it should be detected now - in ata_generic_intr, before ata_generic_interrupt... There is an actual test for the interrupt on the channel, so there should be no race if the controller works correctly. Apparently the VIA doesn't... The detection only applies to DMA - is PIO sensitive to unexpected interrupts, even on working controllers? If so, shouldn't there be some protection against this?