On Mon, 29 Oct 2012, Luigi Semenzato wrote: > I managed to get the stack trace for the process that refuses to die. > I am not sure it's due to the deadlock described in earlier messages. > I will investigate further. > > [96283.704390] chrome x 815ecd20 0 16573 1112 0x00100104 > [96283.704405] c107fe34 00200046 f57ae000 815ecd20 815ecd20 ec0b645a > 0000578f f67cfd20 > [96283.704427] d0a9a9a0 c107fdf8 81037be5 f5bdf1e8 f6021800 00000000 > c107fe04 00200202 > [96283.704449] c107fe0c 00200202 f5bdf1b0 c107fe24 8117ddb1 00200202 > f5bdf1b0 f5bdf1b8 > [96283.704471] Call Trace: > [96283.704484] [<81037be5>] ? queue_work_on+0x2d/0x39 > [96283.704497] [<8117ddb1>] ? put_io_context+0x52/0x6a > [96283.704510] [<813b68f6>] schedule+0x56/0x58 > [96283.704520] [<81028525>] do_exit+0x63e/0x640 Could you find out where this happens to be in the function? If you enable CONFIG_DEBUG_INFO, you should be able to use gdb on vmlinux and find out with l *do_exit+0x63e. -- 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>