Bug 113339 - LTC4703-SCSI devices not being added, need procedure. RH106404
LTC4703-SCSI devices not being added, need procedure. RH106404
Status: CLOSED DUPLICATE of bug 106404
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-release (Show other bugs)
3.0
s390 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-12 16:19 EST by Frank LeFevre
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:00:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Frank LeFevre 2004-01-12 16:19:09 EST
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@de.ibm.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@us.ibm.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@de.ibm.com  2003-10-21 01:24 -
------
 
Skript that collects zSeries specific debug data ------ Additional 
Comments From mpeschke@de.ibm.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@us.ibm.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@us.ibm.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@redhat.com  
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@de.ibm.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@de.ibm.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.
Comment 1 Frank LeFevre 2004-01-12 16:28:33 EST
please close, dup of 106404.
Comment 2 Tim Burke 2004-01-14 19:29:38 EST

*** This bug has been marked as a duplicate of 106404 ***
Comment 3 Red Hat Bugzilla 2006-02-21 14:00:43 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.