[stgt] tgtd segfault during heavy I/O

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Wed Jul 20 18:33:02 CEST 2011

On Wed, 20 Jul 2011 19:08:59 +0800
Kiefer Chang <zapchang at gmail.com> 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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

More information about the stgt mailing list