Hi,
after analysing my described problem (read my old mail) I found a general problem of uClinux concerning realtime latency.
Rescheduling of my user app after the execution of the interrupt service routine in my driver fails only sometimes. This is exactly the case when a concurrently working TCP-sending thread temporarily disables kernel preemption. I've seen it happens e.g. with rcu_read_lock_bh() in ./net/core/dev.c:dev_queue_xmit(). Another disabling of preemption happens in ./net/ipv4/tcp.c:tcp_sendmsg() at goto jump label "wait_for_memory:" when the TCP stack starts to wait for the releasing of a socket buffer.
http://www.linuxdevices.com/articles/AT8211887833.html#3 seems to be related to this problem.
Hmm...first I wonder why the RCU lock stuff is not framed in something like "#ifdef CONFIG_SMP" because I understand it as it just makes sense with a multi-processor environment. Anyway, I made a hack this way and commented out local_bh_disable() in rcu_read_lock_bh() and it seems it's still working well in my single-microblaze-CPU system, with the additional effect of an improved latency. I suggest to patch here with #ifdef CONFIG_SMP, shouldn't we?
Still I have the problem with the disabling of preemption in the case of waiting_for_memory by tcp_sendmsg(), that increases the IRQ latency here up to inacceptable 10 msec! :-( I'm still analysing but it's dreadfully time-consuming with all the logging at this low kernel level.
Do you have any idea/comment etc.?