The following has be reported by IBM LTC: SCSI devices not being added, need procedure. RH106404 Hardware Environment: z990 Software Environment: RHEL-3 RC1 Steps to Reproduce: 1.install kernel-unsupported-2.4.21-3.EL.s390.rpm 2.Updated /etc/modules.conf with options scsi_mod max_scsi_luns=50 3.Updated /etc/zfcp.conf with: 0x104 0x01:0x5005076300c59572 0x00:0x5400000000000000 0x104 0x01:0x5005076300c59572 0x01:0x5401000000000000 0x104 0x01:0x5005076300c59572 0x02:0x5402000000000000 0x104 0x01:0x5005076300c59572 0x03:0x5403000000000000 4.issued: mkinitrd initrd-2.4.21-3.EL.img-2 2.4.21-3.EL 5.edit zipl.conf: changing ramdisk=/boot/initrd-2.4.21-3.EL.img to ramdisk=/boot/initrd-2.4.21-3.EL.img-2 6.issued: zipl 7.reboot 8.modprobe scsi_mod (** need additonal parameters?) 9.modprobe zfcp 10.lsmod Module Size Used by Not tainted zfcp 289860 0 (unused) scsi_mod 124192 1 [zfcp] autofs 13544 0 (autoclean) (unused) qeth 167988 1 qdio 40796 1 [zfcp qeth] af_packet 17868 0 (autoclean) ipt_REJECT 4712 1 (autoclean) ipt_state 1200 6 (autoclean) ip_conntrack 32320 1 (autoclean) [ipt_state] iptable_filter 2480 1 (autoclean) ip_tables 17664 3 [ipt_REJECT ipt_state iptable_filter] ext3 103188 3 jbd 59844 3 [ext3] dasd_fba_mod 6424 0 (unused) dasd_eckd_mod 64032 3 dasd_mod 64640 6 [dasd_fba_mod dasd_eckd_mod] 11.cat /etc/zfcp.conf > /proc/scsi/zfcp/add_map cat: write error: Input/output error 12.echo "scsi scan-new-devices" > /proc/scsi/scsi 13.cat /proc/scsi/scsi Attached devices: none Actual Results: Attached devices: none Expected Results: devices attached Additional Information:------ Additional Comments From mpeschke.com 2003-10-22 03:51 ------- Frank, sorry, should have thought of this a bit ealier: There is an issue in the SCSI mid-layer (scsi_mod.o) which inhibits dynamic addition of SCSI adapters. This is what needs to be done, if someone uses the add_map procfs-file in order to add a configuration with a new FCP adapter. We have provided a fix for the scsi_mod issue, but unfortunately have not yet managed to push it into the mainline kernel. Since RedHat is very cautious with fixes which do not come from www.kernel.org but third parties, they decided to leave this fix out for the time being. And looking for a way to ensure that nobody runs into that venturesome path in scsi_mod, they disabled add_map entirely. That's the crucial point here. Disabling that scsi_mod path has happened in agreement with us, although I'd prefer a different approach, which would make add_map only partially inoperative. This is described in bugzilla 106214 of which this entry should be a duplicate. It seems to be a bit unfortunate that the current disablement patch does not give a kernel message but quietly disregards any add_map input. However, our favourite solution is to get our scsi_mod patch integrated into the official kernel. I am preparing it for the 2.4.23-pre7 kernel. Hope to get it posted today or tomorrow. ------ Additional Comments From lefevre.com 2003-10-21 11:55 ------- Hi Martin, Thanks for the response. Website keeps hanging when attempting to attach the strace and debug script files. Will forward to your Notes id. I did specify my device configuration as zfcp module parameter. insmod zfcp map="0x104 0x01:0x5005076300c99572 0x00:0x5600000000000000 0x104 0x01:0x5005076300c99572 0x01:0x5601000000000000 0x104 0x01:0x5005076300c99572 0x02:0x5602000000000000 0x104 0x01:0x5005076300c99572 0x03:0x5603000000000000" I stopped at 4, could have added more. No problem here. Was attempting to add more via add_map, that's where the problem is. The only scsi related messages in /var/log/messages: Oct 21 08:51:13 rhel30 kernel: SCSI subsystem driver Revision: 1.00 Oct 21 08:51:18 rhel30 kernel: zfcp: zfcp_module_init: driver version 0x3009d At first I didn't believe the zfcp.o module was shipped with 64bit because it didn't find it when I issued modprobe. I found it and attempted to load it but receive the following error: insmod /lib/modules/2.4.21-4.EL/unsupported/drivers/s390/scsi/zfcp.o /lib/modules/2.4.21-4.EL/unsupported/drivers/s390/scsi/zfcp.o: kernel- module version mismatch /lib/modules/2.4.21-4.EL/unsupported/drivers/s390/scsi/zfcp.o was compiled for kernel version 2.4.21-4.EL while this kernel is version 2.4.21-3.EL. - ----- Additional Comments From mpeschke.com 2003-10-21 01:24 - ------ Skript that collects zSeries specific debug data ------ Additional Comments From mpeschke.com 2003-10-21 01:15 ------- Frank, could you strace the failing 'cat zfcp.conf > /proc/scsi/zfcp/add_map'? Would be interesting to know where this procedure fails. Furthermore, could you run the dbginfo.sh afterwards. I will attach this little skript (in case it's not distributed), which collects more (zSeries specific) debug data on live systems. You mentioned in your last comment that you were finally able to get 4 devices added by running insmod. Does this mean that you specified your device configuration as zfcp module parameter? Any other deviations that could give a hint? Seems strange that the fifth device and beyound could not be added successfully. Did you see any zfcp complaints in /var/log/messages about incorrect map entries? Your 4-device configuration looks fine to me, though. SCSI disks on a non-devfs system, such as RedHat, are christened /dev/sd*, e.g. your first disk is /dev/sda, its partitions are /dev/sda1 and so on. Detailed information can be found in the documentation of a linux source tree (Documentation/devices.txt) A lost zfcp module would be worth a seperate bugzilla entry. No zfcp.o in /lib/modules/<kernel-version>/kernel/drivers/s390/scsi? ------ Additional Comments From lefevre.com 2003-10-17 11:32 ------- I'm quite sure this is all procedural at this point. I have successfully loaded 4 devices via insmod zfcp. I am still unsuccessful when trying to add more devices using echo as defined in the device driver manual. Also, when NOT using devfs, what are the associated names in /dev? No scsi or sdx entries. Thanks. ------ Additional Comments From billgo.com 2003-10-17 10:17 ------- We can not complete our testing on time if we do not get some assistance with this problem! ------ Additional Comments From bjohnson 2004-01-05 12:07 ------- Did the patch mentioned by Martin ever make it upstream ? Added 12/18 entry from RedHat Bugzilla. Was unable to access LTC Bugzilla on that date. Hello. Installed RHEL-3 Update1 package and we're still experiencing problems when attempting to add scsi disk devices. Same results on both 31 and 64bit systems. We are following the process as described in the Device Driver and Installation Commands manual. [root@rhel30 root]# modprobe qdio [root@rhel30 root]# modprobe scsi_mod [root@rhel30 root]# insmod zfcp \ > map="0x104 0x01:0x5005076300c18154 0x0:0x570000000000000;\ > 0x104 0x01:0x5005076300c18154 0x1:0x570100000000000;\ > 0x104 0x01:0x5005076300c18154 0x2:0x570200000000000;\ > 0x104 0x01:0x5005076300c18154 0x3:0x570300000000000;\ > 0x104 0x01:0x5005076300c18154 0x4:0x570400000000000;\ > 0x104 0x01:0x5005076300c18154 0x5:0x570500000000000;\ > 0x104 0x01:0x5005076300c18154 0x6:0x570600000000000;\ > 0x104 0x01:0x5005076300c18154 0x7:0x570700000000000;\ > 0x104 0x01:0x5005076300c18154 0x8:0x570800000000000;\ > 0x104 0x01:0x5005076300c18154 0x9:0x570900000000000" Using /lib/modules/2.4.21-6.EL/kernel/drivers/s390/scsi/zfcp.o [root@rhel30 root]# modprobe sd_mod [root@rhel30 root]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: 2105F20 Rev: .293 Type: Unknown ANSI SCSI revision: 03 [root@rhel30 root]# cat /proc/scsi/zfcp/map 0x0104 0x00000001:0x5005076300c18154 0x00000000:0x0570000000000000 0x0104 0x00000001:0x5005076300c18154 0x00000001:0x0570100000000000 0x0104 0x00000001:0x5005076300c18154 0x00000002:0x0570200000000000 0x0104 0x00000001:0x5005076300c18154 0x00000003:0x0570300000000000 0x0104 0x00000001:0x5005076300c18154 0x00000004:0x0570400000000000 0x0104 0x00000001:0x5005076300c18154 0x00000005:0x0570500000000000 0x0104 0x00000001:0x5005076300c18154 0x00000006:0x0570600000000000 0x0104 0x00000001:0x5005076300c18154 0x00000007:0x0570700000000000 0x0104 0x00000001:0x5005076300c18154 0x00000008:0x0570800000000000 0x0104 0x00000001:0x5005076300c18154 0x00000009:0x0570900000000000 Messages in /var/log/messages: Dec 18 14:31:56 rhel30 kernel: zfcp: zfcp_module_init: driver version 0x3009d Dec 18 14:31:56 rhel30 kernel: scsi0 : zfcp Dec 18 14:31:56 rhel30 kernel: Starting timer : 0 0 Dec 18 14:31:56 rhel30 kernel: scsi: unknown type 31 Dec 18 14:31:56 rhel30 kernel: Vendor: IBM Model: 2105F20 Rev: .293 Dec 18 14:31:56 rhel30 kernel: Type: Unknown ANSI SCSI revision: 03 Dec 18 14:31:56 rhel30 kernel: Starting timer : 0 0 Dec 18 14:31:56 rhel30 kernel: resize_dma_pool: unknown device type 31 Thanks, Frank ------ Additional Comments From mpeschke.com 2004-01-07 13:06 ------- I have posted the patch twice to Marcello and linux-scsi without any response: http://marc.theaimsgroup.com/?l=linux-scsi&m=106708846520490&w=2 I could not find the patch in 2.4.25-pre4, but verified that it still applies smoothly. ------ Additional Comments From mpeschke.com 2004-01-09 16:00 ------- When comparing Frank's latest comments to his earlier problem description, I found a deviation in symptoms. Now, he seems to have a general problem with device detection, while device detection had worked when done in the context of loading modules. He has tried insmod .. and did not succeed this time. Thus, this particular issue is unrelated to the original problem. I suspect some setup problem, either wrong FCP_LUN in map, or incomplete Shark setup (LUN must be explicitely enabled for access by that host). Could you look over you setup? Sorry for not pointing you earlier into that direction. I have been on vacation. As for anything else, would be great to get the referred patch integrated. Hi Martin, you were right on. The lun definition on the insmod was missing a digit but the map showed all 16??? I was able to now see all the luns, created all the major and minor nodes, made a mdadm array of 38G and am running a file system thrasher against it. Looks good at this point. Thanks for the help.
please close, dup of 106404.
*** This bug has been marked as a duplicate of 106404 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.