[En-Nut-Discussion] 1 second delay in TCP handshake

[Harald Kipp]

Hi Lars,

I cannot confirm your delay problem directly, but I also
experienced some problems with the Ethernet driver. After trying
some stability tests, I got the strong feeling, that it's
more sensitive to packet corruption than previous versions.
It reliably recovers from corruption, but performance suffers,
when the driver resets the chip too often.

I detected the following problem. Instead of disabling interrupts
system wide, the driver disables controller interrupts by clearing
bit 5 in EIMSK. Unfortunately NicStart contains two calls to
NutSleep, which may switch to another thread. If one of these
threads transmits a packet, then NicOutput will clear this bit
too, fiddle around with the controller and even worse, reenable
NIC interrupts at the end. The controller will end up with
corrupted registers again, which requires another reset.

The previously used NutExitCritical avoids this problem, because
it restores the interrupt status, not simply re-enables it. As a
backdraw, it disabled _all_ interrupts, which was bad for time
critical applications.

The solution is not as trivial as it might look. Note, that incoming
pings (ICMP) are exclusively processed by the NIC receiver thread
itself. This thread will even call NicOutput when sending back the
ICMP reply. A typical candidate for deadlocks.

I'm still investigating.

Harald