You didn't reply to the entire list so I am adding it back. You are using the legacy stack (cpukit/libnetworking) which is 20+ years old and IPV4 only.
There could be a packet which the older stack doesn't like the format of. Perhaps a number pushes something out of range. Any possibility there is IPV6 on the network? I don't know how this stack reacts to that. Another simple thing to try is increasing the size of the stacks and turning on the stack checker. --joel On Thu, Oct 8, 2020 at 10:39 AM <richard.glos...@l3harris.com> wrote: > Hi Joel, > > > > We are using Gaisler’s rc7 release for RTEMS 5.1. I don’t see libbsd in > the map file at all, but not really sure how to tell. > > > > We do have an FPU and our tasks are all FP enabled. Not sure on the > network stack. > > > > *From:* users <users-boun...@rtems.org> *On Behalf Of *Joel Sherrill > *Sent:* Thursday, October 8, 2020 11:29 AM > *To:* Thomas Doerfler <thomas.doerf...@imd-systems.de> > *Cc:* rtems-us...@rtems.org <us...@rtems.org> > *Subject:* [EXTERNAL] Re: RTEMS Network Stack and Managed Switch > > > > > > > > On Thu, Oct 8, 2020 at 10:25 AM Thomas Doerfler < > thomas.doerf...@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.glos...@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 > > us...@rtems.org > > http://lists.rtems.org/mailman/listinfo/users > > > > -- > IMD Ingenieurbuero fuer Microcomputertechnik > Thomas Doerfler Herbststrasse 8 > D-82178 Puchheim Germany > email: thomas.doerf...@imd-systems.de > PGP public key available on request > _______________________________________________ > users mailing list > us...@rtems.org > http://lists.rtems.org/mailman/listinfo/users > > > > 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. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
