Re: udev related issue with latest upstream bits
Mike Christie wrote: Or Gerlitz wrote: I think you said at some point this may happen if I use old udev bits, what version of udev you're using? 147. I do not have any udev wait_for_sysfs: waiting messages in my log so it looks like a udev issue. yep, using that udev version eliminated the errors and the lun appear without any delay. I still have the problem of the luns not being displayed by iscsiadm -m session -P 3, though. Now its a RHEL6 system and I noted that with the RHEL kernel that command does show the luns, I noted that there's a difference in the SYSFS related configs between the RHEL kernel and the way I build the upstream one, I assume this can explain the problem as you said, iscsiadm sysfs scanning isn't doing well with the _deprecated env, correct? Or. grep CONFIG_SYSFS /boot/config-2.6.32-71.el6.x86_64 # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_SYSFS=y grep CONFIG_SYSFS /home/ogerlitz/linux/linux-2.6.37-rc5/.config CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_SYSFS=y -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: qlogic hba: Could not offload sendtargets
On Sun, Dec 26, 2010 at 10:14:21AM -0800, Rudy Gevaert wrote: Hello, I'm trying to use a qlogic hba to do offloading. I don't fully understand anything. I am following the readme file. The following things aren't clear to me: 1) I get an extra interface (eth1). Should I give that interface an ip address? If I don't, I can't ping the target. What is this interface needed for? 2) I set an ip address on the iface reported by iscsiadm: r...@isis:/usr/share/doc/open-iscsi# iscsiadm -m iface default tcp,empty,empty,empty,empty iser iser,empty,empty,empty,empty qla4xxx.00:c0:dd:0e:e3:ad qla4xxx,00:c0:dd:0e:e3:ad,192.168.201.4,empty,empty r...@isis:/usr/share/doc/open-iscsi# iscsiadm -m iface -I qla4xxx.00:c0:dd:0e:e3:ad # BEGIN RECORD 2.0-871 iface.iscsi_ifacename = qla4xxx.00:c0:dd:0e:e3:ad iface.net_ifacename = empty iface.ipaddress = 192.168.201.4 iface.hwaddress = 00:c0:dd:0e:e3:ad iface.transport_name = qla4xxx iface.initiatorname = empty # END RECORD However, then discovery doesn't work: r...@isis:/usr/share/doc/open-iscsi# iscsiadm -m discovery -t st -p 192.168.201.200:3260 -I qla4xxx.00:c0:dd:0e:e3:ad iscsiadm: Could not offload sendtargets to 192.168.201.200. iscsiadm: initiator reported error (1 - unknown error) I'm running 2.6.32-5-xen-amd64 (Debian Squeeze) and 2.0.871.3-2squeeze1 of open-iscsi.. Any help in pointing me in the right direction is greatly appreciated. Did you configure the qla4xxx HBA using the qlogic tools? I don't think you can configure it using open-iscsi/iscsiadm .. -- Pasi -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: udev related issue with latest upstream bits
On 12/27/2010 04:20 AM, Or Gerlitz wrote: Mike Christie wrote: Or Gerlitz wrote: I think you said at some point this may happen if I use old udev bits, what version of udev you're using? 147. I do not have any udev wait_for_sysfs: waiting messages in my log so it looks like a udev issue. yep, using that udev version eliminated the errors and the lun appear without any delay. I still have the problem of the luns not being displayed by iscsiadm -m session -P 3, though. Now its a RHEL6 system and I noted that with the RHEL kernel that command does show the luns, I noted that there's a difference in the SYSFS related configs between the RHEL kernel and the way I build the upstream one, I assume this can explain the problem as you said, iscsiadm sysfs scanning isn't doing well with the _deprecated env, correct? Yeah, there is no sysfs linkage from the scsi_device/LUN to the block device that I can see, so I can find the logical unit number and its mapping to the host and target and bus numbers (the H:B:T:L info you see) but I do not know how to get the block device from it (Or I guess flipped around I can find the block devices but I cannot see how they are linked to the scsi_device/LUN). So I am not sure how to make the mapping. In older kernels there is a symlink or dir that links the two objects. Going to look at sg_map to see how it does it when I get some time. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: udev related issue with latest upstream bits
On 12/27/2010 07:09 PM, Mike Christie wrote: On 12/27/2010 04:20 AM, Or Gerlitz wrote: Mike Christie wrote: Or Gerlitz wrote: I think you said at some point this may happen if I use old udev bits, what version of udev you're using? 147. I do not have any udev wait_for_sysfs: waiting messages in my log so it looks like a udev issue. yep, using that udev version eliminated the errors and the lun appear without any delay. I still have the problem of the luns not being displayed by iscsiadm -m session -P 3, though. Now its a RHEL6 system and I noted that with the RHEL kernel that command does show the luns, I noted that there's a difference in the SYSFS related configs between the RHEL kernel and the way I build the upstream one, I assume this can explain the problem as you said, iscsiadm sysfs scanning isn't doing well with the _deprecated env, correct? Yeah, there is no sysfs linkage from the scsi_device/LUN to the block device that I can see, so I can find the logical unit number and its mapping to the host and target and bus numbers (the H:B:T:L info you see) but I do not know how to get the block device from it (Or I guess flipped around I can find the block devices but I cannot see how they I guess you can go from the block dir to the device (scsi_device/LUN) dir, but you cannot go from the device dir to the block dir. are linked to the scsi_device/LUN). So I am not sure how to make the mapping. In older kernels there is a symlink or dir that links the two objects. Going to look at sg_map to see how it does it when I get some time. It looks like sg_map cheats and does not look at sysfs for this. Will do one or the other. It looks like some sg_map26 commands are broken with your kernel config too now (sg_map26 uses sysfs where sg_map does not). -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
