From owner-freebsd-current@FreeBSD.ORG Mon Aug 2 20:50:59 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 D97D716A4CE for ; Mon, 2 Aug 2004 20:50:59 +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 3529F43D53 for ; Mon, 2 Aug 2004 20:50:59 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i72KoqhO054303; Mon, 2 Aug 2004 22:50:57 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <410EA92C.6090506@DeepCore.dk> Date: Mon, 02 Aug 2004 22:50:52 +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> In-Reply-To: <410E8594.7070600@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: Mon, 02 Aug 2004 20:51:00 -0000 Ville-Pertti Keinonen wrote: > 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? If the controller doesn't have a bit saying if the interrupt is for us, then its impossible to close the race completely (without the above measures in place). However some devices use the DMA interrupt bits even in PIO mode (ie HPT does this) but I have no docs on the VIA's on that, but its worth a try at least... -- -Søren