From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 11 13:51: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 702821065686 for ; Sun, 11 Jul 2010 13:51:26 +0000 (UTC) (envelope-from narcotico@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E5B338FC18 for ; Sun, 11 Jul 2010 13:51:25 +0000 (UTC) Received: by wwe15 with SMTP id 15so1022521wwe.31 for ; Sun, 11 Jul 2010 06:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=eME6VB7wnn7UuaLFtR9tevaOaKzvnTwZ183ATjYKe7k=; b=GTS3k4o+ARH3ytHn4KgiAVmp/26SMKGMPPAQQjGxm5Z2tlXOTW4XHl8maf9DhxapAO AV/l5OQVnG+ECDbV9MJmC6J/Rk7zMAy+er67q7B/SPwCv6jtF3ejkhL3f9qbi9+iQVuJ p3tDTR+MIBjQIetErYsW8iLKatT6C6I635Vyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=N19j+y2xvSpkc5Fe1HFNc0oJZmHzttAGEkZryWo82Smxe6iTdnrmNPVB1lI+aQjIGH nsYhZITkfb2HWN0XjFCJYJaic1kk4BzE78oCJzAoQrZ0KKKdh0EtHYnv+VPMlBdfRsSk wf1SmzfMb6wyp59wlHT83DVnONB2fQlfOOVTg= Received: by 10.227.154.9 with SMTP id m9mr3717110wbw.123.1278856283103; Sun, 11 Jul 2010 06:51:23 -0700 (PDT) Received: from narcoPC (243.150.222.87.dynamic.jazztel.es [87.222.150.243]) by mx.google.com with ESMTPS id o11sm1119455wej.21.2010.07.11.06.51.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 06:51:21 -0700 (PDT) From: =?iso-8859-1?Q?Narciso_Mart=EDnez_Malnero?= To: References: <20100709120024.337FB106574B@hub.freebsd.org> In-Reply-To: <20100709120024.337FB106574B@hub.freebsd.org> Date: Sun, 11 Jul 2010 15:51:19 +0200 Message-ID: <000801cb2100$24de0dc0$6e9a2940$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsfXmkMB6dh/q8wT/OWURwxXX4KJgBobcHg Content-Language: es Subject: RE: freebsd-sparc64 Digest, Vol 380, Issue 4 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, 11 Jul 2010 13:51:26 -0000 Thanks a lot. Now it works perfectly. -----Mensaje original----- De: owner-freebsd-sparc64@freebsd.org [mailto:owner-freebsd-sparc64@freebsd.org] En nombre de freebsd-sparc64-request@freebsd.org Enviado el: viernes, 09 de julio de 2010 14:00 Para: freebsd-sparc64@freebsd.org Asunto: freebsd-sparc64 Digest, Vol 380, Issue 4 Send freebsd-sparc64 mailing list submissions to freebsd-sparc64@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 or, via email, send a message with subject or body 'help' to freebsd-sparc64-request@freebsd.org You can reach the person managing the list at freebsd-sparc64-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-sparc64 digest..." Today's Topics: 1. [head tinderbox] failure on sparc64/sparc64 (FreeBSD Tinderbox) 2. Problems conecting serial port (Sun Enterprise 250) (Narciso Martinez) ---------------------------------------------------------------------- Message: 1 Date: Fri, 9 Jul 2010 07:15:51 GMT From: FreeBSD Tinderbox Subject: [head tinderbox] failure on sparc64/sparc64 To: FreeBSD Tinderbox , , Message-ID: <201007090715.o697FpRD004593@freebsd-current.sentex.ca> TB --- 2010-07-09 06:20:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-09 06:20:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-07-09 06:20:18 - cleaning the object tree TB --- 2010-07-09 06:20:39 - cvsupping the source tree TB --- 2010-07-09 06:20:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-07-09 06:21:26 - building world TB --- 2010-07-09 06:21:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-09 06:21:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-09 06:21:26 - TARGET=sparc64 TB --- 2010-07-09 06:21:26 - TARGET_ARCH=sparc64 TB --- 2010-07-09 06:21:26 - TZ=UTC TB --- 2010-07-09 06:21:26 - __MAKE_CONF=/dev/null TB --- 2010-07-09 06:21:26 - cd /src TB --- 2010-07-09 06:21:26 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 9 06:21:27 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/panic.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/load_elf64.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/reloc_elf64.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/dev_net.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/interp_forth.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -static -nostdlib -o loader locore.o main.o metadata.o vers.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf64.o reloc_elf64.o dev_net.o interp_forth.o /obj/sparc64.sparc64/src/sys/boot/sparc64/loader/../../ficl/libficl.a /obj/sparc64.sparc64/src/sys/boot/sparc64/loader/../../ofw/libofw/libofw.a -lstand /obj/sparc64.sparc64/src/tmp/usr/lib/libstand.a(printf.o)(.text+0x4cc): In function `kvprintf': : undefined reference to `MAX' *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-07-09 07:15:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-09 07:15:51 - ERROR: failed to build world TB --- 2010-07-09 07:15:51 - 2478.18 user 559.40 system 3332.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ------------------------------ Message: 2 Date: Fri, 9 Jul 2010 12:05:10 +0200 From: Narciso Martinez Subject: Problems conecting serial port (Sun Enterprise 250) To: freebsd-sparc64@freebsd.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hello. I was trying connect with this server by serial port but I don't get it. I tried with minicom and gtkterm but I don't get it. For this conection I have to build this cable and all pins are work perfectly (multimeter), I use the next conections from this site: http://www.obsolyte.com/sunFAQ/serial/ 25 pin 9 pin pin 1 GND - pin 1 GND pin 2 TXD - pin 3 RXD pin 3 RXD - pin 3 TXD pin 4 RTS - pin 8 CTS pin 5 CTS - pin 7 RTS pin 7 gnd - pin 5 gnd pin 6 DSR - pin 4 DTR pin 20 DTR - pin 6 DSR Is this correct? What could be the problem? Thank you. ------------------------------ _______________________________________________ freebsd-sparc64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" End of freebsd-sparc64 Digest, Vol 380, Issue 4 *********************************************** From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 11 14:10:46 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 4EFF0106564A for ; Sun, 11 Jul 2010 14:10:46 +0000 (UTC) (envelope-from narcotico@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C4CB88FC13 for ; Sun, 11 Jul 2010 14:10:45 +0000 (UTC) Received: by wyb34 with SMTP id 34so3301460wyb.13 for ; Sun, 11 Jul 2010 07:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :x-cr-hashedpuzzle:x-cr-puzzleid; bh=D34/nIKgDbpQNXJY1HeQtsqP18w9LsJKxdYGNylhKLo=; b=MR8C5T2GSSXz8kYi9pAC22hRMlaM9WQV6vrQ7doG7TU+WF8pT6D6TOYZ0GnXUGUJxn RiFGMG4xlw4ZNH456q1EKD8ZI+6ZGVvpKycvZxExYAY3YdZV77eftBW1cOaWTIRFD/Vi B26wsuKvFYzW78+dviqpI7CD8SSrLml7k9g6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-cr-hashedpuzzle:x-cr-puzzleid; b=tlFr/IRBUl9TjXG/Ro9TiiCSNUdJkc93+eCCAkIvKXgk6GBsiz/k2ih4QVHk7BxL31 k8O4qnCWTTQP99rdo8SecSLybIbUWrhVOGuKwfzdMd85w+faPVxM7O8azdMOTdwZqrAn RylGKobmvu0mCCMGWnc/kgK4yv2deQb2vbcq0= Received: by 10.227.9.147 with SMTP id l19mr11382731wbl.55.1278857444486; Sun, 11 Jul 2010 07:10:44 -0700 (PDT) Received: from narcoPC (243.150.222.87.dynamic.jazztel.es [87.222.150.243]) by mx.google.com with ESMTPS id u7sm1126739weq.32.2010.07.11.07.10.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 07:10:43 -0700 (PDT) From: =?iso-8859-1?Q?Narciso_Mart=EDnez_Malnero?= To: References: <20100709120024.337FB106574B@hub.freebsd.org> In-Reply-To: <20100709120024.337FB106574B@hub.freebsd.org> Date: Sun, 11 Jul 2010 16:10:41 +0200 Message-ID: <000901cb2102$d992aa30$8cb7fe90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsfXmkMB6dh/q8wT/OWURwxXX4KJgBoezrw Content-Language: es x-cr-hashedpuzzle: AQgR ASMy BIUl CKr0 CQIv FpjJ Fv1e GNnL HsCi Hxdk IRrE IXOV JCnD JdXv Js6p J0IS; 1; ZgByAGUAZQBiAHMAZAAtAHMAcABhAHIAYwA2ADQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {7F94A3FF-2807-4126-946A-23EF5DC9173F}; bgBhAHIAYwBvAHQAaQBjAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sun, 11 Jul 2010 14:10:39 GMT; TwBwAHQAaQBtAGkAegBlACAAYwBvAG0AcABpAGwAaQBuAGcAIABmAG8AcgAgAFMAdQBuACAARQBuAHQAZQByAHAAcgBpAHMAZQAgADIANQAwAA== x-cr-puzzleid: {7F94A3FF-2807-4126-946A-23EF5DC9173F} Subject: Optimize compiling for Sun Enterprise 250 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, 11 Jul 2010 14:10:46 -0000 Hello. I would to know if there are any flags to optimize performance and = compiling time (prior the first one).=20 I've found: -mcpu=3Dv9 and mcpu=3Dultrasparc, are these flags better than default? = Which of two ones for this machine (ultrasparc II)? -mtune=3Dultrasparc -pthreads And in other site: CHOST=3D=94sparc64-unknown-linux-gnu=94 CFLAGS=3D=94-O3 -pipe -fomit-frame-pointer=94 CXXFLAGS=3D=94-O3 -pipe -fomit-frame-pointer=94 Which do you use or do you recommended? I am looking for some good configuration without problems. Thanks. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 12 11:07:09 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 47DE81065673 for ; Mon, 12 Jul 2010 11:07:09 +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 364938FC27 for ; Mon, 12 Jul 2010 11:07:09 +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 o6CB79Mr094138 for ; Mon, 12 Jul 2010 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6CB78oU094136 for freebsd-sparc64@FreeBSD.org; Mon, 12 Jul 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Jul 2010 11:07:08 GMT Message-Id: <201007121107.o6CB78oU094136@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, 12 Jul 2010 11:07:09 -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 Tue Jul 13 11:59:17 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 A835F1065675 for ; Tue, 13 Jul 2010 11:59:17 +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 45DFA8FC17 for ; Tue, 13 Jul 2010 11:59:16 +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 o6DBxFmJ035089; Tue, 13 Jul 2010 13:59:15 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6DBxFgm035088; Tue, 13 Jul 2010 13:59:15 +0200 (CEST) (envelope-from marius) Date: Tue, 13 Jul 2010 13:59:15 +0200 From: Marius Strobl To: Narciso =?unknown-8bit?Q?Mart=EDnez?= Malnero Message-ID: <20100713115915.GA35035@alchemy.franken.de> References: <20100709120024.337FB106574B@hub.freebsd.org> <000901cb2102$d992aa30$8cb7fe90$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901cb2102$d992aa30$8cb7fe90$@com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Optimize compiling for Sun Enterprise 250 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, 13 Jul 2010 11:59:17 -0000 On Sun, Jul 11, 2010 at 04:10:41PM +0200, Narciso Martnez Malnero wrote: > Hello. > > I would to know if there are any flags to optimize performance and compiling > time (prior the first one). > > I've found: > > -mcpu=v9 and mcpu=ultrasparc, are these flags better than default? Which of > two ones for this machine (ultrasparc II)? > The system compiler defaults to -mcpu=ultrasparc, which already is the most appropriate CPU type for US-II. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 15 19:38:23 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 04B88106566C for ; Thu, 15 Jul 2010 19:38:23 +0000 (UTC) (envelope-from narcotico@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8577D8FC1E for ; Thu, 15 Jul 2010 19:38:22 +0000 (UTC) Received: by wyf22 with SMTP id 22so1282261wyf.13 for ; Thu, 15 Jul 2010 12:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=DPe1pfopQJZ8a0eD5ep+jL1iY8dHnbvfAkaNCAnNioA=; b=sP6PQnyqiwUAjXdXpCleZkcDXVWhIGNcUisT7EX+82f912Pp43yRpU+4fAg1Pl4t1X +SUcvYVXbdZqmQVbanNP/HxGyZ2CqC1ENvlMEiLO9lTuNaqMQDeZmusF3zCPWOUohNjj l3K4RV1tQCjYuImeLaUU4Sm874EikhsyAzkX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=jcgzR9VziOqsR2ZWA7IrvISiQHiWFnFowVIZCr6z9HFhiOdvbly2KmLC//66pQI7Ts nNKKPtCr5NWAs0LuG6r/hvRAE0GmJPhTBhd/lbxWC2Go6mooTwJEhd+eOdQbJ7wjRmnE cU4euAQbPGCfuBWsCJ14yM38clwmgtWyLkzSQ= Received: by 10.227.146.203 with SMTP id i11mr18188718wbv.107.1279222701439; Thu, 15 Jul 2010 12:38:21 -0700 (PDT) Received: from narcoPC (243.150.222.87.dynamic.jazztel.es [87.222.150.243]) by mx.google.com with ESMTPS id v16sm336497weq.8.2010.07.15.12.38.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 12:38:20 -0700 (PDT) From: =?iso-8859-1?Q?Narciso_Mart=EDnez_Malnero?= To: Date: Thu, 15 Jul 2010 21:38:17 +0200 Message-ID: <002401cb2455$47475b70$d5d61250$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskVUYuKDwhQvojR5y66NWoriSWSw== Content-Language: es Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VNC problem in Sun E250 Without monitor, kb and mouse 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: Thu, 15 Jul 2010 19:38:23 -0000 Hello. =20 At the end, I=92ve got installing FreeBSD 8 in this machine thanks our = posts. =20 I=92ve installed X Windows and TightVNC and others.=20 =20 When I try start vncserver I get the next error: =20 =93Couldn't start Xvnc; trying default font path. Please set correct fontPath in the vncserver script. Couldn't start Xvnc process.=94 =20 For TightVNC I am using the same configuration that I have working in = other machines and the version of TightVNC is the same (amd64 with monitor, = kb, mouse). =20 I=92ve =93googled=94 a lot and probe several solutions that it works for = other people (ubuntu, red hat, =85), it didn=92t work them for me.=20 =20 Like I can=92t probe X windows I don=92t know which is the cause of the = problem. =20 The fontpath that I pass to vncserver are the same of Xorg.conf with = =96fp option. All directories exist. =20 My /etc/X11/xorg.conf is the next: =20 Section "Device" Identifier "VNC Device" Driver "vesa" EndSection =20 Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF/" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" FontPath "/usr/local/lib/X11/fonts/URW/" FontPath "/usr/local/lib/X11/fonts/TrueType/" EndSection =20 Section "Module" Load "freetype" Load "type1" Load "extmod" Load "dbe" Load "glx" Load "dri" Load "dri2" EndSection =20 Section "Screen" Identifier "VNC Screen" Device "VNC Device" Monitor "VNC Monitor" SubSection "Display" Modes "1024x768" EndSubSection EndSection =20 Section "Monitor" Identifier "VNC Monitor" HorizSync 30-70 VertRefresh 50-75 EndSection =20 If you don=92t know the solution, Which vnc server could I use on this machine that it permits X-Windows. =20 Thanks. =20 Kind Regards. From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 16 11:19:54 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 C4C201065673; Fri, 16 Jul 2010 11:19:54 +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 27D9D8FC20; Fri, 16 Jul 2010 11:19:53 +0000 (UTC) Received: by fxm13 with SMTP id 13so1081485fxm.13 for ; Fri, 16 Jul 2010 04:19:52 -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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=Q492xsPuaLvqJyd+sKLfAy60FeUMlhv8/e4tU0dkdOE=; b=gVuK7oZmtKccWm71HSEQJmbEaGaqwk1XVH1SbEN1pYCNTocpVrnYk4f4OscP9oPSUg YHMDeNU7mvV/YH975+QwC/8OaDOLUKr+hxGkMVDQqizBJEru9jcEnRDW18h3pt8q2d+B 1xO9383ZlbQG0J+LrMc+OxdKWJJbozZp6m/6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=XmyC4T4/8ufB3+1BACgRwPW4GvtfJBsQrq00ecAKUPXjqnHowbphfckan7lZ7VyrHJ na39Wo8yRzi+7FLBpNKvR9UJRc3k1vI6+31FfbOO2knTU+NadJgGdVgqkK1pyfQAz+2a GFl6iMgenc4fFLBtqOJ/ZsTU2XUOBPQ4pmPeU= Received: by 10.223.113.12 with SMTP id y12mr543474fap.36.1279279192820; Fri, 16 Jul 2010 04:19:52 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b36sm722791faq.35.2010.07.16.04.19.51 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 04:19:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C404018.6040405@FreeBSD.org> Date: Fri, 16 Jul 2010 14:18:48 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: freebsd-sparc64@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: [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: Fri, 16 Jul 2010 11:19:54 -0000 Hi. I've made a patch, updating sparc64/sun4v timer driver to utilize new MI event timer infrastructure. There are several benefits: - unified interfaces and behavior with other platforms, - support for timer in one-shot mode, - more timer hardware can be easily supported (if there any). Code works for me on UP sparc64 (SunBlade 100) and builds on sun4v. Should work on SMP, but I can't test it. Patch for HEAD can be found here: http://people.freebsd.org/~mav/timers_sparc.patch Any comments? -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 16 21:35: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 5ED491065670; Fri, 16 Jul 2010 21:35:05 +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 ACF8D8FC08; Fri, 16 Jul 2010 21:35:04 +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 o6GLZ3Gq093383; Fri, 16 Jul 2010 23:35:03 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6GLZ3hO093382; Fri, 16 Jul 2010 23:35:03 +0200 (CEST) (envelope-from marius) Date: Fri, 16 Jul 2010 23:35:03 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100716213503.GT4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C404018.6040405@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: Fri, 16 Jul 2010 21:35:05 -0000 On Fri, Jul 16, 2010 at 02:18:48PM +0300, Alexander Motin wrote: > Hi. > > I've made a patch, updating sparc64/sun4v timer driver to utilize new MI > event timer infrastructure. There are several benefits: > - unified interfaces and behavior with other platforms, > - support for timer in one-shot mode, > - more timer hardware can be easily supported (if there any). > Code works for me on UP sparc64 (SunBlade 100) and builds on sun4v. > Should work on SMP, but I can't test it. > > Patch for HEAD can be found here: > http://people.freebsd.org/~mav/timers_sparc.patch > > Any comments? > Hi, 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. Marius From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 16 22:03:36 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 BD089106566C for ; Fri, 16 Jul 2010 22:03:36 +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 45AE48FC1B for ; Fri, 16 Jul 2010 22:03:35 +0000 (UTC) Received: by fxm13 with SMTP id 13so1508975fxm.13 for ; Fri, 16 Jul 2010 15:03:35 -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=4cdoG4DWFdWPLgPDnaKFkuMxIW4CbNyfmPfWVNU9IpA=; b=o1IZn4Qb6EvQyIqszqdB50pXNeKnnp5dTRh6QOqlDP9ulVKRkcU+35riBzAkxF9UdI I+Qa/MH+GPJj3Ay2wAJeRMmxx+D5Voc6Pwdx4cyP4FyN34ke0WcGUSz83+WdtN6wG64g wqyd0PiJYWBy/OZgjRsHJZdXVvQ7oNcT92ZD4= 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=t1eBn+QVvVx+btlj885fak+c0omVdQIHuUh2gOFEOgvvNqrG1UucdbI1pqWpcQR4Bz Lw63qFI2n3KvaOc5eh+vyt698Sd3etqL1fTlso2Yt+lcHnDAq/NopYzigLHg4+zTKk9X CoEiDe9UJezYTlQxE/s2ISYDHuCv+ACC3IWns= Received: by 10.223.113.135 with SMTP id a7mr1177037faq.40.1279317814708; Fri, 16 Jul 2010 15:03:34 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e16sm916217fak.42.2010.07.16.15.03.33 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 15:03:34 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C40D6F5.6070208@FreeBSD.org> Date: Sat, 17 Jul 2010 01:02:29 +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: Fri, 16 Jul 2010 22:03:36 -0000 Marius Strobl wrote: > On Fri, Jul 16, 2010 at 02:18:48PM +0300, Alexander Motin wrote: >> I've made a patch, updating sparc64/sun4v timer driver to utilize new MI >> event timer infrastructure. There are several benefits: >> - unified interfaces and behavior with other platforms, >> - support for timer in one-shot mode, >> - more timer hardware can be easily supported (if there any). >> Code works for me on UP sparc64 (SunBlade 100) and builds on sun4v. >> Should work on SMP, but I can't test it. >> >> Patch for HEAD can be found here: >> http://people.freebsd.org/~mav/timers_sparc.patch >> >> Any comments? > > please don't commit this as-is: That is why I am asking. :) > - 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. On x86 ACPI HPET timers often run about 15MHz, i8254 - about 1.2MHz. What's wrong with 12.5MHz here? > 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. > 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'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 think it would be nice to move it to MI code. MI code knows about base frequency, so theoretically can adapt to it. May be we could fetch some additional info there, if needed. ACPI HPET timer also defines minimal reliable period, so solution could/should be common. > - 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. Does it worth code duplication? Won't it be always cached/ predicted/ prefetched? I have doubt that difference can ever be measured, as this function is minor part of things done on interrupt. > - 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. Oops, just blind copy-paste. Thank you. -- Alexander Motin From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 17 15:25:02 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 10B11106566B; Sat, 17 Jul 2010 15:25:02 +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 69F1B8FC0A; Sat, 17 Jul 2010 15:25:01 +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 o6HFP082005642; Sat, 17 Jul 2010 17:25:00 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6HFP0Hu005641; Sat, 17 Jul 2010 17:25:00 +0200 (CEST) (envelope-from marius) Date: Sat, 17 Jul 2010 17:25:00 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100717152459.GU4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C40D6F5.6070208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C40D6F5.6070208@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: Sat, 17 Jul 2010 15:25:02 -0000 On Sat, Jul 17, 2010 at 01:02:29AM +0300, Alexander Motin wrote: > Marius Strobl wrote: > > > - 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. > > On x86 ACPI HPET timers often run about 15MHz, i8254 - about 1.2MHz. > What's wrong with 12.5MHz here? When using the stick counter instead of the tick one on machines consisting of CPUs running at the same speed everything seems fine except that top(1) TIME output is implausible. Given that with this setup the only difference between using the stick and the tick counter is the frequency at which the counter is driven my best bet is that the stick counter just doesn't provide sufficient granularity. 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. > > > 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. > > > 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). > > > - 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 think it would be nice to move it to MI code. MI code knows about base > frequency, so theoretically can adapt to it. May be we could fetch some > additional info there, if needed. ACPI HPET timer also defines minimal > reliable period, so solution could/should be common. Fine > > > - 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. > > Does it worth code duplication? Won't it be always cached/ predicted/ > prefetched? I have doubt that difference can ever be measured, as this > function is minor part of things done on interrupt. I wouldn't be surprised these branches to actually make a measurable difference; f.e. moving updating the PIL counter from before calling the tick interrupt handler to incrementing it afterwards reduced the delay until it's called by 30% on average on a US-II SMP machine, in turn resulting in a more steady clock and lesser drift which needs compensation (see r157825). Besides the code already is there, just don't nuke it :) Marius From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 17 16:27:12 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 73AF0106564A for ; Sat, 17 Jul 2010 16:27:12 +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 EF9B68FC16 for ; Sat, 17 Jul 2010 16:27:11 +0000 (UTC) Received: by fxm13 with SMTP id 13so1742561fxm.13 for ; Sat, 17 Jul 2010 09:27:10 -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=Gf1WMKi5PZcgF/XDjp32jINCicIARkST7d9q1/h79mA=; b=XxubpfHz5o16E02iGXCHWNyCspkoQZM/jPOPw/CixiR3JoltgxyDWNdAiO8EL1GUoG aKIa68foVPQSiuxJmofDAmNvD/dD7rX6N6j8fVaBtWIahowoP1yt/YkhzMo/nGBDalul fFUPggew73nJRmNPr1UBkFzfSUeE2l+z2tPjc= 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=U6sXV5Ekt5rKeSXXFKJzIVYKn4HmBRMM86D8zbfJFhvG4ioa603aY3LLxBk+oGZYz7 5be4GUqq/GYSHwCFCN147RaHN2yE005qzz5dzxBuJmcQ828dchYCEF0LQLx0WsvvThbI PcKY7oqwOks01UwJUTtR4N1Qgae3I0ev55SBg= Received: by 10.223.104.146 with SMTP id p18mr1802070fao.10.1279384030804; Sat, 17 Jul 2010 09:27:10 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r8sm1232208faq.34.2010.07.17.09.27.09 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 09:27:10 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C41D99B.10202@FreeBSD.org> Date: Sat, 17 Jul 2010 19:26:03 +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> <4C40D6F5.6070208@FreeBSD.org> <20100717152459.GU4706@alchemy.franken.de> In-Reply-To: <20100717152459.GU4706@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: Sat, 17 Jul 2010 16:27:12 -0000 Marius Strobl wrote: > On Sat, Jul 17, 2010 at 01:02:29AM +0300, Alexander Motin wrote: >> Marius Strobl wrote: >>> - 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. >> On x86 ACPI HPET timers often run about 15MHz, i8254 - about 1.2MHz. >> What's wrong with 12.5MHz here? > > When using the stick counter instead of the tick one on machines > consisting of CPUs running at the same speed everything seems fine > except that top(1) TIME output is implausible. Given that with > this setup the only difference between using the stick and the tick > counter is the frequency at which the counter is driven my best > bet is that the stick counter just doesn't provide sufficient > granularity. 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. > 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. >>> 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. 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. >>> 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 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. >> Does it worth code duplication? Won't it be always cached/ predicted/ >> prefetched? I have doubt that difference can ever be measured, as this >> function is minor part of things done on interrupt. > > I wouldn't be surprised these branches to actually make a measurable > difference; f.e. moving updating the PIL counter from before calling > the tick interrupt handler to incrementing it afterwards reduced the > delay until it's called by 30% on average on a US-II SMP machine, in > turn resulting in a more steady clock and lesser drift which needs > compensation (see r157825). Besides the code already is there, just > don't nuke it :) As you wish. -- Alexander Motin