Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 101332
b: refs/heads/master
c: ec6add9
h: refs/heads/master
v: v3
  • Loading branch information
Pavel Machek authored and Jeff Garzik committed Jul 14, 2008
1 parent 3b55f8e commit 6938a38
Show file tree
Hide file tree
Showing 2 changed files with 24 additions and 16 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 18f7ba4c2f4be6b37d925931f04d6cc28d88d1ee
refs/heads/master: ec6add99307d5149e17f6e358f19f0205b622407
38 changes: 23 additions & 15 deletions trunk/drivers/ata/sata_svw.c
Original file line number Diff line number Diff line change
Expand Up @@ -253,21 +253,29 @@ static void k2_bmdma_start_mmio(struct ata_queued_cmd *qc)
/* start host DMA transaction */
dmactl = readb(mmio + ATA_DMA_CMD);
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*/
/* This works around possible data corruption.
On 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)
ap->ops->sff_exec_command(ap, &qc->tf);
}
Expand Down

0 comments on commit 6938a38

Please sign in to comment.