FreeNAS - Bug #3221 - Bug Tracking System
Transcription
FreeNAS - Bug #3221 - Bug Tracking System
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 root@build.ixsystems.com:/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