Hello Mr. Nelson, We made some progress, With below two patches and setting CMA=64, Issue is not getting reproduced. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/dma/edma.c?id=5ca9e7ce6eebec53362ff779264143860ccf68cd https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/dma/edma.c?id=e3ddc979465118b7ba46fed7cd10f4421edc3049
After this it seems to work, however now issue is tar file(size 460MB) extraction takes 1 hour as opposed to 4 mins without above patches. Above two patches are mostly freeing memory in the edma driver, *so root cause seems to be memory leak in the edma driver(kernel version 3.12).* Even if above two patches are solving issue they are giving major performance hit, do you know any other kernel patch for edma driver for kernel 3.12 ? Thank you, Regards, Ankur On Wednesday, 20 July 2016 12:26:06 UTC+5:30, Ankur Tank wrote: > > Thank you for reply Mr. Nelson, > > Were there any patches or fixes your remember for 3.12 kernel ? > We will move to 4.1 kernel but its in pipeline and current boards which we > are shipping should work with 3.12. > Considering that do you have any suggestions for us to fix this issue ? > > While testing I also observed that after mentioned error I saw following > error in the partition from where board was booting. > > [ 194.912834] EXT4-fs error (device mmcblk0p15): ext4_journal_check_start: > 56: Detected aborted journal > [ 194.922558] EXT4-fs (mmcblk0p15): Remounting filesystem read-only > > This error was recovered after rebooting board. However I think we must > handle this case. > I thinking of running e2fsck and reboot the board when error is received > during mounting partition. > But what if this errors not recovered at all ? > do you suggest on that? > > Regards, > Ankur > > On Tuesday, 19 July 2016 22:38:25 UTC+5:30, RobertCNelson wrote: >> >> >> >> On Tue, Jul 19, 2016 at 11:11 AM, Ankur Tank <art...@gmail.com> wrote: >> >>> >>> We are using BeagleBoneBlack based custom Linux board. >>> It has 256MB of RAM and 4GB of eMMC. >>> Currently RFS size of the project is 163MB. While RFS partition size is >>> 500MB. >>> For testing, we added 20 number of big files(10MB size) and started >>> firmware upgrade process. >>> >>> During the firmware Upgrade process we see following error when roofs is >>> being written, >>> >>> We could solve it by changing >>> /proc/sys/vm/min_free_kbytes >>> >>> from *2005* to *4096*. >>> >>> *But now my doubt is what should be the ideal value for that, what >>> factors we should consider while calculating it. From the kernel >>> documentation I don't get that information, * >>> *but I could understand one thing that is this value can not be too low >>> or too high or else system will break.* >>> >>> Any suggestion/pointer ? >>> >>> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode: >>> 0x200020 >>> [ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P O >>> 3.12.10-005-ts-armv7l #2 >>> [ 6676.674321] [<c0012d24>] (unwind_backtrace+0x0/0xf4) from [< >>> c0011130>] (show_stack+0x10/0x14) >>> [ 6676.674355] [<c0011130>] (show_stack+0x10/0x14) from [<c0087548>] >>> (warn_alloc_failed+0xe0/0x118) >>> [ 6676.674383] [<c0087548>] (warn_alloc_failed+0xe0/0x118) from [< >>> c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8) >>> [ 6676.674413] [<c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8) >>> from [<c00b2e8c>] (cache_alloc_refill+0x328/0x620) >>> [ 6676.674436] [<c00b2e8c>] (cache_alloc_refill+0x328/0x620) from [< >>> c00b3224>] (__kmalloc+0xa0/0xe8) >>> [ 6676.674471] [<c00b3224>] (__kmalloc+0xa0/0xe8) from [<c0212904>] >>> (edma_prep_slave_sg+0x84/0x388) >>> [ 6676.674505] [<c0212904>] (edma_prep_slave_sg+0x84/0x388) from [< >>> c02ec0a0>] (omap_hsmmc_request+0x414/0x508) >>> [ 6676.674544] [<c02ec0a0>] (omap_hsmmc_request+0x414/0x508) from [< >>> c02d6748>] (mmc_start_request+0xc4/0xe0) >>> [ 6676.674568] [<c02d6748>] (mmc_start_request+0xc4/0xe0) from [< >>> c02d7530>] (mmc_start_req+0x2d8/0x38c) >>> [ 6676.674589] [<c02d7530>] (mmc_start_req+0x2d8/0x38c) from [< >>> c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8) >>> [ 6676.674611] [<c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from [< >>> c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468) >>> [ 6676.674631] [<c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468) from [< >>> c02e5c68>] (mmc_queue_thread+0x88/0x118) >>> [ 6676.674657] [<c02e5c68>] (mmc_queue_thread+0x88/0x118) from [< >>> c004d8b8>] (kthread+0xb4/0xb8) >>> [ 6676.674681] [<c004d8b8>] (kthread+0xb4/0xb8) from [<c000e298>] ( >>> ret_from_fork+0x14/0x3c) >>> >> >> This actually smells very much like the random mmc issues we saw on >> "3.8.x" based images... mmc wasn't really fixed/solid till the 3.14.x >> timeline... Not sure how much of that was back-ported to 3.12.10... >> >> Regards, >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/441a2700-66dc-4a66-9269-dd17ebe303d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
