[RFC] Event timers on MIPS

[Jayachandran C.]

On Wed, Aug 4, 2010 at 7:52 PM, Alexander Motin <mav at freebsd.org> wrote:
> Neel Natu wrote:
>> Thanks for taking the time to review the patch. Here is the updated patch:
>> http://people.freebsd.org/~neel/tick_diff.txt
>
> Seems fine.
>
>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin <mav at freebsd.org> wrote:
>>> "t_upper++;" there looks a bit strange, as it is not written back. The
>>> wrapping stuff won't work if this timer interrupts were not used.
>>
>> This part is intentional.
>>
>> I wanted only clock_intr() to update the cached values of
>> 'counter_upper' and 'counter_lower_last' and tick_ticker() to sample a
>> consistent snapshot of the tuple and then operate on it.
>>
>> I have added an XXX comment to describe the dependency. We can revisit
>> this if we change the default timer in mips.
>
> It's not about default timer, but about having any other timer. But if
> you wish so, it should be enough for now.

I'm seeing a problem with the timer code on XLR, when I run ping:

xlrboard# ping 192.168.30.1
PING 192.168.30.1 (192.168.30.1): 56 data bytes
64 bytes from 192.168.30.1: icmp_seq=0 ttl=64 time=0.649 ms
64 bytes from 192.168.30.1: icmp_seq=1 ttl=64 time=362.624 ms
64 bytes from 192.168.30.1: icmp_seq=2 ttl=64 time=0.219 ms
64 bytes from 192.168.30.1: icmp_seq=3 ttl=64 time=362.631 ms
64 bytes from 192.168.30.1: icmp_seq=4 ttl=64 time=-362.168 ms
64 bytes from 192.168.30.1: icmp_seq=5 ttl=64 time=362.628 ms
64 bytes from 192.168.30.1: icmp_seq=6 ttl=64 time=0.234 ms
64 bytes from 192.168.30.1: icmp_seq=7 ttl=64 time=362.631 ms
64 bytes from 192.168.30.1: icmp_seq=8 ttl=64 time=0.483 ms

This happens with the current XLR code, and even after updating it
from mips/mips/tick.c (to take in Neel's changes).

Due to the way our network driver works, there is a likely that the
ping packets are received by different CPUs every time, but having the
negative time there seems to indicate some issue.  Also on XLR the
count registers are not synchronized across cores, so the values will
be different for each CPU.

 I will look at some more, but meanwhile, any clue on what might be
wrong would be helpful.  I still haven't done the PIC timer based
timecount, that might fix it, if it is due to the count registers
being out of sync.

Thanks,
JC.