Ok. I easily reproduced it with three hosts.
One target: One host runs tgtd and exports a LUN. Attach GDB to tgtd. Two initiators: The two other hosts run iscsi initiator to log into the target. I ran a small : while true; do dd if=... of=/dev/null bs=512 count=1; date; done on each one of them to see that they were doing i/o continously. On one of the initiators, disable all the respose traffic coming back from the target iptables -I INPUT -s <target IP> -p tcp --sport 3260 -j DROP The output from the while/dd loop on that initiator would immediately hang. After a while tgtd would SEGV. ronnie On Wed, Jul 9, 2008 at 3:32 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On Mon, 7 Jul 2008 11:12:08 +1000 > "ronnie sahlberg" <[EMAIL PROTECTED]> wrote: > >> Please apply. >> >> I have reproduced the SEGV that was reported when I/O has failed/been >> aborted. >> This pathc prevents the SEGV from occuring in this situation. >> >> It does however not address the root cause why tgtd tries to clear a >> list that is already (and it should know is already?) empty. > > It might be easy to debug tgtd with this workaround patch but after > all we need to fix the root problem. It's likely that this workaround > will hurt us in the future. > > I think that there might be bugs in Task Management Message > handling. I try to reproduce the problem after I get the detailed > information of Tomasz's configuration. > _______________________________________________ Stgt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/stgt-devel
