On Wed, 20 Jul 2011 19:08:59 +0800 Kiefer Chang <zapchang@xxxxxxxxx> wrote: > Here is the result, unfortunately neither the core dump or directly > attaching gdb to tgtd can't show right code trace. > system log: > http://dl.dropbox.com/u/8354750/tgtd/20110720/messages.gz > > backtrace (tgtd built with make DEBUG=1): > Core was generated by `./tgtd'. > Program terminated with signal 11, Segmentation fault. > #0 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000000004177d1 in event_loop () at tgtd.c:400 > #2 0x0000000000417e82 in main (argc=1, argv=0x7fff192e2bc8) at tgtd.c:574 Thanks, I'll investigate later. > By the way, if I use O_DIRECT flag on all lun's backing store, I found > tgtd won't segfault during the same I/O test (1 day). > I can't see any abort task command in the log. > I can't understand why...Shouldn't lower performance cause command > timeout much easily? What's kinda I/O test? Write intensive? I guess that with write intensive workload, Linux kernels sometimes are really too slow (look like completely stopping for some time) due to page cache writeback (depends on your kernel version). -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
