From owner-freebsd-sparc64@FreeBSD.ORG Mon Apr 7 17:33:34 2003 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 118E337B401; Mon, 7 Apr 2003 17:33:34 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-63-207-60-150.dsl.lsan03.pacbell.net [63.207.60.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B15143FBD; Mon, 7 Apr 2003 17:33:33 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id E832666D16; Mon, 7 Apr 2003 17:33:32 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id D8A735B8; Mon, 7 Apr 2003 17:33:32 -0700 (PDT) Date: Mon, 7 Apr 2003 17:33:32 -0700 From: Kris Kennaway To: Thomas Moestl Message-ID: <20030408003332.GA60864@rot13.obsecurity.org> References: <20030116072448.GA29468@rot13.obsecurity.org> <20030116201728.GA279@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20030116201728.GA279@crow.dom2ip.de> User-Agent: Mutt/1.4i cc: kan@FreeBSD.ORG cc: sparc64@FreeBSD.ORG cc: obrien@FreeBSD.ORG cc: Kris Kennaway Subject: Re: assembler error in XFree86 snapshot 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, 08 Apr 2003 00:33:34 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2003 at 09:17:28PM +0100, Thomas Moestl wrote: > On Wed, 2003/01/15 at 23:24:48 -0800, Kris Kennaway wrote: > > I'm trying to compile anholt's XFree86 4.2.99 snapshot on sparc, and I > > get the following error message: > >=20 > > cc -c -O -pipe -ansi -Dasm=3D__asm -Wall -Wpointer-arith -Wundef -I= /usr/tmp/XFree86-4-libraries-devel/work/xc -I/usr/tmp/XFree86-4-libraries-d= evel/work/xc/exports/include -DCSRG_BASED -DFUNCPROTO=3D15 -DNARROWPROTO= -DXTHREADS -D_REENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWD= API -DMALLOC_0_RETURNS_NULL XRes.c > > {standard input}: Assembler messages: > > {standard input}:667: Error: relocation overflow > > *** Error code 1 > >=20 > > line 667 of the .s file is: > >=20 > > > .LL86: > > > umul %o0, 4294967295, %o0 >=20 > This is a arguably a gcc bug. All (13-bit) immediate operands are > sign-extended, even those to instructions which operate on unsigned > values, so umul can handle a range of very small and a range of very > large operands. gcc correctly recognizes that it can use an immediate > here; however, it chooses to output it as an unsigned number and does > not sign-extended it from 32 to 64 bit. >=20 > All sign extensions for instructions are made to the full 64 bit > however (even if umul only happens to use 32 of those), so when the > assembler checks whether a value is representable as an immediate, it > will check that the 64-bit sign extension of the immediate creates > the desired value (in sparc64 mode), i.e. it doesn't ignore the upper > 32 bits even if a particular instruction does not use them. >=20 > One solution is to generate negative literals for immediates if we > mean them to be sign-extended (which gcc does already for some other > instructions). The attached patch implements this, I'm not sure it > uses the best possible way to do this though, and it also needs a bit > more testing. *Ping* Someone needs to take this up with the gcc developers so it can get fixed. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+khjcWry0BWjoQKURAkG+AJ0aa51sc3HiTPfohFaRpMby+5yJvACfXz7g FZGA+ClAjIP2M/dQw+scez0= =Znq6 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 8 09:54:58 2003 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 C59F937B401; Tue, 8 Apr 2003 09:54:58 -0700 (PDT) Received: from gw.andersa.net (as1-3-8.ml.g.bonet.se [217.215.159.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C2C43FCB; Tue, 8 Apr 2003 09:54:57 -0700 (PDT) (envelope-from anders@gw.andersa.net) Received: from gw.andersa.net (anders@localhost [127.0.0.1]) by gw.andersa.net (8.12.9/8.12.9) with ESMTP id h38Gsv0B061495; Tue, 8 Apr 2003 18:54:57 +0200 (CEST) (envelope-from anders@gw.andersa.net) Received: (from anders@localhost) by gw.andersa.net (8.12.9/8.12.9/Submit) id h38Gsuin061486; Tue, 8 Apr 2003 18:54:56 +0200 (CEST) Date: Tue, 8 Apr 2003 18:54:55 +0200 From: Anders Andersson To: sos@FreeBSD.org Message-ID: <20030408165455.GB3264@gw.andersa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i cc: sparc64@FreeBSD.org Subject: latest ATA code a no go 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, 08 Apr 2003 16:54:59 -0000 Hi, The latest ATA commit rounds wont compile on my sparc64. [compile output...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mcmodel=medlow -msoft-float -ffreestanding -Werror /usr/src/sys/dev/ata/ata-raid.c cc1: warnings being treated as errors /usr/src/sys/dev/ata/ata-raid.c: In function `ar_print_conf': /usr/src/sys/dev/ata/ata-raid.c:1460: warning: long long int format, u_int64_t arg (arg 2) /usr/src/sys/dev/ata/ata-raid.c:1468: warning: long long int format, u_int64_t arg (arg 2) *** Error code 1 -- Anders Andersson From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 8 14:01:50 2003 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 26B7337B401 for ; Tue, 8 Apr 2003 14:01:50 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4458743F93 for ; Tue, 8 Apr 2003 14:01:49 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h38L28xS082253 for ; Tue, 8 Apr 2003 17:02:08 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h38L28jX082252 for freebsd-sparc64@freebsd.org; Tue, 8 Apr 2003 17:02:08 -0400 (EDT) Date: Tue, 8 Apr 2003 17:02:08 -0400 From: Jake Burkholder To: freebsd-sparc64@freebsd.org Message-ID: <20030408210208.GE78831@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: if_fxp supported in -current [mux@FreeBSD.org: cvs commit: src/sys/sparc64/conf GENERIC] 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, 08 Apr 2003 21:01:50 -0000 Many thanks to Maxime for his hard work! Jake ----- Forwarded message from Maxime Henrion ----- mux 2003/04/08 13:55:30 PDT FreeBSD src repository Modified files: sys/sparc64/conf GENERIC Log: The fxp(4) driver is now working on sparc64 too! Tested by: jake Revision Changes Path 1.52 +1 -1 src/sys/sparc64/conf/GENERIC ----- End forwarded message ----- From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 03:42:32 2003 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 61EFB37B401 for ; Thu, 10 Apr 2003 03:42:32 -0700 (PDT) Received: from geddar.km.ua (geddar.km.ua [62.149.0.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E040443FAF for ; Thu, 10 Apr 2003 03:42:28 -0700 (PDT) (envelope-from maxim@geddar.km.ua) Received: from geddar.km.ua (localhost [127.0.0.1]) by geddar.km.ua (8.12.9/8.12.9) with ESMTP id h3AAfTU8000882 for ; Thu, 10 Apr 2003 13:41:29 +0300 (EEST) (envelope-from maxim@geddar.km.ua) Received: (from maxim@localhost) by geddar.km.ua (8.12.9/8.12.9/Submit) id h3AAfTnI000881 for freebsd-sparc@FreeBSD.ORG; Thu, 10 Apr 2003 13:41:29 +0300 (EEST) Date: Thu, 10 Apr 2003 13:41:29 +0300 From: Maxim Mazurok To: freebsd-sparc@FreeBSD.ORG Message-ID: <20030410104129.GB538@km.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: many troubles 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, 10 Apr 2003 10:42:32 -0000 at first, sorry for my bad english. please, help me. I have Ultra AXi motherboard and UltraIIi processor: maxim@geddar:~>dmesg| head -9 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Thu Apr 10 11:26:08 EEST 2003 root@geddar.km.ua:/usr/src/sys/sparc64/compile/GEDDAR Preloaded elf kernel "/boot/kernel/kernel" at 0xc0344000. Timecounter "tick" frequency 360130984 Hz cpu0: Sun Microsystems UltraSparc-IIi Processor (360.13 MHz CPU) Model: SUNW,UltraSPARC-IIi-Engine full cvsup and rebuild about 5-7 hour ago... problems: 1. i can't see memory size on my sparc in dmesg output. :) 2. u have many problems width BIND(2). it's fragment from /usr/src/crypto/openssh/sshd.c: ===cut=== if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { ===cut=== this fragment worked. and sshd worked widthout problems. apache, sendmail worked too. but all next fragments no worked :( next fragments from /usr/src/libexec/ftpd/ftpd.c ===cut=== if (bind(ctl_sock, (struct sockaddr *)&server_addr, server_addr.su_len) < 0) { ===cut=== next fragments from /usr/src/contrib/ntp/ntpd/ntp_io.c ===cut=== if (bind(fd, (struct sockaddr *)addr, sizeof(*addr)) < 0) { ===cut=== next fragments from /usr/src/contrib/bind/bin/named/ns_main.c ===cut=== if (bind(sp->s_rfd, (struct sockaddr *)&src, sizeof(src)) < 0) ===cut=== fragments of /var/log/messages: ===cut=== Apr 10 13:00:27 geddar named[251]: bind(dfd=20, [62.149.4.13].53): Can't assign requested address Apr 10 13:00:27 geddar named[251]: deleting interface [62.149.4.13].53 Apr 10 13:00:29 geddar ntpd[356]: bind() fd 5, family 2, port 123, addr 62.149.4.13, in_classd=0 flags=1 fails: Can't assign requested address ===cut=== :( 3. i inserted 4 RealTec 8139 cards to my motherboard and see next: maxim@geddar:~>dmesg| grep "RealTek 8139" rl0: port 0xc00-0xcff mem 0xa000-0xa0ff irq 0 at device 2.0 on pci1 rl1: port 0x1000-0x10ff mem 0xc000-0xc0ff irq 4 at device 3.0 on pci1 rl2: port 0x800400-0x8004ff mem 0x42000000-0x420000ff irq 20 at device 3.0 on pci2 rl3: port 0x800800-0x8008ff mem 0x42002000-0x420020ff irq 24 at device 4.0 on pci2 rl0 mapped to irq 0. it's right? 4. after buildworld about 2 weeks ago i see broken 'systat -vm' output in section about activity hard disks (i have 4 HDD, CDROM and pass devices): Disks 0 0 0 0 0 0 0 KB/t 16.00 16.00 0.00 0.00 0.00 0.00 0.00 tps ***** ***** 0 0 0 0 0 MB/s ***** ***** 0.00 0.00 0.00 0.00 0.00 % busy 0 6 0 0 0 0 0 -- Maxim Mazurok (MMP2-RIPE) From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 10:33:17 2003 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 0C5A237B401 for ; Thu, 10 Apr 2003 10:33:17 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3339843F3F for ; Thu, 10 Apr 2003 10:33:16 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3AHXoxS091718; Thu, 10 Apr 2003 13:33:50 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3AHXoar091717; Thu, 10 Apr 2003 13:33:50 -0400 (EDT) Date: Thu, 10 Apr 2003 13:33:49 -0400 From: Jake Burkholder To: Maxim Mazurok Message-ID: <20030410173349.GK78831@locore.ca> References: <20030410104129.GB538@km.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410104129.GB538@km.ua> User-Agent: Mutt/1.4i cc: freebsd-sparc@freebsd.org Subject: Re: many troubles 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, 10 Apr 2003 17:33:17 -0000 Apparently, On Thu, Apr 10, 2003 at 01:41:29PM +0300, Maxim Mazurok said words to the effect of; > at first, sorry for my bad english. > > please, help me. > I have Ultra AXi motherboard and UltraIIi processor: > > maxim@geddar:~>dmesg| head -9 > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #2: Thu Apr 10 11:26:08 EEST 2003 > root@geddar.km.ua:/usr/src/sys/sparc64/compile/GEDDAR > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0344000. > Timecounter "tick" frequency 360130984 Hz > cpu0: Sun Microsystems UltraSparc-IIi Processor (360.13 MHz CPU) > Model: SUNW,UltraSPARC-IIi-Engine > > full cvsup and rebuild about 5-7 hour ago... > > problems: > 1. i can't see memory size on my sparc in dmesg output. :) Fixed. > 2. u have many problems width BIND(2). > it's fragment from /usr/src/crypto/openssh/sshd.c: > ===cut=== > if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { > ===cut=== > this fragment worked. and sshd worked widthout problems. > apache, sendmail worked too. > but all next fragments no worked :( > > next fragments from /usr/src/libexec/ftpd/ftpd.c > ===cut=== > if (bind(ctl_sock, (struct sockaddr *)&server_addr, server_addr.su_len) < 0) { > ===cut=== > > next fragments from /usr/src/contrib/ntp/ntpd/ntp_io.c > ===cut=== > if (bind(fd, (struct sockaddr *)addr, sizeof(*addr)) < 0) { > ===cut=== > > next fragments from /usr/src/contrib/bind/bin/named/ns_main.c > ===cut=== > if (bind(sp->s_rfd, (struct sockaddr *)&src, sizeof(src)) < 0) > ===cut=== > > fragments of /var/log/messages: > ===cut=== > Apr 10 13:00:27 geddar named[251]: bind(dfd=20, [62.149.4.13].53): Can't assign requested address > Apr 10 13:00:27 geddar named[251]: deleting interface [62.149.4.13].53 > Apr 10 13:00:29 geddar ntpd[356]: bind() fd 5, family 2, port 123, addr 62.149.4.13, in_classd=0 flags=1 fails: Can't assign requested address > ===cut=== > :( Can you give some details about your configuration? How are you starting ftpd? Is it binding to a real interface or an alias? It seems to work fine here starting it from inetd, or from the command line as a daemon binding to a specific address. I've used bind before on one of my sparc64 machines and didn't have a problem. Don't know about ntpd. > 3. i inserted 4 RealTec 8139 cards to my motherboard and see next: > > maxim@geddar:~>dmesg| grep "RealTek 8139" > rl0: port 0xc00-0xcff mem 0xa000-0xa0ff irq 0 at device 2.0 on pci1 > rl1: port 0x1000-0x10ff mem 0xc000-0xc0ff irq 4 at device 3.0 on pci1 > rl2: port 0x800400-0x8004ff mem 0x42000000-0x420000ff irq 20 at device 3.0 on pci2 > rl3: port 0x800800-0x8008ff mem 0x42002000-0x420020ff irq 24 at device 4.0 on pci2 > > rl0 mapped to irq 0. it's right? Do all the cards work? irq 0 is normal, its actually irq 1984 but we don't print the ign in most cases. > > 4. after buildworld about 2 weeks ago i see broken 'systat -vm' output in > section about activity hard disks (i have 4 HDD, CDROM and pass devices): > > Disks 0 0 0 0 0 0 0 > KB/t 16.00 16.00 0.00 0.00 0.00 0.00 0.00 > tps ***** ***** 0 0 0 0 0 > MB/s ***** ***** 0.00 0.00 0.00 0.00 0.00 > % busy 0 6 0 0 0 0 0 The '*****' for tps and MB/s? Don't know what that's about, or why its not printing the name of the disks... Jake From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 11:30:19 2003 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 16C4337B407 for ; Thu, 10 Apr 2003 11:30:18 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D131B43FB1 for ; Thu, 10 Apr 2003 11:30:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h3AIUGUp018919 for ; Thu, 10 Apr 2003 11:30:16 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3AIUGE9018918; Thu, 10 Apr 2003 11:30:16 -0700 (PDT) Resent-Date: Thu, 10 Apr 2003 11:30:16 -0700 (PDT) Resent-Message-Id: <200304101830.h3AIUGE9018918@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Andrew Milton Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F1FD37B408 for ; Thu, 10 Apr 2003 11:21:57 -0700 (PDT) Received: from theinternet.com.au (c17609.carlnfd1.nsw.optusnet.com.au [210.49.139.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF2F43FA3 for ; Thu, 10 Apr 2003 11:21:54 -0700 (PDT) (envelope-from akm@orchid.theinternet.com.au) Received: from orchid.theinternet.com.au (orchid.theinternet.com.au [203.34.176.147]) by theinternet.com.au (8.12.9/8.12.9) with ESMTP id h3AHEV8g016649 for ; Fri, 11 Apr 2003 03:14:31 +1000 (EST) (envelope-from akm@orchid.theinternet.com.au) Received: from orchid.theinternet.com.au (localhost.theinternet.com.au [127.0.0.1])h3AHCKaN001521 for ; Fri, 11 Apr 2003 03:12:20 +1000 (EST) (envelope-from akm@orchid.theinternet.com.au) Received: (from akm@localhost) by orchid.theinternet.com.au (8.12.9/8.12.9/Submit) id h3AHCJHg001520; Fri, 11 Apr 2003 03:12:19 +1000 (EST) Message-Id: <200304101712.h3AHCJHg001520@orchid.theinternet.com.au> Date: Fri, 11 Apr 2003 03:12:19 +1000 (EST) From: Andrew Milton To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: sparc64/50789: PCI Bus number reported by /dev/pci is wrong. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew Milton List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2003 18:30:19 -0000 >Number: 50789 >Category: sparc64 >Synopsis: PCI Bus number reported by /dev/pci is wrong. >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-sparc >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 10 11:30:16 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Andrew Milton >Release: FreeBSD 5.0-CURRENT sparc64 >Organization: >Environment: System: FreeBSD orchid.theinternet.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Thu Apr 10 17:36:22 EST 2003 akm@orchid.theinternet.com.au:/usr/obj/usr/src/sys/orchid sparc64 cpu0: Sun Microsystems UltraSparc-IIi Processor (269.80 MHz CPU) Model: SUNW,Ultra-5_10 nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0 DVMA map: 0xc0000000 to 0xc1ffffff PCI-PCI bridge at 0/1/1: setting bus #s to 0/1/1 pcib0: ofw_pci_init: descending to subordinate PCI bus device 1/1/0: latency timer 0 -> 82 pcib0: ofw_pci_init: no interrupt mapping found for 1/1/0 (preset 0) device 1/1/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/1/1 to 33 (preset was 0) device 1/2/0: latency timer 0 -> 66 pcib0: ofw_pci_init: mapping intr for 1/2/0 to 15 (preset was 15) device 1/3/0: latency timer 0 -> 16 pcib0: ofw_pci_init: mapping intr for 1/3/0 to 32 (preset was 14) PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/2 pcib0: ofw_pci_init: descending to subordinate PCI bus pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 1.1 on pci0 pci2: on pcib2 ebus0: revision 0x01 ebus0: mem 0xf1000000-0xf17fffff,0xf0000000-0xf0ffffff at device 1.0 on pci2 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) sab0: addr 0x1400400000-0x140040007f irq 43 on ebus0 sabtty0: on sab0 sabtty0: console 9600,8,n,1,- sabtty1: on sab0 ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x140030015c-0x140030015d,0x14003043bc-0x14003043cb irq 34 (no driver attached) ebus0: addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003023f0-0x14003023f7 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 808e84c0 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400722000-0x1400722003,0x1400704000-0x140070400f,0x1400702000-0x140070200f,0x1400200000-0x14002000ff irq 36,35 (no driver attached) hme0: mem 0xe0000000-0xe0007fff irq 33 at device 1.1 on pci2 miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 2.0 (no driver attached) atapci0: port 0xc00020-0xc0002f,0xc00018-0xc0001b,0xc00010-0xc00017,0xc00008-0xc0000b,0xc00000-0xc00007 irq 32 at device 3.0 on pci2 ata2: at 0xc00000 on atapci0 ata3: at 0xc00010 on atapci0 >Description: The PCI bus reported by pciconf and /dev/pci + ioctls is incorrect, the correct PCI Bus is repported for devices in dmesg output. This likely affects other architectures with > 1 PCI bus, but, I don't have access to any to confirm. >How-To-Repeat: This is fairly simple to detect, I have an onboard video card on pcibus #2, dmesg shows; pci2: at device 2.0 (no driver attached) pciconf -lv: none0@pci1:2:0: class=0x030000 card=0x00000000 chip=0x47541002 rev=0x9a hdr=0x00 vendor = 'ATI Technologies' device = 'Mach 64 GT Rage 3D II Graphics Accelerator' class = display subclass = VGA If I tried to read register 0 I should get the chip back (0x47541002) pciconf -r pci1:2:0 0 ffffffff If I use pci bus 2 as reported by dmesg; pciconf -r pci2:2:0 0 47541002 >Fix: Unknown. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 15:01:46 2003 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 1E3AE37B401; Thu, 10 Apr 2003 15:01:46 -0700 (PDT) Received: from gw.andersa.net (as1-3-8.ml.g.bonet.se [217.215.159.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E345843F85; Thu, 10 Apr 2003 15:01:44 -0700 (PDT) (envelope-from anders@gw.andersa.net) Received: from gw.andersa.net (anders@localhost [127.0.0.1]) by gw.andersa.net (8.12.9/8.12.9) with ESMTP id h3AM1nYd003215; Fri, 11 Apr 2003 00:01:49 +0200 (CEST) (envelope-from anders@gw.andersa.net) Received: (from anders@localhost) by gw.andersa.net (8.12.9/8.12.9/Submit) id h3AM1nQa003214; Fri, 11 Apr 2003 00:01:49 +0200 (CEST) Date: Fri, 11 Apr 2003 00:01:49 +0200 From: Anders Andersson To: jake@FreeBSD.org Message-ID: <20030410220149.GA3168@gw.andersa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i cc: sparc64@FreeBSD.org Subject: sparc64 real memory 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, 10 Apr 2003 22:01:46 -0000 Hi Jake, One question comes to mind after your latest commit to fix the 'real memory' report in dmesg on sparc64. I have 512MB of RAM in both my i386 (p4) box and in my Ultra10. sparc64: real memory = 515129344 (491 MB) avail memory = 493608960 (470 MB) i386: real memory = 536805376 (511 MB) avail memory = 516767744 (492 MB) Is this difference something one would pay any notice about or is ot normal? Anders -- Anders Andersson From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 15:29:03 2003 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 EF12337B401 for ; Thu, 10 Apr 2003 15:29:03 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E4143F3F for ; Thu, 10 Apr 2003 15:29:03 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3AMTXxS093071; Thu, 10 Apr 2003 18:29:33 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3AMTXiu093070; Thu, 10 Apr 2003 18:29:33 -0400 (EDT) Date: Thu, 10 Apr 2003 18:29:32 -0400 From: Jake Burkholder To: Anders Andersson Message-ID: <20030410222932.GN78831@locore.ca> References: <20030410220149.GA3168@gw.andersa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410220149.GA3168@gw.andersa.net> User-Agent: Mutt/1.4i cc: sparc64@FreeBSD.org Subject: Re: sparc64 real memory 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, 10 Apr 2003 22:29:04 -0000 Apparently, On Fri, Apr 11, 2003 at 12:01:49AM +0200, Anders Andersson said words to the effect of; > Hi Jake, > > One question comes to mind after your latest commit to fix the 'real > memory' report in dmesg on sparc64. > > I have 512MB of RAM in both my i386 (p4) box and in my Ultra10. > > sparc64: > real memory = 515129344 (491 MB) > avail memory = 493608960 (470 MB) > > i386: > real memory = 536805376 (511 MB) > avail memory = 516767744 (492 MB) > > Is this difference something one would pay any notice about or is ot > normal? Its normal. The real memory will be lower because the prom takes a chunk of memory and we can't reclaim it for the kernel because we still need to call the prom. There may be some stuff that we're not reclaiming from the loader, but its a little unclear how to safely do that. The avail memory will be lower in relation to the real memory due to being a 64 bit platform; everything is just bigger. Jake From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 23:08:27 2003 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 D3A8637B401 for ; Thu, 10 Apr 2003 23:08:27 -0700 (PDT) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [133.11.205.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7697243FD7 for ; Thu, 10 Apr 2003 23:08:25 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is1.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 2C27E2183B0 for ; Fri, 11 Apr 2003 15:06:54 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h3B66sUm021016 for ; Fri, 11 Apr 2003 15:06:54 +0900 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.135.3])2.9.3.2) with ESMTP id AIH28331; Fri, 11 Apr 2003 15:06:52 +0900 (JST) Date: Fri, 11 Apr 2003 15:06:53 +0900 Message-ID: From: Hidetoshi Shimokawa To: freebsd-sparc@freebsd.org User-Agent: Wanderlust/2.11.0 (Wonderwall) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2003 06:08:28 -0000 Is cross compile for sparc64 binaries on FreeBSD-4 i386 supported? I could do it a weeks ago but now I failed with the following error. TARGET_ARCH=sparc64 make -j2 buildworld -------------------------------------------------------------- >>> stage 3: cross tools .... ===> usr.bin/elf2aout /usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/export/dpt/FreeBSD/FreeBSD-current/src/usr.bin/elf2aout created for /export/dpt/FreeBSD/FreeBSD-current/src/usr.bin/elf2aout rm -f .depend mkdep -f .depend -a -I/usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/legacy/usr/include /export/dpt/FreeBSD/FreeBSD-current/src/usr.bin/elf2aout/elf2aout.c echo elf2aout: /usr/lib/libc.a /usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/legacy/usr/lib/libegacy.a >> .depend cc -O -pipe -I/usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/legacy/usr/include -c /export/dpt/FreeBSD/FreeBSD-current/src/usr.bin/elf2aout/elf2aout.c cc -O -pipe -I/usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/legacy/usr/include -L/usr/obj/sparc64/export/dpt/FreeBSD/FreeBSD-current/src/i386/legacy/usr/lib -static -o elf2aout elf2aout.o -legacy elf2aout.o: In function `main': elf2aout.o(.text+0x20b): undefined reference to `be64toh' elf2aout.o(.text+0x257): undefined reference to `be64toh' elf2aout.o(.text+0x346): undefined reference to `be64toh' elf2aout.o(.text+0x395): undefined reference to `be64toh' elf2aout.o(.text+0x3f9): undefined reference to `be64toh' *** Error code 1 /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 10 23:45:38 2003 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 27C9437B401 for ; Thu, 10 Apr 2003 23:45:38 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFEF343FE9 for ; Thu, 10 Apr 2003 23:45:36 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 193qj5-0006Mu-00 for freebsd-sparc@freebsd.org; Thu, 10 Apr 2003 22:05:23 -0700 Date: Thu, 10 Apr 2003 22:05:22 -0700 (PDT) From: Tom Samplonius To: freebsd-sparc@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Sun Enterprise 4000 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, 11 Apr 2003 06:45:38 -0000 I tried booting the FreeBSD-5.0R install CD on a Sun Enterprise 4000. Everything seemed to go well, but at the time I had no disks attached to install to. I'm guessing the built-in fibre channel controllers on a E4000 aren't going to work? Tom From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 11 00:09:21 2003 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 447D537B401 for ; Fri, 11 Apr 2003 00:09:21 -0700 (PDT) Received: from geddar.km.ua (geddar.km.ua [62.149.0.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D2843F93 for ; Fri, 11 Apr 2003 00:09:19 -0700 (PDT) (envelope-from maxim@geddar.km.ua) Received: from geddar.km.ua (localhost [127.0.0.1]) by geddar.km.ua (8.12.9/8.12.9) with ESMTP id h3B77rU8009397; Fri, 11 Apr 2003 10:07:53 +0300 (EEST) (envelope-from maxim@geddar.km.ua) Received: (from maxim@localhost) by geddar.km.ua (8.12.9/8.12.9/Submit) id h3B77pt1009396; Fri, 11 Apr 2003 10:07:51 +0300 (EEST) Date: Fri, 11 Apr 2003 10:07:51 +0300 From: Maxim Mazurok To: Jake Burkholder Message-ID: <20030411070751.GV538@km.ua> References: <20030410104129.GB538@km.ua> <20030410173349.GK78831@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410173349.GK78831@locore.ca> User-Agent: Mutt/1.5.3i cc: freebsd-sparc@freebsd.org Subject: Re: many troubles 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, 11 Apr 2003 07:09:21 -0000 On Thu, Apr 10, 2003 at 01:33:49PM -0400, Jake Burkholder wrote: >> at first, sorry for my bad english. >> >> please, help me. >> I have Ultra AXi motherboard and UltraIIi processor: >> >> maxim@geddar:~>dmesg| head -9 >> Copyright (c) 1992-2003 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD 5.0-CURRENT #2: Thu Apr 10 11:26:08 EEST 2003 >> root@geddar.km.ua:/usr/src/sys/sparc64/compile/GEDDAR >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0344000. >> Timecounter "tick" frequency 360130984 Hz >> cpu0: Sun Microsystems UltraSparc-IIi Processor (360.13 MHz CPU) >> Model: SUNW,UltraSPARC-IIi-Engine >> >> full cvsup and rebuild about 5-7 hour ago... >> >> problems: >> 1. i can't see memory size on my sparc in dmesg output. :) > >Fixed. tnx! >> 2. u have many problems width BIND(2). >> it's fragment from /usr/src/crypto/openssh/sshd.c: >> ===cut=== >> if (bind(listen_sock, ai->ai_addr, ai->ai_addrlen) < 0) { >> ===cut=== >> this fragment worked. and sshd worked widthout problems. >> apache, sendmail worked too. >> but all next fragments no worked :( >> >> next fragments from /usr/src/libexec/ftpd/ftpd.c >> ===cut=== >> if (bind(ctl_sock, (struct sockaddr *)&server_addr, server_addr.su_len) < 0) { >> ===cut=== >> >> next fragments from /usr/src/contrib/ntp/ntpd/ntp_io.c >> ===cut=== >> if (bind(fd, (struct sockaddr *)addr, sizeof(*addr)) < 0) { >> ===cut=== >> >> next fragments from /usr/src/contrib/bind/bin/named/ns_main.c >> ===cut=== >> if (bind(sp->s_rfd, (struct sockaddr *)&src, sizeof(src)) < 0) >> ===cut=== >> >> fragments of /var/log/messages: >> ===cut=== >> Apr 10 13:00:27 geddar named[251]: bind(dfd=20, [62.149.4.13].53): Can't assign requested address >> Apr 10 13:00:27 geddar named[251]: deleting interface [62.149.4.13].53 >> Apr 10 13:00:29 geddar ntpd[356]: bind() fd 5, family 2, port 123, addr 62.149.4.13, in_classd=0 flags=1 fails: Can't assign requested address >> ===cut=== >> :( > >Can you give some details about your configuration? How are you starting >ftpd? Is it binding to a real interface or an alias? ftpd starting from inetd, named and ntpd - standalone. ftpd answer and receive from me login and password, but can't run ls, get, put....: root@chinger:~#ftp geddar.km.ua Connected to geddar.km.ua. 220 geddar.km.ua FTP server (Version 6.00LS) ready. Name (geddar.km.ua:maxim): 331 Password required for maxim. Password: 230 User maxim logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> binary 200 Type set to I. ftp> passive Passive mode off. ftp> ls 200 PORT command successful. 425 Can't create data socket (62.149.0.130,20): Can't assign requested address. ftp> passive Passive mode on. ftp> ls 425 Can't open passive connection: Can't assign requested address. Passive mode refused. ftp> bye 221 Goodbye. my sparc have 3 ethernet interface width one ip address per interface. and lo0. ftpd, named, ntpd binding to lo0 (127.0.0.1) widthout problems. but only to lo0 :( i can open ssh account to my sparc for You. >It seems to work fine here starting it from inetd, or from the command line >as a daemon binding to a specific address. I've used bind before on one of >my sparc64 machines and didn't have a problem. Don't know about ntpd. > >> 3. i inserted 4 RealTec 8139 cards to my motherboard and see next: >> >> maxim@geddar:~>dmesg| grep "RealTek 8139" >> rl0: port 0xc00-0xcff mem 0xa000-0xa0ff irq 0 at device 2.0 on pci1 >> rl1: port 0x1000-0x10ff mem 0xc000-0xc0ff irq 4 at device 3.0 on pci1 >> rl2: port 0x800400-0x8004ff mem 0x42000000-0x420000ff irq 20 at device 3.0 on pci2 >> rl3: port 0x800800-0x8008ff mem 0x42002000-0x420020ff irq 24 at device 4.0 on pci2 >> >> rl0 mapped to irq 0. it's right? > >Do all the cards work? irq 0 is normal, its actually irq 1984 but we don't >print the ign in most cases. all cards worked. >> 4. after buildworld about 2 weeks ago i see broken 'systat -vm' output in >> section about activity hard disks (i have 4 HDD, CDROM and pass devices): >> >> Disks 0 0 0 0 0 0 0 >> KB/t 16.00 16.00 0.00 0.00 0.00 0.00 0.00 >> tps ***** ***** 0 0 0 0 0 >> MB/s ***** ***** 0.00 0.00 0.00 0.00 0.00 >> % busy 0 6 0 0 0 0 0 > >The '*****' for tps and MB/s? yes :) >Don't know what that's about, or why its not >printing the name of the disks... -- Maxim Mazurok (MMP2-RIPE) From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 11 11:42:53 2003 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 F17C837B401 for ; Fri, 11 Apr 2003 11:42:52 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B0E543FA3 for ; Fri, 11 Apr 2003 11:42:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3893 invoked from network); 11 Apr 2003 18:42:58 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 11 Apr 2003 18:42:58 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3BIgnOv056081; Fri, 11 Apr 2003 14:42:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 11 Apr 2003 14:42:50 -0400 (EDT) From: John Baldwin To: Tom Samplonius cc: freebsd-sparc@freebsd.org Subject: RE: Sun Enterprise 4000 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, 11 Apr 2003 18:42:53 -0000 On 11-Apr-2003 Tom Samplonius wrote: > > I tried booting the FreeBSD-5.0R install CD on a Sun Enterprise 4000. > Everything seemed to go well, but at the time I had no disks attached to > install to. I'm guessing the built-in fibre channel controllers on a E4000 > aren't going to work? What kind of controllers are they? If they are Q-Logic, then they might work with the 'isp' driver. mjacob@ would be the person to ask about that. If they are some other type then they probaby are not supported. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 11 12:55:48 2003 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 E57B837B401 for ; Fri, 11 Apr 2003 12:55:48 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26E8C43F93 for ; Fri, 11 Apr 2003 12:55:48 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3BJuUxS096927; Fri, 11 Apr 2003 15:56:30 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3BJuTNJ096926; Fri, 11 Apr 2003 15:56:29 -0400 (EDT) Date: Fri, 11 Apr 2003 15:56:29 -0400 From: Jake Burkholder To: Hidetoshi Shimokawa Message-ID: <20030411195629.GC94333@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-sparc@freebsd.org Subject: Re: cross build 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, 11 Apr 2003 19:55:49 -0000 Apparently, On Fri, Apr 11, 2003 at 03:06:53PM +0900, Hidetoshi Shimokawa said words to the effect of; > Is cross compile for sparc64 binaries on FreeBSD-4 i386 supported? > > I could do it a weeks ago but now I failed with the following error. > > TARGET_ARCH=sparc64 make -j2 buildworld How old is your 4.x box? You may have to upgrade to a recent -stable to cross build. There's been some dispute about what versions of 4.x cross builds are to be supported on, and I think recently certain commits which made it possible to cross build on older versions of 4.x were backed out. If it doesn't work with top of tree -stable I suggest email ru@. Thanks, Jake From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 11 16:12:47 2003 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 014EA37B401 for ; Fri, 11 Apr 2003 16:12:47 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08FF243FBF for ; Fri, 11 Apr 2003 16:12:46 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3BNChUE093897 for ; Sat, 12 Apr 2003 02:12:44 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3BNChtc093894 for ; Sat, 12 Apr 2003 02:12:43 +0300 (EEST) Date: Sat, 12 Apr 2003 02:12:43 +0300 (EEST) From: Narvi To: freebsd-sparc64@freebsd.org Message-ID: <20030411224922.B75698-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: tlb, tsb & ...stuff 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, 11 Apr 2003 23:12:47 -0000 ok, I'm a lamer and couldn't think of a nice & spiffy subject line. TLB / TSB statistics: Presently we only get statistics on entries being moved into TSB, with no dtlb/itlb separation. Unless people think this is a bad idea, I'd like to make an option that would expose dTLB/iTLB and related TSB misses as statisics. this would allow you to get Solaris 9 style 'trapstat -t' information. The counters would need to be per-processor. TSB & replacement: >From what I gather (please correct me if I'm wrong!) the present TSB consists of 2K entries, organised into buckets with each bucket containing 4 entries. On replacement/entry we enter into an entry that was empty/invalid or pick one "randomly" based on the lower digits of tick. We try 4 times (for each page size) so up to 16 places get probed before a miss / hit. Making it a 4-way random replacement software managed unified L2 tlb (with slight oddness for multiple pages sizes). It would imho be interesting to support a couple of different and selectable entry indexing policies, say at least: * hashed * skew-associative to cater for various access patterns & tsb lookup loads. Again, if this would be a bad idea, let me know. Usparc3(cu) What will happen there? Do we use any of the large page sizes enough to make one of the large TLB-s cache a large(r) page size? From owner-freebsd-sparc64@FreeBSD.ORG Fri Apr 11 21:40:05 2003 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 4A81737B401 for ; Fri, 11 Apr 2003 21:40:05 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6389943F3F for ; Fri, 11 Apr 2003 21:40:04 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h3C4enxS098453; Sat, 12 Apr 2003 00:40:49 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h3C4enwR098452; Sat, 12 Apr 2003 00:40:49 -0400 (EDT) Date: Sat, 12 Apr 2003 00:40:49 -0400 From: Jake Burkholder To: Narvi Message-ID: <20030412044048.GA97094@locore.ca> References: <20030411224922.B75698-100000@haldjas.folklore.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030411224922.B75698-100000@haldjas.folklore.ee> User-Agent: Mutt/1.4i cc: freebsd-sparc64@freebsd.org Subject: Re: tlb, tsb & ...stuff 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, 12 Apr 2003 04:40:05 -0000 Hmm, so someone else has read that code. :) Apparently, On Sat, Apr 12, 2003 at 02:12:43AM +0300, Narvi said words to the effect of; > > ok, I'm a lamer and couldn't think of a nice & spiffy subject line. > > > TLB / TSB statistics: > > Presently we only get statistics on entries being moved into TSB, with no > dtlb/itlb separation. Unless people think this is a bad idea, I'd like to > make an option that would expose dTLB/iTLB and related TSB misses as > statisics. this would allow you to get Solaris 9 style 'trapstat -t' > information. The counters would need to be per-processor. Well, the problem is the current tlb fault handlers are really tight on space in the trap table. I think the tl0_immu_miss and tl0_dmmu_prot have 0 or 1 instructions free. Incrementing counters to track dTLB misses will take 3 instructions minimum, so you'd have to do something like ifdef the handlers to just branch to code at the end of the trap table if the counters are enabled, which gets pretty ugly. You're welcome to do this and report results, but I'm not sure I want it to be committed. There are some adhoc statistics on tsb replacements with options PMAP_STATS, under sysctl debug.pmap_stats. In my experience few replacements occur unless you are using a lot of memory. Adding statistics in the page fault path sounds fine, but lower than that I'm not so sure. > > > TSB & replacement: > > >From what I gather (please correct me if I'm wrong!) the present TSB > consists of 2K entries, organised into buckets with each bucket containing > 4 entries. On replacement/entry we enter into an entry that was > empty/invalid or pick one "randomly" based on the lower digits of tick. We > try 4 times (for each page size) so up to 16 places get probed before a > miss / hit. > > Making it a 4-way random replacement software managed unified L2 tlb (with > slight oddness for multiple pages sizes). Yes, this is correct. The multiple page size stuff doesn't work as well as I'd like, and the vm system isn't setup to use it yet (this is a lot of work). I consider the current tsb implementation to be a bit of an experiment (I'd never dealt with pmap or tlb fault handlers when I started) and worth throwing out completely if we can think of something better. Its decent and fast in most cases but the fixed size of the tsb, which causes the replacements, limits the RSS that a process can have without casuing soft faults into the vm system. The kernel gets bogged down with soft faults pretty fast if you go out the RSS that fits in the tsb. You can really see this if you reduce the size of the tsb. It works well enough for current workloads but once we start supporting things like X I'm not sure that it will fly. I've been planning to replace it with something that's more like page tables and not so reliant on hashing in the same sense. The way it works is in the base case you have a 1 page direct mapped tsb (ie no buckets), indexed by the first 8 bits of virtual address above page size (call this level 0). On a miss in the tsb the tlb fault handler would check a bit in the tte which indicates that there's actually another level and the tte just loaded (the "miss" tte) contains a pointer to it. So it would restart the lookup using the new tsb page. The twist is that as you go the next level you use the next higher "page spread" virtual address bits to index the tsb pages. Basically collisions in the address bits used to index a given level cause another level to be added which is indexed by the next higher set of virtual address bits, instead of causing replacements. The lookup function for an arbitrary level looks something like this: #define TSB_MAX_LEVEL (3) #define TSB_PAGE_ADDRESS_BITS (8) static __inline struct tte * tsb_vpntotte(struct tte *tsb, vm_offset_t vpn, int level) { return (&tsb[(vpn >> (TSB_PAGE_ADDRESS_BITS * level)) & ((1 << TSB_PAGE_ADDRESS_BITS) - 1)]); } static __inline struct tte * tsb_vtotte(struct tte *tsb, vm_offset_t va, int level) { return (tsb_vpntotte(tsb, va >> TAR_VPN_SHIFT, level)); } With 3 levels this can support a 32 gigabyte virtual address space (fully resident), but doesn't penalize processes with sparse address spaces due to not requiring intermediate "page table pages" in all cases. Basically like traditional page tables but backwards :). This has an added advantage of not requiring more than 1 page of contiguous virtual or physical address space for any part of the tsb. With the current implementation you can't increase the tsb size too much because it allocates a large chunk of contiguous virtual address space and as the the kernel address space gets fragmented you start to run out. I'm not sure if you've looked at the kernel tlb fault handlers, but the same technique that's used in MIPS and alpha kernels is used to provide a direct mapped address space region, which corresponds to the upper VA hole on UltraSPARC II. What this does is maps all of physical memory into the upper portion of the address space using 4 meg tlb entries. The physical address is encoded in the virtual address, so the fault handler just needs to extract it and whip up a tlb entry on the fly. No page tables, no lookups, no nothing. This would allow the tsb pages to be mapped with the direct mapped address space, so no mappable kva would be required for the tsb. > > It would imho be interesting to support a couple of different and > selectable entry indexing policies, say at least: > > * hashed > * skew-associative > > to cater for various access patterns & tsb lookup loads. Again, if this > would be a bad idea, let me know. Its a good idea and I'd be interested in the results, but what I'm more interested in is new data structures to support virtual memory that give improvements in design or architecture, rather than heuristics such as tweaking the hashing algorithms. > > Usparc3(cu) > > What will happen there? Do we use any of the large page sizes enough to > make one of the large TLB-s cache a large(r) page size? Yes, see above about the direct mapped address space. I've read papers on generalized schemes for using large page sizes for user mappings, but I'm not sure if we'll see this anytime soon in FreeBSD in a big way. However, the 2 512 entry tlbs with programmable page sizes on USIII+ should work very well with one programmed for 4meg tlb entries and the other for 8K. The direct mapping technique is hooked into the kernel zone allocator, uma, which is also the back end allocator for malloc(9), so allocations of objects that are less than a page minus some overhead use it, which for the most part would give the kernel an entire 512 entry tlb for itself. This may or may not be faster than just using it as a single 1024 entry tlb for 8K mappings, have to see. Anyway, hope I didn't completely blow over your question. Jake From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 12 09:12:38 2003 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 13C9837B401 for ; Sat, 12 Apr 2003 09:12:38 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0C8243F85 for ; Sat, 12 Apr 2003 09:12:36 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h3CGCZUE004438; Sat, 12 Apr 2003 19:12:35 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h3CGCVm0004435; Sat, 12 Apr 2003 19:12:35 +0300 (EEST) Date: Sat, 12 Apr 2003 19:12:31 +0300 (EEST) From: Narvi To: Jake Burkholder In-Reply-To: <20030412044048.GA97094@locore.ca> Message-ID: <20030412174934.E75698-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: tlb, tsb & ...stuff 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, 12 Apr 2003 16:12:38 -0000 On Sat, 12 Apr 2003, Jake Burkholder wrote: > > Hmm, so someone else has read that code. :) > > Apparently, On Sat, Apr 12, 2003 at 02:12:43AM +0300, > Narvi said words to the effect of; > > > > > ok, I'm a lamer and couldn't think of a nice & spiffy subject line. > > > > > > TLB / TSB statistics: > > > > Presently we only get statistics on entries being moved into TSB, with no > > dtlb/itlb separation. Unless people think this is a bad idea, I'd like to > > make an option that would expose dTLB/iTLB and related TSB misses as > > statisics. this would allow you to get Solaris 9 style 'trapstat -t' > > information. The counters would need to be per-processor. > > Well, the problem is the current tlb fault handlers are really tight on > space in the trap table. I think the tl0_immu_miss and tl0_dmmu_prot > have 0 or 1 instructions free. Incrementing counters to track dTLB > misses will take 3 instructions minimum, so you'd have to do something > like ifdef the handlers to just branch to code at the end of the trap > table if the counters are enabled, which gets pretty ugly. You're welcome > to do this and report results, but I'm not sure I want it to be committed. > Ah, yes, this would be bad - > There are some adhoc statistics on tsb replacements with options PMAP_STATS, > under sysctl debug.pmap_stats. In my experience few replacements occur unless > you are using a lot of memory. > > Adding statistics in the page fault path sounds fine, but lower than that I'm > not so sure. > > > > > > > TSB & replacement: > > > > >From what I gather (please correct me if I'm wrong!) the present TSB > > consists of 2K entries, organised into buckets with each bucket containing > > 4 entries. On replacement/entry we enter into an entry that was > > empty/invalid or pick one "randomly" based on the lower digits of tick. We > > try 4 times (for each page size) so up to 16 places get probed before a > > miss / hit. > > > > Making it a 4-way random replacement software managed unified L2 tlb (with > > slight oddness for multiple pages sizes). > > Yes, this is correct. The multiple page size stuff doesn't work as well as > I'd like, and the vm system isn't setup to use it yet (this is a lot of > work). I consider the current tsb implementation to be a bit of an experiment > (I'd never dealt with pmap or tlb fault handlers when I started) and worth > throwing out completely if we can think of something better. Its decent and > fast in most cases but the fixed size of the tsb, which causes the > replacements, limits the RSS that a process can have without casuing soft > faults into the vm system. The kernel gets bogged down with soft faults > pretty fast if you go out the RSS that fits in the tsb. You can really see > this if you reduce the size of the tsb. It works well enough for current > workloads but once we start supporting things like X I'm not sure that it > will fly. So these are mainly capacity and not conflict misses? The obvious wasy to improve this would be to increase the size and eliminate the TAILQ, unless the TAILQ linking removal would cause massive changes. But entry number wise we are probably at the minimal range right now. > > I've been planning to replace it with something that's more like page tables > and not so reliant on hashing in the same sense. The way it works is in the > base case you have a 1 page direct mapped tsb (ie no buckets), indexed by the > first 8 bits of virtual address above page size (call this level 0). On a > miss in the tsb the tlb fault handler would check a bit in the tte which > indicates that there's actually another level and the tte just loaded (the > "miss" tte) contains a pointer to it. So it would restart the lookup using > the new tsb page. The twist is that as you go the next level you use the > next higher "page spread" virtual address bits to index the tsb pages. > Basically collisions in the address bits used to index a given level cause > another level to be added which is indexed by the next higher set of virtual > address bits, instead of causing replacements. The lookup function for an > arbitrary level looks something like this: > > #define TSB_MAX_LEVEL (3) > #define TSB_PAGE_ADDRESS_BITS (8) > > static __inline struct tte * > tsb_vpntotte(struct tte *tsb, vm_offset_t vpn, int level) > { > return (&tsb[(vpn >> (TSB_PAGE_ADDRESS_BITS * level)) & > ((1 << TSB_PAGE_ADDRESS_BITS) - 1)]); > } > > static __inline struct tte * > tsb_vtotte(struct tte *tsb, vm_offset_t va, int level) > { > return (tsb_vpntotte(tsb, va >> TAR_VPN_SHIFT, level)); > } > > With 3 levels this can support a 32 gigabyte virtual address space (fully > resident), but doesn't penalize processes with sparse address spaces due > to not requiring intermediate "page table pages" in all cases. Basically > like traditional page tables but backwards :). > This would have rather bad locality of access though, no? The conflict side of the thing is resolvable (to an extent) using it as a sum or xor addressed cache. I guess I should whip up some code to show what I mean. Missing in L2 can delay you for say 100 cycles. Also, this scheme cause the pages to accumulate with basicly no eviction of 'vist once' pages. > This has an added advantage of not requiring more than 1 page of contiguous > virtual or physical address space for any part of the tsb. With the current > implementation you can't increase the tsb size too much because it allocates > a large chunk of contiguous virtual address space and as the the kernel address > space gets fragmented you start to run out. I'm not sure if you've looked at > the kernel tlb fault handlers, but the same technique that's used in MIPS > and alpha kernels is used to provide a direct mapped address space region, > which corresponds to the upper VA hole on UltraSPARC II. What this does is > maps all of physical memory into the upper portion of the address space using > 4 meg tlb entries. The physical address is encoded in the virtual address, > so the fault handler just needs to extract it and whip up a tlb entry on the > fly. No page tables, no lookups, no nothing. This would allow the tsb pages > to be mapped with the direct mapped address space, so no mappable kva would > be required for the tsb. > Another way to overcome the would be to allocate teh different "ways" of the TSB separately, so that the area need not be contiguous. > > > > It would imho be interesting to support a couple of different and > > selectable entry indexing policies, say at least: > > > > * hashed > > * skew-associative > > > > to cater for various access patterns & tsb lookup loads. Again, if this > > would be a bad idea, let me know. > > Its a good idea and I'd be interested in the results, but what I'm more > interested in is new data structures to support virtual memory that give > improvements in design or architecture, rather than heuristics such as > tweaking the hashing algorithms. > The problem is that almost anything you try is guaranteed to lose under different loads. > > > > Usparc3(cu) > > > > What will happen there? Do we use any of the large page sizes enough to > > make one of the large TLB-s cache a large(r) page size? > > Yes, see above about the direct mapped address space. I've read papers on > generalized schemes for using large page sizes for user mappings, but I'm > not sure if we'll see this anytime soon in FreeBSD in a big way. However, the > 2 512 entry tlbs with programmable page sizes on USIII+ should work very well > with one programmed for 4meg tlb entries and the other for 8K. The direct > mapping technique is hooked into the kernel zone allocator, uma, which is > also the back end allocator for malloc(9), so allocations of objects that are > less than a page minus some overhead use it, which for the most part would > give the kernel an entire 512 entry tlb for itself. This may or may not be > faster than just using it as a single 1024 entry tlb for 8K mappings, have > to see. > I was more thinking about say using 64K pages for user stack or malloc or similar - it doesn't quite have the same complexity as general mapping scheme, in the malloc case could be requested by the user and would keep pressure or TLB & faults down. But sounds like this is not simple/feasible for now. > Anyway, hope I didn't completely blow over your question. > > Jake > From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 12 10:40:10 2003 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 85E7537B401 for ; Sat, 12 Apr 2003 10:40:10 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B02D743FAF for ; Sat, 12 Apr 2003 10:40:09 -0700 (PDT) (envelope-from don_homer@gmx.net) Received: (qmail 27415 invoked by uid 65534); 12 Apr 2003 17:40:08 -0000 Received: from pc4-ipsw1-3-cust208.colc.cable.ntl.com (HELO donhomer) (81.98.252.208) by mail.gmx.net (mp013-rz3) with SMTP; 12 Apr 2003 19:40:08 +0200 From: To: freebsd-sparc@FreeBSD.org Date: Sat, 12 Apr 2003 18:37:52 +0100 Priority: Normal X-mailer: Phoenix Mail Version 20030219 (5.0/2195) MIME-Version: 1.0 Content-type: multipart/mixed; boundary=--PhoenixRRAH--20030412-184027- Message-Id: <20030412174009.B02D743FAF@mx1.FreeBSD.org> Subject: freebsd on sparcstation 20 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, 12 Apr 2003 17:40:10 -0000 ----PhoenixRRAH--20030412-184027- Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable hi there, i have a short question. is it possible to run freebsd on a sparcstation 20 with 144mb of memory=3F if yes, which portation do i have to use=3F thanks in advance, gerald ----PhoenixRRAH--20030412-184027--- From owner-freebsd-sparc64@FreeBSD.ORG Sat Apr 12 10:45:16 2003 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 C12AD37B401 for ; Sat, 12 Apr 2003 10:45:16 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CBD943F93 for ; Sat, 12 Apr 2003 10:45:15 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 194NUs-0004mm-00; Sat, 12 Apr 2003 09:04:54 -0700 Date: Sat, 12 Apr 2003 09:04:52 -0700 (PDT) From: Tom Samplonius To: don_homer@gmx.net In-Reply-To: <20030412174009.B02D743FAF@mx1.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: cc: freebsd-sparc@FreeBSD.org Subject: Re: freebsd on sparcstation 20 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, 12 Apr 2003 17:45:17 -0000 On Sat, 12 Apr 2003 don_homer@gmx.net wrote: > i have a short question. is it possible to run freebsd on a > sparcstation 20 with 144mb of memory? if yes, which portation do i > have to use? > > gerald Sparc 20s are 32bit. FreeBSD/sparc64 only works on 64 bit Sparcs (UltraSparc CPUs). NetBSD and OpenBSD have distributions for 32bit Sparc systems like the Sparc 20. Tom