1. No category

FreeNAS 9 - Bug #3221
cam target layer - fc block targets reboot freenas & da(4) not attaching to ctl2cam0 bus
09/27/2013 06:48 PM - Richard Host
Status:
Priority:
Assignee:
Category:
Target version:
Seen in:
Description
Closed
Start date:
Alexander Motin
% Done:
Due date:
No priority
Estimated time:
9.2.1-RELEASE
09/26/2013
0%
0.00 hour
9.2.0-RELEASE
Reference posts on forums.freenas.org: http://forums.freenas.org/threads/fc-target-support-in-freenas-9-1-0.14139/
da(4) driver not attaching to ctl2cam0 bus
http://freebsdfoundation.blogspot.co.uk/2012/01/cam-target-layer.html
camcontrol devlist -v
scbus8 on ctl2cam0 bus 0:
<FREEBSD CTLDISK 0001>
at scbus8 target 1 lun 0 (pass4)
freenas reboots and error messages when trying to format a fc target.
ctladm port -o on
ctladm realsync off
ctladm create -b ramdisk -s 5368709120
/var/log/messages
(7:1:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device
(7:1:0:0): 10485760 blocks, blocksize 512
Add LUN to Windows Server 2012, I can bring it online but can't format.
ctladm create -b block -o file=/mnt/home/fc/esxi-fc -S ZFSSERIAL01 -d ZFSLUN001
/var/log/messages
(7:1:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device
(7:1:0:0): 209715200 blocks, blocksize 512
camcontrol devlist -v
<FREEBSD CTLDISK 0001>
at scbus9 target 1 lun 0 (pass10)
I Rescan storage in windows, then try and format the disk. It fails with the following error in /var/log/messages
(0:2:0:0): MODE SENSE. CDB: 1a 00 1c 00 c0 00
(0:2:0:0): Tag: 0x11cd88, Type: 1
(0:2:0:0): CTL Status: SCSI Error
(0:2:0:0): SCSI Status: Check Condition
(0:2:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(0:2:0:0): Command byte 2 bit 5 is invalid
History
07/07/2015
1/5
#1 - 09/27/2013 06:52 PM - Richard Host
Title states system reboots using block targets, this did not happen in my 9.1.1-RELEASE tests.
#2 - 09/27/2013 07:07 PM - Anonymous
The MODE SENSE error is just indicating that CTL does not support Mode Page 0x1c (Informational Exceptions Control). This is advisory only as that
page is not required to be present. I doubt it is related to why your Windows system is having access issues with the device.
Based on what data I can find the only relevant field on that modepage has to do with if the SATA SMART command set is support and if so how the
results are returned. CTL does not support SMART so it makes sense that this page would not be present.
da(4) would also not attach to a CTL device as that would be nonsensical -- CTL devices are designed to be exported off the system via a userspace
daemon, not for creating internal synthetic devices. If you need to create a RAM disk or a file-backed synthetic disk device then use mdconfig(8).
#3 - 10/10/2013 08:48 PM - Josh Paetzel
- Category set to 18
- Assignee set to Alexander Motin
Sasha, do you concur?
#4 - 10/11/2013 11:58 AM - Alexander Motin
I agree with Doug about MODE SENSE error. CTL doesn't support that page, but that is not very surprising since it controls reaction of the device on
predicted and background errors, which CTL probably don't have.
What's about missing daX devices for CTL, the answer is simple: When `ctladm port -o on` command initiated ctl2cam0 bus rescan, there was no any
LUN configured yet. So on CAM attempt to probe LUN 0 CTL reported that "LUN is not supported". Later, when LUN was finally created, there were
nobody to trigger rescan. So either LUNs should be configured before enabling port, or you should run `camcontrol rescan all` after configuring new
LUNs to detect them. BTW, try to rescan devices on Windows side too, may be problem is the same, but handled wrong?
What's about reboots, I've only recently got some FC hardware and had no chance to experiment much yet. But I am going to get to it. Otherwise
without additional information I can't say anything.
#5 - 10/11/2013 12:07 PM - Alexander Motin
By the way, AFAIK "ramdisk" backend is not a real disk. It has no space to store all the data. It just tells "OK, done" for any request. It is good for raw
I/O testing, but won't work for any real use or may be even formatting.
#6 - 10/24/2013 08:06 PM - Alexander Motin
- Status changed from Unscreened to Investigation
#7 - 01/20/2014 03:46 PM - Richard Host
Updated to 9.2.0-Release
I put a Brocade Silkworm 200E between my FreeNAS installation and test ESXi host.
07/07/2015
2/5
New zvol (100G) - home/fc-test
ctladm create -b block -o file=/dev/zvol/home/fc-test -S ZFSSERIAL001 -d ZFSLUN001
LUN created successfully
backend:
block
device type: 0
LUN size:
107374182400 bytes
blocksize
512 bytes
LUN ID:
0
Serial Number: ZFSSERIAL001
Device ID;
ZFSLUN001
ctladm realsync off
ctladm port -o on
Front End Ports enabled
Try to format disk in ESXi - freenas crashes
#8 - 01/20/2014 04:45 PM - Alexander Motin
- Seen in changed from 9.1.1-RELEASE to 9.2.0-RELEASE
Could you please provide detailed information about the crash? You should probably be able to find it after reboot in /var/crash.
From the performance point now it may be better to use file on dataset then zvol. zvol performance should improve later, probably in 10.x version.
#9 - 01/20/2014 05:02 PM - Richard Host
Crash Symptoms as observed.
1. Network connectivity fails to respond.
2. iSCSI failes to respond.
3. server reboots...
Nothing in /var/crash
- file called minfree has "2048" .... **edit.
Nothing in /var/log/messages (other than boot info)
#10 - 01/20/2014 07:59 PM - Richard Host
jpaetzel sent me to /data/crash/
@
(ctl0:isp0:0:0:0): Target Mode not enabled yet- lun enable deferred
(ctl1:isp1:0:0:0): Target Mode not enabled yet- lun enable deferred
(7:1:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device
(7:1:0:0): 209715200 blocks, blocksize 512
(ctl2:isp0:0:-1:-1): Target Mode not enabled yet- lun enable deferred
07/07/2015
3/5
da11 at ctl2cam0 bus 0 scbus7 target 1 lun 0
da11: <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device
da11: 800.000MB/s transfers WWNN 0x50000005af336300 WWPN 0x50000005af336304 PortID 0x3
da11: Command Queueing enabled
da11: 102400MB (209715200 512 byte sectors: 255H 63S/T 13054C)
ctlfe_onoffline: isp0 current WWNN 0x20000024ff24380c
ctlfe_onoffline: isp0 current WWPN 0x21000024ff24380c
ctlfe_onoffline: SIM isp0 (path id 0) target enable succeeded
(ctl3:isp1:0:-1:-1): Target Mode not enabled yet- lun enable deferred
ctlfe_onoffline: isp1 current WWNN 0x20000024ff24380d
ctlfe_onoffline: isp1 current WWPN 0x21000024ff24380d
(1:3:1:0): MODE SENSE. CDB: 1a 00 1c 00 40 00
(1:3:1:0): Tag: 0x003d, Type: 1
(1:3:1:0): CTL Status: SCSI Error
(1:3:1:0): SCSI Status: Check Condition
ctlfe_onoffline: SIM isp1 (path id 1) target enable succeeded
(1:3:1:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(1:3:1:0): Command byte 2 bit 5 is invalid
ctlfeasync: WWPN 0x10000000c9733265 port 0x010500 path 1 target 0 arrived
ctlfeasync: WWPN 0x21fd00051e0a12ff port 0xfffc01 path 1 target 1 arrived
ctlfeasync: WWPN 0x21fd00051e0a12ff port 0xfffc01 path 1 target 1 left
(0:5:0:0): INQUIRY. CDB: 12 01 b0 00 40 00
(0:5:0:0): Tag: 0x1140cc, Type: 1
(0:5:0:0): CTL Status: SCSI Error
(0:5:0:0): SCSI Status: Check Condition
(0:5:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(0:5:0:0): Command byte 2 is invalid
(ctl1:isp1:0:0:0): ctlfedone: tag 0x0000 done len 17408 > total 0 sent 0
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x0
fault code
instruction pointer
= supervisor read instruction, page not present
= 0x20:0x0
stack pointer
= 0x28:0xffffff8000371ae0
frame pointer
= 0x28:0xffffff8000371b30
code segment
= base 0x0, limit 0xfffff, type 0x1b
processor eflags
= interrupt enabled, resume, IOPL = 0
current process
= 12 (swi2: cambio)
= DPL 0, pres 1, long 1, def32 0, gran 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^version.txt^^^^^^^^^^^^^^^^^^^^^^^FreeBSD 9.2-RELEASE #0 r+2315ea3: Fri Dec 20c 12:48:50 PST 2013
[email protected]:/tank/home/jkh/checkout/freenas/os-base/amd64/tank/home/jkh/checkout/freenas/FreeBSD/src/sys/FREENAS.amd64
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^$
@
#11 - 01/20/2014 09:14 PM - Josh Paetzel
Can you attach the whole crash from /data/crash please?
#12 - 01/20/2014 09:23 PM - Richard Host
- File textdump.tar.zip added
07/07/2015
4/5
Attached all files from /data/crash
.5 was Last
#13 - 01/21/2014 07:49 AM - Joshoa Alex
Hi
I am experiencing the same problem.
I did a tests on almost all version available - no luck.
My test bed looks like this - FreeNas <-> Linux Ubuntu (Server)
I have 4 different types of FC adapters, and i did a tests on all of them - same result.
But here some useful info:
When i did all the preparation and presented LUN over FC - Linux box sees it.
I did [dd if=/dev/sdb of=/dev/zero] on Linux client - it reads, no errors.
But, when i did [dd if=/dev/sdb of=/home/joshoa/raw.img] - it reads ok, size ok, but file contains GARBAGE.
It looks to me that the read process is actually read some random stuff from RAM.
I saw pieces of my FreeNAS log file there.
When i am trying to WRITE [dd if=/dev/zero of=/dev/sdb] - system crashes immediately.
And i did my test with [ctladm port -o on] and [ctladm port -o on -t fc] - no changes.
And i removed FC adapter from system and created LUN - i was able to see the new /dev/adaX, and i was able to READ/WRITE it.
J
#14 - 01/22/2014 12:10 AM - Alexander Motin
I've merged number of bug fixes for CAM and CTL from FreeBSD. Some of them looked bad enough. You could try to test it on some nightly build in
couple days.
#15 - 01/26/2014 12:24 AM - Jordan Hubbard
- Target version set to 9.2.1-RELEASE
#16 - 01/29/2014 08:00 PM - Joshoa Alex
Hi
Tested it out on 9.2.1 RC1 - works!
Looks like it is OK now.
J
#17 - 01/29/2014 08:09 PM - Alexander Motin
- Status changed from Investigation to Resolved
#18 - 02/09/2014 01:46 PM - Jordan Hubbard
- Status changed from Resolved to Closed
Files
textdump.tar.zip
07/07/2015
114 KB
01/21/2014
Richard Host
5/5