Hi, ---------------------------------------- > From: [email protected] > To: [email protected] > Date: Sun, 15 May 2011 17:32:59 +0200 > CC: [email protected] > Subject: Re: [Xenomai-help] Problems with rt pipes after upgrade > > On Sun, 2011-05-15 at 17:26 +0200, Jan Kiszka wrote: > > On 2011-05-15 17:21, Philippe Gerum wrote: > > > On Sat, 2011-05-14 at 19:25 +0200, Gilles Chanteperdrix wrote: > > >> On 05/14/2011 07:21 PM, Gilles Chanteperdrix wrote: > > >>> On 05/14/2011 12:39 AM, Thomas Schaefer wrote: > > >>>> > > >>>> Hello, > > >>>> > > >>>> ---------------------------------------- > > >>>>> Subject: Re: [Xenomai-help] Problems with rt pipes after upgrade > > >>>>> From: [email protected] > > >>>>> To: [email protected] > > >>>>> CC: [email protected] > > >>>>> Date: Fri, 13 May 2011 12:26:26 +0200 > > >>>>> > > >>>>> On Wed, 2011-05-11 at 07:46 -0700, Thomas Schaefer wrote: > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> we are currently running an earlier version of Xenomai (2.5.3) on a > > >>>>>> Quad core Xeon with kernel 2.6.31.8(X86_64). > > >>>>>> I was looking into upgrading to the latest Xenomai version from the > > >>>>>> git head and kernel 2.6.37.6. > > >>>>>> Everything seems to work well except creating rt_pipes in the kernel > > >>>>>> driver. > > >>>>>> First I thought this is a problem with our PCIe driver but I see the > > >>>>>> same problem when loading xeno_klat. > > >>>>>> > > >>>>>> # modprobe xeno_klat > > >>>>>> [ 70.511784] ------------[ cut here ]------------ > > >>>>>> [ 70.516422] WARNING: at fs/proc/generic.c:860 > > >>>>>> remove_proc_entry+0x25b/0x260() > > >>>>>> [ 70.523556] Hardware name: D-Mitri > > >>>>>> [ 70.526960] remove_proc_entry: removing non-empty directory > > >>>>>> 'native/pipes', leaking at least 'klat_pipe' > > >>>>>> [ 70.536433] Modules linked in: xeno_klat bonding [last unloaded: > > >>>>>> scsi_wait_scan] > > >>>>>> [ 70.545910] Pid: 296, comm: kworker/1:1 Not tainted 2.6.37.6 #4 > > >>>>>> [ 70.551834] Call Trace: > > >>>>>> [ 70.554291] [] ? warn_slowpath_common+0x7b/0xc0 > > >>>>>> [ 70.560484] [] ? warn_slowpath_fmt+0x45/0x50 > > >>>>>> [ 70.566402] [] ? __xlate_proc_name+0x35/0xd0 > > >>>>>> [ 70.572330] [] ? remove_proc_entry+0x25b/0x260 > > >>>>>> [ 70.578434] [] ? registry_proc_callback+0x4b5/0x5c0 > > >>>>>> [ 70.584963] [] ? registry_proc_callback+0x0/0x5c0 > > >>>>>> [ 70.591330] [] ? process_one_work+0x107/0x3c0 > > >>>>>> [ 70.597351] [] ? worker_thread+0x14c/0x410 > > >>>>>> [ 70.603106] [] ? worker_thread+0x0/0x410 > > >>>>>> [ 70.608678] [] ? kthread+0x95/0xa0 > > >>>>>> [ 70.613758] [] ? kernel_thread_helper+0x4/0x10 > > >>>>>> [ 70.619857] [] ? kthread+0x0/0xa0 > > >>>>>> [ 70.624840] [] ? kernel_thread_helper+0x0/0x10 > > >>>>>> [ 70.630941] ---[ end trace 793ec26c5b485748 ]--- > > >>>>>> > > >>>>>> > > >>>>>> I would appreciate if someone could point me in the right direction > > >>>>>> of the possible cause. > > >>>>> > > >>>>> This very much looks like a race in the registry support. We have to > > >>>>> resync registry object deletion done from primary mode with the linux > > >>>>> kernel actually doing the work for us (via /procfs), and somehow, we > > >>>>> don't do this right. This is not a critical issue and will likely not > > >>>>> break your platform, but this is still quite ugly, and requires a fix. > > >>>>> > > >>>>> Could you give us some hints about how to reproduce this easily? TIA, > > >>>>> > > >>>> > > >>>> I used VBox and installed a very basic Debian squeeze with the > > >>>> netinst.iso. > > >>>> Installed our kernel into it from the debian package I created and > > >>>> copied xeno_klat.ko to it. > > >>>> Running insmod xeno_klat.ko shows the same symptom. > > >>> > > >>> xeno_klat insmods here without any problem. You probably have some > > >>> debugging option enabled. Could your post the .config of the kernel you > > >>> use? > > >>> > > >> > > >> I enabled approximately all debugging options. Now I reproduce this bug. > > >> > > >> > > > > > > Ok, I introduced this one. Two bugs in one actually, here are the fixes: > > > > > > diff --git a/ksrc/nucleus/vfile.c b/ksrc/nucleus/vfile.c > > > index d8ac398..6aa42b3 100644 > > > --- a/ksrc/nucleus/vfile.c > > > +++ b/ksrc/nucleus/vfile.c > > > @@ -752,8 +752,10 @@ int xnvfile_init_link(const char *from, > > > > > > ppde = parent->entry.pde; > > > pde = proc_symlink(from, ppde, to); > > > - if (vlink->entry.pde == NULL) > > > + if (pde == NULL) { > > > + remove_proc_entry(pde->name, ppde); > > > > Sure? :) > > This one should be better. > > diff --git a/ksrc/nucleus/vfile.c b/ksrc/nucleus/vfile.c > index d8ac398..4898e86 100644 > --- a/ksrc/nucleus/vfile.c > +++ b/ksrc/nucleus/vfile.c > @@ -752,7 +752,7 @@ int xnvfile_init_link(const char *from, > > ppde = parent->entry.pde; > pde = proc_symlink(from, ppde, to); > - if (vlink->entry.pde == NULL) > + if (pde == NULL) > return -ENOMEM; > > vlink->entry.parent = parent; > > > > > Jan > > > > > return -ENOMEM; > > > + } > > > > > > vlink->entry.parent = parent; > > > vlink->entry.pde = pde; > > > > > > > -- > Philippe. > Thank you very much. This seems to have fixed the problem. Thomas
> > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
