From owner-freebsd-sparc64@FreeBSD.ORG Sun Oct 9 12:33:34 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 9777916A41F for ; Sun, 9 Oct 2005 12:33:34 +0000 (GMT) (envelope-from ardelean@ww.uni-erlangen.de) Received: from servww6.ww.uni-erlangen.de (servww6.ww.uni-erlangen.de [131.188.238.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA25043D46 for ; Sun, 9 Oct 2005 12:33:33 +0000 (GMT) (envelope-from ardelean@ww.uni-erlangen.de) Received: from localhost (ardelean@localhost) by servww6.ww.uni-erlangen.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j99CXTX22364 for ; Sun, 9 Oct 2005 14:33:29 +0200 Date: Sun, 9 Oct 2005 14:33:29 +0200 (CEST) From: Gheorghe Ardelean To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Installing 6.0-BETA5 on Ultra30: RED State Exception X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 12:33:34 -0000 Hi, I have given to FreeBSD 6.0-BETA5 a try on my 250MHz Ultra30. Unfortunately there are problems with it just from the beginning. The first problem I have encountered was the "Release name" which is 6.0-BETA4. Because of this none of the distributions could be found. After restarting and changing this in 6.0-BETA5 (in the Options menu) the distributions could be found but after chunk 34 from bin I get a RED State Exception. ....... 47834112 bytes read from base dist, chunk 34 of 41 @ 655.3 KBytes/sec. RED State Exception TL=0000.0000.0000.0005 TT=0000.0000.0000.0010 TPC=0000.0000.c004.4200 TnPC=0000.0000.c004.4204 TSTATE=0000.0044.5800.1505 TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 TPC=0000.0000.c004.4200 TnPC=0000.0000.c004.4204 TSTATE=0000.0044.5800.1505 TL=0000.0000.0000.0003 TT=0000.0000.0000.0010 TPC=0000.0000.c004.4c60 TnPC=0000.0000.c004.4c64 TSTATE=0000.0044.5800.1505 TL=0000.0000.0000.0002 TT=0000.0000.0000.0063 TPC=0000.0000.c004.8f6c TnPC=0000.0000.c004.8f70 TSTATE=0000.0044.5800.1605 TL=0000.0000.0000.0001 TT=0000.0000.0000.0141 TPC=0000.0000.0020.eba4 TnPC=0000.0000.0020.eba8 TSTATE=0000.0044.0000.1204 ....... A FreeBSD snapshot from 27.07.04 (some 5.2?) works perfectly. What could case this? Any idea? Regards, Gheorghe Ardelean. From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 10 11:02:12 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 8FF8116A438 for ; Mon, 10 Oct 2005 11:02:12 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F05A43D46 for ; Mon, 10 Oct 2005 11:02:12 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9AB2C9u051491 for ; Mon, 10 Oct 2005 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9AB2Ade051484 for freebsd-sparc64@freebsd.org; Mon, 10 Oct 2005 11:02:10 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Oct 2005 11:02:10 GMT Message-Id: <200510101102.j9AB2Ade051484@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 11:02:12 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/09/14] sparc64/71729sparc64 printf in kernel thread causes panic on S o [2004/10/21] sparc64/72962sparc64 [sysinstall] Sysinstall panics on sparc64 o [2005/02/12] sparc64/77417sparc64 [panic] with high usage of cpu when lan u f [2005/04/27] sparc64/80410sparc64 netgraph is causing crash with mpd on spa o [2005/05/11] sparc64/80890sparc64 [panic] kmem_malloc(73728): kmem_map too o [2005/06/23] sparc64/82569sparc64 USB mass storage plug/unplug causes syste 6 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/22] sparc64/72998sparc64 [patch] set_mcontext() change syscalls pa o [2005/06/26] sparc64/82681sparc64 [if_dc] dc state messages 2 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 10 13:47:53 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 77E9D16A420 for ; Mon, 10 Oct 2005 13:47:53 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA4243D48 for ; Mon, 10 Oct 2005 13:47:52 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id j9ADloQL072162; Mon, 10 Oct 2005 15:47:50 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j9ADljc5072161; Mon, 10 Oct 2005 15:47:45 +0200 (CEST) (envelope-from marius) Date: Mon, 10 Oct 2005 15:47:45 +0200 From: Marius Strobl To: Gheorghe Ardelean Message-ID: <20051010154745.A71846@newtrinity.zeist.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ardelean@ww.uni-erlangen.de on Sun, Oct 09, 2005 at 02:33:29PM +0200 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.1-9; AVE: 6.32.0.8; VDF: 6.32.0.69; host: newtrinity.zeist.de) Cc: freebsd-sparc64@freebsd.org Subject: Re: Installing 6.0-BETA5 on Ultra30: RED State Exception X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 13:47:53 -0000 On Sun, Oct 09, 2005 at 02:33:29PM +0200, Gheorghe Ardelean wrote: > > > Hi, > > I have given to FreeBSD 6.0-BETA5 a try on my 250MHz Ultra30. > Unfortunately there are problems with it just from the beginning. > > The first problem I have encountered was the "Release name" > which is 6.0-BETA4. Because of this none of the distributions could be > found. After restarting and changing this in 6.0-BETA5 (in the Options > menu) the distributions could be found but after chunk 34 from bin I get a > RED State Exception. > > ....... > 47834112 bytes read from base dist, chunk 34 of 41 @ 655.3 KBytes/sec. > RED State Exception > > TL=0000.0000.0000.0005 TT=0000.0000.0000.0010 > TPC=0000.0000.c004.4200 TnPC=0000.0000.c004.4204 > TSTATE=0000.0044.5800.1505 > TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 > TPC=0000.0000.c004.4200 TnPC=0000.0000.c004.4204 > TSTATE=0000.0044.5800.1505 > TL=0000.0000.0000.0003 TT=0000.0000.0000.0010 trap level 3-5, trap type 0x10: illegal_instruction > TPC=0000.0000.c004.4c60 TnPC=0000.0000.c004.4c64 > TSTATE=0000.0044.5800.1505 > TL=0000.0000.0000.0002 TT=0000.0000.0000.0063 trap level 2, trap type 0x63: corrected_ECC_error > TPC=0000.0000.c004.8f6c TnPC=0000.0000.c004.8f70 > TSTATE=0000.0044.5800.1605 > TL=0000.0000.0000.0001 TT=0000.0000.0000.0141 trap level 1, trap type 0x141: system call > TPC=0000.0000.0020.eba4 TnPC=0000.0000.0020.eba8 > TSTATE=0000.0044.0000.1204 > ....... > > A FreeBSD snapshot from 27.07.04 (some 5.2?) works perfectly. > > What could case this? Any idea? > The problem is that a corrected_ECC_error trap happens while handling another one. In general FreeBSD doesn't handle corrected_ECC_error traps very well. Nevertheless it means a hardware problem. Often these happen due to problems with the electrical contacts and re-seating the CPU and the memory modules solves them. If not you probably have a fault memory module if these traps happen regularly. The OBP diagnostics (vary from model to model however) and SunVTS should be able to identify a broken memory module. It's most likely just coincidence that you don't see them with FreeBSD 5.2, there where no changes since July '04 which affect handling of corrected_ECC_error traps. Btw., if you actually have a broken memory module would you ship it to me for implementing proper handling of corrected_ECC_error traps? Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 11 21:38:02 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org 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 9C07216A41F; Tue, 11 Oct 2005 21:38:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A0943D48; Tue, 11 Oct 2005 21:38:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id C5F321A3C25; Tue, 11 Oct 2005 14:38:01 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B2D6851334; Tue, 11 Oct 2005 17:38:00 -0400 (EDT) Date: Tue, 11 Oct 2005 17:38:00 -0400 From: Kris Kennaway To: current@FreeBSD.org, sparc64@FreeBSD.org Message-ID: <20051011213800.GA8839@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: des@FreeBSD.org Subject: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 21:38:02 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A few weeks ago I reported that bufinit() on sparc64 machines with >12GB of RAM goes into an infinite loop because of a 32-bit integer counter overflowing. On 5.x it was possible to work around this with the kern.maxbcache tunable, but this didn't work on 6.0 or above. It turns out the problem began here: ---- Revision 1.67 / (download) - annotate - [select for diffs], Mon Nov 8 18:20= :02 2004 UTC (11 months ago) by des Branch: MAIN Changes since 1.66: +17 -17 lines Diff to previous 1.66 (colored) #include instead of (the former includes the latter, but also declares variables which are defined in kern/subr_param.c). Change som VM parameters from quad_t to unsigned long. They refer to quantities (size limits for text, heap and stack segments) which must necessarily be smaller than the size of the address space, so long is adequate on all platforms. MFC after: 1 week ---- which contained: -int maxswzone; /* max swmeta KVA storage */ -int maxbcache; /* max buffer cache KVA storage */ +long maxswzone; /* max swmeta KVA storage */ +long maxbcache; /* max buffer cache KVA storage */ However, des forgot to change the other definition of maxbcache in : extern int maxbcache; /* Max KVA for buffer cache */ In fact, it's a good thing he didn't. On sparc64 if you make that variable a long it causes 32-bit integer overflows elsewhere, which lead to severe filesystem damage on systems with >12GB RAM. With the above bug this is reduced to a hang at boot. The hang is because maxbcache is not capped to a maximum value on sparc64, and a loop termination condition never occurs because of a 32-bit integer overflow. On amd64 it's capped to /* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. */ #ifndef VM_BCACHE_SIZE_MAX #define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) #endif so large-memory amd64 systems never see it. ia64 and ppc would also hang at boot with >12GB, I think. On 5.x, the same hang exists, but you can work around it with the tunable. This tunable was broken by the long/int mismatch on 6.0, so sparc64 systems with >12GB were unusable. This patch reverts the above int->long change, and adds definitions for VM_BCACHE_SIZE_MAX and VM_SWZONE_SIZE_MAX on sparc64 copied from amd64. Actually, they should probably be added on other architectures too (ia64, ppc). Can someone please review? Kris Index: kern/subr_param.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/kern/subr_param.c,v retrieving revision 1.71 diff -u -r1.71 subr_param.c --- kern/subr_param.c 16 Apr 2005 15:07:41 -0000 1.71 +++ kern/subr_param.c 11 Oct 2005 21:09:01 -0000 @@ -75,8 +75,8 @@ int ncallout; /* maximum # of timer events */ int nbuf; int nswbuf; -long maxswzone; /* max swmeta KVA storage */ -long maxbcache; /* max buffer cache KVA storage */ +int maxswzone; /* max swmeta KVA storage */ +int maxbcache; /* max buffer cache KVA storage */ int maxpipekva; /* Limit on pipe KVA */ u_long maxtsiz; /* max text size */ u_long dfldsiz; /* initial data size limit */ @@ -106,11 +106,11 @@ #ifdef VM_SWZONE_SIZE_MAX maxswzone =3D VM_SWZONE_SIZE_MAX; #endif - TUNABLE_LONG_FETCH("kern.maxswzone", &maxswzone); + TUNABLE_INT_FETCH("kern.maxswzone", &maxswzone); #ifdef VM_BCACHE_SIZE_MAX maxbcache =3D VM_BCACHE_SIZE_MAX; #endif - TUNABLE_LONG_FETCH("kern.maxbcache", &maxbcache); + TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); =20 maxtsiz =3D MAXTSIZ; TUNABLE_ULONG_FETCH("kern.maxtsiz", &maxtsiz); Index: sparc64/include/param.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/sparc64/include/param.h,v retrieving revision 1.19 diff -u -r1.19 param.h --- sparc64/include/param.h 20 Nov 2004 02:29:50 -0000 1.19 +++ sparc64/include/param.h 11 Oct 2005 20:54:30 -0000 @@ -110,6 +110,22 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ #define PCPU_PAGES 1 =20 +/* + * Ceiling on amount of swblock kva space, can be changed via + * the kern.maxswzone /boot/loader.conf variable. + */ +#ifndef VM_SWZONE_SIZE_MAX +#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) +#endif + +/* + * Ceiling on size of buffer cache (really only effects write queueing, + * the VM page cache is not effected), can be changed via + * the kern.maxbcache /boot/loader.conf variable. + */ +#ifndef VM_BCACHE_SIZE_MAX +#define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) +#endif =20 /* * Mach derived conversion macros Index: sparc64/include/vmparam.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/sparc64/include/vmparam.h,v retrieving revision 1.14 diff -u -r1.14 vmparam.h --- sparc64/include/vmparam.h 27 Dec 2002 19:31:26 -0000 1.14 +++ sparc64/include/vmparam.h 11 Oct 2005 20:54:30 -0000 @@ -171,6 +171,13 @@ #endif =20 /* + * Ceiling on amount of kmem_map kva space. + */ +#ifndef VM_KMEM_SIZE_MAX +#define VM_KMEM_SIZE_MAX (400 * 1024 * 1024) +#endif + +/* * Initial pagein size of beginning of executable file. */ #ifndef VM_INITIAL_PAGEIN --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTDC4Wry0BWjoQKURAkJgAKDIdrvK7BIwszOZzA4j4aIoLzxjlwCglEmc 0c949Eta0QRcZL2IGt8aNcg= =b4Eg -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 12 10:36:27 2005 Return-Path: X-Original-To: sparc64@freebsd.org 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 135B116A41F; Wed, 12 Oct 2005 10:36:27 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC4B43D53; Wed, 12 Oct 2005 10:36:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E2AA.dip.t-dialin.net [84.163.226.170] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1EPdyC06sI-0003z2; Wed, 12 Oct 2005 12:36:24 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 12:36:50 +0200 User-Agent: KMail/1.8.2 References: <20051011213800.GA8839@xor.obsecurity.org> In-Reply-To: <20051011213800.GA8839@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3464263.jPie93MmLt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510121237.07383.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: sparc64@freebsd.org, des@freebsd.org, Kris Kennaway Subject: Re: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 10:36:27 -0000 --nextPart3464263.jPie93MmLt Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 October 2005 23:38, Kris Kennaway wrote: > A few weeks ago I reported that bufinit() on sparc64 machines with > > >12GB of RAM goes into an infinite loop because of a 32-bit integer > > counter overflowing. On 5.x it was possible to work around this with > the kern.maxbcache tunable, but this didn't work on 6.0 or above. > > It turns out the problem began here: > > ---- > Revision 1.67 / (download) - annotate - [select for diffs], Mon Nov 8 > 18:20:02 2004 UTC (11 months ago) by des Branch: MAIN > Changes since 1.66: +17 -17 lines > Diff to previous 1.66 (colored) > > #include instead of (the former > includes the latter, but also declares variables which are defined > in kern/subr_param.c). > > Change som VM parameters from quad_t to unsigned long. They refer to > quantities (size limits for text, heap and stack segments) which must > necessarily be smaller than the size of the address space, so long is > adequate on all platforms. > > MFC after: 1 week > ---- > > which contained: > > -int maxswzone; /* max swmeta KVA storage */ > -int maxbcache; /* max buffer cache KVA storage */ > +long maxswzone; /* max swmeta KVA storage */ > +long maxbcache; /* max buffer cache KVA storage */ > > However, des forgot to change the other definition of maxbcache in > : > > extern int maxbcache; /* Max KVA for buffer cache */ > > In fact, it's a good thing he didn't. On sparc64 if you make that > variable a long it causes 32-bit integer overflows elsewhere, which > lead to severe filesystem damage on systems with >12GB RAM. With the > above bug this is reduced to a hang at boot. Isn't it enough to introduce the maximum values below? I imagine that the= =20 ultimate goal is to get rid of the constrains, which will be easier if we=20 already have enough bits. > The hang is because maxbcache is not capped to a maximum value on > sparc64, and a loop termination condition never occurs because of a > 32-bit integer overflow. On amd64 it's capped to > > /* > * Ceiling on size of buffer cache (really only effects write queueing, > * the VM page cache is not effected), can be changed via > * the kern.maxbcache /boot/loader.conf variable. > */ > #ifndef VM_BCACHE_SIZE_MAX > #define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) > #endif > > so large-memory amd64 systems never see it. ia64 and ppc would also > hang at boot with >12GB, I think. > > On 5.x, the same hang exists, but you can work around it with the > tunable. This tunable was broken by the long/int mismatch on 6.0, so > sparc64 systems with >12GB were unusable. > > This patch reverts the above int->long change, and adds definitions > for VM_BCACHE_SIZE_MAX and VM_SWZONE_SIZE_MAX on sparc64 copied from > amd64. Actually, they should probably be added on other architectures > too (ia64, ppc). > > Can someone please review? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3464263.jPie93MmLt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTOdTXyyEoT62BG0RAhYIAJ9MlHeu+lXjwgrOw/ZQ/ecl90Lo+gCcDxLL 4BSiJP1pYKOfeRTr2Y8Voo0= =oq8D -----END PGP SIGNATURE----- --nextPart3464263.jPie93MmLt-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 12 11:53:34 2005 Return-Path: X-Original-To: freebsd-sparc64@FreeBSD.org 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 244CD16A420; Wed, 12 Oct 2005 11:53:34 +0000 (GMT) (envelope-from bel@orel.ru) Received: from tts.orel.ru (tts.orel.ru [213.59.64.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6484E43D58; Wed, 12 Oct 2005 11:53:31 +0000 (GMT) (envelope-from bel@orel.ru) Received: from [192.168.99.99] (pf1.net.orel.ru [213.59.64.75]) by tts.orel.ru (8.13.1/8.13.1/bel) with ESMTP id j9CBrX29000890; Wed, 12 Oct 2005 15:53:34 +0400 Message-ID: <434CF933.1020601@orel.ru> Date: Wed, 12 Oct 2005 15:53:23 +0400 From: Andrew Belashov Organization: ORIS User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050419) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <200509080711.j887Bokb036115@freefall.freebsd.org> In-Reply-To: <200509080711.j887Bokb036115@freefall.freebsd.org> X-Enigmail-Version: 0.91.0.0 OpenPGP: url=http://keyserver.veridis.com:11371/export?id=-4584918800852016142 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Zombi-Check: on netra2.orel.ru Cc: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/80410: netgraph is causing crash with mpd on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 11:53:34 -0000 Hello, Gleb! Gleb Smirnoff wrote: > Synopsis: netgraph is causing crash with mpd on sparc64 > > State-Changed-From-To: open->feedback > State-Changed-By: glebius > State-Changed-When: Thu Sep 8 07:11:36 GMT 2005 > State-Changed-Why: > Can you please merge the revision 1.57 of src/sys/netgraph/ng_ksocket.c > into your kernel and try to reproduce the problem. > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=80410 > This revision does not resolve problem. The problem is sparc specific. i386 has no alignment constraints (a small speed hit though). ===[debug log]========================================================= This GDB was configured as "sparc64-portbld-freebsd5.4"... panic: trap: memory address not aligned panic messages: --- panic: trap: memory address not aligned cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 boot() called on cpu#0 Uptime: 3m2s Dumping 1024 MB (2 chunks) chunk at 0x80000000: 536870912 bytes |\^H --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:246 246 savectx(&dumppcb); (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:246 #1 0x00000000c01829d8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 #2 0x00000000c0183244 in panic (fmt=0xc03b4b80 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:567 #3 0x00000000c0065b08 in db_panic (addr=3222937208, have_addr=0, count=-1, modif=0xe0258950 "") at /usr/src/sys/ddb/db_command.c:435 #4 0x00000000c0065c44 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349 #5 0x00000000c00686c8 in db_trap (type=107, code=0) at /usr/src/sys/ddb/db_main.c:210 #6 0x00000000c01a2468 in kdb_trap (type=107, code=0, tf=0x1) at /usr/src/sys/kern/subr_kdb.c:470 #7 0x00000000c0324f64 in trap (tf=0xe0258d20) at /usr/src/sys/sparc64/sparc64/trap.c:307 #8 0x00000000c01a1e78 in kdb_enter (msg=---Can't read userspace from dump, or kernel process--- ) at /usr/src/sys/kern/subr_kdb.c:265 #9 0x00000000c01a1e70 in kdb_enter (msg=0xc03d29f0 "panic") at /usr/src/sys/kern/subr_kdb.c:265 #10 0x00000000c01832b4 in panic (fmt=0xc03eb5f0 "trap: %s") at atomic.h:278 #11 0x00000000c0324e7c in trap (tf=0xe0259120) at /usr/src/sys/sparc64/sparc64/trap.c:369 #12 0x00000000c022e920 in tcp_input (m=0xfffff800b08ac900, off0=64) at /usr/src/sys/netinet/tcp_input.c:538 #13 0x00000000c022e90c in tcp_input (m=0xfffff800b08ac900, off0=20) at /usr/src/sys/netinet/tcp_input.c:535 #14 0x00000000c0225210 in ip_input (m=0xfffff800b08ac900) at /usr/src/sys/netinet/ip_input.c:776 #15 0x00000000c020fbbc in netisr_processqueue (ni=0xc0453158) at /usr/src/sys/net/netisr.c:235 #16 0x00000000c020ff34 in swi_net (dummy=0x0) at atomic.h:278 #17 0x00000000c016a084 in ithread_loop (arg=0xfffff8008042f700) at /usr/src/sys/kern/kern_intr.c:547 #18 0x00000000c0168948 in fork_exit (callout=0xc0169f60 , arg=0xfffff8008042f700, frame=0xe0259880) at /usr/src/sys/kern/kern_fork.c:791 (kgdb) frame 14 #14 0x00000000c0225210 in ip_input (m=0xfffff800b08ac900) at /usr/src/sys/netinet/ip_input.c:776 776 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); (kgdb) p ip $1 = (struct ip *) 0xfffff800b081a035 ------------------------------------^ (memory address not aligned) (kgdb) p ip[0] $2 = {ip_v = 0, ip_hl = 0, ip_tos = 0 '\0', ip_len = 0, ip_id = 0, ip_off = 0, ip_ttl = 0 '\0', ip_p = 6 '\006', ip_sum = 42107, ip_src = { s_addr = 167772162}, ip_dst = {s_addr = 168427777}} (kgdb) p/x ip[0] $3 = {ip_v = 0x0, ip_hl = 0x0, ip_tos = 0x0, ip_len = 0x0, ip_id = 0x0, ip_off = 0x0, ip_ttl = 0x0, ip_p = 0x6, ip_sum = 0xa47b, ip_src = { s_addr = 0xa000002}, ip_dst = {s_addr = 0xa0a0101}} -- With Best Regards, Andrew Belashov. From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 12 16:55:38 2005 Return-Path: X-Original-To: sparc64@freebsd.org 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 B1BCB16A46E; Wed, 12 Oct 2005 16:55:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6726B43D48; Wed, 12 Oct 2005 16:55:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id 483841A3C25; Wed, 12 Oct 2005 09:55:38 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 404B65141B; Wed, 12 Oct 2005 12:55:34 -0400 (EDT) Date: Wed, 12 Oct 2005 12:55:34 -0400 From: Kris Kennaway To: Max Laier Message-ID: <20051012165533.GA55776@xor.obsecurity.org> References: <20051011213800.GA8839@xor.obsecurity.org> <200510121237.07383.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200510121237.07383.max@love2party.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, sparc64@freebsd.org, des@freebsd.org, Kris Kennaway Subject: Re: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 16:55:39 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 12:36:50PM +0200, Max Laier wrote: > > -int maxswzone; /* max swmeta KVA storage */ > > -int maxbcache; /* max buffer cache KVA storage */ > > +long maxswzone; /* max swmeta KVA storage */ > > +long maxbcache; /* max buffer cache KVA storage */ > > > > However, des forgot to change the other definition of maxbcache in > > : > > > > extern int maxbcache; /* Max KVA for buffer cache */ > > > > In fact, it's a good thing he didn't. On sparc64 if you make that > > variable a long it causes 32-bit integer overflows elsewhere, which > > lead to severe filesystem damage on systems with >12GB RAM. With the > > above bug this is reduced to a hang at boot. >=20 > Isn't it enough to introduce the maximum values below? I imagine that th= e=20 > ultimate goal is to get rid of the constrains, which will be easier if we= =20 > already have enough bits. No, it's not. As I mentioned, on 5.x you can work around this problem by using the existing tunable to limit the parameter, but not on 6.0 unless you also revert long to int. Something is getting confused about whether that variable is a long or an int since it's inconsistently defined. Anyway, making these variables consistently long is a very bad idea until more of the system is ready for that - that was the first thing I tried when I identified the problem, and it completely destroyed all of my filesystems within seconds, requiring a reinstall. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTUAFWry0BWjoQKURAjk5AJ9d29kLADXDiqvwMBuSllZoTQwCGACg/R+4 NoD4Wzq2N1iTjS/VVwU4nxk= =F249 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 12 23:02:30 2005 Return-Path: X-Original-To: sparc64@freebsd.org 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 EFE0016A41F; Wed, 12 Oct 2005 23:02:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68C5043D45; Wed, 12 Oct 2005 23:02:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CN2TVk048986; Wed, 12 Oct 2005 19:02:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CN2TOB041168; Wed, 12 Oct 2005 19:02:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D879E7302F; Wed, 12 Oct 2005 19:02:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051012230228.D879E7302F@freebsd-current.sentex.ca> Date: Wed, 12 Oct 2005 19:02:28 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 23:02:31 -0000 TB --- 2005-10-12 22:02:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-12 22:02:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-10-12 22:02:00 - cleaning the object tree TB --- 2005-10-12 22:02:26 - checking out the source tree TB --- 2005-10-12 22:02:26 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-10-12 22:02:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-12 22:09:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-12 22:09:29 - cd /src TB --- 2005-10-12 22:09:29 - /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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -o savecore savecore.o -lz gzip -cn /src/sbin/savecore/savecore.8 > savecore.8.gz ===> sbin/setkey (all) cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/setkey/setkey.c cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c /src/sbin/setkey/parse.y: In function `setkeymsg_add': /src/sbin/setkey/parse.y:1023: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/sbin/setkey/parse.y:1039: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/sbin/setkey. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-12 23:02:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-12 23:02:28 - ERROR: failed to build world TB --- 2005-10-12 23:02:28 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 08:05:58 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 278CB16A41F for ; Thu, 13 Oct 2005 08:05:58 +0000 (GMT) (envelope-from poopadoor@yahoo.com) Received: from web42001.mail.yahoo.com (web42001.mail.yahoo.com [66.218.93.169]) by mx1.FreeBSD.org (Postfix) with SMTP id CEFB743D45 for ; Thu, 13 Oct 2005 08:05:57 +0000 (GMT) (envelope-from poopadoor@yahoo.com) Received: (qmail 83560 invoked by uid 60001); 13 Oct 2005 08:05:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QQ0KjYjubhI5epn3ZXzmPTVHR2IST7RWr7j7sk82D8qq4KEdAxynY7Mb2EQ6ts5klvJhbgIkRcAzQ1FY5JmKwd98CBKhF2nbfcNj2lSD4jbH6cd9QSX04E9wwmQbodi5PIu8WPLF+dyyxbCP2O7CjGiK8hW2REYj47mNPP7f+IY= ; Message-ID: <20051013080557.83558.qmail@web42001.mail.yahoo.com> Received: from [60.240.227.208] by web42001.mail.yahoo.com via HTTP; Thu, 13 Oct 2005 01:05:57 PDT Date: Thu, 13 Oct 2005 01:05:57 -0700 (PDT) From: Ppop Door To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: hme problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 08:05:58 -0000 Greetings, We have an E250, trying to put 5.4R on it, and we get this: hme0: Ethernet address: 08:00:20:e7:16:88 hme0: couldn't establish interrupt Consequently, no hme0 device is available later on for ifconfig. Card and box were working fine as Solaris. Any help, solutions? __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 08:34:21 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 74EB316A41F for ; Thu, 13 Oct 2005 08:34:21 +0000 (GMT) (envelope-from james.gallagher@misys.com) Received: from rly09c.srv.mailcontrol.com (cluster-c.mailcontrol.com [168.143.177.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF9043D48 for ; Thu, 13 Oct 2005 08:34:20 +0000 (GMT) (envelope-from james.gallagher@misys.com) Received: from singex2.misys.com ([203.126.166.10]) by rly09c.srv.mailcontrol.com (MailControl) with ESMTP id j9D8YGNS011247; Thu, 13 Oct 2005 09:34:17 +0100 Received: by singex2.misys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Oct 2005 16:26:29 +0800 Message-ID: From: "Gallagher, James" To: "'Ppop Door'" , freebsd-sparc64@freebsd.org Date: Thu, 13 Oct 2005 16:26:29 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Scanned-By: MailControl A-05-40-00 (www.mailcontrol.com) on 10.67.0.119 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: hme problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 08:34:21 -0000 > -----Original Message----- > From: owner-freebsd-sparc64@freebsd.org > [mailto:owner-freebsd-sparc64@freebsd.org] On Behalf Of Ppop Door > Sent: Thursday, October 13, 2005 16:06 PM > To: freebsd-sparc64@freebsd.org > Subject: hme problems > > > Greetings, > > We have an E250, trying to put 5.4R on it, and we get > this: > hme0: Ethernet address: 08:00:20:e7:16:88 > hme0: couldn't establish interrupt > > Consequently, no hme0 device is available later on for ifconfig. > > Card and box were working fine as Solaris. > > Any help, solutions? > > Hi, No solution that I'm aware of - I asked this question also awhile back (http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-April/002973.html) also as I encountered the problem going from 5.3 to 5.4. I should have a look at it again and try to report the issue properly (once I dig around in the Handbook and figure out what that way is!) James From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 10:15:13 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 53BB716A41F for ; Thu, 13 Oct 2005 10:15:13 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B84043D48 for ; Thu, 13 Oct 2005 10:15:12 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id j9DAFA4K065812; Thu, 13 Oct 2005 12:15:10 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j9DAF525065811; Thu, 13 Oct 2005 12:15:05 +0200 (CEST) (envelope-from marius) Date: Thu, 13 Oct 2005 12:15:05 +0200 From: Marius Strobl To: "Gallagher, James" Message-ID: <20051013121505.A64371@newtrinity.zeist.de> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from james.gallagher@misys.com on Thu, Oct 13, 2005 at 04:26:29PM +0800 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.1-9; AVE: 6.32.0.8; VDF: 6.32.0.79; host: newtrinity.zeist.de) Cc: freebsd-sparc64@freebsd.org Subject: Re: hme problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 10:15:13 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 13, 2005 at 04:26:29PM +0800, Gallagher, James wrote: > > > > > -----Original Message----- > > From: owner-freebsd-sparc64@freebsd.org > > [mailto:owner-freebsd-sparc64@freebsd.org] On Behalf Of Ppop Door > > Sent: Thursday, October 13, 2005 16:06 PM > > To: freebsd-sparc64@freebsd.org > > Subject: hme problems > > > > > > Greetings, > > > > We have an E250, trying to put 5.4R on it, and we get > > this: > > hme0: Ethernet address: 08:00:20:e7:16:88 > > hme0: couldn't establish interrupt > > > > Consequently, no hme0 device is available later on for ifconfig. > > > > Card and box were working fine as Solaris. > > > > Any help, solutions? > > > > > Hi, > > No solution that I'm aware of - I asked this question also awhile back > (http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-April/002973.html) > also as I encountered the problem going from 5.3 to 5.4. I should have a > look at it again and try to report the issue properly (once I dig around in > the Handbook and figure out what that way is!) That's an old bug; the second NS16550 (used as mouse port) on E250 erroneously gets the IRQ of the on-board HME assigned. Later on this became fatal when uart(4) was enabled which began trying to use that NS16550. The attached patch (applies to HEAD and RELENG_6 but it should also be fine to just grab uart_bus_ebus.c from HEAD, apply the patch and stick it into a FreeBSD 5 system) should work around this by causing uart(4) to not attach to the NS16550 in question in favour of a working on-board HME. AFAICT the underlying problem is caused by a IRQ routing problem due to interpreting the information present in OFW wrong. This however can happen at a couple of layers (the exact code path is also model dependend) and I didn't manage to spot faulty code. Fixing it would require me to have at least remote access to an E250 which so far I didn't manage to get. Also currently I'm short on spare time... Marius -- This mail was scanned by AntiVir Milter. This product is licensed for non-commercial use. See www.antivir.de for details. --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uart_bus_ebus.c.diff" Index: uart_bus_ebus.c =================================================================== RCS file: /mnt/futile/usr/data/bsd/cvs/fbsd/src/sys/dev/uart/uart_bus_ebus.c,v retrieving revision 1.7 diff -u -r1.7 uart_bus_ebus.c --- uart_bus_ebus.c 7 Aug 2005 13:37:25 -0000 1.7 +++ uart_bus_ebus.c 13 Oct 2005 09:47:05 -0000 @@ -93,6 +93,21 @@ device_disable(dev); return (ENXIO); } + /* + * XXX Hack + * On E250 the IRQ of the on-board HME gets erroneously + * also assigned to the second NS16550 due to interrupt + * routing problems at some layer. As uart(4) uses a + * INTR_FAST handler while hme(4) doesn't the IRQ can't + * be actually "shared" causing hme(4) to not attach to + * the on-board HME. Prefer the on-board HME at the + * expense of the mouse port for now. + */ + if (!strcmp(sparc64_model, "SUNW,Ultra-250") && + device_get_unit(dev) % 2 == 1) { + device_disable(dev); + return (ENXIO); + } sc->sc_class = &uart_ns8250_class; return (uart_bus_probe(dev, 0, 0, 0, 0)); } --J/dobhs11T7y2rNN-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 14 01:37:38 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 94CA916A41F for ; Fri, 14 Oct 2005 01:37:38 +0000 (GMT) (envelope-from james.gallagher@misys.com) Received: from rly13a.srv.mailcontrol.com (cluster-a.mailcontrol.com [80.69.8.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB00343D48 for ; Fri, 14 Oct 2005 01:37:37 +0000 (GMT) (envelope-from james.gallagher@misys.com) Received: from singex2.misys.com ([203.126.166.10]) by rly13a.srv.mailcontrol.com (MailControl) with ESMTP id j9E1bTo3024189; Fri, 14 Oct 2005 02:37:30 +0100 Received: by singex2.misys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 09:29:39 +0800 Message-ID: From: "Gallagher, James" To: "'Marius Strobl'" Date: Fri, 14 Oct 2005 09:29:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Scanned-By: MailControl A-05-40-00 (www.mailcontrol.com) on 10.65.0.123 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sparc64@freebsd.org Subject: RE: hme problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 01:37:38 -0000 > -----Original Message----- > From: Marius Strobl [mailto:marius@alchemy.franken.de] > Sent: Thursday, October 13, 2005 18:15 PM > To: Gallagher, James > Cc: 'Ppop Door'; freebsd-sparc64@freebsd.org > Subject: Re: hme problems > > > On Thu, Oct 13, 2005 at 04:26:29PM +0800, Gallagher, James wrote: > > > > > > > > > -----Original Message----- > > > From: owner-freebsd-sparc64@freebsd.org > > > [mailto:owner-freebsd-sparc64@freebsd.org] On Behalf Of Ppop Door > > > Sent: Thursday, October 13, 2005 16:06 PM > > > To: freebsd-sparc64@freebsd.org > > > Subject: hme problems > > > > > > > > > Greetings, > > > > > > We have an E250, trying to put 5.4R on it, and we get > > > this: > > > hme0: Ethernet address: 08:00:20:e7:16:88 > > > hme0: couldn't establish interrupt > > > > > > Consequently, no hme0 device is available later on for ifconfig. > > > > > > Card and box were working fine as Solaris. > > > > > > Any help, solutions? > > > > > > > > Hi, > > > > No solution that I'm aware of - I asked this question also > awhile back > > > (http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-April/002973. > > html) > > also as I encountered the problem going from 5.3 to 5.4. I > should have a > > look at it again and try to report the issue properly (once > I dig around in > > the Handbook and figure out what that way is!) > > That's an old bug; the second NS16550 (used as mouse port) on > E250 erroneously gets the IRQ of the on-board HME assigned. > Later on this became fatal when uart(4) was enabled which > began trying to use that NS16550. The attached patch (applies > to HEAD and RELENG_6 but it should also be fine to just grab > uart_bus_ebus.c from HEAD, apply the patch and stick it into > a FreeBSD 5 system) should work around this by causing > uart(4) to not attach to the NS16550 in question in favour of > a working on-board HME. AFAICT the underlying problem is > caused by a IRQ routing problem due to interpreting the > information present in OFW wrong. This however can happen at > a couple of layers (the exact code path is also model > dependend) and I didn't manage to spot faulty code. Fixing it > would require me to have at least remote access to an E250 > which so far I didn't manage to get. Also currently I'm short > on spare time... > > Marius > > Thanks Marius, I'll look at getting this patch on and see how I go. Sadly I can't offer any access to the E250s we have here as they're not permanently connected to the internet (only for updates). Regards, James From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 14 13:42:53 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org 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 1D09F16A41F for ; Fri, 14 Oct 2005 13:42:53 +0000 (GMT) (envelope-from poopadoor@yahoo.com) Received: from web42008.mail.yahoo.com (web42008.mail.yahoo.com [66.218.93.176]) by mx1.FreeBSD.org (Postfix) with SMTP id C796643D45 for ; Fri, 14 Oct 2005 13:42:52 +0000 (GMT) (envelope-from poopadoor@yahoo.com) Received: (qmail 35356 invoked by uid 60001); 14 Oct 2005 13:42:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WxDyB7Yj1OFn5M5wvotOQfygswrLRD7tpD352C8aDM5zQSwNCh6O/gWlCS/Tj9KpWz3w4iVFT3RZMcW4JcJtd4EqpodVJIDW3gK+EUsgkDkFVOLGmsPoPhhtIJdHsQgaW3AiJm25Tp6qWNpp4VQIUWSdlNk6f8S+UrbW+FMXDgg= ; Message-ID: <20051014134252.35354.qmail@web42008.mail.yahoo.com> Received: from [60.240.167.119] by web42008.mail.yahoo.com via HTTP; Fri, 14 Oct 2005 06:42:52 PDT Date: Fri, 14 Oct 2005 06:42:52 -0700 (PDT) From: Ppop Door To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: hme problems - resolved X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 13:42:53 -0000 Hi all, Thanks to Marius for his patch - it worked like a charm on 5.4 and 6 __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 14 20:36:25 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org 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 6514A16A41F for ; Fri, 14 Oct 2005 20:36:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F2443D53 for ; Fri, 14 Oct 2005 20:36:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 11FA61A3C19 for ; Fri, 14 Oct 2005 13:36:25 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6D92C511FE; Fri, 14 Oct 2005 16:36:24 -0400 (EDT) Date: Fri, 14 Oct 2005 16:36:24 -0400 From: Kris Kennaway To: sparc64@FreeBSD.org Message-ID: <20051014203624.GA36662@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: >12GB RAM now usable X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 20:36:25 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With this and my previous commit you should be able to boot 7.0 on systems with more than 12GB of RAM. Under 5.x you can do this by setting the kern.maxbcache tunable to 400*1024*1024, but this tunable was broken under 6.0 (fixed in my previous commit). With the below commit you no longer need the tunable. I'm hoping to get this MFCed into 6.0-R. Kris ----- Forwarded message from Kris Kennaway ----- X-Original-To: kkenn@localhost Delivered-To: kkenn@localhost.obsecurity.org X-Original-To: kris Delivered-To: kris@FreeBSD.ORG X-Original-To: src-committers@FreeBSD.org Delivered-To: src-committers@FreeBSD.org From: Kris Kennaway Date: Fri, 14 Oct 2005 20:31:12 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sparc64/include param.h X-FreeBSD-CVS-Branch: HEAD Precedence: bulk X-Loop: FreeBSD.ORG X-UIDL: &k)#!0V&!!S;'#!d%%!! X-Bogosity: Ham, tests=3Dbogofilter, spamicity=3D0.000000, version=3D0.96.0 kris 2005-10-14 20:31:12 UTC FreeBSD src repository Modified files: sys/sparc64/include param.h=20 Log: Add a default value for VM_BCACHE_SIZE_MAX of 400MB. This is copied from amd64, and is a factor of 3 less than the value previously auto-sized on a 12GB machine, which would cause an overflow in calculations involving t= he maxbcache int, causing bufinit() to loop forever at boot. =20 Reviewed by: mlaier, peter =20 Revision Changes Path 1.20 +8 -0 src/sys/sparc64/include/param.h http://cvsweb.FreeBSD.org/src/sys/sparc64/include/param.h.diff?r1=3D1.19&r2= =3D1.20 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/include/param.h,v | retrieving revision 1.19 | retrieving revision 1.20 | diff -u -p -r1.19 -r1.20 | --- src/sys/sparc64/include/param.h 2004/11/20 02:29:50 1.19 | +++ src/sys/sparc64/include/param.h 2005/10/14 20:31:12 1.20 | @@ -27,7 +27,7 @@ | * SUCH DAMAGE. | * | * from: @(#)param.h 5.8 (Berkeley) 6/28/91 | - * $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/include/para= m.h,v 1.19 2004/11/20 02:29:50 das Exp $ | + * $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/include/para= m.h,v 1.20 2005/10/14 20:31:12 kris Exp $ | */ | =20 | /* | @@ -110,6 +110,14 @@ | #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ | #define PCPU_PAGES 1 | =20 | +/* | + * Ceiling on size of buffer cache (really only effects write queueing, | + * the VM page cache is not effected), can be changed via | + * the kern.maxbcache /boot/loader.conf variable. | + */ | +#ifndef VM_BCACHE_SIZE_MAX | +#define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) | +#endif | =20 | /* | * Mach derived conversion macros ----- End forwarded message ----- --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDUBbDWry0BWjoQKURAjI7AJ0S0CzT+F288Mai8pRzYi1S8cFhaACfZm8l /bCfnIHSXrEELFx6c86wuoY= =GqSa -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 14 22:30:09 2005 Return-Path: X-Original-To: sparc64@freebsd.org 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 3408216A41F; Fri, 14 Oct 2005 22:30:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B778543D45; Fri, 14 Oct 2005 22:30:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EMU79T059416; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EMU7tE026440; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 718BD7302F; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051014223007.718BD7302F@freebsd-current.sentex.ca> Date: Fri, 14 Oct 2005 18:30:07 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 22:30:09 -0000 TB --- 2005-10-14 21:12:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-14 21:12:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-10-14 21:12:13 - cleaning the object tree TB --- 2005-10-14 21:12:37 - checking out the source tree TB --- 2005-10-14 21:12:37 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-10-14 21:12:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-14 21:19:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-14 21:19:55 - cd /src TB --- 2005-10-14 21:19:55 - /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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-10-14 22:24:14 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 22:24:14 - cd /src TB --- 2005-10-14 22:24:14 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 14 22:24:14 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/support.S cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/sys_machdep.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/tick.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/tlb.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/trap.c /src/sys/sparc64/sparc64/trap.c: In function `trap': /src/sys/sparc64/sparc64/trap.c:292: error: structure has no member named `ksi_trap' *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-14 22:30:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-14 22:30:07 - ERROR: failed to build generic kernel TB --- 2005-10-14 22:30:07 - tinderbox aborted