Hello, I've observed the following rather peculiar behavior of crash 7.1.3 (gdb 7.6). crash> set ffff88000376d280 PID: 9615 COMMAND: "jbd2/dm-32-8" TASK: ffff88000376d280 [THREAD_INFO: ffff880002bdc000] CPU: 2 STATE: TASK_UNINTERRUPTIBLE crash> gdb set disassembly-flavor intel crash> bt PID: 9615 TASK: ffff88000376d280 CPU: 2 COMMAND: "jbd2/dm-32-8" #0 [ffff880002bdf9a8] __schedule at ffffffff81618404 #1 [ffff880002bdf9e0] __clone_and_map_data_bio at ffffffff8150af42 #2 [ffff880002bdfa40] schedule at ffffffff81618a8e crash> gdb set disassembly-flavor att crash> bt PID: 9615 TASK: ffff88000376d280 CPU: 2 COMMAND: "jbd2/dm-32-8" #0 [ffff880002bdf9a8] __schedule at ffffffff81618404 #1 [ffff880002bdfa40] schedule at ffffffff81618a8e #2 [ffff880002bdfa60] schedule_timeout at ffffffff8161b3e6 #3 [ffff880002bdfb20] io_schedule_timeout at ffffffff81618054 #4 [ffff880002bdfb50] bit_wait_io at ffffffff81619196 #5 [ffff880002bdfb60] __wait_on_bit at ffffffff81618f7d #6 [ffff880002bdfbb0] out_of_line_wait_on_bit at ffffffff816190d8 #7 [ffff880002bdfc20] __wait_on_buffer at ffffffff811d13d8 #8 [ffff880002bdfc30] jbd2_journal_commit_transaction at ffffffff81270a45 #9 [ffff880002bdfe30] kjournald2 at ffffffff81275073 #10 [ffff880002bdfec0] kthread at ffffffff810738fc #11 [ffff880002bdff50] ret_from_fork at ffffffff8161c75f How come setting the disassembly flavor (which should be just a presentation aid) affects the displaying of the callstack? It took me a while to correlate this behavior. It's also strange that this doesn't happen on all processes on a vmcore file but only on some, so far I haven't been able to find any clues as to which processes this applies to.

Regards, Nikolay