Closed jwt27 closed 8 months ago
Oh, I think I do know why this "worked" on other platforms. On Pentium+ machines, chk_timeout()
will use the rdtsc timer by default, which I noticed before is very inaccurate. So the daemon timer only accidentally triggered due to jitter.
This may also explain why I had some spurious issues in my own code where I used userTimerTick()
. Then the daemon code would never trigger either.
16-bit (Watcom) output:
Parsing `.\wattcp.cfg' (pass 1)
Parsing `.\wattcp.cfg' (pass 2)
ARG_FUNC , matched `MY_IP' = `dhcp'
rundown_dump():
order 3: `restore_sig_handlers' called from sock_ini.c (892)
order 5: `dbug_exit' called from pcdbug.c (306)
order 10: `__eth_release' called from pcsed.c (704)
order 259: `DHCP_exit' called from pcdhcp.c (1435)
order 303: `exit_localport' called from ports.c (59)
order 1000: `daemon_clear_cdecl' called from sock_ini.c (841)
okay
Configuring through DHCP..Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
.Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
.Running daemon 0 (arp_daemon)
Running daemon 1 (dhcp_fsm)
value 3232235779 duplicated in array 3621:3ed8
Address: 192.168.1.29
Calling rundown-func `restore_sig_handlers' at order 3
Calling rundown-func `dbug_exit' at order 5
Calling rundown-func `__eth_release' at order 10
Calling rundown-func `DHCP_exit' at order 259
Calling rundown-func `exit_localport' at order 303
Calling rundown-func `daemon_clear_cdecl' at order 1000
Well done!
The timer was being reset every time daemon_run() was called,
That was a silly mistake with { }
code. Tried it with #97 and all seems well with DHCP now. Good job indeed!
Merging and closing.
Found the DHCP/daemon problem. The timer was being reset every time
daemon_run()
was called, and therefore would never actually trigger.What I don't understand, is why this only caused problems on 16-bit systems...
Fixes: #4