Date: Tue, 03 Aug 2004 10:25:04 +0300 From: Ville-Pertti Keinonen <will+freebsd-current@will.iki.fi> To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> Cc: freebsd-current@freebsd.org Subject: Re: ATA driver races with interrupts Message-ID: <410F3DD0.5030104@will.iki.fi> In-Reply-To: <410EA92C.6090506@DeepCore.dk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt wrote: > 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... The current situation seems to me like ata_generic_intr can't work for *any* controller sharing interrupts, even with DMA on a controller that sets ATA_BMSTAT_INTERRUPT correctly, since if an interrupt occurs before ATA_DMA_ACTIVE is set, ATA_BMSTAT_PORT is never even checked. IMHO ch->running != NULL is an insufficient condition based on which to assume that an interrupt is intended for a specific channel... Something similar to my patch + disabling interrupts to avoid a race between the interrupt and ATA_EXPECT_INTR being set should at least improve the situation. What races would that leave open?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410F3DD0.5030104>