[Click] Interrupts are stuck with an unqueue element

Eddie Kohler kohler at cs.ucla.edu
Thu Feb 25 21:02:13 EST 2010


Hi Lorenzo,

There was probably a bug in the version of Click you were using.  Many bugs in 
Unqueue "notification" (the feature that lets ToDevice go to sleep if there is 
nothing to send) have been fixed.  ALso there must have been a Queue in 
between Unqueue and ToDevice, but whatever.

E


lorenzo.bianconi at alice.it wrote:
> Hi all,
> 
> I am using click 1.6.0 as kernel module and I have encontered some issues using an ethernet device. 
> In particular I have to use an unqueue element in order to stop and restart the node transmission and I noticed that the interrupts (from /proc/interrupts)
> on the eth device are stuck and consequently the device introduces a high latency. 
> This is my configuration
> 
> ||||||||||||||||||||||||||        |||||||||||||||||          |||||||||||||||||||||		       ||||||||||||||||||||
> ||FromDevice|| ---> ||Queue||  --->  ||Unqueue||  ---> ... ---> ||Todevice||
> ||||||||||||||||||||||||||        |||||||||||||||||	     |||||||||||||||||||||	 	       ||||||||||||||||||||
> 
> Is it possibile that this problem is due to an unqueue scheduling issue?? If I stop the click thread, disable the interface (ifconfig eth0 down) 
> and afterwards I restart the interface and the click thread the interrupt number restarts to grow and everyting works fine.
> Is it possible that this problem could be due to the kernel which disables the interrupts and switches to polling-mode in order to avoid the "livelock" problem??
> I am using a kernel 2.6.19 
> 
> I know this is a walkaround but is there a way to restart interrupts on eth device avoiding to restart click thread?
> 
> Thank you very much!!!
> 
> Best regards
> 
> Lorenzo 
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click


More information about the click mailing list