Re: [Xenomai-help] rtnet / Xenomai: Kernel 2.6.19.1 hangs, 2.6.17.7 works

[Jan Kiszka <jan.kiszka@domain.hid>]

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

M. Koehrer wrote:
> Hi rtnet and Xenomai users,
> 
> I have an issue with the latest Xenomai (svn #1962) and rtnet (svn #1095) versions
> using kernel 2.6.19.1. The very same application worked fine on 2.6.17.7 (same Xenomai/rtnet).

/Might/ be an issue of the still fresh 2.6.19 patch. You are using
latest ipipe 1.6-02? Any difference with an earlier version of the
patch? Is the IRQ routing identical for both 2.6.19 and .17?

> My application does the following steps in user space:
> 1) I open one UDP socket to an embedded device.
> 2) The timeout of the socket is set to 5 seconds.
> 3) I send out one UDP message A via rt_dev_send() to the device.
> 4) Then I wait for the response for A in rt_dev_recv()
> 5) Directly after the return of rt_dev_recv() I send  message B via rt_dev_send()
> 6) Then I wait for the response for B in rt_dev_recv()
> Here my PC freezes. I am no longer able to access it, I have to press the reset button on the PC.
> 
> I have connected the PC and the embedded device with a hub. This allows me to monitor the network
> traffic using a second PC. Ethereal shows me, that message B is sent to the embedded device
> and the response of B is sent back to the PC.
> 
> Whenever I place a printf() directly after the rt_dev_recv() statements to see what happens,
> everything works fine and the PC no longer freezes.

printf causes a mode switch and certainly some delay that may let the
system avoid the race situation above.

> 
> As mentioned above, when I use the very same application with 2.6.17.7 (same Xenomai, rtnet version)
> everything is perfect!
> I have a Pentium 4 Dual core, SMP enabled.
> 
> Any idea on this strange behaviour?

Not directly.

OK, this is what you could try: Switch on the Xenomai watchdogs (soft
and NMI). Check if the NMI watchdog is working: boot log messages, maybe
even a test triggering via small /proc/xenomai/nmi_maxlat (we had
problems with it already on some other user's box, so some confirmation
the NMI works is useful). Then see if you system can at least issue some
oops on lock-up. Attach a serial console to grab it.

Beyond this test, could you also try with CONFIG_SMP switched off?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]