On 1/18/07, Rick McNeal <[EMAIL PROTECTED]> wrote:
Jan 18 22:01:07 foobar iscsi: [ID 867852 kern.warning] WARNING: iscsi connection(5) protocol error - received an unsupported opcode:0x41 Needless to say something very strange is occurring here. The target uses various #defines while creating reponse PDU's and 0x41 is not part of those #defines. So how you are getting a packet with such a value is the question. Corruption of the data across the wire? Possible, but highly unlikely unless you've got a real bad network setup.
I have seen network corruption here, but only the once. I was discussing issues around this last night with some of the folks at the London OpenSolaris User Group meeting. OK, so you've got checksums on the zpool supplying the target, and checksums locally in zfs, but what protects the packets as they move across the wire? And I have another core from iscsitgtd on the server.
[EMAIL PROTECTED] mdb - core.iscsi2 Loading modules: [ libavl.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 ld.so.1 ] > $c libc.so.1`_lwp_kill+8(6, ffffffffffffffec, ffffffff7dc00000, 0, 0, 5) libc.so.1`abort+0x10c(1, 4960, 6, 0, aafe4, 4800) libc.so.1`_assert+0x70(10002aad0, 10002aad8, 253, 7000, aac98, ffffffff7dc00000 ) t10_cmd_state_machine+0x444(100261090, 2, 19c, 100000, 8, 100137000) t10_cmd_shoot_event+0x1c(100261160, 2, 0, 4, 100261090, 100261140) spc_mselect_data+0xa0(100261090, 0, 0, 10013cac0, 10013cac4, 0) trans_rqst_dataout+0xc0(100261090, 10013cac0, e, 0, 0, 10013cad7) spc_mselect+0x7c(100261090, 0, 0, e, 10, 10013c4e0) lu_runner+0x148(100261260, 0, 6, 200, 100137f70, 100139e60) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) Well, the code (t10_cmd_state_machine) has detected an illegal state transition. The next question is why. Considering the bogus data that the initiator received it's possible that the target has received something just as unlikely causing it to attempt to do something equally weird. I know this doesn't help much, but this behavior is too strange for words.
;-) Would you feel comfortable shipping me the core and binary? Remember that
since the daemon core could contain data blocks from your backing store I might see something you would wish to keep private.
I'll send it once I get into work in the morning. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
