From owner-freebsd-mips@FreeBSD.ORG Wed Aug 25 14:07:11 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 017CA1065693; Wed, 25 Aug 2010 14:07:11 +0000 (UTC) (envelope-from c.jayachandran@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 310568FC08; Wed, 25 Aug 2010 14:07:09 +0000 (UTC) Received: by wwd20 with SMTP id 20so17402wwd.1 for ; Wed, 25 Aug 2010 07:07:09 -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=NHyiKigcpWfuxX3RCkLW5ZlBBiQjK6iFq+flq6F8nMw=; b=WxdK8DYjy3w5l9lqWlUnS8350dMGzCE1FhmzYgpRU2Oz36iCyo3BHnz7q36Fk+ASf0 ZSCAwAjaW1YneCK3W1DbBe7OpB0Vn3wVZWQXM6gD5wKQdPDzPJI1RYeo7EReeA6YPxRh 2ONKW/6RYy8Nz5gX0Qy0yyMtKe3BmRzAlg9uM= 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=G5utIubKuFGMRAczmg57SV4bOwOkO8DhfT27axFMDlk5L6JI0NEMW9al/R/YkTuwk8 F+eskFvgkSo3Dr7u2VpvK354PKy5YD7QQBO7SMdy5jFAtcsiQuhJ4UaZe3uuHiQFcKFr qPAbdK9pbAHZqo0BQ7sn39k03qLzTGxdLOSaM= MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr7435675wei.13.1282745229020; Wed, 25 Aug 2010 07:07:09 -0700 (PDT) Received: by 10.216.156.135 with HTTP; Wed, 25 Aug 2010 07:07:08 -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, 25 Aug 2010 19:37:08 +0530 Message-ID: From: "Jayachandran C." To: Neel Natu 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: Wed, 25 Aug 2010 14:07:11 -0000 On Thu, Aug 19, 2010 at 7:25 AM, Neel Natu wrote: > 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 pa= tch: >>>> http://people.freebsd.org/~neel/tick_diff.txt >>> >>> Seems fine. >>> >>>> On Sun, Aug 1, 2010 at 4:39 AM, Alexander Motin wrot= e: >>>>> "t_upper++;" there looks a bit strange, as it is not written back. Th= e >>>>> 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". With cpuset, I get a negative time about every few seconds, I have not tried to debug this further. I ended up providing a PIC based platform_timecounter, which I needed to do anyway, and now I get sane values. JC.