On Fri, Apr 17, 2009 at 6:19 AM, Milos Muzik <[email protected]> wrote:
> > Alastair Neil wrote: > <snip> > > > > I succeeded in getting wireshark in stalled on the linux target server > > and did a capture from there (attached). I'm not an expert but this > > jumped out at me as a likely cause: > > > > > > 8.784473 192.168.0.135 -> 192.168.0.45 iSCSI SCSI: Persistent > > Reserve In LUN: 0x00 > > 8.784859 192.168.0.45 -> 192.168.0.135 iSCSI SCSI Response (Check > > Condition) LUN:0x00 [Unreassembled Packet [incorrect TCP checksum]] > > 8.850272 192.168.0.135 -> 192.168.0.45 TCP 49622 > iscsi-target > > [ACK] Seq=1737 Ack=19641 Win=277384 Len=0 TSV=2601 TSER=798756713 > <snip> > > It looks like a patch to support support for persistent reservations in > > the linux kernel was submitted in January 30th this year so it is likely > > that this is simply an unsupported feature at the moment. My question > > is now will this cause problems? Is there a way to disable the > > behaviour in the initiator? > > > > > > Thanks, Alastair Neil > > Hi Alastair, > > those commands "Persistent Reserve In" are likely sent by the initiator to > test > if the targets support persistent reservations. I don't think it is a > problem > that your targets do not support it. > > I wonder what is the actual problem. Is it just appearance of those > messages > about not enough sense information? Are you eventually able to use the > iSCSI > disks? The net traffic dump you attached suggests that at least the login > phase > was successful. > > Anyway, to investigate if some sense data were corrupted you need more > verbose > output from wireshark. The information you are looking for is on SCSI > layer. As > there are no Request Sense commands then probably autosensing is used. > Hence try > to look at responses with Check Condition if they contain valid sense data. > > Wireshark also supports import from Solaris' snoop(1M) output. So you can > analyze network traffic on the initiator side as well. Use this command to > do > that: > snoop -x 0 -d <interface> -o <output file> > > Another option for tracing SCSI commands is to use nice scsi.d dtrace > script > http://blogs.sun.com/chrisg/entry/scsi_d_script > > Regards, > Milos Thanks for the tips, yes the targets are functional, I worry when I see error messages. I'll try one or both of the things you suggest to see if i can get to the root of the issue. Thanks again, Alastair
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
