2008-06-06 20:18:49     Flush Cache Question

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2008-06-06 20:18:49     Flush Cache Question

David Kasper (UNITED STATES)

Message: 56834   

 

Would anybody know if the following call is blocking until caches are flushed?  Or does that just trigger the flush process (I assume performed by pdflush threads)?  Note I use this call in my application code after writing every data file to a drive and immediately follow it by umount.  I.e. I am trying to keep the drive unmounted as my system is susceptible to random power failures.

 

  ::system("echo 3 > /proc/sys/vm/drop_caches");

 

Thank you,

 

David Kasper

QuoteReplyEditDelete

 

 

2008-06-09 10:47:24     Re: Flush Cache Question

Jonathan Kotta (UNITED STATES)

Message: 56870   

 

As I understand it, that drops the read cache.  It won't help in assuring that your data is safe.  Have a look at sync and the '-f -F' options to hdparm.  Also, if umount succeeds, all data has been sent to the disk, though it may still be in the disk's write cache.

QuoteReplyEditDelete

 

 

2008-06-09 15:14:25     Re: Flush Cache Question

Mike Frysinger (UNITED STATES)

Message: 56880   

 

Jonathan is right ... that command drops clean caches only, so it really doesnt help you (and it may actually hurt you as it drops all caches, not just the ones associated with the filesystem you're unmounting)

 

the `sync` command is used to push all caches transactions to storage

QuoteReplyEditDelete

 

 

2008-06-11 11:59:40     Re: Flush Cache Question

Robin Getz (UNITED STATES)

Message: 57009   

 

David:

 

If you need a journalling file system - why not use one? (Unless you have a USB or SD filesystem that needs to be compatible with Win).

 

-Robin

QuoteReplyEditDelete

 

 

2008-06-11 13:56:23     Re: Flush Cache Question

David Kasper (UNITED STATES)

Message: 57017   

 

Robin,

 

Thanks for your reply.  I started to evaluate EXT3 and then realized that data wasn't being saved reliably to the CompactFlash (without any power cycling).  So I wrote a test app that saves 500, 5MByte files, 500 bytes per each write, pseudo-random pattern, 1 second delay between files to CompactFlash.  Next each file is opened and the data verified - I am observing 4% of the files contain corrupt data sections.  Next, I am trying to isolated the problem as either SW or HW.  I removed the "cache flush syntax" from above but that caused page allocation errors.  Note I don't flush or sync anything between each file save and it looks like the error occurs after the file is closed.  I copied the console error message below.  Do you have any suggestions on how to resolve the allocation issue.  I'll probably write a simple diagnostic driver (write/read/verify all sectors) to verify the HW (this would remove the kernel and driver from the problem).

 

Thanks,

 

David Kasper

 

Saving file /mnt/cf/test/Ccp-1 Id-1F4.tst, Size = 5000000.000000, Blk = 500

Closing filesh: page allocation failure. order:7, mode:0x40d0

Hardware Trace:

0 Target : <0x000044a0> { _dump_stack + 0x0 }

   Source :

<0x0003032a> { ___alloc_pages + 0x17a }

1 Target : <0x0003032a> { ___alloc_pages + 0x17a }

   Source : <0x0000c692> { _printk + 0x16 }

2 Target : <0x0000c68e> { _printk + 0x12 }

   Source : <0x0000c51c> { _vprintk + 0x1b0 }

3 Target : <0x0000c510> { _vprintk + 0x1a4 }

   Source : <0xffa0124e> { __common_int_entry + 0xd8 }

4 Target : <0xffa011ec> { __common_int_entry + 0x76 }

   Source : <0xffa00fb4> { _return_from_int + 0x58 }

5 Target : <0xffa00fb4> { _return_from_int + 0x58 }

   Source : <0xffa00f8a> { _return_from_int + 0x2e }

6 Target : <0xffa00f5c> { _return_from_int + 0x0 }

   Source : <0xffa011e8> { __common_int_entry + 0x72 }

7 Target : <0xffa011e6> { __common_int_entry + 0x70 }

   Source : <0xffa0057e> { _asm_do_IRQ + 0x7a }

8 Target : <0xffa00576> { _asm_do_IRQ + 0x72 }

   Source : <0x00010542> { __local_bh_enable + 0x3e }

9 Target : <0x00010504> { __local_bh_enable + 0x0 }

   Source : <0x000107bc> { ___do_softirq + 0x94 }

10 Target : <0x000107b4> { ___do_softirq + 0x8c }

   Source : <0x00010794> { ___do_softirq + 0x6c }

11 Target : <0x00010786> { ___do_softirq + 0x5e }

   Source : <0x000136d2> { _run_timer_softirq + 0x82 }

12 Target : <0x000136ca> { _run_timer_softirq + 0x7a }

   Source : <0x00013674> { _run_timer_softirq + 0x24 }

13 Target : <0x00013664> { _run_timer_softirq + 0x14 }

   Source : <0x0001ec54> { _hrtimer_run_queues + 0xe8 }

14 Target : <0x0001ec20> { _hrtimer_run_queues + 0xb4 }

   Source : <0x0001ec16> { _hrtimer_run_queues + 0xaa }

15 Target : <0x0001ec04> { _hrtimer_run_queues + 0x98 }

   Source : <0x0001ec4a> { _hrtimer_run_queues + 0xde }

Stack from 0176dcdc:

        00000001 0003032e 00000000 00000001 000040d0 008ed70c 00000007 000040d0

        00000000 00000080 00000000 000240d0 00000000 0176c000 0176c000 0176c000

        00000010 00000000 001abcc0 000312e2 0019b284 00000000 0023e8a0 00000020

        000040d0 00000001 00000010 00254b00 00000000 030a8005 000040d0 0023e8a0

        008ef880 00031592 0004cfc4 01676960 00000077 0000ffff 00000002 00000000

        00000000 005dde00 0002ec92 0004cfc4 0002f0be 00000000 00155894 0001c968

Call Trace:

[<0005a094>] _load_flat_binary+0x60c/0xd10

[<00042d90>] _d_delete+0x6c/0xac

[<00004970>] _dma_free_coherent+0x6c/0xa4

[<0000a234>] _copy_fs_struct+0x5c/0x184

[<0000a230>] _copy_fs_struct+0x58/0x184

[<0000e130>] _do_wait+0x1a8/0x938

[<0003020e>] ___alloc_pages+0x5e/0x1fc

[<0001ff9d>] _second_overflow+0x145/0x1e4

[<0004cfc4>] _page_cache_pipe_buf_steal+0x8c/0xdc

[<0000288c>] _do_rt_sigreturn+0x1d0/0x850

[<00034c60>] _fput+0x1c/0x28

[<00042d90>] _d_delete+0x6c/0xac

[<00034c60>] _fput+0x1c/0x28

[<0000980f>] _sched_setscheduler+0x15b/0x270

[<000200d2>] _sysfs_show_available_clocksources+0x46/0x60

[<00004e9f>] _set_gpio_both+0x37/0x70

[<00036f34>] _search_binary_handler+0x6c/0x20c

[<00038234>] _do_execve+0xe8/0x1bc

[<00001aae>] _sys_execve+0x2e/0x54

[<00001a80>] _sys_execve+0x0/0x54

[<00010000>] _mktime+0xa8/0xac

[<00155860>] _noirqdebug_setup+0x1c/0x24

[<00155860>] _noirqdebug_setup+0x1c/0x24

[<00008000>] _bfin_demux_error_irq+0xbc/0x1a8

[<00060000>] _t_start+0x1c/0x40

 

Mem-info:

DMA per-cpu:

CPU    0: Hot: hi:   18, btch:   3 usd:   2   Cold: hi:    6, btch:   1 usd:   5

Active:3914 inactive:3508 dirty:70 writeback:1 unstable:0 free:458 slab:5070 mapped:0 pagetables:0

DMA free:1832kB min:928kB low:1160kB high:1392kB active:15656kB inactive:14032kB present:53848kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0

DMA: 144*4kB 13*8kB 8*16kB 2*32kB 1*64kB 5*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 1832kB

13568 pages of RAM

488 free pages

556 reserved pages

7417 pages shared

0 pages swap cached

Allocation of length 315332 from process 653 failed

DMA per-cpu:

CPU    0: Hot: hi:   18, btch:   3 usd:   2   Cold: hi:    6, btch:   1 usd:   5

Active:3914 inactive:3508 dirty:70 writeback:1 unstable:0 free:458 slab:5070 mapped:0 pagetables:0

DMA free:1832kB min:928kB low:1160kB high:1392kB active:15656kB inactive:14032kB present:53848kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 0

DMA: 144*4kB 13*8kB 8*16kB 2*32kB 1*64kB 5*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 1832kB

Unable to allocate RAM for process text/data, errno 12

 

 

Jump to address 0 - 0x0fff

 

CURRENT PROCESS:

 

COMM=sh PID=653

TEXT = 0x00000000-0x00000000  DATA = 0x00000000-0x00000000

BSS = 0x00000000-0x00000000   USER-STACK = 0x00000000

 

return address: 0x00000000; contents of [PC-16...PC+8]:

Cannot look at the [PC] for it is in unreadable L1 SRAM - sorry

 

 

RETE:  00000000  RETN: 0176e000  RETX: 00000000  RETS: 00000000

IPEND: 0030  SYSCFG: 0036

SEQSTAT: 0006002d    SP: 0176df24

R0: ffffffff    R1: 0039fc97    R2: 0039fedc    R3: 0039fedc

R4: 0080c130    R5: 0039fd70    R6: 00000000    R7: 00000000

P0: 0000000b    P1: 032a4ba0    P2: 00812304    P3: 032b5380

P4: 031378b0    P5: 00000000    FP: 00000000

A0.w: 00000000    A0.x: 00000000    A1.w: 00000000    A1.x: 00000000

LB0: 033dd531  LT0: 033dd52e  LC0: 00000000

LB1: 03386777  LT1: 03386776  LC1: 00000000

B0: 0000001c  L0: 00000000  M0: 00000000  I0: 0039fb24

B1: 00000000  L1: 00000000  M1: 00000000  I1: 0039fd0c

B2: 00000000  L2: 00000000  M2: 00000000  I2: 00000000

B3: 00000000  L3: 00000000  M3: 00000000  I3: 0039f9f8

 

USP: 0039fcd0   ASTAT: 02002020

DCPLB_FAULT_ADDR=0039fccc

ICPLB_FAULT_ADDR=00000000

 

 

Hardware Trace:

0 Target : <0x0000455c> { _trap_c + 0x0 }

   Source : <0xffa00c48> { _exception_to_level5 + 0xb4 }

1 Target : <0xffa00b94> { _exception_to_level5 + 0x0 }

   Source : <0xffa00b92> { _ex_trap_c + 0x4e }

2 Target : <0xffa00b44> { _ex_trap_c + 0x0 }

   Source : <0xffa00ce8> { _trap + 0x28 }

3 Target : <0xffa00cc0> { _trap + 0x0 }

   Source : <0x033cc664> [ /lib/libuClibc-0.9.29.so + 0xc664 ]

4 Target : <0x033cc654> [ /lib/libuClibc-0.9.29.so + 0xc654 ]

   Source : <0x032a4bb2> [ /lib/libpthread-0.9.29.so + 0x4bb2 ]

5 Target : <0x032a4ba8> [ /lib/libpthread-0.9.29.so + 0x4ba8 ]

   Source : <0x032a4b88> [ /lib/libpthread-0.9.29.so + 0x4b88 ]

6 Target : <0x032a4b84> [ /lib/libpthread-0.9.29.so + 0x4b84 ]

   Source : <0x032a4b5c> [ /lib/libpthread-0.9.29.so + 0x4b5c ]

7 Target : <0x032a4b38> [ /lib/libpthread-0.9.29.so + 0x4b38 ]

   Source : <0x032a4ba4> [ /lib/libpthread-0.9.29.so + 0x4ba4 ]

8 Target : <0x032a4ba0> [ /lib/libpthread-0.9.29.so + 0x4ba0 ]

   Source : <0x033cba9c> [ /lib/libuClibc-0.9.29.so + 0xba9c ]

9 Target : <0x033cba94> [ /lib/libuClibc-0.9.29.so + 0xba94 ]

   Source : <0x033cc650> [ /lib/libuClibc-0.9.29.so + 0xc650 ]

10 Target : <0x033cc646> [ /lib/libuClibc-0.9.29.so + 0xc646 ]

   Source : <0xffa0124e> { __common_int_entry + 0xd8 }

11 Target : <0xffa011ec> { __common_int_entry + 0x76 }

   Source : <0xffa0148c> { _evt_system_call + 0x64 }

12 Target : <0xffa0148c> { _evt_system_call + 0x64 }

   Source : <0xffa00e70> { _system_call + 0xb8 }

13 Target : <0xffa00e6c> { _system_call + 0xb4 }

   Source : <0xffa00e5c> { _system_call + 0xa4 }

14 Target : <0xffa00e56> { _system_call + 0x9e }

   Source : <0xffa00e46> { _system_call + 0x8e }

15 Target : <0xffa00e34> { _system_call + 0x7c }

   Source : <0xffa00e54> { _system_call + 0x9c }

Stack from 0176df04:

        00811918 ffa00c4c 0016470c 0016470c 0016470c 0039fedc 0080c130 033cd4ec

        00000000 00000030 0006002d 00000000 0176e000 00000000 00000000 00000000

        ffffffff 02002020 03386777 033dd531 03386776 033dd52e 00000000 00000000

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000001c

        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

        0039f9f8 00000000 0039fd0c 0039fb24 0039fcd0 00000000 00000000 031378b0

Call Trace:

 

 

root:~>

QuoteReplyEditDelete

 

 

2008-06-11 14:31:19     Re: Flush Cache Question

Robin Getz (UNITED STATES)

Message: 57025   

 

David:

 

It looks like a malloc is failing, and then you use the pointer anyway.

 

As for the description - the file system page cache should grow and shrink (by flushing things to the backing device) as necessary. You should not see any problems.

 

Can you attach your application here and we can have a look?

 

-Robin

QuoteReplyEditDelete

 

 

2008-06-11 16:10:49     Re: Flush Cache Question

David Kasper (UNITED STATES)

Message: 57037   

 

Robin,

 

Here is the media tester class.  Note the uClinux::FlushCache() logic has been commented out.  Basically MediaTestMgr() polls a SW flag and then enters a loop of opening, writing and closing until max iterations have been processed.  A new name is created for each iteration.  Let me know if you need further information.

 

David Kasper

 

 

MediaTester.h

uClinuxSys.h

MediaTester.cpp

QuoteReplyEditDelete

 

 

2008-06-12 20:56:05     Re: Flush Cache Question

David Kasper (UNITED STATES)

Message: 57189   

 

Does anybody know if the IDE driver supporting the CompactFlash uses the Blackfin's DMA channels to transfer data?  I looked through the ".../drivers/ide" files and didn't find it.  Common for my corruption cases the files are the correct size but the data is wrong.  I checked the cache policy and it was configured to write back.  I configured the kernel to write through and am repeating the test.  However, this would only help things if DMA were involved.  Also, does anyone knows if I need to configure the cache to write through?

 

David Kasper

QuoteReplyEditDelete

 

 

2008-06-12 21:16:33     Re: Flush Cache Question

Mike Frysinger (UNITED STATES)

Message: 57191   

 

i'm pretty sure it's all PIO ... in 2008R1 and newer, there is no Blackfin-specific driver anymore.  we use the common PATA driver that is part of the SATA framework.

QuoteReplyEditDelete

 

 

2008-06-12 21:24:05     Re: Flush Cache Question

David Kasper (UNITED STATES)

Message: 57193   

 

Mike,

 

I am not that familiar with the interface.  Does PIO imply no DMA for read/writing?

 

Dave

QuoteReplyEditDelete

 

 

2008-06-12 21:36:07     Re: Flush Cache Question

Mike Frysinger (UNITED STATES)

Message: 57195   

 

it doesnt so much imply as it does define: http://en.wikipedia.org/wiki/Programmed_input/output

Attachments

    Outcomes