lkml.org 
[lkml]   [2008]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: sata_svw data corruption, strange problems
From
Date
On Mon, 2008-06-23 at 11:01 +0200, Pavel Machek wrote:
> On Mon 2008-06-23 17:56:32, Tejun Heo wrote:
> > Pavel Machek wrote:
> > > On Mon 2008-06-23 10:39:40, Andreas Schwab wrote:
> > >> Pavel Machek <pavel@suse.cz> writes:
> > >>
> > >>> + 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
> > >> s/returning/resulting/ ?
> > >
> > > Fix thinko in sata_svw comment.
> > >
> > > Signed-off-by: Pavel Machek <pavel@suse.cz>
> >
> > Please collapse into one patch. Thanks.

Am I the only one to find Pavel variant almost as obscure as
the original one ? :-)

It should explain precisely what the workaround is. Ie. to start the
DMA there instead of where it normally is started which is the
bmdma_setup() function.

BTW. Tejun, I suppose that usually starting DMA after issuing the
command is a standard practice of legacy/sff type controllers ? Or it's
just because that's how linux did it until now ?

Ben.

> ---
>
> Clarify comment in sata_svw.c.
>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
>
> diff --git a/drivers/ata/sata_svw.c b/drivers/ata/sata_svw.c
> index 16aa683..fb13b82 100644
> --- a/drivers/ata/sata_svw.c
> +++ b/drivers/ata/sata_svw.c
> @@ -253,21 +253,29 @@ static void k2_bmdma_start_mmio(struct a
> /* 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);
> }
>
>



\
 
 \ /
  Last update: 2008-06-23 11:25    [from the cache]
©2003-2011 Jasper Spaans