On Thu, 2013-05-09 at 16:29 -0700, Vishal Study wrote: > Hello LIO users, > > > This is my first time using LIO in kernel 3.4.x - running debian on > MIPS platform, and trying to play with Ramdisks (to start experiments > with)... The output of /proc/version to identify the specific kernel version would be helpful.. > > Following is what I'm doing: > Create a ramdisk, > > Create a target > add ramdisk to target > > > As soon as I issue the last command, I get crash... > I would think this is a supported feature, but not sure why its > crashing... > Any pointers greatly appreciated. > Thanks > Vishal. > root@mips:~# /etc/init.d/target start > > Loading target_core_mod/ConfigFS core: [OK] > > Calling ConfigFS script /etc/target/tcm_start.sh for target_core_mod: > [OK] > Calling ConfigFS script /etc/target/lio_start.sh for iscsi_target_mod: > [OK] > root@mips:~# > > root@mips:~# cd targetcli/ > > root@mips:~/targetcli# PYTHONPATH=. ./scripts/targetcli > > targetcli GIT_VERSION (rtslib GIT_VERSION) > > Copyright (c) 2011 by RisingTide Systems LLC. > > All rights reserved. > > Loaded iscsi_target_mod kernel module. > > Created '/sys/kernel/config/target/iscsi'. > > /> set global auto_cd_after_create=false > > Parameter auto_cd_after_create is now 'false'. > > /> cd backstores/ > > /backstores> rd_mcp/ create name=rd_backend size=1GB > > Generating a wwn serial. > > Created rd_mcp ramdisk rd_backend with size 1GB. > > > > /> iscsi/ info > > > Fabric module name: iscsi > > ConfigFS path: /sys/kernel/config/target/iscsi > > Supported WWN type: iqn > > Fabric module specfile: /var/target/fabric/iscsi.spec > Fabric module features: discovery_auth, acls, acls_auth, nps, tpgts > Corresponding kernel module: iscsi_target_mod > /> /iscsi create > Created target iqn.2003-01.org.linux-iscsi.mips.mips64:sn.7be0dd81ebd8. > Selected TPG Tag 1. > Successfully created TPG 1. > /> pwd > / > /> cd /iscsi/iqn.2003-01.org.linux-iscsi.mips.mips64:sn.7be0dd81ebd8/tpgt1/ > /iscsi/iqn.20...d81ebd8/tpgt1> luns/ create /backstores/rd_mcp/rd_backend > Selected LUN 0. > CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffffc009ce5c, > ra == ffffffffc00891e0 > Oops[#1]: > Cpu 0 > $ 0 : 0000000000000000 0000000010008ce1 ffffffffc009ce38 fffffffffeeddeef > $ 4 : 800000020c8e2478 80000002091b57c0 800000020926bc50 800000020926bc60 > $ 8 : 000000000000000a 800000020a223482 0000000000200200 8000000209312001 > $12 : 800000020a2cacb8 0000000000000001 8000000208762000 0000000000000000 > $16 : 800000020c8e2478 800000020c8e2478 800000020a8ae980 80000002091ecb70 > $20 : ffffffff805faf60 ffffffffc0088328 80000002091b57c0 0000000000000000 > $24 : 0000000000000002 ffffffff80370b88 > $28 : 8000000209268000 800000020926bd80 ffffffffc0089ab0 ffffffffc00891e0 > Hi : 0000000000000000 > Lo : 0000000000000000 > epc : ffffffffc009ce5c target_fabric_port_link+0x24/0x130 [target_core_mod] > Tainted: G C > ra : ffffffffc00891e0 configfs_symlink+0x178/0x420 [configfs] > Status: 10008ce3 KX SX UX KERNEL EXL IE > Cause : 00800008 > BadVA : 0000000000000000 > PrId : 000d9108 > Modules linked in: iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod > configfs ipv6 mips_ethernet at24 > > Any chance to backtrace this epc (target_fabric_port_link+0x24) in gdb..? Performing a fabric port_link is a typical operation, so I'd be leaning towards something about the manner in which these modules are being built. Is there anything non standard about the way that these modules are being built and or loaded..? --nab > > > Call Trace: > [<ffffffffc009ce5c>] target_fabric_port_link+0x24/0x130 [target_core_mod] > [<ffffffffc00891e0>] configfs_symlink+0x178/0x420 [configfs] > [<ffffffff8024a930>] vfs_symlink+0xa8/0xe0 > [<ffffffff8024dba4>] SyS_symlinkat+0xc4/0xe0 > [<ffffffff80151994>] handle_sys+0x174/0x198 -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
