Am Mittwoch, 4. April 2012, 14:08:36 schrieb Nicholas A. Bellinger: > On Tue, 2012-04-03 at 08:56 +0200, Henning Becker wrote: > > Am Montag, 2. April 2012, 19:27:25 schrieben Sie: > > > On Sat, 2012-03-31 at 21:49 +0200, Henning Becker wrote: > > > > Hello, > > > > I'm using LIO iSCSI target on top of a pacemaker cluster, to provide a > > > > redundant replicated storage. > > > > > > > > I randomly get Kernel Oops in transport_free_dev_tasks, while moving > > > > the > > > > target from one node to the other. > > > > > > > > Kernel log says the following (Kernel 3.3.0-rc6): > > > > http://pastebin.com/tvm3tK7Z Another log (Kernel 3.2.0): > > > > http://pastebin.com/wMNER3We > > > > > > > > Distribution is Debian and it seems only to happen, if there is an > > > > iscsi > > > > connection. > > > > > > > > Any hints? > > > > > > Hello Henning, > > > > > > It would be helpful to know a bit more about the target configuration > > > that is triggering this bug, and what the cluster resource callbacks are > > > being invoked to individual /sys/kernel/config/target/iscsi/ endpoint > > > shutdown to perform the move.. > > > > Hello Nicholas, > > I've written an inotify log of /sys/kernel/config for you. It's here: > > http://pastebin.com/vNEe6vR5 > > Hi again Henning, > > Thanks for the setup info and the nice inotify log. > > > It seems, the Oops happens while disabling target (writing "0" to > > tpgt_1/enable) > > Ok, please verify if this session is attached to an explicit fabric > initiator NodeACL (iSCSI InitiatorName) configfs group, or attached to a > dynamically generated se_node_acl->acl_group using the TPG attrib > generate_node_acl=1 to allow 'demo mode' operation (eg: all initiators > can login to the endpoint)..? Hi Nicholas, thanks for your fast answer and sorry, that it took so long for me. I'm currently using demo mode without any NodeACL. Portal group is initiated with lio_node --permissive and write protection is disabled by writing 0 to attrib/demo_mode_write_protect. And yes, generate_node_acl is '1'. Should I test with ACLs enabled? Thanks, Henning > > > Configuration is nothing special. I'm using the pacemaker services > > iscsiLUN > > and iscsiTarget to configure my LUNs and my target. These services use > > lio_node to configure the target. (I'm using lio_node from GIT) > > > > The pacemaker config lines look like this: > > primitive iscsiLUNTest ocf:heartbeat:iSCSILogicalUnit \ > > > > params lun="0" path="/dev/ReplicatedStorage/Test" > > > > target_iqn="iqn.2012-04.lan.storage:iscsi.storage" > > primitive iscsiTarget1 ocf:heartbeat:iSCSITarget \ > > > > params iqn="iqn.2012-04.lan.storage:iscsi.storage" > > > > implementation="lio" portals="10.122.11.100:3260 10.122.13.100:3260" > > > > > I can think of one recent change for iscsi-target wrt to session > > > referencing counting that could be causing this type of regression in > > > lio-core.git HEAD and mainline v3.4-rc1, but I don't see how it would > > > effect v3.2.x stable code.. > > > > > > Is there anything else special about the work-load and/or configuration > > > required to trigger this bug you've noticed during in your testing..? > > > > I would say, there is nothing special. :-) > > Currently, there is no work load because the system is still in beta > > testing. I never used more than one iSCSI connection concurrently. > > > > I can reproduce the problem on this hardware as well as on my qemu virtual > > installation. > > > > And it seems, that I'm not the only one, who has this problem. Google has > > found this Pastebin http://pastebin.com/26k47QKp of a gentoo machine, > > showing a similar Kernel Oops. But I didn't figure out, to whom this bug > > belongs to. > Thanks for the additional pointer on this bug.. I have a few ideas > where to look, and will take a look at reproducing this soon. Please > let me know wrt to explict NodeACL vs. demo-mode TPG usage. ;) > > Thanks, > > --nab -- 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
