pbraun wrote: > Hi, > > I'm using iscsi-initiator-utils package on RHEL5.3 i386. I'm using an > IET target to export a whole disk on the network. And on the > initiator side, when starting the iscsi service, here's the dmesg, > > May 28 18:59:07 sg1 kernel: Loading iSCSI transport class v2.0-724. > May 28 18:59:07 sg1 kernel: iscsi: registered transport (tcp) > May 28 18:59:07 sg1 kernel: iscsi: registered transport (iser) > May 28 18:59:07 sg1 iscsid: iSCSI logger with pid=6962 started! > May 28 18:59:07 sg1 kernel: scsi19 : iSCSI Initiator over TCP/IP > May 28 18:59:07 sg1 kernel: Vendor: IET Model: VIRTUAL- > DISK Rev: 0 > May 28 18:59:07 sg1 kernel: Type: Direct- > Access ANSI SCSI revision: 04 > May 28 18:59:08 sg1 kernel: SCSI device sdb: 121634816 512-byte hdwr > sectors (62277 MB) > May 28 18:59:08 sg1 kernel: sdb: Write Protect is off > May 28 18:59:08 sg1 kernel: sdb: Mode Sense: 77 00 00 08 > May 28 18:59:08 sg1 kernel: SCSI device sdb: drive cache: write > through > May 28 18:59:08 sg1 kernel: SCSI device sdb: 121634816 512-byte hdwr > sectors (62277 MB) > May 28 18:59:08 sg1 kernel: sdb: Write Protect is off > May 28 18:59:08 sg1 kernel: sdb: Mode Sense: 77 00 00 08 > May 28 18:59:08 sg1 kernel: SCSI device sdb: drive cache: write > through > May 28 18:59:08 sg1 kernel: sdb: sdb1 > May 28 18:59:08 sg1 kernel: sd 19:0:0:0: Attached scsi disk sdb > May 28 18:59:08 sg1 kernel: sd 19:0:0:0: Attached scsi generic sg1 > type 0 > May 28 18:59:08 sg1 iscsid: transport class version 2.0-724. iscsid > version 2.0-868 > May 28 18:59:08 sg1 iscsid: iSCSI daemon with pid=6963 started! > May 28 18:59:08 sg1 iscsid: received iferror -38 > May 28 18:59:08 sg1 last message repeated 2 times > May 28 18:59:08 sg1 iscsid: connection1:0 is operational now > > Note the "received iferror -38" error. > Note. I've got troubbles with MC/Serviceguard refusing to validate a > lock LUN. Maybe that's why. >
It's probably not. iferror -38 just means userspace wanted to setup some feature in the kernel but the kernel did not support it. For example, iscsid wanted to set the abort timeout, but the kernel was older and did not support the ability to config that value. You can live without the feature. If it was fatal then we would have failed the login process. In newer version of the tools that log message is just removed so there is no confusion. Does MC/Serviceguard require lun reset support? > How to fix this ? > > Here's the target config, > Target iqn.2001-04.com.nethence:iscsi.lun0 > Lun 0 Path=/dev/sdb,Type=fileio > MaxConnections 9 > InitialR2T No > ImmediateData Yes > > Here's the initiator config (defaults on RHEL5.3), > node.startup = automatic > node.session.timeo.replacement_timeout = 120 > node.conn[0].timeo.login_timeout = 15 > node.conn[0].timeo.logout_timeout = 15 > node.conn[0].timeo.noop_out_interval = 5 > node.conn[0].timeo.noop_out_timeout = 5 > node.session.initial_login_retry_max = 4 > node.session.cmds_max = 128 > node.session.queue_depth = 32 > node.session.iscsi.InitialR2T = No > node.session.iscsi.ImmediateData = Yes > node.session.iscsi.FirstBurstLength = 262144 > node.session.iscsi.MaxBurstLength = 16776192 > node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 > discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768 > > Thank you > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
