[Xenomai-help] removing Xenomai modules hangs system

[Xenomai-help] removing Xenomai modules hangs system

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

When I remove a skin module for the second time, my system hangs.  I get the
same results with Xenomai-2.5.5.2 and -2.5.6.  I get the same results
removing either xeno_rtdm and xeno_native the second time.  This problem
occurs if all I do is load and unload Xenomai modules, and never load other
modules, or start applications.  Hardware is Intel(R) Core(TM)2 Duo CPU .

xeno2:~ # modprobe -v xeno_rtdm
insmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
xenomai_gid=1000
insmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko

xeno2:~ # modprobe -v -r xeno_rtdm
rmmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
rmmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko

xeno2:~ # insmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
xenomai_gid=1000

xeno2:~ # insmod
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko

xeno2:~ # rmmod -v
/lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
rmmod xeno_rtdm, wait=no

<system hangs here>


Here's the kernel log before the hang:

[   56.244307] I-pipe: Domain Xenomai registered.
[   56.244363] Xenomai: hal/i386 started.
[   56.244389] Xenomai: scheduling class idle registered.
[   56.244393] Xenomai: scheduling class rt registered.
[   56.258394] Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
[   56.258400] Xenomai: debug mode enabled.
[   56.323052] Xenomai: SMI-enabled chipset found
[   56.323067] Xenomai: SMI workaround enabled
[   56.323116] Xenomai: starting RTDM services.
[   63.556015] Xenomai: stopping RTDM services.
[   63.606033] Xenomai: SMI configuration restored
[   63.608524] I-pipe: Domain Xenomai unregistered.
[   63.608529] Xenomai: hal/i386 stopped.
[   63.610270] Xenomai: real-time nucleus unloaded.
[  130.440143] I-pipe: Domain Xenomai registered.
[  130.440198] Xenomai: hal/i386 started.
[  130.440239] Xenomai: scheduling class idle registered.
[  130.440244] Xenomai: scheduling class rt registered.
[  130.453914] Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
[  130.453921] Xenomai: debug mode enabled.
[  143.967395] Xenomai: SMI-enabled chipset found
[  143.967411] Xenomai: SMI workaround enabled
[  143.967467] Xenomai: starting RTDM services.

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

Re: [Xenomai-help] removing Xenomai modules hangs system

[Gilles Chanteperdrix]

Jeff Weber wrote:
> xeno2:~ # rmmod -v
> /lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
> rmmod xeno_rtdm, wait=no

What is this "wait=no" ?

-- 
                                                                Gilles.

Re: [Xenomai-help] removing Xenomai modules hangs system

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Fri, Mar 11, 2011 at 1:19 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Jeff Weber wrote:
> > xeno2:~ # rmmod -v
> >
> /lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
> > rmmod xeno_rtdm, wait=no
>
> What is this "wait=no" ?
>
> I don't know.  When I run 'rmmod -v" the verbose reporting reveals that
rmmod is doing that on my behalf.

[-- Attachment #2: Type: text/html, Size: 758 bytes --]

Re: [Xenomai-help] removing Xenomai modules hangs system

[Gilles Chanteperdrix]

Jeff Weber wrote:
> On Fri, Mar 11, 2011 at 1:19 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Jeff Weber wrote:
>>> xeno2:~ # rmmod -v
>>>
>> /lib/modules/2.6.37.3-xeno-2.5.6-smp/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
>>> rmmod xeno_rtdm, wait=no
>> What is this "wait=no" ?
>>
>> I don't know.  When I run 'rmmod -v" the verbose reporting reveals that
> rmmod is doing that on my behalf.
> 
yeah, but the first time, you use modprobe -r, why using rmmod the
second time? how do we know that it is not using rmmod with wait=no
which causes the issue?

-- 
					    Gilles.