lkml.org 
[lkml]   [2008]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sata_svw data corruption, strange problems
Hello,

Pavel Machek wrote:
> I see strange problems on machine with sata_svw. The machine seems to
> corrupt data every few days (ext3 error, dir index corrupted), and has
> some other very strange problems (keyboard misbehaves, pulling out
> SATA disk cures it, see
> https://bugzilla.novell.com/show_bug.cgi?id=400772 ).
>
> Then I got to the comment
>
> writeb(dmactl | ATA_DMA_START, mmio + ATA_DMA_CMD);
> /* There is a race condition in certain SATA controllers
> that can be seen when the r/w command is given to the controller
> before the host DMA is started. On a Read command, the controller
> would initiate the command to the drive even before it sees the DMA
> start. When there are very fast drives connected to the controller,
> or when the data request hits in the drive cache, there is the
> possibility that the drive returns a part or all of the requested
> data to the controller before the DMA start is issued. In this
> case, the controller would become confused as to what to do with the
> data. In the worst case when all the data is returned back to the
> controller, the controller could hang. In other cases it could
> return partial data returning in data corruption. This problem has
> been seen in PPC systems and can also appear on an system with very
> fast disks, where the SATA controller is sitting behind a number of
> bridges, and hence there is significant latency between the r/w
> command and the start command. */
> /* issue r/w command if the access is to ATA*/
> if (qc->tf.protocol == ATA_PROT_DMA)
>
> ...and that would certainly explain what we are seeing. Are
> serverworks controllers broken by design?

The comment looks like a warning to me as the DMA engine is started
before the command is issued to the drive as explained in the next
comment.

--
tejun


\
 
 \ /
  Last update: 2008-06-23 02:41    [W:0.052 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site