On Wed, 31 Oct 2012, Zhouping Liu wrote: > On 10/31/2012 03:26 PM, Hugh Dickins wrote: > > > > There's quite a few put_page()s in do_huge_pmd_numa_page(), and it > > would help if we could focus on the one which is giving the trouble, > > but I don't know which that is. Zhouping, if you can, please would > > you do an "objdump -ld vmlinux >bigfile" of your kernel, then extract > > from bigfile just the lines from "<do_huge_pmd_numa_page>:" to whatever > > is the next function, and post or mail privately just that disassembly. > > That should be good to identify which of the put_page()s is involved. > > Hugh, I didn't find the next function, as I can't find any words that matched > "do_huge_pmd_numa_page". > is there any other methods? Hmm, do_huge_pmd_numa_page does appear in your stacktrace, unless I've made a typo but am blind to it. Were you applying objdump to the vmlinux which gave you the BUG at mm/memcontrol.c:1134! ? Maybe just do "objdump -ld mm/huge_memory.o >notsobigfile" and mail me an attachment of the notsobigfile. I did try building your config here last night, but ran out of disk space on this partition, and it was already clear that my gcc version differs from yours, so not quite matching. > also I tried to use kdump to dump vmcore file, > but unluckily kdump didn't > work well, if you think it useful to dump vmcore file, I can try it again and > provide more info. It would take me awhile to get up to speed on using that, I'd prefer to start with just the objdump of huge_memory.o. I forgot last night to say that I did try stress (but not on a kernel of your config), but didn't see the BUG: I expect there are too many differences in our environments, and I'd have to tweak things one way or another to get it to happen - probably a waste of time. Thanks, Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>