[Click] Bug ToDevice kernelmodule?

[Wim Vandenberghe]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wim.vandenberghe.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
Url : https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20061220/2085e9f8/wim.vandenberghe.vcf