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] [<ffffffff8103fb1b>] ? warn_slowpath_common+0x7b/0xc0 > [ 70.560484] [<ffffffff8103fc15>] ? warn_slowpath_fmt+0x45/0x50 > [ 70.566402] [<ffffffff81162975>] ? __xlate_proc_name+0x35/0xd0 > [ 70.572330] [<ffffffff81162d0b>] ? remove_proc_entry+0x25b/0x260 > [ 70.578434] [<ffffffff81094375>] ? registry_proc_callback+0x4b5/0x5c0 > [ 70.584963] [<ffffffff81093ec0>] ? registry_proc_callback+0x0/0x5c0 > [ 70.591330] [<ffffffff81055da7>] ? process_one_work+0x107/0x3c0 > [ 70.597351] [<ffffffff810564ac>] ? worker_thread+0x14c/0x410 > [ 70.603106] [<ffffffff81056360>] ? worker_thread+0x0/0x410 > [ 70.608678] [<ffffffff81059e25>] ? kthread+0x95/0xa0 > [ 70.613758] [<ffffffff81003fb4>] ? kernel_thread_helper+0x4/0x10 > [ 70.619857] [<ffffffff81059d90>] ? kthread+0x0/0xa0 > [ 70.624840] [<ffffffff81003fb0>] ? 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, > > > Thanks, > Thomas > _______________________________________________ Xenomai-help mailing list > [email protected] https://mail.gna.org/listinfo/xenomai-help -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
