Date: Wed, 26 Sep 2012 11:33:57 +0300 From: Nikolay Denev <ndenev@gmail.com> To: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: CAM Target Layer, Linux and camcontrol readcap Message-ID: <057A94AC-3CBC-4E91-8816-74EE2E4C8420@gmail.com>
next in thread | raw e-mail | index | archive | help
Hi,
I'm running RELENG_9 and I'm trying to play with CTL.
Initially I've setup an isp(4) interface in TARGET mode and tried to =
export a LUN to a directly connected
Linux RHEL host, but for some reason that failed with the block backend =
(ramdisk was exported properly) :
This is how I export the volume :
zfs create -V1000G tank/oracle
ctladm create -b block -o file=3D/dev/zvol/tank/oracle -S ZFSSERIAL001 =
-d ZFSLUN001
ctladm port -o on
ctladm realsync off=20
camcontrol and ctladm show the device correctly :
[10:25]root@goliath:/home/ndenev# ctladm port -l =20
Port Online Type Name pp vp WWNN WWPN =
=20
0 YES IOCTL CTL ioctl 0 0 0 0 =
=20
1 YES INTERNAL ctl2cam 0 0 0x500000091a1f4700 =
0x500000091a1f4702
2 YES INTERNAL CTL internal 0 0 0 0 =
=20
3 YES FC isp0 0 0 0x20000024ff376b98 =
0x21000024ff376b98
4 YES FC isp1 1 0 0x20000024ff376b99 =
0x21000024ff376b99
[10:26]root@goliath:/home/ndenev# ctladm devlist -v
LUN Backend Size (Blocks) BS Serial Number Device ID =20
0 block 2097152000 512 ZFSSERIAL001 ZFSLUN001 =20
lun_type=3D0
num_threads=3D14
file=3D/dev/zvol/tank/oracle
[10:26]root@goliath:/home/ndenev# camcontrol devlist
<FREEBSD CTLDISK 0001> at scbus2 target 1 lun 0 (da0,pass0)
This is what I see on the Linux host for the exported zvol:
qla2xxx 0000:0a:00.1: LOOP UP detected (8 Gbps).
qla2xxx 0000:0a:00.1: qla2xxx_eh_host_reset: reset succeeded
qla2xxx 0000:0a:00.1: scsi(4:0:0): Abort command issued -- 1 c 2002.
sd 4:0:0:0: scsi: Device offlined - not ready after error recovery
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sdq : READ CAPACITY failed.
sdq : status=3D0, message=3D00, host=3D1, driver=3D00=20
sdq : sense not available.=20
sd 4:0:0:0: rejecting I/O to offline device
sdq: Write Protect is off
sdq: Mode Sense: 00 00 00 00
sd 4:0:0:0: rejecting I/O to offline device
sdq: asking for cache data failed
sdq: assuming drive cache: write through
sd 4:0:0:0: Attached scsi disk sdq
sd 4:0:0:0: Attached scsi generic sg18 type 0
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
sd 4:0:0:0: rejecting I/O to offline device
I've noticed the READ CAPACITY failed message and tried to issue a =
several "camcontrol readcap" commands,
but they got stuck and are now unkillable :
[10:21]root@goliath:/home/ndenev# ps axuw|grep cam
root 29739 0.0 0.0 16300 1628 0- DL+ 8:09AM 0:00.00 =
camcontrol readcap da0
root 30033 0.0 0.0 16300 1628 1- DL+ 8:12AM 0:00.00 =
camcontrol readcap 2:1:0
root 30135 0.0 0.0 16300 1632 2 D+ 8:21AM 0:00.00 =
camcontrol start pass0
procstat shows the same kernel stack for them :
[10:23]root@goliath.:/home/ndenev# procstat -kk 30033
PID TID COMM TDNAME KSTACK =
=20
30033 101161 camcontrol - mi_switch+0x186 =
sleepq_wait+0x42 _sleep+0x390 cam_periph_runccb+0x5a passioctl+0x171 =
devfs_ioctl_f+0x7b kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x546 =
Xfast_syscall+0xf7=20
Also there is this suspicious message on the FreeBSD machine :
cfcs_action: unsupported CCB type 0x918
Then I've tried to remove the volume from CTL but the command also got =
stuck :
[10:29]root@goliath:/home/ndenev# ps axuww|grep ctladm
root 54269 0.0 0.0 18484 1692 3 I 8:24AM 0:00.00 =
ctladm remove -b block -l 0
root 20969 0.0 0.0 16280 1720 5 S+ 10:30AM 0:00.00 grep =
ctladm
[10:30]root@goliath:/home/ndenev# procstat -kk 54269
PID TID COMM TDNAME KSTACK =
=20
54269 101580 ctladm - mi_switch+0x186 =
sleepq_catch_signals+0x2cc sleepq_wait_sig+0xc _sleep+0x2b9 =
ctl_be_block_ioctl+0x9aa ctl_ioctl+0x9e6 devfs_ioctl_f+0x7b =
kern_ioctl+0x115 sys_ioctl+0xfd amd64_syscall+0x546 Xfast_syscall+0xf7=20=
Some Linux mailing lists suggest that maybe a firmware upgrade on the =
Linux box can help, but
this does not explain the stuck readcap and ctladm commands.
Any ideas on how to debug this further are welcome.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?057A94AC-3CBC-4E91-8816-74EE2E4C8420>