From owner-freebsd-sparc Sun Jan 12 0:26:49 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA9A637B401; Sun, 12 Jan 2003 00:26:47 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B94243F18; Sun, 12 Jan 2003 00:26:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0C8POH17473; Sun, 12 Jan 2003 00:25:24 -0800 (PST) Received: from pool0159.cvx22-bradley.dialup.earthlink.net ([209.179.198.159] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XdQS-0006dC-00; Sun, 12 Jan 2003 00:25:01 -0800 Message-ID: <3E21260E.CF088513@mindspring.com> Date: Sun, 12 Jan 2003 00:23:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Kris Kennaway , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112165423.K5527-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4411abf1b3574f4005d4d48b8b0b44a0f666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > > Is this an omission, or are the ports wrong? > > First answer: > This is a bug in the ports. The non-i386 arches are apparently including > instead of the documented interface . Wow, gotta disagree with that; the problem doesn't magically go away when you include the standard header file. > I think the ports are only meddling the FP mask to hide their FP errors > when running under FreeBSD-3.x and earlier anyway. They are meddling with it because the FreeBSD default, while it is permitted by the standard, is different from what most software expects the default to be. Yeah, it'd be nice if it weren't there, but the man page itself specifically uses fpsetmask() in an example (to prevent some trap). > Second answer: > Ports should use the C99 interfaces fe{get,set}*() from , and then > only if C99 is supported. There might be problems with this too: > - C99 isn't supported yet. > - C99 doesn't have fesetmask(). This is partly because it would be > very unportable. It is not an IEEE FP feature. C99 only has > fesetenv(FE_DFL_ENV) to recover from any meddling with the FP > environment. > - Non-default FP environments should only be used in small sections > of code, since large parts of libraries, etc. are entitled to assume > that the environment is the default. So changing the FP mask to a > non-default value at program startup time would give undefined > behaviour if it were possible. This is also really arguable, IMO. The problem with this is that the assumption that they are "entitled to assume that the environment is the default" is really bogus. What this really comes down to is that Intel FP hardware sucks, and should be redesigned to raise exceptions when they occur, instead of on the next operation. It's like the old VT100's, or other therminals with the "AM" attribute which is true, and they wrap before the 81st character, rather than after the 80th. I understand the pipeline stall that would happen on an exception, if this is how they were handed; on the other hand, it's a little bogus to assume that exceptions aren't going to be rare, what with them being "exceptional" and all. 8-). The C99 soapbox is a nice place to stand, if you want to criticize all other implementations; but as you point out, C99 is not really there yet, and even if it were, you could not really expect all code to be changed to conform to it (or any other standard, for that matter, considering the amount of legacy code everywhere). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 0:28:53 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD43A37B401; Sun, 12 Jan 2003 00:28:52 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0032B43E4A; Sun, 12 Jan 2003 00:28:51 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0C8T8jb003508; Sun, 12 Jan 2003 03:29:08 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0C8T8Og003507; Sun, 12 Jan 2003 03:29:08 -0500 (EST) Date: Sun, 12 Jan 2003 03:29:08 -0500 From: Jake Burkholder To: Terry Lambert Cc: Kris Kennaway , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 Message-ID: <20030112032908.H212@locore.ca> References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E212670.41627B9F@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 12, 2003 at 12:25:20AM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Jan 12, 2003 at 12:25:20AM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > Is this an omission, or are the ports wrong? > > > > FWIW, the alpha headers are basically identical to the sparc64 ones. > > There may be missing ifdefs in the ports or the makefiles. > > Isn't that really a lame excuse? Shouldn't > > #ifdef __FreeBSD__ > > be enough to make code compile on all FreeBSD platforms? I don't know, why don't you try it. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 0:33:38 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34AF637B401; Sun, 12 Jan 2003 00:33:37 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 957AD43F6B; Sun, 12 Jan 2003 00:33:36 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0C8L7H16288; Sun, 12 Jan 2003 00:21:07 -0800 (PST) Received: from pool0159.cvx22-bradley.dialup.earthlink.net ([209.179.198.159] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XdGt-0006B9-00; Sun, 12 Jan 2003 00:15:07 -0800 Message-ID: <3E2123B9.A0DBD29@mindspring.com> Date: Sun, 12 Jan 2003 00:13:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112044720.GA16393@rot13.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4411abf1b3574f40049d530a3bc01e929667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kris Kennaway wrote: > Here's another FP-related failure: > > http://bento.freebsd.org/errorlogs/sparc64-5-latest/xaos-3.0.log > > FP_X_DNML is defined on i386 in /usr/include/machine/ieeefp.h, but not > on sparc64. Use of this manifest value requires a feature test. This is a bug in the ported software (IMO). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 0:50:15 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7225F37B401; Sun, 12 Jan 2003 00:50:14 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id E978543F1E; Sun, 12 Jan 2003 00:50:13 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by flavatown.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0C8R6V13232; Sun, 12 Jan 2003 00:27:06 -0800 (PST) Received: from pool0159.cvx22-bradley.dialup.earthlink.net ([209.179.198.159] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XdS2-0006iZ-00; Sun, 12 Jan 2003 00:26:38 -0800 Message-ID: <3E212670.41627B9F@mindspring.com> Date: Sun, 12 Jan 2003 00:25:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder Cc: Kris Kennaway , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42dc34cdb8a5af5854dc38e49ef75bcff667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jake Burkholder wrote: > > Is this an omission, or are the ports wrong? > > FWIW, the alpha headers are basically identical to the sparc64 ones. > There may be missing ifdefs in the ports or the makefiles. Isn't that really a lame excuse? Shouldn't #ifdef __FreeBSD__ be enough to make code compile on all FreeBSD platforms? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 1:27:18 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC3237B401; Sun, 12 Jan 2003 01:27:14 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9AB43F1E; Sun, 12 Jan 2003 01:27:13 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA23195; Sun, 12 Jan 2003 20:23:48 +1100 Date: Sun, 12 Jan 2003 20:24:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Kris Kennaway , , Subject: Re: fpsetmask on sparc64 In-Reply-To: <3E21260E.CF088513@mindspring.com> Message-ID: <20030112194827.S6039-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 12 Jan 2003, Terry Lambert wrote: > Bruce Evans wrote: > > > Is this an omission, or are the ports wrong? > > > > First answer: > > This is a bug in the ports. The non-i386 arches are apparently including > > instead of the documented interface . > > Wow, gotta disagree with that; the problem doesn't magically go > away when you include the standard header file. Yes it does (should). Including an implementation detail like gives undefined behaviour. In this case, one aspect of the undefined behaviour is that fpsetmask() is not declared in the MD file except in the i386 case as a side effect of being implemented as a macro that calls an inline function there. In all the other arches, it is an extern function that is only declared in . > > I think the ports are only meddling the FP mask to hide their FP errors > > when running under FreeBSD-3.x and earlier anyway. > > They are meddling with it because the FreeBSD default, while it is ^^ iswas (1) > permitted by the standard, is different from what most software was (2) > expects the default to be. (1) was permitted by C90; is not permitted by C99, but C99 is not supported yet. (2) was different before FreeBSD-4.0. Are there any ports that still support FreeBSD-3? > Yeah, it'd be nice if it weren't there, but the man page itself > specifically uses fpsetmask() in an example (to prevent some trap). The man page still supports FreeBSD-3 :-). It is version-agnostic. The default setting is very MD, so software that actually cares must not assume anything about the defaults. > > [... in C99] > > - Non-default FP environments should only be used in small sections > > of code, since large parts of libraries, etc. are entitled to assume > > that the environment is the default. So changing the FP mask to a > > non-default value at program startup time would give undefined > > behaviour if it were possible. > > This is also really arguable, IMO. The problem with this is that > the assumption that they are "entitled to assume that the environment > is the default" is really bogus. Anything else would be very expensive both in source code complexity and runtime costs. The environment would have to be switched for every library function that uses FP. C99 only requires a few specialized math functions to be aware of this. > What this really comes down to is that Intel FP hardware sucks, > and should be redesigned to raise exceptions when they occur, > instead of on the next operation. It's like the old VT100's, or This is not suckagae, but a normal consequence of pipelining. Intel hardware is relatively nice here. It gives precise exceptions on the next operation. Less-unmodern hardware like alphas has very imprecise exceptions unless everything is pessimized using trap barriers. See -mtrap-precision in gcc.info. But exceptions are now almost moot on i386's since they don't cause traps. However, at least some alphas need to cause traps to be IEEE conformant since traps are needed to implement some parts of IEEE conformance in software, and the largest of the -mtrap-precision pessimizations are needed for this to work. See -mieee-conformant in gcc.info. > I understand the pipeline stall that would happen on an exception, > if this is how they were handed; on the other hand, it's a little > bogus to assume that exceptions aren't going to be rare, what with > them being "exceptional" and all. 8-). As far as I understand the hardware issues (not far), the stall would be necessary after every FP instruction, not just ones which generate the exception. FP performance would be reduced by approximately a factor of (pipeline_length * number_of_concurrent_FP_ops_achieved). I guess speculative execution code get near appearing to not stall though. > The C99 soapbox is a nice place to stand, if you want to criticize > all other implementations; but as you point out, C99 is not really > there yet, and even if it were, you could not really expect all > code to be changed to conform to it (or any other standard, for > that matter, considering the amount of legacy code everywhere). True. It just gives applications a chance of handling environment- related FP stuff almost portably. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 5:15:29 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C525937B401; Sun, 12 Jan 2003 05:15:27 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D19643ED8; Sun, 12 Jan 2003 05:15:27 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by flavatown.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0CDDIV20804; Sun, 12 Jan 2003 05:13:18 -0800 (PST) Received: from pool0007.cvx40-bradley.dialup.earthlink.net ([216.244.42.7] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XhtG-0005i5-00; Sun, 12 Jan 2003 05:11:03 -0800 Message-ID: <3E216911.B7AFC39F@mindspring.com> Date: Sun, 12 Jan 2003 05:09:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder Cc: Kris Kennaway , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a40a48f0fa5fef75ae6ad82fb2b305d3873ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jake Burkholder wrote: > > Isn't that really a lame excuse? Shouldn't > > > > #ifdef __FreeBSD__ > > > > be enough to make code compile on all FreeBSD platforms? > > I don't know, why don't you try it. I understand the snide reply. My point was that if FreeBSD had platform differences, it should hide them from user space applications: if it's going to be as hard to port to FreeBSD-alpha from FreeBSD-i386, then you might as well spend your time on a higher margin platform. Apparently, Solaris supports fpsetmask(3C) in SVR4 derived Solaris on SPARC, which means that this is not an Intel-specific feature, and therefore it's not possible to justify it being an Intel-specific feature in FreeBSD. In the absolute worst case, it should be stubbed out, and complain, on SPARC and Alpha, if it isn't made to work. Solaris man page: http://www.FreeBSD.org/cgi/man.cgi?query=fpsetmask&apropos=0&sektion=0&manpath=SunOS+5.8&format=html -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 5:45:27 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F69837B401; Sun, 12 Jan 2003 05:45:17 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC96443ED8; Sun, 12 Jan 2003 05:45:16 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0007.cvx40-bradley.dialup.earthlink.net ([216.244.42.7] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XiQG-0001mm-00; Sun, 12 Jan 2003 05:45:09 -0800 Message-ID: <3E217111.B3C4C512@mindspring.com> Date: Sun, 12 Jan 2003 05:43:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Kris Kennaway , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112194827.S6039-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a421d9b60736c7560686df84dbea9b5d3f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > On Sun, 12 Jan 2003, Terry Lambert wrote: > > Bruce Evans wrote: > > > > Is this an omission, or are the ports wrong? > > > > > > First answer: > > > This is a bug in the ports. The non-i386 arches are apparently including > > > instead of the documented interface . > > > > Wow, gotta disagree with that; the problem doesn't magically go > > away when you include the standard header file. > > Yes it does (should). We're at cross-purposes here, I think. It doesn't go away, even if it should; here's ieeefp.h: #ifndef _IEEEFP_H_ #define _IEEEFP_H_ #include #include #ifdef __i386__ #include #else /* !__i386__ */ __BEGIN_DECLS extern fp_rnd_t fpgetround(void); extern fp_rnd_t fpsetround(fp_rnd_t); extern fp_except_t fpgetmask(void); extern fp_except_t fpsetmask(fp_except_t); extern fp_except_t fpgetsticky(void); extern fp_except_t fpsetsticky(fp_except_t); __END_DECLS #endif /* __i386__ */ #endif /* _IEEEFP_H_ */ The function will still be missing from the library, even if there's a valid prototype in scope, because you included the header file, and didn't get any of the manifests. To get the manifests, you have to include the , seperately. Notice that the only real difference is whether or not the operations end up using an inline version of the functions, or expect one to be in the library. That's a library bug, that they would not be implemented on SPARC. The second problem where the manifest wasn't defined is a real problem in the ported code; technically, they are required to feature test before using the manifest constant. > Including an implementation detail like > gives undefined behaviour. In this case, > one aspect of the undefined behaviour is that fpsetmask() is not > declared in the MD file except in the i386 case as a side effect > of being implemented as a macro that calls an inline function there. > In all the other arches, it is an extern function that is only > declared in . The problem was not one of a prototype not being in scope, which is basically a stupid pseudo-compiler error that came from not mandating that that crap get handled at link-time (which is very easy to do, if you are willing to break legacy object compatability, just like symbol decoration can go away). > > > I think the ports are only meddling the FP mask to hide their FP errors > > > when running under FreeBSD-3.x and earlier anyway. > > > > They are meddling with it because the FreeBSD default, while it is > ^^ iswas (1) > > permitted by the standard, is different from what most software > was (2) > > expects the default to be. > > (1) was permitted by C90; is not permitted by C99, but C99 is not supported > yet. So it's irrelevent, right? > (2) was different before FreeBSD-4.0. Are there any ports that still > support FreeBSD-3? Not this software, certainly... making it also irrelevent, right? > > Yeah, it'd be nice if it weren't there, but the man page itself > > specifically uses fpsetmask() in an example (to prevent some trap). > > The man page still supports FreeBSD-3 :-). It is version-agnostic. The > default setting is very MD, so software that actually cares must not > assume anything about the defaults. Exactly. And therfore must call the function to set the FPU into a known state, with regatd to exception handling, etc.. Which makes my case, there. > Anything else would be very expensive both in source code complexity > and runtime costs. A push/pop paradigm could do this without any real cost, actually; when you add threading, things get complicated, but since you are screwing with signal masks before and after threaded calls, to get around the fact that the BSD default of system call restart has been removed in favor of the System V default of system call non-restart, following a signal, you have an amplification factor of 3 on system call overhead anyway, so additional overhead for threads is basically totally lost in the noise of all that *other* overhead you get, just from using threads in the first place. > The environment would have to be switched for every > library function that uses FP. C99 only requires a few specialized > math functions to be aware of this. Everyone who uses FP has to do it anyway: if they want consistent results, and the FP doesn't start in a preferred state, then the answer is that you *always* have to save and restore the state. You could get around this a little, by doing two things: 1) Cache the current state in a user space global, so that the code involved can decide to not do the save/restore, if it's already in the preferred state. 2) FreeBSD could quit being so contrarian, and adopt the same default state that Linux, Solaris, and SCO use, which is, now, for programmers, the preferred state. > > What this really comes down to is that Intel FP hardware sucks, > > and should be redesigned to raise exceptions when they occur, > > instead of on the next operation. It's like the old VT100's, or > > This is not suckagae, but a normal consequence of pipelining. Intel > hardware is relatively nice here. It gives precise exceptions on the > next operation. Less-unmodern hardware like alphas has very imprecise > exceptions unless everything is pessimized using trap barriers. See > -mtrap-precision in gcc.info. But exceptions are now almost moot on > i386's since they don't cause traps. However, at least some alphas > need to cause traps to be IEEE conformant since traps are needed to > implement some parts of IEEE conformance in software, and the largest > of the -mtrap-precision pessimizations are needed for this to work. > See -mieee-conformant in gcc.info. The preferred state of the hardware for most programmers is "no exceptions by default" anyway. FeeBSD tried to be more precise, and makes programmers go out of their way to get the same imprecision and behaviour that they expect, because of their code being written for other platforms. It's not like FreeBSD is the reference platform for much software, so it's not like this is really a moral high ground, here. In any case, trap barriers are not really necessary; implying a barrier when an exception is raised is enough. As long as you don't hit an exceptional condition, you are free to pipeline, and, given that exceptional conditions are, well, "exceptional", and therefore don't happen very often, it's not like you'd be giving up speed in the common case. In the barrier case, you are running a trap handler, anyway (at least, FreeBSD assumes you will be). Add to this the MMX, bcopy, and other abuse of the FP registers, and you've got a lot of good reasons to trap on the event. 8-(. > > I understand the pipeline stall that would happen on an exception, > > if this is how they were handed; on the other hand, it's a little > > bogus to assume that exceptions aren't going to be rare, what with > > them being "exceptional" and all. 8-). > > As far as I understand the hardware issues (not far), the stall would > be necessary after every FP instruction, not just ones which generate > the exception. FP performance would be reduced by approximately a > factor of (pipeline_length * number_of_concurrent_FP_ops_achieved). > I guess speculative execution code get near appearing to not stall > though. I keep getting this rationale, but it doesn't really fly for me. If you are going to raise an exception, you are going to lose the speculative execution that was done on the basis of the idea that you were not going to get an exception. I'm half inclined to say that FP state should be saved and restored on context switches of a process, after it has once used FP, and get rid of all this special crap that comes from trying to lazy-bind FPU context switching. The worst case for this will be the worst case in any case; in the best case, you will save context, and then decide that it's still present, so it doesn't need to be restored. That's an overhead that I think is livable, since it assumes a loaded system in the first place, context switching away from the FP-using process, because there's other stuff that wants to run. > > The C99 soapbox is a nice place to stand, if you want to criticize > > all other implementations; but as you point out, C99 is not really > > there yet, and even if it were, you could not really expect all > > code to be changed to conform to it (or any other standard, for > > that matter, considering the amount of legacy code everywhere). > > True. It just gives applications a chance of handling environment- > related FP stuff almost portably. I'm willing to cross that bridge when someone fully implements C99 compliance, and ignore it, until then. It's not really useful to drive by some place that under construction for 4 years now, and every day sigh about not being able to use the parking garage, or complain about the places you can park to get where you need to go today (IMO). More than 4 years, if you consider that it was possible to start implementation when C99 was still draft. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 7:12:52 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2830137B401 for ; Sun, 12 Jan 2003 07:12:50 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id C633043F1E for ; Sun, 12 Jan 2003 07:12:48 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0CFCfb09536; Sun, 12 Jan 2003 16:12:41 +0100 From: "Roderick van Domburg" To: "Thomas Moestl" Cc: Subject: RE: panic: trap: fast data access mmu miss Date: Sun, 12 Jan 2003 16:13:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030112010950.GA56998@crow.dom2ip.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Running on a Sun Enterprise 250 with a single UltraSparc-II > > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had > > this same problem with sources over the past few (three?) days. > > I had to copy this dmesg by hand, so please bear with any > > possible typos. > > Please try the attached diff. The crash was due to what I consider a > driver bug (not checking the error in the bus_dmamap_load() callback), > however due to the FreeBSD busdma API being largely undocumented it is > a bit difficult to tell what should be considered legal. Much more > problematic is to assume that the first segment's bus address will be > 0 in the error case. This is not currently guaranteed by any > implementation. > > The attached patch fixes that, and also passes a valid pointer to the > callback for maximum compatability. It also fixes some other bugs I > came across. > > This does however still not address the reason for the > bus_dmamap_load() failure; I'm not really sure why this does > happen. Please look for messages like: > __sym_calloc2: failed to allocate ... > and tell me if you see any of them. Thanks for the patches! Unfortunately however, it still doesn't seem to attach sym1 quite right, I believe. Your patches did make the booting process advance further, but the kernel failed to mount root. Here is the dmesg, once again manually copied. That __sym_calloc2 message is right on the second line. If it is of any help, the kernel builds from sources mid-December 2002 worked just fine. sym1: No NVRAM, ID 7, Fast-20, SE, parity checking __sym_calloc2: failed to allocate SCRIPTB0[1308] device_probe_and_attach: sym1 attach returned 6 pcib2: on nexus0 pcib2: Psycho, impl 0, version 4, ign 0x7c0 pci2: on pcib2 pci2: at device 1.0 (no driver attached) nexus0: , type system-service-processor (no driver attached) nexus0: , type memory-controller (no driver attached) Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: [cut] mountroot> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 10:49:31 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BC1237B401; Sun, 12 Jan 2003 10:49:30 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 707ED43F1E; Sun, 12 Jan 2003 10:49:29 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0CInmjb005102; Sun, 12 Jan 2003 13:49:48 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0CInmCW005101; Sun, 12 Jan 2003 13:49:48 -0500 (EST) Date: Sun, 12 Jan 2003 13:49:48 -0500 From: Jake Burkholder To: Terry Lambert Cc: sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 Message-ID: <20030112134948.I212@locore.ca> References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E216911.B7AFC39F@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 12, 2003 at 05:09:37AM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Jan 12, 2003 at 05:09:37AM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > Isn't that really a lame excuse? Shouldn't > > > > > > #ifdef __FreeBSD__ > > > > > > be enough to make code compile on all FreeBSD platforms? > > > > I don't know, why don't you try it. > > I understand the snide reply. My point was that if FreeBSD had My point is that you could help by actually doing something. Your repeated long emails DO NOT HELP. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 11:30:33 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B36DE37B401 for ; Sun, 12 Jan 2003 11:30:32 -0800 (PST) Received: from libra.cs.put.poznan.pl (libra.cs.put.poznan.pl [150.254.30.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A66643ED8 for ; Sun, 12 Jan 2003 11:30:24 -0800 (PST) (envelope-from piotr.wozniak@cs.put.poznan.pl) Received: from libra.cs.put.poznan.pl (localhost [127.0.0.1]) by libra (Postfix on VMS) with SMTP id E289C55A for ; Sun, 12 Jan 2003 20:30:22 +0100 (CET) Received: from dcs-pw (dcs-pw.cs.put.poznan.pl [150.254.31.188]) by libra.cs.put.poznan.pl (Postfix on VMS) with ESMTP id C3CFC39 for ; Sun, 12 Jan 2003 20:30:22 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed To: freebsd-sparc@FreeBSD.ORG Subject: compiling postgresql7 failed From: =?iso-8859-2?B?UGlvdHIgV2+8bmlhaw==?= Organization: PUT Date: Sun, 12 Jan 2003 20:30:23 +0100 Message-ID: User-Agent: Opera M2 7.0 build 2349 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I can't compile Postgresql7... (5.0-RC2, sparc64, gcc version 3.2.1) Is there any way to avoid such errors? Should I modify C++ code?? ---------------------------------------- cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations - I../../../../src/include -I/usr/local/include -c -o xid.o xid.c cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations - I../../../../src/include -I/usr/local/include -c -o xlog.o xlog.c In file included from ../../../../src/include/storage/spin.h:50, from xlog.c:41: ../../../../src/include/storage/s_lock.h:184: syntax error before '*' token ../../../../src/include/storage/s_lock.h:185: warning: return type defaults to `int' ../../../../src/include/storage/s_lock.h:185: warning: no previous prototype for `tas' ---------------------------------------- Piotr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 11:53:56 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B4C037B401 for ; Sun, 12 Jan 2003 11:53:55 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F6943E4A for ; Sun, 12 Jan 2003 11:53:50 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0CJrgb14826; Sun, 12 Jan 2003 20:53:42 +0100 From: "Roderick van Domburg" To: "Piotr WoYniak" , Subject: RE: compiling postgresql7 failed Date: Sun, 12 Jan 2003 20:54:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I can't compile Postgresql7... (5.0-RC2, sparc64, gcc version 3.2.1) > Is there any way to avoid such errors? Should I modify C++ code?? You need to upgrade your ports collection. This issue has been fixed several weeks ago. Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 12:44:47 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F0CD37B401 for ; Sun, 12 Jan 2003 12:44:46 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C59A43E4A for ; Sun, 12 Jan 2003 12:44:45 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0CKiiu4087221 for ; Sun, 12 Jan 2003 12:44:44 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 12 Jan 2003 12:44:44 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: sparc@freebsd.org Subject: Question about odd stack pointer values on sparc64 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Still working on getting Modula-3 going on Sparc64. I think I'm getting close ... In GDB I notice that the stack pointer and frame pointer are often (always?) odd numbers, e.g.: (gdb) p/x $sp $1 = 0x7fdffffdec1 (gdb) p/x $fp $2 = 0x7fdffffdfb1 What is the reason for that? Are the low-order bits simply ignored? Surely the stack is more aligned than that. I'm pretty sure this is confusing the M3 garbage collector. It just might be the proverbial Last Bug. :-) Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 12:51:42 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4170537B401; Sun, 12 Jan 2003 12:51:39 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8FBE43ED8; Sun, 12 Jan 2003 12:51:37 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA25022; Mon, 13 Jan 2003 07:48:23 +1100 Date: Mon, 13 Jan 2003 07:48:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Kris Kennaway , , Subject: Re: fpsetmask on sparc64 In-Reply-To: <3E217111.B3C4C512@mindspring.com> Message-ID: <20030113072350.R8829-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 12 Jan 2003, Terry Lambert wrote: > Bruce Evans wrote: > > On Sun, 12 Jan 2003, Terry Lambert wrote: > > > Bruce Evans wrote: > > > > > Is this an omission, or are the ports wrong? > > > > > > > > First answer: > > > > This is a bug in the ports. The non-i386 arches are apparently including > > > > instead of the documented interface . > > > > > > Wow, gotta disagree with that; the problem doesn't magically go > > > away when you include the standard header file. > > > > Yes it does (should). > > We're at cross-purposes here, I think. It doesn't go away, even if > it should; here's ieeefp.h: > > #ifndef _IEEEFP_H_ > #define _IEEEFP_H_ > > #include > #include ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here are the manifests (sic). > > #ifdef __i386__ > #include ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is i386-specific code (which happens to be the implementation of the functions as inlines). > #else /* !__i386__ */ > __BEGIN_DECLS > extern fp_rnd_t fpgetround(void); > extern fp_rnd_t fpsetround(fp_rnd_t); > extern fp_except_t fpgetmask(void); > extern fp_except_t fpsetmask(fp_except_t); > extern fp_except_t fpgetsticky(void); > extern fp_except_t fpsetsticky(fp_except_t); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here are the declarations of the functions. These are used by the arches that don't implement them as inlines (which happen to be all non-i386 arches). Here are also some style bugs (extern, and no tabs). > __END_DECLS > #endif /* __i386__ */ > > #endif /* _IEEEFP_H_ */ > > The function will still be missing from the library, even if there's > a valid prototype in scope, because you included the header file, and > didn't get any of the manifests. To get the manifests, you have to > include the , seperately. The functions are not shown above. They are normal functions in libc for most arches. > Notice that the only real difference is whether or not the > operations end up using an inline version of the functions, or > expect one to be in the library. > > That's a library bug, that they would not be implemented on SPARC. They aren't implemented as inline functions on sparc64's, so no amount of header inclusion can do more than declare them. Including wrong headers result in them being completely undeclared. > ... > > > > I think the ports are only meddling the FP mask to hide their FP errors > > > > when running under FreeBSD-3.x and earlier anyway. > > > > > > They are meddling with it because the FreeBSD default, while it is > > ^^ iswas (1) > > > permitted by the standard, is different from what most software > > was (2) > > > expects the default to be. > > > > (1) was permitted by C90; is not permitted by C99, but C99 is not supported > > yet. > > So it's irrelevent, right? It's probably irrelevant. I haven't looked at the ports. They seem to attempting to make null changes in FreeBSD-4.0 and later. > > (2) was different before FreeBSD-4.0. Are there any ports that still > > support FreeBSD-3? > > Not this software, certainly... making it also irrelevent, right? Not quite irrelvant, since they seem to have dead code which has been wrong since 1998. > > > Yeah, it'd be nice if it weren't there, but the man page itself > > > specifically uses fpsetmask() in an example (to prevent some trap). > > > > The man page still supports FreeBSD-3 :-). It is version-agnostic. The > > default setting is very MD, so software that actually cares must not > > assume anything about the defaults. > > Exactly. And therfore must call the function to set the FPU into > a known state, with regatd to exception handling, etc.. Which > makes my case, there. Very few applications have a legitimate use for doing this. I would expect the ones that do to know which headers to include. > ... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 13:14:14 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CBE637B401 for ; Sun, 12 Jan 2003 13:14:13 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D12143F5B for ; Sun, 12 Jan 2003 13:14:12 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0CLEBu4087347; Sun, 12 Jan 2003 13:14:11 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030112155525.K212@locore.ca> Date: Sun, 12 Jan 2003 13:14:11 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Jake Burkholder Subject: Re: Question about odd stack pointer values on sparc64 Cc: sparc@FreeBSD.ORG Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jake Burkholder wrote: > Apparently, On Sun, Jan 12, 2003 at 12:44:44PM -0800, > John Polstra said words to the effect of; > >> In GDB I notice that the stack pointer and frame pointer are often >> (always?) odd numbers, e.g.: [...] > Its because the stack is offset by -2047, to get the real stack pointer > add 2047. Ohhhhh! No _wonder_ M3 hasn't been working right ... > As for reasons why this was done, apparently it allows a larger region > of stack to be addressed with 13 bit immediate offsets, also 32 bit sparc > code doesn't use a stack bias so it can be distinguished by testing the > alignment of the unmodified stack pointer. Makes sense. Thanks for the info! John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 13:15:42 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C0337B401 for ; Sun, 12 Jan 2003 13:15:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 79F9A43ED8 for ; Sun, 12 Jan 2003 13:15:39 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 9387 invoked by uid 0); 12 Jan 2003 21:15:38 -0000 Received: from p508e7fb6.dip.t-dialin.net (HELO galatea.local) (80.142.127.182) by mail.gmx.net (mp013-rz3) with SMTP; 12 Jan 2003 21:15:38 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18XpTj-0001Il-00; Sun, 12 Jan 2003 22:17:11 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0CLH6V5005006; Sun, 12 Jan 2003 22:17:06 +0100 (CET) Date: Sun, 12 Jan 2003 22:17:06 +0100 From: Thomas Moestl To: John Polstra Cc: sparc@freebsd.org Subject: Re: Question about odd stack pointer values on sparc64 Message-ID: <20030112211706.GA278@crow.dom2ip.de> Mail-Followup-To: John Polstra , sparc@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 2003/01/12 at 12:44:44 -0800, John Polstra wrote: > Still working on getting Modula-3 going on Sparc64. I think I'm > getting close ... > > In GDB I notice that the stack pointer and frame pointer are often > (always?) odd numbers, e.g.: > > (gdb) p/x $sp > $1 = 0x7fdffffdec1 > (gdb) p/x $fp > $2 = 0x7fdffffdfb1 > > What is the reason for that? Are the low-order bits simply ignored? > Surely the stack is more aligned than that. The actual stack location is %sp + SPOFF (where SPOFF is 2047) by convention. This causes the stack pointer to always contain an odd number; 32 bit binaries do not have this offset, so their stack pointers are always even. This allows some kernel trap handlers to easily distinguish between 32 and 64 bit binaries. 2047 seems to have been chosen of all odd numbers to enlarge the range of "interesting" %fp-relative locations addressable using immediates. The SPARC compliance definition (SCD) has more information on this (it's available at http://www.sparc.com/resource.htm). - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 14:32:50 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D05237B401 for ; Sun, 12 Jan 2003 14:32:49 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715DA43F7C for ; Sun, 12 Jan 2003 14:32:42 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0CKtPjb005743; Sun, 12 Jan 2003 15:55:25 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0CKtPqV005742; Sun, 12 Jan 2003 15:55:25 -0500 (EST) Date: Sun, 12 Jan 2003 15:55:25 -0500 From: Jake Burkholder To: John Polstra Cc: sparc@FreeBSD.ORG Subject: Re: Question about odd stack pointer values on sparc64 Message-ID: <20030112155525.K212@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdp@polstra.com on Sun, Jan 12, 2003 at 12:44:44PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Jan 12, 2003 at 12:44:44PM -0800, John Polstra said words to the effect of; > Still working on getting Modula-3 going on Sparc64. I think I'm > getting close ... > > In GDB I notice that the stack pointer and frame pointer are often > (always?) odd numbers, e.g.: > > (gdb) p/x $sp > $1 = 0x7fdffffdec1 > (gdb) p/x $fp > $2 = 0x7fdffffdfb1 > > What is the reason for that? Are the low-order bits simply ignored? > Surely the stack is more aligned than that. > > I'm pretty sure this is confusing the M3 garbage collector. It just > might be the proverbial Last Bug. :-) Its because the stack is offset by -2047, to get the real stack pointer add 2047. If you look at how gcc addresses stack variables you'll see it adding in the bias. As for reasons why this was done, apparently it allows a larger region of stack to be addressed with 13 bit immediate offsets, also 32 bit sparc code doesn't use a stack bias so it can be distinguished by testing the alignment of the unmodified stack pointer. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 14:53:57 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D524037B401 for ; Sun, 12 Jan 2003 14:53:51 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 90A0443ED8 for ; Sun, 12 Jan 2003 14:53:50 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 11802 invoked by uid 0); 12 Jan 2003 22:53:48 -0000 Received: from p508e7fb6.dip.t-dialin.net (HELO galatea.local) (80.142.127.182) by mail.gmx.net (mp016-rz3) with SMTP; 12 Jan 2003 22:53:48 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18Xr0j-0001YW-00; Sun, 12 Jan 2003 23:55:22 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0CMtI9Q005983; Sun, 12 Jan 2003 23:55:18 +0100 (CET) Date: Sun, 12 Jan 2003 23:55:18 +0100 From: Thomas Moestl To: Roderick van Domburg Cc: freebsd-sparc64@freebsd.org Subject: Re: panic: trap: fast data access mmu miss Message-ID: <20030112225517.GB278@crow.dom2ip.de> Mail-Followup-To: Roderick van Domburg , freebsd-sparc64@freebsd.org References: <20030112010950.GA56998@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, 2003/01/12 at 16:13:20 +0100, Roderick van Domburg wrote: > > > Running on a Sun Enterprise 250 with a single UltraSparc-II > > > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had > > > this same problem with sources over the past few (three?) days. > > > I had to copy this dmesg by hand, so please bear with any > > > possible typos. > > > > Please try the attached diff. The crash was due to what I consider a > > driver bug (not checking the error in the bus_dmamap_load() callback), > > however due to the FreeBSD busdma API being largely undocumented it is > > a bit difficult to tell what should be considered legal. Much more > > problematic is to assume that the first segment's bus address will be > > 0 in the error case. This is not currently guaranteed by any > > implementation. > > > > The attached patch fixes that, and also passes a valid pointer to the > > callback for maximum compatability. It also fixes some other bugs I > > came across. > > > > This does however still not address the reason for the > > bus_dmamap_load() failure; I'm not really sure why this does > > happen. Please look for messages like: > > __sym_calloc2: failed to allocate ... > > and tell me if you see any of them. > > Thanks for the patches! Unfortunately however, it still doesn't seem to > attach sym1 quite right, I believe. Your patches did make the booting > process advance further, but the kernel failed to mount root. Here is the > dmesg, once again manually copied. That __sym_calloc2 message is right on > the second line. Hmmm, that's what I expected. Can you please try the attached patch instead? It adds some more error reporting, so I should be able to see what exactly is going wrong. Please mail me any new lines of output appearing directly above the __sym_calloc2 message. I think I've already ruled out most causes; I'm suspecting that malloc() might be failing due to massive use of M_NOWAIT in the related code. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iommu-errbd.diff" Index: sparc64/sparc64/iommu.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v retrieving revision 1.14 diff -u -r1.14 iommu.c --- sparc64/sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14 +++ sparc64/sparc64/iommu.c 12 Jan 2003 22:43:59 -0000 @@ -517,10 +517,13 @@ { struct resource *res; struct bus_dmamap_res *bdr; - bus_size_t align, bound, sgsize; + bus_size_t align, sgsize; - if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) + if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) { + printf("iommu_dvma_valloc: res descriptor allocation " + "failed.\n"); return (EAGAIN); + } /* * If a boundary is specified, a map cannot be larger than it; however * we do not clip currently, as that does not play well with the lazy @@ -531,12 +534,13 @@ sgsize = round_io_page(size) >> IO_PAGE_SHIFT; if (t->dt_boundary > 0 && t->dt_boundary < IO_PAGE_SIZE) panic("iommu_dvmamap_load: illegal boundary specified"); - bound = ulmax(t->dt_boundary >> IO_PAGE_SHIFT, 1); res = rman_reserve_resource_bound(&iommu_dvma_rman, 0L, - t->dt_lowaddr, sgsize, bound >> IO_PAGE_SHIFT, + t->dt_lowaddr, sgsize, t->dt_boundary >> IO_PAGE_SHIFT, RF_ACTIVE | rman_make_alignment_flags(align), NULL); - if (res == NULL) + if (res == NULL) { + printf("iommu_dvma_valloc: out of DVMA space.\n"); return (ENOMEM); + } bdr->dr_res = res; bdr->dr_used = 0; @@ -766,8 +770,10 @@ pmap_t pmap = NULL; KASSERT(buflen != 0, ("iommu_dvmamap_load_buffer: buflen == 0!")); - if (buflen > dt->dt_maxsize) + if (buflen > dt->dt_maxsize) { + printf("iommu_dvmamap_load_buffer: buffer too long.\n"); return (EINVAL); + } if (td != NULL) pmap = vmspace_pmap(td->td_proc->p_vmspace); @@ -813,6 +819,8 @@ sgcnt++; if (sgcnt >= dt->dt_nsegments || sgcnt >= BUS_DMAMAP_NSEGS) { + printf("iommu_dvmamap_load_buffer: too many " + "segments.\n"); error = EFBIG; break; } @@ -860,7 +868,7 @@ if (error != 0) { iommu_dvmamap_vunload(is, map); - (*cb)(cba, NULL, 0, error); + (*cb)(cba, sgs, 0, error); } else { /* Move the map to the end of the LRU queue. */ iommu_map_insq(map); Index: dev/sym/sym_hipd.c =================================================================== RCS file: /ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.38 diff -u -r1.38 sym_hipd.c --- dev/sym/sym_hipd.c 1 Jan 2003 18:48:52 -0000 1.38 +++ dev/sym/sym_hipd.c 12 Jan 2003 01:05:21 -0000 @@ -712,7 +712,10 @@ { bus_addr_t *baddr; baddr = (bus_addr_t *)arg; - *baddr = segs->ds_addr; + if (error != 0) + *baddr = 0; + else + *baddr = segs->ds_addr; } static m_addr_t ___dma_getp(m_pool_s *mp) @@ -728,8 +731,9 @@ if (bus_dmamem_alloc(mp->dmat, &vaddr, BUS_DMA_NOWAIT, &vbp->dmamap)) goto out_err; - bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr, - MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0); + if (bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr, + MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0)) + goto out_err; if (baddr) { int hc = VTOB_HASH_CODE(vaddr); vbp->vaddr = (m_addr_t) vaddr; @@ -744,8 +748,6 @@ bus_dmamap_unload(mp->dmat, vbp->dmamap); if (vaddr) bus_dmamem_free(mp->dmat, vaddr, vbp->dmamap); - if (vbp->dmamap) - bus_dmamap_destroy(mp->dmat, vbp->dmamap); if (vbp) __sym_mfree(&mp0, vbp, sizeof(*vbp), "VTOB"); return 0; Index: kern/subr_rman.c =================================================================== RCS file: /ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.27 diff -u -r1.27 subr_rman.c --- kern/subr_rman.c 27 Nov 2002 03:55:22 -0000 1.27 +++ kern/subr_rman.c 12 Jan 2003 22:45:20 -0000 @@ -229,7 +229,7 @@ */ do { rstart = (rstart + amask) & ~amask; - if (((rstart ^ (rstart + count)) & bmask) != 0) + if (((rstart ^ (rstart + count - 1)) & bmask) != 0) rstart += bound - (rstart & ~bmask); } while ((rstart & amask) != 0 && rstart < end && rstart < s->r_end); @@ -263,8 +263,11 @@ * two new allocations; the second requires but one. */ rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); - if (rv == 0) + if (rv == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); goto out; + } rv->r_start = rstart; rv->r_end = rstart + count - 1; rv->r_flags = flags | RF_ALLOCATED; @@ -282,6 +285,8 @@ */ r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO); if (r == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); free(rv, M_RMAN); rv = 0; goto out; --XsQoSWH+UP9D9v3l-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 16:10:44 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A7BD37B405 for ; Sun, 12 Jan 2003 16:10:43 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FBDE43EB2 for ; Sun, 12 Jan 2003 16:10:38 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0D07Kb08527; Mon, 13 Jan 2003 01:07:20 +0100 From: "Roderick van Domburg" To: "Thomas Moestl" Cc: Subject: RE: panic: trap: fast data access mmu miss Date: Mon, 13 Jan 2003 01:08:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030112225517.GB278@crow.dom2ip.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hmmm, that's what I expected. Can you please try the attached patch > instead? It adds some more error reporting, so I should be able to see > what exactly is going wrong. Please mail me any new lines of output > appearing directly above the __sym_calloc2 message. Well, somewhere after the isp0 initialization, the console was literally flooded with "iommu_dvma_valloc: out of DMA space." I couldn't see _exactly_ when it started printing those messages. It did that for maybe 15 - 20 seconds, then continued the booting as usual with occasionally the same message (perhaps five times?) then after the 15 second SCSI timeout, the screen was flooded indefinitely with a message from sym0. It went to fast to make it out exactly, but this is about what it said: sym0: PCI STATUS = 0x2000 sym0: [unable to make this part out] SCSI BUS reset detected. sym0: [again unable to read] sym0: [unable to read] regdump 00 00 05 47 00 00 0f 00 08 00 00 80 00 08 02 00 00 00 00 20 ff sym0: [unable to read] I left it running for some 5 minutes, but it appeared to be stuck in that loop. You will have to bear with me on the regdump, I'm not sure if these are the exact number of bytes and the 0's look a lot like 8's, and vice versa, when the console is flooded. Sincerely, Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 16:14:42 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABB1B37B401; Sun, 12 Jan 2003 16:14:41 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id D24FE43EB2; Sun, 12 Jan 2003 16:14:40 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from heron (heron.mail.pas.earthlink.net [207.217.120.189]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0CNjPH19109; Sun, 12 Jan 2003 15:45:25 -0800 (PST) Received: from pool0338.cvx22-bradley.dialup.earthlink.net ([209.179.199.83] helo=mindspring.com) by heron with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18Xrml-0005xR-00; Sun, 12 Jan 2003 15:44:59 -0800 Message-ID: <3E21FDAC.1FD36F5C@mindspring.com> Date: Sun, 12 Jan 2003 15:43:40 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder Cc: sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> <20030112134948.I212@locore.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d7f5fa927a43dcc8f86fdbf12c8f541d93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jake Burkholder wrote: > > > > Isn't that really a lame excuse? Shouldn't > > > > > > > > #ifdef __FreeBSD__ > > > > > > > > be enough to make code compile on all FreeBSD platforms? > > > > > > I don't know, why don't you try it. > > > > I understand the snide reply. My point was that if FreeBSD had > > My point is that you could help by actually doing something. Your > repeated long emails DO NOT HELP. Whereas excuses as to why things are the way they are, and people should just put up with it, DO help? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 16:39:46 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83FF137B401 for ; Sun, 12 Jan 2003 16:39:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1FA7843F1E for ; Sun, 12 Jan 2003 16:39:44 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 26049 invoked by uid 0); 13 Jan 2003 00:39:42 -0000 Received: from p508e7fb6.dip.t-dialin.net (HELO galatea.local) (80.142.127.182) by mail.gmx.net (mp022-rz3) with SMTP; 13 Jan 2003 00:39:42 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18XsfC-0001np-00; Mon, 13 Jan 2003 01:41:15 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0D0fBCu006932; Mon, 13 Jan 2003 01:41:11 +0100 (CET) Date: Mon, 13 Jan 2003 01:41:11 +0100 From: Thomas Moestl To: Roderick van Domburg Cc: freebsd-sparc64@FreeBSD.ORG Subject: Re: panic: trap: fast data access mmu miss Message-ID: <20030113004111.GD278@crow.dom2ip.de> Mail-Followup-To: Roderick van Domburg , freebsd-sparc64@FreeBSD.ORG References: <20030112225517.GB278@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2003/01/13 at 01:08:04 +0100, Roderick van Domburg wrote: > > Hmmm, that's what I expected. Can you please try the attached patch > > instead? It adds some more error reporting, so I should be able to see > > what exactly is going wrong. Please mail me any new lines of output > > appearing directly above the __sym_calloc2 message. > > Well, somewhere after the isp0 initialization, the console was literally > flooded with "iommu_dvma_valloc: out of DMA space." I couldn't see _exactly_ > when it started printing those messages. Oh, you have an isp in that box? In that case this is expected, please remove this line: printf("iommu_dvma_valloc: out of DVMA space.\n"); from sys/sparc64/sparc64/iommu.c and try again. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 18:52:22 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AEE037B401; Sun, 12 Jan 2003 18:52:17 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7266843F13; Sun, 12 Jan 2003 18:52:16 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0D2TXH05241; Sun, 12 Jan 2003 18:29:33 -0800 (PST) Received: from pool0374.cvx40-bradley.dialup.earthlink.net ([216.244.43.119] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XuL8-0003Rt-00; Sun, 12 Jan 2003 18:28:39 -0800 Message-ID: <3E2223F4.5554718E@mindspring.com> Date: Sun, 12 Jan 2003 18:27:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: [PATCH] Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> <20030112134948.I212@locore.ca> <3E21FDAC.1FD36F5C@mindspring.com> Content-Type: multipart/mixed; boundary="------------C36EAE74A9FB2FE61C3D5D7B" X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ad8d6cd516048613d570fcccd34675433ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------C36EAE74A9FB2FE61C3D5D7B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This patch also affects the IA64 and Alpha, as well as just the SPARC. It took a lot of discussion, but it seems to me that the problem is that the prototypes in scope aren't in scope when the wrong include file is included. This is partially a problem with the FreeBSD code, because it's really not healthy to have "#ifdef i386" in /usr/include/*, since these are (supposedly) machine independent files that should not change behaviour based on which platform you are using to compile them. That basically means that the machine dependent behaviour should be in headers. This is actually how it works for the i386 in -current, where the symbols come into scope as macros whose definitions reference inline functions. But this layering is broken for the other platforms, where the symbols are supposed to come into scope by means of prototypes. Therefore, it seems to me, that the correct place to put them is in the header (the other alternative was the header; this seemed wrong to me, but I'm willing to reroll the patch, if there's a lot of disagreement over this point). So I've basically gotten rid of the #ifdef, and pushed the function prototypes down. This will incidently work around the improper inclusion of machine dependent files by ports. I can't really fix that, without the ports that do it being fixed. For code wher this isn't an issue, though, it actually fixes, rather than works around, the problem, in what I thing is the correct way. Context diff attached. -- Terry --------------C36EAE74A9FB2FE61C3D5D7B Content-Type: text/plain; charset=us-ascii; name="fixfp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fixfp.diff" Index: include/ieeefp.h =================================================================== RCS file: /cvs/src/include/ieeefp.h,v retrieving revision 1.6 diff -c -r1.6 ieeefp.h *** include/ieeefp.h 23 Mar 2002 17:24:53 -0000 1.6 --- include/ieeefp.h 12 Jan 2003 22:04:26 -0000 *************** *** 11,28 **** #include #include - - #ifdef __i386__ #include - #else /* !__i386__ */ - __BEGIN_DECLS - extern fp_rnd_t fpgetround(void); - extern fp_rnd_t fpsetround(fp_rnd_t); - extern fp_except_t fpgetmask(void); - extern fp_except_t fpsetmask(fp_except_t); - extern fp_except_t fpgetsticky(void); - extern fp_except_t fpsetsticky(fp_except_t); - __END_DECLS - #endif /* __i386__ */ #endif /* _IEEEFP_H_ */ --- 11,16 ---- Index: sys/alpha/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/alpha/include/floatingpoint.h,v retrieving revision 1.3 diff -c -r1.3 floatingpoint.h *** sys/alpha/include/floatingpoint.h 1 May 2000 20:17:49 -0000 1.3 --- sys/alpha/include/floatingpoint.h 12 Jan 2003 22:10:33 -0000 *************** *** 32,35 **** --- 32,63 ---- * $FreeBSD: src/sys/alpha/include/floatingpoint.h,v 1.3 2000/05/01 20:17:49 peter Exp $ */ + #ifndef _FLOATINGPOINT_H_ + #define _FLOATINGPOINT_H_ + + /* + * IEEE floating point structure and function definitions + */ + + /*- + * XXX the following undocumented pollution is exported: + * fpsetsticky(). + * FP*FLD, FP*OFF and FP*REG from + */ + + #include #include + + /* + * SysV/386 FP control interface for platforms with library implemetnations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS + + #endif /* !_FLOATINGPOINT_H_ */ Index: sys/ia64/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/ia64/include/floatingpoint.h,v retrieving revision 1.1 diff -c -r1.1 floatingpoint.h *** sys/ia64/include/floatingpoint.h 29 Sep 2000 13:46:05 -0000 1.1 --- sys/ia64/include/floatingpoint.h 12 Jan 2003 22:10:50 -0000 *************** *** 32,35 **** --- 32,63 ---- * $FreeBSD: src/sys/ia64/include/floatingpoint.h,v 1.1 2000/09/29 13:46:05 dfr Exp $ */ + #ifndef _FLOATINGPOINT_H_ + #define _FLOATINGPOINT_H_ + + /* + * IEEE floating point structure and function definitions + */ + + /*- + * XXX the following undocumented pollution is exported: + * fpsetsticky(). + * FP*FLD, FP*OFF and FP*REG from + */ + + #include #include + + /* + * SysV/386 FP control interface for platforms with library implemetnations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS + + #endif /* !_FLOATINGPOINT_H_ */ Index: sys/sparc64/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/sparc64/include/floatingpoint.h,v retrieving revision 1.1 diff -c -r1.1 floatingpoint.h *** sys/sparc64/include/floatingpoint.h 10 Feb 2002 14:27:20 -0000 1.1 --- sys/sparc64/include/floatingpoint.h 12 Jan 2003 22:11:14 -0000 *************** *** 32,37 **** --- 32,60 ---- #ifndef _FLOATINGPOINT_H_ #define _FLOATINGPOINT_H_ + /* + * IEEE floating point structure and function definitions + */ + + /*- + * XXX the following undocumented pollution is exported: + * fpsetsticky(). + * FP*FLD, FP*OFF and FP*REG from + */ + + #include #include + + /* + * SysV/386 FP control interface for platforms with library implemetnations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS #endif /* !_FLOATINGPOINT_H_ */ --------------C36EAE74A9FB2FE61C3D5D7B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 18:53:27 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C674337B401; Sun, 12 Jan 2003 18:53:26 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E00A43ED8; Sun, 12 Jan 2003 18:53:26 -0800 (PST) (envelope-from linimon@lonesome.com) Received: from lonesome.lonesome.com (cs2876-77.austin.rr.com [24.28.76.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 0D9121433C; Sun, 12 Jan 2003 20:53:20 -0600 (CST) Content-Type: text/plain; charset="iso-8859-1" From: Mark Linimon Organization: Lonesome Dove Computing Services To: sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 Date: Sun, 12 Jan 2003 20:53:45 -0600 User-Agent: KMail/1.4.3 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112134948.I212@locore.ca> <3E21FDAC.1FD36F5C@mindspring.com> In-Reply-To: <3E21FDAC.1FD36F5C@mindspring.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301122053.45447.linimon@lonesome.com> Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Whereas excuses as to why things are the way they are, and > people should just put up with it, DO help? Well, I don't know about that, but I know that this response does not, in and of itself, help do anthing -- except to raise the room temperature. Anyway, since we now seem to have left any technical content behind, can this be taken to -chat, offline email, or, better yet, /dev/null? Thank you. Mark Linimon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 19: 2:35 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D75337B401 for ; Sun, 12 Jan 2003 19:02:34 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C1A843F3F for ; Sun, 12 Jan 2003 19:02:33 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0D32Ub32519; Mon, 13 Jan 2003 04:02:30 +0100 From: "Roderick van Domburg" To: "Thomas Moestl" Cc: Subject: RE: panic: trap: fast data access mmu miss Date: Mon, 13 Jan 2003 04:03:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030113004111.GD278@crow.dom2ip.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > Hmmm, that's what I expected. Can you please try the attached patch > > > instead? It adds some more error reporting, so I should be able to see > > > what exactly is going wrong. Please mail me any new lines of output > > > appearing directly above the __sym_calloc2 message. > > > > Well, somewhere after the isp0 initialization, the console was literally > > flooded with "iommu_dvma_valloc: out of DMA space." I couldn't see > > _exactly_ when it started printing those messages. > > Oh, you have an isp in that box? In that case this is expected, please > remove this line: > > printf("iommu_dvma_valloc: out of DVMA space.\n"); > > from sys/sparc64/sparc64/iommu.c and try again. Okay, did that. Unfortunately It doesn't mention much more than it did before: sym0: <875> port 0x2000-0x20ff mem 0x410a000-0x410afff, 0x4108000-0x41080ff irq 32 at device 3.1 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff, 0x410c000-0x410c0ff irq 38 at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking __sym_calloc2: failed to allocate SCRIPTB0[1308] device_probe_and_attach: sym1 returned 6 [cut] Mounting root from ufs:/dev/da0a setrootbyname: failed ffs_mountroot: can't find rootvp Root mount failed: 6 Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 19:30:25 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C44F37B401 for ; Sun, 12 Jan 2003 19:30:24 -0800 (PST) Received: from manual-override.net (manual-override.net [65.42.236.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D037143F18 for ; Sun, 12 Jan 2003 19:30:23 -0800 (PST) (envelope-from chris@manual-override.net) Received: from manual-override.net (localhost [127.0.0.1]) by manual-override.net (8.12.7/8.7.1) with ESMTP id h0D3SOPh083993 for ; Sun, 12 Jan 2003 22:28:24 -0500 (EST) Chris-is-the-man: Yes Received: from localhost (chris@localhost) by manual-override.net (8.12.7/8.12.6/Submit) with ESMTP id h0D3SOTl083990 for ; Sun, 12 Jan 2003 22:28:24 -0500 (EST) Date: Sun, 12 Jan 2003 22:28:24 -0500 (EST) From: Chris Orr To: freebsd-sparc@freebsd.org Subject: netra t1 gem driver Message-ID: <20030112222426.F83985-100000@manual-override.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am currently running 5.0-release on a netra t1 ac200. These boxes have 2 ethernet ports. (they work in solaris as eri0 and eri1) I can only get 1 of the ethernet ports to work (gem0) in freebsd. Can anyone point me in the right direction on getting the other port to work? Let me know if you need any more info. Thanks in advance! -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 19:46:34 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8068B37B401; Sun, 12 Jan 2003 19:46:33 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FE243F43; Sun, 12 Jan 2003 19:46:32 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0D3kV2G039110; Sun, 12 Jan 2003 19:46:31 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0D3kcCv002417; Sun, 12 Jan 2003 19:46:38 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0D3kcsh002416; Sun, 12 Jan 2003 19:46:38 -0800 (PST) (envelope-from marcel) Date: Sun, 12 Jan 2003 19:46:38 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> <20030112134948.I212@locore.ca> <3E21FDAC.1FD36F5C@mindspring.com> <3E2223F4.5554718E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E2223F4.5554718E@mindspring.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote: > > Therefore, it seems to me, that the correct place to put them is in > the header (the other alternative was the > header; this seemed wrong to me, but I'm willing > to reroll the patch, if there's a lot of disagreement over this point). I would like to see it in : The synopsis section of our manpage clearly states the inclusion of . That header file includes a machine dependent counterpart . On alpha, ia64 and sparc64 is empty with the exception of the inclusion of . Hence, I would like to see the prototypes and/or implementation in . Since on i386 also includes , we should be able to move the implementation on i386 to as well. If possible, I'd like to see retired unless there's a compelling reason to keep it... My $0.02 -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 21:40:17 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D41C037B405; Sun, 12 Jan 2003 21:40:02 -0800 (PST) Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CF443F5B; Sun, 12 Jan 2003 21:40:01 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from heron (heron.mail.pas.earthlink.net [207.217.120.189]) by badboy.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0D5ICk10333; Sun, 12 Jan 2003 21:18:12 -0800 (PST) Received: from pool0461.cvx22-bradley.dialup.earthlink.net ([209.179.199.206] helo=mindspring.com) by heron with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18Xwus-0003ZN-00; Sun, 12 Jan 2003 21:13:43 -0800 Message-ID: <3E224AAA.11792616@mindspring.com> Date: Sun, 12 Jan 2003 21:12:11 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> <20030112134948.I212@locore.ca> <3E21FDAC.1FD36F5C@mindspring.com> <3E2223F4.5554718E@mindspring.com> <20030113034638.GA2310@dhcp01.pn.xcllnt.net> Content-Type: multipart/mixed; boundary="------------B8AE5B3A0FF5EB7A07DC7E4B" X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fd9aa4dc0fe1a9be7da685d7ac518464548b785378294e88350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------B8AE5B3A0FF5EB7A07DC7E4B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marcel Moolenaar wrote: > On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote: > > Therefore, it seems to me, that the correct place to put them is in > > the header (the other alternative was the > > header; this seemed wrong to me, but I'm willing > > to reroll the patch, if there's a lot of disagreement over this point). > > I would like to see it in : Here is the patch, made this way instead. It's about 4 times larger. Pick which one you like, and commit it to make Kris happy. -- Terry --------------B8AE5B3A0FF5EB7A07DC7E4B Content-Type: text/plain; charset=us-ascii; name="fixfp2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fixfp2.diff" Index: include/ieeefp.h =================================================================== RCS file: /cvs/src/include/ieeefp.h,v retrieving revision 1.6 diff -c -r1.6 ieeefp.h *** include/ieeefp.h 23 Mar 2002 17:24:53 -0000 1.6 --- include/ieeefp.h 13 Jan 2003 00:59:42 -0000 *************** *** 9,28 **** #ifndef _IEEEFP_H_ #define _IEEEFP_H_ - #include #include - - #ifdef __i386__ - #include - #else /* !__i386__ */ - __BEGIN_DECLS - extern fp_rnd_t fpgetround(void); - extern fp_rnd_t fpsetround(fp_rnd_t); - extern fp_except_t fpgetmask(void); - extern fp_except_t fpsetmask(fp_except_t); - extern fp_except_t fpgetsticky(void); - extern fp_except_t fpsetsticky(fp_except_t); - __END_DECLS - #endif /* __i386__ */ #endif /* _IEEEFP_H_ */ --- 9,14 ---- Index: sys/alpha/include/ieeefp.h =================================================================== RCS file: /cvs/src/sys/alpha/include/ieeefp.h,v retrieving revision 1.5 diff -c -r1.5 ieeefp.h *** sys/alpha/include/ieeefp.h 10 May 2000 19:41:40 -0000 1.5 --- sys/alpha/include/ieeefp.h 13 Jan 2003 01:02:21 -0000 *************** *** 9,14 **** --- 9,16 ---- #ifndef _ALPHA_IEEEFP_H_ #define _ALPHA_IEEEFP_H_ + #include + typedef int fp_except_t; #define FP_X_INV (1LL << 1) /* invalid operation exception */ #define FP_X_DZ (1LL << 2) /* divide-by-zero exception */ *************** *** 25,29 **** --- 27,43 ---- FP_RN=2, /* round to nearest representable number */ FP_RP=3 /* round toward positive infinity */ } fp_rnd_t; + + /* + * SysV/386 FP control interface for platforms with library implementations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS #endif /* _ALPHA_IEEEFP_H_ */ Index: sys/alpha/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/alpha/include/floatingpoint.h,v retrieving revision 1.3 diff -c -r1.3 floatingpoint.h *** sys/alpha/include/floatingpoint.h 1 May 2000 20:17:49 -0000 1.3 --- sys/alpha/include/floatingpoint.h 13 Jan 2003 01:10:07 -0000 *************** *** 32,35 **** --- 32,40 ---- * $FreeBSD: src/sys/alpha/include/floatingpoint.h,v 1.3 2000/05/01 20:17:49 peter Exp $ */ + #ifndef _FLOATINGPOINT_H_ + #define _FLOATINGPOINT_H_ + #include + + #endif /* !_FLOATINGPOINT_H_ */ Index: sys/i386/include/ieeefp.h =================================================================== RCS file: /cvs/src/sys/i386/include/ieeefp.h,v retrieving revision 1.7 diff -c -r1.7 ieeefp.h *** sys/i386/include/ieeefp.h 28 Aug 1999 00:44:15 -0000 1.7 --- sys/i386/include/ieeefp.h 13 Jan 2003 01:06:06 -0000 *************** *** 41,46 **** --- 41,48 ---- #ifndef _MACHINE_IEEEFP_H_ #define _MACHINE_IEEEFP_H_ + #include + /* * FP rounding modes */ *************** *** 97,101 **** --- 99,186 ---- #define FP_PRC_OFF 8 /* precision control offset */ #define FP_RND_OFF 10 /* round control offset */ #define FP_STKY_OFF 0 /* sticky flags offset */ + + /*- + * XXX the following undocumented pollution is exported: + * fpsetsticky(). + * FP*FLD, FP*OFF and FP*REG from + */ + + #ifdef __GNUC__ + + #define __fldenv(addr) __asm __volatile("fldenv %0" : : "m" (*(addr))) + #define __fnstenv(addr) __asm __volatile("fnstenv %0" : "=m" (*(addr))) + #define __fnstcw(addr) __asm __volatile("fnstcw %0" : "=m" (*(addr))) + #define __fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr))) + + /* + * return the contents of a FP register + */ + static __inline__ int + __fpgetreg(int _reg) + { + unsigned short _mem; + + /*- + * This is more efficient than it looks. The switch gets optimized + * away if _reg is constant. + * + * The default case only supports _reg == 0. We could handle more + * registers (e.g., tags) using fnstenv, but the interface doesn't + * support more. + */ + switch(_reg) { + default: + __fnstcw(&_mem); + break; + case FP_STKY_REG: + __fnstsw(&_mem); + break; + } + return _mem; + } + + /* + * set a FP mode; return previous mode + */ + static __inline__ int + __fpsetreg(int _m, int _reg, int _fld, int _off) + { + unsigned _env[7]; + unsigned _p; + + /* + * _reg == 0 could be handled better using fnstcw/fldcw. + */ + __fnstenv(_env); + _p = (_env[_reg] & _fld) >> _off; + _env[_reg] = (_env[_reg] & ~_fld) | (_m << _off & _fld); + __fldenv(_env); + return _p; + } + + #endif /* __GNUC__ */ + + /* + * SysV/386 FP control interface + */ + #define fpgetround() ((fp_rnd_t) \ + ((__fpgetreg(FP_RND_REG) & FP_RND_FLD) >> FP_RND_OFF)) + #define fpsetround(m) ((fp_rnd_t) \ + __fpsetreg((m), FP_RND_REG, FP_RND_FLD, FP_RND_OFF)) + #define fpgetprec() ((fp_prec_t) \ + ((__fpgetreg(FP_PRC_REG) & FP_PRC_FLD) >> FP_PRC_OFF)) + #define fpsetprec(m) ((fp_prec_t) \ + __fpsetreg((m), FP_PRC_REG, FP_PRC_FLD, FP_PRC_OFF)) + #define fpgetmask() ((fp_except_t) \ + ((~__fpgetreg(FP_MSKS_REG) & FP_MSKS_FLD) >> FP_MSKS_OFF)) + #define fpsetmask(m) ((fp_except_t) \ + (~__fpsetreg(~(m), FP_MSKS_REG, FP_MSKS_FLD, FP_MSKS_OFF)) & \ + (FP_MSKS_FLD >> FP_MSKS_OFF)) + #define fpgetsticky() ((fp_except_t) \ + ((__fpgetreg(FP_STKY_REG) & FP_STKY_FLD) >> FP_STKY_OFF)) + #define fpresetsticky(m) ((fp_except_t) \ + __fpsetreg(0, FP_STKY_REG, (m), FP_STKY_OFF)) + #define fpsetsticky(m) fpresetsticky(m) #endif /* !_MACHINE_IEEEFP_H_ */ Index: sys/i386/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/i386/include/floatingpoint.h,v retrieving revision 1.12 diff -c -r1.12 floatingpoint.h *** sys/i386/include/floatingpoint.h 1 Jun 2002 17:39:46 -0000 1.12 --- sys/i386/include/floatingpoint.h 13 Jan 2003 01:10:33 -0000 *************** *** 37,130 **** #ifndef _FLOATINGPOINT_H_ #define _FLOATINGPOINT_H_ - /* - * IEEE floating point structure and function definitions - */ - - /*- - * XXX the following undocumented pollution is exported: - * fpsetsticky(). - * FP*FLD, FP*OFF and FP*REG from - */ - - #include #include - - #ifdef __GNUC__ - - #define __fldenv(addr) __asm __volatile("fldenv %0" : : "m" (*(addr))) - #define __fnstenv(addr) __asm __volatile("fnstenv %0" : "=m" (*(addr))) - #define __fnstcw(addr) __asm __volatile("fnstcw %0" : "=m" (*(addr))) - #define __fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr))) - - /* - * return the contents of a FP register - */ - static __inline__ int - __fpgetreg(int _reg) - { - unsigned short _mem; - - /*- - * This is more efficient than it looks. The switch gets optimized - * away if _reg is constant. - * - * The default case only supports _reg == 0. We could handle more - * registers (e.g., tags) using fnstenv, but the interface doesn't - * support more. - */ - switch(_reg) { - default: - __fnstcw(&_mem); - break; - case FP_STKY_REG: - __fnstsw(&_mem); - break; - } - return _mem; - } - - /* - * set a FP mode; return previous mode - */ - static __inline__ int - __fpsetreg(int _m, int _reg, int _fld, int _off) - { - unsigned _env[7]; - unsigned _p; - - /* - * _reg == 0 could be handled better using fnstcw/fldcw. - */ - __fnstenv(_env); - _p = (_env[_reg] & _fld) >> _off; - _env[_reg] = (_env[_reg] & ~_fld) | (_m << _off & _fld); - __fldenv(_env); - return _p; - } - - #endif /* __GNUC__ */ - - /* - * SysV/386 FP control interface - */ - #define fpgetround() ((fp_rnd_t) \ - ((__fpgetreg(FP_RND_REG) & FP_RND_FLD) >> FP_RND_OFF)) - #define fpsetround(m) ((fp_rnd_t) \ - __fpsetreg((m), FP_RND_REG, FP_RND_FLD, FP_RND_OFF)) - #define fpgetprec() ((fp_prec_t) \ - ((__fpgetreg(FP_PRC_REG) & FP_PRC_FLD) >> FP_PRC_OFF)) - #define fpsetprec(m) ((fp_prec_t) \ - __fpsetreg((m), FP_PRC_REG, FP_PRC_FLD, FP_PRC_OFF)) - #define fpgetmask() ((fp_except_t) \ - ((~__fpgetreg(FP_MSKS_REG) & FP_MSKS_FLD) >> FP_MSKS_OFF)) - #define fpsetmask(m) ((fp_except_t) \ - (~__fpsetreg(~(m), FP_MSKS_REG, FP_MSKS_FLD, FP_MSKS_OFF)) & \ - (FP_MSKS_FLD >> FP_MSKS_OFF)) - #define fpgetsticky() ((fp_except_t) \ - ((__fpgetreg(FP_STKY_REG) & FP_STKY_FLD) >> FP_STKY_OFF)) - #define fpresetsticky(m) ((fp_except_t) \ - __fpsetreg(0, FP_STKY_REG, (m), FP_STKY_OFF)) - #define fpsetsticky(m) fpresetsticky(m) #endif /* !_FLOATINGPOINT_H_ */ --- 37,42 ---- Index: sys/ia64/include/ieeefp.h =================================================================== RCS file: /cvs/src/sys/ia64/include/ieeefp.h,v retrieving revision 1.3 diff -c -r1.3 ieeefp.h *** sys/ia64/include/ieeefp.h 13 May 2002 05:01:05 -0000 1.3 --- sys/ia64/include/ieeefp.h 13 Jan 2003 01:03:01 -0000 *************** *** 29,34 **** --- 29,35 ---- #ifndef _MACHINE_IEEEFP_H_ #define _MACHINE_IEEEFP_H_ + #include #include typedef int fp_except_t; *************** *** 47,51 **** --- 48,64 ---- FP_RN=2, /* round to nearest representable number */ FP_RP=3 /* round toward positive infinity */ } fp_rnd_t; + + /* + * SysV/386 FP control interface for platforms with library implementations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS #endif /* _MACHINE_IEEEFP_H_ */ Index: sys/ia64/include/floatingpoint.h =================================================================== RCS file: /cvs/src/sys/ia64/include/floatingpoint.h,v retrieving revision 1.1 diff -c -r1.1 floatingpoint.h *** sys/ia64/include/floatingpoint.h 29 Sep 2000 13:46:05 -0000 1.1 --- sys/ia64/include/floatingpoint.h 13 Jan 2003 01:10:53 -0000 *************** *** 32,35 **** --- 32,40 ---- * $FreeBSD: src/sys/ia64/include/floatingpoint.h,v 1.1 2000/09/29 13:46:05 dfr Exp $ */ + #ifndef _FLOATINGPOINT_H_ + #define _FLOATINGPOINT_H_ + #include + + #endif /* !_FLOATINGPOINT_H_ */ Index: sys/powerpc/include/ieeefp.h =================================================================== RCS file: /cvs/src/sys/powerpc/include/ieeefp.h,v retrieving revision 1.1 diff -c -r1.1 ieeefp.h *** sys/powerpc/include/ieeefp.h 13 May 2002 07:44:42 -0000 1.1 --- sys/powerpc/include/ieeefp.h 13 Jan 2003 01:03:26 -0000 *************** *** 8,13 **** --- 8,15 ---- #ifndef _MACHINE_IEEEFP_H_ #define _MACHINE_IEEEFP_H_ + #include + typedef int fp_except_t; #define FP_X_IMP 0x01 /* imprecise (loss of precision) */ #define FP_X_DZ 0x02 /* divide-by-zero exception */ *************** *** 21,25 **** --- 23,39 ---- FP_RP=2, /* round toward positive infinity */ FP_RM=3 /* round toward negative infinity */ } fp_rnd_t; + + /* + * SysV/386 FP control interface for platforms with library implementations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS #endif /* _MACHINE_IEEEFP_H_ */ Index: sys/sparc64/include/ieeefp.h =================================================================== RCS file: /cvs/src/sys/sparc64/include/ieeefp.h,v retrieving revision 1.3 diff -c -r1.3 ieeefp.h *** sys/sparc64/include/ieeefp.h 14 Sep 2002 18:00:44 -0000 1.3 --- sys/sparc64/include/ieeefp.h 13 Jan 2003 01:03:41 -0000 *************** *** 7,12 **** --- 7,13 ---- #ifndef _MACHINE_IEEEFP_H_ #define _MACHINE_IEEEFP_H_ + #include #include typedef int fp_except_t; *************** *** 22,26 **** --- 23,39 ---- FP_RP = FSR_RD_PINF, /* round toward positive infinity */ FP_RM = FSR_RD_NINF /* round toward negative infinity */ } fp_rnd_t; + + /* + * SysV/386 FP control interface for platforms with library implementations + */ + __BEGIN_DECLS + extern fp_rnd_t fpgetround(void); + extern fp_rnd_t fpsetround(fp_rnd_t); + extern fp_except_t fpgetmask(void); + extern fp_except_t fpsetmask(fp_except_t); + extern fp_except_t fpgetsticky(void); + extern fp_except_t fpsetsticky(fp_except_t); + __END_DECLS #endif /* _MACHINE_IEEEFP_H_ */ --------------B8AE5B3A0FF5EB7A07DC7E4B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Jan 12 21:47:45 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD5A437B401; Sun, 12 Jan 2003 21:47:43 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20AEA43ED8; Sun, 12 Jan 2003 21:47:43 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from heron (heron.mail.pas.earthlink.net [207.217.120.189]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0D4uAH09275; Sun, 12 Jan 2003 20:56:10 -0800 (PST) Received: from pool0461.cvx22-bradley.dialup.earthlink.net ([209.179.199.206] helo=mindspring.com) by heron with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18XwdJ-0001qZ-00; Sun, 12 Jan 2003 20:55:34 -0800 Message-ID: <3E22466B.2F85F2FF@mindspring.com> Date: Sun, 12 Jan 2003 20:54:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030112031626.GA15783@rot13.obsecurity.org> <20030112015221.G212@locore.ca> <3E212670.41627B9F@mindspring.com> <20030112032908.H212@locore.ca> <3E216911.B7AFC39F@mindspring.com> <20030112134948.I212@locore.ca> <3E21FDAC.1FD36F5C@mindspring.com> <3E2223F4.5554718E@mindspring.com> <20030113034638.GA2310@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e3a81b55ffec6df7c48328fe2fbec06f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote: > > Therefore, it seems to me, that the correct place to put them is in > > the header (the other alternative was the > > header; this seemed wrong to me, but I'm willing > > to reroll the patch, if there's a lot of disagreement over this point). > > I would like to see it in : I didn't put it there because that's not where the i386 is getting its version of fpsetmask(), et al. As I said, I'd be happy to reroll the patch, and be overruled. Should I move the i386 inline function and #define's from the machine/floatingpoint.h to the machine/ieeefp.h, as well? It seems to me that all the symbols should come from that place, on all architectures, no matter what place it ends up being. > The synopsis section of our manpage clearly states the inclusion > of . That header file includes a machine dependent > counterpart . On alpha, ia64 and sparc64 > is empty with the exception of the > inclusion of . Actually, on SPARC and i386, it puts _FLOATINGPOINT_H_ into scope, too, while on IA64 and Alpha, it doesn't (which is broken, for the #include #ifndef/#define ... /#endif style). > Hence, I would like to see the prototypes and/or implementation > in . Since on i386 > also includes , we should be able to move > the implementation on i386 to as well. If > possible, I'd like to see retired > unless there's a compelling reason to keep it... Well, that answers my question from above: "yes". 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 0:59:30 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A52E37B405; Mon, 13 Jan 2003 00:59:27 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66B743F65; Mon, 13 Jan 2003 00:59:25 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA10665; Mon, 13 Jan 2003 19:58:55 +1100 Date: Mon, 13 Jan 2003 19:59:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: Terry Lambert , Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> Message-ID: <20030113190710.I11541-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 12 Jan 2003, Marcel Moolenaar wrote: > On Sun, Jan 12, 2003 at 06:27:00PM -0800, Terry Lambert wrote: > > > > Therefore, it seems to me, that the correct place to put them is in > > the header (the other alternative was the > > header; this seemed wrong to me, but I'm willing > > to reroll the patch, if there's a lot of disagreement over this point). > > I would like to see it in : I wouldn't like to see it moved. > The synopsis section of our manpage clearly states the inclusion > of . That header file includes a machine dependent > counterpart . On alpha, ia64 and sparc64 > is empty with the exception of the > inclusion of . > > Hence, I would like to see the prototypes and/or implementation > in . The prototypes are machine-independent, so they are correctly placed in . This has the technical problem that it is difficult to implement declared functions as inlines (*), so we use an ugly i386 ifdef in to prevent them being declared. This seems least evil since inlining them doesn't seem to be useful and the wart only affects i386's, and these functions should be obsoleted by the C99 functions as soon as possible. %%% (*) The folling implementations don't work: (1) int foo(int x); static /* inline */ int foo(int x) { return x; } This is not conforming C IIRC. TenDRA says: "z.c", line 2: Warning: [ISO 6.1.2.2]: 'foo' previously declared with external linkage (at line 1). (Since this is only a warning, I'm not sure that it is an error.) (2) static /* inline */ int foo(int x) { return x; } int foo(int x); This is conforming C, but "helpful" compilers warn about it with certain warning flags: z.c:2: warning: redundant redeclaration of `foo' in same scope z.c:1: warning: previous declaration of `foo' %%% > Since on i386 > also includes , we should be able to move > the implementation on i386 to as well. If > possible, I'd like to see retired > unless there's a compelling reason to keep it... There is no good reason for these to be separate, but they may be required for compatibility. IIRC, their names and interfaces were copied from some system (Sun) that had them, but they were slightly misplaced ( is a BSDism AFAIK so other systems couldn't have anything there)... According to google, was in /usr/include in SunOS in 1992 (we link it there), and it seems to be the primary interface (Sun apparently had ieeefp.h in then, but non-BSD hits on it are not as common. So we seem to have headers half compatible with at least the old version of SunOS that they attempt to be compatible with: - We have as a primary interface on i386's only. It doesn't quite work on other arches since it doesn't include . - We implement as a link to to get the MD and implementation details right and the MI details wrong. Perhaps the broken ports include this and not . Then they would be less broken. - We also have as a primary interface which works on all arches, and our man pages say to use this. - Applications can easily shoot there feet off by stepping into this header tangle in any place except the one that is actually docuemented under FreeBSD. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 1: 2:45 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBFCF37B401; Mon, 13 Jan 2003 01:02:44 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 958C843F13; Mon, 13 Jan 2003 01:02:43 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA11085; Mon, 13 Jan 2003 20:02:36 +1100 Date: Mon, 13 Jan 2003 20:03:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <3E2223F4.5554718E@mindspring.com> Message-ID: <20030113200018.P11690-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 12 Jan 2003, Terry Lambert wrote: > This patch also affects the IA64 and Alpha, as well as just the SPARC. > > It took a lot of discussion, but it seems to me that the problem is > that the prototypes in scope aren't in scope when the wrong include > file is included. Right. It is mainly an application bug like I said. The prototypes also aren't in scope when is included, and the fix is not to add them to . Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 2: 6:16 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCB137B401; Mon, 13 Jan 2003 02:06:13 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC1143F18; Mon, 13 Jan 2003 02:06:09 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DA5v2G040648; Mon, 13 Jan 2003 02:05:58 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DA63Cv003606; Mon, 13 Jan 2003 02:06:04 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0DA5wTq003605; Mon, 13 Jan 2003 02:05:58 -0800 (PST) (envelope-from marcel) Date: Mon, 13 Jan 2003 02:05:58 -0800 From: Marcel Moolenaar To: Bruce Evans Cc: Terry Lambert , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030113190710.I11541-100000@gamplex.bde.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 13, 2003 at 07:59:30PM +1100, Bruce Evans wrote: > > > The synopsis section of our manpage clearly states the inclusion > > of . That header file includes a machine dependent > > counterpart . On alpha, ia64 and sparc64 > > is empty with the exception of the > > inclusion of . > > > > Hence, I would like to see the prototypes and/or implementation > > in . > > The prototypes are machine-independent, so they are correctly placed > in . Agreed in principle, not in practice. > This has the technical problem that it is difficult > to implement declared functions as inlines (*), so we use an ugly > i386 ifdef in to prevent them being declared. This seems > least evil since inlining them doesn't seem to be useful and the > wart only affects i386's, and these functions should be obsoleted > by the C99 functions as soon as possible. This part is what makes me opt for moving the prototypes to the MD header. These functions are trivial most of the time that inlining them makes sense. I don't see why other platforms can't or won't inline in the future. What about signaling the MI header about the existence (or non- existence) of inline functions and/or macros in the MD header so that the MI header can optionally provide the prototypes? This can be done by having the MD header define (or undefine) some macro (or set of macros). Also, it appears to me that we always have to provide non-inlined versions in libc for when inlining is disabled. See ctype.h. I may misinterpret the comment though... > > Since on i386 > > also includes , we should be able to move > > the implementation on i386 to as well. If > > possible, I'd like to see retired > > unless there's a compelling reason to keep it... > > There is no good reason for these to be separate, but they may be > required for compatibility. It appears to be mostly a FreeBSD-ism in its current form. Both NetBSD and OpenBSD resist having it. Maybe the newer platforms should just remove it before it grows code... Anyone object to remove the header on at least sparc64 and ia64? (powerpc doesn't have it -- keep it that way :-) Am I right when I say that removing floatingpoint.h (both the MD file and the MI link) will fix the port, independent of how we shape ieeefp.h? > - We implement as a link to > to get the MD and implementation details right and the MI details wrong. > Perhaps the broken ports include this and not . > Then they would be less broken. Some configure scripts may check for for compatibility with SunOS/Solaris. I doubt they will check In summary: I like Terry's second patch but am sensitive to having the MI prototypes in as well as allowing inlining. What about something like the following to keep the prototypes in , but still allow inlining (in combination with Terrys patch): Index: ieeefp.h =================================================================== RCS file: /home/ncvs/src/include/ieeefp.h,v retrieving revision 1.6 diff -u -r1.6 ieeefp.h --- ieeefp.h 23 Mar 2002 17:24:53 -0000 1.6 +++ ieeefp.h 13 Jan 2003 09:59:08 -0000 @@ -12,9 +12,9 @@ #include #include -#ifdef __i386__ -#include -#else /* !__i386__ */ +#if !defined(_IEEEFP_INLINED_) __BEGIN_DECLS extern fp_rnd_t fpgetround(void); extern fp_rnd_t fpsetround(fp_rnd_t); @@ -23,6 +23,6 @@ extern fp_except_t fpgetsticky(void); extern fp_except_t fpsetsticky(fp_except_t); __END_DECLS -#endif /* __i386__ */ +#endif /* !_IEEEFP_INLINED */ #endif /* _IEEEFP_H_ */ -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 3:21:58 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2691137B401; Mon, 13 Jan 2003 03:21:54 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B99D743ED8; Mon, 13 Jan 2003 03:21:52 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA22763; Mon, 13 Jan 2003 22:21:23 +1100 Date: Mon, 13 Jan 2003 22:21:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: Terry Lambert , Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> Message-ID: <20030113211536.E11945-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 13 Jan 2003, Marcel Moolenaar wrote: > On Mon, Jan 13, 2003 at 07:59:30PM +1100, Bruce Evans wrote: > > > > > The synopsis section of our manpage clearly states the inclusion > > > of . That header file includes a machine dependent > > > counterpart . On alpha, ia64 and sparc64 > > > is empty with the exception of the > > > inclusion of . > > > > > > Hence, I would like to see the prototypes and/or implementation > > > in . > > > > The prototypes are machine-independent, so they are correctly placed > > in . > > Agreed in principle, not in practice. > > > This has the technical problem that it is difficult > > to implement declared functions as inlines (*), so we use an ugly > > i386 ifdef in to prevent them being declared. This seems > > least evil since inlining them doesn't seem to be useful and the > > wart only affects i386's, and these functions should be obsoleted > > by the C99 functions as soon as possible. > > This part is what makes me opt for moving the prototypes to the > MD header. These functions are trivial most of the time that > inlining them makes sense. I don't see why other platforms can't > or won't inline in the future. Hand-inlining things rarely makes sense, especially for little-used compatibility-cruft functions like these. A technical reason for not inlining some of them is that they may need to interact with signal handling. We currently avoid most signal-handling problems related to changing the FP environment by switching the critical part of the environment in setjmp/longjmp, at least on i386's, but C99 seems to forbid this. I think the functions that change the FP environment need to save their setting somehwere so that longjmp() can restore the default FP environment (not necessarily the one when setjmp() was called). I don't know how to do this properly reentrantly. > What about signaling the MI header about the existence (or non- > existence) of inline functions and/or macros in the MD header so > that the MI header can optionally provide the prototypes? This > can be done by having the MD header define (or undefine) some > macro (or set of macros). I'd like to have a simple general way to do this, but don't care about it for these functions. > Also, it appears to me that we always have to provide non-inlined > versions in libc for when inlining is disabled. See ctype.h. > I may misinterpret the comment though... Non-inline versions are needed for at least calling functions through function pointers if this is supported, and C requires it to be supported for most functions including the ctype 1's. This requirement causes some of the implementation complications in . > > > Since on i386 > > > also includes , we should be able to move > > > the implementation on i386 to as well. If > > > possible, I'd like to see retired > > > unless there's a compelling reason to keep it... > > > > There is no good reason for these to be separate, but they may be > > required for compatibility. > > It appears to be mostly a FreeBSD-ism in its current form. Both > NetBSD and OpenBSD resist having it. Maybe the newer platforms > should just remove it before it grows code... That makes sense. floatingpoint.h was added to FreeBSD in 1993/08 (before FreeBSD-1.0R) and never picked up by OtherBSD. ieeefp.h in NetBSD seems to date from 1995/04. ieeefp.h was added to FreeBSD at the same time as floatingpoint.h. It was originally in a Sun- compatible place (), but had mostly-wrong contents (i386 bits). may be MD in SunOS but it isn't in BSD. This was "fixed" in FreeBSD-2 by moving it to . > Anyone object to remove the header on at least sparc64 and ia64? > (powerpc doesn't have it -- keep it that way :-) Not me. Then sparc64 and ia64 will give even better early warnings of broken ports :-). > Am I right when I say that removing floatingpoint.h (both the MD > file and the MI link) will fix the port, independent of how we > shape ieeefp.h? > > > - We implement as a link to > > to get the MD and implementation details right and the MI details wrong. > > Perhaps the broken ports include this and not . > > Then they would be less broken. > > Some configure scripts may check for for compatibility > with SunOS/Solaris. I doubt they will check That's a good reason not to have it. Hopefully its nonexistence in OtherBSD has resulted in its use being correctly configured. However, I suspect most uses in ports are in hard-coded FreeBSD patches. This is confirmed by grepping for floatingpoint\.h and ieeefp\.h in ncvs/ports. > In summary: I like Terry's second patch but am sensitive to having > the MI prototypes in as well as allowing inlining. > What about something like the following to keep the prototypes in > , but still allow inlining (in combination with Terrys > patch): > > Index: ieeefp.h > =================================================================== > RCS file: /home/ncvs/src/include/ieeefp.h,v > retrieving revision 1.6 > diff -u -r1.6 ieeefp.h > --- ieeefp.h 23 Mar 2002 17:24:53 -0000 1.6 > +++ ieeefp.h 13 Jan 2003 09:59:08 -0000 > @@ -12,9 +12,9 @@ > #include > #include > > -#ifdef __i386__ > -#include > -#else /* !__i386__ */ > +#if !defined(_IEEEFP_INLINED_) > __BEGIN_DECLS > extern fp_rnd_t fpgetround(void); > extern fp_rnd_t fpsetround(fp_rnd_t); > @@ -23,6 +23,6 @@ > extern fp_except_t fpgetsticky(void); > extern fp_except_t fpsetsticky(fp_except_t); > __END_DECLS > -#endif /* __i386__ */ > +#endif /* !_IEEEFP_INLINED */ > > #endif /* _IEEEFP_H_ */ I like this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 12:29:57 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C5A37B401; Mon, 13 Jan 2003 12:29:54 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBE5B43F13; Mon, 13 Jan 2003 12:29:53 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YB9d-0003r6-00; Mon, 13 Jan 2003 12:25:54 -0800 Message-ID: <3E23207F.A889A410@mindspring.com> Date: Mon, 13 Jan 2003 12:24:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Marcel Moolenaar , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113190710.I11541-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45a039d7f82adc896d8665b83b895603da8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > The prototypes are machine-independent, so they are correctly placed > in . This has the technical problem that it is difficult > to implement declared functions as inlines (*), so we use an ugly > i386 ifdef in to prevent them being declared. In fact, this is exactly the problem. The correct thing to do is to ensure that the values come into scope at the same level in all implementations. Effectively, this means that the #define's for the i386 version's inline references need to be at the same level as the prototype declarations. Where the prototype declatations take place is actually moot. > This seems least evil since inlining them doesn't seem to be useful > and the wart only affects i386's, and these functions should be > obsoleted by the C99 functions as soon as possible. I think it is better to fully adhere to an old standard than to partially adhere to a new one. FreeBSD was much better off, in terms of software portability, when it supported the full Draft 4 pthreads standard (both Jeremy Allison and I had a hand in the final work of making it conform), than it was when it was in partial conformance to the new standard. Whether or not inlining them should be ripped out in favor of real library routines, as in OpenBSD and NetBSD, is another matter, and, as far as I'm concerned, that's off the table for discussion at this point. I'm unwilling to change implementation this late in the game, only organization. No matter how you look at it, the code should be organized such that including the same header files, *whatever* they are, ends up with the same results on all flavors of FreeBSD. Riht now, that does not happen. Both of the proposed patches fix this. Another way of fixing this would be to move the #define's for the inline versions *up* into /usr/include/ieeefp.h, so that the scope comes from there. This is consistant with your suggestion here. There are two reason to not do this, at this point: 1) It will cause some ports to be broken; arguably, these ports *should* be broken. But when you complain about them, you are really complaining that the scope is visible to user programs directly, instead of forcing them to include the correct header files, instead. I think this complaint should be addressed in the compiler, and can be, by having a #pragma that maches the directory visible to the compiler, with the default being invisible, and the regular headers can set the #pragma, and third party code can break. I would argue that, whatever you do to address the complaint, however, you address it *later*. 2) This approach has the negative effect of leaving platform variant code in a system header file. This is, in my opinion, and incredibly broken thing to do, even if you ignore all other issues. If you are dead set on this approach, I can provide a patch that will move the i386 #define's from up into ; but I believe this is bad design at its worst. > > Since on i386 > > also includes , we should be able to move > > the implementation on i386 to as well. If > > possible, I'd like to see retired > > unless there's a compelling reason to keep it... > > There is no good reason for these to be separate, but they may be > required for compatibility. IIRC, their names and interfaces were > copied from some system (Sun) that had them, but they were slightly > misplaced ( is a BSDism AFAIK so other systems couldn't have > anything there)... According to google, was in > /usr/include in SunOS in 1992 (we link it there), and it seems to > be the primary interface (Sun apparently had ieeefp.h in then, > but non-BSD hits on it are not as common. I agree that floatingpoint.h is probably something that should gracefully fall into compatability, in terms of a message that says "deprecated; include XXX instead"; FreeBSD already has a number of these. But in any case, this is not really a functional issue, and I really don't care about it. 8-). > - Applications can easily shoot there feet off by stepping into this header > tangle in any place except the one that is actually docuemented under > FreeBSD. This is the case as it is today. The patches I have proposed, both reattach the feet of a number of application in ports, based on them already having stepped in this mine field. I think it's not reasonable to believe that you can make people rewrite all the old code in the world to conform to new standards (e.g. C99, etc.). Basically, this means to me that a successful standard is not one which tries to change how things are done, but instead permits legacy code to continue to function. This *also* argues for pushing the declaration scope for these things down, instead of pulling them up into the (supposedly) machine independent headers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 12:31:31 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DDE137B401; Mon, 13 Jan 2003 12:31:30 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id E48D143F13; Mon, 13 Jan 2003 12:31:29 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YBF0-0004Mb-00; Mon, 13 Jan 2003 12:31:27 -0800 Message-ID: <3E2321CF.A5835FCD@mindspring.com> Date: Mon, 13 Jan 2003 12:30:07 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113200018.P11690-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45a039d7f82adc89610f639834c116301548b785378294e88350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > On Sun, 12 Jan 2003, Terry Lambert wrote: > > This patch also affects the IA64 and Alpha, as well as just the SPARC. > > > > It took a lot of discussion, but it seems to me that the problem is > > that the prototypes in scope aren't in scope when the wrong include > > file is included. > > Right. It is mainly an application bug like I said. The prototypes > also aren't in scope when is included, and the fix is not > to add them to . I really disagree. A legacy application *can't* be said to be buggy. If someone cuts you off, and you get into an accident, it was the fault of the person who cut you off, not you. If a legacy application stops working because a system changes, it's the fault of the system doing the changing, not the fault of the people back in 1984 who didn't know ANSI was going to bung-up the C language until their application no longer worked. There has to be some allowance for the continuity of code; it can't just be orphaned instantaneously, without some warning from the system vendor. Say we took your approach, and moved the #define's for the inlines up into , exposing platform dependencies in a (supposedly) platform independent header file. How many ports would break? All of the ports that won't compile on Alpha or SPARC or IA64 today, will end up not compiling on i386, either. That's not an acceptable thing, right before the 5.0 release. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 12:43:52 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45DB037B401; Mon, 13 Jan 2003 12:43:50 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78A643F43; Mon, 13 Jan 2003 12:43:49 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YBQs-0005TF-00; Mon, 13 Jan 2003 12:43:43 -0800 Message-ID: <3E2324B0.585FD417@mindspring.com> Date: Mon, 13 Jan 2003 12:42:24 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e1a62e94264aa9b04a7bb99bada3d2853ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > This part is what makes me opt for moving the prototypes to the > MD header. These functions are trivial most of the time that > inlining them makes sense. I don't see why other platforms can't > or won't inline in the future. I think so, too, but it depends on the hardware. > What about signaling the MI header about the existence (or non- > existence) of inline functions and/or macros in the MD header so > that the MI header can optionally provide the prototypes? This > can be done by having the MD header define (or undefine) some > macro (or set of macros). This would be a Bad Thing(tm). Specifically, it would throw some namespace pollution into the implementation space, which is not something that should be permitted, I think. > Also, it appears to me that we always have to provide non-inlined > versions in libc for when inlining is disabled. See ctype.h. > I may misinterpret the comment though... No, this is true. There is also a problem with the "GNUC" tests in the inilining definitions, particularly, since there is a cdefs.h in scope, and there's a portable way to get rid of the "GNUC"-isms. > Am I right when I say that removing floatingpoint.h (both the MD > file and the MI link) will fix the port, independent of how we > shape ieeefp.h? IMO, no. The port will remain broken. Kris is the person to ask on this, actually, since he's the one who reported the problem, initially. > > - We implement as a link to > > to get the MD and implementation details right and the MI details wrong. > > Perhaps the broken ports include this and not . > > Then they would be less broken. > > Some configure scripts may check for for compatibility > with SunOS/Solaris. I doubt they will check And here's the reason why. The SPARC platform for FreeBSD will need to be sensitive to the fact that people will port from SPARC running some other OS to SPARC running FreeBSD. The most likely source of ported code in this case is SPARC running Solaris, which has the header file in question. > In summary: I like Terry's second patch but am sensitive to having > the MI prototypes in as well as allowing inlining. > What about something like the following to keep the prototypes in > , but still allow inlining (in combination with Terrys > patch): This is a patch post-application of my patch; you are missing the floating point function prototypes in the non-inlined case. 8-). But it's fixable. I personally worry about putting stuff into the namespace that people might then key off of when doing ports or other work, in order to let them use FreeBSD-isms. I'm particularly sensitive on this point, because I personally abused the PTHREAD_MUTEX_INITIALIZER to distinguish between draft 4 and standard implementations, and then that was the first thing that they added going from draft 4 to standard, without implementing all of the rest of the standard first. 8-(. This broke a lot of pthreaded code that I worked on and threw the patches back to the maintainers, including MySQL, OpenLDAP, ACAP, and anything statically declaring the mutex-using classes that implement using threads in the C++ STL code out of MCSCA. It was a real mess when FreeBSD made that change. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 12:45: 5 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA79B37B401; Mon, 13 Jan 2003 12:45:03 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFAB43F13; Mon, 13 Jan 2003 12:45:02 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DKiu2G043503; Mon, 13 Jan 2003 12:44:57 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DKj6mY000953; Mon, 13 Jan 2003 12:45:06 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0DKj6Hs000952; Mon, 13 Jan 2003 12:45:06 -0800 (PST) (envelope-from marcel) Date: Mon, 13 Jan 2003 12:45:05 -0800 From: Marcel Moolenaar To: Bruce Evans Cc: Terry Lambert , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113204505.GA798@dhcp01.pn.xcllnt.net> References: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <20030113211536.E11945-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030113211536.E11945-100000@gamplex.bde.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 13, 2003 at 10:21:59PM +1100, Bruce Evans wrote: > > > > This part is what makes me opt for moving the prototypes to the > > MD header. These functions are trivial most of the time that > > inlining them makes sense. I don't see why other platforms can't > > or won't inline in the future. > > Hand-inlining things rarely makes sense, especially for little-used > compatibility-cruft functions like these. Aahh.. But by hand-inlining compatibility cruft, you remove them from the ABI! You only have them in the API, which is the lesser evil of the two when you want to remove the compatibility cruft completely. > A technical reason for not inlining some of them is that they may need > to interact with signal handling. I don't see how this is related. The only advantage of not inlining is the ability to declare the functions as weak so that they can be overridden. In all other cases it's just an implementation detail that should not affect the functionality. > We currently avoid most signal-handling > problems related to changing the FP environment by switching the critical > part of the environment in setjmp/longjmp, at least on i386's, but C99 > seems to forbid this. I think the functions that change the FP environment > need to save their setting somehwere so that longjmp() can restore the > default FP environment (not necessarily the one when setjmp() was called). > I don't know how to do this properly reentrantly. On ia64 the FP environment is callee saved and thus put in jmpbuf. The general modus operandi seems that functions either use the settings as inherited, or otherwise explicitly set them. This also applies to signal handlers. Thus when the FP environment is changed at function entry, the only action required is to restore the FP environment at function exit. > > Also, it appears to me that we always have to provide non-inlined > > versions in libc for when inlining is disabled. See ctype.h. > > I may misinterpret the comment though... > > Non-inline versions are needed for at least calling functions through > function pointers if this is supported, and C requires it to be supported > for most functions including the ctype 1's. This requirement causes > some of the implementation complications in . I see. Using static inline functions rather than macros should mostly solve this. Function pointer comparison will not work though, but I don't know if it has to. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 13: 6:35 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A618437B401; Mon, 13 Jan 2003 13:06:34 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5BAF43F18; Mon, 13 Jan 2003 13:06:33 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DL6X2G043598; Mon, 13 Jan 2003 13:06:33 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DL6gmY001003; Mon, 13 Jan 2003 13:06:42 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0DL6gog001002; Mon, 13 Jan 2003 13:06:42 -0800 (PST) (envelope-from marcel) Date: Mon, 13 Jan 2003 13:06:42 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113210642.GB798@dhcp01.pn.xcllnt.net> References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <3E2324B0.585FD417@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E2324B0.585FD417@mindspring.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 13, 2003 at 12:42:24PM -0800, Terry Lambert wrote: > > > > Some configure scripts may check for for compatibility > > with SunOS/Solaris. I doubt they will check > > And here's the reason why. The SPARC platform for FreeBSD will need > to be sensitive to the fact that people will port from SPARC running > some other OS to SPARC running FreeBSD. The most likely source of > ported code in this case is SPARC running Solaris, which has the > header file in question. Ok. I'm now going to throw (an interpretation of) your own words into the mix and let you decide how you want to prioritize them. You said that FreeBSD on different platforms should not cause variation in the API or ABI. If having on sparc64 makes sense, then having all kinds of proprietary OS quirks on platforms with proprietary OSes also makes sense. This contradicts with the uniformity across platforms. Either we present the FreeBSD ABI and API uniformly across the supported platforms or we provide an uniform subset and allow deviation for ease of porting but then also have to accept porting across different FreeBSD implementations. I favor an uniform ABI/API if only to keep our ports meisters sane, but also because there's just too much difference that the existence or non-existence of will not make a big difference in porting SunOS/Solaris code. This is gut-feeling -- use salt... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 13:34:24 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B354837B401; Mon, 13 Jan 2003 13:34:21 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B8643F65; Mon, 13 Jan 2003 13:34:21 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YCA4-0007eT-00; Mon, 13 Jan 2003 13:30:25 -0800 Message-ID: <3E232F9C.D323FF99@mindspring.com> Date: Mon, 13 Jan 2003 13:29:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <3E2324B0.585FD417@mindspring.com> <20030113210642.GB798@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a405c081f6ab1e353bb0283fdc7e23389b666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > Ok. I'm now going to throw (an interpretation of) your own words into > the mix and let you decide how you want to prioritize them. I *live* to be hung on my own petard... go for it! 8-). > You said that FreeBSD on different platforms should not cause variation in the > API or ABI. If having on sparc64 makes sense, then > having all kinds of proprietary OS quirks on platforms with proprietary > OSes also makes sense. This contradicts with the uniformity across > platforms. Either we present the FreeBSD ABI and API uniformly across > the supported platforms or we provide an uniform subset and allow > deviation for ease of porting but then also have to accept porting > across different FreeBSD implementations. OK. I understand the discrepancy here. I'm going to point out up front that /usr/include/floatingpoint.h is actually a symlink to /usr/include/machine/floatingpoint.h, so this argument doesn't apply in this case. But that doesn't invalidate your argument, so it still needs to be addressed. The answer is that there should be no variation among platforms at the API level, inasmuch as it's possible to not vary between them. Having on SPARC makes sense, in terms of being able to support a *legacy* interface for *legacy* code that needs it. Both uses of the word "legacy" are important here. I think that the header file should complain, during compilation, when it is used, e.g.: #warning "this file includes which is obsoleted, use instead" This doesn't contradict uniformity across platforms, per se, since the interface is deprecated. That said, it should be uniformly deprecated across platforms; here's why: When someone ports code from Solaris SPARC to FreeBSD SPARC, the resulting port should compile on FreeBSD Alpha, FreeBS IA64, and FreeBSD i386, without modifications, so long as the software uses published interfaces (any file in /usr/include, but not in machine/ or sys/). This is about setting up rules that result in more FreeBSD software for all versions of FreeBSD, not just for one, and not to discourage porting to FreeBSD. I don't think it's acceptable to have porting differences across implementations, if it can be helped. It sets a bad precedent. > I favor an uniform ABI/API if only to keep our ports meisters sane, I don't really care if they are sane, but I'd prefer it if they don't go postal on me. 8-) 8-). > but also because there's just too much difference that the existence > or non-existence of will not make a big difference > in porting SunOS/Solaris code. This is gut-feeling -- use salt... It is, I think, an interface that can be deprecatedm but not removed, at this point. Removal can wait for one minor release following the insertion of a compilation warning message (or however long it is we are going to have to keep living with it, because of the volume of legacy software that needs it (i.e. as long as we have to live with "values.h", I think, and as long as we lived with direct.h/dirent.h; I notice that direct.h is finally gone, now...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 13:41:17 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B48CE37B401; Mon, 13 Jan 2003 13:41:15 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0160F43EB2; Mon, 13 Jan 2003 13:41:15 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DLfE2G043771; Mon, 13 Jan 2003 13:41:14 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0DLfNmY001079; Mon, 13 Jan 2003 13:41:23 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0DLfNUe001078; Mon, 13 Jan 2003 13:41:23 -0800 (PST) (envelope-from marcel) Date: Mon, 13 Jan 2003 13:41:23 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113214122.GD798@dhcp01.pn.xcllnt.net> References: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <20030113211536.E11945-100000@gamplex.bde.org> <20030113204505.GA798@dhcp01.pn.xcllnt.net> <3E232BD8.234FA1B4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E232BD8.234FA1B4@mindspring.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 13, 2003 at 01:12:56PM -0800, Terry Lambert wrote: > > To my mind, this is a problem to address *after* the 5.0 release; > one hopes that the ports compilation issues will be addressed > *before* the 5.0 release. We tag in 2 days. Forget about 5.0-R. The chance of breaking more than that we fix is too high. This needs a couple of bento runs before we can see the impact and flush out the nits. \begin{image} assume there's some ascii art here that shows a traffic sign with the heads of our REs and the following text: No rushing in the RC zone \end{image} :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 13:46: 7 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3088437B401 for ; Mon, 13 Jan 2003 13:46:07 -0800 (PST) Received: from manual-override.net (manual-override.net [65.42.236.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BBBF43F18 for ; Mon, 13 Jan 2003 13:46:06 -0800 (PST) (envelope-from chris@manual-override.net) Received: from manual-override.net (localhost [127.0.0.1]) by manual-override.net (8.12.7/8.7.1) with ESMTP id h0DLi9mj001138 for ; Mon, 13 Jan 2003 16:44:09 -0500 (EST) Chris-is-the-man: Yes Received: from localhost (chris@localhost) by manual-override.net (8.12.7/8.12.6/Submit) with ESMTP id h0DLi9QG001135 for ; Mon, 13 Jan 2003 16:44:09 -0500 (EST) Date: Mon, 13 Jan 2003 16:44:09 -0500 (EST) From: Chris Orr To: sparc@freebsd.org Subject: netra t1 gem driver Message-ID: <20030113164352.M1127-100000@manual-override.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am currently running 5.0-release on a netra t1 ac200. These boxes have 2 ethernet ports. (they work in solaris as eri0 and eri1) I can only get 1 of the ethernet ports to work (gem0) in freebsd. Can anyone point me in the right direction on getting the other port to work? Let me know if you need any more info. Thanks in advance! -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 14: 0:12 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E2537B401; Mon, 13 Jan 2003 14:00:10 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2225943F5B; Mon, 13 Jan 2003 14:00:07 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0DLISH05396; Mon, 13 Jan 2003 13:18:28 -0800 (PST) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YBuY-0005Pr-00; Mon, 13 Jan 2003 13:14:23 -0800 Message-ID: <3E232BD8.234FA1B4@mindspring.com> Date: Mon, 13 Jan 2003 13:12:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <20030113211536.E11945-100000@gamplex.bde.org> <20030113204505.GA798@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41e89a9ed863942cc3974e799c3f84c3193caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > > A technical reason for not inlining some of them is that they may need > > to interact with signal handling. > > I don't see how this is related. The only advantage of not inlining > is the ability to declare the functions as weak so that they can be > overridden. In all other cases it's just an implementation detail > that should not affect the functionality. This does not apply in this case, since the inlined function is not itself making a system call that could be interrupted by a signal. This argument only applies in the case where the inlined function makes a system call, and the default behaviour is not SA_RESTART. > > Non-inline versions are needed for at least calling functions through > > function pointers if this is supported, and C requires it to be supported > > for most functions including the ctype 1's. This requirement causes > > some of the implementation complications in . > > I see. Using static inline functions rather than macros should mostly > solve this. Function pointer comparison will not work though, but I > don't know if it has to. This is a valid argument, but we are not really here to fix the lack of an i386 prototype in scope in the case that inilining is disabled, any more than we are here to fix the fact that everything goes to hell if the #ifdef for "GNUC" fails because another compiler is being used. The prototypes are out of scope in the non-inline case, but the #define's are not. I don't know the correct compiler voodoo to make the #define's go away when inlining is disabled, the way the inline functions themselves do (maybe Bruce can help out here). The other issue is that there are not i386 implementations for these functions in /usr/src/lib/libc/i386/gen, at this point, so you would either need to pull the code in from NetBSD/OpenBSD, or you would need to have a .c file that forces the inlining with stub instances, including the machine dependent header file. To my mind, this is a problem to address *after* the 5.0 release; one hopes that the ports compilation issues will be addressed *before* the 5.0 release. One also hopes that the *way* they are addressed will be to make the ports *work* on IA64, SPARC, and Alpha, rather than making them *break* on i386. Consistent behaviour is not a good thing, if it's consistently *bad*... 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 14:21:18 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35FE537B401 for ; Mon, 13 Jan 2003 14:21:12 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E656743F3F for ; Mon, 13 Jan 2003 14:21:10 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 23346 invoked by uid 0); 13 Jan 2003 22:21:09 -0000 Received: from p508e4d64.dip.t-dialin.net (HELO galatea.local) (80.142.77.100) by mail.gmx.net (mp019-rz3) with SMTP; 13 Jan 2003 22:21:09 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18YCyk-00012y-00; Mon, 13 Jan 2003 23:22:46 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0DMMfkf004027; Mon, 13 Jan 2003 23:22:41 +0100 (CET) Date: Mon, 13 Jan 2003 23:22:41 +0100 From: Thomas Moestl To: Roderick van Domburg Cc: freebsd-sparc64@FreeBSD.ORG Subject: Re: panic: trap: fast data access mmu miss Message-ID: <20030113222241.GB278@crow.dom2ip.de> Mail-Followup-To: Roderick van Domburg , freebsd-sparc64@FreeBSD.ORG References: <20030113004111.GD278@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, 2003/01/13 at 04:03:14 +0100, Roderick van Domburg wrote: > > Oh, you have an isp in that box? In that case this is expected, please > > remove this line: > > > > printf("iommu_dvma_valloc: out of DVMA space.\n"); > > > > from sys/sparc64/sparc64/iommu.c and try again. > > Okay, did that. Unfortunately It doesn't mention much more than it did > before: > > sym0: <875> port 0x2000-0x20ff mem 0x410a000-0x410afff, 0x4108000-0x41080ff > irq 32 at device 3.1 on pci0 > sym0: No NVRAM, ID 7, Fast-20, SE, parity checking > sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff, 0x410c000-0x410c0ff > irq 38 at device 3.1 on pci0 > sym1: No NVRAM, ID 7, Fast-20, SE, parity checking > __sym_calloc2: failed to allocate SCRIPTB0[1308] > device_probe_and_attach: sym1 returned 6 > [cut] > Mounting root from ufs:/dev/da0a > setrootbyname: failed > ffs_mountroot: can't find rootvp > Root mount failed: 6 Damn. OK, here's another diff, with yet more diagnostics and an increased IOTSB size. If this makes the problem go away, please supply a complete dmesg. - Thomas P.S: I'm sorry that this is taking so many iterations to diagnose; debugging-over-mail sucks :) -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iommu-errbd.diff" Index: sparc64/sparc64/iommu.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v retrieving revision 1.14 diff -u -r1.14 iommu.c --- sparc64/sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14 +++ sparc64/sparc64/iommu.c 13 Jan 2003 22:01:55 -0000 @@ -517,10 +517,13 @@ { struct resource *res; struct bus_dmamap_res *bdr; - bus_size_t align, bound, sgsize; + bus_size_t align, sgsize; - if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) + if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) { + printf("iommu_dvma_valloc: res descriptor allocation " + "failed.\n"); return (EAGAIN); + } /* * If a boundary is specified, a map cannot be larger than it; however * we do not clip currently, as that does not play well with the lazy @@ -531,9 +534,8 @@ sgsize = round_io_page(size) >> IO_PAGE_SHIFT; if (t->dt_boundary > 0 && t->dt_boundary < IO_PAGE_SIZE) panic("iommu_dvmamap_load: illegal boundary specified"); - bound = ulmax(t->dt_boundary >> IO_PAGE_SHIFT, 1); res = rman_reserve_resource_bound(&iommu_dvma_rman, 0L, - t->dt_lowaddr, sgsize, bound >> IO_PAGE_SHIFT, + t->dt_lowaddr, sgsize, t->dt_boundary >> IO_PAGE_SHIFT, RF_ACTIVE | rman_make_alignment_flags(align), NULL); if (res == NULL) return (ENOMEM); @@ -766,8 +768,10 @@ pmap_t pmap = NULL; KASSERT(buflen != 0, ("iommu_dvmamap_load_buffer: buflen == 0!")); - if (buflen > dt->dt_maxsize) + if (buflen > dt->dt_maxsize) { + printf("iommu_dvmamap_load_buffer: buffer too long.\n"); return (EINVAL); + } if (td != NULL) pmap = vmspace_pmap(td->td_proc->p_vmspace); @@ -813,6 +817,8 @@ sgcnt++; if (sgcnt >= dt->dt_nsegments || sgcnt >= BUS_DMAMAP_NSEGS) { + printf("iommu_dvmamap_load_buffer: too many " + "segments.\n"); error = EFBIG; break; } @@ -860,7 +866,7 @@ if (error != 0) { iommu_dvmamap_vunload(is, map); - (*cb)(cba, NULL, 0, error); + (*cb)(cba, sgs, 0, error); } else { /* Move the map to the end of the LRU queue. */ iommu_map_insq(map); Index: sparc64/pci/psycho.c =================================================================== RCS file: /ncvs/src/sys/sparc64/pci/psycho.c,v retrieving revision 1.25 diff -u -r1.25 psycho.c --- sparc64/pci/psycho.c 6 Jan 2003 21:59:53 -0000 1.25 +++ sparc64/pci/psycho.c 13 Jan 2003 22:08:51 -0000 @@ -565,7 +565,7 @@ sc->sc_is->is_sb[1] = 0; if (OF_getproplen(sc->sc_node, "no-streaming-cache") < 0) sc->sc_is->is_sb[0] = sc->sc_pcictl + PCR_STRBUF; - psycho_iommu_init(sc, 2); + psycho_iommu_init(sc, 4); } else { /* Just copy IOMMU state, config tag and address */ sc->sc_is = osc->sc_is; Index: dev/sym/sym_hipd.c =================================================================== RCS file: /ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.38 diff -u -r1.38 sym_hipd.c --- dev/sym/sym_hipd.c 1 Jan 2003 18:48:52 -0000 1.38 +++ dev/sym/sym_hipd.c 13 Jan 2003 22:16:56 -0000 @@ -712,7 +712,10 @@ { bus_addr_t *baddr; baddr = (bus_addr_t *)arg; - *baddr = segs->ds_addr; + if (error != 0) + *baddr = 0; + else + *baddr = segs->ds_addr; } static m_addr_t ___dma_getp(m_pool_s *mp) @@ -720,16 +723,22 @@ m_vtob_s *vbp; void *vaddr = 0; bus_addr_t baddr = 0; + int err; vbp = __sym_calloc(&mp0, sizeof(*vbp), "VTOB"); - if (!vbp) + if (!vbp) { + printf("___dma_getp: malloc failed\n"); goto out_err; + } if (bus_dmamem_alloc(mp->dmat, &vaddr, BUS_DMA_NOWAIT, &vbp->dmamap)) goto out_err; - bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr, - MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0); + if ((err = bus_dmamap_load(mp->dmat, vbp->dmamap, vaddr, + MEMO_CLUSTER_SIZE, getbaddrcb, &baddr, 0))) { + printf("bus_dmamap_load: error %d\n", err); + goto out_err; + } if (baddr) { int hc = VTOB_HASH_CODE(vaddr); vbp->vaddr = (m_addr_t) vaddr; @@ -744,8 +753,6 @@ bus_dmamap_unload(mp->dmat, vbp->dmamap); if (vaddr) bus_dmamem_free(mp->dmat, vaddr, vbp->dmamap); - if (vbp->dmamap) - bus_dmamap_destroy(mp->dmat, vbp->dmamap); if (vbp) __sym_mfree(&mp0, vbp, sizeof(*vbp), "VTOB"); return 0; Index: kern/subr_rman.c =================================================================== RCS file: /ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.27 diff -u -r1.27 subr_rman.c --- kern/subr_rman.c 27 Nov 2002 03:55:22 -0000 1.27 +++ kern/subr_rman.c 12 Jan 2003 22:45:20 -0000 @@ -229,7 +229,7 @@ */ do { rstart = (rstart + amask) & ~amask; - if (((rstart ^ (rstart + count)) & bmask) != 0) + if (((rstart ^ (rstart + count - 1)) & bmask) != 0) rstart += bound - (rstart & ~bmask); } while ((rstart & amask) != 0 && rstart < end && rstart < s->r_end); @@ -263,8 +263,11 @@ * two new allocations; the second requires but one. */ rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); - if (rv == 0) + if (rv == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); goto out; + } rv->r_start = rstart; rv->r_end = rstart + count - 1; rv->r_flags = flags | RF_ALLOCATED; @@ -282,6 +285,8 @@ */ r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO); if (r == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); free(rv, M_RMAN); rv = 0; goto out; --AqsLC8rIMeq19msA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 15: 8:19 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E7F37B401; Mon, 13 Jan 2003 15:08:17 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECCCA43E4A; Mon, 13 Jan 2003 15:08:15 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA07448; Tue, 14 Jan 2003 10:04:51 +1100 Date: Tue, 14 Jan 2003 10:05:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <3E2321CF.A5835FCD@mindspring.com> Message-ID: <20030114095915.C14524-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 13 Jan 2003, Terry Lambert wrote: > Bruce Evans wrote: > > On Sun, 12 Jan 2003, Terry Lambert wrote: > > > This patch also affects the IA64 and Alpha, as well as just the SPARC. > > > > > > It took a lot of discussion, but it seems to me that the problem is > > > that the prototypes in scope aren't in scope when the wrong include > > > file is included. > > > > Right. It is mainly an application bug like I said. The prototypes > > also aren't in scope when is included, and the fix is not > > to add them to . > > I really disagree. A legacy application *can't* be said to be > buggy. Depends how legacy. > There has to be some allowance for the continuity of code; it > can't just be orphaned instantaneously, without some warning > from the system vendor. A warning was given here more than 4 years ago: % RCS file: /home/ncvs/src/include/ieeefp.h,v % Working file: ieeefp.h % head: 1.6 % ... % ---------------------------- % revision 1.1 % date: 1998/12/23 11:50:52; author: dfr; state: Exp; % branches: 1.1.2; % Implement fpsetmask() and other fp*() functions. Programs should use % % #include % % to access these functions instead of the i386 specific % % #include % % Submitted by: Hidetoshi Shimokawa % ---------------------------- > Say we took your approach, and moved the #define's for the inlines > up into , exposing platform dependencies in a (supposedly) > platform independent header file. How many ports would break? All Not my approach. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 15:28:27 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C886D37B401 for ; Mon, 13 Jan 2003 15:28:20 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4766943F1E for ; Mon, 13 Jan 2003 15:28:19 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0DNSBb10546; Tue, 14 Jan 2003 00:28:11 +0100 From: "Roderick van Domburg" To: "Thomas Moestl" Cc: "FreeBSD-sparc@FreeBSD. ORG" Subject: RE: panic: trap: fast data access mmu miss Date: Tue, 14 Jan 2003 00:28:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal In-Reply-To: X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Damn. OK, here's another diff, with yet more diagnostics and an > > increased IOTSB size. If this makes the problem go away, please supply > > a complete dmesg. > > It now errs: > > sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff, > 0x410c000-0x410c0ff > sym1: No NVRAM, ID 7, Fast-20, SE, parity checking > bus_dmamap_load: error 12 > __sym_calloc2: failed to allocate SCRIPTB0[1308] I've included the dmesg of the 5.0-RC1 kernel I'm now booting, in case it'd be of any help. By the way, in earlier dmesgs I have seen a couple of "stray vector interrupt 2029" messages, but I can't make out if they occur at system shutdown or kernel bootup. There was another peculiarity in the previous boot dmesg. Somewhere during the initialization of the SCSI disks, all sorts of garbage is printed. I've included it way down below. Hope it is of any help! ---8<-------------- Copyright (c) 1992-2002 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-RC1 #0: Sat Dec 7 11:02:43 GMT 2002 root@foo.baldwin.cx:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel.GENERIC/kernel" at 0xc08e6000. Preloaded mfs_root "/boot/mfsroot" at 0xc08e6198. Timecounter "tick" frequency 400000000 Hz cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) Model: SUNW,Ultra-250 Initializing GEOMetry subsystem md0: Preloaded image 4194304 bytes at 0xc04e3018 nexus0: nexus0: , type (unknown) (no driver attached) pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 7c0 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfe000000 to 0xffffffff device 0/1/0: latency timer 10 -> 82 pcib0: ofw_pci_init: no interrupt mapping found for 0/1/0 (preset 0) device 0/1/1: latency timer 10 -> 82 pcib0: ofw_pci_init: mapping intr for 0/1/1 to 33 (preset was 0) device 0/3/0: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/0 to 32 (preset was 0) device 0/3/1: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/1 to 38 (preset was 0) PCI-PCI bridge at 0/2/0: setting bus #s to 0/1/1 pcib0: ofw_pci_init: descending to subordinate PCI bus device 1/0/1: latency timer 10 -> 82 pcib0: ofw_pci_init: mapping intr for 1/0/1 to 17 (preset was 0) pcib0: ofw_pci_init: mapping intr for 1/4/0 to 16 (preset was 0) pci0: on pcib0 ebus0: revision 0x01 ebus0: mem 0x71000000-0x717fffff,0x70000000-0x70ffffff at device 1.0 on pci0 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a00 3,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) ebus0: addr 0x1400400000-0x140040007f irq 43 (no driver attached) ebus0: addr 0x1400200000-0x140020007f irq 35 (no driver attached) ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 33 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x1400300398-0x1400300399,0x14003043bc-0x14003043c b irq 33 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 80cfc01b ebus0: addr 0x1000000000-0x10000fffff,0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 37,40 (no driver attached) hme0: mem 0x4100000-0x4107fff irq 33 at device 1.1 on pci0 hme0: Ethernet address: 08:00:20:cf:c0:1b miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib1: at device 2.0 on pci0 pci1: on pcib1 isp0: port 0x1000-0x10ff mem 0x4008000-0x4008fff irq 16 at device 4.0 on pci1 isp0: invalid NVRAM header sym0: <875> port 0x2000-0x20ff mem 0x410a000-0x410afff,0x4108000-0x41080ff irq 32 at device 3.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x2400-0x24ff mem 0x410e000-0x410efff,0x410c000-0x410c0ff irq 38 at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pcib2: on nexus0 pcib2: Psycho, impl 0, version 4, ign 7c0 device 2/1/0: latency timer 64 -> 1584 pcib2: ofw_pci_init: mapping intr for 2/1/0 to 0 (preset was 0) pci2: on pcib2 pci2: at device 1.0 (no driver attached) nexus0: , type system-service-processor (no driver attached) nexus0: , type memory-controller (no driver attached) Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da2 at sym0 bus 0 target 9 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da1 at sym0 bus 0 target 8 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) Mounting root from ufs:/dev/da0a ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled ---8<-------------- Waiting 15 seconds for SCSI devices to settle cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da2 at sym0 bus 0 target 9 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers \M^?\M^?\M-x\^O2sp\M^?\M^?\M-x/\M-iB@\M^?\M^?\M-x/\M-iB\240nabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da1 at sym0 bus 0 target 8 lun 0 da1: \^Q\M-@ _\M-<\^A\M^A\M-@\^E\^?\M^@\^A\^B\^X\M-^\M-t\^V\M-=\240\M^?\M-~\M-o\M-`%g\^A\ M^?\M^?\M^?\M^?\M^?\M^?\M-`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M- ?h\M^?\M-~\M-o\M-`$\M^G\^A\^X\M-@\M^AZ\M^@\M-@)\M-?h\M-@#{x\M-@\M^A>\M-a\M-@ I4\^B\^A\^D\M^?\M-~\M-o\M-`\^A\^G\M-!? \M-@\M^AZ\M^@\M-@)\M-?h\^G\^G\^D$\M^L\M-U\M-&\M-@\^X\M-@\M^AZ\M^@\M-@)\M-?h\ M-@#\M-?H\M-@\M^A?\M-A\M-@\^Y\M-8\^X@\^A\^D \M-U\M-&\240\M^?\M^?\M-xB\M-d\M^?\M^?\M-x|\M^@\M^?\M^?\M-xw\M-B\M^?\M-~\M-o\ M-`&\^H\^A\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h\M^?\M^? \M-x{\^E\M^@\M-@\^Y\M^I\M^@\M-@\M^A@A\M-@\^L\M-~\240\M^?\M^?\M-x\^V\M-@)_\24 0\M-@\M^AI\M-E\^\\^D\^H\M^?\M^?\M-xff\M^@\M-@\M^A@\M-!\M-@\^Y\M-k4\M^?\M^?\M -xB\M-n\M^?\M^?\M-xC\^G\M^?\M-~\M-o\M-`&\^Q\^A\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^ ?\M-`\M-@\M^AZ\M^@\M-@)\M-?h%\M-o\^A\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\ M^AZ\M^@\M-@)\M-?h\M^?\M^?\M-xB\M-`\M^?\M^?\M-x{ \M^@\^D\^H\M^?\M^?\M-x]\^A\M^@\M^?\M^?\M-xB\M-d\^Z\M^?\M-~\M-o\M-`&5\^A\M-@& l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h%\M-x\^A\M-@&l`\M^?\M^? \M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h \^D\^E\^E\^D\^E \M^?\M-~\M-o\M-`\M^?\M-~\M-o\M-` &\^B\^A\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h\M^?\M^?\M- xb\M-B\240\M-@&l`\^P\M^?\M^?\M-x\M^K\M-HP\M^?\M^?\M-x{\^G\^A\^A\M^?\M^?\M-x{ \^G\M^@\M^?\M^?\M-x]a`\M^?\M^?\M-xB\M-n\M^?\M^?\M-xw\M-B\M^?\M^?\M-xB\M^A>\M ^?\M^?\M-x{\^D\M^@\M-@\M^ACA\M-@\^M\M-P \M-@\^G\^] \M-@\M^AK \M^?\M^?\M-xx@H \M^?\M^?\M-x]\^A\M-@\M^?\M^?\M-xB\M-d\M^?\M^?\M-xw\M-B\M^?\M^?\M-xB\M-d\M^?\ M-~\M-o\M-`%\M^^\^A\M^?\M-~\M-o\M-` \^A\^?\M-@%\\\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h\M^?\ M^?\M-xD\^B\^P \^A1\^E\M^?\M^?\M^?\M^?\^O\M^?\M^?\M-xw\M-B\M^?\M^?\M-x]\^A`\M^?\M^?\M-xB\M- d\^O\M^?\M^?\M-xw\M-B\^A\M^?\M-~\M-o\M-`%\M-2\^A\M^?\M-~\M-o\M-`%\M-D \M^?\M-~\M-o\M-` 2\^A\^? \M-@%\\\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h\M^?\M-~\M- o\M-`\M-@\^Y\M^A`\M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M^?\M-~\M-o\M-`&\^?\^A\ M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M^?\M^?\M-xrt\^A\M-2M\\\^A\^B\M-@\M^AE\M- 1\M-@\^L\M-f\M^\\M-@"\M^U\^P \^A2\M^?\M-~\M-o\M-`\^P\M-@\^Y\M^C \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M-t\^E\M^?\M^?\M^?\M^?\M^?\M-~\M-o\M-`&\M-1\^A\ M-@&l`\M^?\M^?\M^?\M^?\M^?\M^?\M-`\M-@\M^AZ\M^@\M-@)\M-?h\M-@"\M^I\M^H \M^?\M^?\M-xv\M^?\^P \^A0\M-@\^F\M-4\M-@\^D\M-@\M^AFq\M-@\^L\M-f\M-d\M-@\M^AFq\M-@\^L\M-f\M-T\M^? \M^?\M-xB\M^N\M-x\^B\^T\^E\M^?\M^?\M^?\M^?\M^?\M^?\M-xC\^A\M^?\M^?\M-xC\^B\M ^?\M^?\M-xC\^A\M-p\^K\^Q\M^P\^B\M^?\M^?\M-x\^O2\M-&p\M^?\M^?\M-x/\M-iB@\M^?\ M^?\M-x/\M-iB\240\M-@\^F\M-4\M-@\M-@"\M^G \M-@\M^AG1 \M-@\^F\M-0(\M-@\M^AG1\M-@\^F\M-/T\M-@\M^AQ\M^H\M-@\M^AGa\^E\M^?\M^?\M^?\M^? \M-@#\^WX\M^?\M^?\M-xrl\M^?\M^?\M-xx\^\\M^?\M^?\M-xBh@\M^?\M^?\M-xC\^B\M^?\M ^?\M-x\^?\M-m\M^@\M-@(\^T \M^?\M^?\M-xB\M-v\M^?\M^?\M-x\^?\M-m\M^@\^E\M-@$\M^F\M-H\M^?\M^?\M-xC\^B\M-@ \M^AH\^Q\M-@\^L\M-m\M-$\^A\M-@\M^AO\M-`\M-@\^F\M-4\M-@\M-@"\M^G\240\^A\M^?\M ^?\M-xx\^P\^T\^C\M-m\^E\M^?\M^?\M^?\M^?\M^?\M^?\M-x\^O2\M-.\M-p\M^?\M^?\M-x/ \M-iB@\M^?\M^?\M-x/\M-iB\240\M-@&\^?\M-P\M^?\M^?\M-xC\^A\^_\^Ap\M^?\M^?\M-x/ \M-iu`\M-@\M^AH\M-Q\M-@\^L\M-w0\M-@\M^AH\M-a\M-@\^L\M-z\^H\M^?\M-~\M-o\M-`\M ^?\M^?\M-xBi\^H\M-@"\M^F\M^@\M-@\M^AQx\M^?\M^?\M-x\^O2\M-/x \M^?\M^?\M-xB\M-m\M^?\M^?\M-x/\M-iu \^A3\M-xC\^A\^Bp\M-@\M^ARH\M-@\^Y\M^D@\M^?\M^?\M-x/\M-iu\M-@\^G\M^?\M^?\M-x/ \M-iu\M-C\^V\M-@\^E\M^?\M^?\M^?\M^?\M-@"\M-@\^H\M^?\M^?\M-xBh@\M^?\M^?\M-xrl \M-@\M^AI\M-q\M-@\^C\M^Uh\M-@\M^AI\M-q\M-@\^C\M^U8\M-@\M^AJ\^A\M-@\^G\M-0\M- X0\M-p\^GsH\M^?\M^?\M-xC\^B\M-@\^F\M-*`\M-@$ (\M^?\M^?\M-xC\M-(\M-@\M^AT\M^P\M^?\M^?\M-x/\M-iu\^G\M^?\M^?\M-x/\M-iu`\M-C\ ^T\M-@\M^?\M^?\M-x/\M-e\M-x\M^?\M^?\M-x\^O\M^?\M-y\M-0:\M^?\M^?\M-x\^Ostray vector interrupt 2029 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 16:10: 8 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E2037B401 for ; Mon, 13 Jan 2003 16:10:07 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06B0243E4A for ; Mon, 13 Jan 2003 16:10:07 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0E0A6u4094482 for ; Mon, 13 Jan 2003 16:10:06 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 13 Jan 2003 16:10:06 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: sparc@freebsd.org Subject: CVSup/sparc64: Come and get it! Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Drum roll, please ... After much weeping and wailing and gnashing of teeth, I've gotten CVSup working on FreeBSD/sparc64 platforms. You can grab the client executable from here: http://people.freebsd.org/~jdp/cvsup-sparc64/ It seems to work just fine, but I've hardly tested it at all. So be careful out there. If it doesn't work for you, update your system to -current from January 1, 2003 or later and try again. The package relies on a couple of fairly recent library changes. Don't ask me for specifics, just upgrade. No exceptions, no whining, thank you very much. As part of this effort I updated the Modula-3 code generator to a new gcc-3.2.1 code base. That should make the port to other platforms such as ia64 go much more easily. I'll get all this stuff into the ports after I catch my breath. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 16:21:20 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40C0237B401 for ; Mon, 13 Jan 2003 16:21:19 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0545B43ED8 for ; Mon, 13 Jan 2003 16:21:19 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id BBDE3AE1C1; Mon, 13 Jan 2003 16:21:10 -0800 (PST) Date: Mon, 13 Jan 2003 16:21:10 -0800 From: Maxime Henrion To: John Polstra Cc: sparc@freebsd.org Subject: Re: CVSup/sparc64: Come and get it! Message-ID: <20030114002110.GG16775@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra wrote: > Drum roll, please ... > > After much weeping and wailing and gnashing of teeth, I've gotten > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > It seems to work just fine, but I've hardly tested it at all. So be > careful out there. It works fine here as well! Thanks a million to you for this :-). Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 16:28: 8 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B769A37B401 for ; Mon, 13 Jan 2003 16:28:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 8A75243E4A for ; Mon, 13 Jan 2003 16:28:05 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 11576 invoked by uid 0); 14 Jan 2003 00:28:03 -0000 Received: from p508e4d64.dip.t-dialin.net (HELO galatea.local) (80.142.77.100) by mail.gmx.net (mp011-rz3) with SMTP; 14 Jan 2003 00:28:03 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18YExY-0001OB-00; Tue, 14 Jan 2003 01:29:40 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0E0Tao2005342; Tue, 14 Jan 2003 01:29:36 +0100 (CET) Date: Tue, 14 Jan 2003 01:29:36 +0100 From: Thomas Moestl To: John Polstra Cc: sparc@freebsd.org Subject: Re: CVSup/sparc64: Come and get it! Message-ID: <20030114002936.GA4822@crow.dom2ip.de> Mail-Followup-To: John Polstra , sparc@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2003/01/13 at 16:10:06 -0800, John Polstra wrote: > Drum roll, please ... > > After much weeping and wailing and gnashing of teeth, I've gotten > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > It seems to work just fine, but I've hardly tested it at all. So be > careful out there. > > If it doesn't work for you, update your system to -current from > January 1, 2003 or later and try again. The package relies on a > couple of fairly recent library changes. Don't ask me for specifics, > just upgrade. No exceptions, no whining, thank you very much. > > As part of this effort I updated the Modula-3 code generator to a new > gcc-3.2.1 code base. That should make the port to other platforms > such as ia64 go much more easily. > > I'll get all this stuff into the ports after I catch my breath. Great!!! Many thanks! - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 19:31:48 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8666737B401; Mon, 13 Jan 2003 19:31:47 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B6343F3F; Mon, 13 Jan 2003 19:31:46 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by flavatown.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0E2qpV10669; Mon, 13 Jan 2003 18:52:51 -0800 (PST) Received: from pool0171.cvx21-bradley.dialup.earthlink.net ([209.179.192.171] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YH8C-0007Qr-00; Mon, 13 Jan 2003 18:48:48 -0800 Message-ID: <3E237A41.1351AD49@mindspring.com> Date: Mon, 13 Jan 2003 18:47:29 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030114095915.C14524-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47d619ed94123ae94c49e7aeef37369de387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > > There has to be some allowance for the continuity of code; it > > can't just be orphaned instantaneously, without some warning > > from the system vendor. > > A warning was given here more than 4 years ago: [ ... ] This was a commit log message; that's very different than a #warning in the header file. > > Say we took your approach, and moved the #define's for the inlines > > up into , exposing platform dependencies in a (supposedly) > > platform independent header file. How many ports would break? All > > Not my approach. It's as close to your approach as we are likely to get, unless people are willing to rip out the inlining on the i386, and replace it with libc/gen/*.c code, so that they can put in pure prototypes in the header file, and take the additional overhead that this causes, relative to, say, Linux or some other OS that inlines the code. 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 19:46:19 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BFFA37B401 for ; Mon, 13 Jan 2003 19:46:17 -0800 (PST) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EBB043ED8 for ; Mon, 13 Jan 2003 19:46:16 -0800 (PST) (envelope-from anthonyv@brainlink.com) Received: from [24.189.7.159] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 17836398 for sparc64@freebsd.org; Mon, 13 Jan 2003 22:46:10 -0500 Message-ID: <3E238801.4090708@brainlink.com> Date: Mon, 13 Jan 2003 22:46:09 -0500 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20021224 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sparc64@freebsd.org Subject: Re: CVSup/sparc64: Come and get it! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hey, This is great. I tried cvsup'ing ports on my Ultra2 running today's -CURRENT and here is what I got: .... Edit ports/misc/wmwork/pkg-comment Edit ports/misc/wmx10/Makefile Edit ports/misc/wmx10/pkg-comment Edit ports/misc/xd/Makefile Edit ports/misc/xenmenu/Makefile Edit ports/misc/xosd/Makefile Edit ports/misc/xosd/distinfo Edit ports/misc/xosd/files/patch-src-xmms_plugin-Makefile.am Edit ports/misc/xosd/pkg-plist Edit ports/misc/xpns/Makefile Edit ports/misc/xrmap/Makefile Edit ports/misc/xrmap/files/pkg-message.in Edit ports/misc/xtar/files/patch-aa Checkout ports/misc/xtypo/Makefile Checkout ports/misc/xtypo/distinfo Checkout ports/misc/xtypo/pkg-comment Checkout ports/misc/xtypo/pkg-descr Checkout ports/misc/xtypo/pkg-plist Edit ports/misc/yaunc/Makefile Edit ports/misc/yaunc/files/patch-ae Checkout ports/misc/yaunc/files/patch-my_hdrs.h Edit ports/misc/ytree/Makefile Edit ports/misc/ytree/distinfo *** *** runtime error: *** Value out of range *** file "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 *** use option @M3stackdump to get a stack trace Abort trap (core dumped) One thing to note is that when i re-ran cvsup, this error did not occur again. I am guessing it can happen if you are updating a LOT of ports - I havent updated my ports since early december. But other than that oddity, all is great! Now if the great person with playing with the FAS code gave me something to play with .... :) Regards, Anthony Volodkin John Polstra wrote: >Drum roll, please ... > >After much weeping and wailing and gnashing of teeth, I've gotten >CVSup working on FreeBSD/sparc64 platforms. You can grab the client >executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > >It seems to work just fine, but I've hardly tested it at all. So be >careful out there. > >If it doesn't work for you, update your system to -current from >January 1, 2003 or later and try again. The package relies on a >couple of fairly recent library changes. Don't ask me for specifics, >just upgrade. No exceptions, no whining, thank you very much. > >As part of this effort I updated the Modula-3 code generator to a new >gcc-3.2.1 code base. That should make the port to other platforms >such as ia64 go much more easily. > >I'll get all this stuff into the ports after I catch my breath. > >John > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-sparc" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Jan 13 23:37: 7 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE6F837B401 for ; Mon, 13 Jan 2003 23:36:54 -0800 (PST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 670A943E4A for ; Mon, 13 Jan 2003 23:36:53 -0800 (PST) (envelope-from tomppa@finland.sun.com) Received: from sunfin.Finland.Sun.COM ([129.159.101.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11274 for ; Tue, 14 Jan 2003 00:36:51 -0700 (MST) Received: from ultrahot.Finland.Sun.COM (ultrahot [129.159.101.87]) by sunfin.Finland.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.3beta) with ESMTP id h0E7aoq5005400 for ; Tue, 14 Jan 2003 09:36:50 +0200 (EET) Received: from ultrahot.Finland.Sun.COM (localhost [127.0.0.1]) by ultrahot.Finland.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id h0E7anSV005561 for ; Tue, 14 Jan 2003 09:36:50 +0200 (EET) Received: (from tomppa@localhost) by ultrahot.Finland.Sun.COM (8.12.2+Sun/8.12.2/Submit) id h0E7anWL005558; Tue, 14 Jan 2003 09:36:49 +0200 (EET) From: Tomi Vainio - Sun Finland - MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15907.48650.256866.392460@ultrahot.finland.sun.com> Date: Tue, 14 Jan 2003 09:36:42 +0200 To: freebsd-sparc@freebsd.org Subject: RC3 boot problems so far In-Reply-To: <15907.17453.977625.480276@ultrahot.finland.sun.com> References: <15907.17453.977625.480276@ultrahot.finland.sun.com> X-Mailer: VM 7.07 under 21.4 (patch 9) "Informed Management" XEmacs Lucid Reply-To: Tomi.Vainio@Sun.COM Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've tried to boot couple machines at out lab. Here is the list: SB150 E220R E250 E3500 Netra T1 105 U1E V120 I found couple problems. We can't probe gem-device from FCAL/GBE combo card. - gem0: phy probe failed: 6 - both e220r / t1-105 logs shows this Panic after isp0: - e250 log SCSI errors from multiple devices - isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) - t1-105 log Tomppa ---clip clip--- Sun Enterprise 220R (UltraSPARC-II 360MHz), No Keyboard OpenBoot 3.31, 512 MB memory installed, Serial #12115752. Ethernet address 8:0:20:b8:df:28, Host ID: 80b8df28. Initializing Memory Boot device: /pci@1f,4000/network@1,1 File and args: Timeout waiting for ARP/RARP packet FreeBSD/sparc64 loader bootpath="/pci@1f,4000/network@1,1" loaddev=net0: boot: ethernet address: 08:00:20:b8:df:28 bootp: no reply net_open: client addr: 129.159.107.133 net_open: client name: e220r.cslab.finland.sun.com net_open: server addr: 129.159.107.1 net_open: server path: /u/tomppa/F |/-> \ \: unknown command \|/-/boot/kernel/kernel data=0x312c08+0xe77b8 \|syms=[0x8+0x49890/-\+0x8+0x38cf5] Hit [Enter] to boot immediately, or any other key for command prompt. nothing to autoload yet. jumping to kernel entry at 0xc0038000. stray vector interrupt 2029 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-RC3 #0: Sat Jan 11 06:47:44 GMT 2003 rootk@cyclequad.nuxi.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0480000. Timecounter "tick" frequency 360006234 Hz cpu0: Sun Microsystems UltraSparc-II Processor (360.01 MHz CPU) Model: SUNW,Ultra-60 Initializing GEOMetry subsystem nexus0: pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 7c0 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfe000000 to 0xffffffff device 0/1/0: latency timer 0 -> 82 pcib0: ofw_pci_init: no interrupt mapping found for 0/1/0 (preset 128) device 0/1/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 0/1/1 to 33 (preset was 0) device 0/3/0: latency timer 0 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/0 to 32 (preset was 0) device 0/3/1: latency timer 0 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/1 to 38 (preset was 0) PCI-PCI bridge at 0/5/0: setting bus #s to 0/1/1 pcib0: ofw_pci_init: descending to subordinate PCI bus device 1/0/0: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/0/0 to 28 (preset was 0) device 1/0/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/0/1 to 29 (preset was 0) device 1/1/0: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/1/0 to 29 (preset was 0) device 1/1/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/1/1 to 30 (preset was 0) device 1/2/0: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/2/0 to 30 (preset was 0) device 1/2/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/2/1 to 31 (preset was 0) device 1/3/0: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/3/0 to 31 (preset was 0) device 1/3/1: latency timer 0 -> 82 pcib0: ofw_pci_init: mapping intr for 1/3/1 to 28 (preset was 0) pci0: on pcib0 ebus0: revision 0x01 ebus0: mem 0x71000000-0x717fffff,0x70000000-0x70ffffff at device 1.0 on pci0 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) ebus0: addr 0x1400400000-0x140040007f irq 43 (no driver attached) ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x1400300398-0x1400300399,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 80b8df28 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) hme0: mem 0x10100000-0x10107fff irq 33 at device 1.1 on pci0 hme0: Ethernet address: 08:00:20:b8:df:28 miibus0: on hme0 qsphy0: on miibus0 qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <875> port 0x1000-0x10ff mem 0x1010a000-0x1010afff,0x10108000-0x101080ff irq 32 at device 3.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x1400-0x14ff mem 0x1010e000-0x1010efff,0x1010c000-0x1010c0ff irq 38 at device 3.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) hme1: mem 0x4000000-0x4007fff irq 29 at device 0.1 on pci1 hme1: Ethernet address: 08:00:20:b8:df:28 miibus1: on hme1 qsphy1: on miibus1 qsphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: at device 1.0 (no driver attached) hme2: mem 0x8000000-0x8007fff irq 30 at device 1.1 on pci1 hme2: Ethernet address: 08:00:20:b8:df:28 miibus2: on hme2 qsphy2: on miibus2 qsphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: at device 2.0 (no driver attached) hme3: mem 0xc000000-0xc007fff irq 31 at device 2.1 on pci1 hme3: Ethernet address: 08:00:20:b8:df:28 miibus3: on hme3 qsphy3: on miibus3 qsphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: at device 3.0 (no driver attached) hme4: mem 0x10000000-0x10007fff irq 28 at device 3.1 on pci1 hme4: Ethernet address: 08:00:20:b8:df:28 miibus4: on hme4 qsphy4: on miibus4 qsphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib2: on nexus0 pcib2: Psycho, impl 0, version 4, ign 7c0 PCI-PCI bridge at 2/1/0: setting bus #s to 2/3/3 pcib2: ofw_pci_init: descending to subordinate PCI bus device 3/4/0: latency timer 0 -> 528 pcib2: ofw_pci_init: mapping intr for 3/4/0 to 0 (preset was 255) pcib2: ofw_pci_init: mapping intr for 3/5/0 to 1 (preset was 0) pci2: on pcib2 pcib3: at device 1.0 on pci2 pci3: on pcib3 gem0: mem 0x200000-0x3fffff irq 0 at device 4.0 on pci3 gem0: phy probe failed: 6 gem0: could not be configured device_probe_and_attach: gem0 attach returned 6 isp0: port 0x1000-0x10ff mem 0x400000-0x400fff irq 1 at device 5.0 on pci3 Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) Manual root filesystem specification: : Mount using filesystem eg. ufs:da0a ? List valid disk boot devices Abort manual input mountroot> mountroot> panic: Root mount failed, startup aborted. cpuid = 0; syncing disks, buffers remaining... done Uptime: 2m3s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... Resetting ... ---clip clip--- Sun (TM) Enterprise 250 (2 X UltraSPARC-II 296MHz), No Keyboard OpenBoot 3.26, 512 MB memory installed, Serial #10904892. Ethernet address 8:0:20:a6:65:3c, Host ID: 80a6653c. Timeout waiting for ARP/RARP packet Timeout waiting for ARP/RARP packet Timeout waiting for ARP/RARP packet Timeout waiting for ARP/RARP packet Console: OpenFirmware console FreeBSD/sparc64 loader bootpath="/pci@1f,4000/network@1,1" loaddev=net0: boot: ethernet address: 08:00:20:a6:65:3c bootp: no reply net_open: client addr: 129.159.107.132 net_open: client name: e250.cslab.finland.sun.com net_open: server addr: 129.159.107.1 net_open: server path: /u/tomppa/F |/-> \ \: unknown command /boot/kernel/kernel.ko data=0x312c08+0xe77b8 \|syms=[0x8+0x49890/-\+0x8+0x38cf5|/-\] Hit [Enter] to boot immediately, or any other key for command prompt. nothing to autoload yet. jumping to kernel entry at 0xc0038000. Costray vector interrupt 2029 pyright (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-RC3 #0: Sat Jan 11 06:47:44 GMT 2003 rootk@cyclequad.nuxi.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel.ko" at 0xc0480000. Timecounter "tick" frequency 296000000 Hz cpu0: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) Model: SUNW,Ultra-250 cpu1: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Initializing GEOMetry subsystem nexus0: nexus0: , type (unknown) (no driver attached) pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 7c0 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfe000000 to 0xffffffff device 0/1/0: latency timer 10 -> 82 pcib0: ofw_pci_init: no interrupt mapping found for 0/1/0 (preset 0) device 0/1/1: latency timer 10 -> 82 pcib0: ofw_pci_init: mapping intr for 0/1/1 to 33 (preset was 0) device 0/3/0: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/0 to 32 (preset was 0) device 0/3/1: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/3/1 to 38 (preset was 0) device 0/2/0: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/2/0 to 16 (preset was 0) device 0/2/1: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/2/1 to 17 (preset was 0) PCI-PCI bridge at 0/4/0: setting bus #s to 0/1/1 pcib0: ofw_pci_init: descending to subordinate PCI bus device 1/4/0: latency timer 64 -> 528 pcib0: ofw_pci_init: mapping intr for 1/4/0 to 24 (preset was 0) device 1/5/0: latency timer 64 -> 528 pcib0: ofw_pci_init: mapping intr for 1/5/0 to 25 (preset was 0) device 0/5/0: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/5/0 to 28 (preset was 0) device 0/5/1: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 0/5/1 to 29 (preset was 0) pci0: on pcib0 ebus0: revision 0x01 ebus0: mem 0x71000000-0x717fffff,0x70000000-0x70ffffff at device 1.0 on pci0 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) ebus0: addr 0x1400400000-0x140040007f irq 43 (no driver attached) ebus0: addr 0x1400200000-0x140020007f irq 35 (no driver attached) ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 33 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x1400300398-0x1400300399,0x14003043bc-0x14003043cb irq 33 (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 80a6653c ebus0: addr 0x1000000000-0x10000fffff,0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 37,40 (no driver attached) hme0: mem 0x200000-0x207fff irq 33 at device 1.1 on pci0 hme0: Ethernet address: 08:00:20:a6:65:3c miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <875> port 0x2800-0x28ff mem 0x212000-0x212fff,0x210000-0x2100ff irq 16 at device 2.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x2c00-0x2cff mem 0x216000-0x216fff,0x214000-0x2140ff irq 17 at device 2.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym2: <875> port 0x2000-0x20ff mem 0x20a000-0x20afff,0x208000-0x2080ff irq 32 at device 3.0 on pci0 sym2: No NVRAM, ID 7, Fast-20, SE, parity checking sym3: <875> port 0x2400-0x24ff mem 0x20e000-0x20efff,0x20c000-0x20c0ff irq 38 at device 3.1 on pci0 sym3: No NVRAM, ID 7, Fast-20, SE, parity checking pcib1: at device 4.0 on pci0 pci1: on pcib1 isp0: port 0x1000-0x10ff mem 0x100000-0x100fff irq 24 at device 4.0 on pci1 panic: trap: data access error cpuid = 0; boot() called on cpu#0 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort rsc> xir Are you sure you want to send a non-maskable interrupt (XIR) to your server (Yes/No)? y ---clip clip--- Netra t1 (UltraSPARC-IIi 360MHz), No Keyboard OpenBoot 3.10.24 ME, 64 MB memory installed, Serial #11064612. Ethernet address 8:0:20:a8:d5:24, Host ID: 80a8d524. Initializing Memory Boot device: /pci@1f,0/pci@1,1/network@1,1 File and args: FreeBSD/sparc64 loader bootpath="/pci@1f,0/pci@1,1/network@1,1" loaddev=net0: boot: ethernet address: 08:00:20:a8:d5:24 net_open: server addr: 129.159.107.1 net_open: server path: /u/tomppa/F |/-> \ \: unknown command \|/-/boot/kernel/kernel.ko data=0x312c08+0xe77b8 \|syms=[0x8+0x49890/-\+0x8+0x38cf5|/-\] Hit [Enter] to boot immediately, or any other key for command prompt. nothing to autoload yet. jumping to kernel entry at 0xc0038000. 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-RC3 #0: Sat Jan 11 06:47:44 GMT 2003 rootk@cyclequad.nuxi.com:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel.ko" at 0xc0480000. Timecounter "tick" frequency 360011687 Hz cpu0: Sun Microsystems UltraSparc-IIi Processor (360.01 MHz CPU) Model: SUNW,UltraSPARC-IIi-cEngine Initializing GEOMetry subsystem nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 7c0 DVMA map: 0xc0000000 to 0xdfffffff 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 10 -> 82 pcib0: ofw_pci_init: no interrupt mapping found for 1/1/0 (preset 0) device 1/1/1: latency timer 10 -> 82 pcib0: ofw_pci_init: mapping intr for 1/1/1 to 33 (preset was 0) device 1/2/0: latency timer 17 -> 140 pcib0: ofw_pci_init: mapping intr for 1/2/0 to 32 (preset was 0) PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/2 pcib0: ofw_pci_init: descending to subordinate PCI bus PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/3 PCI-PCI bridge at 2/1/0: setting bus #s to 2/3/3 pcib0: ofw_pci_init: descending to subordinate PCI bus device 3/14/0: latency timer 0 -> 16 pcib0: ofw_pci_init: mapping intr for 3/14/0 to 2 (preset was 14) PCI-PCI bridge at 2/1/0: setting bus #s to 2/3/4 PCI-PCI bridge at 0/1/0: setting bus #s to 0/2/4 PCI-PCI bridge at 3/15/0: setting bus #s to 3/4/4 pcib0: ofw_pci_init: descending to subordinate PCI bus device 4/4/0: latency timer 64 -> 528 pcib0: ofw_pci_init: mapping intr for 4/4/0 to 3 (preset was 255) pcib0: ofw_pci_init: mapping intr for 4/5/0 to 0 (preset was 0) pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 1.0 on pci1 pci3: on pcib2 atapci0: port 0x2020-0x202f,0x2018-0x201b,0x2010-0x2017,0x2008-0x200b,0x2000-0x2007 irq 2 at device 14.0 on pci3 ata2: at 0x2000 on atapci0 ata3: at 0x2010 on atapci0 pcib3: at device 15.0 on pci3 pci4: on pcib3 gem0: mem 0x200000-0x3fffff irq 3 at device 4.0 on pci4 gem0: phy probe failed: 6 gem0: could not be configured device_probe_and_attach: gem0 attach returned 6 isp0: port 0x1000-0x10ff mem 0x400000-0x400fff irq 0 at device 5.0 on pci4 pcib4: at device 1.1 on pci0 pci2: on pcib4 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) ebus0: addr 0x14003803f8-0x14003803ff irq 28 (no driver attached) ebus0: addr 0x14003602f8-0x14003602ff irq 20 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x140030015c-0x140030015d,0x1400340278-0x1400340287 irq 34 (no driver attached) ebus0: addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003203f0-0x14003203f7 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 80a8d524 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400200000-0x140020003f irq 4 (no driver attached) ebus0: addr 0x1400200040 (no driver attached) ebus0: addr 0x1400722000-0x1400722003 (no driver attached) ebus0: addr 0x1000400000-0x10005fffff (no driver attached) ebus0: addr 0x1000800000-0x10009fffff (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 40 (no driver attached) ebus0: addr 0x1400100000-0x1400100003 irq 27 (no driver attached) ebus0: addr 0x1400400000-0x1400400063 (no driver attached) hme0: mem 0xe0000000-0xe0007fff irq 33 at device 1.1 on pci2 hme0: Ethernet address: 08:00:20:a8:d5:24 miibus0: on hme0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy1: on miibus0 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <875> port 0xc00000-0xc000ff mem 0xe000a000-0xe000afff,0xe0008000-0xe00080ff irq 32 at device 2.0 on pci2 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking Timecounters tick every 10.000 msec acd0: CDROM at ata3-master PIO4 Waiting 15 seconds for SCSI devices to settle isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 127, resid 1, status not marked) isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 127, resid 1, status not marked) isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 255, resid 127, status not marked) isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 255, resid 127, status not marked) isp0: bad underrun for 13.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 255, resid 127, status not marked) isp0: bad underrun for 29.0 (count 255, resid 127, status not marked) pass7 at isp0 bus 0 target 13 lun 0 pass7: Fixed Enclosure Services SCSI-3 device pass7: 100.000MB/s transfers pass15 at isp0 bus 0 target 29 lun 0 pass15: Fixed Enclosure Services SCSI-3 device pass15: 100.000MB/s transfers da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 100.000MB/s transfers, Tagged Queueing Enabled da0: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da14 at sym0 bus 0 target 0 lun 0 da14: Fixed Direct Access SCSI-2 device da14: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da14: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) da15 at sym0 bus 0 target 1 lun 0 da15: Fixed Direct Access SCSI-3 device da15: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da15: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 100.000MB/s transfers, Tagged Queueing Enabled da1: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da2 at isp0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 100.000MB/s transfers, Tagged Queueing Enabled da2: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da3 at isp0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 100.000MB/s transfers, Tagged Queueing Enabled da3: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da4 at isp0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 100.000MB/s transfers, Tagged Queueing Enabled da4: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da5 at isp0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-2 device da5: 100.000MB/s transfers, Tagged Queueing Enabled da5: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da6 at isp0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-2 device da6: 100.000MB/s transfers, Tagged Queueing Enabled da6: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da7 at isp0 bus 0 target 16 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 100.000MB/s transfers, Tagged Queueing Enabled da7: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da8 at isp0 bus 0 target 17 lun 0 da8: Fixed Direct Access SCSI-2 device da8: 100.000MB/s transfers, Tagged Queueing Enabled da8: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da9 at isp0 bus 0 target 18 lun 0 da9: Fixed Direct Access SCSI-2 device da9: 100.000MB/s transfers, Tagged Queueing Enabled da9: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da10 at isp0 bus 0 target 19 lun 0 da10: Fixed Direct Access SCSI-2 device da10: 100.000MB/s transfers, Tagged Queueing Enabled da10: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da11 at isp0 bus 0 target 20 lun 0 da11: Fixed Direct Access SCSI-2 device da11: 100.000MB/s transfers, Tagged Queueing Enabled da11: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da12 at isp0 bus 0 target 21 lun 0 da12: Fixed Direct Access SCSI-2 device da12: 100.000MB/s transfers, Tagged Queueing Enabled da12: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da13 at isp0 bus 0 target 22 lun 0 da13: Fixed Direct Access SCSI-2 device da13: 100.000MB/s transfers, Tagged Queueing Enabled da13: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) Manual root filesystem specification: : Mount using filesystem eg. ufs:da0a ? List valid disk boot devices Abort manual input mountroot> panic: Root mount failed, startup aborted. cpuid = 0; syncing disks, buffers remaining... done Uptime: 37s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. ---clip clip--- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 1:10:26 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CEBC37B401 for ; Tue, 14 Jan 2003 01:10:26 -0800 (PST) Received: from ipnet.ru (relay.ipnet.ru [62.16.100.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BF9143F18 for ; Tue, 14 Jan 2003 01:10:25 -0800 (PST) (envelope-from tsypa@ipnet.ru) Received: from [192.168.255.200] (account tsypa HELO hqmon) by ipnet.ru (CommuniGate Pro SMTP 4.0.3) with ESMTP-TLS id 303968 for freebsd-sparc@freebsd.org; Tue, 14 Jan 2003 09:10:24 +0000 Date: Tue, 14 Jan 2003 12:10:23 +0300 From: Igor Tseglevsky To: freebsd-sparc@freebsd.org Subject: cvsup Message-Id: <20030114121023.2d554675.tsypa@ipnet.ru> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What tag I should use to receive (cvsup) a fresh tree of sources? The tag "RELENG_5_0" receives more an old tree, than in 5.0-20030102-SNAP from ftp2. Why? Igor Tseglevsky. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 1:37:31 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 164D437B401 for ; Tue, 14 Jan 2003 01:37:30 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28ACA43F13 for ; Tue, 14 Jan 2003 01:37:24 -0800 (PST) (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 A224566B60; Tue, 14 Jan 2003 01:37:23 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id AAE75FD1; Tue, 14 Jan 2003 01:37:23 -0800 (PST) Date: Tue, 14 Jan 2003 01:37:23 -0800 From: Kris Kennaway To: Igor Tseglevsky Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: cvsup Message-ID: <20030114093723.GA11050@rot13.obsecurity.org> References: <20030114121023.2d554675.tsypa@ipnet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20030114121023.2d554675.tsypa@ipnet.ru> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 14, 2003 at 12:10:23PM +0300, Igor Tseglevsky wrote: > What tag I should use to receive (cvsup) a fresh tree of sources? > The tag "RELENG_5_0" receives more an old tree, than in 5.0-20030102-SNAP from ftp2. Why? RELENG_5_0 is a branch containing (currently) 5.0-RC. Use a "tag" of "." to get the CVS head. For more information see the cvsup docs and the handbook. Kris --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+I9pTWry0BWjoQKURAo09AJ9fU/1iI/ehf3spsQlSB5IQebslzACg6Kg+ jyH09v4itbf15uoZX3Bv8eY= =WVjp -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 1:47:24 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6B9D37B401 for ; Tue, 14 Jan 2003 01:47:22 -0800 (PST) Received: from excalibur.skynet.be (excalibur.skynet.be [195.238.3.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 876BC43F3F for ; Tue, 14 Jan 2003 01:47:21 -0800 (PST) (envelope-from trollet@skynet.be) Received: from skynet.be (163.248-136-217.adsl.skynet.be [217.136.248.163]) by excalibur.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with ESMTP id h0E9lGd22430 for ; Tue, 14 Jan 2003 10:47:16 +0100 (MET) (envelope-from ) Message-ID: <3E23D8EE.DDA28DBB@skynet.be> Date: Tue, 14 Jan 2003 10:31:26 +0100 From: Atle X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: no, en MIME-Version: 1.0 Cc: sparc@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <3E2324B0.585FD417@mindspring.com> <20030113210642.GB798@dhcp01.pn.xcllnt.net> <3E232F9C.D323FF99@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > Having on SPARC makes sense, in terms of being > able to support a *legacy* interface for *legacy* code that needs > it. Both uses of the word "legacy" are important here. I think > that the header file should complain, during compilation, when it > is used, e.g.: > > #warning "this file includes which is obsoleted, use > instead" > > This doesn't contradict uniformity across platforms, per se, > since the interface is deprecated. Please excuse an ignorant fool for barging in, I have been following this, taken a step back, and concluded 'this is not easy to follow'. I often consult my wife when I have design problems, so I will be the 'wife' here. I try as far as possible to let names be uniform across declaration (.h files) and libraries (.a .o .so). So if a program does this #include then it links with something called foo.o or libfoo.a Anything that depends on i386 lives inside some #ifdef i386 #include <386quirks.h> #else #include #endif Is there a fundamental design issue here? If there is even a change that some circular #includes can happen, then surely there must be something wrong? Please ignore this if it is irrelevant, Atle http://atle.linux-site.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 4:18:28 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D28C37B401 for ; Tue, 14 Jan 2003 04:18:27 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id D200C43F43 for ; Tue, 14 Jan 2003 04:18:25 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0ECIHb05302 for ; Tue, 14 Jan 2003 13:18:17 +0100 From: "Roderick van Domburg" To: "FreeBSD-sparc@FreeBSD. ORG" Subject: Re: RC3 boot problems so far Date: Tue, 14 Jan 2003 13:18:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Panic after isp0: > - e250 log Hmm... exactly what is this panic? Is it in any way related to the "panic: trap: fast data access mmu miss" thread on this mailing list? Thomas, perhaps then it's not caused by sym but by isp corrupting something causing sym to fail? Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 6: 4:29 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB1EF37B401 for ; Tue, 14 Jan 2003 06:04:28 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C51F43F3F for ; Tue, 14 Jan 2003 06:04:27 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0EE4Pb30775 for ; Tue, 14 Jan 2003 15:04:25 +0100 From: "Roderick van Domburg" To: "FreeBSD-sparc@FreeBSD. ORG" Subject: RE: RC3 boot problems so far Date: Tue, 14 Jan 2003 15:05:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Panic after isp0: > > - e250 log > > Hmm... exactly what is this panic? Is it in any way related to the "panic: > trap: fast data access mmu miss" thread on this mailing list? > > Thomas, perhaps then it's not caused by sym but by isp corrupting > something > causing sym to fail? Well, that worked! I removed the isp device from the kernel and everything seems to be peachy now. Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 8:59:51 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA37837B401 for ; Tue, 14 Jan 2003 08:59:50 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D102543EB2 for ; Tue, 14 Jan 2003 08:59:49 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.6/8.12.2) with ESMTP id h0EGxmIx049487; Tue, 14 Jan 2003 08:59:48 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.6/8.12.6/Submit) id h0EGwWWW049472; Tue, 14 Jan 2003 08:58:32 -0800 (PST) Date: Tue, 14 Jan 2003 08:58:32 -0800 From: "David O'Brien" To: Tomi Vainio - Sun Finland - Cc: freebsd-sparc@freebsd.org Subject: Re: RC3 boot problems so far Message-ID: <20030114165832.GA49169@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <15907.17453.977625.480276@ultrahot.finland.sun.com> <15907.48650.256866.392460@ultrahot.finland.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15907.48650.256866.392460@ultrahot.finland.sun.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 14, 2003 at 09:36:42AM +0200, Tomi Vainio - Sun Finland - wrote: > Panic after isp0: > - e250 log I also have trouble with a simular configuration. When I put a Qlogic ISP 1080 in my E250, is somehow interferes with the on-board SYM and my disks can't be found as I get all kinds of SCSI bus time outs, etc... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 9:33:12 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDABC37B401; Tue, 14 Jan 2003 09:33:08 -0800 (PST) Received: from moo.cus.org.uk (host213-106-240-81.no-dns-yet.ntli.net [213.106.240.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F4843F13; Tue, 14 Jan 2003 09:33:03 -0800 (PST) (envelope-from dom@moo.cus.org.uk) Received: from moo.cus.org.uk (localhost.cus.org.uk [127.0.0.1]) by moo.cus.org.uk (8.12.5/8.11.3) with ESMTP id h0EHb9pH032783; Tue, 14 Jan 2003 17:37:09 GMT (envelope-from dom@moo.cus.org.uk) Received: (from dom@localhost) by moo.cus.org.uk (8.12.5/8.12.5/Submit) id h0EHb9Sx032782; Tue, 14 Jan 2003 17:37:09 GMT Date: Tue, 14 Jan 2003 17:37:09 GMT Message-Id: <200301141737.h0EHb9Sx032782@moo.cus.org.uk> To: FreeBSD-gnats-submit@freebsd.org Subject: Port Fix: security/john From: Dominic Marks Reply-To: Dominic Marks Cc: freebsd-sparc@freebsd.org X-send-pr-version: 3.113 X-GNATS-Notify: Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Submitter-Id: current-users >Originator: Dominic Marks >Organization: UMIST >Confidential: no >Synopsis: Port Fix: security/john >Severity: non-critical >Priority: low >Category: ports >Class: maintainer-update >Release: FreeBSD 4.6-STABLE i386 >Environment: System: FreeBSD moo.cus.org.uk 4.6-STABLE FreeBSD 4.6-STABLE #0: Sat Jul 20 15:11:50 BST 2002 root@moo.cus.org.uk:/usr/obj/usr/src/sys/MOO i386 >Description: My previous patch for this port doesn't seem to have worked as I hoped it would, build still fails for alpha and sparc64 machines. Here is a new patch which hopefully will make the port build on bento, also, add 'native' support to john for FreeBSD/sparc64, it should use the sparc assembler routines now. I don't have an alpha or sparc64 machine running FreeBSD at the moment so any feedback (positive or negative) would be very helpful. >How-To-Repeat: Apply patch && make >Fix: Index: Makefile =================================================================== RCS file: /home/ncvs/ports/security/john/Makefile,v retrieving revision 1.23 diff -u -3 -p -r1.23 Makefile --- Makefile 2003/01/06 21:33:36 1.23 +++ Makefile 2003/01/14 17:30:53 @@ -34,13 +34,16 @@ ALL_TARGET= ${OSNAME}-${ARCHNAME}-any-el .elif ${MACHINE_ARCH} == "alpha" ARCHNAME= alpha ALL_TARGET= ${OSNAME}-${ARCHNAME}-any-elf +.elif ${MACHINE_ARCH} == "sparc64" +ARCHNAME= sparc +ALL_TARGET= ${OSNAME}-${ARCHNAME}-v9-elf .else ALL_TARGET= generic .endif WRKSRC= ${WRKDIR}/${DISTNAME}/src -pre-fetch: +pre-build: @${ECHO} "Building for ${ALL_TARGET}" do-configure: Updated files/patch-aa --- Makefile.orig Thu Dec 3 00:29:50 1998 +++ Makefile Tue Jan 14 17:20:06 2003 @@ -3,17 +3,18 @@ # Copyright (c) 1996-98 by Solar Designer # -CPP = gcc -CC = gcc -AS = gcc -LD = gcc +CC ?= gcc +CPP = $(CC) +AS = $(CC) +LD = $(CC) CP = cp LN = ln -sf RM = rm -f SED = sed NULL = /dev/null CPPFLAGS = -E -CFLAGS = -c -Wall -O2 -fomit-frame-pointer +CFLAGS ?= -O2 +CFLAGS += -c -Wall -fomit-frame-pointer ASFLAGS = -c LDFLAGS = -s OPT_NORMAL = -funroll-loops @@ -89,8 +90,10 @@ @echo "freebsd-x86-any-a.out FreeBSD, x86, a.out binaries" @echo "freebsd-x86-k6-a.out FreeBSD, AMD K6, a.out binaries" @echo "freebsd-x86-any-elf FreeBSD, x86, ELF binaries" + @echo "freebsd-alpha-any-elf FreeBSD, Alpha, ELF binaries" @echo "freebsd-x86-mmx-elf FreeBSD, x86 with MMX, ELF binaries" @echo "freebsd-x86-k6-elf FreeBSD, AMD K6, ELF binaries" + @echo "freebsd-sparc-v9-elf FreeBSD, SPARC v9, ELF binaries" @echo "openbsd-x86-any OpenBSD, x86" @echo "openbsd-x86-k6 OpenBSD, AMD K6" @echo "solaris-sparc-gcc Solaris, SPARC, gcc" @@ -156,6 +159,16 @@ BENCH_DES_OBJS_DEPEND="$(BENCH_DES_OBJS_ORIG) sparc.o" \ JOHN_OBJS="$(BITSLICE_OBJS) $(JOHN_OBJS_ORIG) sparc.o" +freebsd-sparc-v9-elf: + $(MAKE) HAMMER=use-freebsd-sparc sparc.h + $(LN) sparc.h arch.h + $(MAKE) use-freebsd-sparc NAIL="$(PROJ)" + +use-freebsd-sparc: + $(MAKE) $(NAIL) \ + BENCH_DES_OBJS_DEPEND="$(BENCH_DES_OBJS_ORIG) sparc.o" \ + JOHN_OBJS="$(BITSLICE_OBJS) $(JOHN_OBJS_ORIG) sparc.o " + freebsd-x86-any-a.out: $(LN) x86-any.h arch.h $(MAKE) $(PROJ) \ @@ -173,14 +186,19 @@ $(LN) x86-any.h arch.h $(MAKE) $(PROJ) \ JOHN_OBJS="$(JOHN_OBJS) x86.o" \ - CFLAGS="$(CFLAGS) -m486" \ + CFLAGS="$(CFLAGS)" \ ASFLAGS="$(ASFLAGS) -DBSD" +freebsd-alpha-any-elf: + $(LN) alpha.h arch.h + $(MAKE) $(PROJ) \ + JOHN_OBJS="$(BITSLICE_OBJS) $(JOHN_OBJS) alpha.o" + freebsd-x86-mmx-elf: $(LN) x86-mmx.h arch.h $(MAKE) $(PROJ) \ JOHN_OBJS="$(JOHN_OBJS) x86.o" \ - CFLAGS="$(CFLAGS) -m486" \ + CFLAGS="$(CFLAGS)" \ ASFLAGS="$(ASFLAGS) -DBSD" freebsd-x86-k6-elf: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 10:24:14 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32E6037B401 for ; Tue, 14 Jan 2003 10:24:13 -0800 (PST) Received: from alistair.scapegoats.org (alistair.scapegoats.org [64.40.92.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B17A843F5F for ; Tue, 14 Jan 2003 10:24:12 -0800 (PST) (envelope-from denny@alistair.scapegoats.org) Received: by alistair.scapegoats.org (Postfix, from userid 1001) id B49BF26F; Tue, 14 Jan 2003 12:24:06 -0600 (CST) Date: Tue, 14 Jan 2003 12:24:06 -0600 From: Denny Reiter To: John Polstra Cc: sparc@freebsd.org Subject: Re: CVSup/sparc64: Come and get it! Message-ID: <20030114182406.GA30451@reiters.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Uptime: 12:21PM up 140 days, 10:14, 6 users, load averages: 0.10, 0.07, 0.01 X-Message-Flag: Flagged by Genisys - http://www.darpa.mil/iao/Genisys.htm X-PGP-Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0x997F9D70 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 13, 2003 at 04:10:06PM -0800, John Polstra wrote: > Drum roll, please ... > > After much weeping and wailing and gnashing of teeth, I've gotten > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > It seems to work just fine, but I've hardly tested it at all. So be > careful out there. It worked just fine on 5.0-DP2 running on an Ultra10. Now I'm all Currentey :) Thanks very much! -- Denny Reiter denny@reiters.org So I don't hurt your feelings: happydenny@reiters.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 10:26: 1 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD57637B401 for ; Tue, 14 Jan 2003 10:25:59 -0800 (PST) Received: from alistair.scapegoats.org (alistair.scapegoats.org [64.40.92.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 511AC43EB2 for ; Tue, 14 Jan 2003 10:25:59 -0800 (PST) (envelope-from denny@alistair.scapegoats.org) Received: by alistair.scapegoats.org (Postfix, from userid 1001) id B458326E; Tue, 14 Jan 2003 12:25:58 -0600 (CST) Date: Tue, 14 Jan 2003 12:25:58 -0600 From: Denny Reiter To: John Polstra Cc: sparc@freebsd.org Subject: Re: CVSup/sparc64: Come and get it! Message-ID: <20030114182558.GB30451@reiters.org> References: <20030114182406.GA30451@reiters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030114182406.GA30451@reiters.org> X-Uptime: 12:25PM up 140 days, 10:19, 6 users, load averages: 0.00, 0.03, 0.00 X-Message-Flag: Flagged by Genisys - http://www.darpa.mil/iao/Genisys.htm X-PGP-Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0x997F9D70 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org grr. I meant RC2, not DP2. On Tue, Jan 14, 2003 at 12:24:06PM -0600, Denny Reiter wrote: > On Mon, Jan 13, 2003 at 04:10:06PM -0800, John Polstra wrote: > > Drum roll, please ... > > > > After much weeping and wailing and gnashing of teeth, I've gotten > > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > > executable from here: > > > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > > > It seems to work just fine, but I've hardly tested it at all. So be > > careful out there. > > It worked just fine on 5.0-DP2 running on an Ultra10. > Now I'm all Currentey :) > > Thanks very much! > > -- > Denny Reiter denny@reiters.org > So I don't hurt your feelings: happydenny@reiters.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-sparc" in the body of the message -- Denny Reiter denny@reiters.org So I don't hurt your feelings: happydenny@reiters.org Does your train of thought have a caboose? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 10:48:49 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B69037B401 for ; Tue, 14 Jan 2003 10:48:47 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1770743F18 for ; Tue, 14 Jan 2003 10:48:46 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0EImeu5099843 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Jan 2003 10:48:41 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0EImew9036994; Tue, 14 Jan 2003 10:48:40 -0800 (PST) (envelope-from jdp) Date: Tue, 14 Jan 2003 10:48:40 -0800 (PST) Message-Id: <200301141848.h0EImew9036994@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: anthonyv@brainlink.com Subject: Re: CVSup/sparc64: Come and get it! In-Reply-To: <3E238801.4090708@brainlink.com> References: <3E238801.4090708@brainlink.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <3E238801.4090708@brainlink.com>, Anthony Volodkin wrote: > > This is great. I tried cvsup'ing ports on my Ultra2 running today's > -CURRENT and here is what I got: > > .... > Edit ports/misc/wmwork/pkg-comment > Edit ports/misc/wmx10/Makefile > Edit ports/misc/wmx10/pkg-comment > Edit ports/misc/xd/Makefile > Edit ports/misc/xenmenu/Makefile > Edit ports/misc/xosd/Makefile > Edit ports/misc/xosd/distinfo > Edit ports/misc/xosd/files/patch-src-xmms_plugin-Makefile.am > Edit ports/misc/xosd/pkg-plist > Edit ports/misc/xpns/Makefile > Edit ports/misc/xrmap/Makefile > Edit ports/misc/xrmap/files/pkg-message.in > Edit ports/misc/xtar/files/patch-aa > Checkout ports/misc/xtypo/Makefile > Checkout ports/misc/xtypo/distinfo > Checkout ports/misc/xtypo/pkg-comment > Checkout ports/misc/xtypo/pkg-descr > Checkout ports/misc/xtypo/pkg-plist > Edit ports/misc/yaunc/Makefile > Edit ports/misc/yaunc/files/patch-ae > Checkout ports/misc/yaunc/files/patch-my_hdrs.h > Edit ports/misc/ytree/Makefile > Edit ports/misc/ytree/distinfo > > *** > *** runtime error: > *** Value out of range > *** file > "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > *** Hmm, that's interesting! This error occurs when the system's date is wildly wrong (before the year 1970, usually). But I don't think it's consistently wrong in your case, or the error would have happened sooner and it would fail every time. I'll double check the time/date support. Probably I botched a data type or an endianness setting for this platform. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 11:17: 9 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DD837B401 for ; Tue, 14 Jan 2003 11:17:08 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC05F43ED8 for ; Tue, 14 Jan 2003 11:17:07 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0EJH6u5000122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 14 Jan 2003 11:17:07 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0EJH6H4037062; Tue, 14 Jan 2003 11:17:06 -0800 (PST) (envelope-from jdp) Date: Tue, 14 Jan 2003 11:17:06 -0800 (PST) Message-Id: <200301141917.h0EJH6H4037062@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Subject: Re: CVSup/sparc64: Come and get it! In-Reply-To: <200301141848.h0EImew9036994@vashon.polstra.com> References: <3E238801.4090708@brainlink.com> <200301141848.h0EImew9036994@vashon.polstra.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200301141848.h0EImew9036994@vashon.polstra.com>, John Polstra wrote: > In article <3E238801.4090708@brainlink.com>, > Anthony Volodkin wrote: > > > > *** > > *** runtime error: > > *** Value out of range > > *** file > > "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > > *** > > Hmm, that's interesting! This error occurs when the system's date > is wildly wrong (before the year 1970, usually). But I don't think > it's consistently wrong in your case, or the error would have > happened sooner and it would fail every time. > > I'll double check the time/date support. Probably I botched a > data type or an endianness setting for this platform. Something is definitely broken in this area. I'll let you know when I have a fixed version. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 11:31:40 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0812D37B4D8 for ; Tue, 14 Jan 2003 11:31:33 -0800 (PST) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A38343F13 for ; Tue, 14 Jan 2003 11:31:32 -0800 (PST) (envelope-from groudier@free.fr) Received: from [192.168.1.129] (195.242.73.187) by mail.libertysurf.net (6.5.026) id 3DEB4B6900C7F0BD; Tue, 14 Jan 2003 20:31:30 +0100 Date: Tue, 14 Jan 2003 21:30:36 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: groudier@localhost.my.domain To: Thomas Moestl Cc: Roderick van Domburg , Subject: Re: panic: trap: fast data access mmu miss In-Reply-To: <20030112225517.GB278@crow.dom2ip.de> Message-ID: <20030114211838.C2122-100000@localhost.my.domain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 12 Jan 2003, Thomas Moestl wrote: > On Sun, 2003/01/12 at 16:13:20 +0100, Roderick van Domburg wrote: > > > > Running on a Sun Enterprise 250 with a single UltraSparc-II > > > > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had > > > > this same problem with sources over the past few (three?) days. > > > > I had to copy this dmesg by hand, so please bear with any > > > > possible typos. > > > > > > Please try the attached diff. The crash was due to what I consider a > > > driver bug (not checking the error in the bus_dmamap_load() callback)= , > > > however due to the FreeBSD busdma API being largely undocumented it i= s > > > a bit difficult to tell what should be considered legal. Much more > > > problematic is to assume that the first segment's bus address will be > > > 0 in the error case. This is not currently guaranteed by any > > > implementation. > > > > > > The attached patch fixes that, and also passes a valid pointer to the > > > callback for maximum compatability. It also fixes some other bugs I > > > came across. > > > > > > This does however still not address the reason for the > > > bus_dmamap_load() failure; I'm not really sure why this does > > > happen. Please look for messages like: > > > __sym_calloc2: failed to allocate ... > > > and tell me if you see any of them. > > > > Thanks for the patches! Unfortunately however, it still doesn't seem to > > attach sym1 quite right, I believe. Your patches did make the booting > > process advance further, but the kernel failed to mount root. Here is t= he > > dmesg, once again manually copied. That __sym_calloc2 message is right = on > > the second line. > > Hmmm, that's what I expected. Can you please try the attached patch > instead? It adds some more error reporting, so I should be able to see > what exactly is going wrong. Please mail me any new lines of output > appearing directly above the __sym_calloc2 message. > > I think I've already ruled out most causes; I'm suspecting that > malloc() might be failing due to massive use of M_NOWAIT in the > related code. If less than 20K of memory is massive allocation, then your mail may well come from twenty years ago IT age and I can only be dreaming at the moment. :-) The driver fails during initialisation after having allocated less than 20K in PAGE size chunk for the controller and probably less than 2 PAGES if PAGE size is large. The _real_ cause of the breakage is likely in the code that has been changed and you may preferably look into it, in my opinion. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 12: 9:16 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F262237B401 for ; Tue, 14 Jan 2003 12:09:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BA71943F18 for ; Tue, 14 Jan 2003 12:09:12 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 28941 invoked by uid 0); 14 Jan 2003 20:09:10 -0000 Received: from p508e6a74.dip.t-dialin.net (HELO galatea.local) (80.142.106.116) by mail.gmx.net (mp016-rz3) with SMTP; 14 Jan 2003 20:09:10 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18YXOX-0000ih-00; Tue, 14 Jan 2003 21:10:46 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0EKAUiL002770; Tue, 14 Jan 2003 21:10:30 +0100 (CET) Date: Tue, 14 Jan 2003 21:10:30 +0100 From: Thomas Moestl To: =?iso-8859-1?Q?G=E9rard?= Roudier Cc: Roderick van Domburg , freebsd-sparc64@FreeBSD.ORG Subject: Re: panic: trap: fast data access mmu miss Message-ID: <20030114201030.GA947@crow.dom2ip.de> Mail-Followup-To: =?iso-8859-1?Q?G=E9rard?= Roudier , Roderick van Domburg , freebsd-sparc64@FreeBSD.ORG References: <20030112225517.GB278@crow.dom2ip.de> <20030114211838.C2122-100000@localhost.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030114211838.C2122-100000@localhost.my.domain> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2003/01/14 at 21:30:36 +0100, Gérard Roudier wrote: > > > On Sun, 12 Jan 2003, Thomas Moestl wrote: > > > On Sun, 2003/01/12 at 16:13:20 +0100, Roderick van Domburg wrote: > > > > > Running on a Sun Enterprise 250 with a single UltraSparc-II > > > > > CPU, 512 MB RAM and three Fujitsu SCSI-II hard disks. I've had > > > > > this same problem with sources over the past few (three?) days. > > > > > I had to copy this dmesg by hand, so please bear with any > > > > > possible typos. > > > > > > > > Please try the attached diff. The crash was due to what I consider a > > > > driver bug (not checking the error in the bus_dmamap_load() callback), > > > > however due to the FreeBSD busdma API being largely undocumented it is > > > > a bit difficult to tell what should be considered legal. Much more > > > > problematic is to assume that the first segment's bus address will be > > > > 0 in the error case. This is not currently guaranteed by any > > > > implementation. > > > > > > > > The attached patch fixes that, and also passes a valid pointer to the > > > > callback for maximum compatability. It also fixes some other bugs I > > > > came across. > > > > > > > > This does however still not address the reason for the > > > > bus_dmamap_load() failure; I'm not really sure why this does > > > > happen. Please look for messages like: > > > > __sym_calloc2: failed to allocate ... > > > > and tell me if you see any of them. > > > > > > Thanks for the patches! Unfortunately however, it still doesn't seem to > > > attach sym1 quite right, I believe. Your patches did make the booting > > > process advance further, but the kernel failed to mount root. Here is the > > > dmesg, once again manually copied. That __sym_calloc2 message is right on > > > the second line. > > > > Hmmm, that's what I expected. Can you please try the attached patch > > instead? It adds some more error reporting, so I should be able to see > > what exactly is going wrong. Please mail me any new lines of output > > appearing directly above the __sym_calloc2 message. > > > > I think I've already ruled out most causes; I'm suspecting that > > malloc() might be failing due to massive use of M_NOWAIT in the > > related code. > > If less than 20K of memory is massive allocation, then your mail may well > come from twenty years ago IT age and I can only be dreaming at the > moment. :-) > > The driver fails during initialisation after having allocated less than > 20K in PAGE size chunk for the controller and probably less than 2 PAGES > if PAGE size is large. I was not refering to sym alone. The IOMMU code itself also uses M_NOWAIT to allocate DVMA memory and resource descriptors, and it's not unlikely that previosly intialized drivers have used it and drained the pool. The last round of updates increased the number of allocations the IOMMU code does, hence this suspicion (it turns out to be rather unlikely after reading some more allocator code though :) - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 14:48:29 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ADF237B401 for ; Tue, 14 Jan 2003 14:48:28 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34D4843EB2 for ; Tue, 14 Jan 2003 14:48:27 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0EMmPu4001074 for ; Tue, 14 Jan 2003 14:48:26 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 14 Jan 2003 14:48:25 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: sparc@freebsd.org Subject: Sparc64 floating point questions Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think that the CVSup failure one person reported was caused by the fact that I'm not currently saving/restoring the floating point state on thread context switches. I need to find out how to do that. It looks like if I save and restore the FSR and the FPRS and %q0 through %q60, that will do it. Am I missing anything? What is the most straightforward way to save all of the %qN registers? Like this? stq %q0, ... stq %q4, ... stq %q8, ... [...] stq %q60, ... Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 15:17:40 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7720C37B405; Tue, 14 Jan 2003 15:17:38 -0800 (PST) Received: from blueyonder.co.uk (pcow034o.blueyonder.co.uk [195.188.53.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0E7143EB2; Tue, 14 Jan 2003 15:17:36 -0800 (PST) (envelope-from freebsd.dev@blueyonder.co.uk) Received: from blueyonder.co.uk ([80.192.78.208]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 14 Jan 2003 23:18:42 +0000 Message-ID: <3E249A88.7030109@blueyonder.co.uk> Date: Tue, 14 Jan 2003 23:17:28 +0000 From: Keith Jones User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20030111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Lambert Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113200018.P11690-100000@gamplex.bde.org> <3E2321CF.A5835FCD@mindspring.com> In-Reply-To: <20030113200018.P11690-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > If a legacy application stops working because a system changes, > it's the fault of the system doing the changing, not the fault of > the people back in 1984 who didn't know ANSI was going to bung-up > the C language until their application no longer worked. > > There has to be some allowance for the continuity of code; it > can't just be orphaned instantaneously, without some warning > from the system vendor. I'm new to this list, so apologies if this has been stated before, but having just discovered that /usr/include/malloc.h has gone from being merely deprecated (in -STABLE) to obsolete (in -RC), I'm with Terry on this one. Yes it may be the right thing to do from a standards point of view, but there's still a lot of legacy code out there that uses it. (And a lot of new code too, I'll bet, since malloc.h still works fine and dandy on Linux, and despite the fact that the man page has said '#include ' for a few years now, developers still fail to RTFM, it appears.) Okay, it's only a small thing, but if you have too many of these small things to deal with at once, you're in porting Hell. ;) Keith To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 16:28:59 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F05DB37B401 for ; Tue, 14 Jan 2003 16:28:47 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D842043F5B for ; Tue, 14 Jan 2003 16:28:45 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 24468 invoked by uid 0); 15 Jan 2003 00:28:38 -0000 Received: from p508e6a74.dip.t-dialin.net (HELO galatea.local) (80.142.106.116) by mail.gmx.net (mp018-rz3) with SMTP; 15 Jan 2003 00:28:38 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18YbRi-0001K7-00; Wed, 15 Jan 2003 01:30:18 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0F0UEbx005090; Wed, 15 Jan 2003 01:30:14 +0100 (CET) Date: Wed, 15 Jan 2003 01:30:14 +0100 From: Thomas Moestl To: John Polstra Cc: sparc@freebsd.org Subject: Re: Sparc64 floating point questions Message-ID: <20030115003013.GA3536@crow.dom2ip.de> Mail-Followup-To: John Polstra , sparc@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, 2003/01/14 at 14:48:25 -0800, John Polstra wrote: > I think that the CVSup failure one person reported was caused by the > fact that I'm not currently saving/restoring the floating point state > on thread context switches. Hmmm, how do you switch contexts? If it's voluntary in some form (i.e. using a function call like longjmp()), you do not need to save, as the floating-point registers are not preserved across function calls (so the compiler should save and reload them across calls as needed, unless that's different for m3). When switching by signals in some form, sendsig() should save the registers in the signal context, so this should be safe when restoring the context by returning from the signal handler. However, this saving is not currently done, which is a bug. The attached patch should fix this (it also implements getcontext() and setcontext(), setcontext() will not work for ucontexts from signals and some optimizing remains to be done though). > I need to find out how to do that. It > looks like if I save and restore the FSR and the FPRS and %q0 through > %q60, that will do it. Am I missing anything? Yes, that should do it. > What is the most straightforward way to save all of the %qN registers? > Like this? > > stq %q0, ... > stq %q4, ... > stq %q8, ... > [...] > stq %q60, ... Yes, unless you want to use UltraSPARC specific instructions. Then, you could do: wr %g0, ASI_BLK_P, %asi stda %f0, [...] %asi stda %f16, [...] %asi stda %f32, [...] %asi stda %f48, [...] %asi This stores 16 floating-point registers at a time, i.e. 64 bytes, which is a complete 2nd-level-cache line, so it should be faster. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ctx2.diff" Index: include/cache.h =================================================================== RCS file: /ncvs/src/sys/sparc64/include/cache.h,v retrieving revision 1.6 diff -u -r1.6 cache.h --- include/cache.h 20 May 2002 16:30:46 -0000 1.6 +++ include/cache.h 9 Jan 2003 23:10:53 -0000 @@ -99,8 +99,8 @@ void dcache_inval(pmap_t, vm_offset_t, vm_offset_t); void dcache_inval_phys(vm_offset_t, vm_offset_t); void dcache_blast(void); -void ecache_flush(vm_offset_t, vm_offset_t); #if 0 +void ecache_flush(vm_offset_t, vm_offset_t); void ecache_inval_phys(vm_offset_t, vm_offset_t); #endif Index: include/fp.h =================================================================== RCS file: /ncvs/src/sys/sparc64/include/fp.h,v retrieving revision 1.8 diff -u -r1.8 fp.h --- include/fp.h 8 Jun 2002 07:17:18 -0000 1.8 +++ include/fp.h 9 Jan 2003 23:27:22 -0000 @@ -45,8 +45,8 @@ * Note: The pointers passed to the next two functions must be aligned on * 64 byte boundaries. */ -void savefpctx(struct fpstate *); -void restorefpctx(struct fpstate *); +void savefpregs(struct fpstate *); +void savefpctx(struct thread *); #endif /* _KERNEL */ #endif /* !_MACHINE_FP_H_ */ Index: include/pcb.h =================================================================== RCS file: /ncvs/src/sys/sparc64/include/pcb.h,v retrieving revision 1.12 diff -u -r1.12 pcb.h --- include/pcb.h 19 Oct 2002 15:54:34 -0000 1.12 +++ include/pcb.h 9 Jan 2003 23:00:31 -0000 @@ -37,6 +37,7 @@ /* NOTE: pcb_fpstate must be aligned on a 64 byte boundary. */ struct pcb { struct fpstate pcb_fpstate; + u_long pcb_fpsaved; u_long pcb_fp; u_long pcb_pc; u_long pcb_nsaved; Index: include/ucontext.h =================================================================== RCS file: /ncvs/src/sys/sparc64/include/ucontext.h,v retrieving revision 1.8 diff -u -r1.8 ucontext.h --- include/ucontext.h 10 Jan 2003 00:04:56 -0000 1.8 +++ include/ucontext.h 14 Jan 2003 23:47:40 -0000 @@ -42,16 +42,24 @@ typedef struct __mcontext mcontext_t; +/* Common. */ #define mc_flags mc_global[0] -#define mc_sp mc_out[6] -#define mc_fprs mc_local[0] -#define mc_fsr mc_local[1] -#define mc_gsr mc_local[2] -#define mc_tnpc mc_in[0] -#define mc_tpc mc_in[1] -#define mc_tstate mc_in[2] -#define mc_y mc_in[4] -#define mc_wstate mc_in[5] +#define mc_sp mc_out[6] + +/* Signal contexts only. */ +#define mcs_fprs mc_local[0] +#define mcs_fsr mc_local[1] +#define mcs_gsr mc_local[2] +#define mcs_tnpc mc_in[0] +#define mcs_tpc mc_in[1] +#define mcs_tstate mc_in[2] +#define mcs_y mc_in[4] +#define mcs_wstate mc_in[5] + +/* Regular user contexts only. */ +#define mcu_tpc mc_out[0] +#define mcu_tnpc mc_out[1] +#define mcu_pc mc_out[7] #define _MC_VERSION_SHIFT 0 #define _MC_VERSION_BITS 32 @@ -60,5 +68,6 @@ #define _MC_FLAGS_SHIFT 32 #define _MC_FLAGS_BITS 32 #define _MC_VOLUNTARY ((1L << 0) << _MC_FLAGS_SHIFT) +#define _MC_FP ((1L << 1) << _MC_FLAGS_SHIFT) #endif /* !_MACHINE_UCONTEXT_H_ */ Index: sparc64/cache.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/cache.c,v retrieving revision 1.14 diff -u -r1.14 cache.c --- sparc64/cache.c 5 Jan 2003 05:30:40 -0000 1.14 +++ sparc64/cache.c 10 Jan 2003 17:11:24 -0000 @@ -430,6 +430,7 @@ stxa_sync(dca, ASI_DCACHE_TAG, 0); } +#if 0 /* Flush an E$ physical range using block commit stores. */ void ecache_flush(vm_offset_t start, vm_offset_t end) @@ -439,8 +440,8 @@ if (!cache.c_enabled) return; - /* XXX: not needed in all cases, provide a wrapper in fp.c */ - savefpctx(&curthread->td_pcb->pcb_fpstate); + critical_enter(); + savefpctx(curthread); wr(fprs, 0, FPRS_FEF); for (addr = start & ~(cache.ec_linesize - 1); addr <= end; @@ -451,10 +452,10 @@ } membar(Sync); - restorefpctx(&curthread->td_pcb->pcb_fpstate); + wr(fprs, 0, 0); + critical_enter(); } -#if 0 /* * Invalidate an E$ range using diagnostic accesses. * This is disabled: it suffers from the same races as dcache_blast() and Index: sparc64/exception.S =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/exception.S,v retrieving revision 1.57 diff -u -r1.57 exception.S --- sparc64/exception.S 29 Dec 2002 00:23:48 -0000 1.57 +++ sparc64/exception.S 10 Jan 2003 18:02:02 -0000 @@ -458,16 +458,21 @@ .endm .macro tl0_fp_restore - wr %g0, FPRS_FEF, %fprs + ba %xcc, tl0_fp_restore + wr %g0, FPRS_FEF, %fprs + .align 32 + .endm + +ENTRY(tl0_fp_restore) wr %g0, ASI_BLK_S, %asi ldda [PCB_REG + PCB_FPSTATE + FP_FB0] %asi, %f0 ldda [PCB_REG + PCB_FPSTATE + FP_FB1] %asi, %f16 ldda [PCB_REG + PCB_FPSTATE + FP_FB2] %asi, %f32 ldda [PCB_REG + PCB_FPSTATE + FP_FB3] %asi, %f48 membar #Sync + stx %g0, [PCB_REG + PCB_FPSAVED] done - .align 32 - .endm +END(tl0_fp_restore) .macro tl0_insn_excptn wrpr %g0, PSTATE_ALT, %pstate Index: sparc64/genassym.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/genassym.c,v retrieving revision 1.45 diff -u -r1.45 genassym.c --- sparc64/genassym.c 28 Dec 2002 23:58:18 -0000 1.45 +++ sparc64/genassym.c 9 Jan 2003 22:57:15 -0000 @@ -250,6 +250,7 @@ ASSYM(PCB_NSAVED, offsetof(struct pcb, pcb_nsaved)); ASSYM(PCB_RWSP, offsetof(struct pcb, pcb_rwsp)); ASSYM(PCB_RW, offsetof(struct pcb, pcb_rw)); +ASSYM(PCB_FPSAVED, offsetof(struct pcb, pcb_fpsaved)); ASSYM(VM_PMAP, offsetof(struct vmspace, vm_pmap)); ASSYM(PM_ACTIVE, offsetof(struct pmap, pm_active)); Index: sparc64/machdep.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/machdep.c,v retrieving revision 1.75 diff -u -r1.75 machdep.c --- sparc64/machdep.c 10 Jan 2003 00:04:56 -0000 1.75 +++ sparc64/machdep.c 15 Jan 2003 00:06:37 -0000 @@ -92,6 +92,7 @@ #include #include #include +#include #include #include #include @@ -365,6 +366,7 @@ struct sigframe *sfp; struct sigacts *psp; struct sigframe sf; + mcontext_t *mcp; struct thread *td; struct frame *fp; struct proc *p; @@ -399,7 +401,16 @@ sf.sf_uc.uc_stack = p->p_sigstk; sf.sf_uc.uc_stack.ss_flags = (p->p_flag & P_ALTSTACK) ? ((oonstack) ? SS_ONSTACK : 0) : SS_DISABLE; - bcopy(tf, &sf.sf_uc.uc_mcontext, sizeof(*tf)); + + savefpctx(td); + mcp = &sf.sf_uc.uc_mcontext; + mcp->mc_flags = 0; + bcopy(tf, mcp, sizeof(*tf)); + if (td->td_pcb->pcb_fpsaved) { + bcopy(&td->td_pcb->pcb_fpstate, &mcp->mc_fp, + sizeof(mcp->mc_fp)); + mcp->mc_flags |= _MC_FP; + } /* Allocate and validate space for the signal handler context. */ if ((p->p_flag & P_ALTSTACK) != 0 && !oonstack && @@ -455,6 +466,28 @@ }; #endif +static int +set_sigmcontext(struct thread *td, const mcontext_t *mcp) +{ + uint64_t wstate; + int error; + + if ((error = rwindow_save(td)) != 0) + return (error); + + if (!TSTATE_SECURE(mcp->mcs_tstate)) + return (EINVAL); + wstate = td->td_frame->tf_wstate; + bcopy(mcp, td->td_frame, sizeof(*td->td_frame)); + td->td_frame->tf_wstate = wstate; + if ((mcp->mc_flags & _MC_FP) != 0) { + td->td_frame->tf_fprs &= ~FPRS_FEF; + bcopy(&mcp->mc_fp, &td->td_pcb->pcb_fpstate, + sizeof(td->td_pcb->pcb_fpstate)); + } + return (0); +} + /* * MPSAFE */ @@ -463,14 +496,11 @@ { struct trapframe *tf; struct proc *p; - mcontext_t *mc; ucontext_t uc; + int error; p = td->td_proc; - if (rwindow_save(td)) { - PROC_LOCK(p); - sigexit(td, SIGILL); - } + tf = td->td_frame; CTR2(KTR_SIG, "sigreturn: td=%p ucp=%p", td, uap->sigcntxp); if (copyin(uap->sigcntxp, &uc, sizeof(uc)) != 0) { @@ -478,12 +508,8 @@ return (EFAULT); } - mc = &uc.uc_mcontext; - tf = td->td_frame; - if (!TSTATE_SECURE(mc->mc_tstate)) - return (EINVAL); - mc->mc_wstate = tf->tf_wstate; - bcopy(mc, tf, sizeof(*tf)); + if ((error = set_sigmcontext(td, &uc.uc_mcontext)) != 0) + return (error); PROC_LOCK(p); p->p_sigmask = uc.uc_sigmask; @@ -508,15 +534,49 @@ int get_mcontext(struct thread *td, mcontext_t *mcp) { + struct trapframe *tf; + struct frame *f; + int error; - return (ENOSYS); + /* + * Need to save the ins and locals of the caller; gcc does not know + * that getcontext() is magic and will not discard them after the call. + */ + tf = td->td_frame; + f = (struct frame *)(uintptr_t)(tf->tf_sp + SPOFF); + if ((error = rwindow_save(td)) != 0 || + (error = copyin(&f->fr_local, &mcp->mc_local, + sizeof(f->fr_local) + sizeof(f->fr_in)) != 0)) + return (error); + mcp->mc_sp = tf->tf_sp; + mcp->mcu_pc = tf->tf_out[7]; + mcp->mcu_tpc = tf->tf_tpc; + mcp->mcu_tnpc = tf->tf_tnpc; + mcp->mc_flags = _MC_VOLUNTARY; + return (0); } int set_mcontext(struct thread *td, const mcontext_t *mcp) { + struct trapframe *tf; + struct frame *f; + int error; - return (ENOSYS); + /* Handle return from signal. */ + if ((mcp->mc_flags & _MC_VOLUNTARY) == 0) + return (set_sigmcontext(td, mcp)); + tf = td->td_frame; + f = (struct frame *)(uintptr_t)(mcp->mc_sp + SPOFF); + if ((error = rwindow_save(td)) != 0 || + (error = copyout(&mcp->mc_local, &f->fr_local, + sizeof(f->fr_local) + sizeof(f->fr_in)) != 0)) + return (error); + tf->tf_sp = mcp->mc_sp; + tf->tf_out[7] = mcp->mcu_pc; + tf->tf_tpc = mcp->mcu_tpc; + tf->tf_tnpc = mcp->mcu_tnpc; + return (0); } /* @@ -696,4 +756,18 @@ tf->tf_fsr = fpregs->fr_fsr; tf->tf_gsr = fpregs->fr_gsr; return (0); +} + +void +savefpctx(struct thread *td) +{ + struct pcb *pcb = td->td_pcb; + + critical_enter(); + if ((td->td_frame->tf_fprs & FPRS_FEF) != 0) { + savefpregs(&pcb->pcb_fpstate); + pcb->pcb_fpsaved = 1; + td->td_frame->tf_fprs &= ~FPRS_FEF; + } + critical_exit(); } Index: sparc64/swtch.S =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/swtch.S,v retrieving revision 1.22 diff -u -r1.22 swtch.S --- sparc64/swtch.S 22 Oct 2002 18:03:15 -0000 1.22 +++ sparc64/swtch.S 9 Jan 2003 23:27:51 -0000 @@ -74,6 +74,7 @@ stda %f48, [%l1 + PCB_FPSTATE + FP_FB3] %asi membar #Sync wr %g0, 0, %fprs + stx %l3, [%l1 + PCB_FPSAVED] andn %l3, FPRS_FEF, %l3 stx %l3, [%l2 + TF_FPRS] @@ -269,8 +270,8 @@ ENTRY(savectx) save %sp, -CCFSZ, %sp flushw - call savefpctx - mov %i0, %o0 + call savefpregs + add %i0, PCB_FPSTATE, %o0 stx %fp, [%i0 + PCB_FP] stx %i7, [%i0 + PCB_PC] ret @@ -280,29 +281,14 @@ /* * void savefpctx(struct fpstate *); */ -ENTRY(savefpctx) +ENTRY(savefpregs) wr %g0, FPRS_FEF, %fprs wr %g0, ASI_BLK_S, %asi - stda %f0, [%o0 + PCB_FPSTATE + FP_FB0] %asi - stda %f16, [%o0 + PCB_FPSTATE + FP_FB1] %asi - stda %f32, [%o0 + PCB_FPSTATE + FP_FB2] %asi - stda %f48, [%o0 + PCB_FPSTATE + FP_FB3] %asi + stda %f0, [%o0 + FP_FB0] %asi + stda %f16, [%o0 + FP_FB1] %asi + stda %f32, [%o0 + FP_FB2] %asi + stda %f48, [%o0 + FP_FB3] %asi membar #Sync retl wr %g0, 0, %fprs -END(savefpctx) - -/* - * void restorefpctx(struct fpstate *); - */ -ENTRY(restorefpctx) - wr %g0, FPRS_FEF, %fprs - wr %g0, ASI_BLK_S, %asi - ldda [%o0 + PCB_FPSTATE + FP_FB0] %asi, %f0 - ldda [%o0 + PCB_FPSTATE + FP_FB1] %asi, %f16 - ldda [%o0 + PCB_FPSTATE + FP_FB2] %asi, %f32 - ldda [%o0 + PCB_FPSTATE + FP_FB3] %asi, %f48 - membar #Sync - retl - wr %g0, 0, %fprs -END(restorefpctx) +END(savefpregs) Index: sparc64/vm_machdep.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/vm_machdep.c,v retrieving revision 1.32 diff -u -r1.32 vm_machdep.c --- sparc64/vm_machdep.c 5 Jan 2003 05:30:40 -0000 1.32 +++ sparc64/vm_machdep.c 9 Jan 2003 23:14:32 -0000 @@ -181,11 +181,7 @@ /* * Ensure that p1's pcb is up to date. */ - if ((td1->td_frame->tf_fprs & FPRS_FEF) != 0) { - mtx_lock_spin(&sched_lock); - savefpctx(&pcb1->pcb_fpstate); - mtx_unlock_spin(&sched_lock); - } + savefpctx(td1); /* Make sure the copied windows are spilled. */ flushw(); /* Copy the pcb (this will copy the windows saved in the pcb, too). */ --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 16:47:28 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BD2737B401 for ; Tue, 14 Jan 2003 16:47:26 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F9243ED8 for ; Tue, 14 Jan 2003 16:47:24 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0F0lNu5001463 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Jan 2003 16:47:23 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0F0lNFc037477; Tue, 14 Jan 2003 16:47:23 -0800 (PST) (envelope-from jdp) Date: Tue, 14 Jan 2003 16:47:23 -0800 (PST) Message-Id: <200301150047.h0F0lNFc037477@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: tmoestl@gmx.net Subject: Re: Sparc64 floating point questions In-Reply-To: <20030115003013.GA3536@crow.dom2ip.de> References: <20030115003013.GA3536@crow.dom2ip.de> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20030115003013.GA3536@crow.dom2ip.de>, Thomas Moestl wrote: > On Tue, 2003/01/14 at 14:48:25 -0800, John Polstra wrote: > > I think that the CVSup failure one person reported was caused by the > > fact that I'm not currently saving/restoring the floating point state > > on thread context switches. > > Hmmm, how do you switch contexts? If it's voluntary in some form > (i.e. using a function call like longjmp()), you do not need to save, > as the floating-point registers are not preserved across function > calls (so the compiler should save and reload them across calls as > needed, unless that's different for m3). It's not always voluntary. Timer signals are used for pre-emption. Though as a temporary work-around, cvsup can be made non-pre-emptive by adding the magic argument "@M3nopreemption" to the command line. It works OK like that, since it is so I/O intensive. > When switching by signals in some form, sendsig() should save > the registers in the signal context, so this should be safe when > restoring the context by returning from the signal handler. > However, this saving is not currently done, which is a bug. OK, I think that must be the problem. By the way, I know that at some point in the past the FP state was not saved on the i386 when signal handlers were invoked. It was definitely necessary to save the FP state when switching threads in the i386 port of Modula-3. I seem to recall that somebody may have changed the kernel to preserve the FP state since that time. > The attached patch should fix this (it also implements getcontext() > and setcontext(), setcontext() will not work for ucontexts from > signals and some optimizing remains to be done though). Thanks for the patch. I am not in a good position to test it, because I don't have a Sparc box myself. I've just been using panther.freebsd.org. I think at least for now I'll just explicitly save all of the FP registers when I switch threads. That way this thing should stand a chance of working with 5.0-RELEASE. > > I need to find out how to do that. It > > looks like if I save and restore the FSR and the FPRS and %q0 through > > %q60, that will do it. Am I missing anything? > > Yes, that should do it. Good, and thanks. > Yes, unless you want to use UltraSPARC specific instructions. Then, > you could do: > > wr %g0, ASI_BLK_P, %asi > stda %f0, [...] %asi > stda %f16, [...] %asi > stda %f32, [...] %asi > stda %f48, [...] %asi > > This stores 16 floating-point registers at a time, i.e. 64 bytes, > which is a complete 2nd-level-cache line, so it should be faster. I don't know much about Sparc machines. But it sounds like there exist 64-bit Sparcs which are not UltraSPARCs. So I'd better do it the most general way. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 16:53:21 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E14EB37B401 for ; Tue, 14 Jan 2003 16:53:20 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28AD743ED8 for ; Tue, 14 Jan 2003 16:53:20 -0800 (PST) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0F0rJu4001486 for ; Tue, 14 Jan 2003 16:53:19 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 14 Jan 2003 16:53:19 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: sparc@freebsd.org Subject: Work-around for random CVSup/sparc64 failures Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org One person has reported a non-reproduceable CVSup failure on the sparc64 platform which produced this message: > *** > *** runtime error: > *** Value out of range > *** file "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > *** I am pretty sure this is a problem with the current thread switching code in the Modula-3 runtime system. It could produce various symptoms, including the above. As a work-around until I fix the bug, you should add an extra argument "@M3nopreemption" to the cvsup command line, like this: cvsup -L 2 supfile @M3nopreemption I'm fairly certain that will prevent the failures. Please let me know if it doesn't. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 17:32:25 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEFE237B401 for ; Tue, 14 Jan 2003 17:32:23 -0800 (PST) Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F4D443E4A for ; Tue, 14 Jan 2003 17:32:22 -0800 (PST) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from wit377002 (wit377002.student.utwente.nl [130.89.165.107]) by netlx010.civ.utwente.nl (8.11.4/HKD) with SMTP id h0F1WIb32521 for ; Wed, 15 Jan 2003 02:32:18 +0100 From: "Roderick van Domburg" To: "FreeBSD-sparc@FreeBSD. ORG" Subject: vinum seems to work Date: Wed, 15 Jan 2003 02:32:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-UTwente-MailScanner: Found to be clean Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, I wanted to let you know that vinum seems to work just fine on sparc64. I've got a two-disk concatenation running right now and it does the job without moaning. Roderick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 18:15:34 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D7C37B401 for ; Tue, 14 Jan 2003 18:15:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AD7743EB2 for ; Tue, 14 Jan 2003 18:15:32 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 8657 invoked by uid 0); 15 Jan 2003 02:15:30 -0000 Received: from p508e6a74.dip.t-dialin.net (HELO galatea.local) (80.142.106.116) by mail.gmx.net (mp008-rz3) with SMTP; 15 Jan 2003 02:15:30 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18Yd78-0001hv-00; Wed, 15 Jan 2003 03:17:10 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0F2H6xo006566; Wed, 15 Jan 2003 03:17:06 +0100 (CET) Date: Wed, 15 Jan 2003 03:17:06 +0100 From: Thomas Moestl To: John Polstra Cc: sparc@freebsd.org Subject: Re: Sparc64 floating point questions Message-ID: <20030115021706.GA5902@crow.dom2ip.de> Mail-Followup-To: John Polstra , sparc@freebsd.org References: <20030115003013.GA3536@crow.dom2ip.de> <200301150047.h0F0lNFc037477@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301150047.h0F0lNFc037477@vashon.polstra.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 2003/01/14 at 16:47:23 -0800, John Polstra wrote: > In article <20030115003013.GA3536@crow.dom2ip.de>, > Thomas Moestl wrote: > > On Tue, 2003/01/14 at 14:48:25 -0800, John Polstra wrote: > > > I need to find out how to do that. It > > > looks like if I save and restore the FSR and the FPRS and %q0 through > > > %q60, that will do it. Am I missing anything? > > > > Yes, that should do it. > > Good, and thanks. Oh, I should have mentioned that %fprs is a bit special; the kernel uses the FEF bit to test whether floating point support is enabled for the process, and will only save the state across context switches in that case. It will also lazily restore the context, i.e. it will disable the FEF bit and reload the registers only when the process uses floating point operations for the next time (which triggers an exception in that case). That means that %fprs must be restored first, otherwise this might clear FEF and cause stale values to be reloaded later. In fact, you do not need to save it at all; the only other bits in that register are the DU (upper fp register file half dirty) and DL (lower half dirty) bits, which are automatically maintained. For performance, it would probably be best to always just set the FEF bit before reloading the other registers (this is not required though), like: wr %g0, FPRS_FEF, %fprs - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Tue Jan 14 23:32:39 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A18437B401 for ; Tue, 14 Jan 2003 23:32:38 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 626EB43E4A for ; Tue, 14 Jan 2003 23:32:30 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (smmsp@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0F4Xijb014660 for ; Tue, 14 Jan 2003 23:33:44 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0EIO7sD013975; Tue, 14 Jan 2003 13:24:07 -0500 (EST) Date: Tue, 14 Jan 2003 13:24:07 -0500 From: Jake Burkholder To: John Polstra Cc: sparc@FreeBSD.ORG Subject: Re: CVSup/sparc64: Come and get it! Message-ID: <20030114132407.A12327@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdp@polstra.com on Mon, Jan 13, 2003 at 04:10:06PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Mon, Jan 13, 2003 at 04:10:06PM -0800, John Polstra said words to the effect of; > Drum roll, please ... > > After much weeping and wailing and gnashing of teeth, I've gotten > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > It seems to work just fine, but I've hardly tested it at all. So be > careful out there. Awesome! Thanks very much for your hard work. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Wed Jan 15 0:58:43 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABC0337B401 for ; Wed, 15 Jan 2003 00:58:40 -0800 (PST) Received: from one.2531.org (w005.z064003115.lax-ca.dsl.cnc.net [64.3.115.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BE6343F5B for ; Wed, 15 Jan 2003 00:58:34 -0800 (PST) (envelope-from mmca@2531.org) Received: from 2531.org (localhost.2531.org [127.0.0.1]) by one.2531.org (8.12.6/8.12.6) with ESMTP id h0F8wYRC028036; Wed, 15 Jan 2003 00:58:38 -0800 (PST) (envelope-from mmca@2531.org) Message-Id: <200301150858.h0F8wYRC028036@one.2531.org> Date: Wed, 15 Jan 2003 00:58:34 -0800 (PST) From: mmca@2531.org Subject: Re: CVSup/sparc64: Come and get it! To: jdp@polstra.com Cc: sparc@FreeBSD.ORG In-Reply-To: <20030114002110.GG16775@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra wrote: > Drum roll, please ... > > After much weeping and wailing and gnashing of teeth, I've gotten > CVSup working on FreeBSD/sparc64 platforms. You can grab the client > executable from here: > > http://people.freebsd.org/~jdp/cvsup-sparc64/ > > It seems to work just fine, but I've hardly tested it at all. So be > careful out there. > cvsup worked great for /usr/src but while syncing ports I also got: Edit ports/mail/tmda/Makefile *** *** runtime error: *** Value out of range *** file "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 70 *** use option @M3stackdump to get a stack trace Abort (core dumped) I am going to rm ports and try to reproduce this error. -M -------------------- uname -a FreeBSD sol.2531.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jan 15 02:20:31 GMT 2003 mmca@:/usr/obj/usr/src/sys/SOL sparc64 dmesg 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 #0: Wed Jan 15 02:20:31 GMT 2003 mmca@:/usr/obj/usr/src/sys/SOL Preloaded elf kernel "/boot/kernel/kernel" at 0xc035e000. Timecounter "tick" frequency 333000000 Hz cpu0: Sun Microsystems UltraSparc-IIi Processor (333.00 MHz CPU) Model: SUNW,Ultra-5_10 Initializing GEOMetry subsystem nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0 DVMA map: 0xc0000000 to 0xc1ffffff 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) ebus0: addr 0x1400400000-0x140040007f irq 43 (no driver attached) 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 80a28314 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 hme0: Ethernet address: 08:00:20:a2:83:14 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 Timecounters tick every 10.000 msec ad0: 8693MB [17662/16/63] at ata2-master WDMA2 ad1: 8693MB [17662/16/63] at ata2-slave WDMA2 acd0: CDROM at ata3-master PIO4 Mounting root from ufs:/dev/ad0a pid 455 (cvsup), uid 0: exited on signal 6 (core dumped) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Wed Jan 15 5:19:53 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B170337B401; Wed, 15 Jan 2003 05:19:50 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 857C843ED8; Wed, 15 Jan 2003 05:19:49 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA04471; Thu, 16 Jan 2003 00:19:26 +1100 Date: Thu, 16 Jan 2003 00:20:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: Terry Lambert , Jake Burkholder , , Subject: Re: [PATCH] Re: fpsetmask on sparc64 In-Reply-To: <20030113204505.GA798@dhcp01.pn.xcllnt.net> Message-ID: <20030115233615.Y23066-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 13 Jan 2003, Marcel Moolenaar wrote: > On Mon, Jan 13, 2003 at 10:21:59PM +1100, Bruce Evans wrote: > > > > > > This part is what makes me opt for moving the prototypes to the > > > MD header. These functions are trivial most of the time that > > > inlining them makes sense. I don't see why other platforms can't > > > or won't inline in the future. > > > > Hand-inlining things rarely makes sense, especially for little-used > > compatibility-cruft functions like these. > > Aahh.. But by hand-inlining compatibility cruft, you remove them > from the ABI! You only have them in the API, which is the lesser > evil of the two when you want to remove the compatibility cruft > completely. Good point. I had intended to implement the compatibility cruft as calls to the new (extern) interfaces or possibly as just weak aliases. > > A technical reason for not inlining some of them is that they may need > > to interact with signal handling. > > I don't see how this is related. The only advantage of not inlining > is the ability to declare the functions as weak so that they can be > overridden. In all other cases it's just an implementation detail > that should not affect the functionality. > > > We currently avoid most signal-handling > > problems related to changing the FP environment by switching the critical > > part of the environment in setjmp/longjmp, at least on i386's, but C99 > > seems to forbid this. I think the functions that change the FP environment > > need to save their setting somehwere so that longjmp() can restore the > > default FP environment (not necessarily the one when setjmp() was called). > > I don't know how to do this properly reentrantly. > > On ia64 the FP environment is callee saved and thus put in jmpbuf. This may be a bug. Putting things in jmpbuf results in the local environment being restored by longjmp(), but some readings of the C standard require feset*() to alter a global environment which must not be affected by setjmp()/longjump(). > The general modus operandi seems that functions either use the > settings as inherited, or otherwise explicitly set them. This also > applies to signal handlers. Thus when the FP environment is changed > at function entry, the only action required is to restore the FP > environment at function exit. Restoring the FP environment on function exit would clearly be wrong for normal functions, since the function might have called feset*(). longmp() is different because it is specified to restore the environment saved by setjmp(). The C standard also specifies that functions do not change the FP modes or flags unless the function is documented to change them and the issue is whether restoring the environment saved by setjmp() includes the FP environment. I don't see how longjmp() can work right unless it restores either the local environment saved by setjmp() or a at least a global environment saved by feset*() later. E.g., gcc implements float-to-int conversions by temporarily switching the rounding mode. longjmp() from a signal handler that interrupts the conversion must restore the mode to a default since the inline code that restores it will not be reached. This seems to be still broken in glibc-2.2.5 on i386's. Most arches hopefully don't have this problem because the rounding mode can be set for individual instructions and/or there are special instructions for doing the conversions. FreeBSD on i386's restores only the control word in longjmp(). It clobbers the status word. Not touching at least the exception flags in the status word seems to be right. The exception flags are supposed to be sticky and clearing them in longjmp() breaks this. > > > Also, it appears to me that we always have to provide non-inlined > > > versions in libc for when inlining is disabled. See ctype.h. > > > I may misinterpret the comment though... > > > > Non-inline versions are needed for at least calling functions through > > function pointers if this is supported, and C requires it to be supported > > for most functions including the ctype 1's. This requirement causes > > some of the implementation complications in . > > I see. Using static inline functions rather than macros should mostly > solve this. Function pointer comparison will not work though, but I > don't know if it has to. I think it doesn't in C90+gcc at least, but having lots of static copies of the same function bloats the code and is painful to debug. C99's inline functions are a little different from gcc's. I don't remember many details. In theory, "extern inline" is more suitable here, but C99 doesn't have it and "static inline" is easier to use. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Wed Jan 15 8:31:23 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE9F737B401 for ; Wed, 15 Jan 2003 08:31:22 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD2F843F85 for ; Wed, 15 Jan 2003 08:31:21 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0FGVIu5005313 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Jan 2003 08:31:18 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0FGVCOv038517; Wed, 15 Jan 2003 08:31:12 -0800 (PST) (envelope-from jdp) Date: Wed, 15 Jan 2003 08:31:12 -0800 (PST) Message-Id: <200301151631.h0FGVCOv038517@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: mmca@2531.org Subject: Re: CVSup/sparc64: Come and get it! In-Reply-To: <200301150858.h0F8wYRC028036@one.2531.org> References: <200301150858.h0F8wYRC028036@one.2531.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200301150858.h0F8wYRC028036@one.2531.org>, wrote: > cvsup worked great for /usr/src but while syncing ports I also got: > > Edit ports/mail/tmda/Makefile > > > *** > *** runtime error: > *** Value out of range > *** file "/s/scratch/jdp/ezm3-1.1/libs/libm3/src/uid/Common/TimeStamp.m3", line 70 > *** Thanks for the report. I found out about that bug yesterday. Until I get around to fixing it, add the argument "@M3nopreemption" to the cvsup command line (anywhere on the command line). That should work around the bug. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Wed Jan 15 10:53:35 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 108ED37B401 for ; Wed, 15 Jan 2003 10:53:34 -0800 (PST) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7955C43F75 for ; Wed, 15 Jan 2003 10:53:26 -0800 (PST) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h0FIrKf28012 for ; Wed, 15 Jan 2003 16:53:20 -0200 Message-ID: <3E25AE20.2080808@tcoip.com.br> Date: Wed, 15 Jan 2003 16:53:20 -0200 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021212 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: sparc@freebsd.org Subject: loader(8) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings, sparc people. In the hopes of providing .4th files to loader that people (other than me) can actually modify, I have been considering a regex parser, so we could introduce something like what exists in perl, sed, awk, etc. After long consideration, I came to the conclusion that the best way of providing such a thing would be importing regex into libstand. This would keep the rather complex regex code in C and avoid introducing a buggy regex implementation. Though it would be available at any point in loader, the regex interface is only done on FICL, so no FICL, no regex. The biggest drawback, by far, is the size by which it would increase loader. On i386, it's about 32 Kb. As I had to copy the regex files over to libstand, it might well be possible to further reduce this size by removing the more unlikelier options, or trading speed for space. Now, I'd like to know how the loader space constraints are looking like in the sparc architecture, and by how much this patch increase loader's size. The patch is at: http://people.freebsd.org/~dcs/regex.diff -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net There was a young monk of Dundee Who complained that it hurt him to pee, He said, "Pax vobiscum, Now why won't the piss come? I'm afraid I've the c-l-a-p." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Wed Jan 15 23:24:51 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1D1437B405; Wed, 15 Jan 2003 23:24:49 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C37F643F5B; Wed, 15 Jan 2003 23:24:48 -0800 (PST) (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 884E766E44; Wed, 15 Jan 2003 23:24:48 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 5BAA7FD6; Wed, 15 Jan 2003 23:24:48 -0800 (PST) Date: Wed, 15 Jan 2003 23:24:48 -0800 From: Kris Kennaway To: kan@FreeBSD.org, obrien@FreeBSD.org, sparc64@FreeBSD.org Subject: assembler error in XFree86 snapshot Message-ID: <20030116072448.GA29468@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm trying to compile anholt's XFree86 4.2.99 snapshot on sparc, and I get the following error message: cc -c -O -pipe -ansi -Dasm=__asm -Wall -Wpointer-arith -Wundef -I/usr/tmp/XFree86-4-libraries-devel/work/xc -I/usr/tmp/XFree86-4-libraries-devel/work/xc/exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL XRes.c {standard input}: Assembler messages: {standard input}:667: Error: relocation overflow *** Error code 1 line 667 of the .s file is: > .LL86: > umul %o0, 4294967295, %o0 and the corresponding source line is: #ifdef LONG64 *bytes = (rep.bytes_overflow * 4294967295) + rep.bytes; #else *bytes = rep.bytes_overflow ? 0xffffffff : rep.bytes; #endif Commenting out the LONG64 clause allows the build to progress. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Jl4/Wry0BWjoQKURAqbjAKDVHae9CRB7rqqkgA7q3MytXacgRgCgz66N 7NBjBurFPJ1eVzxlLqEjLuw= =J8+K -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 1:28:34 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 996B237B401 for ; Thu, 16 Jan 2003 01:28:32 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B62843ED8 for ; Thu, 16 Jan 2003 01:28:31 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0G9STM05060 for ; Thu, 16 Jan 2003 10:28:29 +0100 (MET) Date: Thu, 16 Jan 2003 10:28:29 +0100 (CET) From: Harti Brandt To: sparc@freebsd.org Subject: ahc driver and vinum work on Ultra10 Message-ID: <20030116101732.S715@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, the release notes for 5.0 say, that support for ahc(4) is coming really soon now. It appears, that an adaptec 29160N is just working out of the box if you put the ahc driver into your kernel config (see dmesg below). You just cannot boot from it (because it has no OF code). So its probably a good idea to just remove that 'coming real soon' from the hardware list. It may also make sense to enable building vinum. I reported back in december, that I found RAID0 and RAID1 to work, and there was another report on this a couple of days ago. The following patch will do that: harti Index: Makefile =================================================================== RCS file: /home/cvs/freebsd/src/sys/modules/Makefile,v retrieving revision 1.298 diff -r1.298 Makefile 274c274,275 < SUBDIR+=hme --- > SUBDIR+=hme \ > vinum kernel: Copyright (c) 1992-2003 The FreeBSD Project. kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 kernel: The Regents of the University of California. All rights reserved. kernel: FreeBSD 5.0-CURRENT #3: Tue Jan 7 18:15:41 CET 2003 kernel: root@catssrv.fokus.gmd.de:/opt/obj/usr/src/sys/CATSSRV kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc05d6000. kernel: Preloaded elf module "/boot/kernel/random.ko" at 0xc05d6170. kernel: Preloaded elf module "/boot/kernel/if_hme.ko" at 0xc05d6240. kernel: Preloaded elf module "/boot/kernel/miibus.ko" at 0xc05d6310. kernel: Timecounter "tick" frequency 333000000 Hz kernel: cpu0: Sun Microsystems UltraSparc-IIi Processor (333.00 MHz CPU) kernel: Model: SUNW,Ultra-5_10 kernel: Initializing GEOMetry subsystem kernel: nexus0: kernel: pcib0: on nexus0 kernel: pcib0: Sabre, impl 0, version 0, ign 0x7c0 kernel: DVMA map: 0xc0000000 to 0xc1ffffff kernel: pci0: on pcib0 kernel: pcib1: at device 1.0 on pci0 kernel: pci1: on pcib1 kernel: ahc0: port 0x400-0x4ff mem 0x2000-0x2fff irq 16 at device 1.0 on pci1 kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs [SNIP] kernel: Waiting 15 seconds for SCSI devices to settle kernel: da0 at ahc0 bus 0 target 1 lun 0 kernel: da0: Fixed Direct Access SCSI-3 device kernel: da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled kernel: da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 4:50: 9 2003 Delivered-To: freebsd-sparc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F1D737B405 for ; Thu, 16 Jan 2003 04:50:06 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDE7F43F5B for ; Thu, 16 Jan 2003 04:50:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0GCo3NS034514 for ; Thu, 16 Jan 2003 04:50:03 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0GCo36Q034513; Thu, 16 Jan 2003 04:50:03 -0800 (PST) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA5E37B401 for ; Thu, 16 Jan 2003 04:44:29 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D58A43E4A for ; Thu, 16 Jan 2003 04:44:28 -0800 (PST) (envelope-from hbb@catssrv.fokus.gmd.de) Received: from catssrv.fokus.gmd.de (catssrv [192.168.229.23]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0GCiRM29753 for ; Thu, 16 Jan 2003 13:44:27 +0100 (MET) Received: from catssrv.fokus.gmd.de (localhost [127.0.0.1]) by catssrv.fokus.gmd.de (8.12.6/8.12.6) with ESMTP id h0GCiQ0V000675 for ; Thu, 16 Jan 2003 13:44:26 +0100 (CET) (envelope-from hbb@catssrv.fokus.gmd.de) Received: (from hbb@localhost) by catssrv.fokus.gmd.de (8.12.6/8.12.6/Submit) id h0GCiQko000674; Thu, 16 Jan 2003 13:44:26 +0100 (CET) (envelope-from hbb) Message-Id: <200301161244.h0GCiQko000674@catssrv.fokus.gmd.de> Date: Thu, 16 Jan 2003 13:44:26 +0100 (CET) From: Hartmut Brandt Reply-To: Hartmut Brandt To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: sparc64/47143: OFW console does not implement ALT_BREAK_TO_DEBUGGER Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 47143 >Category: sparc64 >Synopsis: OFW console does not implement ALT_BREAK_TO_DEBUGGER >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-sparc >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 16 04:50:03 PST 2003 >Closed-Date: >Last-Modified: >Originator: Hartmut Brandt >Release: FreeBSD 5.0-CURRENT sparc64 >Organization: FhI Fokus >Environment: System: FreeBSD catssrv.fokus.gmd.de 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Jan 16 13:19:01 CET 2003 hbb@catssrv.fokus.gmd.de:/opt/obj/usr/src/sys/CATSSRV sparc64 >Description: The kernel option ALT_BREAK_TO_DEBUGGER does not work with the open firmware console on sparc (and probably other platforms that use ofw). >How-To-Repeat: Compile a kernel with 'options ALT_BREAK_TO_DEBUGGER' and 'options DDB', reboot and try \r~^B. Observe, that the debugger is not called. >Fix: The following patch implements the flag in ofw_console.c. Index: ofw_console.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/dev/ofw/ofw_console.c,v retrieving revision 1.7 diff -c -r1.7 ofw_console.c *** ofw_console.c 18 Nov 2002 06:19:12 -0000 1.7 --- ofw_console.c 16 Jan 2003 12:39:41 -0000 *************** *** 28,33 **** --- 28,36 ---- "$FreeBSD: src/sys/dev/ofw/ofw_console.c,v 1.7 2002/11/18 06:19:12 jake Exp $"; #endif /* not lint */ + #include "opt_ddb.h" + #include "opt_comconsole.h" + #include #include #include *************** *** 39,44 **** --- 42,49 ---- #include + #include + #define OFW_POLL_HZ 4 static d_open_t ofw_dev_open; *************** *** 68,73 **** --- 73,82 ---- static struct callout_handle ofw_timeouthandle = CALLOUT_HANDLE_INITIALIZER(&ofw_timeouthandle); + #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER) + static int alt_break_state; + #endif + static void ofw_tty_start(struct tty *); static int ofw_tty_param(struct tty *, struct termios *); static void ofw_tty_stop(struct tty *, int); *************** *** 295,300 **** --- 304,314 ---- } } + #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER) + if (db_alt_break(ch, &alt_break_state)) + breakpoint(); + #endif + return (ch); } *************** *** 304,309 **** --- 318,327 ---- unsigned char ch; if (OF_read(stdin, &ch, 1) > 0) { + #if defined(DDB) && defined(ALT_BREAK_TO_DEBUGGER) + if (db_alt_break(ch, &alt_break_state)) + breakpoint(); + #endif return (ch); } >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 11:37:34 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3081037B401 for ; Thu, 16 Jan 2003 11:37:32 -0800 (PST) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EB8E43EB2 for ; Thu, 16 Jan 2003 11:37:31 -0800 (PST) (envelope-from groudier@free.fr) Received: from [192.168.1.129] (213.36.54.206) by mail.libertysurf.net (6.5.026) id 3DEB487600D3E7E6; Thu, 16 Jan 2003 20:37:29 +0100 Date: Thu, 16 Jan 2003 21:36:55 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: groudier@localhost.my.domain To: Thomas Moestl Cc: Roderick van Domburg , Subject: Re: panic: trap: fast data access mmu miss In-Reply-To: <20030114201030.GA947@crow.dom2ip.de> Message-ID: <20030116210625.B1829-100000@localhost.my.domain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 14 Jan 2003, Thomas Moestl wrote: > On Tue, 2003/01/14 at 21:30:36 +0100, G=E9rard Roudier wrote: [...] > > > I think I've already ruled out most causes; I'm suspecting that > > > malloc() might be failing due to massive use of M_NOWAIT in the > > > related code. > > > > If less than 20K of memory is massive allocation, then your mail may we= ll > > come from twenty years ago IT age and I can only be dreaming at the > > moment. :-) > > > > The driver fails during initialisation after having allocated less than > > 20K in PAGE size chunk for the controller and probably less than 2 PAGE= S > > if PAGE size is large. > > I was not refering to sym alone. The IOMMU code itself also uses > M_NOWAIT to allocate DVMA memory and resource descriptors, and it's > not unlikely that previosly intialized drivers have used it and > drained the pool. The last round of updates increased the number of > allocations the IOMMU code does, hence this suspicion (it turns out > to be rather unlikely after reading some more allocator code though :) Thanks for the clarification. I just have some general comments about: :) Most (almost all) resources allocated at drivers/modules initialisation are never freeed. As a result, these resources should be available at the moment they are requested and waiting or not for availability will not add any magic that can prevent from shortage, in my opinion. Speaking about sym, it tries to recover from resource shortage after initialisation and should succeed most of the time. I just don't want the driver to allocate everything at initialisation since this can be hudge wastage in average. And yes, the driver will also use NOWAIT option after initialisation, since waiting for resources would either need complex synchronisation or would break IO ordering requirements. Note that we could allocate the needed resources and no more in SIMs if FreeBSD/CAM provided the slave_alloc()/slave_configure()/slave_destroy() semantic as in Linux 2.5. May-be Justin should consider this to be implemented in CAM. :) And on the other hand, SIMs could wait for resources during initialisation if aggressive parallelism that may lead to resource shortage occurs on kernel boot, since there is generally no ordering requirements during initialisation step. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 12:16:21 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 414F637B407 for ; Thu, 16 Jan 2003 12:16:18 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 6064343F5F for ; Thu, 16 Jan 2003 12:16:15 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 5150 invoked by uid 0); 16 Jan 2003 20:16:08 -0000 Received: from p508e7336.dip.t-dialin.net (HELO galatea.local) (80.142.115.54) by mail.gmx.net (mp006-rz3) with SMTP; 16 Jan 2003 20:16:08 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18ZGSR-0000zF-00; Thu, 16 Jan 2003 21:17:47 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0GKHSJM003796; Thu, 16 Jan 2003 21:17:28 +0100 (CET) Date: Thu, 16 Jan 2003 21:17:28 +0100 From: Thomas Moestl To: Kris Kennaway Cc: kan@FreeBSD.org, obrien@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: assembler error in XFree86 snapshot Message-ID: <20030116201728.GA279@crow.dom2ip.de> References: <20030116072448.GA29468@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030116072448.GA29468@rot13.obsecurity.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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: > > cc -c -O -pipe -ansi -Dasm=__asm -Wall -Wpointer-arith -Wundef -I/usr/tmp/XFree86-4-libraries-devel/work/xc -I/usr/tmp/XFree86-4-libraries-devel/work/xc/exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL XRes.c > {standard input}: Assembler messages: > {standard input}:667: Error: relocation overflow > *** Error code 1 > > line 667 of the .s file is: > > > .LL86: > > umul %o0, 4294967295, %o0 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. 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. 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. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C Index: config/sparc/sparc.c =================================================================== RCS file: /ncvs/src/contrib/gcc/config/sparc/sparc.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 sparc.c --- config/sparc/sparc.c 10 Oct 2002 04:40:04 -0000 1.1.1.9 +++ config/sparc/sparc.c 16 Jan 2003 18:09:06 -0000 @@ -6462,6 +6462,22 @@ output_address (XEXP (x, 0)); return; + case 's': + { + /* Print a sign-extended 32-bit value. */ + HOST_WIDE_INT xi; + int i; + if (GET_CODE(x) == CONST_INT) + xi = INTVAL (x); + else if (GET_CODE(x) == CONST_DOUBLE) + xi = CONST_DOUBLE_LOW (x); + else + output_operand_lossage ("invalid %%s operand"); + i = trunc_int_for_mode (xi, SImode); + fprintf (file, "%d", i); + return; + } + case 0: /* Do nothing special. */ break; Index: config/sparc/sparc.md =================================================================== RCS file: /ncvs/src/contrib/gcc/config/sparc/sparc.md,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 sparc.md --- config/sparc/sparc.md 10 Oct 2002 04:40:08 -0000 1.1.1.8 +++ config/sparc/sparc.md 16 Jan 2003 17:09:36 -0000 @@ -6120,7 +6120,7 @@ "TARGET_HARD_MUL32" "* { - return TARGET_SPARCLET ? \"umuld\\t%1, %2, %L0\" : \"umul\\t%1, %2, %L0\\n\\trd\\t%%y, %H0\"; + return TARGET_SPARCLET ? \"umuld\\t%1, %s2, %L0\" : \"umul\\t%1, %s2, %L0\\n\\trd\\t%%y, %H0\"; }" [(set (attr "type") (if_then_else (eq_attr "isa" "sparclet") @@ -6134,7 +6134,7 @@ (mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "r")) (match_operand:SI 2 "uns_small_int" "")))] "TARGET_DEPRECATED_V8_INSNS && TARGET_ARCH64" - "umul\\t%1, %2, %0" + "umul\\t%1, %s2, %0" [(set_attr "type" "imul")]) ;; XXX @@ -6145,8 +6145,8 @@ (clobber (match_scratch:SI 3 "=X,h"))] "TARGET_V8PLUS" "@ - umul\\t%1, %2, %L0\\n\\tsrlx\\t%L0, 32, %H0 - umul\\t%1, %2, %3\\n\\tsrlx\\t%3, 32, %H0\\n\\tmov\\t%3, %L0" + umul\\t%1, %s2, %L0\\n\\tsrlx\\t%L0, 32, %H0 + umul\\t%1, %s2, %3\\n\\tsrlx\\t%3, 32, %H0\\n\\tmov\\t%3, %L0" [(set_attr "type" "multi") (set_attr "length" "2,3")]) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 13:14:55 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CE1E37B401 for ; Thu, 16 Jan 2003 13:14:55 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477C443F3F for ; Thu, 16 Jan 2003 13:14:54 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id h0GLEjdc082504 for ; Thu, 16 Jan 2003 16:14:45 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Thu, 16 Jan 2003 16:14:44 -0500 To: sparc64@FreeBSD.ORG From: Garance A Drosihn Subject: portupgrade on sparc64 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Now that a cvsup binary is available, I'm trying to compile more ports on my sparc64 test machine. While I'm able to compile ruby and portupgrade, the portupgrade program doesn't seem to be working right for me. I keep getting results such as: (22) /usr/local/sbin/portinstall -Rr trafshow ** No such installed package nor such port called 'trafshow' is found. Do others see the same behavior with portupgrade under sparc64? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 13:17:22 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A54B437B401 for ; Thu, 16 Jan 2003 13:17:20 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC0843EB2 for ; Thu, 16 Jan 2003 13:17:19 -0800 (PST) (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 8A12E66B60; Thu, 16 Jan 2003 13:17:19 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 4B2BAFD3; Thu, 16 Jan 2003 13:17:19 -0800 (PST) Date: Thu, 16 Jan 2003 13:17:19 -0800 From: Kris Kennaway To: Garance A Drosihn Cc: sparc64@FreeBSD.ORG Subject: Re: portupgrade on sparc64 Message-ID: <20030116211718.GA32982@rot13.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2003 at 04:14:44PM -0500, Garance A Drosihn wrote: > Now that a cvsup binary is available, I'm trying to compile more > ports on my sparc64 test machine. While I'm able to compile ruby > and portupgrade, the portupgrade program doesn't seem to be working > right for me. I keep getting results such as: >=20 > (22) /usr/local/sbin/portinstall -Rr trafshow > ** No such installed package nor such port called 'trafshow' is found. >=20 > Do others see the same behavior with portupgrade under sparc64? Are you using ruby 1.6 or 1.8? The former doesn't work on sparc64 (et al), and the default was recently changed to 1.8. Kris --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+JyFeWry0BWjoQKURArIMAKC1n2+xqJjKkkm3T0i7lHwIJzu1BwCg1XFb bk4TLClDZKMmUg48TF/aURU= =PmFV -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 14:32:35 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2CD537B401 for ; Thu, 16 Jan 2003 14:32:33 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1204A43F18 for ; Thu, 16 Jan 2003 14:32:33 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id h0GMWUdc041894; Thu, 16 Jan 2003 17:32:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030116211718.GA32982@rot13.obsecurity.org> References: <20030116211718.GA32982@rot13.obsecurity.org> Date: Thu, 16 Jan 2003 17:32:29 -0500 To: Kris Kennaway From: Garance A Drosihn Subject: Re: portupgrade on sparc64 Cc: sparc64@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 1:17 PM -0800 1/16/03, Kris Kennaway wrote: >On Thu, Jan 16, 2003 at 04:14:44PM -0500, Garance A Drosihn wrote: > > While I'm able to compile ruby and portupgrade, the portupgrade > > program doesn't seem to be working right for me. > >Are you using ruby 1.6 or 1.8? The former doesn't work on sparc64 >(et al), and the default was recently changed to 1.8. "Both", sort of. I was starting with a fresh system, so I did a cd /usr/ports/lang/ruby make && make install && make clean cd /usr/ports/sysutils/portupgrade make && make install && make clean The first set did install 1.6, but it's there as ruby16. The second set did not find /usr/local/bin/ruby, so it first built ruby-devel. So after all that, ruby -v tells me: ruby 1.8.0 (2003-01-11) [sparc64-freebsd5] I just deinstalled ruby, and I still have the problem. I deinstalled portupgrade and reinstalled it, and still have the problem. It might be some other things I'm doing. I'll try a few other changes. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 14:37:54 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A3E37B401 for ; Thu, 16 Jan 2003 14:37:53 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F2F943F13 for ; Thu, 16 Jan 2003 14:37:52 -0800 (PST) (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 787B566B60; Thu, 16 Jan 2003 14:37:51 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 5F128FDC; Thu, 16 Jan 2003 14:37:51 -0800 (PST) Date: Thu, 16 Jan 2003 14:37:51 -0800 From: Kris Kennaway To: Garance A Drosihn Cc: Kris Kennaway , sparc64@FreeBSD.ORG Subject: Re: portupgrade on sparc64 Message-ID: <20030116223751.GA33580@rot13.obsecurity.org> References: <20030116211718.GA32982@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 16, 2003 at 05:32:29PM -0500, Garance A Drosihn wrote: > I just deinstalled ruby, and I still have the problem. > I deinstalled portupgrade and reinstalled it, and still have > the problem. It might be some other things I'm doing. I'll > try a few other changes. Talking to knu once you've done this might be the best idea. Kris --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+JzQ+Wry0BWjoQKURAifSAJ9QevakWGuhe6OEoUd69CO/93jAgQCg/g0l sxO7u0Tx0yJcBmcd/DeAseE= =6XYj -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 15:11:13 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C7EC37B401 for ; Thu, 16 Jan 2003 15:11:11 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F1543EB2 for ; Thu, 16 Jan 2003 15:11:10 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id h0GNB46F027242 for ; Thu, 16 Jan 2003 15:11:04 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id h0GNB3Aq027238 for sparc@freebsd.org; Thu, 16 Jan 2003 15:11:03 -0800 Date: Thu, 16 Jan 2003 15:11:03 -0800 From: Brooks Davis To: sparc@freebsd.org Subject: Ultra 10 won't boot after install Message-ID: <20030116151103.A25846@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've got an ultra 10 that I'm trying to get up and running with 5.0. I've triedthe RC1 mini ISO as well as both the mini and regular RC3 ISOs. I make it through install sucessfully (though it failed to sync 103 buffers this last time), but when I try to boot from the ok prompt I get the output at the end of this message. I'm stumped. Any suggestions of things to check or try would be helpful. Thanks, Brooks ok boot Resetting ...=20 Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 300MHz), No Keyboard OpenBoot 3.11, 128 MB memory installed, Serial #9478304. Ethernet address 8:0:20:90:a0:a0, Host ID: 8090a0a0. Rebooting with command: boot =20 Boot device: disk:b File and args:=20 Evaluating: boot Can't open boot device Boot device: disk:b File and args:=20 Evaluating: boot Can't open boot device ok boot disk:a Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args:=20 Can't open boot device ok boot disk Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0 File and args:=20 Can't open boot device ok=20 --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+JzwEXY6L6fI4GtQRAvPNAJ4+mVwAAWafkJgVOfGlJQQdAGZx+gCfdHBn t91wv/U5yVyDBtzXRRqCAxI= =PjbI -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 15:47: 6 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8239C37B405 for ; Thu, 16 Jan 2003 15:47:04 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56D5F43F13 for ; Thu, 16 Jan 2003 15:47:03 -0800 (PST) (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 259C966B60 for ; Thu, 16 Jan 2003 15:47:02 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 1AC1EFDC; Thu, 16 Jan 2003 15:47:02 -0800 (PST) Date: Thu, 16 Jan 2003 15:47:02 -0800 From: Kris Kennaway To: sparc@FreeBSD.org Subject: XFree86 and syscons support Message-ID: <20030116234701.GA34086@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I managed to get XFree86 to compile on sparc64, however it fails to run due to the lack of console support on FreeBSD/sparc64. Is anyone working on this? Kris --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+J0R1Wry0BWjoQKURAvyxAJ9MRrvLS5nAaDbY4afXcQMIziIQhACfVd/W d6DWUXItOBCkvPk2/BkT8CQ= =wz8H -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Jan 16 18:16: 8 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A12C237B401 for ; Thu, 16 Jan 2003 18:16:07 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EDF43F1E for ; Thu, 16 Jan 2003 18:16:06 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0H2G0u5014162 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 16 Jan 2003 18:16:01 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0H2G0PZ040597; Thu, 16 Jan 2003 18:16:00 -0800 (PST) (envelope-from jdp) Date: Thu, 16 Jan 2003 18:16:00 -0800 (PST) Message-Id: <200301170216.h0H2G0PZ040597@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: tmoestl@gmx.net Subject: Re: Sparc64 floating point questions In-Reply-To: <20030115021706.GA5902@crow.dom2ip.de> References: <20030115003013.GA3536@crow.dom2ip.de> <200301150047.h0F0lNFc037477@vashon.polstra.com> <20030115021706.GA5902@crow.dom2ip.de> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20030115021706.GA5902@crow.dom2ip.de>, Thomas Moestl wrote: > > Oh, I should have mentioned that %fprs is a bit special; the kernel > uses the FEF bit to test whether floating point support is enabled for > the process, and will only save the state across context switches in > that case. It will also lazily restore the context, i.e. it will > disable the FEF bit and reload the registers only when the process > uses floating point operations for the next time (which triggers an > exception in that case). > That means that %fprs must be restored first, otherwise this might > clear FEF and cause stale values to be reloaded later. > In fact, you do not need to save it at all; the only other bits in > that register are the DU (upper fp register file half dirty) and DL > (lower half dirty) bits, which are automatically maintained. > For performance, it would probably be best to always just set the FEF > bit before reloading the other registers (this is not required > though), like: > > wr %g0, FPRS_FEF, %fprs I'm a little bit confused about this. Won't the instruction above clear the DU and DL bits? And isn't that a bad thing to do? It seems like the state maintained in those bits is per-process rather than per-thread. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 5:29:20 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1E37B401 for ; Fri, 17 Jan 2003 05:29:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A62543F3F for ; Fri, 17 Jan 2003 05:29:16 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 7869 invoked by uid 0); 17 Jan 2003 13:29:15 -0000 Received: from p508E75C4.dip.t-dialin.net (HELO galatea.local) (80.142.117.196) by mail.gmx.net (mp002-rz3) with SMTP; 17 Jan 2003 13:29:15 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18ZWaO-0000OS-00; Fri, 17 Jan 2003 14:31:05 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0HDUtQR001515; Fri, 17 Jan 2003 14:30:55 +0100 (CET) Date: Fri, 17 Jan 2003 14:30:55 +0100 From: Thomas Moestl To: John Polstra Cc: sparc@freebsd.org Subject: Re: Sparc64 floating point questions Message-ID: <20030117133055.GA304@crow.dom2ip.de> Mail-Followup-To: John Polstra , sparc@freebsd.org References: <20030115003013.GA3536@crow.dom2ip.de> <200301150047.h0F0lNFc037477@vashon.polstra.com> <20030115021706.GA5902@crow.dom2ip.de> <200301170216.h0H2G0PZ040597@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301170216.h0H2G0PZ040597@vashon.polstra.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 2003/01/16 at 18:16:00 -0800, John Polstra wrote: > In article <20030115021706.GA5902@crow.dom2ip.de>, > Thomas Moestl wrote: > > > > Oh, I should have mentioned that %fprs is a bit special; the kernel > > uses the FEF bit to test whether floating point support is enabled for > > the process, and will only save the state across context switches in > > that case. It will also lazily restore the context, i.e. it will > > disable the FEF bit and reload the registers only when the process > > uses floating point operations for the next time (which triggers an > > exception in that case). > > That means that %fprs must be restored first, otherwise this might > > clear FEF and cause stale values to be reloaded later. > > In fact, you do not need to save it at all; the only other bits in > > that register are the DU (upper fp register file half dirty) and DL > > (lower half dirty) bits, which are automatically maintained. > > For performance, it would probably be best to always just set the FEF > > bit before reloading the other registers (this is not required > > though), like: > > > > wr %g0, FPRS_FEF, %fprs > > I'm a little bit confused about this. Won't the instruction above > clear the DU and DL bits? Yes. > And isn't that a bad thing to do? It seems like the state > maintained in those bits is per-process rather than per-thread. Since you are going to write to all fp registers anyway, both will get set automatically. These bits are not used by the hardware and exist only to allow software to skip saving unused registers. The kernel does not currently make use of them. However, if it (or a userland thread manager) did, and a switch was to take place before all registers were restored, the missing dirty bits would indicate that the yet unaccessed parts of the registers need not be saved, which does not matter at all since their old values will not be used any more. The kernel itself does never clear DU and DL, so it is possible to use them in user land to skip unnecessary saving (and unneccesary reloading if one of the halves was not accessed at all); in this case it would be necessary to clear the bits explicitely after reloading. Both will however get set currently each time the fp registers are restored after a (kernel) context switch, so this does probably not really pay off. Also, things would break if the kernel started to use them for saving decisions. Setting FEF explicitely before reloading makes sure that a fp state that was saved on a previous context switch and that might not have been restored yet will not be restored due to the following register accesses. Since all registers will be overwritten anyway, this would just eat cycles unnecessarily. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 6:34:43 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF8F237B401; Fri, 17 Jan 2003 06:34:40 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7347043EB2; Fri, 17 Jan 2003 06:34:39 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0HEYbM13061; Fri, 17 Jan 2003 15:34:37 +0100 (MET) Date: Fri, 17 Jan 2003 15:34:37 +0100 (CET) From: Harti Brandt To: tmm@freebsd.org Cc: sparc@freebsd.org Subject: Problem with iommu_dvmamap_create Message-ID: <20030117151958.U715@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, it seems, there is a problem in this function. I have a case, where my driver creates a dma_tag with a maxsize of 64k-1, a maximum segment size of 64k-1 and a large maximum number of segments (say 30...40). As soon, as I create a DMA map with this tag, the io gets botched (up to the point, that the boot prom reports a nvram checksum error). When I comment out the code in iommu.c as follows I can at least create and destroy the maps without any bad effect (I did not try to load them yet): int iommu_dvmamap_create(bus_dma_tag_t pt, bus_dma_tag_t dt, struct iommu_state *is, int flags, bus_dmamap_t *mapp) { bus_size_t totsz, presz, currsz; int error, i, maxpre; if ((error = sparc64_dmamap_create(pt->dt_parent, dt, flags, mapp)) != 0) return (error); KASSERT(SLIST_EMPTY(&(*mapp)->dm_reslist), ("iommu_dvmamap_create: hierarchy botched")); iommu_map_insq(*mapp); /* * Preallocate DVMA space; if this fails now, it is retried at load * time. Through bus_dmamap_load_mbuf() and bus_dmamap_load_uio(), it * is possible to have multiple discontiguous segments in a single map, * which is handled by allocating additional resources, instead of * increasing the size, to avoid fragmentation. * Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can * handle more; that case is handled by reallocating at map load time. */ totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE); error = iommu_dvma_valloc(dt, is, *mapp, totsz); if (error != 0) return (0); #if 0 /* * Try to be smart about preallocating some additional segments if * needed. */ maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG); presz = dt->dt_maxsize / maxpre; for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) { currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz)); error = iommu_dvma_valloc(dt, is, *mapp, currsz); if (error != 0) break; totsz += currsz; } #endif return (0); } The problem seems to be the dt_maxsize / maxpre. In my case this evaluates to 0 and the call to valloc will use a currsz of 0. This seems to have bad effects on the resource manager. Also the loop will allocate one segment more than it needs (it does not count the first allocation). This is, however, not critical. I suggest also changing the comment above - it mentions BUS_SPACE_MAXSIZE, but BUS_SPACE_MAXSIZE does not figure in the code (should be IOMMU_MAX_PRE probably, which happens to be BUS_SPACE_MAXSIZE). Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 8: 7:22 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87A7337B401 for ; Fri, 17 Jan 2003 08:07:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BBC9243F18 for ; Fri, 17 Jan 2003 08:07:14 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 11648 invoked by uid 0); 17 Jan 2003 16:07:12 -0000 Received: from p508e75c4.dip.t-dialin.net (HELO galatea.local) (80.142.117.196) by mail.gmx.net (mp016-rz3) with SMTP; 17 Jan 2003 16:07:12 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18ZZ3G-0000o3-00; Fri, 17 Jan 2003 17:09:02 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0HG8v27003102; Fri, 17 Jan 2003 17:08:57 +0100 (CET) Date: Fri, 17 Jan 2003 17:08:57 +0100 From: Thomas Moestl To: Harti Brandt Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117160857.GB304@crow.dom2ip.de> Mail-Followup-To: Harti Brandt , sparc@freebsd.org References: <20030117151958.U715@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20030117151958.U715@beagle.fokus.gmd.de> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, 2003/01/17 at 15:34:37 +0100, Harti Brandt wrote: > Hi, > > it seems, there is a problem in this function. I have a case, where my > driver creates a dma_tag with a maxsize of 64k-1, a maximum segment size > of 64k-1 and a large maximum number of segments (say 30...40). As soon, as > I create a DMA map with this tag, the io gets botched (up to the point, > that the boot prom reports a nvram checksum error). When I comment out the > code in iommu.c as follows I can at least create and destroy the maps > without any bad effect (I did not try to load them yet): Can you please make try the attached patch? I mostly posted it to this list before it fixes some bogons which may be related (bugs in the lowaddr and boundary handling) and adds some diagnostics. I also fixed the two issues you noted below and KASSERT()ed that presz can't be 0. Can you also please post the exact map and tag creation calls? > int > iommu_dvmamap_create(bus_dma_tag_t pt, bus_dma_tag_t dt, struct iommu_state *is, > int flags, bus_dmamap_t *mapp) > { > bus_size_t totsz, presz, currsz; > int error, i, maxpre; > > if ((error = sparc64_dmamap_create(pt->dt_parent, dt, flags, mapp)) != 0) > return (error); > KASSERT(SLIST_EMPTY(&(*mapp)->dm_reslist), > ("iommu_dvmamap_create: hierarchy botched")); > iommu_map_insq(*mapp); > /* > * Preallocate DVMA space; if this fails now, it is retried at load > * time. Through bus_dmamap_load_mbuf() and bus_dmamap_load_uio(), it > * is possible to have multiple discontiguous segments in a single map, > * which is handled by allocating additional resources, instead of > * increasing the size, to avoid fragmentation. > * Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can > * handle more; that case is handled by reallocating at map load time. > */ > totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE); > error = iommu_dvma_valloc(dt, is, *mapp, totsz); > if (error != 0) > return (0); > #if 0 > /* > * Try to be smart about preallocating some additional segments if > * needed. > */ > maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG); > presz = dt->dt_maxsize / maxpre; > for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) { > currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz)); > error = iommu_dvma_valloc(dt, is, *mapp, currsz); > if (error != 0) > break; > totsz += currsz; > } > #endif > return (0); > } > > The problem seems to be the dt_maxsize / maxpre. In my case this evaluates > to 0 and the call to valloc will use a currsz of 0. This seems to have bad > effects on the resource manager. Hmmm, allocating with a size of 0 would of course be a bug, but I fail to see what would cause presz to be 0 in the first place in your example - maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all else would be a bogus tag. > Also the loop will allocate one segment more than it needs (it does not > count the first allocation). This is, however, not critical. Doh, right. > I suggest also changing the comment above - it mentions BUS_SPACE_MAXSIZE, > but BUS_SPACE_MAXSIZE does not figure in the code (should be > IOMMU_MAX_PRE probably, which happens to be BUS_SPACE_MAXSIZE). Will do (it used to be BUS_SPACE_MAXSIZE directly, but I overlooked the comment when changing things). Thanks, - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iommu-misc.diff" Index: sparc64/sparc64/iommu.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/iommu.c,v retrieving revision 1.14 diff -u -r1.14 iommu.c --- sparc64/sparc64/iommu.c 6 Jan 2003 21:59:54 -0000 1.14 +++ sparc64/sparc64/iommu.c 17 Jan 2003 15:52:16 -0000 @@ -517,10 +517,13 @@ { struct resource *res; struct bus_dmamap_res *bdr; - bus_size_t align, bound, sgsize; + bus_size_t align, sgsize; - if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) + if ((bdr = malloc(sizeof(*bdr), M_IOMMU, M_NOWAIT)) == NULL) { + printf("iommu_dvma_valloc: res descriptor allocation " + "failed.\n"); return (EAGAIN); + } /* * If a boundary is specified, a map cannot be larger than it; however * we do not clip currently, as that does not play well with the lazy @@ -531,9 +534,9 @@ sgsize = round_io_page(size) >> IO_PAGE_SHIFT; if (t->dt_boundary > 0 && t->dt_boundary < IO_PAGE_SIZE) panic("iommu_dvmamap_load: illegal boundary specified"); - bound = ulmax(t->dt_boundary >> IO_PAGE_SHIFT, 1); res = rman_reserve_resource_bound(&iommu_dvma_rman, 0L, - t->dt_lowaddr, sgsize, bound >> IO_PAGE_SHIFT, + t->dt_lowaddr >> IO_PAGE_SHIFT, sgsize, + t->dt_boundary >> IO_PAGE_SHIFT, RF_ACTIVE | rman_make_alignment_flags(align), NULL); if (res == NULL) return (ENOMEM); @@ -719,7 +722,7 @@ * is possible to have multiple discontiguous segments in a single map, * which is handled by allocating additional resources, instead of * increasing the size, to avoid fragmentation. - * Clamp preallocation to BUS_SPACE_MAXSIZE. In some situations we can + * Clamp preallocation to IOMMU_MAX_PRE. In some situations we can * handle more; that case is handled by reallocating at map load time. */ totsz = ulmin(IOMMU_SIZE_ROUNDUP(dt->dt_maxsize), IOMMU_MAX_PRE); @@ -732,7 +735,10 @@ */ maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG); presz = dt->dt_maxsize / maxpre; - for (i = 0; i < maxpre && totsz < IOMMU_MAX_PRE; i++) { + KASSERT(presz != 0, ("iommu_dvmamap_create: bogus preallocation size " + ", nsegments = %d, maxpre = %d, maxsize = %lu", dt->dt_nsegments, + maxpre, dt->dt_maxsize)); + for (i = 1; i < maxpre && totsz < IOMMU_MAX_PRE; i++) { currsz = round_io_page(ulmin(presz, IOMMU_MAX_PRE - totsz)); error = iommu_dvma_valloc(dt, is, *mapp, currsz); if (error != 0) @@ -766,8 +772,10 @@ pmap_t pmap = NULL; KASSERT(buflen != 0, ("iommu_dvmamap_load_buffer: buflen == 0!")); - if (buflen > dt->dt_maxsize) + if (buflen > dt->dt_maxsize) { + printf("iommu_dvmamap_load_buffer: buffer too long.\n"); return (EINVAL); + } if (td != NULL) pmap = vmspace_pmap(td->td_proc->p_vmspace); @@ -813,6 +821,8 @@ sgcnt++; if (sgcnt >= dt->dt_nsegments || sgcnt >= BUS_DMAMAP_NSEGS) { + printf("iommu_dvmamap_load_buffer: too many " + "segments.\n"); error = EFBIG; break; } @@ -860,7 +870,7 @@ if (error != 0) { iommu_dvmamap_vunload(is, map); - (*cb)(cba, NULL, 0, error); + (*cb)(cba, sgs, 0, error); } else { /* Move the map to the end of the LRU queue. */ iommu_map_insq(map); Index: kern/subr_rman.c =================================================================== RCS file: /ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.27 diff -u -r1.27 subr_rman.c --- kern/subr_rman.c 27 Nov 2002 03:55:22 -0000 1.27 +++ kern/subr_rman.c 12 Jan 2003 22:45:20 -0000 @@ -229,7 +229,7 @@ */ do { rstart = (rstart + amask) & ~amask; - if (((rstart ^ (rstart + count)) & bmask) != 0) + if (((rstart ^ (rstart + count - 1)) & bmask) != 0) rstart += bound - (rstart & ~bmask); } while ((rstart & amask) != 0 && rstart < end && rstart < s->r_end); @@ -263,8 +263,11 @@ * two new allocations; the second requires but one. */ rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); - if (rv == 0) + if (rv == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); goto out; + } rv->r_start = rstart; rv->r_end = rstart + count - 1; rv->r_flags = flags | RF_ALLOCATED; @@ -282,6 +285,8 @@ */ r = malloc(sizeof *r, M_RMAN, M_NOWAIT|M_ZERO); if (r == 0) { + printf("rman_reserve_resource: out of " + "memory.\n"); free(rv, M_RMAN); rv = 0; goto out; --sdtB3X0nJg68CQEu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 8:30:24 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CBAF37B401; Fri, 17 Jan 2003 08:30:22 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D9343ED8; Fri, 17 Jan 2003 08:30:21 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0HGUDM26173; Fri, 17 Jan 2003 17:30:14 +0100 (MET) Date: Fri, 17 Jan 2003 17:30:13 +0100 (CET) From: Harti Brandt To: Thomas Moestl Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create In-Reply-To: <20030117160857.GB304@crow.dom2ip.de> Message-ID: <20030117171317.F44530@beagle.fokus.gmd.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20030117171317.O44530@beagle.fokus.gmd.de> Content-Disposition: INLINE Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>Can you please make try the attached patch? I mostly posted it to this TM>list before it fixes some bogons which may be related (bugs in the TM>lowaddr and boundary handling) and adds some diagnostics. I also fixed TM>the two issues you noted below and KASSERT()ed that presz can't be 0. TM> TM>Can you also please post the exact map and tag creation calls? if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, HE_MAX_PDU, 3 * HE_CONFIG_MAX_TPD_PER_PACKET, HE_MAX_PDU, 0, &sc->tx_tag)) { device_printf(dev, "could not allocate TX tag\n"); error = ENOMEM; goto failed; } error = bus_dmamap_create(sc->tx_tag, 0, &t->map); if (error != 0) { HE_MAX_PDU is 65535 and HE_CONFIG_MAX_TPD_PER_PACKET is 11. TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to TM>see what would cause presz to be 0 in the first place in your example - TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all TM>else would be a bogus tag. Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and maxpres. On a related topic. I just got a panic when actually using the map. There are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k PDU is segmented into 32 or more mbufs. I think, that NSEGS should be large enough to handle 64k PDUs so it should probably be 40 or so. The other problem is, that bus_dmamap_load_mbuf happily will try to load such a PDU. There is a check in iommu_dvmamap_load_buffer for the segment count and it sets error to EFBIG, but the function than fails to check that error. The return at the end should probably read 'return (error)'. I try your patch and tell you the results. Thanks, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 8:31:10 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFE2137B401 for ; Fri, 17 Jan 2003 08:31:08 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7269B43E4A for ; Fri, 17 Jan 2003 08:31:07 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id h0HGV5u5017196 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 17 Jan 2003 08:31:06 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id h0HGV5PO041575; Fri, 17 Jan 2003 08:31:05 -0800 (PST) (envelope-from jdp) Date: Fri, 17 Jan 2003 08:31:05 -0800 (PST) Message-Id: <200301171631.h0HGV5PO041575@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: tmoestl@gmx.net Subject: Re: Sparc64 floating point questions In-Reply-To: <20030117133055.GA304@crow.dom2ip.de> References: <20030115021706.GA5902@crow.dom2ip.de> <200301170216.h0H2G0PZ040597@vashon.polstra.com> <20030117133055.GA304@crow.dom2ip.de> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20030117133055.GA304@crow.dom2ip.de>, Thomas Moestl wrote: > Since you are going to write to all fp registers anyway, both will get > set automatically. These bits are not used by the hardware and exist > only to allow software to skip saving unused registers. The kernel > does not currently make use of them. However, if it (or a userland > thread manager) did, and a switch was to take place before all > registers were restored, the missing dirty bits would indicate that > the yet unaccessed parts of the registers need not be saved, which > does not matter at all since their old values will not be used any > more. > The kernel itself does never clear DU and DL, so it is possible to use > them in user land to skip unnecessary saving (and unneccesary > reloading if one of the halves was not accessed at all); in this case > it would be necessary to clear the bits explicitely after reloading. > Both will however get set currently each time the fp registers are > restored after a (kernel) context switch, so this does probably not > really pay off. Also, things would break if the kernel started to use > them for saving decisions. > > Setting FEF explicitely before reloading makes sure that a fp state > that was saved on a previous context switch and that might not have > been restored yet will not be restored due to the following register > accesses. Since all registers will be overwritten anyway, this would > just eat cycles unnecessarily. Thanks! I understand it perfectly now. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 9: 5:33 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27B8737B405; Fri, 17 Jan 2003 09:05:32 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DB5F43F79; Fri, 17 Jan 2003 09:05:30 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0HH5SM29866; Fri, 17 Jan 2003 18:05:28 +0100 (MET) Date: Fri, 17 Jan 2003 18:05:28 +0100 (CET) From: Harti Brandt To: Thomas Moestl Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create In-Reply-To: <20030117160857.GB304@crow.dom2ip.de> Message-ID: <20030117175953.X45050@beagle.fokus.gmd.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20030117175953.M45050@beagle.fokus.gmd.de> Content-Disposition: INLINE Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>Can you please make try the attached patch? I mostly posted it to this TM>list before it fixes some bogons which may be related (bugs in the TM>lowaddr and boundary handling) and adds some diagnostics. I also fixed TM>the two issues you noted below and KASSERT()ed that presz can't be 0. It seems, that your patch fixes the problem, although I'm not sure how :-) It even prints 'iommu_dvmamap_load_buffer: too many segments' now, but crashes afterwards (see my previous mail). Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 9: 9:36 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B8A37B401 for ; Fri, 17 Jan 2003 09:09:35 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 2996243ED8 for ; Fri, 17 Jan 2003 09:09:33 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 16370 invoked by uid 0); 17 Jan 2003 17:09:31 -0000 Received: from p508e75c4.dip.t-dialin.net (HELO galatea.local) (80.142.117.196) by mail.gmx.net (mp011-rz3) with SMTP; 17 Jan 2003 17:09:31 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18Za1W-0000xR-00; Fri, 17 Jan 2003 18:11:18 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0HHBB8n003684; Fri, 17 Jan 2003 18:11:11 +0100 (CET) Date: Fri, 17 Jan 2003 18:11:11 +0100 From: Thomas Moestl To: Harti Brandt Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117171111.GC304@crow.dom2ip.de> Mail-Followup-To: Harti Brandt , sparc@freebsd.org References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> <20030117171317.F44530@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117171317.F44530@beagle.fokus.gmd.de> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote: > On Fri, 17 Jan 2003, Thomas Moestl wrote: > TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to > TM>see what would cause presz to be 0 in the first place in your example - > TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. > TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all > TM>else would be a bogus tag. > > Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and > maxpres. > > On a related topic. I just got a panic when actually using the map. There > are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These > seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k > PDU is segmented into 32 or more mbufs. I think, that NSEGS should be > large enough to handle 64k PDUs so it should probably be 40 or so. BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only thing to limit is the stack space used by the segment array. In the current setting, 272 bytes are used at most, which is less than 1.5 minimal function frames. Values such as 64 should still be OK. > The other problem is, that bus_dmamap_load_mbuf happily will try to load > such a PDU. There is a check in iommu_dvmamap_load_buffer for the segment > count and it sets error to EFBIG, but the function than fails to check > that error. The return at the end should probably read 'return (error)'. Bah, that's what you get when you reorganize code too much. It should just return (EFBIG) instead of setting error. > I try your patch and tell you the results. Thanks. Looking at the code you pasted above, I'm afraid that they won't help though. The only possibility for a simple map creation to break things in that way is that it changes the available DVMA space and may cause this or other maps to be pruned. In both cases, another driver must be using DMA already or do load or unload operations for this to take any effect. So, can you please tell me which other DMA-using devices you have in that box, so that I can try to figure out the possible interactions? - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 9:20: 4 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7C9B37B401; Fri, 17 Jan 2003 09:20:02 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F7E43F43; Fri, 17 Jan 2003 09:20:01 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0HHJxM01247; Fri, 17 Jan 2003 18:19:59 +0100 (MET) Date: Fri, 17 Jan 2003 18:19:59 +0100 (CET) From: Harti Brandt To: Thomas Moestl Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create In-Reply-To: <20030117171111.GC304@crow.dom2ip.de> Message-ID: <20030117181111.R45050@beagle.fokus.gmd.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> <20030117171317.F44530@beagle.fokus.gmd.de> <20030117171111.GC304@crow.dom2ip.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote: TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>> TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to TM>> TM>see what would cause presz to be 0 in the first place in your example - TM>> TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. TM>> TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all TM>> TM>else would be a bogus tag. TM>> TM>> Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and TM>> maxpres. TM>> TM>> On a related topic. I just got a panic when actually using the map. There TM>> are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These TM>> seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k TM>> PDU is segmented into 32 or more mbufs. I think, that NSEGS should be TM>> large enough to handle 64k PDUs so it should probably be 40 or so. TM> TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only TM>thing to limit is the stack space used by the segment array. In the TM>current setting, 272 bytes are used at most, which is less than 1.5 TM>minimal function frames. Values such as 64 should still be OK. Would it be possible if you change it just there? TM>Thanks. Looking at the code you pasted above, I'm afraid that they TM>won't help though. The only possibility for a simple map creation to TM>break things in that way is that it changes the available DVMA space TM>and may cause this or other maps to be pruned. In both cases, another TM>driver must be using DMA already or do load or unload operations for TM>this to take any effect. So, can you please tell me which other TM>DMA-using devices you have in that box, so that I can try to figure TM>out the possible interactions? I have an ATA controller from which I boot, a hme card and an adaptec 29160, but I don't use the SCSI disk at the moment. What I did to trigger the error was: 1) compile the code with the '3 * HE_....' changed to 1. 2) install, kldload, ifconfig up -> ok 3) compile the original code 3) kldunload, install, kldload, ifconfig up -> baaaah 'baaaah' means, that a lot of strange things happen: the driver gets a lot of interrupts, but the interrupt status words (these are written per DMA) are invalid. when kldunloading sometimes I get a repeated loop of 'fast data mmu ... miss' and ddb prompts. After booting (I need to switch the machine off to do this!) the nvram checksum is usually bad and the machine ofw status is reset. I tried to find the problem for 3 days now.... With your patch applied things seem better, but I still fail to see why :-) Thanks, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 9:31:23 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E52437B401 for ; Fri, 17 Jan 2003 09:31:22 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id F417B43EB2 for ; Fri, 17 Jan 2003 09:31:20 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 12532 invoked by uid 0); 17 Jan 2003 17:31:19 -0000 Received: from p508e75c4.dip.t-dialin.net (HELO galatea.local) (80.142.117.196) by mail.gmx.net (mp006-rz3) with SMTP; 17 Jan 2003 17:31:19 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18ZaMf-00011k-00; Fri, 17 Jan 2003 18:33:09 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0HHX3Tp003951; Fri, 17 Jan 2003 18:33:03 +0100 (CET) Date: Fri, 17 Jan 2003 18:33:03 +0100 From: Thomas Moestl To: Harti Brandt Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117173303.GD304@crow.dom2ip.de> Mail-Followup-To: Harti Brandt , sparc@freebsd.org References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> <20030117171317.F44530@beagle.fokus.gmd.de> <20030117171111.GC304@crow.dom2ip.de> <20030117181111.R45050@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117181111.R45050@beagle.fokus.gmd.de> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 2003/01/17 at 18:19:59 +0100, Harti Brandt wrote: > On Fri, 17 Jan 2003, Thomas Moestl wrote: > TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only > TM>thing to limit is the stack space used by the segment array. In the > TM>current setting, 272 bytes are used at most, which is less than 1.5 > TM>minimal function frames. Values such as 64 should still be OK. > > Would it be possible if you change it just there? Yes, I'll do that with the next update. > I have an ATA controller from which I boot, a hme card and an adaptec > 29160, but I don't use the SCSI disk at the moment. Hmmm, none of these has boundary requirements of a form that were broken previously. The lowaddr breakage also affects none of them (it was quite harmless for the class of the PCI devices that is currently supported). > What I did to trigger the error was: > > 1) compile the code with the '3 * HE_....' changed to 1. > 2) install, kldload, ifconfig up -> ok > 3) compile the original code > 3) kldunload, install, kldload, ifconfig up -> baaaah > > 'baaaah' means, that a lot of strange things happen: the driver gets a lot > of interrupts, but the interrupt status words (these are written per DMA) > are invalid. when kldunloading sometimes I get a repeated loop of 'fast > data mmu ... miss' and ddb prompts. After booting (I need to switch the > machine off to do this!) the nvram checksum is usually bad and the machine > ofw status is reset. I tried to find the problem for 3 days now.... With > your patch applied things seem better, but I still fail to see why :-) So do I. Can you maybe put the full code of the driver in question somewhere for download? Thanks, - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 15: 0:28 2003 Delivered-To: freebsd-sparc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C4F237B401 for ; Fri, 17 Jan 2003 15:00:27 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F058443F5B for ; Fri, 17 Jan 2003 15:00:23 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0HN0NNS010671 for ; Fri, 17 Jan 2003 15:00:23 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0HN0NMJ010670; Fri, 17 Jan 2003 15:00:23 -0800 (PST) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C85A037B401 for ; Fri, 17 Jan 2003 14:56:16 -0800 (PST) Received: from kendra.ne.client2.attbi.com (kendra.ne.client2.attbi.com [24.147.23.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C27B43F1E for ; Fri, 17 Jan 2003 14:56:16 -0800 (PST) (envelope-from ahd@kew.com) Received: by kendra.ne.client2.attbi.com (Postfix, from userid 1001) id 80BA815500; Fri, 17 Jan 2003 17:56:10 -0500 (EST) Message-Id: <20030117225610.80BA815500@kendra.ne.client2.attbi.com> Date: Fri, 17 Jan 2003 17:56:10 -0500 (EST) From: Drew Derbyshire Reply-To: Drew Derbyshire To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 47175 >Category: sparc64 >Synopsis: Sparc Ultra 5/10 console not usable for FreeBSD install >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-sparc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Jan 17 15:00:23 PST 2003 >Closed-Date: >Last-Modified: >Originator: Drew Derbyshire >Release: FreeBSD 5.0 RC3 sparc64 >Organization: Kendra Electronic Wonderworks >Environment: System: Clean FreeBSD 5.0 RC3 install on Sun Ultra 5/10 UPA/PCI UltraSparc IIi 333Mhz) OpenFirmware Console with monitor on system video adapter and standard Sun keyboard from hell (tm). >Description: Attempted to install FReeBSD 5.0 RC3 on Sparc with system console. (OpenFirmware console and standard Sun keyboard). Install kernel prompt comes up with numerous choices for serial consoles, but none for the native console! Various choices all fail -- some produce garbled output, others are readable but don't highlight text and don't parse basic keyboard operations (such as up arrow). >How-To-Repeat: Boot FreeBSD 5.0 install CDROM on ultra Sparc with a real console. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 15: 4:39 2003 Delivered-To: freebsd-sparc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23D2637B401; Fri, 17 Jan 2003 15:04:39 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA90243ED8; Fri, 17 Jan 2003 15:04:38 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0HN4cNS012631; Fri, 17 Jan 2003 15:04:38 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0HN4cuZ012627; Fri, 17 Jan 2003 15:04:38 -0800 (PST) Date: Fri, 17 Jan 2003 15:04:38 -0800 (PST) From: Kris Kennaway Message-Id: <200301172304.h0HN4cuZ012627@freefall.freebsd.org> To: ahd@gnats.plus.kew.com, kris@FreeBSD.org, freebsd-sparc@FreeBSD.org Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: Sparc Ultra 5/10 console not usable for FreeBSD install State-Changed-From-To: open->closed State-Changed-By: kris State-Changed-When: Fri Jan 17 15:03:59 PST 2003 State-Changed-Why: Yes, console support is not yet available. http://www.freebsd.org/cgi/query-pr.cgi?pr=47175 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Jan 17 15:10: 9 2003 Delivered-To: freebsd-sparc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 345AF37B406 for ; Fri, 17 Jan 2003 15:10:08 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D61BA43EB2 for ; Fri, 17 Jan 2003 15:10:07 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0HNA7NS017750 for ; Fri, 17 Jan 2003 15:10:07 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0HNA7jY017749; Fri, 17 Jan 2003 15:10:07 -0800 (PST) Date: Fri, 17 Jan 2003 15:10:07 -0800 (PST) Message-Id: <200301172310.h0HNA7jY017749@freefall.freebsd.org> To: freebsd-sparc@FreeBSD.org Cc: From: Kris Kennaway Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install Reply-To: Kris Kennaway Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR sparc64/47175; it has been noted by GNATS. From: Kris Kennaway To: Drew Derbyshire Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install Date: Fri, 17 Jan 2003 15:03:28 -0800 On Fri, Jan 17, 2003 at 05:56:10PM -0500, Drew Derbyshire wrote: > Install kernel prompt comes up with numerous choices for > serial consoles, but none for the native console! Various > choices all fail -- some produce garbled output, others are > readable but don't highlight text and don't parse basic > keyboard operations (such as up arrow). "Yes" :-) i.e. well-known, documented limitation. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Jan 18 5:10:14 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AD6037B401 for ; Sat, 18 Jan 2003 05:10:13 -0800 (PST) Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BA843F18 for ; Sat, 18 Jan 2003 05:10:12 -0800 (PST) (envelope-from nick@freebsd.cx) Received: from host213-123-154-40.in-addr.btopenworld.com ([213.123.154.40] helo=cordelia.tachief.com) by carbon.btinternet.com with smtp (Exim 3.22 #16) id 18Zsjd-0002Ez-00 for sparc64@freebsd.org; Sat, 18 Jan 2003 13:10:05 +0000 Received: (qmail 27827 invoked by uid 1000); 18 Jan 2003 13:03:44 -0000 Date: Sat, 18 Jan 2003 13:03:44 +0000 From: Nick Jones To: Drew Derbyshire Cc: sparc64@freebsd.org Subject: Re: sparc64/47175: Sparc Ultra 5/10 console not usable for FreeBSD install Message-ID: <20030118130344.GA7513@cordelia.tachief.com> References: <20030117225610.80BA815500@kendra.ne.client2.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030117225610.80BA815500@kendra.ne.client2.attbi.com> User-Agent: Mutt/1.3.99i X-Operating-System: OpenBSD/3.2 (i386) X-Uptime: 1:00PM up 16 mins, 2 users, load averages: 0.22, 0.28, 0.29 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 17 Jan 2003 at 17:56:10 -0500, Drew Derbyshire wrote: > Install kernel prompt comes up with numerous choices for > serial consoles, but none for the native console! Various > choices all fail -- some produce garbled output, others are > readable but don't highlight text and don't parse basic > keyboard operations (such as up arrow). It *is* possible, albeit somewhat fiddly. Using termtype selection 1, you can use Ctrl-N and Ctrl-P to move up and down the list (you will see the cursor flash on the screen momentarily indictating the menu choice), space to select, and Ctrl-D to delete. Like I say - fiddly, but better than nothing if for some reason you are unable to install via a serial console :) -- /Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Jan 18 14:31:47 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4EF037B401 for ; Sat, 18 Jan 2003 14:31:46 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B73843F3F for ; Sat, 18 Jan 2003 14:31:46 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.6/8.12.2) with ESMTP id h0IMVjIx077190; Sat, 18 Jan 2003 14:31:45 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.6/8.12.6/Submit) id h0IMUQJo077161; Sat, 18 Jan 2003 14:30:26 -0800 (PST) Date: Sat, 18 Jan 2003 14:30:26 -0800 From: "David O'Brien" To: John Polstra Cc: sparc@freebsd.org, tmoestl@gmx.net Subject: Re: Sparc64 floating point questions Message-ID: <20030118223026.GJ70151@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mail-Followup-To: David O'Brien , John Polstra , sparc@freebsd.org, tmoestl@gmx.net References: <20030115003013.GA3536@crow.dom2ip.de> <200301150047.h0F0lNFc037477@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301150047.h0F0lNFc037477@vashon.polstra.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 14, 2003 at 04:47:23PM -0800, John Polstra wrote: > I don't know much about Sparc machines. But it sounds like there > exist 64-bit Sparcs which are not UltraSPARCs. So I'd better do it > the most general way. I'd have to stretch my brain to be sure about that (maybe the Fujitsu HAL?). For FreeBSD's purposes, you should assume that all 64-bit Sparcs are UltraSPARC's. That is certainly how I have the toolchain configured. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Jan 18 14:54:14 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 478DE37B401; Sat, 18 Jan 2003 14:54:13 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C13DF43EB2; Sat, 18 Jan 2003 14:54:12 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.6/8.12.2) with ESMTP id h0IMs5Ix077543; Sat, 18 Jan 2003 14:54:05 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.6/8.12.6/Submit) id h0IMqnN0077513; Sat, 18 Jan 2003 14:52:49 -0800 (PST) Date: Sat, 18 Jan 2003 14:52:49 -0800 From: "David O'Brien" To: Dominic Marks Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-sparc@freebsd.org Subject: Re: Port Fix: security/john Message-ID: <20030118225249.GM70151@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200301141737.h0EHb9Sx032782@moo.cus.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301141737.h0EHb9Sx032782@moo.cus.org.uk> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 14, 2003 at 05:37:09PM +0000, Dominic Marks wrote: > >Description: > My previous patch for this port doesn't seem to have worked as I > hoped it would, build still fails for alpha and sparc64 > machines. Here is a new patch which hopefully will make the port > build on bento, also, add 'native' support to john for > FreeBSD/sparc64, it should use the sparc assembler routines now. The port was upgraded to version 1.6.32 which builds fine on my Blade100. Can you take at look at that version and see if you still feel anything needs patching? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Jan 18 18:38:30 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49E7C37B401 for ; Sat, 18 Jan 2003 18:38:29 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98F2343E4A for ; Sat, 18 Jan 2003 18:38:28 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0J2dejb037761 for ; Sat, 18 Jan 2003 21:39:40 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0J2dd98037760 for freebsd-sparc@freebsd.org; Sat, 18 Jan 2003 21:39:39 -0500 (EST) Date: Sat, 18 Jan 2003 21:39:39 -0500 From: Jake Burkholder To: freebsd-sparc@freebsd.org Subject: if_xl supported in -current Message-ID: <20030118213939.A30009@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As of this afternoon (rev 1.122 of if_xl.c) the xl driver is supported on sparc64. There have been reports of problems with the driver in e250s, if you have one of these machines and an xl card please try it and report any problems, it should work fine in other machines. Thanks go to Maxime Henrion for converting the driver to use busdma, and to Thomas Moestl for making it endian clean. Have fun, Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message