RTEMS Network Stack and Managed Switch

[Joel Sherrill]

On Thu, Oct 8, 2020 at 10:25 AM Thomas Doerfler <
Thomas.Doerfler at imd-systems.de> wrote:

> Richard,
>
> what hardware/BSP are you running on?
>

Thomas beat me on this. :)

Also the RTEMS version and network stack (legacy vs libbsd).

>
> Just a shot in the dark: It seems the system crashes in arplookup -> ...
> -> svfprintf. Can it be that some networking routine tries to print a
> message with floating point, but the FPU is disabled for the
> corresponding task?
>

Since I recall you are using a LEON, this is indeed a very likely culprit.

The stack trace is a bit odd since nothing in libc would call _Internal_XXX.

--joel

>
> wkr,
>
> Thomas.
>
> Am 08.10.20 um 17:15 schrieb Richard.Glossop at L3Harris.com:
> > We have discovered a problem with the RTEMS network stack reaching the
> > RTEMS _Terminate function when the interfaces are attached to a managed
> > switch (in this case a Cisco 3560).
> >
> >
> >
> > This does not occur with direct connections or when attached to a layer
> > 2 unmanaged switch (NetGear or SMC).  Of course the 3560 puts out a lot
> > of traffic that a layer 2 switch does not (spanning tree, CDP etc….)
> >
> >
> >
> > So it seems the managed switch is putting out traffic that is bringing
> > RTEMS down.
> >
> >
> >
> > Has anyone seen this behavior?  Have you determined the root cause?
> >
> >
> >
> >
> >
> > I set a break point and caught the following backtrace:
> >
> >
> >
> >   #0   0x6006ec90   0x60200180   <_Terminate+0x4>
> >
> >   #1   0x6006ece0   0x602001e8   <_Internal_error+0x8>
> >
> >   #2   0x600da250   0x60200248   <_svfprintf_r+0x14>
> >
> >   #3   0x600d5810   0x60200420   <snprintf+0x58>
> >
> >   #4   0x60073bac   0x60200508   <inet_ntop4+0x24>
> >
> >   #5   0x60073e70   0x60200580   <inet_ntop+0x280>
> >
> >   #6   0x60073b78   0x60200630   <inet_ntoa_r+0x1c>
> >
> >   #7   0x60076340   0x60200698   <arplookup+0x78>
> >
> >   #8   0x60076e34   0x60200710   <arpintr+0x20c>
> >
> >   #9   0x6008861c   0x602007c0   <networkDaemon+0xa0>
> >
> >   #10  0x60088164   0x60200828   <taskEntry+0x20>
> >
> >   #11  0x6006d210   0x60200888   <_Thread_Entry_adaptor_numeric+0x8>
> >
> >   #12  0x6006c464   0x602008e8   <_Thread_Handler+0x60>
> >
> >   #13  0x6006c404   0x60200948   <_Thread_Handler+0>
> >
> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> > use of the intended recipient and may contain material that is
> > proprietary, confidential, privileged or otherwise legally protected or
> > restricted under applicable government laws. Any review, disclosure,
> > distributing or other use without expressed permission of the sender is
> > strictly prohibited. If you are not the intended recipient, please
> > contact the sender and delete all copies without reading, printing, or
> > saving.
> >
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available on request
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20201008/5b0600a0/attachment-0001.html>