Am Dienstag, 10. April 2012, 23:54:06 schrieb Nicholas A. Bellinger: > On Mon, 2012-04-09 at 23:26 +0200, Henning Becker wrote: > > 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'. > Hi Henning, > > Thanks additional for the feedback on your setup. > > > Should I test with ACLs enabled? > > At this point I'm still thinking it's something to do with active I/O > shutdown with sessions attached to dynamic ACLs with demo-mode > (generate_node_acls=1) enabled.. Hi Nicholas, I have bad news. The problem just occured also with generate_node_acls=0. The Oops happend twice this time with slighty different stack traces. Perhaps, it can help you: http://pastebin.com/jpnuYxqV Henning > > Being able to verify if the issue is reproducible with Explict NodeACLs > for your setup would help me further isolate down the problem space. > > 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
