Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Aug 2004 20:02:32 +0200
From:      =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk>
To:        Ville-Pertti Keinonen <will+freebsd-current@will.iki.fi>
Cc:        freebsd-current@freebsd.org
Subject:   Re: ATA driver races with interrupts
Message-ID:  <410E81B8.1000206@DeepCore.dk>
In-Reply-To: <410E7B8B.3080407@will.iki.fi>
References:  <410E688D.7020709@will.iki.fi> <410E74F7.1070000@will.iki.fi> <20040802132802.3d7kgoow0c80ss0s@www.sweetdreamsracing.biz> <410E7B8B.3080407@will.iki.fi>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Ville-Pertti Keinonen wrote:
> Kenneth Culver wrote:
> 
>> I have this exact same motherboard, but I'm using the onboard promise 
>> controller
>> set up with 2 disks as a raid0, and I'm not having any problems with this
>> setup. I used the promise controller because from what I've been told, 
>> the
>> promise controllers are very fast in FreeBSD compared to other 
>> controllers.
> 
> 
> If the two disks appear as one to FreeBSD, the problem probably isn't 
> going to show up.
> 
> It may also depend on the controller, since the channel registers might 
> not satisfy the conditions in ata_generic_interrupt (I didn't bother 
> digging up my ATA specs while debugging this), but even if it is a 
> controller oddity, I don't think the ATA driver should be sensitive such 
> conditions.

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...

-- 
-Søren



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?410E81B8.1000206>