From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 4 20:59:47 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EFAC16A4CE for ; Sun, 4 Jan 2004 20:59:47 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5645C43D45 for ; Sun, 4 Jan 2004 20:59:46 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id i054xcvT054642; Sun, 4 Jan 2004 20:59:38 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id i054xbsH054641; Sun, 4 Jan 2004 20:59:37 -0800 (PST) (envelope-from obrien) Date: Sun, 4 Jan 2004 20:59:37 -0800 From: "David O'Brien" To: Garance A Drosihn , Harti Brandt Message-ID: <20040105045937.GC25184@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20031222080115.GA645@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-sparc64@freebsd.org Subject: Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2004 04:59:47 -0000 On Mon, Dec 22, 2003 at 02:16:30PM -0500, Garance A Drosihn wrote: > Note that there it is likely we will switch sparc64 to a > 64-bit time_t before 5.3 is released. We talked about making > that change sometime in January, once we would be sure that > 5.2-release was settled. On Tue, Dec 23, 2003 at 10:09:53AM +0100, Harti Brandt wrote: > time_t is a long on Solaris and hence 64bit (when compiling in 64-bit > mode). Compatibility (with Solaris and Posix) requires time_t to be > 64-bit > and tv_sec to be a time_t. I hope we will get this right until > 5.3 goes out. I'm running with a 64-bit time_t for two months now > without problems. Before the tree starts to get disruptive and unstable on the push to 5.3; maybe this is a good time to make the switch to 64-bit time_t for sparc64. -- David From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 5 11:03:11 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8458216A4D0 for ; Mon, 5 Jan 2004 11:03:11 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2811E43D8F for ; Mon, 5 Jan 2004 11:01:42 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i05J1fFR016134 for ; Mon, 5 Jan 2004 11:01:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i05J1e7J016128 for freebsd-sparc64@freebsd.org; Mon, 5 Jan 2004 11:01:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 5 Jan 2004 11:01:41 -0800 (PST) Message-Id: <200401051901.i05J1e7J016128@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2004 19:03:11 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/12/16] sparc64/60300sparc64 Constant kernel messages: calcru: negativ 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/24] sparc64/53670sparc64 pthreads implementation on 5.1-Release sp 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/02/03] sparc64/47845sparc64 4 second daily clock drift a [2003/10/10] sparc64/57856sparc64 sparc64: IDE Raid controller no detect di 2 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 5 16:20:12 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4125516A4CE; Mon, 5 Jan 2004 16:20:12 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A16643D46; Mon, 5 Jan 2004 16:20:07 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) i060K6v9094099; Mon, 5 Jan 2004 19:20:06 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id i060K6PB094098; Mon, 5 Jan 2004 19:20:06 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Mon, 5 Jan 2004 19:20:06 -0500 (EST) Message-Id: <200401060020.i060K6PB094098@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 00:20:12 -0000 TB --- 2004-01-06 00:12:54 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2004-01-06 00:12:54 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-01-06 00:12:54 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-01-06 00:15:41 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> 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 [...] cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\" -DCROSS_COMPILE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"sparc64-undermydesk-freebsd\" -DIN_GCC -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc6! 4/src/i386/legacy/usr/include -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/final.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\" -DCROSS_COMPILE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"sparc64-undermydesk-freebsd\" -DIN_GCC -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc6! 4/src/i386/legacy/usr/include -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/flow.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\" -DCROSS_COMPILE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"sparc64-undermydesk-freebsd\" -DIN_GCC -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc6! 4/src/i386/legacy/usr/include -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/fold-const.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\" -DCROSS_COMPILE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"sparc64-undermydesk-freebsd\" -DIN_GCC -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc6! 4/src/i386/legacy/usr/include -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/function.c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/function.c: In function `expand_function_end': /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/function.c:7000: error: `TARGET_PROFILER_EPILOGUE' undeclared (first use in this function) /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/function.c:7000: error: (Each undeclared identifier is reported only once /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/function.c:7000: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-01-06 00:20:06 - TB --- /usr/bin/make returned exit code 1 TB --- 2004-01-06 00:20:06 - TB --- ERROR: failed to build world TB --- 2004-01-06 00:20:06 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 5 19:18:45 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA1316A4CE for ; Mon, 5 Jan 2004 19:18:45 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B82A43D1D for ; Mon, 5 Jan 2004 19:18:44 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i063Ihlb002790 for ; Mon, 5 Jan 2004 22:18:43 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Mon, 5 Jan 2004 22:18:42 -0500 To: sparc64@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Minor sparc64 install-time questions X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 03:18:46 -0000 I just did an install of 5.2-rc2 on my Sparc Ultra-10 machine. That seems to have gone fine, but I have two questions. Right after booting up, the user is asked to pick a terminal type, from: 1 - standard ansi terminal 2 - vt100 or compatible 3 - freebsd system console (color) 4 - freebsd system console (mono) 5 - xterm terminal emulator None of those worked particularly great for me, although all of them seemed to work "to some degree". I finally decided on choice #2, as that seemed to work the best in the disklabel step. How does one know which to pick? - - - Also, is there any way to have more than 7 BSD partitions (in addition to 'c', of course) on a single hard disk? - - - Also, are we supposed to be using 'bsdlabel' instead of 'disklabel' now? I assume so, since there is no disklabel installed in my system... When I go to run bsdlabel, it tells me that I *must* specify a -m architecture, even though the man page indicates that is optional. The man page also does not say what valid values for 'arch' are (neither does the program). Looking at the source, it seems that nothing sparc-ish is listed as a valid option. I can do disklabeling chores via sysinstall, where it both works and also claims that it's the 'FreeBSD Disklabel Editor'. - - - One last question, which may do nothing more than show how I am ignorant of some details. After the install of 5.2-RC2 onto a clean disk, /lib has a variety of "versioned" libraries, such as libutil.so.4. However, it does not include any symlinks from the non-versioned name (eg: libutil.so) to one of the versioned files. /usr/lib does seem to include such symlinks, as does /lib on my freebsd/i386 system. Is this how /lib is expected to be on a new sparc64 install? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 5 20:36:29 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E903716A4CE for ; Mon, 5 Jan 2004 20:36:29 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C4243D45 for ; Mon, 5 Jan 2004 20:36:28 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i064aI3s003830; Mon, 5 Jan 2004 23:36:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040105045937.GC25184@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20031222080115.GA645@server.vk2pj.dyndns.org> <20040105045937.GC25184@dragon.nuxi.com> Date: Mon, 5 Jan 2004 23:36:17 -0500 To: Harti Brandt From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-sparc64@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 04:36:30 -0000 In the thread on Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) David O'Brien wrote: >On Mon, Dec 22, 2003, Garance A Drosihn wrote: > > Note that there it is likely we will switch sparc64 to a >> 64-bit time_t before 5.3 is released. We talked about making >> that change sometime in January, once we would be sure that >> 5.2-release was settled. > >On Tue, Dec 23, 2003, Harti Brandt wrote: > > time_t is a long on Solaris and hence 64bit (when compiling > > in 64-bit mode). Compatibility (with Solaris and Posix) > > requires time_t to be 64-bit and tv_sec to be a time_t. > > I'm running with a 64-bit time_t for two months now > > without problems. > >Before the tree starts to get disruptive and unstable on the >push to 5.3; maybe this is a good time to make the switch to >64-bit time_t for sparc64. I think this is a good idea. I just finished a clean install of 5.2-RC2 on my ultra-10, and I'm building a few of my favorite ports on that. I'll then duplicate that install to alternate partitions, and see what happens when updating that to a 64-bit time_t. So, all I need to change is the line: typedef __int32_t __time_t; in /usr/src/sys/sparc64/include/_types.h and the line: long tv_sec; /* seconds (XXX should be time_t) */ in /usr/src/sys/sys/_timeval.h Most the other definitions of tv_sec that I found are already using time_t. Btw, I noticed: sys/netinet/ip_fw.h: u_int32_t timestamp; /* tv_sec of last match*/ sys/netinet6/ip6_fw.h: long timestamp; /* timestamp (tv_sec) of last match */ but I haven't looked at the code to see how much we care about those two references. Anything else, Harti? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 5 23:32:08 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B882F16A4CE for ; Mon, 5 Jan 2004 23:32:08 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6159743D45 for ; Mon, 5 Jan 2004 23:32:06 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 27682 invoked from network); 6 Jan 2004 07:32:05 -0000 Received: from dsl017-045-168.spk4.dsl.speakeasy.net (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Jan 2004 07:32:05 -0000 Received: from hydrogen.funkthat.com (rahsrq@localhost.funkthat.com [127.0.0.1])i067W5j2022804; Mon, 5 Jan 2004 23:32:05 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i067W4xf022803; Mon, 5 Jan 2004 23:32:04 -0800 (PST) Date: Mon, 5 Jan 2004 23:32:04 -0800 From: John-Mark Gurney To: Garance A Drosihn Message-ID: <20040106073204.GD74366@funkthat.com> Mail-Followup-To: Garance A Drosihn , sparc64@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: sparc64@freebsd.org Subject: Re: Minor sparc64 install-time questions X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 07:32:09 -0000 Garance A Drosihn wrote this message on Mon, Jan 05, 2004 at 22:18 -0500: > I just did an install of 5.2-rc2 on my Sparc Ultra-10 machine. > That seems to have gone fine, but I have two questions. > > Right after booting up, the user is asked to pick a terminal > type, from: > 1 - standard ansi terminal > 2 - vt100 or compatible > 3 - freebsd system console (color) > 4 - freebsd system console (mono) > 5 - xterm terminal emulator > > None of those worked particularly great for me, although all > of them seemed to work "to some degree". I finally decided on > choice #2, as that seemed to work the best in the disklabel > step. How does one know which to pick? You need to know what type of terminal you are using. If you are using Windows Terminal, then 1 is probably best.. xterm + tip on another box, then 5... console + tip on a FreeBSD box, then 3 or 4.. > Also, is there any way to have more than 7 BSD partitions (in > addition to 'c', of course) on a single hard disk? possibly add another label to one of the partitions... I haven't tried this, but it should work.. :) > Also, are we supposed to be using 'bsdlabel' instead of > 'disklabel' now? I assume so, since there is no disklabel > installed in my system... When I go to run bsdlabel, it tells > me that I *must* specify a -m architecture, even though the > man page indicates that is optional. The man page also does > not say what valid values for 'arch' are (neither does the > program). Looking at the source, it seems that nothing > sparc-ish is listed as a valid option. on sparc you need to be using sunlabel to be compatible with openboot to be able to boot the disk.. > I can do disklabeling chores via sysinstall, where it both > works and also claims that it's the 'FreeBSD Disklabel Editor'. Yep, lots of people use sysinstall for this.. > One last question, which may do nothing more than show how > I am ignorant of some details. After the install of 5.2-RC2 > onto a clean disk, /lib has a variety of "versioned" libraries, > such as libutil.so.4. However, it does not include any symlinks > from the non-versioned name (eg: libutil.so) to one of the > versioned files. /usr/lib does seem to include such symlinks, > as does /lib on my freebsd/i386 system. Is this how /lib is > expected to be on a new sparc64 install? My upgraded (from source) system is the same way. I haven't had any problems, though I haven't used it much.. so I guess it's the way it's suppose to be.. :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 01:17:28 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6739E16A4CE for ; Tue, 6 Jan 2004 01:17:28 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D01BE43D1F for ; Tue, 6 Jan 2004 01:17:25 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i069HLL06387; Tue, 6 Jan 2004 10:17:22 +0100 (MET) Date: Tue, 6 Jan 2004 10:17:21 +0100 (CET) From: Harti Brandt To: Garance A Drosihn In-Reply-To: Message-ID: <20040106095942.O66232@beagle.fokus.fraunhofer.de> References: <200312212239.38557.craig@xfoil.gank.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 09:17:28 -0000 On Mon, 5 Jan 2004, Garance A Drosihn wrote: GAD>In the thread on GAD> Re: An experiment: 64-bit time_t on IA-32 (5.2-RC) GAD>David O'Brien wrote: GAD>>On Mon, Dec 22, 2003, Garance A Drosihn wrote: GAD>> > Note that there it is likely we will switch sparc64 to a GAD>>> 64-bit time_t before 5.3 is released. We talked about making GAD>>> that change sometime in January, once we would be sure that GAD>>> 5.2-release was settled. GAD>> GAD>>On Tue, Dec 23, 2003, Harti Brandt wrote: GAD>> > time_t is a long on Solaris and hence 64bit (when compiling GAD>> > in 64-bit mode). Compatibility (with Solaris and Posix) GAD>> > requires time_t to be 64-bit and tv_sec to be a time_t. GAD>> > I'm running with a 64-bit time_t for two months now GAD>> > without problems. GAD>> GAD>>Before the tree starts to get disruptive and unstable on the GAD>>push to 5.3; maybe this is a good time to make the switch to GAD>>64-bit time_t for sparc64. GAD> GAD>I think this is a good idea. I just finished a clean install of GAD>5.2-RC2 on my ultra-10, and I'm building a few of my favorite GAD>ports on that. I'll then duplicate that install to alternate GAD>partitions, and see what happens when updating that to a 64-bit GAD>time_t. GAD> GAD>So, all I need to change is the line: GAD> typedef __int32_t __time_t; GAD> GAD>in /usr/src/sys/sparc64/include/_types.h GAD>and the line: GAD> long tv_sec; /* seconds (XXX should be time_t) */ GAD> GAD>in /usr/src/sys/sys/_timeval.h GAD> GAD>Most the other definitions of tv_sec that I found are GAD>already using time_t. Btw, I noticed: GAD>sys/netinet/ip_fw.h: GAD> u_int32_t timestamp; /* tv_sec of last match*/ GAD>sys/netinet6/ip6_fw.h: GAD> long timestamp; /* timestamp (tv_sec) of last match */ GAD> GAD>but I haven't looked at the code to see how much we care about GAD>those two references. GAD> GAD>Anything else, Harti? That's just what I did. The real problem is the upgrade procedure and whether we will force people to recompile everything (and not provide a compatibility library). Providing a compat library would require a library version bump, correct? We are already at 5 so we can't do this. Given that there is no stable, we can argument that's how current is and go with that (and that's the reason for doing the change now). The only problem with the upgrade procedure I had was with tic, that for some reason got into an endless loop when running on the wrong kernel. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 07:50:50 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E08516A4CE for ; Tue, 6 Jan 2004 07:50:50 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A87543D48 for ; Tue, 6 Jan 2004 07:50:49 -0800 (PST) (envelope-from salgatt@turtleshell.net) Received: from mail.turtleshell.net ([69.139.82.199]) by comcast.net (rwcrmhc13) with SMTP id <2004010615504801500ss417e>; Tue, 6 Jan 2004 15:50:48 +0000 Received: (qmail 94536 invoked from network); 6 Jan 2004 15:41:20 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost.internal.turtleshell.net with SMTP; 6 Jan 2004 15:41:20 -0000 Date: Tue, 6 Jan 2004 10:41:20 -0500 (EST) From: "Scott M. Algatt" X-X-Sender: turtle@lithagus.turtleshell.net To: freebsd-sparc64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61-turtle (1.212.2.1-2003-12-09-exp) on lithagus.turtleshell.net X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=8.0 tests=BAYES_00 autolearn=ham version=2.61-turtle Subject: Jumpstart install.cfg X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Scott M. Algatt" List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 15:50:50 -0000 I am at my wit's end and was hoping someone might be able to help me. I am running both 5.2-BETA and 5.1-RELEASE on Ultra 5's. I wanted to go the jumpstart route and try to configure a FreeBSD jumpstart server that will install other FreeBSD machines for me. It seems that I have almost every piece in place except for the install.cfg file for sysinstall. The machine boots from the network and reads the install.cfg but errors out with /: filesystem is full. Regards, Scott M. Algatt Behold the turtle. He makes progress only when he sticks his neck out. From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 10:28:33 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08EC516A4CE; Tue, 6 Jan 2004 10:28:33 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D487443D5E; Tue, 6 Jan 2004 10:28:25 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id i06ISOvT042649; Tue, 6 Jan 2004 10:28:24 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id i06ISOw7042648; Tue, 6 Jan 2004 10:28:24 -0800 (PST) (envelope-from obrien) Date: Tue, 6 Jan 2004 10:28:24 -0800 From: "David O'Brien" To: harti@freebsd.org Message-ID: <20040106182824.GA42422@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106095942.O66232@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-sparc64@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-sparc64@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 18:28:33 -0000 On Tue, Jan 06, 2004 at 10:17:21AM +0100, Harti Brandt wrote: > That's just what I did. The real problem is the upgrade procedure and > whether we will force people to recompile everything (and not provide a > compatibility library). I think we can have a 'Flag Day' and not deal with a compat lib. > The only problem with the upgrade procedure I had was with tic, that > for some reason got into an endless loop when running on the wrong kernel. We would need a fool-proof procedure for going from say a 5.0-R install to post 64-bit time_t. -- -- David (obrien@FreeBSD.org) From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 10:34:17 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7608416A4D1 for ; Tue, 6 Jan 2004 10:34:17 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B2AB43D54 for ; Tue, 6 Jan 2004 10:34:13 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i06IY9AI005626; Tue, 6 Jan 2004 13:34:09 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040106073204.GD74366@funkthat.com> References: <20040106073204.GD74366@funkthat.com> Date: Tue, 6 Jan 2004 13:34:08 -0500 To: John-Mark Gurney From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: sparc64@freebsd.org Subject: Re: Minor sparc64 install-time questions X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 18:34:17 -0000 At 11:32 PM -0800 1/5/04, John-Mark Gurney wrote: >Garance A Drosihn wrote on Mon, Jan 05, 2004: > > Right after booting up, the user is asked to pick a terminal >> type, from: >> 1 - standard ansi terminal >> 2 - vt100 or compatible >> 3 - freebsd system console (color) >> 4 - freebsd system console (mono) >> 5 - xterm terminal emulator >> > > None of those worked particularly great for me, although > > all of them seemed to work "to some degree". I finally > > decided on choice #2, as that seemed to work the best in > > the disklabel step. How does one know which to pick? > >You need to know what type of terminal you are using. If >you are using Windows Terminal, then 1 is probably best.. >xterm + tip on another box, then 5... console + tip on a >FreeBSD box, then 3 or 4.. I am sitting at the ultra-sparc, with a sun keyboard and a monitor attached to the video card. Just me, the Ultra-10 and the installation CD. So, I guess that would be called the "openfirmware console", or something. I'm not much of a sun-hardware expert, so I'm not sure what to be looking for in dmesg. The only video-ish line that I see in dmesg is: pci1: at device 2.0 (no driver attached) (reminder: I did get through the install fine, I'm just curious what the best answer is for the terminal-type) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 6 21:08:21 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FDD116A4CE; Tue, 6 Jan 2004 21:08:21 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060D343D45; Tue, 6 Jan 2004 21:08:20 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i0758FLJ027335; Wed, 7 Jan 2004 00:08:19 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040106182824.GA42422@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> Date: Wed, 7 Jan 2004 00:08:13 -0500 To: freebsd-sparc64@freebsd.org, harti@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 05:08:21 -0000 At 10:28 AM -0800 1/6/04, David O'Brien wrote: >On Tue, Jan 06, 2004, Harti Brandt wrote: > > That's just what I did. The real problem is the upgrade > > procedure and whether we will force people to recompile > > everything (and not provide a compatibility library). > >I think we can have a 'Flag Day' and not deal with a compat lib. That's what I was going to shoot for. While I did not get a lot of reaction to my previous messages in November, it seemed that most people thought we should just make the change. > > The only problem with the upgrade procedure I had was with > > tic, that for some reason got into an endless loop when > > running on the wrong kernel. > >We would need a fool-proof procedure for going from say a >5.0-R install to post 64-bit time_t. How flexible should we be? My first thought is to tell people: 1) upgrade to RELENG_5_2 2) *after* you know that upgrade worked, then run a patch file (which will already be in /usr/src?), which will modify the appropriate files needed for this change. 3) rebuild after making just that one change. No cvsup. 3a) ...details to be filled in... 3b) ...blah blah, rebuild key ports, etc etc... 4) change your cvsup files to tag=. Or we could do a more flexible version, combining a -Define in CFLAGS (set in /etc/make.conf), along with some extra magic when installing the include files during 'make installworld'. Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64. The remaining steps would be the same, but users could flip the switch at whatever time they wanted, instead of being forced to upgrade to RELENG_5_2. I think users should still do a "double install", where they first have to get thru a successful install at one point, and then modify the setting in /etc/make.conf and immediately do a second install. I think it is a good idea to have everyone upgrade to RELENG_5_2 first anyway, because we already have quite a lot of changes between 5.0-Release and RELENG_5_2. However, I'd be willing to work towards the second idea if other sparc users really want the more flexible option. I realize I skipped over the important details in "step 3", but I hope to start filling those in later this week or the weekend. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 7 09:45:32 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD39C16A4D0; Wed, 7 Jan 2004 09:45:32 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCA2943D78; Wed, 7 Jan 2004 09:44:00 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id i07HhkvT055300; Wed, 7 Jan 2004 09:43:46 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id i07HhkCJ055299; Wed, 7 Jan 2004 09:43:46 -0800 (PST) (envelope-from obrien) Date: Wed, 7 Jan 2004 09:43:46 -0800 From: "David O'Brien" To: Garance A Drosihn Message-ID: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: harti@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-sparc64@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 17:45:33 -0000 On Wed, Jan 07, 2004 at 12:08:13AM -0500, Garance A Drosihn wrote: > How flexible should we be? My first thought is to tell people: > > 1) upgrade to RELENG_5_2 > 2) *after* you know that upgrade worked, then run a patch > file (which will already be in /usr/src?), which will > modify the appropriate files needed for this change. > 3) rebuild after making just that one change. No cvsup. I think it has to all be doable given a CVS archive, no external patches. If need be: cvs up -Pd -r RELENG_5_2 make buildworld make kernel reboot make installworld cvs up -Pd -D '' make ... ---\ reboot | what ever is the debugged order to do things... make ... ---/ cvs up -PdA make buildworld make kernel reboot make installworld > Or we could do a more flexible version, combining a -Define in > CFLAGS (set in /etc/make.conf), along with some extra magic > when installing the include files during 'make installworld'. > Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64. I think we should only do this if we can't achieve this as above. > The remaining steps would be the same, but users could flip > the switch at whatever time they wanted, instead of being > forced to upgrade to RELENG_5_2. I think that will be a nightmare of too much potential for people doing it wrong. From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 7 18:15:16 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A067C16A4CE for ; Wed, 7 Jan 2004 18:15:16 -0800 (PST) Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id C46B043D1D for ; Wed, 7 Jan 2004 18:15:15 -0800 (PST) (envelope-from adudek@gwu.edu) Received: from dialup-171.75.39.139.dial1.washington1.level3.net ([171.75.39.139] helo=[127.0.0.1]) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AePhY-0001Rw-00 for freebsd-sparc64@freebsd.org; Wed, 07 Jan 2004 18:15:13 -0800 Date: Wed, 07 Jan 2004 21:15:14 -0500 From: Aaron Dudek To: freebsd-sparc64@freebsd.org Message-Id: <20040107211253.0646.ADUDEK@gwu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [en] Subject: slowness with USB keyboard.... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 02:15:16 -0000 I am happy to see that the USB keyboard is now supported with 5.2-RC. I am curious if anyone else is seeing slow response times when using it on a Blade 100? Would removing the debugging info improve speed or should this be corrected by release? Thanks -- Aaron Dudek From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 8 01:41:17 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5094C16A4CE for ; Thu, 8 Jan 2004 01:41:17 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1905443D1D for ; Thu, 8 Jan 2004 01:41:16 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 0FFF95C7F6; Thu, 8 Jan 2004 01:41:16 -0800 (PST) Date: Thu, 8 Jan 2004 10:41:16 +0100 From: Maxime Henrion To: sparc64@FreeBSD.org Message-ID: <20040108094116.GU2060@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Need testers for patch to get MAC address of integrated dc(4) cards X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 09:41:17 -0000 --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I've tweaked Marius' patch to properly get the MAC address of the integrated Davicom cards found in some sparc64 boxes from OpenFirmware without breaking the build of the dc(4) module. I'd like to get this tested as soon as possible because this patch should go into 5.2-RELEASE and we don't have much time left. Since I don't have the necessary hardware to test it myself, I need your help guys :-). For what it's worth, putting the code into an OF_getetheraddr2() function is a bit crude, but since Marius experienced difficulties merging it into OF_getetheraddr(), I chose to stay on the safe side. This can be revisited later. Thanks, Maxime --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dc.patch" Index: pci/if_dc.c =================================================================== RCS file: /space/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.137 diff -u -r1.137 if_dc.c --- pci/if_dc.c 6 Dec 2003 02:29:31 -0000 1.137 +++ pci/if_dc.c 7 Jan 2004 23:32:51 -0000 @@ -131,6 +131,11 @@ #include +#ifdef __sparc64__ +#include +#include +#endif + MODULE_DEPEND(dc, pci, 1, 1, 1); MODULE_DEPEND(dc, ether, 1, 1, 1); MODULE_DEPEND(dc, miibus, 1, 1, 1); @@ -2106,6 +2111,19 @@ dc_read_eeprom(sc, (caddr_t)&eaddr, 0, 3, 1); break; case DC_TYPE_DM9102: + dc_read_eeprom(sc, (caddr_t)&eaddr, DC_EE_NODEADDR, 3, 0); +#ifdef __sparc64__ + /* + * If this is an onboard dc(4) the station address read from + * the EEPROM is all zero and we have to get it from the fcode. + */ + for (i = 0; i < ETHER_ADDR_LEN; i++) + if (eaddr[i] != 0x00) + break; + if (i >= ETHER_ADDR_LEN && OF_getetheraddr2(dev, eaddr) == -1) + OF_getetheraddr(dev, eaddr); +#endif + break; case DC_TYPE_21143: case DC_TYPE_ASIX: dc_read_eeprom(sc, (caddr_t)&eaddr, DC_EE_NODEADDR, 3, 0); Index: sparc64/sparc64/ofw_machdep.c =================================================================== RCS file: /space/ncvs/src/sys/sparc64/sparc64/ofw_machdep.c,v retrieving revision 1.6 diff -u -r1.6 ofw_machdep.c --- sparc64/sparc64/ofw_machdep.c 26 Dec 2003 14:30:19 -0000 1.6 +++ sparc64/sparc64/ofw_machdep.c 7 Jan 2004 23:44:38 -0000 @@ -29,6 +29,8 @@ * Some OpenFirmware helper functions that are likely machine dependent. */ +#include "opt_ofw_pci.h" + #include #include @@ -56,6 +58,21 @@ if (node <= 0 || OF_getprop(node, "idprom", &idp, sizeof(idp)) == -1) panic("Could not determine the machine ethernet address"); bcopy(&idp.id_ether, addr, ETHER_ADDR_LEN); +} + +int +OF_getetheraddr2(device_t dev, u_char *addr) +{ + phandle_t node; + +#ifdef OFW_NEWPCI + node = ofw_pci_get_node(dev); +#else + node = ofw_pci_node(dev); +#endif + if (node <= 0) + return (-1); + return (OF_getprop(node, "local-mac-address", addr, ETHER_ADDR_LEN)); } int --XMCwj5IQnwKtuyBG-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 8 08:59:22 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3324C16A4CE; Thu, 8 Jan 2004 08:59:22 -0800 (PST) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC25543D78; Thu, 8 Jan 2004 08:58:40 -0800 (PST) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i08Gwe9J098097; Thu, 8 Jan 2004 17:58:40 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i08GwZ4o098096; Thu, 8 Jan 2004 17:58:35 +0100 (CET) (envelope-from marius) Date: Thu, 8 Jan 2004 17:58:35 +0100 From: Marius Strobl To: Maxime Henrion Message-ID: <20040108175835.A95298@newtrinity.zeist.de> References: <20040108094116.GU2060@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040108094116.GU2060@elvis.mu.org>; from mux@freebsd.org on Thu, Jan 08, 2004 at 10:41:16AM +0100 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.23.0.2; VDF 6.23.0.26 cc: sparc64@freebsd.org Subject: Re: Need testers for patch to get MAC address of integrated dc(4) cards X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 16:59:22 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 08, 2004 at 10:41:16AM +0100, Maxime Henrion wrote: > Hi all, > > > > I've tweaked Marius' patch to properly get the MAC address of the > integrated Davicom cards found in some sparc64 boxes from OpenFirmware > without breaking the build of the dc(4) module. I'd like to get this > tested as soon as possible because this patch should go into 5.2-RELEASE > and we don't have much time left. Since I don't have the necessary > hardware to test it myself, I need your help guys :-). > > For what it's worth, putting the code into an OF_getetheraddr2() > function is a bit crude, but since Marius experienced difficulties > merging it into OF_getetheraddr(), I chose to stay on the safe side. > This can be revisited later. > Please use the attached version instead, it has two changes over Maxime's version: - Fix compilation by adding a prototype for OF_getetheraddr2(). - Add a debugging printf for an issue I had with my version of OF_getetheraddr() to really make sure it works as expected. The patch is compile tested but otherwise not (yet) tested on my side. I probably won't be able to really test it in time for getting it into 5.2-RELEASE, so if you own a Netra X1 or a Sunfire V100 please give it a try an reply with all the dcX lines you get in /var/run/dmesg.boot. Thanks. --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dc.patch2" Index: pci/if_dc.c =================================================================== RCS file: /usr/data/bsd/cvs/fbsd/src/sys/pci/if_dc.c,v retrieving revision 1.138 diff -u -r1.138 if_dc.c --- pci/if_dc.c 8 Jan 2004 06:22:15 -0000 1.138 +++ pci/if_dc.c 8 Jan 2004 14:22:26 -0000 @@ -131,6 +131,11 @@ #include +#ifdef __sparc64__ +#include +#include +#endif + MODULE_DEPEND(dc, pci, 1, 1, 1); MODULE_DEPEND(dc, ether, 1, 1, 1); MODULE_DEPEND(dc, miibus, 1, 1, 1); @@ -2106,6 +2111,19 @@ dc_read_eeprom(sc, (caddr_t)&eaddr, 0, 3, 1); break; case DC_TYPE_DM9102: + dc_read_eeprom(sc, (caddr_t)&eaddr, DC_EE_NODEADDR, 3, 0); +#ifdef __sparc64__ + /* + * If this is an onboard dc(4) the station address read from + * the EEPROM is all zero and we have to get it from the fcode. + */ + for (i = 0; i < ETHER_ADDR_LEN; i++) + if (eaddr[i] != 0x00) + break; + if (i >= ETHER_ADDR_LEN && OF_getetheraddr2(dev, eaddr) == -1) + OF_getetheraddr(dev, eaddr); +#endif + break; case DC_TYPE_21143: case DC_TYPE_ASIX: dc_read_eeprom(sc, (caddr_t)&eaddr, DC_EE_NODEADDR, 3, 0); Index: sparc64/include/ofw_machdep.h =================================================================== RCS file: /usr/data/bsd/cvs/fbsd/src/sys/sparc64/include/ofw_machdep.h,v retrieving revision 1.3 diff -u -r1.3 ofw_machdep.h --- sparc64/include/ofw_machdep.h 2 Sep 2003 20:32:12 -0000 1.3 +++ sparc64/include/ofw_machdep.h 8 Jan 2004 16:27:28 -0000 @@ -32,6 +32,7 @@ int OF_decode_addr(phandle_t, int *, bus_addr_t *); void OF_getetheraddr(device_t, u_char *); +int OF_getetheraddr2(device_t, u_char *); void cpu_shutdown(void *); void openfirmware_exit(void *); Index: sparc64/sparc64/ofw_machdep.c =================================================================== RCS file: /usr/data/bsd/cvs/fbsd/src/sys/sparc64/sparc64/ofw_machdep.c,v retrieving revision 1.6 diff -u -r1.6 ofw_machdep.c --- sparc64/sparc64/ofw_machdep.c 26 Dec 2003 14:30:19 -0000 1.6 +++ sparc64/sparc64/ofw_machdep.c 8 Jan 2004 14:49:18 -0000 @@ -29,6 +29,8 @@ * Some OpenFirmware helper functions that are likely machine dependent. */ +#include "opt_ofw_pci.h" + #include #include @@ -56,6 +58,23 @@ if (node <= 0 || OF_getprop(node, "idprom", &idp, sizeof(idp)) == -1) panic("Could not determine the machine ethernet address"); bcopy(&idp.id_ether, addr, ETHER_ADDR_LEN); +} + +int +OF_getetheraddr2(device_t dev, u_char *addr) +{ + phandle_t node; + +#ifdef OFW_NEWPCI + node = ofw_pci_get_node(dev); +#else + node = ofw_pci_node(dev); +#endif + if (node <= 0) { + device_printf(dev, "OF_getetheraddr2: invalid node.\n"); + return (-1); + } + return (OF_getprop(node, "local-mac-address", addr, ETHER_ADDR_LEN)); } int --ZfOjI3PrQbgiZnxM-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 8 09:03:35 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 320EB16A4CE for ; Thu, 8 Jan 2004 09:03:35 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D105E43D7E for ; Thu, 8 Jan 2004 09:03:31 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id C19905C746; Thu, 8 Jan 2004 09:03:31 -0800 (PST) Date: Thu, 8 Jan 2004 18:03:31 +0100 From: Maxime Henrion To: Marius Strobl Message-ID: <20040108170331.GW2060@elvis.mu.org> References: <20040108094116.GU2060@elvis.mu.org> <20040108175835.A95298@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108175835.A95298@newtrinity.zeist.de> User-Agent: Mutt/1.4.1i cc: sparc64@freebsd.org Subject: Re: Need testers for patch to get MAC address of integrated dc(4) cards X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 17:03:35 -0000 Marius Strobl wrote: > On Thu, Jan 08, 2004 at 10:41:16AM +0100, Maxime Henrion wrote: > > Hi all, > > > > > > > > I've tweaked Marius' patch to properly get the MAC address of the > > integrated Davicom cards found in some sparc64 boxes from OpenFirmware > > without breaking the build of the dc(4) module. I'd like to get this > > tested as soon as possible because this patch should go into 5.2-RELEASE > > and we don't have much time left. Since I don't have the necessary > > hardware to test it myself, I need your help guys :-). > > > > For what it's worth, putting the code into an OF_getetheraddr2() > > function is a bit crude, but since Marius experienced difficulties > > merging it into OF_getetheraddr(), I chose to stay on the safe side. > > This can be revisited later. > > > > Please use the attached version instead, it has two changes over Maxime's > version: > - Fix compilation by adding a prototype for OF_getetheraddr2(). Hmm, yes, I had this in my tree of course but forgot to include it in the patch. > - Add a debugging printf for an issue I had with my version of > OF_getetheraddr() to really make sure it works as expected. I guess that could be useful. Cheers, Maxime From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 8 10:51:29 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EB9616A4CE for ; Thu, 8 Jan 2004 10:51:29 -0800 (PST) Received: from radix.sorted.org (radix.sorted.org [194.70.217.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB27743D1F for ; Thu, 8 Jan 2004 10:51:27 -0800 (PST) (envelope-from pete@sorted.org) Received: by radix.sorted.org (Postfix, from userid 501) id C37942B926; Thu, 8 Jan 2004 18:51:25 +0000 (GMT) Date: Thu, 8 Jan 2004 18:51:25 +0000 From: Pete Bentley To: sparc64@freebsd.org Message-ID: <20040108185125.GA92398@sorted.org> References: <20040108094116.GU2060@elvis.mu.org> <20040108175835.A95298@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108175835.A95298@newtrinity.zeist.de> User-Agent: Mutt/1.4.1i Subject: Re: Need testers for patch to get MAC address of integrated dc(4) cards X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 18:51:29 -0000 On Thu, Jan 08, 2004 at 05:58:35PM +0100, Marius Strobl wrote: > The patch is compile tested but otherwise not (yet) tested on my side. > I probably won't be able to really test it in time for getting it into > 5.2-RELEASE, so if you own a Netra X1 or a Sunfire V100 please give it > a try an reply with all the dcX lines you get in /var/run/dmesg.boot. After minimal testing, it appears to be functionally identical to the previous patch I was using (the one that called OF_getprop( ..., "local-mac-address") from inside if_dc.c). This on a X1 with -CURRENT as of about 2 hours ago with just this patch applied:- dc0: port 0x10000-0x100ff at device 12.0 on pci0 dc0: Ethernet address: 00:03:ba:06:2a:a6 dc1: port 0x10100-0x101ff mem 0x2000-0x20ff at device 5.0 on pci0 dc1: Ethernet address: 00:03:ba:06:2a:a7 [...] dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state Surely we can do better than OF_getetheraddr2() as a name though :) Pete. From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 00:09:12 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344B416A4CE for ; Fri, 9 Jan 2004 00:09:12 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BDF43D53 for ; Fri, 9 Jan 2004 00:09:09 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i09896Kx015796 for ; Fri, 9 Jan 2004 03:09:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <20040107174346.GA50142@dragon.nuxi.com> Date: Fri, 9 Jan 2004 03:09:04 -0500 To: freebsd-sparc64@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 08:09:12 -0000 At 9:43 AM -0800 1/7/04, David O'Brien wrote: >On Wed, Jan 07, 2004 at 12:08:13AM -0500, Garance A Drosihn wrote: >> How flexible should we be? My first thought is to tell people: >> >> 1) upgrade to RELENG_5_2 >> 2) *after* you know that upgrade worked, then run a patch >> file (which will already be in /usr/src?), which will >> modify the appropriate files needed for this change. >> 3) rebuild after making just that one change. No cvsup. > >I think it has to all be doable given a CVS archive, no >external patches. That is certainly less work for me to do, but.. > > Or we could do a more flexible version, combining a -Define in >> CFLAGS (set in /etc/make.conf), along with some extra magic >> when installing the include files during 'make installworld'. >> Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64. > >I think we should only do this if we can't achieve this as above. part of the reason for doing this is to allow more people to help me test whatever procedure I dream up. It takes me more than seven hours to do buildworld+buildkernel+installkernel, and more to finish up any given test. And at the end of that, all we know is that it works for me on my Ultra 10. So, there would be some benefit if I had something that could be committed without changing anything for anyone, and then we could pull in a few more people to test it by flipping the switch in /etc/make.conf. However, my first attempt at doing that shows that it isn't as simple to do as I'd like. Some things in buildworld are compiled without CFLAGS from /etc/make.conf, and it would probably waste too much time to figure out fixes for those. I have another 64-bit build going right now, but I'll have to wait until tomorrow to see how it works out. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 10:29:55 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4168716A4CE for ; Fri, 9 Jan 2004 10:29:55 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E4D43D5C for ; Fri, 9 Jan 2004 10:29:53 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i09ITpL07847 for ; Fri, 9 Jan 2004 19:29:52 +0100 (MET) Date: Fri, 9 Jan 2004 19:29:51 +0100 (CET) From: Harti Brandt To: sparc64@freebsd.org Message-ID: <20040109192555.P16150@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: building kernel for Ultra-1 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 18:29:55 -0000 Hi, the Ultra-1 doesn't have a PCI bus, so I thought I ommit the device pci in the configuration file. This fails however because ofw_machdep.c unconditionally includes ofw_pci.h, which in turn unconditionally includes ofw_pci_if.h, which is not there. Should this work? Maybe conditionally including ofw_pci.h? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 11:07:51 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47DBC16A4CE; Fri, 9 Jan 2004 11:07:51 -0800 (PST) Received: from kundenserver16.yws-admin.de (kundenserver16.yws-admin.de [217.115.154.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38C9943D2D; Fri, 9 Jan 2004 11:07:50 -0800 (PST) (envelope-from fsmeets@kasimir.com) Received: from kasimir.com (pD951E093.dip.t-dialin.net [217.81.224.147]) by kundenserver16.yws-admin.de (Postfix) with ESMTP id 584A3352587; Fri, 9 Jan 2004 20:07:48 +0100 (CET) Message-ID: <3FFEFC03.9050706@kasimir.com> Date: Fri, 09 Jan 2004 20:07:47 +0100 From: "Florian C. Smeets" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031213 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sparc64@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: jeff@freebsd.org Subject: GENERIC with SCHED_ULE buildproblem on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 19:07:51 -0000 Hi, when trying to build a GENERIC kernel with SCHED_ULE on a UP box the build bails out when linking the kernel. It is related to something with "mp_maxid" if i recall correctly. The box is at work and i won't have access to it again befor monday so i don't have the error message available. Sorry! The sources were from 3 days ago. The build box was a U5. tif, flo From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 13:17:42 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E821C16A4CE for ; Fri, 9 Jan 2004 13:17:42 -0800 (PST) Received: from lb586.lougentile.com (lb586.lougentile.com [207.106.90.48]) by mx1.FreeBSD.org (Postfix) with SMTP id B03E043D1D for ; Fri, 9 Jan 2004 13:17:39 -0800 (PST) (envelope-from lougentile@lougentile.com) Received: (qmail 24042 invoked by uid 0); 9 Jan 2004 21:17:38 -0000 Received: from pcp01430102pcs.toresd01.pa.comcast.net (HELO gametester) (68.81.187.158) by www.lougentile.com with SMTP; 9 Jan 2004 21:17:38 -0000 Date: Fri, 9 Jan 2004 16:17:42 -0500 From: Lou Gentile X-Mailer: The Bat! (v2.01) CD5BF9353B3B7091 Organization: The Lou Gentile Show X-Priority: 3 (Normal) Message-ID: <8837574796.20040109161742@lougentile.com> To: freebsd-sparc@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: SUN4D Support X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lou Gentile List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 21:17:43 -0000 Hello freebsd-sparc, Any luck on getting the support for SUN4D (SPARCSERVER 1000) up and running. Linux supports it and i cannot stand that OS but unfortunately it is my only choice. ------------- Best regards, Lou mailto:lougentile@lougentile.com TO SEND ME EMAIL YOU MUST HAVE THIS KEY IN YOUR MESSAGE OR YOU WILL NEED A CONFIRMATION! ENCRYPTION KEY: 201ort339jsw10021jqa From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 13:35:52 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 203B216A4CE for ; Fri, 9 Jan 2004 13:35:52 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACC043D54 for ; Fri, 9 Jan 2004 13:35:37 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) i09LZWcR013348; Fri, 9 Jan 2004 22:35:33 +0100 (CET) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.10/8.12.9) with ESMTP id i09LZWKi004387; Fri, 9 Jan 2004 22:35:32 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.10/8.12.9/Submit) id i09LZWwV004386; Fri, 9 Jan 2004 22:35:32 +0100 (CET) (envelope-from wkb) Date: Fri, 9 Jan 2004 22:35:32 +0100 From: Wilko Bulte To: Lou Gentile Message-ID: <20040109213532.GA4364@freebie.xs4all.nl> References: <8837574796.20040109161742@lougentile.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8837574796.20040109161742@lougentile.com> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-STABLE X-PGP: finger wilko@freebsd.org cc: freebsd-sparc@freebsd.org Subject: Re: SUN4D Support X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 21:35:52 -0000 On Fri, Jan 09, 2004 at 04:17:42PM -0500, Lou Gentile wrote: > Hello freebsd-sparc, > Any luck on getting the support for SUN4D (SPARCSERVER > 1000) up and running. Linux supports it and i cannot > stand that OS but unfortunately it is my only choice. It is not your only choice, NetBSD is another one. But there are no plans to support the old Sparcs with FreeBSD. -- | / o / /_ _ |/|/ / / /( (_) Bulte wilko@FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 17:07:28 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3082B16A4CE; Fri, 9 Jan 2004 17:07:28 -0800 (PST) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A3D443D53; Fri, 9 Jan 2004 17:07:25 -0800 (PST) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) i0A17Ov9065341; Fri, 9 Jan 2004 20:07:24 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id i0A17NFP065340; Fri, 9 Jan 2004 20:07:23 -0500 (EST) (envelope-from des+tinderbox@freebsd.org) Date: Fri, 9 Jan 2004 20:07:23 -0500 (EST) Message-Id: <200401100107.i0A17NFP065340@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 01:07:28 -0000 TB --- 2004-01-10 00:37:54 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2004-01-10 00:37:54 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-01-10 00:37:54 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-01-10 00:40:11 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> 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 [...] cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/stdtime/lo! caltime.c cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/stdtime/st! rftime.c cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/stdtime/st! rptime.c cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/stdtime/ti! melocal.c cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/stdtime/ti! me32.c cc -O -pipe -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sy! s/__sparc_sigtramp_setup.c /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys/__sparc_sigtramp_setup.c: In function `__sparc_sigtramp_setup': /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys/__sparc_sigtramp_setup.c:45: warning: passing arg 2 of `sysarch' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-01-10 01:07:23 - TB --- /usr/bin/make returned exit code 1 TB --- 2004-01-10 01:07:23 - TB --- ERROR: failed to build world TB --- 2004-01-10 01:07:23 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 23:21:06 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 279A716A4CE; Fri, 9 Jan 2004 23:21:06 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 733FC43D48; Fri, 9 Jan 2004 23:20:59 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i0A7KwKx032156; Sat, 10 Jan 2004 02:20:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <20040107174346.GA50142@dragon.nuxi.com> Date: Sat, 10 Jan 2004 02:20:57 -0500 To: freebsd-sparc64@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: harti@freebsd.org Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 07:21:06 -0000 After reading over what Harti had done, and staring at the standard makefiles awhile, I ended up writing one helper- script. With this helper-script, the upgrade to 64-bits went fairly smooth. For my switch, what I did was: cvsup to -current update & install that snapshot (using the standard updating procedures, this is still the 32-bit time_t system) 1) change __time_t to __int64_t 2) rm -Rf /usr/obj/usr/src/* 3) make buildworld && make buildkernel && make installkernel (wait seven hours...) 4) mergemaster -p <- not really needed... 5) reboot into single-user mode. 6) cd /usr/src <- or NFS-mounted equivalent 7) installworld_nk <- magic script 8) mergemaster <- not really needed... 9) Reboot, and come up on complete new 64-bit time_t system. 10) portupgrade -Rr -f ruby portupgrade 11) portupgrade -Rr -f bash python 12) ---> Have To Do Something with CVSUP <--- (in my case, I'll probably rebuild all of ezm3 and cvsup, but I doubt that everyone would want to do that. We probably need to have a pre-built 64-bit cvsup available as pkg or a download) 13) portupgrade other ports... Doing it this way, I hit no snags. Or at least, I haven't noticed any yet. This could be made even easier by collapsing the 'installworld_nk' script into some new 'installworld_nk' target in /usr/src/Makefile. The script tries to be as general a solution as possible -- it is not specific to this 64-bit time_t change. ("nk" is short for "New Kernel") Notes: 1) Since I only change this one single line, there really is no need for doing things like mergemaster. I really like the idea that when switching to 64-bit time_t, that should be the *only* change you're making from a system that you already know is working on your hardware. 4) If one would do 'mergemaster -p', it would probably be best do to it before shutting down, instead of after booting into a 64-bit kernel and 32-bit world. 5) Usually I cheat on this, and I reboot into multi-user mode and then 'shutdown now' to get into single-user mode. That cheat does not work well when making this change. You really have to 'boot -s', pick your shell, and do a 'mount -a'. Probably should start swap too, but I have enough ram that I don't have to care about that part. 5a) For the general case, this is the "shakey-ist" step, because I started up on a /bin/sh which was not built for the new kernel. For this specific change, that did not seem to be a problem. 6) The way I wrote the script, I expect it would work for people who do installs via NFS-mounted filesystems, perhaps mounted at somewhere other than /usr/src. However, I am not setup to test that. I am testing only the standard case of /usr/src and /usr/obj. 7) What the standard 'make installworld' does, is it looks for a list of programs, does a 'which $prog' on them, and copies all of those (from the "old system") into a temp directory, and changes PATH to use that directory. What my script does is take that same list of programs, copies them out of ${.OBJDIR} into a temp directory, changes PATH to add on the new directory, removes one PATH= command from a copy of /usr/src/Makefile, and then runs the standard 'installworld' target. So, using this tactic it should be true that *every* program needed by the installworld process will match the new kernel. I know that doesn't happen for /bin/sh, and I can't prove that it did happen for all other programs, but I did get through the entire installworld without error-ing out. That's why I say this could be collapsed into a new standard target. The script is only doing a slight variation from the standard installworld target. I am not going to *do* that, I'm just saying it could be done. 10) I use portupgrade to update ports, so I figured this was the obvious first-step. After that, I've just been upgrading ports which "I expect" need to be upgraded. After that, I did the dumb test of: irb <- interactive ruby test = Time.now() test += 3600*24*365 and kept repeating the last command. On a 32-bit time_t, the command errors out in 2038. On the new system, it just keeps going up. I hope to do a repeat test of all of this work sometime over the weekend. I also might try to make some more improvements. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 10 08:16:39 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AAE916A4CE; Sat, 10 Jan 2004 08:16:39 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id F086243D55; Sat, 10 Jan 2004 08:16:37 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 96A4F5482B; Sat, 10 Jan 2004 10:16:37 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 333006D45F; Sat, 10 Jan 2004 10:16:37 -0600 (CST) Date: Sat, 10 Jan 2004 10:16:37 -0600 From: "Jacques A. Vidrine" To: Tinderbox Message-ID: <20040110161637.GB80952@madman.celabo.org> References: <200401100107.i0A17NFP065340@cueball.rtp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401100107.i0A17NFP065340@cueball.rtp.FreeBSD.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: current@freebsd.org cc: sparc64@freebsd.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 16:16:39 -0000 On Fri, Jan 09, 2004 at 08:07:23PM -0500, Tinderbox wrote: [...] > TB --- 2004-01-10 00:37:54 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org > /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys/__sparc_sigtramp_setup.c: In function `__sparc_sigtramp_setup': > /vol/vol1/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys/__sparc_sigtramp_setup.c:45: warning: passing arg 2 of `sysarch' discards qualifiers from pointer target type > *** Error code 1 [...] > TB --- 2004-01-10 01:07:23 - TB --- ERROR: failed to build world > TB --- 2004-01-10 01:07:23 - tinderbox aborted Sorry, my mistake. I failed to notice that the argument was `const', and I failed to test properly (installed machine/sysarch.h != current machine/sysarch.h on test machine). Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 10 13:39:53 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00AF716A4CE for ; Sat, 10 Jan 2004 13:39:53 -0800 (PST) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619C643D55 for ; Sat, 10 Jan 2004 13:39:51 -0800 (PST) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 648D8322; Sat, 10 Jan 2004 15:39:50 -0600 (CST) Date: Sat, 10 Jan 2004 15:39:50 -0600 From: Tillman Hodgson To: freebsd-sparc64@freebsd.org Message-ID: <20040110213950.GR451@seekingfire.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <20040107174346.GA50142@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.5.1i Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 21:39:53 -0000 On Sat, Jan 10, 2004 at 02:20:57AM -0500, Garance A Drosihn wrote: > After reading over what Harti had done, and staring at the > standard makefiles awhile, I ended up writing one helper- > script. With this helper-script, the upgrade to 64-bits > went fairly smooth. > I hope to do a repeat test of all of this work sometime over > the weekend. I also might try to make some more improvements. Thanks for doing this work and making your notes public. As a sparc64 user (running a public web site and hosting mailing lists) I appreciate any effort to make the 64-bit time transition smoother, and success stories with detailed notes definitely help :-) -T -- Laws to suppress tend to strengthen what they would prohibit. This is the fine point on which all the legal professions of history have based their job security. - Bene Gesserit Coda