Re: tgtd segfault during heavy I/O

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:
> 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

[Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [XFree86]     [Video Devices]

Add to Google Powered by Linux