On Mon, 14 Sep 2009 16:56:03 +0200 Florian Haas <florian.haas@xxxxxxxxxx> wrote: > On 2009-09-14 16:50, FUJITA Tomonori wrote: > > On Mon, 07 Sep 2009 10:16:06 +0200 > > Florian Haas <florian.haas@xxxxxxxxxx> wrote: > > > >> On 09/07/2009 08:00 AM, Florian Haas wrote: > >>> On 09/07/2009 07:58 AM, FUJITA Tomonori wrote: > >>>> On Mon, 07 Sep 2009 07:47:32 +0200 > >>>> Florian Haas <florian.haas@xxxxxxxxxx> wrote: > >>>> > >>>>>> What iSCSI initiator implementation do you use on Linux? > >>>>> For testing? I use open-iscsi on Debian lenny; the Debian package > >>>>> version number is 2.0.870~rc3-0.4. My sg3-utils package version (if > >>>>> that's of any help) is 1.24-2. > >>>> That's strange. open-iscsi doesn't send TARGET_REST. > >>> Interesting. Let me grab a packet dump and I'll be back in touch. > >> You're right, open-iSCSI apparently simply translates any host or "bus" > >> reset into a new login sequence. For device resets, it does use a Task > >> Management Function (0x02) of the type "LU reset" (0x05). > > > > Mike posted a patch to add WARM_RESET support to open-iscsi. I lightly > > tested my patch to add TARGET_RESET to tgt and it seems to work. > > > > FYI, sg_reset utility doesn't send TARGET_RESET so you need to modify > > it. > > Then out of curiosity, how did you test TARGET_RESET when working over > open-iscsi? I modified sg_reset.c to issue SG_SCSI_RESET_TARGET ioctl. > >> Going back to my original problem, I've now sifted through packet traces > >> generated on the production iSCSI target server (the one that the MSCS > >> hosts talk to), and have encountered something that leaves me > >> confounded. This applies to both IET and STGT (hence yet another > >> cross-post to both lists), so it's either something that is wrong in > >> both implementation, or some breakage in MSCS. Perhaps someone can > >> enlighten me here. > > > > Have you tried the latest git tree (the CAPACITY bug was fixed)? > > Yes the capacity read seems to work OK now. Thanks. There still seems to > be an additional issue with regard to "bus resets" from the MS > initiator, but we're currently still investigating whether it's an > initiator or target issue. Ok, I thought that a CAPACITY READ command is successful, then the initiator sends TARGET RESET. Let me know if you find a issue on the target side or add a workaround to avoid initiator issues. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
