From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 00:09:27 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CE3816A4CE; Sun, 6 Feb 2005 00:09:27 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC3BE43D5A; Sun, 6 Feb 2005 00:09:26 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j1609MWc060757; Sat, 5 Feb 2005 19:09:22 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j1609Cf7060756; Sat, 5 Feb 2005 19:09:12 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 5 Feb 2005 19:09:12 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050206000912.GA59372@VARK.MIT.EDU> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205181808.J10966@delplex.bde.org> cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-i386@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 00:09:27 -0000 On Sat, Feb 05, 2005, Bruce Evans wrote: > Better call the MI tan() to do all this. It won't take significantly > longer, and shouldn't be reached in most cases anyway. Yeah, but s_tan.S overrides s_tan.c, so that would require extra machinery. Also, if fptan had worked as advertised and correctly identified the cases where range reduction was necessary, calling rem_pio2() directly would have avoided superfluous range checking. > I think it is because fptan is inherently inaccurate. [...] As you mention, it gets the wrong answer for M_PI. In general, it seems to do pretty badly on numbers close to multiples of pi. Granted, one could argue that the answer returned is going to be even *further* from the answer the programmer expected (namely, 0), so it won't make much difference. ;-) BTW, Kahan has a program for producing large floating-point numbers close to multiples of pi/2: http://www.cs.berkeley.edu/~wkahan/testpi/ In investigating this, I discovered several interesting things: - The Intel software developer's guide says that fptan has an error of at most 1 ulp, but as we've seen, they're lying. - Maple 9.5 on sparc64 with Digits:=5000 corroborates fdlibm's answer to tan(M_PI). - fdlibm's tan() does not seem to be much slower than fptan on the range (-M_PI,M_PI), which is what people are most likely to care about. The MD version is faster for some inputs where the small angle approximation applies (|x| < 2^-28 implies x == tan(x)). fdlibm special cases this, too, but the special case isn't early enough, and the bugfix in fdlibm 5.3 slows things down. Throwing that special case out of the average, fdlibm seems to be faster! (NB: I benchmarked this very sloppily on ref4. Perhaps you could confirm the results...) Your suggestion of effectively special-casing large inputs and inputs close to multiples of pi is probably the right way to fix the inaccuracy. However, I'm worried that it would wipe away any performance benefit of using fptan, if there is a benefit at all. How about punting and removing s_tan.S instead? Other unanswered questions (ENOTIME right now): - What about sin() and cos()? - What about the float versions of these? From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 00:10:22 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C5A516A4CE for ; Sun, 6 Feb 2005 00:10:22 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE2F843D41 for ; Sun, 6 Feb 2005 00:10:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j160ALkd052991 for ; Sun, 6 Feb 2005 00:10:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j160ALwg052990; Sun, 6 Feb 2005 00:10:21 GMT (envelope-from gnats) Date: Sun, 6 Feb 2005 00:10:21 GMT Message-Id: <200502060010.j160ALwg052990@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: David Schultz Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 00:10:22 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Sat, 5 Feb 2005 19:09:12 -0500 On Sat, Feb 05, 2005, Bruce Evans wrote: > Better call the MI tan() to do all this. It won't take significantly > longer, and shouldn't be reached in most cases anyway. Yeah, but s_tan.S overrides s_tan.c, so that would require extra machinery. Also, if fptan had worked as advertised and correctly identified the cases where range reduction was necessary, calling rem_pio2() directly would have avoided superfluous range checking. > I think it is because fptan is inherently inaccurate. [...] As you mention, it gets the wrong answer for M_PI. In general, it seems to do pretty badly on numbers close to multiples of pi. Granted, one could argue that the answer returned is going to be even *further* from the answer the programmer expected (namely, 0), so it won't make much difference. ;-) BTW, Kahan has a program for producing large floating-point numbers close to multiples of pi/2: http://www.cs.berkeley.edu/~wkahan/testpi/ In investigating this, I discovered several interesting things: - The Intel software developer's guide says that fptan has an error of at most 1 ulp, but as we've seen, they're lying. - Maple 9.5 on sparc64 with Digits:=5000 corroborates fdlibm's answer to tan(M_PI). - fdlibm's tan() does not seem to be much slower than fptan on the range (-M_PI,M_PI), which is what people are most likely to care about. The MD version is faster for some inputs where the small angle approximation applies (|x| < 2^-28 implies x == tan(x)). fdlibm special cases this, too, but the special case isn't early enough, and the bugfix in fdlibm 5.3 slows things down. Throwing that special case out of the average, fdlibm seems to be faster! (NB: I benchmarked this very sloppily on ref4. Perhaps you could confirm the results...) Your suggestion of effectively special-casing large inputs and inputs close to multiples of pi is probably the right way to fix the inaccuracy. However, I'm worried that it would wipe away any performance benefit of using fptan, if there is a benefit at all. How about punting and removing s_tan.S instead? Other unanswered questions (ENOTIME right now): - What about sin() and cos()? - What about the float versions of these? From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 00:40:16 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1999F16A4CF for ; Sun, 6 Feb 2005 00:40:16 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92FC43D2F for ; Sun, 6 Feb 2005 00:40:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j160eFfW055005 for ; Sun, 6 Feb 2005 00:40:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j160eFjg055004; Sun, 6 Feb 2005 00:40:15 GMT (envelope-from gnats) Resent-Date: Sun, 6 Feb 2005 00:40:15 GMT Resent-Message-Id: <200502060040.j160eFjg055004@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, JD Bronson Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD8A16A4CE for ; Sun, 6 Feb 2005 00:38:43 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id E879143D1D for ; Sun, 6 Feb 2005 00:38:42 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j160cgZr058615 for ; Sun, 6 Feb 2005 00:38:42 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j160cgCf058614; Sun, 6 Feb 2005 00:38:42 GMT (envelope-from nobody) Message-Id: <200502060038.j160cgCf058614@www.freebsd.org> Date: Sun, 6 Feb 2005 00:38:42 GMT From: JD Bronson To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: i386/77154: 5.3 refuses to boot when IDE channel2 is enabled and no drive is installed X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 00:40:16 -0000 >Number: 77154 >Category: i386 >Synopsis: 5.3 refuses to boot when IDE channel2 is enabled and no drive is installed >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 06 00:40:15 GMT 2005 >Closed-Date: >Last-Modified: >Originator: JD Bronson >Release: 5.3 >Organization: Aurora Health Care >Environment: FreeBSD 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Feb 5 08:58:19 CST 2005 jbronson@shadow.wixb.com:/usr/obj/usr/src/sys/WIXB i386 >Description: Using 5.3 release is when I 1st noticed this. CVSup to 5.3-STABLE does not fix this trouble. If both IDE channels are enabled and they are all set to AUTO/AUTO for master/slave and there is no drive (yet) installed to IDE channel2, the machine hangs at boot. If I install a drive to IDE channel2, the machine boots. If I disable IDE channel2, the machine will boot as well. When it hangs, all I see on the console is: FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: ..if I hit at this point, the beastie menu comes up. The machine will NOT boot on it's own. >How-To-Repeat: See Description >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 07:32:43 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CD916A4CE; Sun, 6 Feb 2005 07:32:43 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9939943D48; Sun, 6 Feb 2005 07:32:42 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j167WfA6028875; Sun, 6 Feb 2005 18:32:41 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j167WcVU000427; Sun, 6 Feb 2005 18:32:39 +1100 Date: Sun, 6 Feb 2005 18:32:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20050206000912.GA59372@VARK.MIT.EDU> Message-ID: <20050206162951.J14584@delplex.bde.org> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050206000912.GA59372@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-gnats-submit@freebsd.org cc: freebsd-i386@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 07:32:43 -0000 On Sat, 5 Feb 2005, David Schultz wrote: > On Sat, Feb 05, 2005, Bruce Evans wrote: > > Better call the MI tan() to do all this. It won't take significantly > > longer, and shouldn't be reached in most cases anyway. > > Yeah, but s_tan.S overrides s_tan.c, so that would require extra > machinery. Also, if fptan had worked as advertised and correctly > identified the cases where range reduction was necessary, calling > rem_pio2() directly would have avoided superfluous range checking. I hacked the file (but not the machinery) easily enough for testing. fptan advertises to work? :-) At least the amd64 manual (instruction reference) only claims that it sets C2 if the arg is outside the range [-2^63,2^63]. > > I think it is because fptan is inherently inaccurate. [...] > > As you mention, it gets the wrong answer for M_PI. In general, it > seems to do pretty badly on numbers close to multiples of pi. > Granted, one could argue that the answer returned is going to be > even *further* from the answer the programmer expected (namely, 0), > so it won't make much difference. ;-) Too bad the correct answer is a little further from 0. > ... > - The Intel software developer's guide says that fptan has an error > of at most 1 ulp, but as we've seen, they're lying. The amd64 manual (application refrence) says "x87 computations are carried out in double extended precision format, so that the transcendental functions [are accurate to 1 ulp]". The "so that" part doesn't follow. We are seeing something like naive extended precision computations and how inaccurate they can be even when only a double precision result is wanted. > [... too much detail to reply to :-)] > Your suggestion of effectively special-casing large inputs and > inputs close to multiples of pi is probably the right way to fix > the inaccuracy. However, I'm worried that it would wipe away > any performance benefit of using fptan, if there is a benefit > at all. How about punting and removing s_tan.S instead? The problem affects at least sin() and cos() too, so I think throwing away the optimized versions is too extreme. Perhaps a single range check to let the MD version handle only values near 0 ([-pi/2+eps, pi/2-eps]? would be efficient enough. > Other unanswered questions (ENOTIME right now): > - What about sin() and cos()? > - What about the float versions of these? I tested sin(). It misbehaves similarly (with identical results for args (2 * n * M_PI). It's interesting that there is fptan and not ftan, but fsin and not fpsin. Both are partial. I don't run -current and hadn't seen your code for the MD float versions... They are buggier: (1) the exponent can be up to 127, so more than half of the representable values exceed 2^63 in magnitude and thus need range reduction. Results for tan(0x1p64) using various methods: buggy MD tanf: 0x1p+64 1.84467e+19 buggy MD tan: -0x1.8467b926c834bp-2 -0.379302 fdlibm MI tanf: -0x1.82bee6p-6 -0.0236051 bc s(x)/c(x) (scale=40): -.02360508353334969937000... bc s(x)/c(x) (default scale=20): -.02358521765210826916 It looks like fdlibm is perfect and scale=20 in bc is not quite enough. sinf(0x1p64) would be 0x1p64 too. This is preposterous for sin(). (2) they return extra bits of precision. The MD double precision versions have the same bug; the bug is just clearer for the float case, and cannot be fixed by FreeBSD's rounding precision hack. BTW, I don't trust the range reduction for floating point pi/2 but never finished debugging or fixing it. According to my old comment, it is off by pi/2 and very slow for many values between 32768 and 65535. However, I couldn't duplicate this misbehaviour last time I looked at it. I used to fix it using the double version. Bruce From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 07:40:13 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B7BC16A4CE for ; Sun, 6 Feb 2005 07:40:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FCFD43D31 for ; Sun, 6 Feb 2005 07:40:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j167eC1b036401 for ; Sun, 6 Feb 2005 07:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j167eChw036400; Sun, 6 Feb 2005 07:40:12 GMT (envelope-from gnats) Date: Sun, 6 Feb 2005 07:40:12 GMT Message-Id: <200502060740.j167eChw036400@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 07:40:13 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Sun, 6 Feb 2005 18:32:38 +1100 (EST) On Sat, 5 Feb 2005, David Schultz wrote: > On Sat, Feb 05, 2005, Bruce Evans wrote: > > Better call the MI tan() to do all this. It won't take significantly > > longer, and shouldn't be reached in most cases anyway. > > Yeah, but s_tan.S overrides s_tan.c, so that would require extra > machinery. Also, if fptan had worked as advertised and correctly > identified the cases where range reduction was necessary, calling > rem_pio2() directly would have avoided superfluous range checking. I hacked the file (but not the machinery) easily enough for testing. fptan advertises to work? :-) At least the amd64 manual (instruction reference) only claims that it sets C2 if the arg is outside the range [-2^63,2^63]. > > I think it is because fptan is inherently inaccurate. [...] > > As you mention, it gets the wrong answer for M_PI. In general, it > seems to do pretty badly on numbers close to multiples of pi. > Granted, one could argue that the answer returned is going to be > even *further* from the answer the programmer expected (namely, 0), > so it won't make much difference. ;-) Too bad the correct answer is a little further from 0. > ... > - The Intel software developer's guide says that fptan has an error > of at most 1 ulp, but as we've seen, they're lying. The amd64 manual (application refrence) says "x87 computations are carried out in double extended precision format, so that the transcendental functions [are accurate to 1 ulp]". The "so that" part doesn't follow. We are seeing something like naive extended precision computations and how inaccurate they can be even when only a double precision result is wanted. > [... too much detail to reply to :-)] > Your suggestion of effectively special-casing large inputs and > inputs close to multiples of pi is probably the right way to fix > the inaccuracy. However, I'm worried that it would wipe away > any performance benefit of using fptan, if there is a benefit > at all. How about punting and removing s_tan.S instead? The problem affects at least sin() and cos() too, so I think throwing away the optimized versions is too extreme. Perhaps a single range check to let the MD version handle only values near 0 ([-pi/2+eps, pi/2-eps]? would be efficient enough. > Other unanswered questions (ENOTIME right now): > - What about sin() and cos()? > - What about the float versions of these? I tested sin(). It misbehaves similarly (with identical results for args (2 * n * M_PI). It's interesting that there is fptan and not ftan, but fsin and not fpsin. Both are partial. I don't run -current and hadn't seen your code for the MD float versions... They are buggier: (1) the exponent can be up to 127, so more than half of the representable values exceed 2^63 in magnitude and thus need range reduction. Results for tan(0x1p64) using various methods: buggy MD tanf: 0x1p+64 1.84467e+19 buggy MD tan: -0x1.8467b926c834bp-2 -0.379302 fdlibm MI tanf: -0x1.82bee6p-6 -0.0236051 bc s(x)/c(x) (scale=40): -.02360508353334969937000... bc s(x)/c(x) (default scale=20): -.02358521765210826916 It looks like fdlibm is perfect and scale=20 in bc is not quite enough. sinf(0x1p64) would be 0x1p64 too. This is preposterous for sin(). (2) they return extra bits of precision. The MD double precision versions have the same bug; the bug is just clearer for the float case, and cannot be fixed by FreeBSD's rounding precision hack. BTW, I don't trust the range reduction for floating point pi/2 but never finished debugging or fixing it. According to my old comment, it is off by pi/2 and very slow for many values between 32768 and 65535. However, I couldn't duplicate this misbehaviour last time I looked at it. I used to fix it using the double version. Bruce From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 09:21:59 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1349616A4CE; Sun, 6 Feb 2005 09:21:59 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0BA043D1F; Sun, 6 Feb 2005 09:21:58 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j169Lq5K064331; Sun, 6 Feb 2005 04:21:52 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j169LpmI064330; Sun, 6 Feb 2005 04:21:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sun, 6 Feb 2005 04:21:51 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050206092151.GA63584@VARK.MIT.EDU> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050206000912.GA59372@VARK.MIT.EDU> <20050206162951.J14584@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050206162951.J14584@delplex.bde.org> cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-i386@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 09:21:59 -0000 On Sun, Feb 06, 2005, Bruce Evans wrote: > > [... too much detail to reply to :-)] > > Your suggestion of effectively special-casing large inputs and > > inputs close to multiples of pi is probably the right way to fix > > the inaccuracy. However, I'm worried that it would wipe away > > any performance benefit of using fptan, if there is a benefit > > at all. How about punting and removing s_tan.S instead? > > The problem affects at least sin() and cos() too, so I think throwing > away the optimized versions is too extreme. Perhaps a single range > check to let the MD version handle only values near 0 ([-pi/2+eps, > pi/2-eps]? would be efficient enough. > > > Other unanswered questions (ENOTIME right now): > > - What about sin() and cos()? > > - What about the float versions of these? > > I tested sin(). It misbehaves similarly (with identical results for > args (2 * n * M_PI). My question was more along the lines of, ``Is there an actual performance benefit for sin() and cos()?'' If there is little or no benefit, then there is no reason to keep the assembly routines and worry about how to fix them. I'll try to investigate this aspect in more detail at some point, unless you beat me to it... > I don't run -current and hadn't seen your code for the MD float versions... > They are buggier: > (1) the exponent can be up to 127, so more than half of the representable > values exceed 2^63 in magnitude and thus need range reduction. Results > for tan(0x1p64) using various methods: > > buggy MD tanf: 0x1p+64 1.84467e+19 > buggy MD tan: -0x1.8467b926c834bp-2 -0.379302 > fdlibm MI tanf: -0x1.82bee6p-6 -0.0236051 Whups. FWIW, they're not mine; I got them from NetBSD. Another one of the float functions in the NetBSD repository is buggy, too, but I forget which one. I only imported the ones that seemed to be correct and faster than fdlibm for input bit patterns chosen uniformly at random, but I guess I missed that problem. > (2) they return extra bits of precision. The MD double precision versions > have the same bug; the bug is just clearer for the float case, and > cannot be fixed by FreeBSD's rounding precision hack. > > BTW, I don't trust the range reduction for floating point pi/2 but > never finished debugging or fixing it. According to my old comment, > it is off by pi/2 and very slow for many values between 32768 and > 65535. However, I couldn't duplicate this misbehaviour last time I > looked at it. I used to fix it using the double version. Yeah, there seem to be many values for which __ieee754_rem_pio2f() returns the wrong quotient: -0x1.8009c6p+8 (input) d = -244 (return value of __ieee754_rem_pio2()) f = -4 (return value of __ieee754_rem_pio2f()) 0x1.389ee4p+87 d = 4 f = 3 -0x1.70bca6p+16 d = -60095 f = -7 It also gets the remainder completely wrong sometimes: 0x1.389ee4p+87 rd0 = -0x1.6ad286p-4 (y[0] from rem_pio2(), rounded to float) rf0 = 0x1.7b728cp+0 (y[0] from rem_pio2f()) 0x1.4d23ecp+95 rd0 = -0x1.ee68f8p-2 rf0 = 0x1.168578p+0 -0x1.5a172p+63 rd0 = 0x1.52f2aap-1 rf0 = -0x1.d14ccp-1 Also, rem_pio2f() is probably not much more efficient than rem_pio2(). The former would be better if it used a single double instead of two floats for increased accuracy. (The double version has two use two doubles for accuracy because there's no ``double double'' type.) Results for MI tan() differ from MI tanf() by >2 ulp for many inputs, including: 0x1.00008ep+15 0x1.0000ap+15 0x1.0000a4p+15 0x1.0000aep+15 [...] Perhaps this is due to the problem with rem_pio2f(). From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 09:30:21 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D61A816A4CE for ; Sun, 6 Feb 2005 09:30:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A019D43D1D for ; Sun, 6 Feb 2005 09:30:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j169ULZq068345 for ; Sun, 6 Feb 2005 09:30:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j169ULM1068344; Sun, 6 Feb 2005 09:30:21 GMT (envelope-from gnats) Date: Sun, 6 Feb 2005 09:30:21 GMT Message-Id: <200502060930.j169ULM1068344@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: David Schultz Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 09:30:22 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Sun, 6 Feb 2005 04:21:51 -0500 On Sun, Feb 06, 2005, Bruce Evans wrote: > > [... too much detail to reply to :-)] > > Your suggestion of effectively special-casing large inputs and > > inputs close to multiples of pi is probably the right way to fix > > the inaccuracy. However, I'm worried that it would wipe away > > any performance benefit of using fptan, if there is a benefit > > at all. How about punting and removing s_tan.S instead? > > The problem affects at least sin() and cos() too, so I think throwing > away the optimized versions is too extreme. Perhaps a single range > check to let the MD version handle only values near 0 ([-pi/2+eps, > pi/2-eps]? would be efficient enough. > > > Other unanswered questions (ENOTIME right now): > > - What about sin() and cos()? > > - What about the float versions of these? > > I tested sin(). It misbehaves similarly (with identical results for > args (2 * n * M_PI). My question was more along the lines of, ``Is there an actual performance benefit for sin() and cos()?'' If there is little or no benefit, then there is no reason to keep the assembly routines and worry about how to fix them. I'll try to investigate this aspect in more detail at some point, unless you beat me to it... > I don't run -current and hadn't seen your code for the MD float versions... > They are buggier: > (1) the exponent can be up to 127, so more than half of the representable > values exceed 2^63 in magnitude and thus need range reduction. Results > for tan(0x1p64) using various methods: > > buggy MD tanf: 0x1p+64 1.84467e+19 > buggy MD tan: -0x1.8467b926c834bp-2 -0.379302 > fdlibm MI tanf: -0x1.82bee6p-6 -0.0236051 Whups. FWIW, they're not mine; I got them from NetBSD. Another one of the float functions in the NetBSD repository is buggy, too, but I forget which one. I only imported the ones that seemed to be correct and faster than fdlibm for input bit patterns chosen uniformly at random, but I guess I missed that problem. > (2) they return extra bits of precision. The MD double precision versions > have the same bug; the bug is just clearer for the float case, and > cannot be fixed by FreeBSD's rounding precision hack. > > BTW, I don't trust the range reduction for floating point pi/2 but > never finished debugging or fixing it. According to my old comment, > it is off by pi/2 and very slow for many values between 32768 and > 65535. However, I couldn't duplicate this misbehaviour last time I > looked at it. I used to fix it using the double version. Yeah, there seem to be many values for which __ieee754_rem_pio2f() returns the wrong quotient: -0x1.8009c6p+8 (input) d = -244 (return value of __ieee754_rem_pio2()) f = -4 (return value of __ieee754_rem_pio2f()) 0x1.389ee4p+87 d = 4 f = 3 -0x1.70bca6p+16 d = -60095 f = -7 It also gets the remainder completely wrong sometimes: 0x1.389ee4p+87 rd0 = -0x1.6ad286p-4 (y[0] from rem_pio2(), rounded to float) rf0 = 0x1.7b728cp+0 (y[0] from rem_pio2f()) 0x1.4d23ecp+95 rd0 = -0x1.ee68f8p-2 rf0 = 0x1.168578p+0 -0x1.5a172p+63 rd0 = 0x1.52f2aap-1 rf0 = -0x1.d14ccp-1 Also, rem_pio2f() is probably not much more efficient than rem_pio2(). The former would be better if it used a single double instead of two floats for increased accuracy. (The double version has two use two doubles for accuracy because there's no ``double double'' type.) Results for MI tan() differ from MI tanf() by >2 ulp for many inputs, including: 0x1.00008ep+15 0x1.0000ap+15 0x1.0000a4p+15 0x1.0000aep+15 [...] Perhaps this is due to the problem with rem_pio2f(). From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 12:28:04 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72BC316A4CF; Sun, 6 Feb 2005 12:28:04 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7755043D48; Sun, 6 Feb 2005 12:28:03 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j16CRxHn013487; Sun, 6 Feb 2005 23:27:59 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j16CRv8w022949; Sun, 6 Feb 2005 23:27:58 +1100 Date: Sun, 6 Feb 2005 23:27:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Schultz In-Reply-To: <20050206092151.GA63584@VARK.MIT.EDU> Message-ID: <20050206225602.H2484@epsplex.bde.org> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050206000912.GA59372@VARK.MIT.EDU> <20050206162951.J14584@delplex.bde.org> <20050206092151.GA63584@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-gnats-submit@freebsd.org cc: freebsd-i386@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 12:28:04 -0000 On Sun, 6 Feb 2005, David Schultz wrote: > On Sun, Feb 06, 2005, Bruce Evans wrote: > ... > > BTW, I don't trust the range reduction for floating point pi/2 but > > never finished debugging or fixing it. According to my old comment, > > it is off by pi/2 and very slow for many values between 32768 and > > 65535. However, I couldn't duplicate this misbehaviour last time I > > looked at it. I used to fix it using the double version. > > Yeah, there seem to be many values for which __ieee754_rem_pio2f() > returns the wrong quotient: > > -0x1.8009c6p+8 (input) > d = -244 (return value of __ieee754_rem_pio2()) > f = -4 (return value of __ieee754_rem_pio2f()) > ... > It also gets the remainder completely wrong sometimes: > > 0x1.389ee4p+87 > rd0 = -0x1.6ad286p-4 (y[0] from rem_pio2(), rounded to float) > rf0 = 0x1.7b728cp+0 (y[0] from rem_pio2f()) > ... I didn't check these. When I tried to debug this, I got confused by y[0] quite often legitimately differing, because the result is in y[1] and the integer result too and there are many equivalent combinations. I also started checking the float trig functions on all 2^32 possible args, but got discouraged by too many differences of more than 1 ulp. > Also, rem_pio2f() is probably not much more efficient than > rem_pio2(). The former would be better if it used a single double > instead of two floats for increased accuracy. (The double version > has two use two doubles for accuracy because there's no ``double > double'' type.) As you know, this is related to the general uselessness of the float interfaces on machines with doubles. But SSE1 makes this more interesting even on i386's. Floats might be faster despite the existence of doubles because a different ALU can be used for them. > Results for MI tan() differ from MI tanf() by >2 ulp for many > inputs, including: > > 0x1.00008ep+15 > 0x1.0000ap+15 > 0x1.0000a4p+15 > 0x1.0000aep+15 > [...] > > Perhaps this is due to the problem with rem_pio2f(). It does. Reverting to my version of rem_pio2f() that just calls rem_pio2() fixes the MI tanf() on all these values. Here is the patch. The changes in the "#if 0" part seemed to help for some cases but they don't help much for the above values. %%% Index: e_rem_pio2f.c =================================================================== RCS file: /home/ncvs/src/lib/msun/src/e_rem_pio2f.c,v retrieving revision 1.7 diff -u -2 -r1.7 e_rem_pio2f.c --- e_rem_pio2f.c 28 May 2002 17:51:46 -0000 1.7 +++ e_rem_pio2f.c 6 Feb 2005 11:53:53 -0000 @@ -58,10 +58,10 @@ single precision and the last 8 bits are forced to 0. */ static const int32_t npio2_hw[] = { -0x3fc90f00, 0x40490f00, 0x4096cb00, 0x40c90f00, 0x40fb5300, 0x4116cb00, -0x412fed00, 0x41490f00, 0x41623100, 0x417b5300, 0x418a3a00, 0x4196cb00, -0x41a35c00, 0x41afed00, 0x41bc7e00, 0x41c90f00, 0x41d5a000, 0x41e23100, -0x41eec200, 0x41fb5300, 0x4203f200, 0x420a3a00, 0x42108300, 0x4216cb00, -0x421d1400, 0x42235c00, 0x4229a500, 0x422fed00, 0x42363600, 0x423c7e00, -0x4242c700, 0x42490f00 +0x3fc90f80, 0x40490f80, 0x4096cb80, 0x40c90f80, 0x40fb5380, 0x4116cb80, +0x412fed80, 0x41490f80, 0x41623180, 0x417b5380, 0x418a3a80, 0x4196cb80, +0x41a35c80, 0x41afed80, 0x41bc7e80, 0x41c90f80, 0x41d5a080, 0x41e23180, +0x41eec280, 0x41fb5380, 0x4203f200, 0x420a3a80, 0x42108300, 0x4216cb80, +0x421d1400, 0x42235c80, 0x4229a500, 0x422fed80, 0x42363600, 0x423c7e80, +0x4242c700, 0x42490f80, }; @@ -88,6 +88,8 @@ pio2_3t = 6.1232342629e-17; /* 0x248d3132 */ - int32_t __ieee754_rem_pio2f(float x, float *y) +int32_t +__ieee754_rem_pio2f(float x, float *y) { +#if 0 float z,w,t,r,fn; float tx[3]; @@ -129,5 +131,5 @@ r = t-fn*pio2_1; w = fn*pio2_1t; /* 1st round good to 40 bit */ - if(n<32&&(ix&0xffffff00)!=npio2_hw[n-1]) { + if(n<32&&(ix&0xffffff80)!=npio2_hw[n-1]) { y[0] = r-w; /* quick check no cancellation */ } else { @@ -177,3 +179,19 @@ if(hx<0) {y[0] = -y[0]; y[1] = -y[1]; return -n;} return n; +#else + /* + * The above is broken for many values of x between 32768 + * and 65536-epsilon. It is wrong by +pi/2 at best. It + * is also very slow for these values. Just use the double + * precision version. This only works on machines with + * double precision of course. + */ + double new_y[2]; + int n; + + n = __ieee754_rem_pio2((double)x, new_y); + y[0] = new_y[0]; + y[1] = (new_y[0] - y[0]) + new_y[1]; + return n; +#endif } %%% The comment about off by pi/2 errors is probably wrong. I now think the problem is that small errors errors lead to n being off by 1. Then y[0] is off by pi/2 to sort of compensate. Bruce From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 12:30:23 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6518316A4CE for ; Sun, 6 Feb 2005 12:30:23 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2955843D3F for ; Sun, 6 Feb 2005 12:30:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j16CUMTo074153 for ; Sun, 6 Feb 2005 12:30:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j16CUMwq074144; Sun, 6 Feb 2005 12:30:22 GMT (envelope-from gnats) Date: Sun, 6 Feb 2005 12:30:22 GMT Message-Id: <200502061230.j16CUMwq074144@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 12:30:23 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Sun, 6 Feb 2005 23:27:56 +1100 (EST) On Sun, 6 Feb 2005, David Schultz wrote: > On Sun, Feb 06, 2005, Bruce Evans wrote: > ... > > BTW, I don't trust the range reduction for floating point pi/2 but > > never finished debugging or fixing it. According to my old comment, > > it is off by pi/2 and very slow for many values between 32768 and > > 65535. However, I couldn't duplicate this misbehaviour last time I > > looked at it. I used to fix it using the double version. > > Yeah, there seem to be many values for which __ieee754_rem_pio2f() > returns the wrong quotient: > > -0x1.8009c6p+8 (input) > d = -244 (return value of __ieee754_rem_pio2()) > f = -4 (return value of __ieee754_rem_pio2f()) > ... > It also gets the remainder completely wrong sometimes: > > 0x1.389ee4p+87 > rd0 = -0x1.6ad286p-4 (y[0] from rem_pio2(), rounded to float) > rf0 = 0x1.7b728cp+0 (y[0] from rem_pio2f()) > ... I didn't check these. When I tried to debug this, I got confused by y[0] quite often legitimately differing, because the result is in y[1] and the integer result too and there are many equivalent combinations. I also started checking the float trig functions on all 2^32 possible args, but got discouraged by too many differences of more than 1 ulp. > Also, rem_pio2f() is probably not much more efficient than > rem_pio2(). The former would be better if it used a single double > instead of two floats for increased accuracy. (The double version > has two use two doubles for accuracy because there's no ``double > double'' type.) As you know, this is related to the general uselessness of the float interfaces on machines with doubles. But SSE1 makes this more interesting even on i386's. Floats might be faster despite the existence of doubles because a different ALU can be used for them. > Results for MI tan() differ from MI tanf() by >2 ulp for many > inputs, including: > > 0x1.00008ep+15 > 0x1.0000ap+15 > 0x1.0000a4p+15 > 0x1.0000aep+15 > [...] > > Perhaps this is due to the problem with rem_pio2f(). It does. Reverting to my version of rem_pio2f() that just calls rem_pio2() fixes the MI tanf() on all these values. Here is the patch. The changes in the "#if 0" part seemed to help for some cases but they don't help much for the above values. %%% Index: e_rem_pio2f.c =================================================================== RCS file: /home/ncvs/src/lib/msun/src/e_rem_pio2f.c,v retrieving revision 1.7 diff -u -2 -r1.7 e_rem_pio2f.c --- e_rem_pio2f.c 28 May 2002 17:51:46 -0000 1.7 +++ e_rem_pio2f.c 6 Feb 2005 11:53:53 -0000 @@ -58,10 +58,10 @@ single precision and the last 8 bits are forced to 0. */ static const int32_t npio2_hw[] = { -0x3fc90f00, 0x40490f00, 0x4096cb00, 0x40c90f00, 0x40fb5300, 0x4116cb00, -0x412fed00, 0x41490f00, 0x41623100, 0x417b5300, 0x418a3a00, 0x4196cb00, -0x41a35c00, 0x41afed00, 0x41bc7e00, 0x41c90f00, 0x41d5a000, 0x41e23100, -0x41eec200, 0x41fb5300, 0x4203f200, 0x420a3a00, 0x42108300, 0x4216cb00, -0x421d1400, 0x42235c00, 0x4229a500, 0x422fed00, 0x42363600, 0x423c7e00, -0x4242c700, 0x42490f00 +0x3fc90f80, 0x40490f80, 0x4096cb80, 0x40c90f80, 0x40fb5380, 0x4116cb80, +0x412fed80, 0x41490f80, 0x41623180, 0x417b5380, 0x418a3a80, 0x4196cb80, +0x41a35c80, 0x41afed80, 0x41bc7e80, 0x41c90f80, 0x41d5a080, 0x41e23180, +0x41eec280, 0x41fb5380, 0x4203f200, 0x420a3a80, 0x42108300, 0x4216cb80, +0x421d1400, 0x42235c80, 0x4229a500, 0x422fed80, 0x42363600, 0x423c7e80, +0x4242c700, 0x42490f80, }; @@ -88,6 +88,8 @@ pio2_3t = 6.1232342629e-17; /* 0x248d3132 */ - int32_t __ieee754_rem_pio2f(float x, float *y) +int32_t +__ieee754_rem_pio2f(float x, float *y) { +#if 0 float z,w,t,r,fn; float tx[3]; @@ -129,5 +131,5 @@ r = t-fn*pio2_1; w = fn*pio2_1t; /* 1st round good to 40 bit */ - if(n<32&&(ix&0xffffff00)!=npio2_hw[n-1]) { + if(n<32&&(ix&0xffffff80)!=npio2_hw[n-1]) { y[0] = r-w; /* quick check no cancellation */ } else { @@ -177,3 +179,19 @@ if(hx<0) {y[0] = -y[0]; y[1] = -y[1]; return -n;} return n; +#else + /* + * The above is broken for many values of x between 32768 + * and 65536-epsilon. It is wrong by +pi/2 at best. It + * is also very slow for these values. Just use the double + * precision version. This only works on machines with + * double precision of course. + */ + double new_y[2]; + int n; + + n = __ieee754_rem_pio2((double)x, new_y); + y[0] = new_y[0]; + y[1] = (new_y[0] - y[0]) + new_y[1]; + return n; +#endif } %%% The comment about off by pi/2 errors is probably wrong. I now think the problem is that small errors errors lead to n being off by 1. Then y[0] is off by pi/2 to sort of compensate. Bruce From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 16:38:37 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEBAE16A4CE; Sun, 6 Feb 2005 16:38:36 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 066F743D39; Sun, 6 Feb 2005 16:38:36 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: by smtp.des.no (Pony Express, from userid 666) id 83296530C; Sun, 6 Feb 2005 17:38:34 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E9D485308; Sun, 6 Feb 2005 17:37:56 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 666) id 506E1B861; Sun, 6 Feb 2005 17:37:56 +0100 (CET) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050206163756.506E1B861@dwp.des.no> Date: Sun, 6 Feb 2005 17:37:56 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=ADDR_FREE,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 Subject: [releng_4_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 16:38:37 -0000 TB --- 2005-02-06 15:45:26 - tinderbox 2.3 running on dwp.des.no TB --- 2005-02-06 15:45:26 - starting RELENG_4_8 tinderbox run for i386/i386 TB --- 2005-02-06 15:45:26 - mkdir /home/tinderbox/sandbox/RELENG_4_8/i386 TB --- 2005-02-06 15:45:26 - mkdir /home/tinderbox/sandbox/RELENG_4_8/i386/i386 TB --- 2005-02-06 15:45:26 - checking out the source tree TB --- 2005-02-06 15:45:26 - cd /home/tinderbox/sandbox/RELENG_4_8/i386/i386 TB --- 2005-02-06 15:45:26 - /usr/bin/cvs -f -R -q -d/home/ncvs checkout -P -rRELENG_4_8 src TB --- 2005-02-06 15:57:12 - building world (CFLAGS=-O -pipe) TB --- 2005-02-06 15:57:12 - cd /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src TB --- 2005-02-06 15:57:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/tinderbox/sandbox/RELENG_4_8/i386/i386/obj/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2005-02-06 16:29:43 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-02-06 16:29:43 - cd /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src TB --- 2005-02-06 16:29:43 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 6 16:29:43 UTC 2005 >>> Kernel build for GENERIC completed on Sun Feb 6 16:34:04 UTC 2005 TB --- 2005-02-06 16:34:04 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2005-02-06 16:34:04 - cd /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src TB --- 2005-02-06 16:34:04 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 6 16:34:04 UTC 2005 [...] /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/dev/fb/vga.c:1331: warning: `filll_io' defined but not used /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/dev/fb/vga.c:1321: warning: `fill' defined but not used cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/../include -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-builtin -mpreferred-stack-boundary=2 /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/dev/fe/if_fe_isa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/../include -I/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-builtin -mpreferred-stack-boundary=2 /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/dev/kbd/atkbd.c In file included from /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/dev/kbd/atkbd.c:251: atkbdmap.h:113: `PASTE' undeclared here (not in a function) atkbdmap.h:113: initializer element is not constant atkbdmap.h:113: (near initialization for `key_map.key[102].map[1]') *** Error code 1 Stop in /home/tinderbox/sandbox/RELENG_4_8/i386/i386/obj/home/tinderbox/sandbox/RELENG_4_8/i386/i386/src/sys/LINT. *** Error code 1 Stop in /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src. *** Error code 1 Stop in /home/tinderbox/sandbox/RELENG_4_8/i386/i386/src. TB --- 2005-02-06 16:37:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-06 16:37:56 - ERROR: failed to build lint kernel TB --- 2005-02-06 16:37:56 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Sun Feb 6 17:17:36 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AABE916A4CE for ; Sun, 6 Feb 2005 17:17:36 +0000 (GMT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 28AAE43D54 for ; Sun, 6 Feb 2005 17:17:36 +0000 (GMT) (envelope-from meka@softhome.net) Received: (qmail 12590 invoked by uid 417); 6 Feb 2005 17:17:34 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 6 Feb 2005 17:17:34 -0000 Received: from hal9000 ([82.208.205.27]) (AUTH: LOGIN meka@softhome.net) by softhome.net with esmtp; Sun, 06 Feb 2005 10:17:23 -0700 Date: Mon, 7 Feb 2005 19:29:33 +0100 From: "Meka[ni]" To: FreeBSD Message-ID: <20050207192933.171eb0d8@hal9000> X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: networked sound X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 17:17:36 -0000 I really don't know how to search for it (google or freebsd.org) because I don't know the exact name of the program (deamon?). What I would like to do is to plug my amplifier to FreeBSD box and that all other sound coming from other computers are played trough FreeBSD one. So, I need something like a module/driver (bsd, linux and windows) that will add virtual sound card to the machine. Linux and FreeBSD are important. I would like to have Windows driver, too, but it is not so important (games and music). I can make a mixer (something like DJ mixer), but I would really hate to make more cables fit into my room. Computers are connected on the LAN so it would be wonderful to eliminate the need for extra cables. Thanx. :o) _________________ Sometimes we want so much to explain, that we forget about the five senses we have and that could be better ways of communication than words From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 01:50:20 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE0316A4CE for ; Mon, 7 Feb 2005 01:50:20 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04DA543D3F for ; Mon, 7 Feb 2005 01:50:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j171oJwX065333 for ; Mon, 7 Feb 2005 01:50:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j171oJWU065326; Mon, 7 Feb 2005 01:50:19 GMT (envelope-from gnats) Date: Mon, 7 Feb 2005 01:50:19 GMT Message-Id: <200502070150.j171oJWU065326@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jeremy Chadwick Subject: Re: i386/73865: NOINET6=yes in /etc/make.conf ignored X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jeremy Chadwick List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 01:50:20 -0000 The following reply was made to PR i386/73865; it has been noted by GNATS. From: Jeremy Chadwick To: freebsd-gnats-submit@FreeBSD.org, vman@tmok.com Cc: Subject: Re: i386/73865: NOINET6=yes in /etc/make.conf ignored Date: Sun, 6 Feb 2005 17:50:36 -0800 I can confirm this bug in 5.3-STABLE as of 2005/02/06 @ 17:30 PST. The rpcbind source code needs appropriate '#ifdef NOINET6' framework. As it stands now, it just blindly tries to bind to a IPv6 UDP socket. If this is something the FreeBSD folks can't do due to limited time, I can probably come up with the framework myself. Please let me know if this is the case, and I'll do my best to submit a patch. This should really be reassigned to medium priority, not low. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 02:00:42 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1364F16A4CE for ; Mon, 7 Feb 2005 02:00:42 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED3F543D54 for ; Mon, 7 Feb 2005 02:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1720fiH065616 for ; Mon, 7 Feb 2005 02:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1720f7x065615; Mon, 7 Feb 2005 02:00:41 GMT (envelope-from gnats) Date: Mon, 7 Feb 2005 02:00:41 GMT Message-Id: <200502070200.j1720f7x065615@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Jeremy Chadwick Subject: Re: i386/73865: NOINET6=yes in /etc/make.conf ignored X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jeremy Chadwick List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 02:00:42 -0000 The following reply was made to PR i386/73865; it has been noted by GNATS. From: Jeremy Chadwick To: freebsd-gnats-submit@FreeBSD.org, vman@tmok.com Cc: Subject: Re: i386/73865: NOINET6=yes in /etc/make.conf ignored Date: Sun, 6 Feb 2005 18:01:25 -0800 Included here is the applicable patch. Thankfully someone had already written the main framework in the .c and .h files (re: #ifdef INET6). This is patch applies to src/usr.sbin/rpcbind/Makefile. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | ----- SNIP ----- --- rpcbind/Makefile.orig Fri Apr 4 09:49:18 2003 +++ rpcbind/Makefile Sun Feb 6 17:57:07 2005 @@ -13,7 +13,11 @@ rpcb_svc.c rpcb_svc_com.c security.c warmstart.c util.c \ rpc_generic.c -CFLAGS+= -I${LIBCRPCDIR} -I${LIBCINCLUDE} -DPORTMAP -DINET6 -DLIBWRAP +CFLAGS+= -I${LIBCRPCDIR} -I${LIBCINCLUDE} -DPORTMAP -DLIBWRAP + +.if !defined(NOINET6) +CFLAGS+= -DINET6 +.endif DPADD= ${LIBWRAP} ${LIBUTIL} LDADD= -lwrap -lutil From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 03:40:17 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8711516A4CE for ; Mon, 7 Feb 2005 03:40:17 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C92B43D39 for ; Mon, 7 Feb 2005 03:40:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j173eGwj078151 for ; Mon, 7 Feb 2005 03:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j173eGQY078150; Mon, 7 Feb 2005 03:40:16 GMT (envelope-from gnats) Resent-Date: Mon, 7 Feb 2005 03:40:16 GMT Resent-Message-Id: <200502070340.j173eGQY078150@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Frank Mayhar Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F260216A4CE for ; Mon, 7 Feb 2005 03:35:15 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F8B943D2D for ; Mon, 7 Feb 2005 03:35:13 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.1/8.13.1) with ESMTP id j173ZAdM064059 for ; Sun, 6 Feb 2005 19:35:10 -0800 (PST) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.1/8.12.9) with ESMTP id j173ZA8l026538 for ; Sun, 6 Feb 2005 19:35:10 -0800 (PST) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.1/8.13.1/Submit) id j173ZA2G026537; Sun, 6 Feb 2005 19:35:10 -0800 (PST) (envelope-from frank) Message-Id: <200502070335.j173ZA2G026537@realtime.exit.com> Date: Sun, 6 Feb 2005 19:35:10 -0800 (PST) From: Frank Mayhar To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: i386/77189: Kernel panic "pmap_mapdev: Couldn't alloc kernel virtual memory" starting XFree86 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Frank Mayhar List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 03:40:17 -0000 >Number: 77189 >Category: i386 >Synopsis: Kernel panic "pmap_mapdev: Couldn't alloc kernel virtual memory" starting XFree86 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 07 03:40:16 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Frank Mayhar >Release: FreeBSD 4.11-STABLE i386 >Organization: Exit Consulting >Environment: System: FreeBSD realtime.exit.com 4.11-STABLE FreeBSD 4.11-STABLE #4: Thu Jan 20 12:24:45 PST 2005 frank@realtime.exit.com:/usr/obj/usr/src/sys/REALTIME i386 Running XFree86 4.4.0 trying to do direct rendering with a Radeon 8500 128MB display card. Happens on 4-stable up to and including 4.11. >Description: I consistently hit a panic, "pmap_mapdev: Couldn't alloc kernel virtual memory," when I try to start XFree86 4.4 with agp.ko and radeon.ko loaded. I have a Radeon 8500 display card with 128MB of memory and I would like to do direct rendering on it, but this bug makes doing so impossible. The stack looks like: #3 0xc01837d9 in poweroff_wait (junk=0xc0341340, howto=0xc5397300) at /usr/src/sys/kern/kern_shutdown.c:612 #4 0xc02dbbb2 in pmap_mapdev (pa=0xe0000000, size=0x8000000) at /usr/src/sys/i386/i386/pmap.c:3067 #5 0xc54d377a in radeon_ioremap (dev=0xc54c4000, map=0xc5397300) at @/dev/drm/drm_memory.h:243 #6 0xc54cf001 in radeon_addmap (kdev=0xc54c6d00, cmd=0xc0186415, data=0xf90d6ea4 "", flags=0x3, p=0xf8f6ad40) at @/dev/drm/drm_bufs.h:125 #7 0xc54d21ec in radeon_ioctl (kdev=0xc54c6d00, cmd=0xc0186415, data=0xf90d6ea4 "", flags=0x3, p=0xf8f6ad40) at @/dev/drm/drm_drv.h:1122 #8 0xc01bd8ee in spec_poll (ap=0xf90d6de0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:323 #9 0xc01bd619 in spec_open (ap=0xf90d6de0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:147 #10 0xc025c84d in default_pager_getpages (object=0xf90d6de0, m=0xc54fccc0, count=0x0, reqpage=0x18) at /usr/src/sys/vm/default_pager.c:100 #11 0xc01b9f57 in vn_ioctl (fp=0xc54fccc0, com=0xc0186415, data=0xf90d6ea4 "", p=0xf8f6ad40) at /usr/src/sys/kern/vfs_vnops.c:607 #12 0xc0192e52 in ioctl (p=0xf8f6ad40, uap=0xf90d6f80) at /usr/src/sys/kern/sys_generic.c:637 #13 0xc02dde79 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0x883f010, tf_esi = 0x7, tf_ebp = 0xbfbff580, tf_isp = 0xf90d6fd4, tf_ebx = 0x0, tf_edx = 0x8000000, tf_ecx = 0x0, tf_eax = 0x36, tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x4822568c, tf_cs = 0x1f, tf_eflags = 0x3293, tf_esp = 0xbfbff554, tf_ss = 0x2f}) at /usr/src/sys/i386/i386/trap.c:1175 And the request like: (kgdb) print *map $5 = { offset = 0xe0000000, size = 0x8000000, type = _DRM_FRAME_BUFFER, flags = 0, handle = 0x0, mtrr = 0x1, iot = 0x0, ioh = 0x0 } (kgdb) print request $6 = { offset = 0xe0000000, size = 0x8000000, type = _DRM_FRAME_BUFFER, flags = 0, handle = 0x0, mtrr = 0x7 } Looking at the code in question, it's clear that it's trying to allocate the virtual space for the frame buffer, described in the logfile: (--) RADEON(0): Chipset: "ATI Radeon 8500 QL (AGP)" (ChipID = 0x514c) (--) RADEON(0): Linear framebuffer at 0xe0000000 (--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM) And the allocation is failing. It seems somewhat unfriendly to panic the kernel in this case, especially since the calling code in radeon_ioremap() knows how to handle a null return from pmap_mapdev() (it bumps a "fail" counter and returns NULL). It would also be really nice to know just why the allocation is failing, since this machine has 2GB in it. Do I need to increase the number of PTEs somehow? Just FYI, kernel_map looks like (kgdb) print *kernel_map $20 = { header = { prev = 0xe09d9ff0, next = 0xc03a2330, start = 0xbfeff000, end = 0xffbff000, avail_ssize = 0x0, object = { vm_object = 0x0, sub_map = 0x0 }, offset = 0x0, eflags = 0x0, protection = 0x0, max_protection = 0x0, inheritance = 0x0, wired_count = 0x0, lastr = 0x0 }, lock = { lk_interlock = { lock_data = 0x0 }, lk_flags = 0x1000000, lk_sharecount = 0x0, lk_waitcount = 0x0, lk_exclusivecount = 0x0, lk_prio = 0x4, lk_wmesg = 0xc0326554 "thrd_sleep", lk_timo = 0x0, lk_lockholder = 0xffffffff }, nentries = 0xc3, size = 0x391ab000, system_map = 0x1, infork = 0x0, hint = 0xe09da470, timestamp = 0x49a, first_free = 0xe09d9300, pmap = 0xc03b2720 } I'll have the dump lying around for a while, so if there's any more information you would like, let me know. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 07:50:10 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956FB16A4CE; Mon, 7 Feb 2005 07:50:10 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C698C43D1F; Mon, 7 Feb 2005 07:50:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j177o9E8020048; Mon, 7 Feb 2005 02:50:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j177q5B1074444; Mon, 7 Feb 2005 02:52:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EB2467306E; Mon, 7 Feb 2005 02:50:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050207075008.EB2467306E@freebsd-current.sentex.ca> Date: Mon, 7 Feb 2005 02:50:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 07:50:10 -0000 TB --- 2005-02-07 05:44:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-07 05:44:52 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-02-07 05:44:52 - checking out the source tree TB --- 2005-02-07 05:44:52 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-02-07 05:44:52 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-07 06:00:28 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-07 06:00:28 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-07 06:00:28 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-07 07:24:31 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-07 07:24:31 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-07 07:24:31 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 7 07:24:31 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Feb 7 07:38:22 UTC 2005 TB --- 2005-02-07 07:38:22 - generating LINT kernel config TB --- 2005-02-07 07:38:22 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2005-02-07 07:38:22 - /usr/bin/make -B LINT TB --- 2005-02-07 07:38:22 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-07 07:38:22 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-07 07:38:22 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 7 07:38:22 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/home/tinderbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make sh /tinderbox/CURRENT/i386/pc98/src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline vers.c linking kernel upd7210.o(.text+0xf47): In function `do_idata': : undefined reference to `isa_dmatc' *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-02-07 07:50:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-07 07:50:08 - ERROR: failed to build lint kernel TB --- 2005-02-07 07:50:08 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 08:01:01 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBBD716A4CE; Mon, 7 Feb 2005 08:01:01 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209D643D49; Mon, 7 Feb 2005 08:01:01 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id C2574530C; Mon, 7 Feb 2005 09:00:59 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 8C1EC5308; Mon, 7 Feb 2005 09:00:39 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id EDA4CB86E; Mon, 7 Feb 2005 09:00:38 +0100 (CET) To: FreeBSD Tinderbox References: <20050206163756.506E1B861@dwp.des.no> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 07 Feb 2005 09:00:38 +0100 In-Reply-To: <20050206163756.506E1B861@dwp.des.no> (FreeBSD Tinderbox's message of "Sun, 6 Feb 2005 17:37:56 +0100 (CET)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: stable@freebsd.org cc: i386@freebsd.org Subject: Re: [releng_4_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 08:01:02 -0000 FreeBSD Tinderbox writes: > TB --- 2005-02-06 15:45:26 - tinderbox 2.3 running on dwp.des.no Ack! This was a test run, I didn't intend for mail to go out but forgot to change the rc file. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 08:07:12 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D47CD16A4CE; Mon, 7 Feb 2005 08:07:12 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 753BD43D1F; Mon, 7 Feb 2005 08:07:12 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3F49F51485; Mon, 7 Feb 2005 00:07:10 -0800 (PST) Date: Mon, 7 Feb 2005 00:07:10 -0800 From: Kris Kennaway To: Dag-Erling Sm?rgrav Message-ID: <20050207080710.GA15085@xor.obsecurity.org> References: <20050206163756.506E1B861@dwp.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: stable@freebsd.org cc: FreeBSD Tinderbox cc: i386@freebsd.org Subject: Re: [releng_4_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 08:07:13 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 07, 2005 at 09:00:38AM +0100, Dag-Erling Sm?rgrav wrote: > FreeBSD Tinderbox writes: > > TB --- 2005-02-06 15:45:26 - tinderbox 2.3 running on dwp.des.no >=20 > Ack! This was a test run, I didn't intend for mail to go out but > forgot to change the rc file. It's okay, no-one reads these mails any more anyway :-) Kris --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCByGtWry0BWjoQKURAjWPAJ454NhuQcBbxjRRJXR2+Qis+7K6EwCfXsx8 EeHT1/jrNrUsm59aHueYRCU= =ormG -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 11:01:46 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81B8716A4CE for ; Mon, 7 Feb 2005 11:01:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBFDC43D5D for ; Mon, 7 Feb 2005 11:01:45 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j17B1j0Z059306 for ; Mon, 7 Feb 2005 11:01:45 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j17B1iT7059300 for freebsd-i386@freebsd.org; Mon, 7 Feb 2005 11:01:44 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Feb 2005 11:01:44 GMT Message-Id: <200502071101.j17B1iT7059300@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-i386@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 11:01:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/10/06] i386/57673 i386 [disklabel] Odd/dangerous disklabel behav o [2004/02/16] i386/62902 i386 Data Corruption on Dell PE 600SC (Server o [2004/04/16] i386/65646 i386 FreeBSD suddenly turns off the power o [2004/04/28] i386/66039 i386 panic: system panic with file system corr o [2004/05/27] i386/67260 i386 [boot] stack overflow after boot menu whe o [2004/09/05] i386/71395 i386 Data corrupted on Serverworks CG-SL chips o [2004/09/09] i386/71538 i386 [install] multi-homed install trashes exi o [2005/01/18] i386/76397 i386 ata raid crashes in g_down (heavy load) o [2005/02/01] i386/76944 i386 i386 bus_dmamap_create() bug o [2005/02/01] i386/76948 i386 Slow network with rl0 (rl0 driver problem o [2005/02/02] i386/77016 i386 Problem starting a jail in FreeBSD 5.2.1- 11 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/13] i386/25781 i386 Statclocks cannot be disabled on ServerWo o [2002/07/05] i386/40219 i386 [apm] apm breaks removable media o [2002/10/16] i386/44130 i386 Enabled apm hangs up FreeBSD kernel on i8 o [2003/02/24] i386/48614 i386 VESA VGA modes for syscons lock up machin o [2003/05/22] i386/52556 i386 Syskonnect SK9843SX, sk driver, MII not d o [2003/05/22] i386/52581 i386 Boot loaders reading more than one sector o [2003/05/24] i386/52638 i386 SCSI U320 on SMP server won't run faster o [2003/06/06] i386/52975 i386 CPUTYPE=k7 results in non-functional /boo o [2003/06/11] i386/53200 i386 [boot] 5.1-RC1 SMP kernel boot gags at "A o [2003/06/16] i386/53382 i386 Repetable panics in ffs_vget() on Prolian o [2003/06/23] i386/53620 i386 [install] Kernel panics / reboots during o [2003/07/02] i386/54033 i386 Disk lockup. o [2003/07/15] i386/54501 i386 Promise Ultra133 TX2 does not work proper o [2003/08/13] i386/55555 i386 system freezes with access to /dev/ums0 o [2003/08/13] i386/55561 i386 SMbus and I2C don't attach when loaded as o [2003/08/15] i386/55615 i386 machine freezes - goes on after key press a [2003/08/24] i386/55930 i386 partly configured serial port freezes sys o [2003/09/17] i386/56937 i386 panic: system panic during high network l o [2003/09/20] i386/57043 i386 [hang] ar driver with 2 port PCI card loc f [2003/09/22] i386/57097 i386 [hang] Promise Ultra 100 TX2 causes locku p [2003/10/01] i386/57480 i386 Removing very large files using rm doesn' o [2003/10/09] i386/57818 i386 4.9-RC panics when kernel is built with a o [2003/10/16] i386/58139 i386 [panic] -CURRENT panics on Thinkpad A31p o [2003/10/23] i386/58458 i386 ATAPI-CDROM DMA Support on ALi Aladdin V o [2003/10/26] i386/58580 i386 After sysinstall, F2 fails; wrong device o [2003/10/30] i386/58718 i386 need to remove battery before booting lap o [2003/11/02] i386/58826 i386 reboot on an IBM PC Server 315 merely hal o [2003/11/11] i386/59192 i386 ATA drive not spotted with SCSI drive o [2003/11/25] i386/59683 i386 panic: signal 12 4.9-STABLE - frequent cr o [2003/11/26] i386/59701 i386 System hungup, after resume from suspend. o [2003/12/02] i386/59895 i386 [hang] system hangs from disk IO errors [ f [2003/12/02] i386/59897 i386 [hang] problems with swap-pager with grea f [2003/12/02] i386/59898 i386 [boot] pxe boot: BTX halted o [2003/12/17] i386/60344 i386 [boot] Intel ICH5 SATA RAID boot problems o [2003/12/27] i386/60603 i386 dd causes error when copying cd from ATA o [2003/12/27] i386/60633 i386 [hang] SIS motherboard with the SIS 5591 o [2003/12/27] i386/60641 i386 Sporadic SCSI bus resets with 53C810 unde o [2003/12/28] i386/60671 i386 FreeBSD 5.2RC2 installation process doesn o [2003/12/29] i386/60681 i386 wicontrol -L critical crash (sigbus) o [2003/12/29] i386/60690 i386 atapicd driver causes spontaneous uncondi o [2004/01/04] i386/60887 i386 can't boot when fbsd exists with other op o [2004/01/08] i386/61063 i386 [ata] ata hangs in smp system f [2004/01/10] i386/61163 i386 [boot] "/:write failed, filesystem is ful o [2004/01/12] i386/61253 i386 [panic] page fault on installation freebs o [2004/01/13] i386/61303 i386 5.2-REL hangs during boot with 3-port pyr o [2004/01/13] i386/61326 i386 Reboot while booting from 5.2-RELEASE CD o [2004/01/14] i386/61342 i386 [hang] CD-based installation crashes [4.9 o [2004/01/20] i386/61646 i386 [workaround] Strange irq20 weirdness caus o [2004/01/22] i386/61705 i386 [ntp] Random "bus errors" on 5.2-RELEASE o [2004/01/22] i386/61709 i386 [panic] 5.2-REL i386 Crashes hard; panics o [2004/01/25] i386/61890 i386 [fdisk] FDisk uses incorrect calculations f [2004/02/02] i386/62248 i386 [boot] 5.2 current hangs on boot o [2004/02/02] i386/62280 i386 em0 broken after resume in 5.2-CURRENT o [2004/02/09] i386/62565 i386 device.hints are not honored in 5.2.1-RC o [2004/02/13] i386/62807 i386 4.9 SMP does not work with Compaq Smart o [2004/02/15] i386/62888 i386 ad4: WARNING - WRITE_DMA interrupt was se o [2004/02/24] i386/63305 i386 reading udf filesystem on dvd+rw leads to o [2004/02/27] i386/63430 i386 [ata] TIMEOUT - ATA READ o [2004/02/27] i386/63441 i386 [panic] fatal trap 12 in pmap.c [4.9 with o [2004/02/27] i386/63467 i386 [ata] Sil 3114: RAID not detected using S o [2004/03/03] i386/63678 i386 5.2.1 installation hangs on t30 o [2004/03/04] i386/63776 i386 [boot] hang during boot on a toshiba p25 o [2004/03/06] i386/63828 i386 [hang] when installing Release 5.2.1 (i38 o [2004/03/06] i386/63853 i386 [hang] 5.2.1 boot CD hangs during boot (T o [2004/03/07] i386/63871 i386 [panic] kernel panic in swi8 after 1 hour o [2004/03/09] i386/63992 i386 [hang] XFree86 4.3 hangs on IBM ThinkPad o [2004/03/12] i386/64183 i386 5.1-RELEASE Install hung at "Probing devi o [2004/03/19] i386/64450 i386 Lucent Technologies WaveLAN/IEEE (PCI) fr o [2004/03/25] i386/64680 i386 5.2.1 pci-cfgintr steals serial mouse irq o [2004/03/25] i386/64697 i386 5.2.x BTX loader halts with Promise FastT o [2004/03/25] i386/64716 i386 [nis] mv crashes FreeBSD 5.2.1-p3 o [2004/03/25] i386/64727 i386 [boot] cannot find disk on asus p4s533mx o [2004/04/03] i386/65137 i386 [boot] 5.2.1 Intall Boot from floppies pa o [2004/04/14] i386/65523 i386 [patch] PXE loader malfunction in multipl o [2004/04/19] i386/65775 i386 [panic] Transmeta crusoe without longrun o [2004/04/22] i386/65896 i386 [panic] 5.2-RELEASE re(4) driver, kernel f [2004/04/25] i386/65954 i386 [panic] Sil0680 panic [5.2.1-p5] o [2004/04/29] i386/66087 i386 [install] hang at PCI config [5.2.1] o [2004/05/01] i386/66133 i386 [boot] nvidia motherboard installer locks o [2004/05/06] i386/66306 i386 pnpbios_identify() queries for more devic f [2004/05/06] i386/66339 i386 [hang] XFree86 initialization with an Lap o [2004/05/07] i386/66350 i386 [sysinstall] sysinstall creates a partiti o [2004/05/07] i386/66368 i386 [install] 4.9 install fails with MODE_SEN o [2004/05/19] i386/66876 i386 [patch] Cannot extract tar(1) multi-volum o [2004/05/22] i386/67047 i386 mpt driver does not recognize messages fr o [2004/06/01] i386/67469 i386 src/lib/msun/i387/s_tan.S gives incorrect o [2004/06/07] i386/67688 i386 5.2.1 initial floppy boot fails with Fata o [2004/06/11] i386/67833 i386 [boot] 4.10 does not boot after enabling f [2004/06/15] i386/67955 i386 [panic] -current on T40p kernel trap 12 i o [2004/06/27] i386/68411 i386 VMware Virtual Machine - Network Fails Du o [2004/06/28] i386/68438 i386 bootloader cannot read from icp vortex ar o [2004/06/28] i386/68460 i386 [nfs] NFS mounts lock processes in sbwait o [2004/07/01] i386/68554 i386 [hang] system freeze on Compaq Evo 600c [ o [2004/07/10] i386/68899 i386 Problems reading and writing DVD-RAM disc o [2004/07/11] i386/68900 i386 5.x install CDs fail to boot on Toshiba S o [2004/07/14] i386/69049 i386 [install] error "anic: page fault" o [2004/07/19] i386/69260 i386 [install] Problem starting the installati o [2004/07/19] i386/69281 i386 init dies when MAXSSIZ, MAXDSIZ, and DFLD f [2004/08/03] i386/69945 i386 "Page fault" while shutting down on VIA K o [2004/08/05] i386/70028 i386 umass isuue in the boot prcess on SONY La o [2004/08/11] i386/70330 i386 Re-Open 33262? - gdb does not handle pend o [2004/08/13] i386/70386 i386 IBM x345 Freezes Randomly o [2004/08/15] i386/70482 i386 Array adapter problems o [2004/08/16] i386/70525 i386 [boot] boot0cfg: -o packet not effective o [2004/08/16] i386/70531 i386 [patch] boot0 hides Lilo in extended slic o [2004/08/19] i386/70663 i386 Freebsd 4.10 ncplogin + Netware 4.11 = nw o [2004/08/20] i386/70747 i386 ddos attack causes box to crash on kernel f [2004/08/21] i386/70805 i386 [apm] page fault early during boot with a o [2004/08/25] i386/70925 i386 [hang] 5.3Beta1 acpi-pci driver failure, f [2004/08/25] i386/70962 i386 [install] When downloading the installer o [2004/08/26] i386/71000 i386 [boot] BTX halted when booting from CD on o [2004/08/27] i386/71048 i386 [hang] ASUS TUV4X hangs when SONY CRX140E o [2004/08/28] i386/71087 i386 [hang] 5.3-beta(2-5) fail to install on e o [2004/08/30] i386/71144 i386 FBSD5.3b2 doesn't boot on a Compaq Armada o [2004/08/30] i386/71158 i386 pci bus number 3 devices are missing on l o [2004/08/31] i386/71190 i386 Dead thinkpad R31 after installing 5.2.1 o [2004/08/31] i386/71208 i386 Intel EtherExpress not working o [2004/09/05] i386/71392 i386 5.3-Beta[2-5] crash after final sync when o [2004/09/06] i386/71428 i386 DMA does not work on VIA 82C586 [4.10] o [2004/09/07] i386/71470 i386 [hang] Asus P4P800-E Promise 20378 RAID 1 o [2004/09/12] i386/71641 i386 5.3-BETA3: wi0 hangs during kernel load o [2004/09/19] i386/71894 i386 burncd unkillable with bad CD's o [2004/09/22] i386/72004 i386 [boot] FreeBSD 5.2.1 install hangs with e o [2004/09/24] i386/72065 i386 4.x and 5.2.1 doesn't recognize PCnet/ISA f [2004/09/24] i386/72069 i386 [panic] Fatal trap 12: page fault while i o [2004/09/30] i386/72215 i386 with acpi enabled network card will not w o [2004/10/04] i386/72334 i386 7) i386|[boot] FreeBSD 5.3 Beta6 and Beta o [2004/10/05] i386/72343 i386 Suspend resets system on Inspiron 5160. o [2004/10/06] i386/72378 i386 NFS hangs in 5.3-BETA7 [3Com gbit card] o [2004/10/07] i386/72416 i386 FreeBSD 5.3-BETA7: The alternate systemcl o [2004/10/08] i386/72441 i386 HP Proliant DL380 hangs on reboot with 5. o [2004/10/09] i386/72456 i386 5.xx Releases Do Not Identify ATA when 4. o [2004/10/12] i386/72579 i386 unable to install FreeBSD on Intel E7520 o [2004/10/17] i386/72778 i386 5.3beta7 never boots, suspected SMP probl o [2004/10/21] i386/72960 i386 BTX halted with Promise Tx2000 Raid o [2004/10/21] i386/72976 i386 [panic] trap 9 on boot [ACPI-related] o [2004/10/25] i386/73102 i386 FreeBSD hangs on boot-up of omnibook 4150 o [2004/10/27] i386/73182 i386 fxp0: device timeout o [2004/10/27] i386/73196 i386 [hang]5.2.1 boot CD hangs during boot on o [2004/10/29] i386/73265 i386 FreeBSD kernel crashes when booting on EC o [2004/10/30] i386/73298 i386 "Fatal trap 12: page fault while in kerne o [2004/11/03] i386/73484 i386 Kernel panic when doing `ls` from the cli o [2004/11/07] i386/73640 i386 FreeBSD 5.2.1 y ahora 5.3 se queda congel o [2004/11/08] i386/73658 i386 ed(4) can't get correct MAC address o [2004/11/08] i386/73666 i386 5.3 UDMA error WD1600 can't partition dri f [2004/11/10] i386/73765 i386 Install Issue on DELL Oplex 260 [5.3R] o [2004/11/14] i386/73934 i386 fdisk sees disk as empty o [2004/11/16] i386/74008 i386 IBM eServer x225 cannot boot any v5.x - e o [2004/11/17] i386/74044 i386 ServerWorks OSB4 SMBus interface does not o [2004/11/18] i386/74074 i386 hw.ata.wc=0 / but write cache still enabl o [2004/11/19] i386/74124 i386 ata0 failure on HP(Vectra) VL6/350 [intro o [2004/11/21] i386/74217 i386 init died [Presario 2500] o [2004/11/28] i386/74467 i386 On a freshly installed FreeBSD-4.10 (bina o [2004/11/29] i386/74532 i386 Install will not boot on Toshiba Satalite o [2004/12/01] i386/74576 i386 FAILURE - ATA_IDENTIFY no interrupt o [2004/12/01] i386/74595 i386 Suspected FreeBSD-4.10 rndcontrol(8) rela o [2004/12/01] i386/74601 i386 Cardbus fails after busdma_machdep.c upda o [2004/12/02] i386/74605 i386 5.3 networking impossibly slow on 32M p15 o [2004/12/07] i386/74816 i386 OS crash with kernel trap 12 in different o [2004/12/08] i386/74860 i386 on kernel recompile, "make depend" fails o [2004/12/09] i386/74892 i386 FBSD 5.3-STABLE randomly crashes (Fatal t o [2004/12/10] i386/74923 i386 kernel panic with ncplist on 5.3-release o [2004/12/12] i386/74988 i386 dma errors with large maxtor hard drives o [2004/12/14] i386/75041 i386 Sk driver gets "Corrupt MAC on input" dur o [2004/12/16] i386/75165 i386 if ng_pppoe switches to nonstandard mode o [2004/12/17] i386/75201 i386 nge driver causes FreeBSD 5.3-RELEASE and o [2004/12/23] i386/75441 i386 fxp device timeout o [2004/12/27] i386/75531 i386 Various DMA errors result in system panic o [2005/01/05] i386/75847 i386 system freeze on Medion laptop o [2005/01/06] i386/75887 i386 with vt0.disabled=0 and PCVT in kernel vi o [2005/01/10] i386/76023 i386 xmms causes panic o [2005/01/11] i386/76105 i386 PF on renamed interfaces page fault while o [2005/01/15] i386/76294 i386 builtin gzip in tar fails o [2005/01/17] i386/76372 i386 cannot burn iso image disk2 of any releas o [2005/01/20] i386/76487 i386 Compiled GENERIC kernel (and non-GENERIC) o [2005/01/25] i386/76666 i386 Booting and Sound are mutually exclusive o [2005/01/27] i386/76737 i386 CardBus problem (cbb1: Could not map regi o [2005/01/28] i386/76785 i386 Installation Errors o [2005/01/30] i386/76840 i386 aureal-kmod locks the STABLE snapshot of o [2005/01/30] i386/76851 i386 AGP unrecognized & Over Use of my CPU o [2005/01/31] i386/76925 i386 standard pci-ide, install - "NO DISKS FOU o [2005/02/06] i386/77154 i386 5.3 refuses to boot when IDE channel2 is o [2005/02/07] i386/77189 i386 Kernel panic "pmap_mapdev: Couldn't alloc 183 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/24] i386/40958 i386 apm on Acer TravelMate 351 could not resu o [2002/08/21] i386/41856 i386 VESA splash screen problems on ThinkPad 2 o [2003/05/14] i386/52249 i386 [PATCH] Bootmanager shows NTFS partitions o [2003/05/19] i386/52427 i386 DVD replay under MSI "655 MAX" mobo inter o [2003/06/14] i386/53324 i386 pam_group problems (PAM_RUSER used instea o [2003/10/31] i386/58784 i386 ATA DMA fails and vx0 creates panic o [2003/11/23] conf/59600 i386 [PATCH] Improved us.emacs.kbd mapping f [2003/11/30] i386/59854 i386 System panics when AMD 762 AGP is loaded o [2003/12/17] i386/60319 i386 [hang] read error 34/0 during installatio o [2003/12/29] i386/60702 i386 can't boot 5.2-RC2 iso's to install o [2004/01/05] misc/60919 i386 No login possible (sporadic) o [2004/01/06] i386/60963 i386 [PATCH] Win32 Applications abort on PECOF o [2004/01/07] i386/61005 i386 [boot] The Boot Manager in FreeBSD 5.2RC o [2004/01/13] i386/61308 i386 Maxproc Limits counts Zombie Processes wh o [2004/01/14] i386/61348 i386 Adaptec 1460D PCI SCSI Card does not work o [2004/01/16] i386/61442 i386 Highpoint RocketRAID 1520 uses only UDMA2 o [2004/01/17] i386/61481 i386 [patch] a mechanism to wire io-channel-ch o [2004/01/20] i386/61603 i386 [sysinstall] wrong geometry guessed o [2004/01/24] i386/61838 i386 Realtek -8139C Card Not Supported o [2004/01/24] i386/61843 i386 Intel PRO/100 VE adapter is not recognize f [2004/01/25] i386/61889 i386 Have to reinsert pccard after reboot o [2004/01/27] i386/62003 i386 [patch] make /boot/loader "reboot" code s o [2004/02/17] i386/62977 i386 Mouse daemon during install/setup f [2004/02/25] i386/63334 i386 make kernel error o [2004/03/05] i386/63815 i386 boot loader waste a lot of time (10 min) o [2004/03/23] i386/64626 i386 AP initialization problem on GIGABYTE GA- f [2004/03/27] i386/64795 i386 Network Adapter not configuring o [2004/04/03] i386/65124 i386 Unable to disable TERM_EMU cleanly o [2004/04/14] i386/65528 i386 mouse cursor disapears on moving o [2004/04/18] i386/65691 i386 fxp0: device timeout p [2004/04/18] i386/65729 i386 Document machdep.hlt_cpus sysctl f [2004/05/21] i386/66996 i386 Problem with CD/DVD ROM o [2004/05/22] i386/67055 i386 Mouse (wheel) detection problem on SIS748 o [2004/05/30] i386/67383 i386 [patch] do a better job disassembling cod o [2004/06/01] i386/67456 i386 [LOR] LOR on dual-xeon w/ ht o [2004/06/09] i386/67763 i386 [patch] PCMCIA: MELCO manufacturer code s o [2004/06/10] i386/67773 i386 5.x series - md5 on dev no longer works e o [2004/06/18] i386/68087 i386 wget core dumps with: Assertion failed: ( o [2004/06/19] i386/68117 i386 serious network collisions after NIC "med o [2004/06/20] i386/68140 i386 Problem with Sony AIT ATAPI Tape dirve o [2004/06/30] i386/68514 i386 Realtek driver halts on oversized frames o [2004/06/30] i386/68518 i386 Hangs while loading 82443BX agp during bo o [2004/07/07] i386/68754 i386 [hang] SMP reset bug (Tyan Thunder100, 44 o [2004/07/18] i386/69257 i386 [patch] in_cksum_hdr is non-functional wi o [2004/07/23] i386/69460 i386 the nic's speed slow down when both side o [2004/07/28] kern/69688 i386 NATD does not work with outgoing PPTP VPN o [2004/07/28] i386/69722 i386 wi0: init failed o [2004/07/29] i386/69730 i386 [patch] puc driver doesn't support PC-Com o [2004/08/02] kern/69931 i386 PS/2 Optical Mouse (Micro Innovations) mi f [2004/08/05] i386/70036 i386 pcn device not recognizing device o [2004/08/18] i386/70610 i386 [patch] spkr(4): hardcoded assumption HZ o [2004/08/22] i386/70810 i386 [patch] Enable SMBus device on Asus P4B s o [2004/08/22] i386/70832 i386 Serious problems with RealTek NIC using r o [2004/08/25] i386/70926 i386 [boot] 5.3Beta-1 bootstrap error: "atapci o [2004/09/11] i386/71586 i386 FreeBSD 5.3-BETA3 #3 hang during boot on o [2004/09/20] i386/71924 i386 timeouts with ata+hpt366 controller on BE o [2004/09/29] i386/72179 i386 Inconsistent apm(8) output regarding the o [2004/10/30] i386/73308 i386 kevinxlinuz@126.com o [2004/10/30] i386/73328 i386 top shows NICE as -111 on processes start o [2004/11/08] i386/73663 i386 module_register_init: MOD_LOAD (ibcs2, 0x o [2004/11/08] i386/73673 i386 ifconfig tun0 destroy report: ifconfig: S o [2004/11/09] i386/73742 i386 5.3 rel i386 disk2 image not copying o [2004/11/10] i386/73785 i386 I have just downloaded 5.3 ISO to try.. N o [2004/11/12] i386/73847 i386 volume label - 5.3 cd 1 o [2004/11/12] i386/73865 i386 NOINET6=yes in /etc/make.conf ignored o [2004/11/14] i386/73921 i386 sysctlbyname for machdep.tsc_freq doesn't o [2004/11/15] i386/73968 i386 pkg_version ends with Unable to open INDE o [2004/11/15] i386/73978 i386 an error message appears during loading o o [2004/11/18] i386/74091 i386 PCMCIA: MELCO Manufacturer code should be o [2004/11/20] i386/74153 i386 FreeBSD 5.3 cannot boot ftom pst o [2004/11/21] i386/74188 i386 no sound on a7v600-x with chipset VT8237 o [2004/11/21] i386/74191 i386 Notebook PC2001 Compliant AC97 audio work o [2004/11/21] i386/74211 i386 USB flash drive causes CAM status 0x4 on o [2004/11/21] i386/74216 i386 system halts o [2004/11/21] i386/74218 i386 boot floppy (2nd time) read error o [2004/11/24] i386/74327 i386 mlock() causes physical memory leakage o [2004/11/26] i386/74406 i386 sysinstall accepts but discards media opt o [2004/11/27] i386/74454 i386 [PATCH] Adding VIA Eden family to bsd.cpu o [2004/12/01] i386/74593 i386 Installer installs the wrong version of l o [2004/12/03] i386/74650 i386 System Reboot with umount command o [2004/12/07] i386/74803 i386 3Com509B o [2004/12/08] i386/74829 i386 FreeBSD 5.3-RELEASE hangs during boot/ins o [2004/12/12] i386/74966 i386 Realtek driver seems to misinterpret some o [2004/12/12] i386/74971 i386 vinum creates (shows) incorrect volume (s o [2004/12/14] i386/75057 i386 [QUIRK] Add support for ZICPlay USB MP3 P o [2004/12/15] i386/75090 i386 READ_BIG errors with Sony CRX1611 o [2004/12/22] i386/75387 i386 Future support of Promise SATAII150 TX4 w o [2004/12/23] i386/75420 i386 CMD 648 PCI not work o [2004/12/28] i386/75570 i386 chflags nosappnd directory doesn't work o [2004/12/28] i386/75583 i386 Installation fails o [2004/12/29] i386/75589 i386 O2Micro pccard1 slot not functioning whil o [2005/01/04] i386/75776 i386 NO ps/2 keyboard using USB keyboard under o [2005/01/05] i386/75862 i386 fpsetsticky() incorrectly clears, instead o [2005/01/06] i386/75898 i386 Exception and reboot: Loader and kernel u o [2005/01/09] i386/76013 i386 patch to allow mod_frontpage to work with o [2005/01/09] i386/76019 i386 security patch -- use binaries from rtr i o [2005/01/10] i386/76041 i386 patch to allow mod_frontpage to work with o [2005/01/23] i386/76587 i386 ps2 mouse weird... o [2005/01/25] i386/76653 i386 Problem with Asahi Optical usb device (Pe o [2005/01/26] i386/76707 i386 Bind 9 - query-source bug? o [2005/01/27] i386/76752 i386 /usr/bin/login o [2005/01/27] i386/76775 i386 BIND9 and dynamic updates 102 problems total. From owner-freebsd-i386@FreeBSD.ORG Mon Feb 7 21:50:14 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6075416A4CE for ; Mon, 7 Feb 2005 21:50:14 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E1B43D48 for ; Mon, 7 Feb 2005 21:50:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j17LoDfn040603 for ; Mon, 7 Feb 2005 21:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j17LoDPj040602; Mon, 7 Feb 2005 21:50:13 GMT (envelope-from gnats) Resent-Date: Mon, 7 Feb 2005 21:50:13 GMT Resent-Message-Id: <200502072150.j17LoDPj040602@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, David Perry Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E344416A4CF for ; Mon, 7 Feb 2005 21:46:44 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7353D43D1D for ; Mon, 7 Feb 2005 21:46:44 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j17Lkh33089243 for ; Mon, 7 Feb 2005 21:46:43 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j17Lkh6m089239; Mon, 7 Feb 2005 21:46:43 GMT (envelope-from nobody) Message-Id: <200502072146.j17Lkh6m089239@www.freebsd.org> Date: Mon, 7 Feb 2005 21:46:43 GMT From: David Perry To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: i386/77239: 3Com 3CXFEM656C does not seem to be supported by xl driver, despite HARDWARE.TXT X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 21:50:14 -0000 >Number: 77239 >Category: i386 >Synopsis: 3Com 3CXFEM656C does not seem to be supported by xl driver, despite HARDWARE.TXT >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 07 21:50:13 GMT 2005 >Closed-Date: >Last-Modified: >Originator: David Perry >Release: 5.3-RELEASE >Organization: LLNL >Environment: FreeBSD 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 (Hand-typed -- may contain typos) >Description: HARDWARE.TXT says that the 3Com CardBus 3CXFEM656C NIC is supported by the xl driver, but that does not seem to be the case. I have a Dell Latitude CPx which I installed from a downloaded ISO. My experience seems to be the same as that of Karel Miklav (http://lists.freebsd.org/pipermail/freebsd-mobile/2004-October/005103.html). The driver seems to read the card, but cannot configure it (from dmesg): xl0: <3Com 3c656C Fast Etherlink XL> port 0x1000-0x10ff mem 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on cardbus1 xl0: using memory mapped I/O xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: eeprom failed to come ready xl0: failed to read station address device_attach: xl0 attach returned 6 >How-To-Repeat: Re-installed once with same results. Reboot shows the same dmesg output. >Fix: None >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Tue Feb 8 00:43:19 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 648EE16A4CE; Tue, 8 Feb 2005 00:43:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFCB43D2D; Tue, 8 Feb 2005 00:43:19 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j180hJ37060467; Tue, 8 Feb 2005 00:43:19 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j180hJBU060463; Tue, 8 Feb 2005 00:43:19 GMT (envelope-from kris) Date: Tue, 8 Feb 2005 00:43:19 GMT From: Kris Kennaway Message-Id: <200502080043.j180hJBU060463@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/76041: patch to allow mod_frontpage to work with security fix from rtr X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 00:43:19 -0000 Synopsis: patch to allow mod_frontpage to work with security fix from rtr Responsible-Changed-From-To: freebsd-i386->freebsd-ports-bugs Responsible-Changed-By: kris Responsible-Changed-When: Tue Feb 8 00:42:52 GMT 2005 Responsible-Changed-Why: Correct category and mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=76041 From owner-freebsd-i386@FreeBSD.ORG Tue Feb 8 00:43:49 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 388CE16A4CE; Tue, 8 Feb 2005 00:43:49 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB26843D46; Tue, 8 Feb 2005 00:43:48 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j180hmYQ060514; Tue, 8 Feb 2005 00:43:48 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j180hm6B060510; Tue, 8 Feb 2005 00:43:48 GMT (envelope-from kris) Date: Tue, 8 Feb 2005 00:43:48 GMT From: Kris Kennaway Message-Id: <200502080043.j180hm6B060510@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/76013: patch to allow mod_frontpage to work with security fix from rtr X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 00:43:49 -0000 Synopsis: patch to allow mod_frontpage to work with security fix from rtr Responsible-Changed-From-To: freebsd-i386->freebsd-ports-bugs Responsible-Changed-By: kris Responsible-Changed-When: Tue Feb 8 00:43:24 GMT 2005 Responsible-Changed-Why: Correct category and mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=76013 From owner-freebsd-i386@FreeBSD.ORG Tue Feb 8 00:45:05 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E1016A4CE; Tue, 8 Feb 2005 00:45:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6162443D2F; Tue, 8 Feb 2005 00:45:05 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j180j5l4060594; Tue, 8 Feb 2005 00:45:05 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j180j5qP060590; Tue, 8 Feb 2005 00:45:05 GMT (envelope-from kris) Date: Tue, 8 Feb 2005 00:45:05 GMT From: Kris Kennaway Message-Id: <200502080045.j180j5qP060590@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/76019: security patch -- use binaries from rtr instead of microsoft X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 00:45:05 -0000 Synopsis: security patch -- use binaries from rtr instead of microsoft Responsible-Changed-From-To: freebsd-i386->freebsd-ports-bugs Responsible-Changed-By: kris Responsible-Changed-When: Tue Feb 8 00:44:55 GMT 2005 Responsible-Changed-Why: Correct category and mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=76019 From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 00:21:13 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3891B16A4CE; Wed, 9 Feb 2005 00:21:13 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A194743D1D; Wed, 9 Feb 2005 00:21:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j190LCqn076288; Tue, 8 Feb 2005 19:21:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j190LTQ2053695; Tue, 8 Feb 2005 19:21:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0280E7306E; Tue, 8 Feb 2005 19:21:11 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050209002111.0280E7306E@freebsd-current.sentex.ca> Date: Tue, 8 Feb 2005 19:21:11 -0500 (EST) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 00:21:13 -0000 TB --- 2005-02-08 23:00:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-08 23:00:56 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-02-08 23:00:56 - checking out the source tree TB --- 2005-02-08 23:00:56 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-02-08 23:00:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-08 23:06:37 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-08 23:06:37 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-02-08 23:06:37 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-09 00:13:54 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-09 00:13:54 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-02-09 00:13:54 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Feb 9 00:13:54 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/netinet/udp_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/netinet6/dest6.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/netinet6/frag6.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/i386/src/sys/netinet6/icmp6.c /tinderbox/CURRENT/i386/i386/src/sys/netinet6/icmp6.c: In function `icmp6_rip6_input': /tinderbox/CURRENT/i386/i386/src/sys/netinet6/icmp6.c:1901: error: `ripcbinfo' undeclared (first use in this function) /tinderbox/CURRENT/i386/i386/src/sys/netinet6/icmp6.c:1901: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/i386/src/sys/netinet6/icmp6.c:1901: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-02-09 00:21:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-09 00:21:11 - ERROR: failed to build generic kernel TB --- 2005-02-09 00:21:11 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 01:39:15 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0661716A4CF; Wed, 9 Feb 2005 01:39:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B06143D1D; Wed, 9 Feb 2005 01:39:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j191dD97079073; Tue, 8 Feb 2005 20:39:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j191dWrF085913; Tue, 8 Feb 2005 20:39:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A81107306E; Tue, 8 Feb 2005 20:39:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050209013913.A81107306E@freebsd-current.sentex.ca> Date: Tue, 8 Feb 2005 20:39:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 01:39:15 -0000 TB --- 2005-02-09 00:21:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-09 00:21:12 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-02-09 00:21:12 - checking out the source tree TB --- 2005-02-09 00:21:12 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-02-09 00:21:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-09 00:26:54 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-09 00:26:54 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-09 00:26:54 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-09 01:33:53 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-09 01:33:53 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-09 01:33:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Feb 9 01:33:53 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/pc98/src/sys/netinet/udp_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/dest6.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/frag6.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/icmp6.c /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/icmp6.c: In function `icmp6_rip6_input': /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/icmp6.c:1901: error: `ripcbinfo' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/icmp6.c:1901: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/netinet6/icmp6.c:1901: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-02-09 01:39:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-09 01:39:13 - ERROR: failed to build generic kernel TB --- 2005-02-09 01:39:13 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 05:14:21 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4850D16A4CE; Wed, 9 Feb 2005 05:14:21 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 813F143D2F; Wed, 9 Feb 2005 05:14:20 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j195EAIr019058; Wed, 9 Feb 2005 00:14:10 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j195E1ar019057; Wed, 9 Feb 2005 00:14:01 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 9 Feb 2005 00:14:01 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050209051401.GA18775@VARK.MIT.EDU> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050205181808.J10966@delplex.bde.org> cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-i386@FreeBSD.ORG cc: bde@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 05:14:21 -0000 I ran some careful performance comparisons between the version of i387 tan() I posted earlier and the fdlibm tan(). Executive summary: the fdlibm tan() is faster for virtually all inputs on a Pentium 4. Pentium 3s seem to have lower-latency FPUs, but fdlibm still beats the fptan instruction for the important cases where fptan actually gets the right answer. I used the following sets of inputs: tbl1: small numbers -7.910377e-286 -5.142120e-78 -8.305257e-262 -2.089491e-228 9.625342e-237 -5.867161e-64 9.000611e-34 5.192603e-280 -1.255581e-153 1.275985e-153 tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 -2.410568e-05 -6.482504e-01 -1.971384e-03 -1.686721e-04 -3.629842e-04 1.036818e-03 2.987541e-04 6.186103e+00 2.165271e-02 1.032138e-04 tbl3: large numbers 2.379610e+172 3.238483e+204 -4.680033e+194 -1.442727e+225 3.090948e+48 1.778800e+185 5.177174e+295 -1.237869e+204 -4.577895e+223 -6.735385e+171 tbl4: special cases nan inf -inf -0.0 +0.0 The results below are divided into four columns. The first is the average number of clock cycles taken by the fdlibm tan() for the corresponding table input above on a Pentium 4, the second is the clock cycles for the assembly tan(), the third is the difference, and the fourth is the percentage difference relative to column 1. das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1259.000000 1697.000000 438.000000 +35% 1162.000000 1488.000000 326.000000 +28% 1060.000000 1445.000000 385.000000 +36% 1059.000000 1453.000000 394.000000 +37% 1065.000000 1459.000000 394.000000 +37% 1059.000000 1458.000000 399.000000 +38% 1031.000000 1461.000000 430.000000 +42% 1054.000000 1436.000000 382.000000 +36% 1056.000000 1455.000000 399.000000 +38% 1073.000000 1459.000000 386.000000 +36% das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 2018.000000 1985.000000 -33.000000 -2% 1713.000000 1821.000000 108.000000 +6% 1694.000000 1730.000000 36.000000 +2% 1708.000000 1737.000000 29.000000 +2% 1703.000000 1745.000000 42.000000 +2% 1696.000000 1762.000000 66.000000 +4% 1718.000000 1774.000000 56.000000 +3% 1890.000000 2108.000000 218.000000 +12% 1693.000000 1744.000000 51.000000 +3% 1702.000000 1714.000000 12.000000 +1% das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5737.000000 6078.000000 341.000000 +6% 5110.000000 5200.000000 90.000000 +2% 6726.000000 7030.000000 304.000000 +5% 5370.000000 5403.000000 33.000000 +1% 5032.000000 5206.000000 174.000000 +3% 5229.000000 5199.000000 -30.000000 -1% 6313.000000 6523.000000 210.000000 +3% 5201.000000 5583.000000 382.000000 +7% 6443.000000 6560.000000 117.000000 +2% 5172.000000 5356.000000 184.000000 +4% das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 4726.000000 3234.000000 -1492.000000 -32% 3181.000000 2850.000000 -331.000000 -10% 3149.000000 2842.000000 -307.000000 -10% 1045.000000 1091.000000 46.000000 +4% 1076.000000 1114.000000 38.000000 +4% (P.S.: Oops, forgot to compile s_sin.c with -O.) I also ran the first three tests on freefall (Pentium III, using the old reduction code), and got results that aren't as favorable for the fdlibm version: das@freefall:~> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1384.000000 442.000000 -942.000000 -68% 584.000000 440.000000 -144.000000 -25% 589.000000 441.000000 -148.000000 -25% 584.000000 441.000000 -143.000000 -24% 585.000000 441.000000 -144.000000 -25% 585.000000 440.000000 -145.000000 -25% 585.000000 441.000000 -144.000000 -25% 584.000000 440.000000 -144.000000 -25% 584.000000 441.000000 -143.000000 -24% 584.000000 441.000000 -143.000000 -24% das@freefall:~> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 639.000000 656.000000 17.000000 +3% 820.000000 648.000000 -172.000000 -21% 640.000000 654.000000 14.000000 +2% 639.000000 702.000000 63.000000 +10% 638.000000 654.000000 16.000000 +3% 639.000000 658.000000 19.000000 +3% 638.000000 655.000000 17.000000 +3% 1789.000000 654.000000 -1135.000000 -63% 639.000000 654.000000 15.000000 +2% 638.000000 656.000000 18.000000 +3% das@freefall:~> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5751.000000 1918.000000 -3833.000000 -67% 4383.000000 2351.000000 -2032.000000 -46% 6241.000000 2150.000000 -4091.000000 -66% 4401.000000 2483.000000 -1918.000000 -44% 4387.000000 1182.000000 -3205.000000 -73% 4276.000000 2004.000000 -2272.000000 -53% 5814.000000 2735.000000 -3079.000000 -53% 4389.000000 2180.000000 -2209.000000 -50% 5779.000000 2270.000000 -3509.000000 -61% 4379.000000 2020.000000 -2359.000000 -54% Here, fdlibm usually wins for tbl2, which is the most important class of inputs. It is slower for the two inputs in tbl2 that are close to multiples of 2pi and for large inputs, but in all fairness, the i387 gets the wrong answer in those cases---hence, this PR. The i387 legitimately beats fdlibm for the small inputs, for which tan(x) == x, so a special case for those earlier in fdlibm would probably be beneficial. Conclusion: We should toss out the assembly versions of tan() and tanf(), and possibly special-case small inputs in fdlibm tan(). I found similar results for sin(), so we should probably do the same for that, too. Again, this is on my Pentium 4; YMMV. das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1254.000000 1981.000000 727.000000 +58% 1109.000000 1603.000000 494.000000 +45% 1056.000000 1579.000000 523.000000 +50% 1051.000000 1565.000000 514.000000 +49% 1043.000000 1569.000000 526.000000 +50% 1077.000000 1572.000000 495.000000 +46% 1050.000000 1570.000000 520.000000 +50% 1051.000000 1566.000000 515.000000 +49% 1042.000000 1569.000000 527.000000 +51% 1048.000000 1568.000000 520.000000 +50% das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1404.000000 1656.000000 252.000000 +18% 1222.000000 1563.000000 341.000000 +28% 1205.000000 1614.000000 409.000000 +34% 1210.000000 1603.000000 393.000000 +32% 1206.000000 1616.000000 410.000000 +34% 1218.000000 1636.000000 418.000000 +34% 1207.000000 1645.000000 438.000000 +36% 1772.000000 1610.000000 -162.000000 -9% 1213.000000 1615.000000 402.000000 +33% 1208.000000 1617.000000 409.000000 +34% das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5057.000000 5260.000000 203.000000 +4% 5076.000000 6708.000000 1632.000000 +32% 6528.000000 5978.000000 -550.000000 -8% 5074.000000 6922.000000 1848.000000 +36% 5116.000000 2889.000000 -2227.000000 -44% 4702.000000 5190.000000 488.000000 +10% 5884.000000 7223.000000 1339.000000 +23% 5138.000000 5927.000000 789.000000 +15% 5834.000000 5923.000000 89.000000 +2% 5051.000000 5618.000000 567.000000 +11% das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 3536.000000 3576.000000 40.000000 +1% 3190.000000 2705.000000 -485.000000 -15% 3189.000000 2698.000000 -491.000000 -15% 1053.000000 1171.000000 118.000000 +11% 1059.000000 1174.000000 115.000000 +11% The above data was generated using the program below, executed as follows: ./a.out < tblN | grep avg | awk '{print $2}' > perfN When compiling the program, it is necessary to add -Dfunc=tan or -Dfunc=itan. #include #include #include #include #include #define ITER 10000 #define rdtsc(rv) __asm __volatile("xor %%ax,%%ax\n\tcpuid\n\trdtsc" \ : "=A" (*(rv)) : : "ebx", "ecx") double itan(double); static void runtest(double d) { volatile double result; double avg, sd; uint64_t start, end; int64_t total; int t[ITER]; int i, n; int tmax, tmin; printf("%a\n", d); total = 0; for (i = 0; i < ITER; i++) { rdtsc(&start); result = func(d); rdtsc(&end); t[i] = end - start; total += t[i]; } /* compute initial avg and sd */ avg = (double)total / ITER; sd = 0; for (i = 0; i < ITER; i++) sd += (avg - t[i]) * (avg - t[i]); sd = sqrt(sd / ITER); /* recompute avg and sd with outliers removed, find max and min */ n = 0; tmax = 0; tmin = INT_MAX; for (i = 0; i < ITER; i++) { if (fabs(avg - t[i]) <= sd * 2) { total += t[i]; n++; if (t[i] > tmax) tmax = t[i]; if (t[i] < tmin) tmin = t[i]; } else { t[i] = -1; } } avg = (double)total / n; sd = 0; for (i = 0; i < ITER; i++) { if (t[i] >= 0) sd += (avg - t[i]) * (avg - t[i]); } sd = sqrt(sd / n); printf("avg:\t%.0f\nsd:\t%.0f\nmin:\t%d\nmax:\t%d\nout:\t%.02f%%\n\n", avg, sd, tmin, tmax, (double)(ITER - n) * 100 / ITER); } int main(int argc, char *argv[]) { double d; while (scanf("%lf", &d) > 0) runtest(d); return (0); } From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 05:20:06 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15F6B16A4CE for ; Wed, 9 Feb 2005 05:20:06 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 732E443D41 for ; Wed, 9 Feb 2005 05:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j195K5iF097912 for ; Wed, 9 Feb 2005 05:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j195K5sR097911; Wed, 9 Feb 2005 05:20:05 GMT (envelope-from gnats) Date: Wed, 9 Feb 2005 05:20:05 GMT Message-Id: <200502090520.j195K5sR097911@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: David Schultz Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 05:20:06 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Wed, 9 Feb 2005 00:14:01 -0500 I ran some careful performance comparisons between the version of i387 tan() I posted earlier and the fdlibm tan(). Executive summary: the fdlibm tan() is faster for virtually all inputs on a Pentium 4. Pentium 3s seem to have lower-latency FPUs, but fdlibm still beats the fptan instruction for the important cases where fptan actually gets the right answer. I used the following sets of inputs: tbl1: small numbers -7.910377e-286 -5.142120e-78 -8.305257e-262 -2.089491e-228 9.625342e-237 -5.867161e-64 9.000611e-34 5.192603e-280 -1.255581e-153 1.275985e-153 tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 -2.410568e-05 -6.482504e-01 -1.971384e-03 -1.686721e-04 -3.629842e-04 1.036818e-03 2.987541e-04 6.186103e+00 2.165271e-02 1.032138e-04 tbl3: large numbers 2.379610e+172 3.238483e+204 -4.680033e+194 -1.442727e+225 3.090948e+48 1.778800e+185 5.177174e+295 -1.237869e+204 -4.577895e+223 -6.735385e+171 tbl4: special cases nan inf -inf -0.0 +0.0 The results below are divided into four columns. The first is the average number of clock cycles taken by the fdlibm tan() for the corresponding table input above on a Pentium 4, the second is the clock cycles for the assembly tan(), the third is the difference, and the fourth is the percentage difference relative to column 1. das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1259.000000 1697.000000 438.000000 +35% 1162.000000 1488.000000 326.000000 +28% 1060.000000 1445.000000 385.000000 +36% 1059.000000 1453.000000 394.000000 +37% 1065.000000 1459.000000 394.000000 +37% 1059.000000 1458.000000 399.000000 +38% 1031.000000 1461.000000 430.000000 +42% 1054.000000 1436.000000 382.000000 +36% 1056.000000 1455.000000 399.000000 +38% 1073.000000 1459.000000 386.000000 +36% das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 2018.000000 1985.000000 -33.000000 -2% 1713.000000 1821.000000 108.000000 +6% 1694.000000 1730.000000 36.000000 +2% 1708.000000 1737.000000 29.000000 +2% 1703.000000 1745.000000 42.000000 +2% 1696.000000 1762.000000 66.000000 +4% 1718.000000 1774.000000 56.000000 +3% 1890.000000 2108.000000 218.000000 +12% 1693.000000 1744.000000 51.000000 +3% 1702.000000 1714.000000 12.000000 +1% das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5737.000000 6078.000000 341.000000 +6% 5110.000000 5200.000000 90.000000 +2% 6726.000000 7030.000000 304.000000 +5% 5370.000000 5403.000000 33.000000 +1% 5032.000000 5206.000000 174.000000 +3% 5229.000000 5199.000000 -30.000000 -1% 6313.000000 6523.000000 210.000000 +3% 5201.000000 5583.000000 382.000000 +7% 6443.000000 6560.000000 117.000000 +2% 5172.000000 5356.000000 184.000000 +4% das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 4726.000000 3234.000000 -1492.000000 -32% 3181.000000 2850.000000 -331.000000 -10% 3149.000000 2842.000000 -307.000000 -10% 1045.000000 1091.000000 46.000000 +4% 1076.000000 1114.000000 38.000000 +4% (P.S.: Oops, forgot to compile s_sin.c with -O.) I also ran the first three tests on freefall (Pentium III, using the old reduction code), and got results that aren't as favorable for the fdlibm version: das@freefall:~> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1384.000000 442.000000 -942.000000 -68% 584.000000 440.000000 -144.000000 -25% 589.000000 441.000000 -148.000000 -25% 584.000000 441.000000 -143.000000 -24% 585.000000 441.000000 -144.000000 -25% 585.000000 440.000000 -145.000000 -25% 585.000000 441.000000 -144.000000 -25% 584.000000 440.000000 -144.000000 -25% 584.000000 441.000000 -143.000000 -24% 584.000000 441.000000 -143.000000 -24% das@freefall:~> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 639.000000 656.000000 17.000000 +3% 820.000000 648.000000 -172.000000 -21% 640.000000 654.000000 14.000000 +2% 639.000000 702.000000 63.000000 +10% 638.000000 654.000000 16.000000 +3% 639.000000 658.000000 19.000000 +3% 638.000000 655.000000 17.000000 +3% 1789.000000 654.000000 -1135.000000 -63% 639.000000 654.000000 15.000000 +2% 638.000000 656.000000 18.000000 +3% das@freefall:~> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5751.000000 1918.000000 -3833.000000 -67% 4383.000000 2351.000000 -2032.000000 -46% 6241.000000 2150.000000 -4091.000000 -66% 4401.000000 2483.000000 -1918.000000 -44% 4387.000000 1182.000000 -3205.000000 -73% 4276.000000 2004.000000 -2272.000000 -53% 5814.000000 2735.000000 -3079.000000 -53% 4389.000000 2180.000000 -2209.000000 -50% 5779.000000 2270.000000 -3509.000000 -61% 4379.000000 2020.000000 -2359.000000 -54% Here, fdlibm usually wins for tbl2, which is the most important class of inputs. It is slower for the two inputs in tbl2 that are close to multiples of 2pi and for large inputs, but in all fairness, the i387 gets the wrong answer in those cases---hence, this PR. The i387 legitimately beats fdlibm for the small inputs, for which tan(x) == x, so a special case for those earlier in fdlibm would probably be beneficial. Conclusion: We should toss out the assembly versions of tan() and tanf(), and possibly special-case small inputs in fdlibm tan(). I found similar results for sin(), so we should probably do the same for that, too. Again, this is on my Pentium 4; YMMV. das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1254.000000 1981.000000 727.000000 +58% 1109.000000 1603.000000 494.000000 +45% 1056.000000 1579.000000 523.000000 +50% 1051.000000 1565.000000 514.000000 +49% 1043.000000 1569.000000 526.000000 +50% 1077.000000 1572.000000 495.000000 +46% 1050.000000 1570.000000 520.000000 +50% 1051.000000 1566.000000 515.000000 +49% 1042.000000 1569.000000 527.000000 +51% 1048.000000 1568.000000 520.000000 +50% das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 1404.000000 1656.000000 252.000000 +18% 1222.000000 1563.000000 341.000000 +28% 1205.000000 1614.000000 409.000000 +34% 1210.000000 1603.000000 393.000000 +32% 1206.000000 1616.000000 410.000000 +34% 1218.000000 1636.000000 418.000000 +34% 1207.000000 1645.000000 438.000000 +36% 1772.000000 1610.000000 -162.000000 -9% 1213.000000 1615.000000 402.000000 +33% 1208.000000 1617.000000 409.000000 +34% das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 5057.000000 5260.000000 203.000000 +4% 5076.000000 6708.000000 1632.000000 +32% 6528.000000 5978.000000 -550.000000 -8% 5074.000000 6922.000000 1848.000000 +36% 5116.000000 2889.000000 -2227.000000 -44% 4702.000000 5190.000000 488.000000 +10% 5884.000000 7223.000000 1339.000000 +23% 5138.000000 5927.000000 789.000000 +15% 5834.000000 5923.000000 89.000000 +2% 5051.000000 5618.000000 567.000000 +11% das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' 3536.000000 3576.000000 40.000000 +1% 3190.000000 2705.000000 -485.000000 -15% 3189.000000 2698.000000 -491.000000 -15% 1053.000000 1171.000000 118.000000 +11% 1059.000000 1174.000000 115.000000 +11% The above data was generated using the program below, executed as follows: ./a.out < tblN | grep avg | awk '{print $2}' > perfN When compiling the program, it is necessary to add -Dfunc=tan or -Dfunc=itan. #include #include #include #include #include #define ITER 10000 #define rdtsc(rv) __asm __volatile("xor %%ax,%%ax\n\tcpuid\n\trdtsc" \ : "=A" (*(rv)) : : "ebx", "ecx") double itan(double); static void runtest(double d) { volatile double result; double avg, sd; uint64_t start, end; int64_t total; int t[ITER]; int i, n; int tmax, tmin; printf("%a\n", d); total = 0; for (i = 0; i < ITER; i++) { rdtsc(&start); result = func(d); rdtsc(&end); t[i] = end - start; total += t[i]; } /* compute initial avg and sd */ avg = (double)total / ITER; sd = 0; for (i = 0; i < ITER; i++) sd += (avg - t[i]) * (avg - t[i]); sd = sqrt(sd / ITER); /* recompute avg and sd with outliers removed, find max and min */ n = 0; tmax = 0; tmin = INT_MAX; for (i = 0; i < ITER; i++) { if (fabs(avg - t[i]) <= sd * 2) { total += t[i]; n++; if (t[i] > tmax) tmax = t[i]; if (t[i] < tmin) tmin = t[i]; } else { t[i] = -1; } } avg = (double)total / n; sd = 0; for (i = 0; i < ITER; i++) { if (t[i] >= 0) sd += (avg - t[i]) * (avg - t[i]); } sd = sqrt(sd / n); printf("avg:\t%.0f\nsd:\t%.0f\nmin:\t%d\nmax:\t%d\nout:\t%.02f%%\n\n", avg, sd, tmin, tmax, (double)(ITER - n) * 100 / ITER); } int main(int argc, char *argv[]) { double d; while (scanf("%lf", &d) > 0) runtest(d); return (0); } From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 15:17:51 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AE4016A4CE; Wed, 9 Feb 2005 15:17:51 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1FFC43D1D; Wed, 9 Feb 2005 15:17:50 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j19FHnHn015747; Thu, 10 Feb 2005 02:17:49 +1100 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j19FHkTv027614; Thu, 10 Feb 2005 02:17:47 +1100 Date: Thu, 10 Feb 2005 02:17:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Schultz In-Reply-To: <20050209051401.GA18775@VARK.MIT.EDU> Message-ID: <20050209232758.F3249@epsplex.bde.org> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050209051401.GA18775@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-gnats-submit@freebsd.org cc: freebsd-i386@freebsd.org cc: bde@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:17:51 -0000 On Wed, 9 Feb 2005, David Schultz wrote: > I ran some careful performance comparisons between the version of > i387 tan() I posted earlier and the fdlibm tan(). Executive > summary: the fdlibm tan() is faster for virtually all inputs on a > Pentium 4. Pentium 3s seem to have lower-latency FPUs, but fdlibm > still beats the fptan instruction for the important cases where > fptan actually gets the right answer. I did some not so careful comparisions and found: - hardware sin is about twice as fast as fdlibm sin on athlonxp - hardware sin is about the same speed as fdlibm sin on athlon64. The absolute speed is about the same as on athlonxp with a similar CPU clock (athlon64 apparently speeds up fdlibm but not hardware sin) - using float precision didn't make much difference (it was slightly slower IIRC). I used a uniform distribution with ranges [0..10] and [0..1000], and e_rem_pio2f.c was fixed to use the double version on athlonxp but not on athlon64. I think newer CPUs are more likely to optimize simple instructions better relative to transcendentatal functions. SSE2 doesn't help for fsin, and using fsin on athlonxp is slower than ever because the registers have to be moved from xmm to i387 via memory. But perhaps there are separate ALUs that help more in real applications. fdlibm probably works better in benchmarks than in real applications because its code and tables stay cached. > I used the following sets > of inputs: > > tbl1: small numbers > ... > tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 > ... > tbl3: large numbers > ... > tbl4: special cases This data may be too unusual. Maybe the NaNs are slower. Denormals would probably be slower. > The results below are divided into four columns. The first is the > average number of clock cycles taken by the fdlibm tan() for the > corresponding table input above on a Pentium 4, the second is the > clock cycles for the assembly tan(), the third is the difference, > and the fourth is the percentage difference relative to column 1. > > das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 1259.000000 1697.000000 438.000000 +35% > ... > das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 2018.000000 1985.000000 -33.000000 -2% > ... > das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 5737.000000 6078.000000 341.000000 +6% > ... > das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 4726.000000 3234.000000 -1492.000000 -32% > ... > > (P.S.: Oops, forgot to compile s_sin.c with -O.) I get the following for the range [0..10] step 0.0000001 on athlonxp: 257 fdlibm sin(double) (msun src) 128 fsin(double) (libc obj) 107 sinf(double) (inline asm src) 151 ftan(double) (libc obj) In case I messed up the scaling, this translates to 50-120 nsec/call (TSC freq 2223MHz). The execuion latency for fsin is 96-192 cycles according to the athlon32 optimization manual, so 107-128 seems about right. > I also ran the first three tests on freefall (Pentium III, using > the old reduction code), and got results that aren't as favorable > for the fdlibm version: > > das@freefall:~> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 1384.000000 442.000000 -942.000000 -68% > 584.000000 440.000000 -144.000000 -25% > ... > das@freefall:~> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 639.000000 656.000000 17.000000 +3% > ... > das@freefall:~> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 5751.000000 1918.000000 -3833.000000 -67% > ... Freefall is surprisingly underpowered :-). I get similar cycle counts on it: 232 fdlibm sin(double) (msun src) 121 fsin(double) (libc obj) 112 sinf(double) (inline asm src) 178 tan(double) (libc obj (fdlibm)) My test loop (1/10 as long as this for freefall): %%% double d; ... x = rdtsc(); for (d = 0; d < 10.0; d += 0.0000001) tan(d); y = rdtsc(); %%% > Here, fdlibm usually wins for tbl2, which is the most important > class of inputs. It is slower for the two inputs in tbl2 that are > close to multiples of 2pi and for large inputs, but in all > fairness, the i387 gets the wrong answer in those cases---hence, > this PR. The i387 legitimately beats fdlibm for the small inputs, > for which tan(x) == x, so a special case for those earlier in > fdlibm would probably be beneficial. Special inputs take much longer according to your tests, but I hope thousands of cycles is not the usual case. > Conclusion: We should toss out the assembly versions of tan() and > tanf(), and possibly special-case small inputs in fdlibm tan(). > The above data was generated using the program below, executed as > follows: > ./a.out < tblN | grep avg | awk '{print $2}' > perfN > When compiling the program, it is necessary to add > -Dfunc=tan or -Dfunc=itan. For me, this gives numbers in between yours and mine. I only tried hardware tan on athlonxp, and the numbers were about 2000 for most of tbl3, one 1000 in the middle of tbl3, and 400 for everything else. > #define rdtsc(rv) __asm __volatile("xor %%ax,%%ax\n\tcpuid\n\trdtsc" \ > : "=A" (*(rv)) : : "ebx", "ecx") The synchronising cpuid here is responsible for a factor of 3 difference for me. Moving the rdtsc out of the loop gives the following changes in cycle counts: 2000 -> [944..1420] 1000 -> 431 400 -> 132 Each rdtsc() in the loop costs 75 cycles for tbl1, and actually using the results costs another 120 cycles. I think the cpuid is disturbing the timings too much. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 15:20:27 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5232616A5A4 for ; Wed, 9 Feb 2005 15:20:27 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D46143D45 for ; Wed, 9 Feb 2005 15:20:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j19FKQxE099759 for ; Wed, 9 Feb 2005 15:20:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j19FKQsr099758; Wed, 9 Feb 2005 15:20:26 GMT (envelope-from gnats) Date: Wed, 9 Feb 2005 15:20:26 GMT Message-Id: <200502091520.j19FKQsr099758@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:20:27 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, bde@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Thu, 10 Feb 2005 02:17:45 +1100 (EST) On Wed, 9 Feb 2005, David Schultz wrote: > I ran some careful performance comparisons between the version of > i387 tan() I posted earlier and the fdlibm tan(). Executive > summary: the fdlibm tan() is faster for virtually all inputs on a > Pentium 4. Pentium 3s seem to have lower-latency FPUs, but fdlibm > still beats the fptan instruction for the important cases where > fptan actually gets the right answer. I did some not so careful comparisions and found: - hardware sin is about twice as fast as fdlibm sin on athlonxp - hardware sin is about the same speed as fdlibm sin on athlon64. The absolute speed is about the same as on athlonxp with a similar CPU clock (athlon64 apparently speeds up fdlibm but not hardware sin) - using float precision didn't make much difference (it was slightly slower IIRC). I used a uniform distribution with ranges [0..10] and [0..1000], and e_rem_pio2f.c was fixed to use the double version on athlonxp but not on athlon64. I think newer CPUs are more likely to optimize simple instructions better relative to transcendentatal functions. SSE2 doesn't help for fsin, and using fsin on athlonxp is slower than ever because the registers have to be moved from xmm to i387 via memory. But perhaps there are separate ALUs that help more in real applications. fdlibm probably works better in benchmarks than in real applications because its code and tables stay cached. > I used the following sets > of inputs: > > tbl1: small numbers > ... > tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 > ... > tbl3: large numbers > ... > tbl4: special cases This data may be too unusual. Maybe the NaNs are slower. Denormals would probably be slower. > The results below are divided into four columns. The first is the > average number of clock cycles taken by the fdlibm tan() for the > corresponding table input above on a Pentium 4, the second is the > clock cycles for the assembly tan(), the third is the difference, > and the fourth is the percentage difference relative to column 1. > > das@VARK:/home/t/freebsd> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 1259.000000 1697.000000 438.000000 +35% > ... > das@VARK:/home/t/freebsd> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 2018.000000 1985.000000 -33.000000 -2% > ... > das@VARK:/home/t/freebsd> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 5737.000000 6078.000000 341.000000 +6% > ... > das@VARK:/home/t/freebsd> paste perf4 perf4md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 4726.000000 3234.000000 -1492.000000 -32% > ... > > (P.S.: Oops, forgot to compile s_sin.c with -O.) I get the following for the range [0..10] step 0.0000001 on athlonxp: 257 fdlibm sin(double) (msun src) 128 fsin(double) (libc obj) 107 sinf(double) (inline asm src) 151 ftan(double) (libc obj) In case I messed up the scaling, this translates to 50-120 nsec/call (TSC freq 2223MHz). The execuion latency for fsin is 96-192 cycles according to the athlon32 optimization manual, so 107-128 seems about right. > I also ran the first three tests on freefall (Pentium III, using > the old reduction code), and got results that aren't as favorable > for the fdlibm version: > > das@freefall:~> paste perf1 perf1md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 1384.000000 442.000000 -942.000000 -68% > 584.000000 440.000000 -144.000000 -25% > ... > das@freefall:~> paste perf2 perf2md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 639.000000 656.000000 17.000000 +3% > ... > das@freefall:~> paste perf3 perf3md | awk '{printf("%f\t%f\t%f\t%+.0f%%\n", $1, $2, $2-$1, ($2-$1)*100/$1);}' > 5751.000000 1918.000000 -3833.000000 -67% > ... Freefall is surprisingly underpowered :-). I get similar cycle counts on it: 232 fdlibm sin(double) (msun src) 121 fsin(double) (libc obj) 112 sinf(double) (inline asm src) 178 tan(double) (libc obj (fdlibm)) My test loop (1/10 as long as this for freefall): %%% double d; ... x = rdtsc(); for (d = 0; d < 10.0; d += 0.0000001) tan(d); y = rdtsc(); %%% > Here, fdlibm usually wins for tbl2, which is the most important > class of inputs. It is slower for the two inputs in tbl2 that are > close to multiples of 2pi and for large inputs, but in all > fairness, the i387 gets the wrong answer in those cases---hence, > this PR. The i387 legitimately beats fdlibm for the small inputs, > for which tan(x) == x, so a special case for those earlier in > fdlibm would probably be beneficial. Special inputs take much longer according to your tests, but I hope thousands of cycles is not the usual case. > Conclusion: We should toss out the assembly versions of tan() and > tanf(), and possibly special-case small inputs in fdlibm tan(). > The above data was generated using the program below, executed as > follows: > ./a.out < tblN | grep avg | awk '{print $2}' > perfN > When compiling the program, it is necessary to add > -Dfunc=tan or -Dfunc=itan. For me, this gives numbers in between yours and mine. I only tried hardware tan on athlonxp, and the numbers were about 2000 for most of tbl3, one 1000 in the middle of tbl3, and 400 for everything else. > #define rdtsc(rv) __asm __volatile("xor %%ax,%%ax\n\tcpuid\n\trdtsc" \ > : "=A" (*(rv)) : : "ebx", "ecx") The synchronising cpuid here is responsible for a factor of 3 difference for me. Moving the rdtsc out of the loop gives the following changes in cycle counts: 2000 -> [944..1420] 1000 -> 431 400 -> 132 Each rdtsc() in the loop costs 75 cycles for tbl1, and actually using the results costs another 120 cycles. I think the cpuid is disturbing the timings too much. Bruce From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 20:00:42 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D5F16A576 for ; Wed, 9 Feb 2005 20:00:41 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99CD143D48 for ; Wed, 9 Feb 2005 20:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j19K0fLT030345 for ; Wed, 9 Feb 2005 20:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j19K0fB0030332; Wed, 9 Feb 2005 20:00:41 GMT (envelope-from gnats) Resent-Date: Wed, 9 Feb 2005 20:00:41 GMT Resent-Message-Id: <200502092000.j19K0fB0030332@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Kirkwood Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3942816A4DF for ; Wed, 9 Feb 2005 19:53:27 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2161C43D48 for ; Wed, 9 Feb 2005 19:53:27 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j19JrQCw070875 for ; Wed, 9 Feb 2005 19:53:26 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j19JrQJ1070874; Wed, 9 Feb 2005 19:53:26 GMT (envelope-from nobody) Message-Id: <200502091953.j19JrQJ1070874@www.freebsd.org> Date: Wed, 9 Feb 2005 19:53:26 GMT From: Mark Kirkwood To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: i386/77325: valgrind hangs at program completion, see warnings in messages about static ldt allocation X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 20:00:42 -0000 >Number: 77325 >Category: i386 >Synopsis: valgrind hangs at program completion, see warnings in messages about static ldt allocation >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 09 20:00:41 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Mark Kirkwood >Release: 5.3 RELEASE >Organization: N?A >Environment: FreeBSD zmori.markir.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Thu Nov 25 15:48:11 NZDT 2004 markir@zmori.markir.net:/usr/obj/usr/src/sys/STANDARD i386 diff GENERIC STANDARD 22,23c22,23 < cpu I486_CPU < cpu I586_CPU --- > #cpu I486_CPU > #cpu I586_CPU 25c25 < ident GENERIC --- > ident STANDARD 108a109 > device atapicam # CAM Cooked SCSI device 272a274,277 > > # Sound card > device sound # Pnp PCI Sound Cards > device "snd_emu10k1" >Description: valgrind hangs at program completion, and has to be killed with 'kill -9' There are warnings in messages that read: Feb 10 08:37:57 zmori kernel: Warning: pid 14803 used static ldt allocation. Feb 10 08:37:57 zmori kernel: See the i386_set_ldt man page for more info >How-To-Repeat: create trivial c program : int main(int argc, char **argv) { return 0; } compile using gcc 3.4.2 and run using valgrind from ports (not valgrind-snapshot, tho I might see if I can reproduce with that) >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Wed Feb 9 21:48:00 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE1016A4CE; Wed, 9 Feb 2005 21:48:00 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F46443D1D; Wed, 9 Feb 2005 21:48:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j19LoveJ009582; Wed, 9 Feb 2005 16:50:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j19LmICe026729; Wed, 9 Feb 2005 16:48:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 85C4C7306E; Wed, 9 Feb 2005 16:47:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050209214759.85C4C7306E@freebsd-current.sentex.ca> Date: Wed, 9 Feb 2005 16:47:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 21:48:00 -0000 TB --- 2005-02-09 20:09:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-09 20:09:21 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-02-09 20:09:21 - checking out the source tree TB --- 2005-02-09 20:09:21 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-02-09 20:09:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-09 20:15:04 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-09 20:15:04 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-09 20:15:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-09 21:22:36 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-09 21:22:36 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-09 21:22:36 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Feb 9 21:22:36 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Wed Feb 9 21:36:22 UTC 2005 TB --- 2005-02-09 21:36:22 - generating LINT kernel config TB --- 2005-02-09 21:36:22 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2005-02-09 21:36:22 - /usr/bin/make -B LINT TB --- 2005-02-09 21:36:22 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-09 21:36:22 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-09 21:36:22 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 9 21:36:22 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: implicit declaration of function `forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: nested extern declaration of `forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:209: warning: nested extern declaration of `forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: redundant redeclaration of 'forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: previous implicit declaration of 'forward_hardclock' was here /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:244: warning: nested extern declaration of `forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: redundant redeclaration of 'forward_hardclock' /tinderbox/CURRENT/i386/pc98/src/sys/pc98/pc98/clock.c:195: warning: previous implicit declaration of 'forward_hardclock' was here *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-02-09 21:47:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-09 21:47:59 - ERROR: failed to build lint kernel TB --- 2005-02-09 21:47:59 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Thu Feb 10 04:30:26 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD8A116A4CE for ; Thu, 10 Feb 2005 04:30:26 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA01B43D3F for ; Thu, 10 Feb 2005 04:30:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1A4UQlQ014100 for ; Thu, 10 Feb 2005 04:30:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1A4UQHb014069; Thu, 10 Feb 2005 04:30:26 GMT (envelope-from gnats) Resent-Date: Thu, 10 Feb 2005 04:30:26 GMT Resent-Message-Id: <200502100430.j1A4UQHb014069@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, kriengsak Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66D9216A4CE for ; Thu, 10 Feb 2005 04:28:25 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CCA543D31 for ; Thu, 10 Feb 2005 04:28:25 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j1A4SOEn051117 for ; Thu, 10 Feb 2005 04:28:24 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j1A4SOO9051115; Thu, 10 Feb 2005 04:28:24 GMT (envelope-from nobody) Message-Id: <200502100428.j1A4SOO9051115@www.freebsd.org> Date: Thu, 10 Feb 2005 04:28:24 GMT From: kriengsak To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: i386/77335: Can not initial Ethernet Broadcom UDI PXE-2.1 on IBM server (FreeBSD 5.3) X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 04:30:27 -0000 >Number: 77335 >Category: i386 >Synopsis: Can not initial Ethernet Broadcom UDI PXE-2.1 on IBM server (FreeBSD 5.3) >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Feb 10 04:30:25 GMT 2005 >Closed-Date: >Last-Modified: >Originator: kriengsak >Release: 5.3 >Organization: UniNet >Environment: >Description: I haven't driver Ethernet card Broadcom UDI PXE-2.1 on IBM server . >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Thu Feb 10 07:23:34 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 715E716A4CE; Thu, 10 Feb 2005 07:23:34 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C23C543D1F; Thu, 10 Feb 2005 07:23:33 +0000 (GMT) (envelope-from das@freebsd.org) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j1A7NJMa026972; Thu, 10 Feb 2005 02:23:19 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j1A7NETY026967; Thu, 10 Feb 2005 02:23:14 -0500 (EST) (envelope-from das@freebsd.org) Date: Thu, 10 Feb 2005 02:23:14 -0500 From: David Schultz To: Bruce Evans Message-ID: <20050210072314.GA26713@VARK.MIT.EDU> References: <200406012251.i51MpkkU024224@VARK.homeunix.com> <20040602172105.T23521@gamplex.bde.org> <20050204215913.GA44598@VARK.MIT.EDU> <20050205181808.J10966@delplex.bde.org> <20050209051401.GA18775@VARK.MIT.EDU> <20050209232758.F3249@epsplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209232758.F3249@epsplex.bde.org> cc: FreeBSD-gnats-submit@freebsd.org cc: freebsd-i386@freebsd.org cc: bde@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 07:23:34 -0000 On Thu, Feb 10, 2005, Bruce Evans wrote: > > I used the following sets > > of inputs: > > > > tbl1: small numbers > > ... > > tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 > > ... > > tbl3: large numbers > > ... > > tbl4: special cases > > This data may be too unusual. Maybe the NaNs are slower. Denormals > would probably be slower. The data in tbl2 are pretty usual, I think, and I measured all of the data points independently. But yes, NaNs are slower, as the results for tbl4 indicate. Looking back, though, I did notice that very few of my inputs in tbl2 require argument reduction. In your tests on [0..10], on the other hand, 92% of the inputs require argument reduction in fdlibm. It would be interesting to see for which of your tests fdlibm is faster, and for which it is slower. One possibility is that fdlibm is slower most of the time; another is that it is far slower for the close-to-pi/2 cases that the i387 gets wrong, and that messes up the averages. > The synchronising cpuid here is responsible for a factor of 3 difference > for me. Moving the rdtsc out of the loop gives the following changes > in cycle counts: > > 2000 -> [944..1420] > 1000 -> 431 > 400 -> 132 > > Each rdtsc() in the loop costs 75 cycles for tbl1, and actually using > the results costs another 120 cycles. > > I think the cpuid is disturbing the timings too much. I don't care so much about the rdtsc overhead since I'm only measuring relative performance. A null function is measured as taking 388 cycles on my Pentium 4, but some of that is due to gcc getting confused by the volatile variable and generating extra code at -O0. However, it is true that I am basically measuring latency and not throughput. Ordinarily, it is possible to execute FPU and CPU instructions simultaneously, and the FPU may even have more than one FU available for executing fptan. The cpuid instructions clear out the pipeline and destroy any parallelism that might have been possible. Your version does a better job of measuring throughput. You're also right that fdlibm tan() blows out about 512 bytes of instruction cache. Anyway, I unfortunately don't have time for all this. Do you want the assembly versions of these to stay or not? If so, it would be great if you could fix them and make sure that the result isn't obviously slower than fdlibm. If not, I'll be happy to spend two minutes making all those pesky bugs in them go away. ;-) From owner-freebsd-i386@FreeBSD.ORG Thu Feb 10 07:30:18 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D884216A4CF for ; Thu, 10 Feb 2005 07:30:18 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 932B343D60 for ; Thu, 10 Feb 2005 07:30:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1A7UI50063664 for ; Thu, 10 Feb 2005 07:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1A7UI7v063663; Thu, 10 Feb 2005 07:30:18 GMT (envelope-from gnats) Date: Thu, 10 Feb 2005 07:30:18 GMT Message-Id: <200502100730.j1A7UI7v063663@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: David Schultz Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 07:30:19 -0000 The following reply was made to PR i386/67469; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, bde@freebsd.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Date: Thu, 10 Feb 2005 02:23:14 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209232758.F3249@epsplex.bde.org> On Thu, Feb 10, 2005, Bruce Evans wrote: > > I used the following sets > > of inputs: > > > > tbl1: small numbers > > ... > > tbl2: numbers on [-8pi,8pi] greater in magnitude than 2^-18 > > ... > > tbl3: large numbers > > ... > > tbl4: special cases > > This data may be too unusual. Maybe the NaNs are slower. Denormals > would probably be slower. The data in tbl2 are pretty usual, I think, and I measured all of the data points independently. But yes, NaNs are slower, as the results for tbl4 indicate. Looking back, though, I did notice that very few of my inputs in tbl2 require argument reduction. In your tests on [0..10], on the other hand, 92% of the inputs require argument reduction in fdlibm. It would be interesting to see for which of your tests fdlibm is faster, and for which it is slower. One possibility is that fdlibm is slower most of the time; another is that it is far slower for the close-to-pi/2 cases that the i387 gets wrong, and that messes up the averages. > The synchronising cpuid here is responsible for a factor of 3 difference > for me. Moving the rdtsc out of the loop gives the following changes > in cycle counts: > > 2000 -> [944..1420] > 1000 -> 431 > 400 -> 132 > > Each rdtsc() in the loop costs 75 cycles for tbl1, and actually using > the results costs another 120 cycles. > > I think the cpuid is disturbing the timings too much. I don't care so much about the rdtsc overhead since I'm only measuring relative performance. A null function is measured as taking 388 cycles on my Pentium 4, but some of that is due to gcc getting confused by the volatile variable and generating extra code at -O0. However, it is true that I am basically measuring latency and not throughput. Ordinarily, it is possible to execute FPU and CPU instructions simultaneously, and the FPU may even have more than one FU available for executing fptan. The cpuid instructions clear out the pipeline and destroy any parallelism that might have been possible. Your version does a better job of measuring throughput. You're also right that fdlibm tan() blows out about 512 bytes of instruction cache. Anyway, I unfortunately don't have time for all this. Do you want the assembly versions of these to stay or not? If so, it would be great if you could fix them and make sure that the result isn't obviously slower than fdlibm. If not, I'll be happy to spend two minutes making all those pesky bugs in them go away. ;-) From owner-freebsd-i386@FreeBSD.ORG Thu Feb 10 17:13:52 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A195E16A4CE; Thu, 10 Feb 2005 17:13:52 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C68443D41; Thu, 10 Feb 2005 17:13:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j1AHDp2n067370; Thu, 10 Feb 2005 12:13:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j1AHEB32063289; Thu, 10 Feb 2005 12:14:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A35507306E; Thu, 10 Feb 2005 12:13:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050210171351.A35507306E@freebsd-current.sentex.ca> Date: Thu, 10 Feb 2005 12:13:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 17:13:52 -0000 TB --- 2005-02-10 16:00:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-10 16:00:47 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-02-10 16:00:47 - checking out the source tree TB --- 2005-02-10 16:00:47 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-02-10 16:00:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-10 16:06:31 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-10 16:06:31 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-02-10 16:06:31 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-10 17:13:50 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-10 17:13:50 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-02-10 17:13:50 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 10 17:13:51 UTC 2005 >>> stage 1: configuring the kernel [...] with your /usr/src/sys and install a new config binary before trying this again. If running the new config fails check your config file against the GENERIC or LINT config files for changes in config syntax, or option/device naming conventions *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-02-10 17:13:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-10 17:13:51 - ERROR: failed to build generic kernel TB --- 2005-02-10 17:13:51 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Thu Feb 10 18:27:17 2005 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E11516A4CE; Thu, 10 Feb 2005 18:27:17 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E4B843D4C; Thu, 10 Feb 2005 18:27:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1AIRFYe027232; Thu, 10 Feb 2005 13:27:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1AIRqKe054944; Thu, 10 Feb 2005 13:27:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C66607306E; Thu, 10 Feb 2005 13:27:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050210182715.C66607306E@freebsd-current.sentex.ca> Date: Thu, 10 Feb 2005 13:27:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.82/704/Thu Feb 10 06:37:18 2005 on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 18:27:17 -0000 TB --- 2005-02-10 17:13:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-10 17:13:51 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-02-10 17:13:51 - checking out the source tree TB --- 2005-02-10 17:13:51 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-02-10 17:13:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-10 17:19:57 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-10 17:19:57 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-10 17:19:57 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-10 18:27:14 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-10 18:27:14 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-02-10 18:27:14 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 10 18:27:15 UTC 2005 >>> stage 1: configuring the kernel [...] with your /usr/src/sys and install a new config binary before trying this again. If running the new config fails check your config file against the GENERIC or LINT config files for changes in config syntax, or option/device naming conventions *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-02-10 18:27:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-10 18:27:15 - ERROR: failed to build generic kernel TB --- 2005-02-10 18:27:15 - tinderbox aborted From owner-freebsd-i386@FreeBSD.ORG Fri Feb 11 11:00:41 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCD3316A4CE for ; Fri, 11 Feb 2005 11:00:41 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF3043D41 for ; Fri, 11 Feb 2005 11:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1BB0fbJ088787 for ; Fri, 11 Feb 2005 11:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1BB0f7Y088785; Fri, 11 Feb 2005 11:00:41 GMT (envelope-from gnats) Date: Fri, 11 Feb 2005 11:00:41 GMT Message-Id: <200502111100.j1BB0f7Y088785@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Marian Cerny Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marian Cerny List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 11:00:41 -0000 The following reply was made to PR i386/70832; it has been noted by GNATS. From: Marian Cerny To: freebsd-gnats-submit@FreeBSD.org Cc: Russell Jackson , Andrew Belashov , Florian Klemenz , John-Mark Gurney Subject: Re: i386/70832: Serious problems with RealTek NIC using re0 driver on Evo N1015v Date: Fri, 11 Feb 2005 11:52:31 +0100 All of my problems are still actual on FreeBSD 5.3R, too :-(. Kernel panics on 'halt -p' always when network cable is connected. When network cable is plugged out, there is no panic at all and the laptop correctly turns itself off. Today I have discovered (thanks to pav@FreeBSD.org), that setting > ifconfig re0 -txcsum -rxcsum solves most of my problems. cvsup works ok, no kernel panic on 'halt -p' even when the network cable is plugged in. Of course it does not solve "rarely hangs at boot", because the setting is applied after boot. I have not tested the "-txcsum -rxcsum" for long time, just for a few hours. Should I divide this PR (each subproblem into separate PR)? Other similar problems found: o PR kern/76551 - re0: watchdog timeout problem o http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg07324.html - problem with checksum offloading on re o http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg20316.html - re0 device txcsum issue Would be great if this could be fixed before 5.4R. -- Marian Cerny Jabber: jojo@njs.netlab.cz