From owner-freebsd-mips@FreeBSD.ORG Thu Aug 19 01:55:52 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 481C91065694; Thu, 19 Aug 2010 01:55:52 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6228FC12; Thu, 19 Aug 2010 01:55:51 +0000 (UTC) Received: by wwf26 with SMTP id 26so3362790wwf.1 for ; Wed, 18 Aug 2010 18:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yEqRnq7IIJBQywuA7dBMcV/7IL8NyTbVdN8acK02XJ0=; b=mE3rpicg2OC6nTIgyxKyneTRtEJE6l47hoH1Iq1XDLLkCa96kIcLXsjYHf9yPYNsUD pyRxfHTmNRr7As0ZUraYHhXUPau8zSJJAlvthQWEhV2fGWoVlLqm0HgR/na7gSB7dI3B Ea8+1m0Sue/pM+5ngs1RfoK6PcltdRG+VmRuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S8LNTI6TccSBV/D95BvepyQLNUAdO5ZnYDWEo52R9yMNQWvUnlm3Yurd8JofJh8NZV 1OhclRhzd8AFEDOVeIcIhYxOo6QEn95b6sLI1G4I6F9lQyZbN8l1pYM7g4/SipOcUOLK dGLZItnP+0/n2MVtB8RXvD8u5KvnSO+xhVMcc= MIME-Version: 1.0 Received: by 10.216.38.20 with SMTP id z20mr7648187wea.108.1282182950138; Wed, 18 Aug 2010 18:55:50 -0700 (PDT) Received: by 10.216.80.8 with HTTP; Wed, 18 Aug 2010 18:55:50 -0700 (PDT) In-Reply-To: References: <4C41A248.8090605@FreeBSD.org> <4C41B4CF.6080409@FreeBSD.org> <4C4205CC.6080700@FreeBSD.org> <4C4ED247.80701@FreeBSD.org> <4C555CF7.5080101@FreeBSD.org> <4C5977BC.1060104@FreeBSD.org> Date: Wed, 18 Aug 2010 18:55:50 -0700 Message-ID: From: Neel Natu To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , Alexander Motin , freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 01:55:52 -0000 Hi JC, On Wed, Aug 18, 2010 at 7:45 AM, Jayachandran C. wrote: > On Wed, Aug 4, 2010 at 7:52 PM, Alexander Motin wrote: >> Neel Natu wrote: >>> Thanks for taking the time to review the patch. Here is the updated pat= ch: >>> http://people.freebsd.org/~neel/tick_diff.txt >> >> Seems fine. >> >>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin 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=3D0 ttl=3D64 time=3D0.649 ms > 64 bytes from 192.168.30.1: icmp_seq=3D1 ttl=3D64 time=3D362.624 ms > 64 bytes from 192.168.30.1: icmp_seq=3D2 ttl=3D64 time=3D0.219 ms > 64 bytes from 192.168.30.1: icmp_seq=3D3 ttl=3D64 time=3D362.631 ms > 64 bytes from 192.168.30.1: icmp_seq=3D4 ttl=3D64 time=3D-362.168 ms > 64 bytes from 192.168.30.1: icmp_seq=3D5 ttl=3D64 time=3D362.628 ms > 64 bytes from 192.168.30.1: icmp_seq=3D6 ttl=3D64 time=3D0.234 ms > 64 bytes from 192.168.30.1: icmp_seq=3D7 ttl=3D64 time=3D362.631 ms > 64 bytes from 192.168.30.1: icmp_seq=3D8 ttl=3D64 time=3D0.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. =A0Also on XLR the > count registers are not synchronized across cores, so the values will > be different for each CPU. > > =A0I will look at some more, but meanwhile, any clue on what might be > wrong would be helpful. =A0I 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. > Can you try pinning the ping process to cpu 0 and repeat your test? Something like "cpuset -l 0 ping a.b.c.d". best Neel > Thanks, > JC. >