[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: Data corruption when MMC block bounce option enabled
From:       Vinayak <vinayak.pane () gmail ! com>
Date:       2008-06-30 14:18:13
Message-ID: 7ea3a06a0806300706u23c74e50xf6f863d20559dd9f () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jun 27, 2008 at 11:14 PM, Pierre Ossman <drzeus@drzeus.cx> wrote:

> On Tue, 24 Jun 2008 15:19:18 +0530
> Vinayak <vinayak.pane@gmail.com> wrote:
>
> > They does not change. But my query is how exactly they are interpreted in
> > case of BLOCK_BOUNCE ?
> > Well, from the code snippet of card/queue.c:
> >
> >             bouncesz = MMC_QUEUE_BOUNCESZ;
> >             blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
> >             blk_queue_max_sectors(mq->queue, bouncesz / 512);
> >             blk_queue_max_phys_segments(mq->queue, bouncesz / 512);
> >             blk_queue_max_hw_segments(mq->queue, bouncesz / 512);
> >             blk_queue_max_segment_size(mq->queue, bouncesz);
> >
> > It is clear that the values individual driver sets through
> > host->max_req_size,  host->max_seg_size
> > parameters will not be used while setting blk_queue_max(s) configuration
> for
> > request queue.
> >
>
> The key is that bouncesz is calculated based on what the driver has
> reported. The code for it is just above the one you cited:
>
>                bouncesz = MMC_QUEUE_BOUNCESZ;
>
>                if (bouncesz > host->max_req_size)
>                        bouncesz = host->max_req_size;
>                if (bouncesz > host->max_seg_size)
>                        bouncesz = host->max_seg_size;
>
Alright, In my case bouncesz should be 4096 then. However,
bounce limit is hardcoded to BLK_BOUNCE_HIGH.

 blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);


> >
> > When I write big file (~10MB) to MMC card, my controller receives the
> > requests which are further written without any errors to card. But the
> two
> > file's hexdump differs.
> >
>
> Sounds like a memory shuffling bug in your driver. It's fairly common
> during development.
>
> Are you seeing it for both DMA and PIO? And both reads and writes?
>
No I observe this only in case of DMA, and not in interrupt or polling mode.

In polling mode the settings are
        mmc->max_hw_segs = 16;
        mmc->max_phys_segs = NR_SG;

Infact the DMA mode works perfectly fine without this bounce buffer option.

I wonder, how can memory get shuffled in my layer of functions when the
bounce buffer is completely under control by block i/o layer. I am
suspecting that the bounce buffer might get shuffled internally. Is it
populated sequentially always ?


> >
> > Settings within driver are as follows:
> >
> > mmc->max_hw_segs = 1;
> > mmc->max_phys_segs = 1;
> > mmc->max_req_size = 4096;
> > mmc->max_blk_size = 16384;
> > mmc->max_blk_count = 0xffffff;
> > mmc->max_seg_size = mmc->max_req_size;
> >
>
> That should be fine, although it is always better if it is internally
> consistent. E.g. how could you transfer a 16 KiB block if the request
> can't be larger than 4 KiB?


What I understood from these exported parameters is
max_req_size = max_blk_size * max_blk_count

Which indeed doesn't work & produces the garbled data as well.
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]