Hello Mr.Nelson, This issue is reproducible in 4.1 kernel also. I found the use case where it is almost every time reproducible.
1. Conider that we have two RFS partition, and current root is /dev/mmcblk0p15. Another RFS partition /dev/mmcblk0p16 is not in use. 2. Create RFS tar of 390MB(compressed size. Uncompressed size is 487MB) of size. I had include some big files in it. (I had copied 35 files of size 10MB each). 3. Copy this big tar e.g. rootfs.tar.gz to board. 4. Mount unused partition i.e. /dev/mmcblk0p16 to /mnt/rfs_test. 5. Delete content from /mnt/rfs_test/, using command rm -rf /mnt/rfs_test/* 6. Untar rootfs.tar.gz to /mnt/rfs_test/ tar -xzvf /home/rootfs.tar.gz -C /mnt/rfs_test/ 7. From another ssh terminal run while [ true ];do dd if=/dev/mmcblk0p16 of=/dev/null bs=1M; done 8. From yet another terminal observe the syslog, or dmesg while [ ture ] ; do clear; dmesg | tail -n 30; sleep 2;done 9. Before tar extraction completes you will see error reproduced. So It doesn't seem to be mmc driver issue, isn't it ? Do you have any suggestion/pointer for me ? Thank you, 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 > <javascript:>> 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/c390a7b3-9fd3-448c-bfaa-f54b449a7f30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
