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    [W:0.027 / U:59.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site