From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 06:58:05 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 590E7106566B for ; Sun, 18 Jul 2010 06:58:05 +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 D9E268FC15 for ; Sun, 18 Jul 2010 06:58:04 +0000 (UTC) Received: by fxm13 with SMTP id 13so1884689fxm.13 for ; Sat, 17 Jul 2010 23:58:03 -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=CEJOni8Z1soBFBsVC8ZF7aF5vasFEd+WoMXaWhVH2OA=; b=UhvOORoJ8TqlmmJOkRhFqg2z4N86S+ugMYu0B0/pQ80rHWAJWy657NLW0jcY8YqNSU HJgR6JK182tOYLxCvuRk+zuKVbYlm3wKpnbnsbxk922lyTbaJ3uL67ieRxZIRflPTFEM 2LcBu9QhWQ6y8RsJAzDj06BuhZGMfAXgsdVhw= 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=RMM3AdvH34ncfDbqHVvSnvxzj6+XJpn4UBRHbjT1FmIg3ghhHID1SUWxojcnCrn1OY eFvdG1/EP1asvOEAiRPkXQLBffLkTK5Hnd7SJEBS194Ow2G/L7QyN5syp3G2LUF370tA wzSlI5PE8mI6Ijn5Ck3cscu7sLFrQjTeROhUo= Received: by 10.223.124.9 with SMTP id s9mr2279271far.91.1279436283738; Sat, 17 Jul 2010 23:58:03 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q17sm1481176faa.21.2010.07.17.23.58.02 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 23:58:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C42A5B9.7080901@FreeBSD.org> Date: Sun, 18 Jul 2010 09:56:57 +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> In-Reply-To: <20100716213503.GT4706@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 06:58:05 -0000 Marius Strobl wrote: > please don't commit this as-is: > - using the stick instead of the tick counter for machines with CPUs > and thus tick counters running at different speeds has turned out > to be suboptimal, probably due to the fact that the 12.5MHz the > stick counters typically are driven by don't provide sufficient > granularity. Thus the more desireable variant for these machines > probably is to provide the tick counter of the BSP as the only > non-per-CPU timer and forward it to the APs via IPIs. This also > leaves the stick counter of all >= US-III machines generally > available for driving statclock, which likely is also desirable. > - I'd like to keep the tick grace check as this caused problems in > the past. Probably tick_et_start() just should return an error > in this case. > - I don't like wasting CPU cycles for determining whether the > workaround for BlackBird CPUs is needed (assuming #1 above is > implemented so distinguishing stick/tick is no longer needed) > with every (s)tick interrupt which are a lot as this just won't > ever change during runtime, i.e. I'd like to keep the different > interrupt handlers which are set up as needed. > - Replacing intr_disable_all() with intr_disable() on sun4v > probably isn't a good idea as the latter doesn't disable IPIs > as it does on sparc64 and other architectures. Here is new path, updated respecting two last points: http://people.freebsd.org/~mav/timers_sparc2.patch Don't you have some spare system with stick problems, so I could play with it? And some documentation? I am curious, what is wrong there. :) -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 14:05:10 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 63BEB1065677; Sun, 18 Jul 2010 14:05:10 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8388FC12; Sun, 18 Jul 2010 14:05:09 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6IE58oJ013568; Sun, 18 Jul 2010 16:05:08 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6IE58d4013567; Sun, 18 Jul 2010 16:05:08 +0200 (CEST) (envelope-from marius) Date: Sun, 18 Jul 2010 16:05:08 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100718140508.GX4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C40D6F5.6070208@FreeBSD.org> <20100717152459.GU4706@alchemy.franken.de> <4C41D99B.10202@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C41D99B.10202@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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 14:05:10 -0000 On Sat, Jul 17, 2010 at 07:26:03PM +0300, Alexander Motin wrote: > Marius Strobl wrote: > > On Sat, Jul 17, 2010 at 01:02:29AM +0300, Alexander Motin wrote: > >> Marius Strobl wrote: > > If it is granularity, then it is caused not by the base frequency. Here > is typical x86 timer frequencies: > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.TSC.frequency: 2000085680 > , but TSC is not used on SMP. Others have frequencies not higher then > stick and still working fine. IMHO while counter is monotonic and it's > frequency is higher then frequency of context switches - it should not > be important. I would looked for some different reason. If you have an idea what else could be causing it I'm all ears :) Part of the problem is that there's so much stuff ticking inside the kernel - hard, prof soft and clocks, time counters, cycle counters and CPU tickers - it's hard to follow which source is used for what and how they are supposed to work and also might interact. > > > Using the stick counter on machines consisting of CPUs running at > > different speeds (well, actually all the combinations of using > > stick/tick for hardclock, timecounter, CPU ticker and cycle > > counter I tried as they didn't appear totally wrong) additionally > > has the problem of processes getting killed as they are diagnosed > > to have exceeded their maximum CPU limit, although with the in-tree > > code only the timecounter provided by the host-PCI-bridge should > > be used for this calculation as far as the MD initialization is > > concerned when the stick counter is used to drive hardclock. > > On my SB100 I've seen only tick timecounter registered. If there is some > other timecounter hardware in a system, why it is not registered? It > would be much easier to experiment, having more trusted spare parts. The timecounter I was talking about is implemented by (ab)using one of their performance counters of Schizo host-PCI-bridges in bus cycle counting mode. The host-SBus-bridges and the Psycho host-PCI-bridges also have a timecounter but the Hummingbird host-PCI-bridges found in Blade 100 don't have such counters. > > >>> Thus the more desireable variant for these machines > >>> probably is to provide the tick counter of the BSP as the only > >>> non-per-CPU timer and forward it to the APs via IPIs. > >> It would be possible if timer was programmable from any CPU. But as I > >> understand - it require thread to be binded, which handled by > >> infrastructure only for per-CPU timer. > > > > Wouldn't it be sufficient to bind curthread to the BSP in > > tick_et_start() in that case? For one-shot mode this probably > > is to much overhead (assuming a tickless kernel) but for > > periodic mode IMO this approach should be sound. > > tick_et_start() is called under spin lock and sometimes critical > section. You can't call CPU binding there. For per-CPU timers > reconfiguration there is special logic implemented in MI code using IPIs. Too bad. > > By the way I have some doubts about tick_get_timecount_mp() correctness. > It tries to bind thread to BSP, but what if it is called inside > interrupt handler, or under lock, or some else. I have doubt binding > will work in that case. I've no idea whether sched_bind() works under locks etc as there's no man page describing it, however as it requires curthread to be locked and thread_lock() itself uses a spin lock and locking(9) basically says that acquiring a spinlock with any other lock held is okay I assume that the whole thing is fine with any lock held. Also if there were such restrictions I'd expect there some KASSERTs etc to be in place in the functions invovled preventing incorrect use but tick_get_timecount_mp() doesn't trigger such. Apart from that I'm not really happy about that construct myself but I don't see an alternative to always bind to the same CPU when reading the tick counter in order to get reliable results and in US-IIIi-based machines there just isn't another piece of hardware besides the per-CPU stick and tick counters that could be used as a timecounter available. > > >>> This also > >>> leaves the stick counter of all >= US-III machines generally > >>> available for driving statclock, which likely is also desirable. > >> It would be nice, but I don't know how separate their interrupts. > > > > I think this should be possible in the soft interrupt dispatch. > > However, meanwhile it came to my mind that there was a problem > > with using the stick counter on US-IIIi machines (which also > > only can consist of CPUs running at the same frequency though). > > Is this hardware working at all? May be there is something wrong by > definition or it is misused? I haven't tried to verify whether the frequency actually is correct but it in US-III-based machines it's at least incrementing and generating interrupts and OpenSolaris also is using it (and also just getting its frequency via the OFW device tree) so it should be basically fine. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 14:21:03 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 691CA106566B; Sun, 18 Jul 2010 14:21:03 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97D648FC13; Sun, 18 Jul 2010 14:21:02 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6IEL1j5013665; Sun, 18 Jul 2010 16:21:01 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6IEL1gD013664; Sun, 18 Jul 2010 16:21:01 +0200 (CEST) (envelope-from marius) Date: Sun, 18 Jul 2010 16:21:01 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100718142101.GY4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C42A5B9.7080901@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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 14:21:03 -0000 On Sun, Jul 18, 2010 at 09:56:57AM +0300, Alexander Motin wrote: > Marius Strobl wrote: > > please don't commit this as-is: > > - using the stick instead of the tick counter for machines with CPUs > > and thus tick counters running at different speeds has turned out > > to be suboptimal, probably due to the fact that the 12.5MHz the > > stick counters typically are driven by don't provide sufficient > > granularity. Thus the more desireable variant for these machines > > probably is to provide the tick counter of the BSP as the only > > non-per-CPU timer and forward it to the APs via IPIs. This also > > leaves the stick counter of all >= US-III machines generally > > available for driving statclock, which likely is also desirable. > > - I'd like to keep the tick grace check as this caused problems in > > the past. Probably tick_et_start() just should return an error > > in this case. > > - I don't like wasting CPU cycles for determining whether the > > workaround for BlackBird CPUs is needed (assuming #1 above is > > implemented so distinguishing stick/tick is no longer needed) > > with every (s)tick interrupt which are a lot as this just won't > > ever change during runtime, i.e. I'd like to keep the different > > interrupt handlers which are set up as needed. > > - Replacing intr_disable_all() with intr_disable() on sun4v > > probably isn't a good idea as the latter doesn't disable IPIs > > as it does on sparc64 and other architectures. > > Here is new path, updated respecting two last points: > http://people.freebsd.org/~mav/timers_sparc2.patch 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? 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. > > 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. > 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 Marius 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 From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 17:35:49 2010 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88011106566B; Sun, 18 Jul 2010 17:35:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4785B8FC0C; Sun, 18 Jul 2010 17:35:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6IHZjST062863; Sun, 18 Jul 2010 13:35:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6IHZjiE062862; Sun, 18 Jul 2010 17:35:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Jul 2010 17:35:45 GMT Message-Id: <201007181735.o6IHZjiE062862@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 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:35:49 -0000 TB --- 2010-07-18 16:59:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 16:59:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-07-18 16:59:15 - cleaning the object tree TB --- 2010-07-18 16:59:27 - cvsupping the source tree TB --- 2010-07-18 16:59:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-07-18 17:35:45 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:35:45 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:35:45 - 0.58 user 7.79 system 2190.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 17:43:51 2010 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 104491065677; Sun, 18 Jul 2010 17:43:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C5D358FC19; Sun, 18 Jul 2010 17:43:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o6IHhou2062881; Sun, 18 Jul 2010 13:43:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6IHhoPp062880; Sun, 18 Jul 2010 17:43:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Jul 2010 17:43:50 GMT Message-Id: <201007181743.o6IHhoPp062880@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 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:43:51 -0000 TB --- 2010-07-18 17:03:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 17:03:19 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-07-18 17:03:19 - cleaning the object tree TB --- 2010-07-18 17:03:30 - cvsupping the source tree TB --- 2010-07-18 17:03:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-07-18 17:43:50 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:43:50 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:43:50 - 0.52 user 6.58 system 2430.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 19 11:07:05 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 EEE73106564A for ; Mon, 19 Jul 2010 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DCEA88FC23 for ; Mon, 19 Jul 2010 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JB75XI065836 for ; Mon, 19 Jul 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JB75Fl065834 for freebsd-sparc64@FreeBSD.org; Mon, 19 Jul 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jul 2010 11:07:05 GMT Message-Id: <201007191107.o6JB75Fl065834@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org 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: Mon, 19 Jul 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/145211 sparc64 [panic] Memory modified after free o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption f sparc/127051 sparc64 [hme] hme interfaces "pause" with the message "device o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 14 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 19 12:24:26 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 064F7106566C; Mon, 19 Jul 2010 12:24:26 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 43A8D8FC0C; Mon, 19 Jul 2010 12:24:25 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6JCONdq033693; Mon, 19 Jul 2010 14:24:23 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6JCON9Y033692; Mon, 19 Jul 2010 14:24:23 +0200 (CEST) (envelope-from marius) Date: Mon, 19 Jul 2010 14:24:23 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100719122423.GA4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> <4C433391.4080808@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C433391.4080808@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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: Mon, 19 Jul 2010 12:24:26 -0000 On Sun, Jul 18, 2010 at 08:02:09PM +0300, Alexander Motin wrote: > 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? Ah, I haven't looked at the MI code to closely. No, it's not that important, a printf should be sufficient for now, I just don't want the check to get completely dropped. > > > 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 Looks good, thanks. > > Looking on documentation I may assume that STICK counter incremented > synchronously over the system, while they may need initial sync. I've no idea how synchronous the (S)TICK counters actually are across the system over time and with differenct CPU models. However, at least Linux really jumps through hoops to periodically synchronize them at runtime over and over again so I assume that they are not that stable and decided to not rely on their synchronousity. Did you come across a description in the documentation saying that they are in sync, apart from the sentence saying that the clocks are synchronized at the rising edge? > 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. You mean when the AP fetches the value before the BSP stores them? That's dealt with by initializing csa_tick with 0 and the APs reading csa_tick in a loop until it's not zero. That variant should result in somewhat better synchronisity than your version while not hurting the common case. Note that the membars in there actually should be redundant as the kernel is run with total store order (but also don't hurt anything). Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 19 15:04:51 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 2A7091065672 for ; Mon, 19 Jul 2010 15:04:51 +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 A7A3B8FC16 for ; Mon, 19 Jul 2010 15:04:50 +0000 (UTC) Received: by fxm13 with SMTP id 13so2454038fxm.13 for ; Mon, 19 Jul 2010 08:04:49 -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=jg59H+ZT34OCZRA6WzAGcZz8xp1giWKp+62aFVX19Bs=; b=rp9tdeb0n5kd3B3w66EzSHO07FAhxHFRFcZ8w0FfWC4Vc9yUww/B/PF6GNCnwVlXhK TFMcmQ9hQqU1yB6DOG+Lhz2oVC6+la+QkFiN2s10Jl/mOqxyRhoMkI2srLWOpmwwYH5o 320G5NpQBt/6WcbJz6dYrtJ9sg70ddno4ov8M= 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=n3JknVicXdOqirOfLAkYPJr8Z0EARLSp7OZQrxzeiJXlfvajfYV84L1X/ThHtb4jNV DExrBZv0a5V5p8kmeFL+/LnhwFRg0EM2bcQBdFu2h7ErzEwA6vqF3CEmkctT37zmeonL 7dZGhugISCJ1ozi/WEH+8APUCIzkUpEAaNpjo= Received: by 10.223.117.20 with SMTP id o20mr3891834faq.55.1279551889700; Mon, 19 Jul 2010 08:04:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b36sm2049774faq.11.2010.07.19.08.04.48 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 08:04:48 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C44694C.9040108@FreeBSD.org> Date: Mon, 19 Jul 2010 18:03:40 +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> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de> In-Reply-To: <20100719122423.GA4706@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: Mon, 19 Jul 2010 15:04:51 -0000 Marius Strobl wrote: > On Sun, Jul 18, 2010 at 08:02:09PM +0300, Alexander Motin wrote: >> 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? > > Ah, I haven't looked at the MI code to closely. No, it's not that > important, a printf should be sufficient for now, I just don't > want the check to get completely dropped. I better do it MI way. It's not so difficult. I am just thinking what better report from driver: allowed divisors, periods, or rounding function. >> Looking on documentation I may assume that STICK counter incremented >> synchronously over the system, while they may need initial sync. > > I've no idea how synchronous the (S)TICK counters actually are > across the system over time and with differenct CPU models. > However, at least Linux really jumps through hoops to periodically > synchronize them at runtime over and over again so I assume that > they are not that stable and decided to not rely on their > synchronousity. > Did you come across a description in the documentation saying > that they are in sync, apart from the sentence saying that the > clocks are synchronized at the rising edge? There is indeed too small info about this. I've found that thing about edge, you've noticed, also I've found that TICK clock is integer multiply of STICK. Taking analogy to x86 I may assume that CPUs with different frequencies still quite likely use same bus frequency (STICK), or even sharing the same bus, while have different multipliers for core (TICK) frequency. It is indeed only an assumption, but it would be strange for CPU designers to implement one more counter, which is not better then already existing one. >> 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. > > You mean when the AP fetches the value before the BSP stores > them? That's dealt with by initializing csa_tick with 0 and > the APs reading csa_tick in a loop until it's not zero. That > variant should result in somewhat better synchronisity than > your version while not hurting the common case. Note that the > membars in there actually should be redundant as the kernel > is run with total store order (but also don't hurt anything). Ah, sorry, found the loop on AP. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 19 16:39:58 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 85524106566C for ; Mon, 19 Jul 2010 16:39:58 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFF48FC24 for ; Mon, 19 Jul 2010 16:39:57 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id o6JGdtmL021416; Mon, 19 Jul 2010 17:39:55 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1OatNj-00019U-Qa; Mon, 19 Jul 2010 17:39:55 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.4/8.14.4) with ESMTP id o6JGdtQZ023189; Mon, 19 Jul 2010 17:39:55 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.4/8.14.4/Submit) id o6JGdtmp023188; Mon, 19 Jul 2010 17:39:55 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Narciso Martinez In-Reply-To: References: Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 17:39:55 +0100 Message-ID: <1279557595.21436.99.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-sparc64@FreeBSD.org Subject: Re: NetBoot Install Sparc64 Problems 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: Mon, 19 Jul 2010 16:39:58 -0000 On Mon, 2010-07-05 at 16:31 +0200, Narciso Martinez wrote: > Sometime I get "\", another time Sparc machine ask (by TFTP) files > that doesn't exist in tftpboot (directory /boot from CD). >=20 > The problems are mainly in bootptab and in the content of /tftpboot. > My bootptal is like this: > .default:\ > :bf=3D"WHAT SHOULD I PUT HERE FOR NET INSTALL?":dn=3Ddomain:ds=3Dnameserv= er:\ > :gw=3Dgateway:ht=3Dether:hd=3D"AND HERE?":hn:\ > :sm=3D255.255.255.0 >=20 > hostname:ht=3D1:ha=3D080020C4269A:tc=3D.default:ip=3DIP: I'm afraid I can't help you with bootp directly, but here's what I use with isc-dhcpd: group sparc64 { next-server a.b.c.d; filename "kernel-sparc64.nfs"; option root-path "a.b.c.d:/space/freebsd/roots/sparc64"; host v120 { hardware ethernet 00:03:ba:2c:8e:d1; fixed-address w.x.y.z; = } host v240 { hardware ethernet 00:03:ba:7d:3e:b9; fixed-address w.x.y.z; = } host v480 { hardware ethernet 00:03:ba:2f:17:6e; fixed-address w.x.y.z; = } host v880 { hardware ethernet 00:03:ba:0b:35:4f; fixed-address w.x.y.z; = } } > In the other side, in my /tftpboot I copy al directory /boot from cd > install and I created the symbolic link with the mac the sparc64. Then, in /tftpboot, I have copies of /boot/loader named after the IP addresses converted to hex, so for example loader for the server 10.0.128.1 would be named /tftpboot/0A008001 Finally, /space/freebsd/roots/sparc64 is just a copy of the root filesystem, or in your case, I assume a straight copy of the install CD should work. Gavin --=20 Gavin Atkinson FreeBSD committer and bugmeister From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 10:54:57 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 00F9D106570B; Tue, 20 Jul 2010 10:54:57 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 39F648FC0C; Tue, 20 Jul 2010 10:54:56 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6KAstJu043537; Tue, 20 Jul 2010 12:54:55 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6KAstIX043536; Tue, 20 Jul 2010 12:54:55 +0200 (CEST) (envelope-from marius) Date: Tue, 20 Jul 2010 12:54:55 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100720105454.GE4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de> <4C44694C.9040108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C44694C.9040108@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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: Tue, 20 Jul 2010 10:54:57 -0000 On Mon, Jul 19, 2010 at 06:03:40PM +0300, Alexander Motin wrote: > > There is indeed too small info about this. I've found that thing about > edge, you've noticed, also I've found that TICK clock is integer > multiply of STICK. Taking analogy to x86 I may assume that CPUs with > different frequencies still quite likely use same bus frequency (STICK), > or even sharing the same bus, while have different multipliers for core > (TICK) frequency. > It is indeed only an assumption, but it would be strange for CPU > designers to implement one more counter, which is not better then > already existing one. My understanding is that the only advantage of the STICK counter over the TICK one is that the former is always driven by the same frequency across all CPUs in a system, regardless of the frequency the CPUs are running at (as needed in machines equipped with different CPU models or when down throttling). Marius From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 11:11:28 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 3C7D11065677 for ; Tue, 20 Jul 2010 11:11:28 +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 BA8D18FC12 for ; Tue, 20 Jul 2010 11:11:27 +0000 (UTC) Received: by fxm13 with SMTP id 13so2960731fxm.13 for ; Tue, 20 Jul 2010 04:11:26 -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=fnwP+dkxmVAsSXGlxKMsSaVqlviV7J+MlFihGA4JgnA=; b=o4QeyEv40uc1unHB9hCxfp8hcGCo4QQ08g31/b1oDLhU3EHXuhlN1VlABi6/x4vBCf BNFv6bVqieqBhDnijkgkIS1H0woHVz2W0lew0AjwWcZpxCoqFjeVGmICau4bZWQjxqw/ RoPzSK5LYfnDdiEYVJuFLfbJT3ldnMuUziDJM= 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=xKOLMv0Txw/qVQRgfcUpAR7pvSbQjWpHbIzkIAfuvfkpIjIsQQcaisNnHVbtChK8Sl tA9Ft3ET12RDwlX8Pau6b/HEvXEonZNiq3P3roMAz/77R1SMtyaNmKYoqQ7PMM42ture XZz66Y/446Va6YJmvsLFrKafHOQiEEQ1ORuVY= Received: by 10.86.63.10 with SMTP id l10mr3863420fga.28.1279624286630; Tue, 20 Jul 2010 04:11:26 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w11sm2412410fao.37.2010.07.20.04.11.25 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 04:11:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C458417.3010707@FreeBSD.org> Date: Tue, 20 Jul 2010 14:10:15 +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> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de> <4C44694C.9040108@FreeBSD.org> <20100720105454.GE4706@alchemy.franken.de> In-Reply-To: <20100720105454.GE4706@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: Tue, 20 Jul 2010 11:11:28 -0000 Marius Strobl wrote: > On Mon, Jul 19, 2010 at 06:03:40PM +0300, Alexander Motin wrote: >> There is indeed too small info about this. I've found that thing about >> edge, you've noticed, also I've found that TICK clock is integer >> multiply of STICK. Taking analogy to x86 I may assume that CPUs with >> different frequencies still quite likely use same bus frequency (STICK), >> or even sharing the same bus, while have different multipliers for core >> (TICK) frequency. >> It is indeed only an assumption, but it would be strange for CPU >> designers to implement one more counter, which is not better then >> already existing one. > > My understanding is that the only advantage of the STICK counter > over the TICK one is that the former is always driven by the same > frequency across all CPUs in a system, regardless of the frequency > the CPUs are running at (as needed in machines equipped with > different CPU models or when down throttling). It seems like question to platform, not CPU documentation. I may assume (theoretically), that depending on chipset, CPUs may have: single bus clock generator, several asynchronous generators with same frequency (non-coherent) or event several generators with different frequencies. First case is the best, second may require periodic synchronization to avoid drift, third additionally requires some scaling. It would be nice to play with some problematic system to find are things so bad or reason is somewhere else. Unless it is documented somewhere. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 18:16:13 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 476DA1065676; Tue, 20 Jul 2010 18:16:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 17DA98FC0C; Tue, 20 Jul 2010 18:16:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BC08746B2A; Tue, 20 Jul 2010 14:16:12 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D83B78A04F; Tue, 20 Jul 2010 14:16:11 -0400 (EDT) From: John Baldwin To: freebsd-sparc64@freebsd.org Date: Tue, 20 Jul 2010 13:54:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C404018.6040405@FreeBSD.org> <4C41D99B.10202@FreeBSD.org> <20100718140508.GX4706@alchemy.franken.de> In-Reply-To: <20100718140508.GX4706@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201354.02827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Jul 2010 14:16:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Motin , Marius Strobl 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: Tue, 20 Jul 2010 18:16:13 -0000 On Sunday, July 18, 2010 10:05:08 am Marius Strobl wrote: > On Sat, Jul 17, 2010 at 07:26:03PM +0300, Alexander Motin wrote: > > By the way I have some doubts about tick_get_timecount_mp() correctness. > > It tries to bind thread to BSP, but what if it is called inside > > interrupt handler, or under lock, or some else. I have doubt binding > > will work in that case. > > I've no idea whether sched_bind() works under locks etc as > there's no man page describing it, however as it requires > curthread to be locked and thread_lock() itself uses a > spin lock and locking(9) basically says that acquiring a > spinlock with any other lock held is okay I assume that > the whole thing is fine with any lock held. Also if there > were such restrictions I'd expect there some KASSERTs etc > to be in place in the functions invovled preventing > incorrect use but tick_get_timecount_mp() doesn't trigger > such. It isn't safe mostly because sched_bind() might need to context switch if you aren't currently running on the desired CPU. If you do that with another spin lock held you should hit this KASSERT(): KASSERT(td->td_critnest == 1 || (td->td_critnest == 2 && (td->td_owepreempt) && (flags & SW_INVOL) != 0 && newtd == NULL) || panicstr, ("mi_switch: switch in a critical section")); Since td_critnest will be > 1 and flags will have SW_VOL set instead of SW_INVOL. Really critical_exit() is the only place that is allowed to call mi_switch() with td_critnest != 1, but ULE doesn't even do that now. > Apart from that I'm not really happy about that construct > myself but I don't see an alternative to always bind to > the same CPU when reading the tick counter in order to > get reliable results and in US-IIIi-based machines there > just isn't another piece of hardware besides the per-CPU > stick and tick counters that could be used as a timecounter > available. You could check td_critnest perhaps in your routine and if it is non-zero just return the cached value of the timecounter from the last time it was polled from tc_ticktock() (effectively turning those instances of getfootime() into just footime()). Things like gettimeofday() would still be correct as they can safely bind to the BSP, and I doubt many interrupt handlers are actually using getfootime(). -- John Baldwin From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 18:32:38 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 7D438106564A; Tue, 20 Jul 2010 18:32:38 +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 C35A88FC16; Tue, 20 Jul 2010 18:32:37 +0000 (UTC) Received: by fxm13 with SMTP id 13so3388348fxm.13 for ; Tue, 20 Jul 2010 11:32:36 -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=xgUQxj5AUUMekdLBmh6iqo2GWkNHQb/2lAqQOU5tqbc=; b=RmsPVTSJVZFuz2dgM6PVF/PpOT+uQX1owNb3JV4hePlqjmWNwZhBh3B3B9z4EvDlon NmIlAccA9cr86LGd4VUYio+/8p1iRt5vseo/Mei2szO9DqPGe3VWCCH5xGa2XrEgF1q/ GxtCsojDL5x768E4rtNlc7NTvAg2AnKmNbHQE= 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=xPxF+gYM1ltS2+rHGpW7hiYKdgMCOujPNLj9xtuab1NzQNw45iw2/HQPBSRMo2Ln0N t0McoOuUx/8RAjDN46+JlsTrwAbDhr+DP62hbIM48fc3zmF4SvIk/J0RFo927IS4HzC+ gfcXgks96wN3bfsuutMBZrGOchCPeKjHmBUjc= Received: by 10.223.122.148 with SMTP id l20mr5789742far.84.1279650756472; Tue, 20 Jul 2010 11:32:36 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id m3sm2551637fai.17.2010.07.20.11.32.33 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 11:32:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C45EBBE.50502@FreeBSD.org> Date: Tue, 20 Jul 2010 21:32:30 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: John Baldwin References: <4C404018.6040405@FreeBSD.org> <4C41D99B.10202@FreeBSD.org> <20100718140508.GX4706@alchemy.franken.de> <201007201354.02827.jhb@freebsd.org> In-Reply-To: <201007201354.02827.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org, Marius Strobl 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: Tue, 20 Jul 2010 18:32:38 -0000 John Baldwin wrote: > On Sunday, July 18, 2010 10:05:08 am Marius Strobl wrote: >> Apart from that I'm not really happy about that construct >> myself but I don't see an alternative to always bind to >> the same CPU when reading the tick counter in order to >> get reliable results and in US-IIIi-based machines there >> just isn't another piece of hardware besides the per-CPU >> stick and tick counters that could be used as a timecounter >> available. > > You could check td_critnest perhaps in your routine and if it is non-zero just > return the cached value of the timecounter from the last time it was polled > from tc_ticktock() (effectively turning those instances of getfootime() into > just footime()). Things like gettimeofday() would still be correct as they > can safely bind to the BSP, and I doubt many interrupt handlers are actually > using getfootime(). Thinking about tickless kernel and looking how it is done in Linux I have feeling that we may need to call getbinuptime or something alike in the interrupt threads to properly schedule events. At this moment I don't see another way to avoid time drift due to interrupt latency and other delays. That's why I would like this issue to be fixed in some better and less consuming way. May be using per-CPU ticker could help at that specific question, but I still don't like the situation. In future it may be not very good to wake up exactly CPU0 from sleep just to update system time for other cores, as it is done now. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 20 22:49:44 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 B5B641065674; Tue, 20 Jul 2010 22:49:44 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2F38FC0A; Tue, 20 Jul 2010 22:49:43 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6KMnfBc049074; Wed, 21 Jul 2010 00:49:41 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6KMnfGf049073; Wed, 21 Jul 2010 00:49:41 +0200 (CEST) (envelope-from marius) Date: Wed, 21 Jul 2010 00:49:41 +0200 From: Marius Strobl To: John Baldwin Message-ID: <20100720224940.GF4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <4C41D99B.10202@FreeBSD.org> <20100718140508.GX4706@alchemy.franken.de> <201007201354.02827.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007201354.02827.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Alexander Motin , 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: Tue, 20 Jul 2010 22:49:44 -0000 On Tue, Jul 20, 2010 at 01:54:02PM -0400, John Baldwin wrote: > On Sunday, July 18, 2010 10:05:08 am Marius Strobl wrote: > > On Sat, Jul 17, 2010 at 07:26:03PM +0300, Alexander Motin wrote: > > > By the way I have some doubts about tick_get_timecount_mp() correctness. > > > It tries to bind thread to BSP, but what if it is called inside > > > interrupt handler, or under lock, or some else. I have doubt binding > > > will work in that case. > > > > I've no idea whether sched_bind() works under locks etc as > > there's no man page describing it, however as it requires > > curthread to be locked and thread_lock() itself uses a > > spin lock and locking(9) basically says that acquiring a > > spinlock with any other lock held is okay I assume that > > the whole thing is fine with any lock held. Also if there > > were such restrictions I'd expect there some KASSERTs etc > > to be in place in the functions invovled preventing > > incorrect use but tick_get_timecount_mp() doesn't trigger > > such. > > It isn't safe mostly because sched_bind() might need to context switch if you > aren't currently running on the desired CPU. If you do that with another spin > lock held you should hit this KASSERT(): > > KASSERT(td->td_critnest == 1 || (td->td_critnest == 2 && > (td->td_owepreempt) && (flags & SW_INVOL) != 0 && > newtd == NULL) || panicstr, > ("mi_switch: switch in a critical section")); > > Since td_critnest will be > 1 and flags will have SW_VOL set instead of > SW_INVOL. Really critical_exit() is the only place that is allowed to call > mi_switch() with td_critnest != 1, but ULE doesn't even do that now. Thanks for clearing that up. > > > Apart from that I'm not really happy about that construct > > myself but I don't see an alternative to always bind to > > the same CPU when reading the tick counter in order to > > get reliable results and in US-IIIi-based machines there > > just isn't another piece of hardware besides the per-CPU > > stick and tick counters that could be used as a timecounter > > available. > > You could check td_critnest perhaps in your routine and if it is non-zero just > return the cached value of the timecounter from the last time it was polled > from tc_ticktock() (effectively turning those instances of getfootime() into > just footime()). Things like gettimeofday() would still be correct as they > can safely bind to the BSP, and I doubt many interrupt handlers are actually > using getfootime(). > I think instead of using sched_bind() I could just IPI the BSP in case the it's called on an AP. When implementing the tick reader as direct cross trap that should have minimal overhead and avoids making any assumptions about the caller of the tc_get_timecount function. Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 21 12:11:50 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 6F00C1065674 for ; Wed, 21 Jul 2010 12:11:50 +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 ECD248FC1C for ; Wed, 21 Jul 2010 12:11:49 +0000 (UTC) Received: by fxm13 with SMTP id 13so3802753fxm.13 for ; Wed, 21 Jul 2010 05:11:48 -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=pfIvaVjPk/jESfzrhYvi74iNwIymzGgUrlC8mACnP2Q=; b=tJPjgdSIq2fL7VEjey98lcQ2ilMw4ovmunQMvKUfGyQVU4fNNXAHnfjhork7Ld92EF Nu7/0Pzjri92UAIgIlGQyv1GusZJtBNwSuQirR6d+toqRg8c4HmsVgjc990HBOTb41wK tcxKzcseG49xyAtfpKYCKExUIkQkIP8bbxz7k= 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=Cnfq6Yvjtn6vXhqqlIQ5LcFzyQNWUbTdYpXz1r+tpaM93htioar2F6fvK8VKINtH7j 2q2vx3lcyE7/sGd4/vYyJIH44m3qNGAsXeS0fb2g4KRYLxLZV4WzvBTOf8B6nbPi0bXv GQfi0dVzwEkwfKWkfaXfCLPEMg9t11/11x2Co= Received: by 10.223.119.131 with SMTP id z3mr55785faq.61.1279714306548; Wed, 21 Jul 2010 05:11:46 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id l12sm2868351fan.25.2010.07.21.05.11.44 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 05:11:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C46E3BB.7060204@FreeBSD.org> Date: Wed, 21 Jul 2010 15:10:35 +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> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de> <4C44694C.9040108@FreeBSD.org> In-Reply-To: <4C44694C.9040108@FreeBSD.org> 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: Wed, 21 Jul 2010 12:11:50 -0000 Alexander Motin wrote: > Marius Strobl wrote: >> On Sun, Jul 18, 2010 at 08:02:09PM +0300, Alexander Motin wrote: >>> 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? >> Ah, I haven't looked at the MI code to closely. No, it's not that >> important, a printf should be sufficient for now, I just don't >> want the check to get completely dropped. > > I better do it MI way. It's not so difficult. I am just thinking what > better report from driver: allowed divisors, periods, or rounding function. Here is updated patch for latest HEAD, which should handle this: http://people.freebsd.org/~mav/timers_sparc4.patch I also added support for STICK timecounter. For this moment with lowest priority to not use it by default, until it is tested. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 24 12:38:19 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 645F3106566C for ; Sat, 24 Jul 2010 12:38:19 +0000 (UTC) (envelope-from lkh@soul.lnet.fi) Received: from soul.lnet.fi (soul.lnet.fi [86.50.32.33]) by mx1.freebsd.org (Postfix) with ESMTP id 13D548FC15 for ; Sat, 24 Jul 2010 12:38:18 +0000 (UTC) Received: by soul.lnet.fi (Postfix, from userid 256) id 53050ABE5C; Sat, 24 Jul 2010 15:25:01 +0300 (EEST) Date: Sat, 24 Jul 2010 15:25:00 +0300 From: Lasse K H To: freebsd-sparc64@freebsd.org Message-ID: <20100724122500.GA29960@soul.lnet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: 8.1: IPFILTER (ipf) ipmon not logging? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lasse K H List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 12:38:19 -0000 Hello, I can't get ipmon(8) working with FreeBSD 8.1. It does not log anything with my Ultra 10. The same setup works fine with FreeBSD 6.4. How to solve this problem? Thank you. ipmon is running: root 25885 0.0 0.5 7064 2424 ?? Ss 9:49AM 0:00.70 /sbin/ipmon -Ds /etc/ipf.rules: pass in quick on lo0 all pass out quick on lo0 all pass in log first quick on hme0 proto tcp from any to any port = 22 flags S keep state pass in quick on hme0 all pass out quick on hme0 all ipfstat -hoi: 0 pass out quick on lo0 all 65 pass out quick on hme0 all 0 pass in quick on lo0 all 1 pass in log first quick on hme0 proto tcp from any to any port = ssh flags S/FSRPAU keep state 74 pass in quick on hme0 all /etc/syslog.conf: *.* /var/log/all.log /sbin/ifconfig hme0: hme0: flags=8843 metric 0 mtu 1500 options=8000b ether 08:00:20:b0:5c:15 inet 172.16.0.70 netmask 0xffffff00 broadcast 172.16.0.255 media: Ethernet autoselect (100baseTX ) status: active uname -a: FreeBSD tlhNEW.kareltek.fi 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 06:53:42 UTC 2010 root@araz.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 24 17:22:01 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 8FB97106567F for ; Sat, 24 Jul 2010 17:22:01 +0000 (UTC) (envelope-from lkh@soul.lnet.fi) Received: from soul.lnet.fi (soul.lnet.fi [86.50.32.33]) by mx1.freebsd.org (Postfix) with ESMTP id 44A5D8FC28 for ; Sat, 24 Jul 2010 17:22:01 +0000 (UTC) Received: by soul.lnet.fi (Postfix, from userid 256) id 97061ABE5E; Sat, 24 Jul 2010 20:21:56 +0300 (EEST) Date: Sat, 24 Jul 2010 20:21:56 +0300 From: Lasse K H To: freebsd-sparc64@freebsd.org Message-ID: <20100724172156.GA30112@soul.lnet.fi> References: <20100724122500.GA29960@soul.lnet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100724122500.GA29960@soul.lnet.fi> User-Agent: Mutt/1.4.2.2i Subject: Re: 8.1: IPFILTER (ipf) ipmon not logging? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lasse K H List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 17:22:01 -0000 On Sat, Jul 24, 2010 at 03:25:00PM +0300, Lasse K H wrote: > Hello, > I can't get ipmon(8) working with FreeBSD 8.1. > It does not log anything with my Ultra 10. > The same setup works fine with FreeBSD 6.4. > How to solve this problem? Thank you. ifconfig hme0 -txcsum -rxcsum did fix the problem. L From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 24 21:41:40 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 A2F0C1065670 for ; Sat, 24 Jul 2010 21:41:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id B648B8FC08 for ; Sat, 24 Jul 2010 21:41:40 +0000 (UTC) Received: by pzk7 with SMTP id 7so651301pzk.13 for ; Sat, 24 Jul 2010 14:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=VCrhFG1eArGkR+yAA9do95VFzxJmyXFV1MDaTiEdplU=; b=Mjzeo3TVDMDuFuPmcB4HiFMzttRogpRg3ECpAkzoJmSybDUNGxTqUwCS4F3w/lNDVL YKDF5Vr6bSP8NXkGzguOw7jS9ovmPcuvdTPeP1O2qBK2iXyJWPCvLBBl+itr1FEp5xZ3 NuxVFOE0ZFk1AqogDUF7Ymal1p39x7iXl0fD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Is65Sq+C7ulM9BBcGgB1sLe+R+xhzdhBkLZlZa6py4xHsNUbvYwnXKYU2yoWiML3Yv Eg0YmlvNfdlZR+BOJSSQYeexynPo+HiYJQgFSQnvbjcQyl9uEbC6JecM2l6idUHTZ/Pt 3Ymr78uBS35JnkBOGI+e9UIaVzWQaOWBfOUmw= Received: by 10.142.210.2 with SMTP id i2mr6358760wfg.173.1280007699802; Sat, 24 Jul 2010 14:41:39 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l6sm6545rvb.14.2010.07.24.14.41.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Jul 2010 14:41:38 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 24 Jul 2010 14:40:54 -0700 From: Pyun YongHyeon Date: Sat, 24 Jul 2010 14:40:54 -0700 To: Lasse K H Message-ID: <20100724214054.GA24965@michelle.cdnetworks.com> References: <20100724122500.GA29960@soul.lnet.fi> <20100724172156.GA30112@soul.lnet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100724172156.GA30112@soul.lnet.fi> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: 8.1: IPFILTER (ipf) ipmon not logging? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 21:41:40 -0000 On Sat, Jul 24, 2010 at 08:21:56PM +0300, Lasse K H wrote: > On Sat, Jul 24, 2010 at 03:25:00PM +0300, Lasse K H wrote: > > Hello, > > I can't get ipmon(8) working with FreeBSD 8.1. > > It does not log anything with my Ultra 10. > > The same setup works fine with FreeBSD 6.4. > > How to solve this problem? Thank you. > > ifconfig hme0 -txcsum -rxcsum > did fix the problem. > ipfilter has a bug in RX checksum offloading handling on FreeBSD. See PR/106438 and possible patch in the PR. You can switch to pf(4) which has no such a bug.