The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on
04/13/2011 10:15:44 AM:
> From: Terry Wilson <terry.wil...@potashcorp.com>
> To: IBMVM@LISTSERV.UARK.EDU
> Date: 04/13/2011 10:19 AM
> Subject: Re: Cannot see SVC disk zLinux
> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
>
> Entered it manually and here is the info.
> command:
> zlinux1:/sys/bus/ccw/drivers/zfcp/0.0.5401 # lsscsi -g
> [0:0:1:1074479120]disk IBM 2107900 .280 /dev/sda
> /dev/sg0 >> 8300 disk works fine
> [1:0:2:49409]disk IBM 2145 0000 - /dev/
> sg1 >> new SVC DISK
>
> command:
> zlinux1:/sys/bus/ccw/drivers/zfcp/0.0.5401 # sg_luns /dev/sg1
> Report Luns command has bad field in cdb
>
> When zoning the LUNS the 8300 has zLinux as a valid unittype the SVCdoes
not.
Terry,
Aren't you referring to host connections, which is sometimes called lun
masking? Here we use type = generic when adding hosts on the SVC console.
Since the sg devices get created, I don't think there is a zoning problem.
Linux can obviously get to the target wwpn because it figured out that
there is a 2145 SVC there.
I think there is a problem with the hosts that were specified on the SVC
console. I tried to do lsluns with a channel that is unknown to our SVC
and got the same messages as you:
root@Laplace-4E15:lsluns -c 0.1.7900 -p 0x5005076801104bac
Scanning for LUNs on adapter 0.1.7900
at port 0x5005076801104bac:
Unable to send the REPORT_LUNS command to LUN.
I then configured the well known lun by hand, and also got the same
messages as you:
root@Laplace-4E15:sg_luns /dev/sg4
Report Luns command has bad field in cdb
So I ran it again with -v
root@Laplace-4E15:sg_luns -v /dev/sg4
report luns cdb: a0 00 00 00 00 00 00 00 20 00 00 00
report luns: Fixed format, current; Sense key: Illegal Request
Additional sense: Logical unit not supported
Info fld=0x0 [0]
Report Luns command has bad field in cdb
Those are the real error messages that I was hoping for!
Then someone here reminded me of scsi_logging_level. I guess I rely on
finisar traces too much to see all of bits crossing the fibre channel
links when I have problems. Anyway, "scsi_logging_level -s --all 7" will
turn on verbose messages in /var/log/messages. So running lsluns against
the troublesome SVC port gives this:
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530031] sg_open: dev=4,
flags=0x8802
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530046] sg_add_sfp:
sfp=0x00000000ec3ae000
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530050] sg_build_reserve:
req_size=32768
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530054] sg_build_indirect:
buff_size=32768, blk_size=32768
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530063] sg_build_indirect:
k=0, num=32768, ret_sz=32768
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530067] sg_build_indirect:
k_use_sg=1, rem_sz=0
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530071] sg_add_sfp:
bufflen=32768, k_use_sg=1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530125] sg_ioctl: sg4,
cmd=0x2285
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530129]
scsi_block_when_processing_errors: rtn: 1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530135] sg_common_write: scsi
opcode=0xa0, cmd_size=12
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530140] sg_start_req:
dxfer_len=8192
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530149] sg_link_reserve:
size=8192
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530174] scsi 0:0:11:49409:
[sg4] Send: 0x00000000fcac6c78
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530182] scsi 0:0:11:49409:
[sg4] CDB: Report luns: a0 00 00 00 00 00 00 00 20 00 00 00
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530210] buffer =
0x00000000fd2cd3b8, bufflen = 8192, queuecommand 0x000000000049948c
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530227] leaving
scsi_dispatch_cmnd()
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530410] scsi 0:0:11:49409:
[sg4] Done: 0x00000000fcac6c78 SUCCESS
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530418] scsi 0:0:11:49409:
[sg4] Result: hostbyte=DID_OK driverbyte=DRIVER_OK
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530425] scsi 0:0:11:49409:
[sg4] CDB: Report luns: a0 00 00 00 00 00 00 00 20 00 00 00
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530452] scsi 0:0:11:49409:
[sg4] Sense Key : Illegal Request [current]
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530461] Info fld=0x0
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530465] scsi 0:0:11:49409:
[sg4] Add. Sense: Logical unit not supported
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530475] scsi 0:0:11:49409:
[sg4] scsi host busy 1 failed 0
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530482] scsi 0:0:11:49409:
Notifying upper driver of completion (result 8000002)
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530487] 16 sectors total, 8192
bytes done.
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530497] sg_cmd_done: sg4,
pack_id=0, res=0x8000002
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530526] sg_finish_rem_req:
res_used=1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530536] sg_unlink_reserve:
req->k_use_sg=1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530590] sg_release: sg4
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530608] sg_remove_sfp:
bufflen=32768, k_use_sg=1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530612] sg_remove_scat:
k_use_sg=1
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530616] sg_remove_scat: k=0,
pg=0x000003e0033d0900
Apr 13 23:38:55 Laplace-4E15 kernel: [31575.530634] sg_remove_sfp: sg4,
sfp=0x00000000ec3ae000
Which is much easier than the manual procedure that I had you do.
Somewhere in the middle of the output there is the "illegal request"
status that you'd see with sg_luns -v.
I recommend that you double check the WWPNs in SVC. They should match the
"port_name" field when running "lszfcp -a -b 0.x.xxxx".
Regards,
Ray Higgs
System z FCP Firmware Development
Bld. 706, B42
2455 South Road
Poughkeepsie, NY 12601
(845) 435-8666, T/L 295-8666
rayhi...@us.ibm.com
