[openbeosnetteam] Re: KDL visits...

David wrote:
> Do we think this might be due to dprintf???
>
> KERNEL PANIC: add_timer(001a6a60, 3000, 00129750, 2) already in 
> timer queue (tulip0_rx_thread, 00129777)!
> 

And then added:

> So, that one was due to dprintf...this one isn't...
> 
> KERNEL PANIC: add_timer(001a6a60, 3000, 00129750, 2) already in 
> timer queue (idle thread 1, 00129777)!

Seems to panic from dprintf() internal code and 
from idle thread code. Both (dprintf() and null_thread code) should use 
the kernel timers service, for serial port output support (dprintf) or 
simply snooze when idle...

Anyway, AFAIK dprintf() is not interrupt-safe, only kprintf() is.
The BeOS R5 kernel timers are interrupt-driven. Software interrupts, but 
still interrupts...

The "Drivers" BeBook chapter state that calling cancel_timer() from 
the timer handler is not supported. 
I dunno if it was fixed in R5 kernel.
See http://bang.dhs.org/be/bebook/Drivers/KernelFunctions.html#cancel_timer()

We ARE currently calling cancel_timer() from our arp timer arp.c:arpq_run().

[Oh, by the way, we never cancel the tcp timers tcp_slowtim and tcp_fasttim.
tcp.c:tcp_init()].

/me think that we could be hitting here some kernel timers internal 
table duplicate keys error: differents threads (00129777, always!) 
are callind add_timer() with same parameters! Strange.
Looks like some cancel_timer()s are not really done 
(checking his return value could help make better diagnostic here).

Would it be difficult to use again the thread'based net_timers service 
contributed by Axel?
They'll works in kernelland too, just a matter of calling 
spawn_kernel_thread() in right place...

Okay, enough speculations...
:-)

-Philippe.

Other related posts: