[En-Nut-Discussion] Nutos 5.1 on Ethernut 1.3g with multiple threads: network freezes

[Uwe Bonnes]

>>>>> "Jonathan" == Jonathan Woithe <jwoithe at atrad.com.au> writes:
...
    Jonathan> I have been instrumenting the packet path with printf()s this
    Jonathan> morning and was able to make some progress before the presence
    Jonathan> of additional printf()s changed the program behaviour.  This
    Jonathan> in itself is interesting as it suggests that memory corruption
    Jonathan> might be the root cause.

printf debugiing is quite intrusive. If the serial line is busy, a call to
some print function will block until there is space. So for time critical
instrumentation, toggling pins is more appropriate.

    >> From this work it appears that packets are being received by NutOS at
    >> all
    Jonathan> times during the fault condition.  The problem is that the
    Jonathan> outside world never sees anything in response.

    Jonathan> Curiously enough, the ethernut *does* respond to ARP requests
    Jonathan> even when it's apparently unresponsive to IP packets:

    Jonathan> 12:17:48.268374 IP pc.domain > 192.168.0.245: ICMP echo
    Jonathan> request, id 15889, seq 1, length 64 12:17:49.267483 IP
    Jonathan> pc.domain > 192.168.0.245: ICMP echo request, id 15889, seq 2,
    Jonathan> length 64 12:17:50.267475 IP pc.domain > 192.168.0.245: ICMP
    Jonathan> echo request, id 15889, seq 3, length 64 12:17:51.267643 IP
    Jonathan> pc.domain > 192.168.0.245: ICMP echo request, id 15889, seq 4,
    Jonathan> length 64 12:17:52.267477 IP pc.domain > 192.168.0.245: ICMP
    Jonathan> echo request, id 15889, seq 5, length 64 12:17:53.267476 IP
    Jonathan> pc.domain > 192.168.0.245: ICMP echo request, id 15889, seq 6,
    Jonathan> length 64

    Jonathan> The pc.domain machine already had an ARP entry when "ping" was
    Jonathan> started here, so initially it just used that.

    Jonathan> 12:17:53.271451 ARP, Request who-has 192.168.0.245 tell
    Jonathan> pc.domain, length 28 12:17:54.267470 IP pc.domain >
    Jonathan> 192.168.0.245: ICMP echo request, id 15889, seq 7, length 64
    Jonathan> 12:17:54.271447 ARP, Request who-has 192.168.0.245 tell
    Jonathan> pc.domain, length 28 12:17:55.267478 IP pc.domain >
    Jonathan> 192.168.0.245: ICMP echo request, id 15889, seq 8, length 64
    Jonathan> 12:17:55.271439 ARP, Request who-has 192.168.0.245 tell
    Jonathan> pc.domain, length 28 12:17:56.267492 IP pc.domain >
    Jonathan> 192.168.0.245: ICMP echo request, id 15889, seq 9, length 64
    Jonathan> 12:17:57.267471 ARP, Request who-has 192.168.0.245 tell
    Jonathan> pc.domain, length 28 12:17:57.268234 ARP, Reply 192.168.0.245
    Jonathan> is-at 42:54:52:44:10:00 (oui Unknown), length 46

    Jonathan> Although it took some time (4 ARP requests over 4 seconds),
    Jonathan> the ethernut did eventually respond to one of these.

    Jonathan> 12:17:57.268250 IP pc.domain > 192.168.0.245: ICMP echo
    Jonathan> request, id 15889, seq 10, length 64 12:17:58.267484 IP
    Jonathan> pc.domain > 192.168.0.245: ICMP echo request, id 15889, seq
    Jonathan> 11, length 64 12:17:59.267474 IP pc.domain > 192.168.0.245:
    Jonathan> ICMP echo request, id 15889, seq 12, length 64

    Jonathan> Subsequent ping packets still went unanswered.

    Jonathan> Obviously print_P() calls are more disruptive to the code
    Jonathan> layout than I/O pin manipulations, so I'll see about trying
    Jonathan> that.

    Jonathan> Another thing I did was annotate NutEtherInput() and
    Jonathan> NutEtherOutput() to print something on entry.  In the fault
    Jonathan> condition I see paired calls to these (that is,
    Jonathan> NutEtherInput() is followed a little time later by
    Jonathan> NutEtherOutput()).  However, no packets were noted by tcpdump
    Jonathan> as coming from the ethernut at these times (only the ICMP
    Jonathan> requests from the PC).

Was said before, none of my many designs with NutOS uses ethernet. So it is
good that Hendrik joined the discussion.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------