On Tue, Jul 19, 2016 at 11:11 AM, Ankur Tank <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiYgrAkSP_%2BbK-9z-abNiyr%3DdzSDzVQ9dAasSRpGTcw1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
