[stgt] Infinite Loop on 1.0.26?

[Brad.Goodman at emc.com]

>
>-----Original Message-----
>From: stgt-owner at vger.kernel.org [mailto:stgt-owner at vger.kernel.org] On Behalf Of Brad.Goodman at emc.com
>Sent: Saturday, April 07, 2012 10:02 AM
>To: stgt at vger.kernel.org
>Subject: Infinite Loop on 1.0.26?
>
>I have been doing some testing with the most recent 1.0.26 code.
>
>I noticed a state yesterday, after running an iSER read tests from multiple initiators to multiple instances of tgtd.
>
>My read tests completed normally, after which I happened to check CPU utilization on the target system. All of my tgtd instances (6 >or 8 in total) were running 100% CPU utilization (most of which was in system time).
>
>I made sure my tests were not running - and even went as far as to do an iSCSI/iSER logout on each of my initiators, but this had >no impact on the target CPU numbers. I verified that my connection media (Infiniband) had no discernable traffic on it - so in >short, it doesn't appear as though there as any actual activity to the target daemon.
>
>None of the instances would respond to a (normal) shutdown request via tgtadm, and it would say that connection to the endpoint >could not be established. No problems were indicated in /var/log/messages or otherwise.
>
>In short - I'm suspecting that tgtd was stuck in some sort of infinite loop. Had I been less hasty, I would have connected via >strace or gdb to get a closer look at what was going on.
>
>I have never seen this type of behavior ever, on prior versions. Barring that investigation when/if this happens again - I just >wanted to see if this was a "known" issue, or anyone had ever seen anything like this before. Is this new? Any ideas?
>
>Thanks,
>
>Brad Goodman
>EMC Corporation
>
 
Hit this again today - strace looked like:

epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}, {EPOLLIN, {u32=26439904, u64=26439904}}}, 1024, 4294967295) = 2
read(12, "\1\0\0\0\0\0\0\0", 8)         = 8
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1
epoll_wait(3, {{EPOLLOUT|EPOLLHUP, {u32=38412480, u64=38412480}}}, 1024, 4294967295) = 1

...but one of the first two lines for hundreds of the latters - continuing forever.
--
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