Re: udev related issue with latest upstream bits
On 12/30/2010 02:16 AM, Or Gerlitz wrote: Mike Christie wrote: 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). yes, sg_map26 is very much broken indeed on my kernel... I wonder if this sysfs config is something we should worry about, specifically as RHEL6 isn't setting the _deprecated configs, are there other distros who does that? I do not know. We do not do it in Fedora either. -- 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
Mike Christie wrote: I do not know. We do not do it in Fedora either. okay, so I guess we'll leave it for that time being... Or. -- 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
Mike Christie wrote: 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). yes, sg_map26 is very much broken indeed on my kernel... I wonder if this sysfs config is something we should worry about, specifically as RHEL6 isn't setting the _deprecated configs, are there other distros who does that? Or. -- 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
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: 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.
Re: udev related issue with latest upstream bits
On 12/23/2010 02:05 PM, Or Gerlitz wrote: [...] you can see that the kernel scsi code detected the new scsi host (98) / lun on it and assigned the sdd device for that lun, but I can tell that this all happens only @ 16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11 If we both use the same .config is there anything else that can explain the difference? 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. -- 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
Mike Christie wrote: Do you mean the /dev/sdX's getting created or the kernel scsi scanning code detecting luns? I did not see either. Mike, from this log you can see that the kernel scsi code detected the new scsi host (98) / lun on it and assigned the sdd device for that lun, but I can tell that this all happens only @ 16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11 If we both use the same .config is there anything else that can explain the difference? are you sure you see the luns through sg_map -i -x when the iscsiadm login is done? Dec 23 16:07:11 cto-1 kernel: scsi98 : iSCSI Initiator over TCP/IP Dec 23 16:07:11 cto-1 kernel: scsi 98:0:0:0: RAID Voltaire vsa 1PQ: 0 ANSI: 5 Dec 23 16:07:11 cto-1 kernel: scsi 98:0:0:0: Attached scsi generic sg4 type 12 Dec 23 16:07:11 cto-1 kernel: scsi 98:0:0:1: Direct-Access Voltaire VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 Dec 23 16:07:11 cto-1 kernel: sd 98:0:0:1: Attached scsi generic sg5 type 0 Dec 23 16:07:11 cto-1 kernel: sd 98:0:0:1: [sdd] 2147483648 512-byte logical blocks: (1.09 TB/1.00 TiB) Dec 23 16:07:11 cto-1 kernel: sd 98:0:0:1: [sdd] Write Protect is off Dec 23 16:07:11 cto-1 kernel: sd 98:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 23 16:07:11 cto-1 kernel: sdd: unknown partition table Dec 23 16:07:11 cto-1 kernel: sd 98:0:0:1: [sdd] Attached SCSI disk Dec 23 16:07:11 cto-1 iscsid: connection92:0 is operational now Dec 23 16:07:14 cto-1 udevd-event[11497]: wait_for_sysfs: waiting for '/sys/devices/platform/host98/ioerr_cnt' failed Dec 23 16:07:18 cto-1 udevd-event[11521]: wait_for_sysfs: waiting for '/sys/devices/platform/host98/session92/target98:0:0/ioerr_cnt' faile see below the full log including the iscsi debug prints Or. Dec 23 16:07:11 cto-1 kernel: scsi98 : iSCSI Initiator over TCP/IP Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_mgmt_task mgmtpdu [op 0x3 hdr-itt 0x0 datalen 440] Dec 23 16:07:11 cto-1 kernel: session92: __iscsi_complete_pdu [op 0x23 cid 0 itt 0x0 len 300] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_complete_task complete task itt 0x0 state 3 sc (null) Dec 23 16:07:11 cto-1 kernel: session92: iscsi_free_task freeing task itt 0x0 state 1 sc (null) Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_scsi_cmd_pdu iscsi prep [read cid 0 sc 88020c027800 cdb 0x12 itt 0x1 len 36 bidi_len 0 cmdsn 1 win 1] Dec 23 16:07:11 cto-1 kernel: session92: __iscsi_complete_pdu [op 0x25 cid 0 itt 0x1 len 0] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_data_in_rsp data in with status done [sc 88020c027800 res 0 itt 0x1] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_complete_task complete task itt 0x1 state 3 sc 88020c027800 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_free_task freeing task itt 0x1 state 1 sc 88020c027800 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_scsi_cmd_pdu iscsi prep [read cid 0 sc 8801ebf48d00 cdb 0x12 itt 0x2 len 66 bidi_len 0 cmdsn 2 win 129] Dec 23 16:07:11 cto-1 kernel: session92: __iscsi_complete_pdu [op 0x25 cid 0 itt 0x2 len 0] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_data_in_rsp data in with status done [sc 8801ebf48d00 res 0 itt 0x2] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_complete_task complete task itt 0x2 state 3 sc 8801ebf48d00 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_free_task freeing task itt 0x2 state 1 sc 8801ebf48d00 Dec 23 16:07:11 cto-1 kernel: scsi 98:0:0:0: RAID Voltaire vsa 1PQ: 0 ANSI: 5 Dec 23 16:07:11 cto-1 kernel: scsi 98:0:0:0: Attached scsi generic sg4 type 12 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_scsi_cmd_pdu iscsi prep [read cid 0 sc 8801ec3a4100 cdb 0xa0 itt 0x3 len 4096 bidi_len 0 cmdsn 3 win 129] Dec 23 16:07:11 cto-1 kernel: session92: __iscsi_complete_pdu [op 0x25 cid 0 itt 0x3 len 0] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_data_in_rsp data in with status done [sc 8801ec3a4100 res 0 itt 0x3] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_complete_task complete task itt 0x3 state 3 sc 8801ec3a4100 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_free_task freeing task itt 0x3 state 1 sc 8801ec3a4100 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_scsi_cmd_pdu iscsi prep [read cid 0 sc 8801e7075200 cdb 0x12 itt 0x4 len 36 bidi_len 0 cmdsn 4 win 129] Dec 23 16:07:11 cto-1 kernel: session92: __iscsi_complete_pdu [op 0x25 cid 0 itt 0x4 len 0] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_data_in_rsp data in with status done [sc 8801e7075200 res 0 itt 0x4] Dec 23 16:07:11 cto-1 kernel: session92: iscsi_complete_task complete task itt 0x4 state 3 sc 8801e7075200 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_free_task freeing task itt 0x4 state 1 sc 8801e7075200 Dec 23 16:07:11 cto-1 kernel: session92: iscsi_prep_scsi_cmd_pdu
Re: udev related issue with latest upstream bits
[...] you can see that the kernel scsi code detected the new scsi host (98) / lun on it and assigned the sdd device for that lun, but I can tell that this all happens only @ 16:07:18 which is seven seconds --after-- the lun was detected @ 16:07:11 If we both use the same .config is there anything else that can explain the difference? I think you said at some point this may happen if I use old udev bits, what version of udev you're using? Or. -- 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/19/2010 06:38 AM, Or Gerlitz wrote: Mike Christie wrote: [...] I think in general the iscsi tools are using sysfs incorrectly. I think I need to use the sysfs code udev is using. Again, I'm more not less (...) worried from the original problem of the luns appearing with delay on the initiator node, I wonder if anyone else was hitting this problem as well? Do you mean the /dev/sdX's getting created or the kernel scsi scanning code detecting luns? I did not see either. -- 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
Mike Christie wrote: [...] I think in general the iscsi tools are using sysfs incorrectly. I think I need to use the sysfs code udev is using. Again, I'm more not less (...) worried from the original problem of the luns appearing with delay on the initiator node, I wonder if anyone else was hitting this problem as well? Or. -- 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/16/2010 01:24 AM, Or Gerlitz wrote: can it explain the delay in exposing the luns to the initiator scsi stack? Not sure what you mean exactly. The initiator will do iscsi login then scan for devices by doing echo - - - /sys/class/scsi_host/hostX/scan. The scsi layer handles this by doing inquirys and report luns commands. If it finds devices it creates the scsi_device kernel structs for the logical unit. So the kernel initaitor stack knows about the LUs right away and we should see them in sysfs. When the kernel creates the scsi_device struct and does a add on the kobject in the device struct in them, udev would see a hoplug event and handle this by making the /dev nodes. So a udev issue could slow down the creation of the /dev nodes. -- 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/15/2010 03:21 PM, Mike Christie wrote: # iscsiadm -m session -P 3 The iscsiadm -m session output does not rely on udev or anything that udev creates like the /dev nodes. iscsiadm just reads sysfs. The missing output could be due to a change in the sysfs layout again. Could you send me your kernel .config? Ah weird. If I added CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y and I can hit the iscsiadm -m session -P 3 problem. It is strange that we work with the new layout but not the old one for once. The iscsi_sysfs/sysfs.c code just needs a tweaking. Looking into it now. If you do not enable the depreciated settings it should work. -- 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/16/2010 07:01 PM, Mike Christie wrote: On 12/15/2010 03:21 PM, Mike Christie wrote: # iscsiadm -m session -P 3 The iscsiadm -m session output does not rely on udev or anything that udev creates like the /dev nodes. iscsiadm just reads sysfs. The missing output could be due to a change in the sysfs layout again. Could you send me your kernel .config? Ah weird. If I added CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y and I can hit the iscsiadm -m session -P 3 problem. It is strange that we work with the new layout but not the old one for once. The iscsi_sysfs/sysfs.c code just needs a tweaking. Looking into it now. If you do not enable the depreciated settings it should work. Hey, wait. If I am putting CONFIG_SYSFS_DEPRECATED=y does that mean that the sysfs layout should have the old layout and not change? -- 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.
udev related issue with latest upstream bits
Hi Mike, With kernel 2.6.37-rc5 (the latest upstream release) I see some udev related issue, when doing login (I'm using iscsi-initiator-utils-6.2.0.871-0.16.el5), the following appears in the system logs udevd-event[12383]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/ioerr_cnt' failed udevd-event[12409]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/session16/target18:0:0/ioerr_cnt' failed practically what happens is that it takes some extra time for the luns to appear after the login, but I wasn't sure if/what is the problem, maybe my udev (udev-095-14.21.el5_5.1) is too old for this kernel? when doing iscsidadm -m session -P 3 the luns are printed empty, e.g see the below, note that since the target is tgt we don't expect any disk for lun zero, but lun one has a disk associated with it as you can see from the sg_map output Attached SCSI devices: Host Number: 18 State: running scsi18 Channel 00 Id 0 Lun: 0 scsi18 Channel 00 Id 0 Lun: 1 # sg_map -i -x [...] /dev/sg4 18 0 0 0 12 Voltaire vsa 1 /dev/sg5 18 0 0 1 0 /dev/sdd Fio FS3-202-161-ES 1.0 Dec 15 16:28:58 cto-1 kernel: scsi18 : iSCSI Initiator over TCP/IP Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:0: RAID Voltaire vsa 1PQ: 0 ANSI: 5 Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:0: Attached scsi generic sg4 type 12 Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:1: Direct-Access Fio FS3-202-161-ES 1.0 PQ: 0 ANSI: 5 Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: Attached scsi generic sg5 type 0 Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] 155175680 512-byte logical blocks: (79.4 GB/73.9 GiB) Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Write Protect is off Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 15 16:28:58 cto-1 kernel: sdd: unknown partition table Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Attached SCSI disk Dec 15 16:28:59 cto-1 iscsid: connection16:0 is operational now Dec 15 16:29:02 cto-1 udevd-event[12383]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/ioerr_cnt' failed Dec 15 16:29:06 cto-1 udevd-event[12409]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/session16/target18:0:0/ioerr_cnt' failed # iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 2.0-871 Target: iqn.nsg2 Current Portal: 192.168.20.222:3260,1 Persistent Portal: 192.168.20.222:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.1994-05.com.redhat:f5f051c97f8 Iface IPaddress: 192.168.20.1 Iface HWaddress: (null) Iface Netdev: (null) SID: 16 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 8192 FirstBurstLength: 65536 MaxBurstLength: 262144 ImmediateData: Yes InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 18 State: running scsi18 Channel 00 Id 0 Lun: 0 scsi18 Channel 00 Id 0 Lun: 1 # iscsiadm -m session -P 3 -d 8191 [...] Attached SCSI devices: iscsiadm: sysfs_device_get: open '/class/iscsi_session/session16' iscsiadm: sysfs_resolve_link: path link '/class/iscsi_session/session16' points to '../../devices/platform/host18/session16/iscsi_session/session16' iscsiadm: sysfs_resolve_link: base '/class/iscsi_session/session16', tail 'devices/platform/host18/session16/iscsi_session/session16', back 2 iscsiadm: sysfs_resolve_link: after moving back '' iscsiadm: sysfs_device_get: found in cache '/devices/platform/host18/session16/iscsi_session/session16' iscsiadm: sysfs_device_get_parent: open '/devices/platform/host18/session16/iscsi_session/session16' iscsiadm: sysfs_device_get_parent: open '/devices/platform/host18/session16/iscsi_session' iscsiadm: sysfs_device_get_parent: open '/devices/platform/host18/session16' iscsiadm: sysfs_attr_get_value: open '/class/scsi_host/host18'/'state' iscsiadm: sysfs_attr_get_value: new uncached attribute '/sys/class/scsi_host/host18/state' iscsiadm: sysfs_attr_get_value: add to cache
Re: udev related issue with latest upstream bits
On 12/15/2010 08:47 AM, Or Gerlitz wrote: Hi Mike, With kernel 2.6.37-rc5 (the latest upstream release) I see some udev related issue, when doing login (I'm using iscsi-initiator-utils-6.2.0.871-0.16.el5), the following appears in the system logs udevd-event[12383]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/ioerr_cnt' failed udevd-event[12409]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/session16/target18:0:0/ioerr_cnt' failed practically what happens is that it takes some extra time for the luns to appear after the login, but I wasn't sure if/what is the problem, maybe my udev (udev-095-14.21.el5_5.1) is too old for this kernel? when doing iscsidadm -m session -P 3 the luns are printed empty, e.g see the below, note that since the target is tgt we don't expect any disk for lun zero, but lun one has a disk associated with it as you can see from the sg_map output Attached SCSI devices: Host Number: 18 State: running scsi18 Channel 00 Id 0 Lun: 0 scsi18 Channel 00 Id 0 Lun: 1 # sg_map -i -x [...] /dev/sg4 18 0 0 0 12 Voltaire vsa 1 /dev/sg5 18 0 0 1 0 /dev/sdd Fio FS3-202-161-ES 1.0 Dec 15 16:28:58 cto-1 kernel: scsi18 : iSCSI Initiator over TCP/IP Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:0: RAID Voltaire vsa 1PQ: 0 ANSI: 5 Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:0: Attached scsi generic sg4 type 12 Dec 15 16:28:58 cto-1 kernel: scsi 18:0:0:1: Direct-Access Fio FS3-202-161-ES 1.0 PQ: 0 ANSI: 5 Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: Attached scsi generic sg5 type 0 Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] 155175680 512-byte logical blocks: (79.4 GB/73.9 GiB) Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Write Protect is off Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dec 15 16:28:58 cto-1 kernel: sdd: unknown partition table Dec 15 16:28:58 cto-1 kernel: sd 18:0:0:1: [sdd] Attached SCSI disk Dec 15 16:28:59 cto-1 iscsid: connection16:0 is operational now Dec 15 16:29:02 cto-1 udevd-event[12383]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/ioerr_cnt' failed Dec 15 16:29:06 cto-1 udevd-event[12409]: wait_for_sysfs: waiting for '/sys/devices/platform/host18/session16/target18:0:0/ioerr_cnt' failed # iscsiadm -m session -P 3 The iscsiadm -m session output does not rely on udev or anything that udev creates like the /dev nodes. iscsiadm just reads sysfs. The missing output could be due to a change in the sysfs layout again. Could you send me your kernel .config? The other udev messages could also be caused by a older udev and a sysfs change. -- 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
Mike Christie wrote: Could you send me your kernel .config? Yes I do The other udev messages could also be caused by a older udev and a sysfs change can it explain the delay in exposing the luns to the initiator scsi stack? Or. -- 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.
