[Click] Bug ToDevice kernelmodule?

[Eddie Kohler]

Hi Wim,

A patch that Jason Park posted long ago, in May 2006, applied a slightly 
better fix for this problem.  The patch would not reschedule if there was no 
carrier, and listened for carrier-up events to restart Click's transmit 
behavior.  I've just applied a version of this patch to the sources.  You 
might try with current Click.

Thanks for reporting this!
Eddie


Wim Vandenberghe wrote:
> Hi,
> 
> i've noticed some strange behaviour using ToDevice in kernel mode. The 
> problem was that there was a wired interface used in a ToDevice in 
> kernel mode, but there was no cable attached to the interface. At first, 
> the click module had a normal cpu load of 1%, but after half a minute or 
> so, it suddenly became 99,9%. When i performed a click-uninstall and 
> reinstalled my click config, it imediately became 99,9%
> 
> After a while, i could pinpoint the cause of the problem. In my config, 
> now and then a packet is broadcasted on all the interfaces, including 
> the one without a wire. At first, the interface accepted the packet from 
> the todevice, probably putting it in an internal buffer. But after a 
> while, the buffer became full, and the interface signalled "busy" to the 
> todevice. This caused the todevice to continuously reschedule it's task, 
> trying to give the packet to the interface, causing the high CPU load. I 
> was able to solve the problem by changing the reschedule condition at 
> the end of the run_task methode from "bool reschedule = (busy || sent > 
> 0 || _signal.active());" to "bool reschedule = ((!busy) && (sent > 0 || 
> _signal.active()));".
> 
> It can be noticed that this is the same condition as when "#ifdef 
> HAVE_CLICK_KERNEL_TX_NOTIFY", but i was not able to get click working 
> with that variabele defined, that's why i changed the general reschedule 
> condition. The consequence is that the task will be rescheduled as 
> before, but only when the device is not busy.
> 
> After this change, the run_task wasn't rescheduled anymore and the CPU 
> load remained normal. However, when a cable was plugged into the 
> interface, the run_task never was called, making the interface useless. 
> Therefore, i added a timer in the todevice, that is started if the 
> reschedule variable is false, and calling the run_task method after 500 
> ms. This way, the CPU load remains normal, but when a cable is plugged 
> into the interface, it becomes usable again.
> 
> I don't know if this is the best way to solve the described problem, and 
> if this could be descibed as a click bug, but i thought it was best to 
> post this on the click mailing list.
> 
> Kind regards,
> 
> Wim
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click