From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 17:03:18 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86FAD106564A for ; Sun, 18 Jul 2010 17:03:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12A568FC17 for ; Sun, 18 Jul 2010 17:03:17 +0000 (UTC) Received: by fxm13 with SMTP id 13so2010065fxm.13 for ; Sun, 18 Jul 2010 10:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=g0b+AJof6x7pVVtd3h8u4CMu8yG37J9TP6mGNgofyak=; b=p8yNoGS4+xoT26/3xev5q0U0g1Hl2SUTMENkegoyx9hkzRp9skhJqsGmfLbzmoi9kW qIZh9Pkb6P5Aw4TKSBpgbpTxpQhvPnUIaSe/qxMu2pooqImYmXQ71aBRNel8jdti5OVz Q497r7LB0q5OiYx49MvAKODGhWvzMQ/2hzXHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wWD5WbxeiDzKNBNUCCad2H9fksvzuOWSCUJa19RniBAICjE2MZEDtmJm6ggWI+DuMT rzfCT6S1LtuqMTzGi+XSxwnmaWK4oeTAd7Zxg8vQBbfMPOUELNPTAFxtEnKc3bDeI6HK l/qPH7A71WOOS7DVM0pjeZLfXAJGB1HLOO9CI= Received: by 10.86.98.10 with SMTP id v10mr1888924fgb.72.1279472596876; Sun, 18 Jul 2010 10:03:16 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r27sm1658164faa.0.2010.07.18.10.03.15 (version=SSLv3 cipher=RC4-MD5); Sun, 18 Jul 2010 10:03:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C433391.4080808@FreeBSD.org> Date: Sun, 18 Jul 2010 20:02:09 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marius Strobl References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> In-Reply-To: <20100718142101.GY4706@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 17:03:18 -0000 Marius Strobl wrote: > Looks better, but can't you just implement the tick grace check > in tick_et_start() and let it return an error if the interval > is too short until there maybe is an MI way to supply a minimum > period? Is it so important now? If I understand right, limit was set at 50KHz. I haven't heard somebody was trying to use so high HZ values. And even so, 10000 ticks for 500MHz CPU seems much more then enough to handle simple read-modify-write operation with disabled interrupts. May be there is something wrong with interrupt acknowledgment in case the rest of interrupt handler takes too much time or some else? If it is the result of some unexpected delays, may be it would be better to reread timer after writing comparator to make sure we got in time and plank wasn't reached yet? tick_et_start() status is not checked my MI code at the moment, as error handling in that case is not obvious. Do you like panic of printf there? > Also please follow style(9) and don't initializing variables in > the declarations and leave tick_{clear,start} at the end of the > file in order to not move code around unnecessarily. Fixed: http://people.freebsd.org/~mav/timers_sparc3.patch >> Don't you have some spare system with stick problems, so I could play >> with it? > > I have but I recently moved and am currently busy with semester > finals so it'll probably be mid-August when I'm able to set it up > again. I'm not sure I'll be able to provide remote access though. It's a pity. >> And some documentation? I am curious, what is wrong there. :) > > Just look at the documentation of US-III or later CPUs: > www.cs.pitt.edu/~cho/cs2410/currentsemester/handouts/USIIIv2.pdf Thanks. Now it seems more clear. Looking on documentation I may assume that STICK counter incremented synchronously over the system, while they may need initial sync. Looking on sync code I've got some doubts about it's correctness. If I understand right, BSP waits for AP to signal readiness, then reads it's timers and fills respective variable. AP during startup sets readiness flag, then fetches value and programs timer. But what happens if AP fetches value before the AP stores them? I don't see any protection against it there. Wouldn't it be reasonable to do instead: - for BSP: membar(StoreLoad); csa->csa_tick = rd(tick); membar(StoreLoad); csa->csa_state = CPU_TICKSYNC; do { membar(StoreLoad); csa->csa_tick = rd(tick); } while (csa->csa_state != CPU_TICKSYNCDONE) - for APs (C equivalent): while (csa->csa_state != CPU_TICKSYNC) ; membar(StoreLoad); wrpr(csa->csa_tick, 0, 0); membar(StoreLoad); csa->csa_state = CPU_TICKSYNCDONE; ? -- Alexander Motin