Date: Sat, 7 Feb 2009 19:37:14 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.ORG> To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Cc: bofh@terranova.net, freebsd-current@FreeBSD.ORG Subject: Re: HT 1000 SATA suggestion Message-ID: <E96EB43E-04C7-4082-829F-A71F5F04BF57@FreeBSD.ORG> In-Reply-To: <Pine.LNX.4.64.0902071102110.8765@artax.karlin.mff.cuni.cz> References: <Pine.LNX.4.64.0902071102110.8765@artax.karlin.mff.cuni.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7Feb, 2009, at 11:27 , Mikulas Patocka wrote: > Hi > > I found that you have problems with HT1000 SATA in FreeBSD. > > The problem is actually explained in the comments in the Linux driver. > > For normal IDE & legacy SATA cards, the sequence to perform DMA is =20 > this: > > - load register file > - submit the command to the disk > - setup dma sg table address and start dma > > But for ServerWorks SATA chips this sequence is wrong. If there is =20 > some > CPU latency and data from the disk arrive BEFORE you start the dma =20 > engine, > the controller will hang or corrupt the data. > > The correct sequence is to first start dma and then write the =20 > command to > the taskfile. (Linux does this on serverworks SATA chips for both =20 > read and > write commands, likely it doesn't cause problems with write commands) Just for the record this (amongst lots of other things) was tried long =20= ago and does *not* solve the problem we were having. I'm not sure what to make out of their reasoning though, as the result =20= from the problem they describe would be that the amount of data =20 transfered would be wrong, in that case the transaction will either =20 fail or hang the controller, which in both cases should trigger error =20= handling. -S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E96EB43E-04C7-4082-829F-A71F5F04BF57>