[stgt] tgtd segfault during heavy I/O

[FUJITA Tomonori]

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