From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 02:55:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1EF816A403 for ; Sun, 14 Jan 2007 02:55:39 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFD413C441 for ; Sun, 14 Jan 2007 02:55:39 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l0E2tdxW014794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 13 Jan 2007 18:55:39 -0800 X-Auth-Received: from [192.168.0.101] (dsl254-013-145.sea1.dsl.speakeasy.net [216.254.13.145]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l0E2tcL8030469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 13 Jan 2007 18:55:39 -0800 Message-ID: <45A99BA8.6040204@u.washington.edu> Date: Sat, 13 Jan 2007 18:55:36 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070109) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.13.184432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Embarking on upgrade from 6.1-RELEASE to 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 02:55:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Before I do this, I have a few questions; I know that the bulk majority of the documentation for my questions may exist online or in /usr/src/UPDATING, but I was just curious of the major changes that I can expect between 6 and 7: 1. What scheduler is currently the most complete for SMP/multi-core capable processors? 2. Do I need to add some sort of compatibility layer for 6 going to 7 (similar to compat_5)? 3. What are (briefly) some of the major changes for the ABI/API going from 6 to 7? Someone mentioned some changes to the ABI when I emailed the hackers@ list previously, so I was just curious. 4. How is SATA support for SIS motherboards under 7? Decent? 5. Is 7 running gcc-4.x? Thanks! - -Garrett -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqZuoEnKyINQw/HARAoddAKCckCXHkzXJ9ReG4rgECck0wFdlfwCaA24C zChCcF+a8yK3tV4JXxn1UQo= =gMS9 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 04:05:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C0B516A417 for ; Sun, 14 Jan 2007 04:05:57 +0000 (UTC) (envelope-from SRS1=8ff32e4f63c333de12006ae8421fb999ec5733ad=es.net==8ff32e4f63c333de12006ae8421fb999ec5733ad=214=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id E1D3413C48B for ; Sun, 14 Jan 2007 04:05:56 +0000 (UTC) (envelope-from SRS1=8ff32e4f63c333de12006ae8421fb999ec5733ad=es.net==8ff32e4f63c333de12006ae8421fb999ec5733ad=214=es.net=oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id TEP35534 for ; Sat, 13 Jan 2007 19:53:34 -0800 Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id TEP68932 for ; Sat, 13 Jan 2007 19:53:32 -0800 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id TEP58931; Sat, 13 Jan 2007 19:53:31 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 082BB45053; Sat, 13 Jan 2007 19:53:31 -0800 (PST) To: Garrett Cooper In-Reply-To: Your message of "Sat, 13 Jan 2007 18:55:36 PST." <45A99BA8.6040204@u.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1168746811_25232P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 13 Jan 2007 19:53:31 -0800 From: "Kevin Oberman" Message-Id: <20070114035331.082BB45053@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Embarking on upgrade from 6.1-RELEASE to 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 04:05:57 -0000 --==_Exmh_1168746811_25232P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 13 Jan 2007 18:55:36 -0800 > From: Garrett Cooper > Sender: owner-freebsd-current@freebsd.org > > Before I do this, I have a few questions; I know that the bulk > majority of the documentation for my questions may exist online or in > /usr/src/UPDATING, but I was just curious of the major changes that I > can expect between 6 and 7: > > 1. What scheduler is currently the most complete for SMP/multi-core > capable processors? 4BSD is stable and works well. Jeff R just committed a major overhaul of ULE and it MAY now perform a bit better and has been reported to be stable, now. But it is still experimental d a work in p progress. > 2. Do I need to add some sort of compatibility layer for 6 going to 7 > (similar to compat_5)? There is COMPAT_FREEBSD6, but there is no compat_6x port at this time. Due to the instability of ABIs in current, be prepared to do a lot of port building. > 3. What are (briefly) some of the major changes for the ABI/API going > from 6 to 7? Someone mentioned some changes to the ABI when I emailed > the hackers@ list previously, so I was just curious. Lots of ABI changes. Read /usr/src/UPDATING for the details. ABI changes should all be mentioned there. > 4. How is SATA support for SIS motherboards under 7? Decent? No idea. I have neither a SIS mobo or a SATA system. > 5. Is 7 running gcc-4.x? Not yet, but it should be coming fairly soon. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1168746811_25232P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFFqak7kn3rs5h7N1ERApbxAKCwnmuFhKx5bzc5Bwk1KEIi1r9anwCdGcCD fiPGhdGTl6Y8FoznXsrzVGs= =hirn -----END PGP SIGNATURE----- --==_Exmh_1168746811_25232P-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 04:40:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E8D516A412 for ; Sun, 14 Jan 2007 04:40:13 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id DED3D13C48C for ; Sun, 14 Jan 2007 04:40:12 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l0E4eCem032286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 13 Jan 2007 20:40:12 -0800 X-Auth-Received: from [192.168.0.101] (dsl254-013-145.sea1.dsl.speakeasy.net [216.254.13.145]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l0E4eBr3010535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 13 Jan 2007 20:40:12 -0800 Message-ID: <45A9B42A.3010003@u.washington.edu> Date: Sat, 13 Jan 2007 20:40:10 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070109) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070114035331.082BB45053@ptavv.es.net> In-Reply-To: <20070114035331.082BB45053@ptavv.es.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.13.202933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_PHRASE1_B 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Embarking on upgrade from 6.1-RELEASE to 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 04:40:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Oberman wrote: >> Date: Sat, 13 Jan 2007 18:55:36 -0800 >> From: Garrett Cooper >> Sender: owner-freebsd-current@freebsd.org >> >> Before I do this, I have a few questions; I know that the bulk >> majority of the documentation for my questions may exist online or in >> /usr/src/UPDATING, but I was just curious of the major changes that I >> can expect between 6 and 7: >> >> 1. What scheduler is currently the most complete for SMP/multi-core >> capable processors? > > 4BSD is stable and works well. Jeff R just committed a major overhaul > of ULE and it MAY now perform a bit better and has been reported to be > stable, now. But it is still experimental > d a work in p progress. Ok, sounds good. Will build a ULE and 4BSD scheduler enabled kernel, just in case :). >> 2. Do I need to add some sort of compatibility layer for 6 going to 7 >> (similar to compat_5)? > > There is COMPAT_FREEBSD6, but there is no compat_6x port at this > time. Due to the instability of ABIs in current, be prepared to do a > lot of port building. Ok. At least this machine has less than 30 ports (just Samba, vim-lite, etc). >> 3. What are (briefly) some of the major changes for the ABI/API going >> from 6 to 7? Someone mentioned some changes to the ABI when I emailed >> the hackers@ list previously, so I was just curious. > > Lots of ABI changes. Read /usr/src/UPDATING for the details. ABI changes > should all be mentioned there. Excellent. Good to know it's documented there. >> 5. Is 7 running gcc-4.x? > > Not yet, but it should be coming fairly soon. Ok, cool. I noticed that there were a number of performance enhancements and some tuning stuff going from gcc-3.4 to gcc-4.x, so it'll be nice when that time comes around, but unfortunately building things is going to become complicated for maintainers for a while; I know because I was using Gentoo during the 3.4 -> 4.x move. - -Garrett -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqbQpEnKyINQw/HARAvmiAJ0dOHrm8H7i5tAx61WUMT/MQsYy7ACeIH+1 7h5uIZFJIvtdWW5dlKvZZeM= =Abrv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 04:50:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F62616A52D for ; Sun, 14 Jan 2007 04:50:39 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.Buffalo.EDU [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 029A813C4B7 for ; Sun, 14 Jan 2007 04:49:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.100] (ny-lackawna-cad2-grp3d-162.bflony.adelphia.net [67.21.137.162]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.13.7/8.13.7) with ESMTP id l0E4aCmP064624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 13 Jan 2007 23:36:15 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1G1qKZ7sr31AwziX0fsX" Date: Sat, 13 Jan 2007 23:33:50 -0500 Message-Id: <1168749230.3918.1.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 FreeBSD GNOME Team Port X-DCC--Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.3 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on phoebe.cse.buffalo.edu X-Virus-Scanned: ClamAV 0.88.3/2439/Sat Jan 13 15:33:25 2007 on phoebe.cse.buffalo.edu X-Virus-Status: Clean Subject: January 2007 Monthly Snapshots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 04:50:39 -0000 --=-1G1qKZ7sr31AwziX0fsX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a quick note to say the January 2007 Monthly Snapshots are available in the usual place (and have been for about a week, sorry for the late note...). Checksums: MD5 (6.2-STABLE-200701-powerpc-bootonly.iso) =3D ff0635c08c8d0bd02f8235b409= ce6f05 MD5 (6.2-STABLE-200701-powerpc-disc1.iso) =3D aa84293728565aea080ac005d6ab0= 075 MD5 (6.2-STABLE-200701-powerpc-docs.iso) =3D 6049953d7c6e43b9a289950a440dd2= ad MD5 (7.0-CURRENT-200701-amd64-bootonly.iso) =3D cdecac285dfe9d3afeb71bd9de8= 7640c MD5 (7.0-CURRENT-200701-amd64-disc1.iso) =3D fef7a0a22f218879278618cc548f8e= af MD5 (7.0-CURRENT-200701-i386-bootonly.iso) =3D bf6b96fedd5116ce6e449b39e429= d626 MD5 (7.0-CURRENT-200701-i386-disc1.iso) =3D 7dbee71bdae4eb2f2c635ef29fca111= 4 MD5 (7.0-CURRENT-200701-ia64-bootonly.iso) =3D 0cf93836a4fc1a0ade820d759875= bf3f MD5 (7.0-CURRENT-200701-ia64-disc1.iso) =3D dddaca93c91accd38a9dbc8b48967af= 3 MD5 (7.0-CURRENT-200701-ia64-docs.iso) =3D ee7a967b48307cb610e7e66cf70c140c MD5 (7.0-CURRENT-200701-ia64-livefs.iso) =3D 08c4183332d70fe010d1793d93f75b= dd MD5 (7.0-CURRENT-200701-pc98-bootonly.iso) =3D f8b3cf4ff5c63d6b270b8143d6b3= 508c MD5 (7.0-CURRENT-200701-pc98-disc1.iso) =3D b3e7e3939214319fc23a2cf0875ee4a= 9 MD5 (7.0-CURRENT-200701-powerpc-bootonly.iso) =3D fd8112348a67557239ba58406= 91fae2f MD5 (7.0-CURRENT-200701-powerpc-disc1.iso) =3D e28f46a9e5cc85b8d3c140ef160a= cb4c MD5 (7.0-CURRENT-200701-powerpc-docs.iso) =3D 168533b380397ecb63847c85528ac= 9b1 MD5 (7.0-CURRENT-200701-sparc64-bootonly.iso) =3D 80fbc364dcc9c288afa5b0671= 7493553 MD5 (7.0-CURRENT-200701-sparc64-disc1.iso) =3D b9152e5370d026c432c363eea512= ae50 SHA256 (6.2-STABLE-200701-powerpc-bootonly.iso) =3D 93adee28cb51c285dce6b01= 766fccfc05254845af89eb3fed81cec896103e20f SHA256 (6.2-STABLE-200701-powerpc-disc1.iso) =3D 9e7d2ceba93155d6edba3aeb82= fa219e30adbfe63e6a835f4ab8b73f031e005f SHA256 (6.2-STABLE-200701-powerpc-docs.iso) =3D 8982f7baeba8d5a8f4213dd8ead= 0dfae763e9c3a93cbbec10c2884b9bde2c9d9 SHA256 (7.0-CURRENT-200701-amd64-bootonly.iso) =3D 5e7ad6d15031cad8d159aded= 9b22a720f709fd71d122086d5a0ea3ce6a3abaab SHA256 (7.0-CURRENT-200701-amd64-disc1.iso) =3D 191f14c6358877a0a4a5c58a669= 62bf76549da48d0ead7ee4a8b5a63de4b3f0d SHA256 (7.0-CURRENT-200701-i386-bootonly.iso) =3D 243cab38a64cecd5d5f0194a3= 273ec0ced504cf6d9e80c1d28227f1b296a9b0e SHA256 (7.0-CURRENT-200701-i386-disc1.iso) =3D 868eab51cc8c2a0dd339bcae7cf7= a72ad541a73696ee7f99aceeb73fff2d71e4 SHA256 (7.0-CURRENT-200701-ia64-bootonly.iso) =3D 6bc32092ace77a86a23996930= eefd2c7ae85c6504d8c4d56b048c0dfbcea3a67 SHA256 (7.0-CURRENT-200701-ia64-disc1.iso) =3D 1dc65c6c675671ce47032f1e7c98= d20e529091e6282ac2759c7247caf14ba712 SHA256 (7.0-CURRENT-200701-ia64-docs.iso) =3D 0a85f25b3f7fcb9eec9fa659bfcbf= eab04885429714c2670cdf4a448578ae480 SHA256 (7.0-CURRENT-200701-ia64-livefs.iso) =3D 4d803bfa04e828487ac29290b87= bf5103f55bc0d6877cedc0eeebd64a748e131 SHA256 (7.0-CURRENT-200701-pc98-bootonly.iso) =3D f393a668bc61de84f573894dc= d454354d983c276590ece8edef0c351df4b5a7a SHA256 (7.0-CURRENT-200701-pc98-disc1.iso) =3D e5be6edc43f63b4cb46093752b8f= b3ffbdb9c3da9be67db6a4fa063f77f61755 SHA256 (7.0-CURRENT-200701-powerpc-bootonly.iso) =3D 18c060db4f1746a20ff8c1= c93c97459cfe23791e007f104261a02d962d2595e3 SHA256 (7.0-CURRENT-200701-powerpc-disc1.iso) =3D 21f003a4c913efb40136f382e= 597da2fd85f3fcd63501fc6599c5b72b182c688 SHA256 (7.0-CURRENT-200701-powerpc-docs.iso) =3D 7699005cb811275c0dc6193a5d= ae4bbd6a94c1f36b1b72b902e6a6cc2d57fb92 SHA256 (7.0-CURRENT-200701-sparc64-bootonly.iso) =3D 6278412efe5e71e1ef8e43= 2fc2bcfefd9f8f15b75e691f6ac4223a1f91c93fba SHA256 (7.0-CURRENT-200701-sparc64-disc1.iso) =3D 22670355611d9e8eed5fe7ba1= 24db3edd76dffc6a9cf32adde48d32c0425c73c --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-1G1qKZ7sr31AwziX0fsX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFqbKu/G14VSmup/YRAnSDAJ45B3B0iLQHwXWGY4ck1itsdwAH8QCZAZ2a UGxLKI++Vxgj+f1LhX8vL/M= =EoSa -----END PGP SIGNATURE----- --=-1G1qKZ7sr31AwziX0fsX-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 07:00:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A5B016A80A for ; Sun, 14 Jan 2007 07:00:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id B3AF813C459 for ; Sun, 14 Jan 2007 07:00:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 26862 invoked by uid 399); 14 Jan 2007 07:00:16 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 14 Jan 2007 07:00:16 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45A9D4FD.5000809@FreeBSD.org> Date: Sat, 13 Jan 2007 23:00:13 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Garrett Cooper References: <45A99BA8.6040204@u.washington.edu> In-Reply-To: <45A99BA8.6040204@u.washington.edu> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Embarking on upgrade from 6.1-RELEASE to 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 07:00:28 -0000 Garrett Cooper wrote: > Before I do this, I have a few questions; I know that the bulk > majority of the documentation for my questions may exist online or in > /usr/src/UPDATING, but I was just curious of the major changes that I > can expect between 6 and 7: It's generally considered polite to read those docs that you know about first before asking on a public list. > 1. What scheduler is currently the most complete for SMP/multi-core > capable processors? One of the guidelines for running -current is to stay abreast of the -current list. This questions leads me to believe that you might want to spend a little more time reading the list before you jump. > 2. Do I need to add some sort of compatibility layer for 6 going to 7 > (similar to compat_5)? As someone else said, you're better off just rebuilding all your ports. In -current things break sometimes, A[BP]Is change, so being required to rebuild formerly working ports is par for the course. It's one of the reasons that I wrote sysutils/portmaster. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 08:26:43 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0FD416A492 for ; Sun, 14 Jan 2007 08:26:43 +0000 (UTC) (envelope-from doublef-ctm@yandex.ru) Received: from smtp4.yandex.ru (smtp4.yandex.ru [213.180.223.136]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFC513C428 for ; Sun, 14 Jan 2007 08:26:42 +0000 (UTC) (envelope-from doublef-ctm@yandex.ru) Received: from [85.172.94.213] ([85.172.94.213]:246 "EHLO shark" smtp-auth: "doublef-ctm" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S7768231AbXANI0k (ORCPT ); Sun, 14 Jan 2007 11:26:40 +0300 X-Comment: RFC 2476 MSA function at smtp4.yandex.ru logged sender identity as: doublef-ctm Received: by shark (Postfix, from userid 1000) id 1ED871776B; Sun, 14 Jan 2007 11:26:38 +0300 (MSK) Date: Sun, 14 Jan 2007 11:26:38 +0300 From: Sergey Zaharchenko To: current@freebsd.org Message-ID: <20070114082638.GA1820@shark.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline X-Listening-To: Silence User-Agent: Mutt/1.5.11 Cc: Subject: 0xdeadcode in dev2udev and ohci strangeness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 08:26:43 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello list, Today while fooling around with some USB devices (recent GENERIC kernel compiled with options USB_DEBUG; single-user mode; a Transcend USB Flash, an Acorp card reader (umass) and a Prolific COM port (uplcom), all plugged in/out randomly) and sysctls (hw.usb.debug=3D1, hw.usb.(ohci|uhci|ehci|umass|uplcom).debug=3D1), I triggered the following page fault (retyped from a camera shot) by a lowly `sysctl -a|grep usb': Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic i =3D 00 fault virtual address =3D 0xdeadc19e fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0676f25 stack pointer =3D 0x28:0xdd345aac frame pointer =3D 0x28:0xdd345aac code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 76 (sysctl) [thread pid 76 tid 100042 ] Stopped at dev2udev+0x11: movl 0xc0(%eax),%eax db> bt Tracing pid 76 tid 100042 td 0xc36bb000 dev2udev(c3790d00,88,0,0,0,...) at dev2udev+0x11 sysctl_kern_ttys(c09ebf80,0,0,dd345b98,c09ebf80,...) at sysctl_kern_ttys+0x= ab sysctl_root(0,dd345c18,2,dd345b98) at sysctl_root+0x12f userland_sysctl(c36bb000,dd345c18,2,0,bfbfdbbc,0,0,0,dd345c14,c0a3c408,0,c0= 93c5c8,522) at userland_sysctl+0xf4 __sysctl(c36bb000,dd345d00) at __sysctl+0x77 syscall(dd345d38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (-1077943200), eip =3D 0x2, esp =3D 0x296, ebp =3D 0xbfbfdbbc -= -- sys/fs/devfs/devfs_vnops.c: dev_t dev2udev(struct cdev *x) { if (x =3D=3D NULL) return (NODEV); return (x->si_priv->cdp_inode); <-- dev2udev+0x11 is here } Looks like si_priv for a non-NULL x is 0xdeadcode somewhere... I've also stumbled across a reproducible strange situation: after plugging in and out the Prolific several times and leaving it out, the kernel prints (with ohci.debug=3D1) this every second or so: ohci_rhsc: sc=3D0xc369f000 xfer=3D0xc354c800 hstatus=3D0x00000000 ohci_rhsc: change=3D0x04 Is this normal? Should I ask on freebsd-usb@? --=20 DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFqek9wo7hT/9lVdwRAjSyAJ43zo4/pgWBQMXrLQrsBDPRBjkRVACdGSof myGwB+gn1F0KLZXTomXPNLk= =57Rq -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 12:08:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F1C316A40F for ; Sun, 14 Jan 2007 12:08:37 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7BF13C45B for ; Sun, 14 Jan 2007 12:08:37 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2007 04:08:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0EC83Ah026493 for ; Sun, 14 Jan 2007 04:08:03 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0EC7vi6027873 for ; Sun, 14 Jan 2007 04:08:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 04:05:46 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 04:05:46 -0800 Message-ID: <45AA1C64.9020106@cisco.com> Date: Sun, 14 Jan 2007 07:04:52 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2007 12:05:46.0862 (UTC) FILETIME=[530290E0:01C737D4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3005; t=1168776483; x=1169640483; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Another=20question=20..=20this=20time=20on=20a=20panic |Sender:=20; bh=rDPY/QL4bTecc/JbVumWRnOMxYk9K7MAyidkfe4h3dw=; b=Wo2BLknonaI6cHmIZPqmTAIdt77CjuRv0FAx3CmqLedj7N7Q9AE0R6vTb0aipQA7cWd7Ylnq AhN9JaqUwXBCCGxIW2Cc5K/nIyXshaIOLproES2OoBiGPo/uSYtGYTi5; Authentication-Results: sj-dkim-7; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); Cc: Subject: Another question .. this time on a panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 12:08:37 -0000 Hi all: I have another question.. this time on a panic I received its: ----------------------------------------------------- Unread portion of the kernel message buffer: panic: kmem_malloc(4096): kmem_map too small: 83386368 total allocated cpuid = 0 Uptime: 17h51m42s Dumping 255 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 255MB (65248 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:166 During symbol reading, Incomplete CFI data; unspecified registers at 0xc0691f65. #1 0xc06924d4 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:411 #2 0xc06927de in panic (fmt=0xc092b294 "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at ../../../kern/kern_shutdown.c:567 #3 0xc082e335 in kmem_malloc (map=0xc14710a8, size=0x1000, flags=0x102) at ../../../vm/vm_kern.c:299 #4 0xc0826f5a in page_alloc (zone=0xc14525a0, bytes=0x1000, pflag=0x0, wait=0x102) at ../../../vm/uma_core.c:953 #5 0xc0826b53 in slab_zalloc (zone=0xc14525a0, wait=0x102) at ../../../vm/uma_core.c:818 #6 0xc08281d8 in uma_zone_slab (zone=0xc14525a0, flags=0x2) at ../../../vm/uma_core.c:2018 #7 0xc0828480 in uma_zalloc_bucket (zone=0xc14525a0, flags=0x2) at ../../../vm/uma_core.c:2127 #8 0xc0828054 in uma_zalloc_arg (zone=0xc14525a0, udata=0x0, flags=0x2) at ../../../vm/uma_core.c:1935 #9 0xc0815c1d in ffs_vget (mp=0xc240129c, ino=0x17e7, flags=0x0, vpp=0xcd1c9974) at uma.h:275 #10 0xc081c6b4 in ufs_lookup (ap=0xcd1c9a18) at ../../../ufs/ufs/ufs_lookup.c:572 #11 0xc08a3376 in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0xcd1c9a18) at vnode_if.c:153 #12 0xc06e7a02 in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #13 0xc08a32bf in VOP_LOOKUP_APV (vop=0xc09bb120, a=0xcd1c9ab8) at vnode_if.c:99 #14 0xc06ed050 in lookup (ndp=0xcd1c9ba4) at vnode_if.h:56 #15 0xc06ec92a in namei (ndp=0xcd1c9ba4) at ../../../kern/vfs_lookup.c:210 #16 0xc06fa859 in kern_stat (td=0xc2912360, path=0xbfbfaa00
, pathseg=UIO_USERSPACE, sbp=0xcd1c9c18) at ../../../kern/vfs_syscalls.c:2086 #17 0xc06fa807 in stat (td=0xc2912360, uap=0xcd1c9d00) at ../../../kern/vfs_syscalls.c:2070 #18 0xc0892fea in syscall (frame=0xcd1c9d38) at ../../../i386/i386/trap.c:1008 #19 0xc087c410 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 #20 0x28332783 in ?? () Previous frame inner to this frame (corrupt stack?) ------------------------------------------------------------- With what little poking around I have done it looks like I am out of wired memory... However the SCTP tests that were running have NO allocated associations etc.. so I am thinking I might have a memory leak.. Is there any way to tell what is holding all the memory :-) Thanks R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 16:16:39 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEF2516A407; Sun, 14 Jan 2007 16:16:39 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4A73E13C448; Sun, 14 Jan 2007 16:16:37 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with SMTP id l0EGGP7c088419; Mon, 15 Jan 2007 01:16:29 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 15 Jan 2007 01:16:25 +0900 From: Norikatsu Shigemura To: Alan Cox Message-Id: <20070115011625.36efae62.nork@FreeBSD.org> In-Reply-To: <45A519D9.9020006@cs.rice.edu> References: <20070110235152.1b65f3de.nork@FreeBSD.org> <45A519D9.9020006@cs.rice.edu> X-Mailer: Sylpheed 2.3.0rc (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Mon, 15 Jan 2007 01:16:30 +0900 (JST) Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: Panic on pmap_remove_pages by KASSERT when process is exiting.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 16:16:39 -0000 On Wed, 10 Jan 2007 10:52:41 -0600 Alan Cox wrote: > Norikatsu Shigemura wrote: > >Hi Alan. > > In recently 7-current, I often had a panic on pmap_remove_pages > > at /usr/src/sys/i386/i386/pmap.c#3072. > > Do you have any idea? > Please run a memory tester on your machine. Over the years, most of the > reported panics in pmap_remove_pages() have been a result of flakey memory. Thanks for your advice! I validated all memories(512MB SDR-SDRAM x4). And I confirmed that all memories are dying. orz From owner-freebsd-current@FreeBSD.ORG Sun Jan 14 20:45:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E9B216A407 for ; Sun, 14 Jan 2007 20:45:49 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id CEC5C13C44C for ; Sun, 14 Jan 2007 20:45:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so1849198nfc for ; Sun, 14 Jan 2007 12:45:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bezcD2KinKSCHgx2XwD6xnYNeRitDRuVYgmFdIgvv/lObx6NAr8fNMhC3jw+E650Fh3K90eNZ+saW5CEcfNLoq0W96uTrcMTdlTtlJt42yvFXHpO+9+alYmNrz67t+HC5/iBcmzDmV886vrP3QhrJJ23f+MkeHY1RWiBkYdGyAg= Received: by 10.82.162.14 with SMTP id k14mr468625bue.1168807545282; Sun, 14 Jan 2007 12:45:45 -0800 (PST) Received: by 10.82.191.16 with HTTP; Sun, 14 Jan 2007 12:45:45 -0800 (PST) Message-ID: Date: Sun, 14 Jan 2007 12:45:45 -0800 From: "Kip Macy" To: "Sergey Zaharchenko" , current@freebsd.org In-Reply-To: <20070114082638.GA1820@shark.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070114082638.GA1820@shark.localdomain> Cc: Subject: Re: 0xdeadcode in dev2udev and ohci strangeness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 20:45:49 -0000 Oxdeadcode indicates use after free - which I've seen at least one other instance of in the USB stack. -Kip On 1/14/07, Sergey Zaharchenko wrote: > Hello list, > > Today while fooling around with some USB devices (recent GENERIC kernel > compiled with options USB_DEBUG; single-user mode; a Transcend USB > Flash, an Acorp card reader (umass) and a Prolific COM port (uplcom), > all plugged in/out randomly) and sysctls (hw.usb.debug=1, > hw.usb.(ohci|uhci|ehci|umass|uplcom).debug=1), I triggered the following > page fault (retyped from a camera shot) by a lowly `sysctl -a|grep usb': > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic i = 00 > fault virtual address = 0xdeadc19e > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0676f25 > stack pointer = 0x28:0xdd345aac > frame pointer = 0x28:0xdd345aac > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 76 (sysctl) > [thread pid 76 tid 100042 ] > Stopped at dev2udev+0x11: movl 0xc0(%eax),%eax > db> bt > Tracing pid 76 tid 100042 td 0xc36bb000 > dev2udev(c3790d00,88,0,0,0,...) at dev2udev+0x11 > sysctl_kern_ttys(c09ebf80,0,0,dd345b98,c09ebf80,...) at > sysctl_kern_ttys+0xab > sysctl_root(0,dd345c18,2,dd345b98) at sysctl_root+0x12f > userland_sysctl(c36bb000,dd345c18,2,0,bfbfdbbc,0,0,0,dd345c14,c0a3c408,0,c093c5c8,522) > at userland_sysctl+0xf4 > __sysctl(c36bb000,dd345d00) at __sysctl+0x77 > syscall(dd345d38) at syscall+0x256 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (-1077943200), eip = 0x2, esp = 0x296, ebp = 0xbfbfdbbc --- > > sys/fs/devfs/devfs_vnops.c: > > dev_t > dev2udev(struct cdev *x) > { > if (x == NULL) > return (NODEV); > return (x->si_priv->cdp_inode); <-- dev2udev+0x11 is here > } > > Looks like si_priv for a non-NULL x is 0xdeadcode somewhere... > > I've also stumbled across a reproducible strange situation: after > plugging in and out the Prolific several times and leaving it out, the > kernel prints (with ohci.debug=1) this every second or so: > > ohci_rhsc: sc=0xc369f000 xfer=0xc354c800 hstatus=0x00000000 > ohci_rhsc: change=0x04 > > Is this normal? Should I ask on freebsd-usb@? > > -- > DoubleF > No virus detected in this message. Ehrm, wait a minute... > /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 > Oh yes, no virus:) > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 02:43:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13AC216A407 for ; Mon, 15 Jan 2007 02:43:15 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 902AB13C45A for ; Mon, 15 Jan 2007 02:43:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0F24rl9088672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 12:34:54 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 15 Jan 2007 12:34:37 +1030 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1191793.GzmnGBbx9l"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701151234.47602.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Subject: Undefined symbol "rtprio_thread" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 02:43:15 -0000 --nextPart1191793.GzmnGBbx9l Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I just upgraded to -current to try out SCHED_ULE and thought I'd also try=20 using libthr, however the later was stymied by the following problem with=20 openoffice.. [inchoate 12:33] ~ >openoffice /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "rtprio_thread" /libexec/ld-elf.so.1: /usr/lib/libthr.so.2: Undefined symbol "rtprio_thread" My libmap.conf is.. libpthread.so.2 libthr.so.2 libpthread.so libthr.so Anyone have any suggestions on how to fix it? (Recompile OOo? :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1191793.GzmnGBbx9l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFquE/5ZPcIHs/zowRAmBvAJ9VBzebmYrHI0RWAkHKpima+um26ACgq18W hzVE6iJah67caaNcF2veb9I= =8GSf -----END PGP SIGNATURE----- --nextPart1191793.GzmnGBbx9l-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 04:11:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EF5A16A407; Mon, 15 Jan 2007 04:11:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 35FCF13C45A; Mon, 15 Jan 2007 04:11:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0F4B37q043901; Sun, 14 Jan 2007 23:11:03 -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.8/8.13.8) with ESMTP id l0F4B3G0010568; Sun, 14 Jan 2007 23:11:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4221173034; Sun, 14 Jan 2007 23:11:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115041103.4221173034@freebsd-current.sentex.ca> Date: Sun, 14 Jan 2007 23:11:03 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on news X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 04:11:04 -0000 TB --- 2007-01-15 02:56:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 02:56:49 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-15 02:56:49 - cleaning the object tree TB --- 2007-01-15 02:57:25 - checking out the source tree TB --- 2007-01-15 02:57:25 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-15 02:57:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 03:03:20 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 03:03:20 - cd /src TB --- 2007-01-15 03:03:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 03:03:22 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 03:58:43 UTC 2007 TB --- 2007-01-15 03:58:43 - generating LINT kernel config TB --- 2007-01-15 03:58:43 - cd /src/sys/sun4v/conf TB --- 2007-01-15 03:58:43 - /usr/bin/make -B LINT TB --- 2007-01-15 03:58:43 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 03:58:43 - cd /src TB --- 2007-01-15 03:58:43 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 03:58:43 UTC 2007 >>> 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 [...] awk -f /src/sys/modules/ata/atapicam/../../../conf/kmod_syms.awk atapicam.kld export_syms | xargs -J% objcopy % atapicam.kld ld -Bshareable -d -warn-common -o atapicam.ko atapicam.kld objcopy --strip-debug atapicam.ko ===> ath (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../contrib/dev/ath -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /src/sys/modules/ath/../../dev/ath/if_ath.c /src/sys/modules/ath/../../dev/ath/if_ath.c: In function `ath_getchannels': /src/sys/modules/ath/../../dev/ath/if_ath.c:4853: warning: implicit declaration of function `ath_hal_isgsmsku' /src/sys/modules/ath/../../dev/ath/if_ath.c:4853: warning: nested extern declaration of `ath_hal_isgsmsku' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 04:11:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 04:11:03 - ERROR: failed to build lint kernel TB --- 2007-01-15 04:11:03 - tinderbox aborted TB --- 0.63 user 1.94 system 4453.51 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 04:11:27 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E31A216A585; Mon, 15 Jan 2007 04:11:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B70EC13C442; Mon, 15 Jan 2007 04:11:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0F4BQdI071145; Sun, 14 Jan 2007 23:11:26 -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.8/8.13.8) with ESMTP id l0F4BQaU067021; Sun, 14 Jan 2007 23:11:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6D67773036; Sun, 14 Jan 2007 23:11:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115041126.6D67773036@freebsd-current.sentex.ca> Date: Sun, 14 Jan 2007 23:11:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 04:11:28 -0000 TB --- 2007-01-15 02:51:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 02:51:40 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-01-15 02:51:40 - cleaning the object tree TB --- 2007-01-15 02:52:19 - checking out the source tree TB --- 2007-01-15 02:52:19 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-01-15 02:52:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 03:03:20 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 03:03:20 - cd /src TB --- 2007-01-15 03:03:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 03:03:22 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 03:58:48 UTC 2007 TB --- 2007-01-15 03:58:48 - generating LINT kernel config TB --- 2007-01-15 03:58:48 - cd /src/sys/sparc64/conf TB --- 2007-01-15 03:58:48 - /usr/bin/make -B LINT TB --- 2007-01-15 03:58:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 03:58:48 - cd /src TB --- 2007-01-15 03:58:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 03:58:49 UTC 2007 >>> 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 [...] awk -f /src/sys/modules/ata/atapicam/../../../conf/kmod_syms.awk atapicam.kld export_syms | xargs -J% objcopy % atapicam.kld ld -Bshareable -d -warn-common -o atapicam.ko atapicam.kld objcopy --strip-debug atapicam.ko ===> ath (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I- -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../contrib/dev/ath -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -c /src/sys/modules/ath/../../dev/ath/if_ath.c /src/sys/modules/ath/../../dev/ath/if_ath.c: In function `ath_getchannels': /src/sys/modules/ath/../../dev/ath/if_ath.c:4853: warning: implicit declaration of function `ath_hal_isgsmsku' /src/sys/modules/ath/../../dev/ath/if_ath.c:4853: warning: nested extern declaration of `ath_hal_isgsmsku' *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 04:11:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 04:11:26 - ERROR: failed to build lint kernel TB --- 2007-01-15 04:11:26 - tinderbox aborted TB --- 0.82 user 2.23 system 4785.69 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 05:47:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7AF716A40F; Mon, 15 Jan 2007 05:47:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 631A813C448; Mon, 15 Jan 2007 05:47:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0F5lvai074343; Mon, 15 Jan 2007 00:47: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.8/8.13.8) with ESMTP id l0F5lvpw035963; Mon, 15 Jan 2007 00:47:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3C5B273034; Mon, 15 Jan 2007 00:47:57 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115054757.3C5B273034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 00:47:57 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 05:47:58 -0000 TB --- 2007-01-15 04:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 04:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-15 04:15:00 - cleaning the object tree TB --- 2007-01-15 04:15:49 - checking out the source tree TB --- 2007-01-15 04:15:49 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-15 04:15:49 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 04:26:18 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 04:26:18 - cd /src TB --- 2007-01-15 04:26:18 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 04:26:20 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 15 05:42:52 UTC 2007 TB --- 2007-01-15 05:42:52 - generating LINT kernel config TB --- 2007-01-15 05:42:52 - cd /src/sys/amd64/conf TB --- 2007-01-15 05:42:52 - /usr/bin/make -B LINT TB --- 2007-01-15 05:42:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 05:42:52 - cd /src TB --- 2007-01-15 05:42:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 05:42:52 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/atapi-fd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/atapi-tape.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ah_osdep.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/ath_rate/sample/sample.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function `ath_getchannels': /src/sys/dev/ath/if_ath.c:4853: warning: implicit declaration of function `ath_hal_isgsmsku' /src/sys/dev/ath/if_ath.c:4853: warning: nested extern declaration of `ath_hal_isgsmsku' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 05:47:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 05:47:56 - ERROR: failed to build lint kernel TB --- 2007-01-15 05:47:56 - tinderbox aborted TB --- 0.74 user 3.60 system 5576.20 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 06:41:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D077316A415 for ; Mon, 15 Jan 2007 06:41:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF3013C428 for ; Mon, 15 Jan 2007 06:41:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.25]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0F6fbvg097911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 17:11:40 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 15 Jan 2007 17:11:32 +1030 User-Agent: KMail/1.9.5 References: <200701151234.47602.doconnor@gsoft.com.au> In-Reply-To: <200701151234.47602.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3808849.4RLFpaHQ9R"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701151711.33138.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Subject: Re: Undefined symbol "rtprio_thread" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 06:41:45 -0000 --nextPart3808849.4RLFpaHQ9R Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 15 January 2007 12:34, Daniel O'Connor wrote: > Anyone have any suggestions on how to fix it? (Recompile OOo? :) It appears to be a Java problem so I'll try rebuilding Java. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3808849.4RLFpaHQ9R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFqyId5ZPcIHs/zowRAqacAJ9h3UW/ll+utJf6LUXdTwGqaclV3gCcDp/W 339OpBurIltEMyqgFEv9mnM= =O+3T -----END PGP SIGNATURE----- --nextPart3808849.4RLFpaHQ9R-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 06:43:58 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D60116A407; Mon, 15 Jan 2007 06:43:58 +0000 (UTC) (envelope-from dsh@vlink.ru) Received: from rigel.internal.vlink.ru (rigel.internal.vlink.ru [85.172.168.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBDE13C442; Mon, 15 Jan 2007 06:43:57 +0000 (UTC) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id AF006FECCB4; Mon, 15 Jan 2007 09:43:55 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [85.172.168.250]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 6DA3010098B1; Mon, 15 Jan 2007 09:43:55 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.8/8.13.8) with ESMTP id l0F6htlC095228; Mon, 15 Jan 2007 09:43:55 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.8/8.13.8/Submit) id l0F6hsSR095225; Mon, 15 Jan 2007 09:43:54 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: John Baldwin To: John Baldwin References: <200611152004.kAFK4vfe058983@repoman.freebsd.org> <200701091417.18936.jhb@freebsd.org> <87ejq26n8b.fsf@neva.vlink.ru> <200701111126.10095.jhb@freebsd.org> From: Denis Shaposhnikov Date: Mon, 15 Jan 2007 09:43:54 +0300 In-Reply-To: <200701111126.10095.jhb@freebsd.org> (John Baldwin's message of "Thu, 11 Jan 2007 11:26:09 -0500") Message-ID: <87r6twiyc5.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b27 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 06:43:58 -0000 >>>>> "John" == John Baldwin writes: John> Try this and see if it disables MSI for you automatically: John> Index: pci.c John> =================================================================== John> RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v retrieving revision John> 1.331 diff -u -r1.331 pci.c John> --- pci.c 28 Dec 2006 06:14:42 -0000 1.331 John> +++ pci.c 11 Jan 2007 16:25:20 -0000 I've applied the patch and sysctl hw.pci.enable_msi still show "1" but no system freeze like boot with MSI disabled. BTW, I have watchdog timeouts and panic with em(4) on next to hosts. Disabling MSI fixes it. Here is pciconf -l: ==================== hostb0@pci0:0:0: class=0x060000 card=0x80941043 chip=0x25608086 rev=0x03 hdr=0x00 vgapci0@pci0:2:0: class=0x030000 card=0x25621043 chip=0x25628086 rev=0x03 hdr=0x00 none0@pci0:29:0: class=0x0c0300 card=0x80891043 chip=0x24c28086 rev=0x02 hdr=0x00 none1@pci0:29:1: class=0x0c0300 card=0x80891043 chip=0x24c48086 rev=0x02 hdr=0x00 none2@pci0:29:2: class=0x0c0300 card=0x80891043 chip=0x24c78086 rev=0x02 hdr=0x00 pcib1@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x82 hdr=0x01 isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24c08086 rev=0x02 hdr=0x00 atapci0@pci0:31:1: class=0x01018a card=0x80891043 chip=0x24cb8086 rev=0x02 hdr=0x00 fxp0@pci2:9:0: class=0x020000 card=0x305c1014 chip=0x12298086 rev=0x08 hdr=0x00 em0@pci2:10:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 em1@pci2:10:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 em2@pci2:11:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 em3@pci2:11:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 rl0@pci2:13:0: class=0x020000 card=0x80b31043 chip=0x813910ec rev=0x10 hdr=0x00 ==================== ==================== hostb0@pci0:0:0: class=0x060000 card=0x25708086 chip=0x25708086 rev=0x02 hdr=0x00 vgapci0@pci0:2:0: class=0x030000 card=0x03701462 chip=0x25728086 rev=0x02 hdr=0x00 none0@pci0:29:0: class=0x0c0300 card=0x03701462 chip=0x24d28086 rev=0x02 hdr=0x00 none1@pci0:29:1: class=0x0c0300 card=0x03701462 chip=0x24d48086 rev=0x02 hdr=0x00 none2@pci0:29:2: class=0x0c0300 card=0x03701462 chip=0x24d78086 rev=0x02 hdr=0x00 none3@pci0:29:3: class=0x0c0300 card=0x03701462 chip=0x24de8086 rev=0x02 hdr=0x00 none4@pci0:29:7: class=0x0c0320 card=0x03701462 chip=0x24dd8086 rev=0x02 hdr=0x00 pcib1@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0xc2 hdr=0x01 isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24d08086 rev=0x02 hdr=0x00 atapci0@pci0:31:1: class=0x01018a card=0x03701462 chip=0x24db8086 rev=0x02 hdr=0x00 atapci1@pci0:31:2: class=0x01018f card=0x03701462 chip=0x24d18086 rev=0x02 hdr=0x00 none5@pci0:31:3: class=0x0c0500 card=0x03701462 chip=0x24d38086 rev=0x02 hdr=0x00 none6@pci0:31:5: class=0x040100 card=0x03701462 chip=0x24d58086 rev=0x02 hdr=0x00 em0@pci1:10:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 em1@pci1:10:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 hdr=0x00 rl0@pci1:13:0: class=0x020000 card=0x037c1462 chip=0x813910ec rev=0x10 hdr=0x00 ==================== Thank you very much! -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet xmpp:dsh@vlink.ru mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 08:47:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29E3B16A412 for ; Mon, 15 Jan 2007 08:47:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id B30AF13C467 for ; Mon, 15 Jan 2007 08:47:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0F8VPXf001422; Mon, 15 Jan 2007 19:31:25 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0F8VPnU001421; Mon, 15 Jan 2007 19:31:25 +1100 (EST) (envelope-from peter) Date: Mon, 15 Jan 2007 19:31:25 +1100 From: Peter Jeremy To: Randall Stewart Message-ID: <20070115083125.GC839@turion.vk2pj.dyndns.org> References: <45AA1C64.9020106@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <45AA1C64.9020106@cisco.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Another question .. this time on a panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 08:47:14 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2007-Jan-14 07:04:52 -0500, Randall Stewart wrote: >panic: kmem_malloc(4096): kmem_map too small: 83386368 total allocated =2E.. >With what little poking around I have done it looks >like I am out of wired memory... =2E.. >Is there any way to tell what is holding all the memory :-) vmstat -m --=20 Peter Jeremy --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFqzvd/opHv/APuIcRAtb5AJ96IS6pLqP0q29h5wV7UYzh+lsHtwCglXfC V5Rgs0xim3K9JWhoX8t+TsU= =tpC5 -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 10:27:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44F9516A415; Mon, 15 Jan 2007 10:27:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C0F2013C442; Mon, 15 Jan 2007 10:27:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-97.lns1.adl2.internode.on.net [203.122.211.97]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0FARRrq007393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jan 2007 20:57:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 15 Jan 2007 20:55:07 +1030 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2030755.xbXKgaSDyY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701152055.18416.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Cc: kde@freebsd.org Subject: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 10:27:43 -0000 --nextPart2030755.xbXKgaSDyY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I recently updated my machine to -current, however I can nolonger unlock my= =20 desktop - I have to manually kill the kdesktop_lock process. I've recompiled kdebase but it had no effect. I plan to try kdelibs soon. Is this a known issue? Thanks =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2030755.xbXKgaSDyY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFq1aO5ZPcIHs/zowRAsDbAJ0dafRYCzt8dTwynrjxNjU9yE7HfACZASio bJ7m8qkVqPf79d5QG5igM/E= =ILs6 -----END PGP SIGNATURE----- --nextPart2030755.xbXKgaSDyY-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 12:45:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 010F016A415 for ; Mon, 15 Jan 2007 12:45:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D114213C459 for ; Mon, 15 Jan 2007 12:45:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4C3474A67E; Mon, 15 Jan 2007 07:45:57 -0500 (EST) Date: Mon, 15 Jan 2007 12:45:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20070115083125.GC839@turion.vk2pj.dyndns.org> Message-ID: <20070115124503.X24395@fledge.watson.org> References: <45AA1C64.9020106@cisco.com> <20070115083125.GC839@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , current@freebsd.org Subject: Re: Another question .. this time on a panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 12:45:58 -0000 On Mon, 15 Jan 2007, Peter Jeremy wrote: > On Sun, 2007-Jan-14 07:04:52 -0500, Randall Stewart wrote: >> panic: kmem_malloc(4096): kmem_map too small: 83386368 total allocated > ... >> With what little poking around I have done it looks >> like I am out of wired memory... > ... >> Is there any way to tell what is holding all the memory :-) > > vmstat -m And vmstat -z for the slab allocator. Both of which can be run on core dumps as well as live systems. In the DDB debugger, there's also "show uma" and "show malloc" which display basically the same information. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 12:47:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71F4D16A412 for ; Mon, 15 Jan 2007 12:47:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4884413C45D for ; Mon, 15 Jan 2007 12:47:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C996A4A685; Mon, 15 Jan 2007 07:47:51 -0500 (EST) Date: Mon, 15 Jan 2007 12:47:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel O'Connor In-Reply-To: <200701152055.18416.doconnor@gsoft.com.au> Message-ID: <20070115124603.R24395@fledge.watson.org> References: <200701152055.18416.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: andre@FreeBSD.org, freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 12:47:52 -0000 On Mon, 15 Jan 2007, Daniel O'Connor wrote: > I recently updated my machine to -current, however I can nolonger unlock my > desktop - I have to manually kill the kdesktop_lock process. > > I've recompiled kdebase but it had no effect. I plan to try kdelibs soon. > > Is this a known issue? Yes -- Peter recently ran into this, and John did a bit of debugging. Andre's work to optimize socket send may have broken 0-byte writes on stream sockets. My recent commit of the zerosend regression test is intended to help encourage fixing it. :-) I've not investigated exactly why KDE performs zero-byte writes on a stream socket, but it could be it's sending ancillary data but no normal data. Whether it's legitimate or not, we should fix this, however. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 14:47:56 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10EE916A4A7; Mon, 15 Jan 2007 14:47:56 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id D64AE13C478; Mon, 15 Jan 2007 14:47:55 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2007 06:47:55 -0800 X-IronPort-AV: i="4.13,190,1167638400"; d="scan'208"; a="101716570:sNHT43743690" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0FEltGH031755; Mon, 15 Jan 2007 06:47:55 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0FEltUw023808; Mon, 15 Jan 2007 06:47:55 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 06:47:54 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 06:47:54 -0800 Message-ID: <45AB93E2.1030200@cisco.com> Date: Mon, 15 Jan 2007 09:46:58 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Robert Watson References: <45AA1C64.9020106@cisco.com> <20070115083125.GC839@turion.vk2pj.dyndns.org> <20070115124503.X24395@fledge.watson.org> In-Reply-To: <20070115124503.X24395@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2007 14:47:54.0699 (UTC) FILETIME=[23AA71B0:01C738B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1040; t=1168872475; x=1169736475; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Another=20question=20..=20this=20time=20on=20a=20pani c |Sender:=20; bh=N97MpS6euvmcD/kgWFsg6piwMN53J2AqN/okRC16Sqc=; b=XDyYq71U5qY2CkGLyUkd62JCf3G1+f7zX6l1yF5oiEke5VuhTmdkffs/e4mUwbgfSKshoeKE 51zZDt1rNDV153dNKLmh38NCBO9dLKHyKQhDBYRZoz0z8li9RV7aHRgx; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: Peter Jeremy , current@FreeBSD.org Subject: Re: Another question .. this time on a panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 14:47:56 -0000 Robert Watson wrote: > > On Mon, 15 Jan 2007, Peter Jeremy wrote: > >> On Sun, 2007-Jan-14 07:04:52 -0500, Randall Stewart wrote: >>> panic: kmem_malloc(4096): kmem_map too small: 83386368 total allocated >> ... >>> With what little poking around I have done it looks >>> like I am out of wired memory... >> ... >>> Is there any way to tell what is holding all the memory :-) >> >> vmstat -m > > And vmstat -z for the slab allocator. Both of which can be run on core > dumps as well as live systems. But unfortunately its broke.. at least when I tried it, it did not work... :( > > In the DDB debugger, there's also "show uma" and "show malloc" which > display basically the same information. Ahh.. but my machine is debug unattended... so I have made a kgdb set of utilites that do vmstat_zone and vmstat_malloc :-) R > > Robert N M Watson > Computer Laboratory > University of Cambridge > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 14:58:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B5D816A6D1 for ; Mon, 15 Jan 2007 14:58:36 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 554E213C44B for ; Mon, 15 Jan 2007 14:58:36 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Jan 2007 06:58:36 -0800 X-IronPort-AV: i="4.13,190,1167638400"; d="scan'208"; a="356193441:sNHT49649240" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0FEwZTT031495 for ; Mon, 15 Jan 2007 06:58:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0FEwZUw028891 for ; Mon, 15 Jan 2007 06:58:35 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 06:58:33 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 06:58:33 -0800 Message-ID: <45AB9661.9040909@cisco.com> Date: Mon, 15 Jan 2007 09:57:37 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: current@FreeBSD.org References: <45AB9324.1030701@cisco.com> In-Reply-To: <45AB9324.1030701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2007 14:58:33.0287 (UTC) FILETIME=[A04B3D70:01C738B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3603; t=1168873115; x=1169737115; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20VM=20Memory=20question |Sender:=20 |To:=20current@FreeBSD.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowe d |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=/IvxWFej/ZR5ZfYKIVV1uNt9HyYFZ3S83vM0HvAi0uQ=; b=jqR1WA/2OsCuu5Hnl/fIQT5+g5RVpxMgwD5xLCObXh9thc/PPaa90sWYxE9tdqDKoI4diw03 05+yzdOwDmvPwSoxo+KQhtVRXoTkAODIuzFEEBernhSzOYaKHOcXFT/qxiN1cUyq1QQWbgkc7O UQU8HXnuALJxaKfEgGDouPW+w=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: Subject: VM Memory question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 14:58:36 -0000 Having posted this to the wrong place.. :-0 Let me redirect it to the right one :-) Randall Stewart wrote: > Hi all: > > I am looking at a memory problem.. i.e. maybe a leak somewhere.. > > I wrote a script in kgdb to get malloc and zone info. > Now I am not all that familiar with these structures > but I think there may be an issue.. either that > or I just don't understand what I am reading :-) > > The big standout to me is: > > zone:0xc145f1e0 pages: 14092 keg_free: 0 size:16384 alloc: > 12446364 frees: 12446297 fail: 0 biu:57720832 > -------------------------------------------- > > From my limited understanding.. pages aka keg->uk_pages > tells me I have a huge number of pages in the zone > coming out to about 57Meg of memory.. wow! > > > Now this zone is really: > ----------------------------------------------- > $3 = (struct uma_zone *) 0xc145f1e0 > (kgdb) print *$3 > $4 = { > uz_name = 0xc090c41b "mbuf_jumbo_16k", > uz_lock = 0xc1461188, > uz_keg = 0xc1461180, > uz_link = { > le_next = 0x0, > le_prev = 0xc14611ac > }, > uz_full_bucket = { > lh_first = 0xc6a64c48 > }, > uz_free_bucket = { > lh_first = 0xc6a3b624 > }, > uz_ctor = 0xc06888ec , > uz_dtor = 0xc06889c4 , > uz_init = 0, > uz_fini = 0, > uz_allocs = 0xbdea9c, > uz_frees = 0xbdea59, > uz_fails = 0x0, > uz_fills = 0x0, > uz_count = 0x80, > uz_cpu = {{ > uc_freebucket = 0xc6a3f20c, > uc_allocbucket = 0xc6a35000, > uc_allocs = 0x291, > uc_frees = 0x295 > }} > } > ------------------------------------ > > Now looking at the allocs/frees.. and subtracting we > only have (according to the zone) 67 that are not free.. > > The keg looks as follows: > ---------------------------------------- > $5 = { > uk_link = { > le_next = 0xc1461100, > le_prev = 0xc1461200 > }, > uk_lock = { > mtx_object = { > lo_name = 0xc090c41b "mbuf_jumbo_16k", > lo_type = 0xc09099e2 "UMA zone", > lo_flags = 0x1430000, > lo_witness_data = { > lod_list = { > stqe_next = 0xc0a06be0 > }, > lod_witness = 0xc0a06be0 > } > }, > mtx_lock = 0x4, > mtx_recurse = 0x0 > }, > uk_hash = { > uh_slab_hash = 0xc6a4b000, > uh_hashsize = 0x1000, > uh_hashmask = 0xfff > }, > uk_zones = { > lh_first = 0xc145f1e0 > }, > uk_part_slab = { > lh_first = 0x0 > }, > uk_free_slab = { > lh_first = 0x0 > }, > uk_full_slab = { > lh_first = 0xc692b5b0 > }, > uk_recurse = 0x0, > uk_align = 0x3, > uk_pages = 0x370c, > uk_free = 0x0, > uk_size = 0x4000, > uk_rsize = 0x4000, > uk_maxpages = 0x0, > uk_init = 0xc0829b90 , > uk_fini = 0xc0829ba8 , > uk_allocf = 0xc0826f40 , > uk_freef = 0xc08270ac , > uk_obj = 0x0, > uk_kva = 0x0, > uk_slabzone = 0xc14731e0, > uk_pgoff = 0x0, > uk_ppera = 0x4, > uk_ipers = 0x1, > uk_flags = 0x508 > } > ---------------------------------- > > So where is all the memory hiding? > > And if its free (as the zone implies) why is it > not getting released back to the system... (the machine > crashed with a "no memory" condition.. > > ??? > > Help from someone with a clue would be much > appreciated :-) > > Thanks > > R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 15:37:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB63C16A407 for ; Mon, 15 Jan 2007 15:37:03 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 8557813C468 for ; Mon, 15 Jan 2007 15:37:03 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D01F.dip.t-dialin.net [84.165.208.31]) by redbull.bpaserver.net (Postfix) with ESMTP id 483482E1BA for ; Mon, 15 Jan 2007 16:44:13 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id C76D25B497E for ; Mon, 15 Jan 2007 16:36:56 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0FFaucX074838 for current@freebsd.org; Mon, 15 Jan 2007 16:36:56 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 15 Jan 2007 16:36:56 +0100 Message-ID: <20070115163656.wqjrj2jlwgw8gc0c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 15 Jan 2007 16:36:56 +0100 From: Alexander Leidinger To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.364, required 6, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14, IMPRONONCABLE_2 1.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Subject: panic: relpbuf with vp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 15:37:03 -0000 Hi, I just noticed the panic: relpbuf with vp This is with -current as of Jan 9. Is this fixed, or do you need more =20 info (which one, I have the coredump around)? Bye, Alexander. (kgdb) bt #0 doadump () at pcpu.h:166 During symbol reading, Incomplete CFI data; unspecified registers at =20 0xc04a0906. #1 0xc04a0fd6 in boot (howto=3D0x104) at ../../../kern/kern_shutdown.c:411 #2 0xc04a0b25 in panic (fmt=3D0xc05c5b35 "relpbuf with vp") at =20 ../../../kern/kern_shutdown.c:567 #3 0xc056b172 in relpbuf (bp=3D0xcceb0f90, pfreecnt=3D0xc05f0e2c) at =20 ../../../vm/vm_pager.c:397 #4 0xc054bc46 in ffs_rawread_main (vp=3D0xc3a24218, uio=3D0xd70fcc68) at = =20 ../../../ufs/ffs/ffs_rawread.c:417 #5 0xc054c209 in ffs_rawread (vp=3D0xc3a24218, uio=3D0xd70fcc68, =20 workdone=3D0xd70fcb58) at ../../../ufs/ffs/ffs_rawread.c:476 #6 0xc0549beb in ffs_read (ap=3D0xd70fcba0) at ../../../ufs/ffs/ffs_vnops.c= :432 #7 0xc059932c in VOP_READ_APV (vop=3D0x0, a=3D0xd70fcba0) at vnode_if.c:637 #8 0xc04fae9b in vn_read (fp=3D0xc4cf0090, uio=3D0xd70fcc68, =20 active_cred=3D0xc3071d00, flags=3D0x0, td=3D0xc5bff000) at vnode_if.h:343 #9 0xc04c56c6 in dofileread (td=3D0xc5bff000, fd=3D0x4, fp=3D0xc4cf0090, = =20 auio=3D0xd70fcc68, offset=3DUnhandled dwarf expression opcode 0x93 ) at file.h:242 #10 0xc04c5864 in kern_readv (td=3D0xc5bff000, fd=3D0x4, auio=3D0xd70fcc68) = =20 at ../../../kern/sys_generic.c:192 #11 0xc04c5902 in read (td=3D0xc5bff000, uap=3D0x0) at =20 ../../../kern/sys_generic.c:116 #12 0xc058f815 in syscall (frame=3D0xd70fcd38) at ../../../i386/i386/trap.c:= 1008 #13 0xc0581150 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 #14 0x281100e8 in ?? () Previous frame inner to this frame (corrupt stack?) Bye, Alexander. --=20 Each man is his own prisoner, in solitary confinement for life. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 17:01:00 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5296616A40F; Mon, 15 Jan 2007 17:01:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2808A13C442; Mon, 15 Jan 2007 17:01:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0FH0xUh012836; Mon, 15 Jan 2007 12:00:59 -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.8/8.13.8) with ESMTP id l0FH0xkB026590; Mon, 15 Jan 2007 12:00:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 593E673034; Mon, 15 Jan 2007 12:00:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115170059.593E673034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 12:00:59 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 17:01:00 -0000 TB --- 2007-01-15 15:51:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 15:51:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-15 15:51:59 - cleaning the object tree TB --- 2007-01-15 15:52:28 - checking out the source tree TB --- 2007-01-15 15:52:28 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-15 15:52:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 15:58:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 15:58:09 - cd /src TB --- 2007-01-15 15:58:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 15:58:11 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 16:53:39 UTC 2007 TB --- 2007-01-15 16:53:39 - generating LINT kernel config TB --- 2007-01-15 16:53:39 - cd /src/sys/sun4v/conf TB --- 2007-01-15 16:53:39 - /usr/bin/make -B LINT TB --- 2007-01-15 16:53:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 16:53:39 - cd /src TB --- 2007-01-15 16:53:39 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 16:53:41 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 17:00:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 17:00:59 - ERROR: failed to build lint kernel TB --- 2007-01-15 17:00:59 - tinderbox aborted TB --- 0.55 user 2.01 system 4139.20 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 17:01:20 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B683F16A416; Mon, 15 Jan 2007 17:01:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBA213C469; Mon, 15 Jan 2007 17:01:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0FH1K5f012895; Mon, 15 Jan 2007 12:01:20 -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.8/8.13.8) with ESMTP id l0FH1JOV027064; Mon, 15 Jan 2007 12:01:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D0A5173034; Mon, 15 Jan 2007 12:01:19 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115170119.D0A5173034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 12:01:19 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 17:01:20 -0000 TB --- 2007-01-15 15:46:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 15:46:42 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-01-15 15:46:42 - cleaning the object tree TB --- 2007-01-15 15:47:13 - checking out the source tree TB --- 2007-01-15 15:47:13 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-01-15 15:47:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 15:58:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 15:58:09 - cd /src TB --- 2007-01-15 15:58:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 15:58:11 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 16:53:44 UTC 2007 TB --- 2007-01-15 16:53:44 - generating LINT kernel config TB --- 2007-01-15 16:53:44 - cd /src/sys/sparc64/conf TB --- 2007-01-15 16:53:44 - /usr/bin/make -B LINT TB --- 2007-01-15 16:53:44 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 16:53:44 - cd /src TB --- 2007-01-15 16:53:44 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 16:53:44 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 17:01:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 17:01:19 - ERROR: failed to build lint kernel TB --- 2007-01-15 17:01:19 - tinderbox aborted TB --- 0.73 user 2.38 system 4477.69 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 17:11:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A26A016A47C; Mon, 15 Jan 2007 17:11:05 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id CEC2613C4BC; Mon, 15 Jan 2007 17:11:03 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l0FGeaZW077055; Mon, 15 Jan 2007 10:40:36 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l0FGeYro077054; Mon, 15 Jan 2007 10:40:34 -0600 (CST) (envelope-from brooks) Date: Mon, 15 Jan 2007 10:40:34 -0600 From: Brooks Davis To: "Daniel O'Connor" Message-ID: <20070115164034.GC74652@lor.one-eyed-alien.net> References: <200701152055.18416.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <200701152055.18416.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 17:11:05 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2007 at 08:55:07PM +1030, Daniel O'Connor wrote: > Hi, > I recently updated my machine to -current, however I can nolonger unlock = my=20 > desktop - I have to manually kill the kdesktop_lock process. >=20 > I've recompiled kdebase but it had no effect. I plan to try kdelibs soon. >=20 > Is this a known issue? The problem is apparently due to breaking of sending zerobyte messages over certain types of sockets. I think peter has a patch that works around it in KDE, but I'm not sure it's available anywhere. -- Brooks --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFq66CXY6L6fI4GtQRAv+PAJ0TDqR5LENKHk2QvgIN3Ktw7oBr+QCeIEAb wN4PgEyLxQn29muk1pZcgEQ= =90Ez -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 18:21:03 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D1A516A416 for ; Mon, 15 Jan 2007 18:21:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D5E1C13C459 for ; Mon, 15 Jan 2007 18:21:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 51932 invoked from network); 15 Jan 2007 17:35:27 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Jan 2007 17:35:27 -0000 Message-ID: <45ABBFCC.3040204@freebsd.org> Date: Mon, 15 Jan 2007 18:54:20 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Brooks Davis References: <200701152055.18416.doconnor@gsoft.com.au> <20070115164034.GC74652@lor.one-eyed-alien.net> In-Reply-To: <20070115164034.GC74652@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 18:21:03 -0000 Brooks Davis wrote: > On Mon, Jan 15, 2007 at 08:55:07PM +1030, Daniel O'Connor wrote: > >>Hi, >>I recently updated my machine to -current, however I can nolonger unlock my >>desktop - I have to manually kill the kdesktop_lock process. >> >>I've recompiled kdebase but it had no effect. I plan to try kdelibs soon. >> >>Is this a known issue? > > > The problem is apparently due to breaking of sending zerobyte messages > over certain types of sockets. I think peter has a patch that works > around it in KDE, but I'm not sure it's available anywhere. I have a fix in the works. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 18:41:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D98C16A412; Mon, 15 Jan 2007 18:41:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2215E13C459; Mon, 15 Jan 2007 18:41:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FIfdcV061475; Mon, 15 Jan 2007 13:41:39 -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.8/8.13.8) with ESMTP id l0FIfdIj023528; Mon, 15 Jan 2007 13:41:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E561173034; Mon, 15 Jan 2007 13:41:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115184138.E561173034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 13:41:38 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 18:41:40 -0000 TB --- 2007-01-15 17:05:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 17:05:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-15 17:05:01 - cleaning the object tree TB --- 2007-01-15 17:05:47 - checking out the source tree TB --- 2007-01-15 17:05:47 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-15 17:05:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 17:16:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 17:16:09 - cd /src TB --- 2007-01-15 17:16:09 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 17:16:10 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 15 18:33:17 UTC 2007 TB --- 2007-01-15 18:33:17 - generating LINT kernel config TB --- 2007-01-15 18:33:17 - cd /src/sys/amd64/conf TB --- 2007-01-15 18:33:17 - /usr/bin/make -B LINT TB --- 2007-01-15 18:33:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 18:33:17 - cd /src TB --- 2007-01-15 18:33:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 18:33:17 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 18:41:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 18:41:38 - ERROR: failed to build lint kernel TB --- 2007-01-15 18:41:38 - tinderbox aborted TB --- 0.84 user 3.50 system 5797.48 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 19:27:11 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BD9716A412; Mon, 15 Jan 2007 19:27:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CBF3013C448; Mon, 15 Jan 2007 19:27:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FJRA1V068396; Mon, 15 Jan 2007 14:27:10 -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.8/8.13.8) with ESMTP id l0FJR7n9079923; Mon, 15 Jan 2007 14:27:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A11EE73034; Mon, 15 Jan 2007 14:27:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115192707.A11EE73034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 14:27:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 19:27:11 -0000 TB --- 2007-01-15 18:13:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 18:13:08 - starting HEAD tinderbox run for i386/i386 TB --- 2007-01-15 18:13:08 - cleaning the object tree TB --- 2007-01-15 18:13:43 - checking out the source tree TB --- 2007-01-15 18:13:43 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-01-15 18:13:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 18:22:28 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 18:22:28 - cd /src TB --- 2007-01-15 18:22:28 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 18:22:30 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 19:18:02 UTC 2007 TB --- 2007-01-15 19:18:02 - generating LINT kernel config TB --- 2007-01-15 19:18:02 - cd /src/sys/i386/conf TB --- 2007-01-15 19:18:02 - /usr/bin/make -B LINT TB --- 2007-01-15 19:18:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 19:18:02 - cd /src TB --- 2007-01-15 19:18:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 19:18:02 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 19:27:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 19:27:07 - ERROR: failed to build lint kernel TB --- 2007-01-15 19:27:07 - tinderbox aborted TB --- 0.88 user 2.63 system 4439.18 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 19:54:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E721116A494; Mon, 15 Jan 2007 19:54:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A89AF13C45E; Mon, 15 Jan 2007 19:54:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FJs8lI072436; Mon, 15 Jan 2007 14:54:08 -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.8/8.13.8) with ESMTP id l0FJs8sB011292; Mon, 15 Jan 2007 14:54:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6180A73034; Mon, 15 Jan 2007 14:54:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115195408.6180A73034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 14:54:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 19:54:10 -0000 TB --- 2007-01-15 18:41:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 18:41:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-01-15 18:41:39 - cleaning the object tree TB --- 2007-01-15 18:42:10 - checking out the source tree TB --- 2007-01-15 18:42:10 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-01-15 18:42:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 18:53:19 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 18:53:19 - cd /src TB --- 2007-01-15 18:53:19 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 18:53:20 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 19:46:47 UTC 2007 TB --- 2007-01-15 19:46:47 - generating LINT kernel config TB --- 2007-01-15 19:46:47 - cd /src/sys/pc98/conf TB --- 2007-01-15 19:46:47 - /usr/bin/make -B LINT TB --- 2007-01-15 19:46:47 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 19:46:47 - cd /src TB --- 2007-01-15 19:46:47 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 19:46:48 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 19:54:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 19:54:08 - ERROR: failed to build lint kernel TB --- 2007-01-15 19:54:08 - tinderbox aborted TB --- 0.91 user 2.66 system 4348.97 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 21:01:24 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2190616A417; Mon, 15 Jan 2007 21:01:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D42DD13C467; Mon, 15 Jan 2007 21:01:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FL1Mm5081739; Mon, 15 Jan 2007 16:01:23 -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.8/8.13.8) with ESMTP id l0FL1Mec082874; Mon, 15 Jan 2007 16:01:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9ACF973034; Mon, 15 Jan 2007 16:01:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115210122.9ACF973034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 16:01:22 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner4 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 21:01:24 -0000 TB --- 2007-01-15 19:27:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 19:27:07 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-01-15 19:27:07 - cleaning the object tree TB --- 2007-01-15 19:27:40 - checking out the source tree TB --- 2007-01-15 19:27:40 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-01-15 19:27:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 19:36:11 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 19:36:11 - cd /src TB --- 2007-01-15 19:36:11 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 19:36:12 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 20:51:17 UTC 2007 TB --- 2007-01-15 20:51:17 - generating LINT kernel config TB --- 2007-01-15 20:51:17 - cd /src/sys/ia64/conf TB --- 2007-01-15 20:51:17 - /usr/bin/make -B LINT TB --- 2007-01-15 20:51:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 20:51:17 - cd /src TB --- 2007-01-15 20:51:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 20:51:18 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 21:01:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 21:01:22 - ERROR: failed to build lint kernel TB --- 2007-01-15 21:01:22 - tinderbox aborted TB --- 0.60 user 2.53 system 5654.61 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 21:04:53 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2865316A417; Mon, 15 Jan 2007 21:04:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DB24413C47E; Mon, 15 Jan 2007 21:04:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FL4qIC082303; Mon, 15 Jan 2007 16:04:52 -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.8/8.13.8) with ESMTP id l0FL4p97055479; Mon, 15 Jan 2007 16:04:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A23AC73034; Mon, 15 Jan 2007 16:04:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115210451.A23AC73034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 16:04:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 21:04:53 -0000 TB --- 2007-01-15 19:54:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 19:54:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-01-15 19:54:08 - cleaning the object tree TB --- 2007-01-15 19:54:34 - checking out the source tree TB --- 2007-01-15 19:54:34 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-01-15 19:54:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 20:02:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 20:02:56 - cd /src TB --- 2007-01-15 20:02:56 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 20:02:57 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 20:58:37 UTC 2007 TB --- 2007-01-15 20:58:37 - generating LINT kernel config TB --- 2007-01-15 20:58:37 - cd /src/sys/powerpc/conf TB --- 2007-01-15 20:58:37 - /usr/bin/make -B LINT TB --- 2007-01-15 20:58:37 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 20:58:37 - cd /src TB --- 2007-01-15 20:58:37 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 20:58:37 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 21:04:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 21:04:51 - ERROR: failed to build lint kernel TB --- 2007-01-15 21:04:51 - tinderbox aborted TB --- 0.66 user 2.27 system 4243.00 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 21:50:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF69F16A47C for ; Mon, 15 Jan 2007 21:50:41 +0000 (UTC) (envelope-from spaceman@stonehenge.sk) Received: from otana.stonehenge.sk (otana.stonehenge.sk [82.208.39.177]) by mx1.freebsd.org (Postfix) with SMTP id 34D7A13C4EF for ; Mon, 15 Jan 2007 21:50:38 +0000 (UTC) (envelope-from spaceman@stonehenge.sk) Received: (qmail 46389 invoked by uid 1000); 15 Jan 2007 21:24:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otana.stonehenge.sk X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RECEIVED,NO_RELAYS autolearn=disabled version=3.1.7 Date: Mon, 15 Jan 2007 22:24:03 +0100 From: Varga Michal To: Andre Oppermann Message-ID: <20070115212403.GB1049@stonehenge.sk> References: <200701152055.18416.doconnor@gsoft.com.au> <20070115164034.GC74652@lor.one-eyed-alien.net> <45ABBFCC.3040204@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45ABBFCC.3040204@freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org, kde@freebsd.org Subject: Re: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 21:50:42 -0000 On Mon, 2007-Jan-15 at 18:54:20 +0100, Andre Oppermann wrote: > Brooks Davis wrote: > >On Mon, Jan 15, 2007 at 08:55:07PM +1030, Daniel O'Connor wrote: > > > >>Hi, > >>I recently updated my machine to -current, however I can nolonger unlock > >>my desktop - I have to manually kill the kdesktop_lock process. > >> > >>I've recompiled kdebase but it had no effect. I plan to try kdelibs soon. > >> > >>Is this a known issue? > > > > > >The problem is apparently due to breaking of sending zerobyte messages > >over certain types of sockets. I think peter has a patch that works > >around it in KDE, but I'm not sure it's available anywhere. > > I have a fix in the works. > Just for the record, this problem doesn't seem to be KDE-specific. I'm experiencing the same behaviour under Gnome 2.16 - xscreensaver isn't able to correctly close itself and without manually killing the proces, you are not able to return to the desktop. - i386 FreeBSD 7.0-CURRENT #0: Mon Jan 15 06:48:57 CET 2007 - gnome2-2.16.2 - xscreensaver-gnome-hacks-4.24_1 Sending a sigterm to gnome-screensaver does the trick. m. From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 22:16:15 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5ADDF16A417; Mon, 15 Jan 2007 22:16:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 329AA13C478; Mon, 15 Jan 2007 22:16:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FMGE6M094370; Mon, 15 Jan 2007 17:16:14 -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.8/8.13.8) with ESMTP id l0FMGE6W058244; Mon, 15 Jan 2007 17:16:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 148E473034; Mon, 15 Jan 2007 17:16:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115221614.148E473034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 17:16:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 22:16:15 -0000 TB --- 2007-01-15 21:04:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 21:04:51 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-15 21:04:52 - cleaning the object tree TB --- 2007-01-15 21:05:27 - checking out the source tree TB --- 2007-01-15 21:05:27 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-15 21:05:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 21:13:14 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 21:13:14 - cd /src TB --- 2007-01-15 21:13:14 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 21:13:16 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 22:08:53 UTC 2007 TB --- 2007-01-15 22:08:53 - generating LINT kernel config TB --- 2007-01-15 22:08:53 - cd /src/sys/sun4v/conf TB --- 2007-01-15 22:08:53 - /usr/bin/make -B LINT TB --- 2007-01-15 22:08:53 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 22:08:53 - cd /src TB --- 2007-01-15 22:08:53 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 22:08:53 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 22:16:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 22:16:13 - ERROR: failed to build lint kernel TB --- 2007-01-15 22:16:13 - tinderbox aborted TB --- 0.51 user 1.78 system 4281.76 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 22:16:36 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A9F16A585; Mon, 15 Jan 2007 22:16:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B8BFF13C4D9; Mon, 15 Jan 2007 22:16:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FMGZZ5094403; Mon, 15 Jan 2007 17:16:35 -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.8/8.13.8) with ESMTP id l0FMGY1O058608; Mon, 15 Jan 2007 17:16:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E9C6073034; Mon, 15 Jan 2007 17:16:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115221634.E9C6073034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 17:16:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 22:16:36 -0000 TB --- 2007-01-15 21:01:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 21:01:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-01-15 21:01:22 - cleaning the object tree TB --- 2007-01-15 21:01:51 - checking out the source tree TB --- 2007-01-15 21:01:51 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-01-15 21:01:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 21:13:14 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 21:13:14 - cd /src TB --- 2007-01-15 21:13:14 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 21:13:16 UTC 2007 >>> 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 >>> World build completed on Mon Jan 15 22:08:58 UTC 2007 TB --- 2007-01-15 22:08:58 - generating LINT kernel config TB --- 2007-01-15 22:08:58 - cd /src/sys/sparc64/conf TB --- 2007-01-15 22:08:58 - /usr/bin/make -B LINT TB --- 2007-01-15 22:08:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 22:08:59 - cd /src TB --- 2007-01-15 22:08:59 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 22:08:59 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 22:16:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 22:16:34 - ERROR: failed to build lint kernel TB --- 2007-01-15 22:16:34 - tinderbox aborted TB --- 0.56 user 1.78 system 4512.13 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jan 15 23:55:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2751D16A536; Mon, 15 Jan 2007 23:55:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E151F13C455; Mon, 15 Jan 2007 23:55:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0FNtYkw003914; Mon, 15 Jan 2007 18:55:34 -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.8/8.13.8) with ESMTP id l0FNtXKf042968; Mon, 15 Jan 2007 18:55:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9B24973034; Mon, 15 Jan 2007 18:55:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070115235533.9B24973034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 18:55:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 23:55:35 -0000 TB --- 2007-01-15 22:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 22:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-15 22:20:00 - cleaning the object tree TB --- 2007-01-15 22:20:41 - checking out the source tree TB --- 2007-01-15 22:20:41 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-15 22:20:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 22:31:00 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 22:31:00 - cd /src TB --- 2007-01-15 22:31:00 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 22:31:01 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Jan 15 23:47:09 UTC 2007 TB --- 2007-01-15 23:47:09 - generating LINT kernel config TB --- 2007-01-15 23:47:09 - cd /src/sys/amd64/conf TB --- 2007-01-15 23:47:09 - /usr/bin/make -B LINT TB --- 2007-01-15 23:47:09 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-15 23:47:09 - cd /src TB --- 2007-01-15 23:47:09 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 15 23:47:09 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-15 23:55:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-15 23:55:33 - ERROR: failed to build lint kernel TB --- 2007-01-15 23:55:33 - tinderbox aborted TB --- 0.80 user 2.63 system 5732.88 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 00:40:39 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D46BA16A416; Tue, 16 Jan 2007 00:40:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEED13C471; Tue, 16 Jan 2007 00:40:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0G0edxM061442; Mon, 15 Jan 2007 19:40:39 -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.8/8.13.8) with ESMTP id l0G0ecQb098648; Mon, 15 Jan 2007 19:40:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D3BE673034; Mon, 15 Jan 2007 19:40:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070116004038.D3BE673034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 19:40:38 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 00:40:40 -0000 TB --- 2007-01-15 23:27:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 23:27:18 - starting HEAD tinderbox run for i386/i386 TB --- 2007-01-15 23:27:19 - cleaning the object tree TB --- 2007-01-15 23:27:44 - checking out the source tree TB --- 2007-01-15 23:27:44 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-01-15 23:27:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-15 23:36:04 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-15 23:36:04 - cd /src TB --- 2007-01-15 23:36:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 15 23:36:05 UTC 2007 >>> 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 >>> World build completed on Tue Jan 16 00:31:37 UTC 2007 TB --- 2007-01-16 00:31:37 - generating LINT kernel config TB --- 2007-01-16 00:31:37 - cd /src/sys/i386/conf TB --- 2007-01-16 00:31:37 - /usr/bin/make -B LINT TB --- 2007-01-16 00:31:37 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-16 00:31:37 - cd /src TB --- 2007-01-16 00:31:37 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 16 00:31:37 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-16 00:40:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-16 00:40:38 - ERROR: failed to build lint kernel TB --- 2007-01-16 00:40:38 - tinderbox aborted TB --- 0.66 user 1.79 system 4399.35 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 01:07:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4BA516A412; Tue, 16 Jan 2007 01:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 99DE813C459; Tue, 16 Jan 2007 01:07:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0G173XH008307; Mon, 15 Jan 2007 20:07:03 -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.8/8.13.8) with ESMTP id l0G173nl021164; Mon, 15 Jan 2007 20:07:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4237673034; Mon, 15 Jan 2007 20:07:03 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070116010703.4237673034@freebsd-current.sentex.ca> Date: Mon, 15 Jan 2007 20:07:03 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 01:07:07 -0000 TB --- 2007-01-15 23:55:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-15 23:55:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-01-15 23:55:33 - cleaning the object tree TB --- 2007-01-15 23:55:59 - checking out the source tree TB --- 2007-01-15 23:55:59 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-01-15 23:55:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-16 00:06:45 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-16 00:06:45 - cd /src TB --- 2007-01-16 00:06:45 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 16 00:06:46 UTC 2007 >>> 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 >>> World build completed on Tue Jan 16 00:59:51 UTC 2007 TB --- 2007-01-16 00:59:51 - generating LINT kernel config TB --- 2007-01-16 00:59:51 - cd /src/sys/pc98/conf TB --- 2007-01-16 00:59:51 - /usr/bin/make -B LINT TB --- 2007-01-16 00:59:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-16 00:59:51 - cd /src TB --- 2007-01-16 00:59:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 16 00:59:51 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_resource.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_rwlock.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sema.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_shutdown.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_sig.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/kern/kern_subr.c /src/sys/kern/kern_subr.c: In function `hashinit_flags': /src/sys/kern/kern_subr.c:375: warning: suggest parentheses around comparison in operand of | *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-16 01:07:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-16 01:07:03 - ERROR: failed to build lint kernel TB --- 2007-01-16 01:07:03 - tinderbox aborted TB --- 0.49 user 1.98 system 4289.31 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 08:10:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09EC616A412 for ; Tue, 16 Jan 2007 08:10:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 8A6A413C45A for ; Tue, 16 Jan 2007 08:10:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13055 invoked by uid 399); 16 Jan 2007 08:10:01 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jan 2007 08:10:01 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45AC8856.1090707@FreeBSD.org> Date: Tue, 16 Jan 2007 00:09:58 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Andre Oppermann References: <200701152055.18416.doconnor@gsoft.com.au> <20070115164034.GC74652@lor.one-eyed-alien.net> <45ABBFCC.3040204@freebsd.org> In-Reply-To: <45ABBFCC.3040204@freebsd.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't unlock desktop after updating to recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 08:10:06 -0000 Andre Oppermann wrote: > Brooks Davis wrote: >> On Mon, Jan 15, 2007 at 08:55:07PM +1030, Daniel O'Connor wrote: >> >>> Hi, >>> I recently updated my machine to -current, however I can nolonger >>> unlock my desktop - I have to manually kill the kdesktop_lock process. >>> >>> I've recompiled kdebase but it had no effect. I plan to try kdelibs >>> soon. >>> >>> Is this a known issue? >> >> >> The problem is apparently due to breaking of sending zerobyte messages >> over certain types of sockets. I think peter has a patch that works >> around it in KDE, but I'm not sure it's available anywhere. > > I have a fix in the works. I've also been bitten by this with -current + windowmaker + xscreensaver, so if you need another guinea pig, let me know. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 16:51:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 513CE16A40F for ; Tue, 16 Jan 2007 16:51:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id C8A3213C467 for ; Tue, 16 Jan 2007 16:51:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2441848nfc for ; Tue, 16 Jan 2007 08:51:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MJqDbKN+1J/WogPf7CmW4GhVSTNysIIcc1+XzrrhnTaHCYZVp4ULcE3cbHTqJgDNOn+nXmi9dXL4WbTu2rtAW9KA/zYDlZx3wUhjDbiCvlvMFy8NWwfaOppMeoiP99pqKTZishA82AVQ5L+6+Eneaxh0zZ4jvWG193+laGJDuJY= Received: by 10.49.80.12 with SMTP id h12mr3001101nfl.1168966264243; Tue, 16 Jan 2007 08:51:04 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 08:51:03 -0800 (PST) Message-ID: <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> Date: Tue, 16 Jan 2007 17:51:03 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> X-Google-Sender-Auth: b8864b2be4837ff1 Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 16:51:13 -0000 2006/7/28, Attilio Rao : > > After some thinking, I think it's better using init/fini methods > (since they hide the sizeof(struct turnstile) with size parameter). > > Feedbacks and comments are welcome: > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff [CC'ed all the interested people] Even if a long time is passed I did some benchmarks based on ebizzy tool. This program claims to reproduce a real httpd server behaviour and is used into the Linux world for benchmarks, AFAIK. I think that results of the comparison on this patch is very interesting, and I think it worths a commit :) I think that results can be even better on a Xeon machine (I had no chance to reproduce this on some of these). (Results taken in consideration have been measured after some starts, in order to minimize caching differences). The patch: http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff The benchmark results: http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark The kernel options file: http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT For any information, comment, etc. please feel free to contact me. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 18:30:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BD6916A47E for ; Tue, 16 Jan 2007 18:30:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7D813C4BC for ; Tue, 16 Jan 2007 18:30:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 16 Jan 2007 10:10:43 -0800 Received: from [10.251.23.190] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 69794125B2B; Tue, 16 Jan 2007 10:30:11 -0800 (PST) Message-ID: <45AD19B2.6010806@elischer.org> Date: Tue, 16 Jan 2007 10:30:10 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Attilio Rao References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> In-Reply-To: <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , Kip Macy , Suleiman Souhlal , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 18:30:19 -0000 Attilio Rao wrote: > 2006/7/28, Attilio Rao : >> >> After some thinking, I think it's better using init/fini methods >> (since they hide the sizeof(struct turnstile) with size parameter). >> >> Feedbacks and comments are welcome: >> http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > [CC'ed all the interested people] > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > This program claims to reproduce a real httpd server behaviour and is > used into the Linux world for benchmarks, AFAIK. > I think that results of the comparison on this patch is very > interesting, and I think it worths a commit :) > I think that results can be even better on a Xeon machine (I had no > chance to reproduce this on some of these). > (Results taken in consideration have been measured after some starts, > in order to minimize caching differences). > > The patch: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > The benchmark results: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark those are very big differences! what does the benchmark actually measure? > > The kernel options file: > http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT > > For any information, comment, etc. please feel free to contact me. > > Attilio > > From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 18:39:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 452F216A4A7 for ; Tue, 16 Jan 2007 18:39:37 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id C30A213C45E for ; Tue, 16 Jan 2007 18:39:36 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2474464nfc for ; Tue, 16 Jan 2007 10:39:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UTl/lgoYGJ2QtrSspPNXs2Pu6MP12LIvOFcrKSpTvxH0QVu2e/wNYLuTKdn29pZXOskpwJmLNZt9vS77apI5Tv2dZJsIT+2/1wIrG7AAP7fDeusQk9Tz0EzhpCqTkCctUUWYI4dl31Z57JjH8GH+zQn64pRIB+DdOvAjpDpT9LY= Received: by 10.48.245.17 with SMTP id s17mr6333351nfh.1168972769649; Tue, 16 Jan 2007 10:39:29 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 10:39:29 -0800 (PST) Message-ID: <3bbf2fe10701161039g4b1572a1qf8b97f2389b31a0e@mail.gmail.com> Date: Tue, 16 Jan 2007 19:39:29 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Julian Elischer" In-Reply-To: <45AD19B2.6010806@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <45AD19B2.6010806@elischer.org> X-Google-Sender-Auth: dcfd126d2e293cf6 Cc: Kip Macy , freebsd-current@freebsd.org, Pawel Jakub Dawidek , Suleiman Souhlal , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 18:39:37 -0000 2007/1/16, Julian Elischer : > Attilio Rao wrote: > > 2006/7/28, Attilio Rao : > >> > >> After some thinking, I think it's better using init/fini methods > >> (since they hide the sizeof(struct turnstile) with size parameter). > >> > >> Feedbacks and comments are welcome: > >> http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > [CC'ed all the interested people] > > > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > > This program claims to reproduce a real httpd server behaviour and is > > used into the Linux world for benchmarks, AFAIK. > > I think that results of the comparison on this patch is very > > interesting, and I think it worths a commit :) > > I think that results can be even better on a Xeon machine (I had no > > chance to reproduce this on some of these). > > (Results taken in consideration have been measured after some starts, > > in order to minimize caching differences). > > > > The patch: > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > The benchmark results: > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark > > those are very big differences! > what does the benchmark actually measure? just time ./ebizzy (which create a lot of contention inside the kernel). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 19:02:47 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF32316A47C for ; Tue, 16 Jan 2007 19:02:47 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA1613C45B for ; Tue, 16 Jan 2007 19:02:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2481077nfc for ; Tue, 16 Jan 2007 11:02:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YZE0tLgPRXi+hfCE3w1kfRdpT8GDWp3BAzGffR6YFMLIM34rfy7wI6OrtglSL0Kj/GiQVHkwoFuumYaaNBZjNeW1r0D9xNsLUCro2NCqmZfNADKCoyZBLqsosSDLwe29d0qhmMJD05HcZ4Ign0pFMmEwBEPRGRlAQKJ/RpiJzTo= Received: by 10.49.80.12 with SMTP id h12mr3173846nfl.1168974160335; Tue, 16 Jan 2007 11:02:40 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 11:02:40 -0800 (PST) Message-ID: <3bbf2fe10701161102w5a094dfge7faf641ab1a0425@mail.gmail.com> Date: Tue, 16 Jan 2007 20:02:40 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Nick Evans" In-Reply-To: <20070116131836.0681a51d@pleiades.nextvenue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116122925.5cdb1ded@pleiades.nextvenue.com> <3bbf2fe10701160951x1cb4cd75pd843b453a8f4a96@mail.gmail.com> <20070116131836.0681a51d@pleiades.nextvenue.com> X-Google-Sender-Auth: 2259c4ab2e877946 Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 19:02:48 -0000 2007/1/16, Nick Evans : > On Tue, 16 Jan 2007 18:51:30 +0100 > "Attilio Rao" wrote: > > > 2007/1/16, Nick Evans : > > > On Tue, 16 Jan 2007 17:51:03 +0100 > > > "Attilio Rao" wrote: > > > > > > > 2006/7/28, Attilio Rao : > > > > > > > > > > After some thinking, I think it's better using init/fini methods > > > > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > > > > > > > Feedbacks and comments are welcome: > > > > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > > > > > [CC'ed all the interested people] > > > > > > > > Even if a long time is passed I did some benchmarks based on ebizzy > > > > tool. This program claims to reproduce a real httpd server behaviour > > > > and is used into the Linux world for benchmarks, AFAIK. > > > > I think that results of the comparison on this patch is very > > > > interesting, and I think it worths a commit :) > > > > I think that results can be even better on a Xeon machine (I had no > > > > chance to reproduce this on some of these). > > > > (Results taken in consideration have been measured after some starts, > > > > in order to minimize caching differences). > > > > > > > > The patch: > > > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > > > > > The benchmark results: > > > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark > > > > > > > > The kernel options file: > > > > http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT > > > > > > > > For any information, comment, etc. please feel free to contact me. > > > > > > > > Attilio > > > > > > > > > > > > -- > > > > Peace can only be achieved by understanding - A. Einstein > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > > Attilio, > > > > > > What class of Xeon do you need this tested on, P3 or the newer P4+ stuff? > > > I have a few systems here I can test this on including a quad P3-Xeon box > > > that I've been testing Jeff's ULE 2.0 on. Do you have specific extra test > > > points or are the before and after for the (non)preemption cases > > > sufficient? I can also give you access to the systems if that is easier. > > > > Hi Nick, > > thanks a lot for responsivness and help. > > I think that P3 Xeon alredy should show some speedup, in particular I > > would see some tests on the P3-Xeon quad. > > It would be enough reproduce the test I did (using the same options > > file and starting ebizzy for 1-2 times before the results gathering). > > I hope you are suitable for doing this benchmarks alone (FreeBSD + > > university + job don't leave me too much time ATM :(( ). > > > > Thanks a lot for your efforts, > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > > > Yea, we should be able to handle benchmarking this if you can help me > through the first hurdle. Do you have a version that compiles cleanly on > -CURRENT? The version I dug up off lkml via google complains: > > root@current[13:10]# make > gcc -Wall -lpthread -o ebizzy ebizzy.c > In file included from ebizzy.c:43: > /usr/include/malloc.h:3:2: #error " has been replaced by " > ebizzy.c: In function `read_options': > ebizzy.c:212: warning: implicit declaration of function `mallopt' > ebizzy.c:212: error: `M_MMAP_MAX' undeclared (first use in this function) > ebizzy.c:212: error: (Each undeclared identifier is reported only once > ebizzy.c:212: error: for each function it appears in.) > ebizzy.c: In function `alloc_mem': > ebizzy.c:224: error: `MAP_ANONYMOUS' undeclared (first use in this function) > *** Error code 1 > > Stop in /root/ebizzy. > > > I didn't see an updated version listed in our archives anywhere. Since ebizzy doesn't compile natively on FreeBSD try this patch (it disables the -m option, but it doesn't matter currently): http://users.gufi.org/~rookie/works/patches/ts-sq/ebizzy.diff Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:27:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A668916A40F; Tue, 16 Jan 2007 20:27:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 1080613C519; Tue, 16 Jan 2007 20:27:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0GKR5Hp046593; Tue, 16 Jan 2007 15:27:06 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 16 Jan 2007 14:38:51 -0500 User-Agent: KMail/1.9.1 References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> In-Reply-To: <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200701161438.52481.jhb@freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 16 Jan 2007 15:27:06 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2457/Tue Jan 16 06:53:04 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:27:20 -0000 On Tuesday 16 January 2007 11:51, Attilio Rao wrote: > 2006/7/28, Attilio Rao : > > > > After some thinking, I think it's better using init/fini methods > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > Feedbacks and comments are welcome: > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > [CC'ed all the interested people] > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > This program claims to reproduce a real httpd server behaviour and is > used into the Linux world for benchmarks, AFAIK. > I think that results of the comparison on this patch is very > interesting, and I think it worths a commit :) > I think that results can be even better on a Xeon machine (I had no > chance to reproduce this on some of these). > (Results taken in consideration have been measured after some starts, > in order to minimize caching differences). > > The patch: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff Looks good. Some minor nits are that in subr_turnstile.c in the comment I would say "a turnstile is allocated" rather than "a turnstile is got from a specific UMA zone" as it reads a little bit clearer. Also, I would say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 and amd64 rather than adding a new UMA_ALIGN_SYNC? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:27:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D65216A47E for ; Tue, 16 Jan 2007 20:27:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id AAA8713C51B for ; Tue, 16 Jan 2007 20:27:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0GKR5Hq046593; Tue, 16 Jan 2007 15:27:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Denis Shaposhnikov Date: Tue, 16 Jan 2007 14:45:43 -0500 User-Agent: KMail/1.9.1 References: <200611152004.kAFK4vfe058983@repoman.freebsd.org> <200701111126.10095.jhb@freebsd.org> <87r6twiyc5.fsf@neva.vlink.ru> In-Reply-To: <87r6twiyc5.fsf@neva.vlink.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701161445.43950.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 16 Jan 2007 15:27:16 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2457/Tue Jan 16 06:53:04 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/bce if_bce.c src/sys/dev/em if_em.c if_em.h src/sys/dev/mpt mpt.h mpt_pci.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:27:21 -0000 On Monday 15 January 2007 01:43, Denis Shaposhnikov wrote: > >>>>> "John" == John Baldwin writes: > > John> Try this and see if it disables MSI for you automatically: > > John> Index: pci.c > John> =================================================================== > John> RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v retrieving revision > John> 1.331 diff -u -r1.331 pci.c > John> --- pci.c 28 Dec 2006 06:14:42 -0000 1.331 > John> +++ pci.c 11 Jan 2007 16:25:20 -0000 > > I've applied the patch and sysctl hw.pci.enable_msi still show "1" but > no system freeze like boot with MSI disabled. > > BTW, I have watchdog timeouts and panic with em(4) on next to > hosts. Disabling MSI fixes it. Here is pciconf -l: I've blacklisted these for now, thanks. These are both non-PCI-express desktop chipsets. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:34:29 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92EAC16A47C; Tue, 16 Jan 2007 20:34:29 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3240013C428; Tue, 16 Jan 2007 20:34:29 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id l0GKOB4r077462; Tue, 16 Jan 2007 12:24:11 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> Date: Tue, 16 Jan 2007 12:24:11 -0800 (PST) From: John Polstra To: Attilio Rao X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (blake.polstra.com [64.81.189.66]); Tue, 16 Jan 2007 12:24:14 -0800 (PST) Cc: Pawel Jakub Dawidek , Kip Macy , Suleiman Souhlal , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:34:29 -0000 On 16-Jan-2007 Attilio Rao wrote: > The patch: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > The benchmark results: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark > > The kernel options file: > http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT This is good stuff! I tried your patch on a performance-critical system that I've been working on. Without going into a lot of detail, it's a bunch of in-kernel code that blasts packets back and forth between pairs of gigabit interfaces. Userland isn't involved at all. Running 4 gigabit ports in this way on a Dell 1950 with 4 CPU cores running at 3.0 GHz, I got about 4% better performance (in terms of packets per second) using your patch. That's a pretty good improvement, considering that the design makes some effort to avoid lock contention. John From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:36:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08CDE16A4AB for ; Tue, 16 Jan 2007 20:36:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 87CEF13C46A for ; Tue, 16 Jan 2007 20:36:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2508984nfc for ; Tue, 16 Jan 2007 12:36:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=e4X8wT0Si9S6zAUEmRhUhH4qfZ1Yrrnfh2/pl8CiZEo1EGlRNGR6Ztl2vrfNN9BzjNA4/KP1e17TRckRRZKtyYRbmUOoHGR0UopQ33RGYD5ii/x8vwMob4UAWnrV5uHzPTacdYyE7q6OcHG4D4K1yZx3qQce59Q0Yo3oDA8Llvg= Received: by 10.49.19.5 with SMTP id w5mr6498912nfi.1168979776259; Tue, 16 Jan 2007 12:36:16 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 12:36:16 -0800 (PST) Message-ID: <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> Date: Tue, 16 Jan 2007 21:36:16 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200701161438.52481.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <200701161438.52481.jhb@freebsd.org> X-Google-Sender-Auth: 1ee207f6857c0685 Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:36:22 -0000 2007/1/16, John Baldwin : > On Tuesday 16 January 2007 11:51, Attilio Rao wrote: > > 2006/7/28, Attilio Rao : > > > > > > After some thinking, I think it's better using init/fini methods > > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > > > Feedbacks and comments are welcome: > > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > [CC'ed all the interested people] > > > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > > This program claims to reproduce a real httpd server behaviour and is > > used into the Linux world for benchmarks, AFAIK. > > I think that results of the comparison on this patch is very > > interesting, and I think it worths a commit :) > > I think that results can be even better on a Xeon machine (I had no > > chance to reproduce this on some of these). > > (Results taken in consideration have been measured after some starts, > > in order to minimize caching differences). > > > > The patch: > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > Looks good. Some minor nits are that in subr_turnstile.c in the comment I > would say "a turnstile is allocated" rather than "a turnstile is got from a > specific UMA zone" as it reads a little bit clearer. Also, I would > say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, > why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 > and amd64 rather than adding a new UMA_ALIGN_SYNC? I was thinking that in this way anyone who wants to replace the syncronizing primitive boundary to an appropriate value can do it. I just used UMA_ALIGN_CACHE as default value beacause I don't know the better boundary (for syncronizing primitives) for other arches. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:43:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7210816A40F; Tue, 16 Jan 2007 20:43:15 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id 111EA13C4A7; Tue, 16 Jan 2007 20:43:14 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id l0GKhEZd077880; Tue, 16 Jan 2007 12:43:14 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200701161438.52481.jhb@freebsd.org> Date: Tue, 16 Jan 2007 12:43:14 -0800 (PST) From: John Polstra To: John Baldwin X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (blake.polstra.com [64.81.189.66]); Tue, 16 Jan 2007 12:43:14 -0800 (PST) Cc: Pawel Jakub Dawidek , Kip Macy , Suleiman Souhlal , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:43:15 -0000 On 16-Jan-2007 John Baldwin wrote: > On Tuesday 16 January 2007 11:51, Attilio Rao wrote: >> The patch: >> http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > Looks good. Some minor nits are that in subr_turnstile.c in the comment I > would say "a turnstile is allocated" rather than "a turnstile is got from a > specific UMA zone" as it reads a little bit clearer. Also, I would > say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, > why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 > and amd64 rather than adding a new UMA_ALIGN_SYNC? Also, instead of calling bzero in the _init functions, I think you could pass UMA_ZONE_ZINIT to uma_zcreate. John From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 20:52:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B36D16A412 for ; Tue, 16 Jan 2007 20:52:05 +0000 (UTC) (envelope-from sepotvin@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 654EB13C448 for ; Tue, 16 Jan 2007 20:52:05 +0000 (UTC) (envelope-from sepotvin@videotron.ca) Received: from [10.0.0.136] ([67.70.237.74]) by VL-MO-MR003.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPA id <0JBZ005VD8IRH990@VL-MO-MR003.ip.videotron.ca> for freebsd-current@freebsd.org; Tue, 16 Jan 2007 14:52:04 -0500 (EST) Date: Wed, 17 Jan 2007 03:52:03 +0800 From: "Stephane E. Potvin" In-reply-to: <499c70c0701080850q72eac288h50b8265fe4e62a53@mail.gmail.com> To: Abdullah Al-Marrie Message-id: <45AD2CE3.7040304@videotron.ca> Organization: TelcoBridges Inc. MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <499c70c0701080850q72eac288h50b8265fe4e62a53@mail.gmail.com> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) Cc: freebsd-current@freebsd.org Subject: Re: cpu0: Unable to find _CST method X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 20:52:05 -0000 Abdullah Al-Marrie wrote: > Hello, > > I have strange msg in the dmesg > > cpu0: Unable to find _CST method > [dmesg removed] Hi Abdullah, The warning you are seeing (along with the following line: cpu0: Switching to generic Cx mode) is part of the recent upgrade to the acpi cpu driver to enable higher Cx modes for SMP systems. The warning just indicates that you have a multi-cpu system but that your ACPI AML didn't provide a _CST method. This is a harmless warning and the cpu driver will revert to using the previous method to change the Cx states). This will probably limit you to the C1 state, ymmv. You might want to try to update to a newer BIOS version, which might include the _CST method. Regards, Steph From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:00:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA63916A4E5; Tue, 16 Jan 2007 21:00:28 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from relay.talkpoint.com (pobox.talkpoint.com [204.141.15.158]) by mx1.freebsd.org (Postfix) with ESMTP id 79FD313C43E; Tue, 16 Jan 2007 21:00:05 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from ASSP-nospam ([127.0.0.1]) by relay.talkpoint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Jan 2007 15:42:58 -0500 Received: from 204.141.15.136 ([204.141.15.136] helo=postal.talkpoint.com) by ASSP-nospam ; 16 Jan 07 20:42:58 -0000 Received: from pleiades.nextvenue.com ([204.141.15.194]) by postal.talkpoint.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZN3V7H6Q; Tue, 16 Jan 2007 15:42:58 -0500 Date: Tue, 16 Jan 2007 15:42:58 -0500 From: Nick Evans To: "Attilio Rao" Message-ID: <20070116154258.568e1aaf@pleiades.nextvenue.com> In-Reply-To: <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 20:42:58.0756 (UTC) FILETIME=[E8495040:01C739AE] Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:00:28 -0000 On Tue, 16 Jan 2007 17:51:03 +0100 "Attilio Rao" wrote: > 2006/7/28, Attilio Rao : > > > > After some thinking, I think it's better using init/fini methods > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > Feedbacks and comments are welcome: > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > [CC'ed all the interested people] > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > This program claims to reproduce a real httpd server behaviour and is > used into the Linux world for benchmarks, AFAIK. > I think that results of the comparison on this patch is very > interesting, and I think it worths a commit :) > I think that results can be even better on a Xeon machine (I had no > chance to reproduce this on some of these). > (Results taken in consideration have been measured after some starts, > in order to minimize caching differences). > > The patch: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > The benchmark results: > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark > > The kernel options file: > http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT > > For any information, comment, etc. please feel free to contact me. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Some preliminary results: PREEMPTION: 4BSD, Quad P3-Xeon, 2GB ram pre-patch 1. 176.36 real 703.75 user 0.01 sys 2. 176.73 real 704.34 user 0.03 sys 3. 176.49 real 703.72 user 0.04 sys 4. 175.81 real 701.36 user 0.03 sys 5. 176.57 real 700.98 user 0.02 sys post-patch 1. 179.17 real 714.39 user 0.01 sys 2. 178.33 real 711.50 user 0.04 sys 3. 178.32 real 711.04 user 0.03 sys 4. 177.34 real 707.51 user 0.03 sys 5. 178.25 real 710.17 user 0.03 sys From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:00:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4499416A62A for ; Tue, 16 Jan 2007 21:00:59 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id ADA0D13C4B8 for ; Tue, 16 Jan 2007 21:00:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so2516008nfc for ; Tue, 16 Jan 2007 13:00:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Q12o8UA/Wy2JUq7tjb8PCVX9cKBUmeqIUnn6w8TePJo3cO79yjdceWit2T3/M4yQd40PLgKybfnEpYu0Tebz+NCxmiieBdZZdkDqDqC6L/RafyCkVhJJhFujmHTL9T1L2sFmrPUiw7K3ie/Um0jxgr5dv8SzeUD2OlEKEmlyEGE= Received: by 10.49.27.17 with SMTP id e17mr5583403nfj.1168981254082; Tue, 16 Jan 2007 13:00:54 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 13:00:54 -0800 (PST) Message-ID: <3bbf2fe10701161300jc53b707h408fc0848767511f@mail.gmail.com> Date: Tue, 16 Jan 2007 22:00:54 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Polstra" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701161438.52481.jhb@freebsd.org> X-Google-Sender-Auth: 89b7436090da4470 Cc: Pawel Jakub Dawidek , Kip Macy , Suleiman Souhlal , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:00:59 -0000 2007/1/16, John Polstra : > On 16-Jan-2007 John Baldwin wrote: > > On Tuesday 16 January 2007 11:51, Attilio Rao wrote: > >> The patch: > >> http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > Looks good. Some minor nits are that in subr_turnstile.c in the comment I > > would say "a turnstile is allocated" rather than "a turnstile is got from a > > specific UMA zone" as it reads a little bit clearer. Also, I would > > say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, > > why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 > > and amd64 rather than adding a new UMA_ALIGN_SYNC? > > Also, instead of calling bzero in the _init functions, I think you > could pass UMA_ZONE_ZINIT to uma_zcreate. Since it doesn't seem to be documented, it automatically zeros all the initializations or just the first one? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:10:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF31716A58C; Tue, 16 Jan 2007 21:10:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6E46013C4A6; Tue, 16 Jan 2007 21:10:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0GLA1MB047029; Tue, 16 Jan 2007 16:10:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 16 Jan 2007 16:05:21 -0500 User-Agent: KMail/1.9.1 References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <200701161438.52481.jhb@freebsd.org> <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> In-Reply-To: <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701161605.22394.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 16 Jan 2007 16:10:14 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2457/Tue Jan 16 06:53:04 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:10:23 -0000 On Tuesday 16 January 2007 15:36, Attilio Rao wrote: > 2007/1/16, John Baldwin : > > On Tuesday 16 January 2007 11:51, Attilio Rao wrote: > > > 2006/7/28, Attilio Rao : > > > > > > > > After some thinking, I think it's better using init/fini methods > > > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > > > > > Feedbacks and comments are welcome: > > > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > > > [CC'ed all the interested people] > > > > > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > > > This program claims to reproduce a real httpd server behaviour and is > > > used into the Linux world for benchmarks, AFAIK. > > > I think that results of the comparison on this patch is very > > > interesting, and I think it worths a commit :) > > > I think that results can be even better on a Xeon machine (I had no > > > chance to reproduce this on some of these). > > > (Results taken in consideration have been measured after some starts, > > > in order to minimize caching differences). > > > > > > The patch: > > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > Looks good. Some minor nits are that in subr_turnstile.c in the comment I > > would say "a turnstile is allocated" rather than "a turnstile is got from a > > specific UMA zone" as it reads a little bit clearer. Also, I would > > say "Allocate a" rather than "Get a" for the two _alloc() functions. Also, > > why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386 > > and amd64 rather than adding a new UMA_ALIGN_SYNC? > > I was thinking that in this way anyone who wants to replace the > syncronizing primitive boundary to an appropriate value can do it. > I just used UMA_ALIGN_CACHE as default value beacause I don't know the > better boundary (for syncronizing primitives) for other arches. Is there a good reason to not cache-align synch primitives? That is, why would an arch not use cache-align? Also, is there a reason to not update UMA_ALIGN_CACHE on x86? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:19:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9830316A47C; Tue, 16 Jan 2007 21:19:15 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 32BEC13C4B8; Tue, 16 Jan 2007 21:19:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0GLJ8j9067886; Tue, 16 Jan 2007 14:19:13 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45AD4148.90002@samsco.org> Date: Tue, 16 Jan 2007 14:19:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: John Baldwin References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <200701161438.52481.jhb@freebsd.org> <3bbf2fe10701161236s48e6cc16p99c8c38c1d7becde@mail.gmail.com> <200701161605.22394.jhb@freebsd.org> In-Reply-To: <200701161605.22394.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 16 Jan 2007 14:19:13 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Pawel Jakub Dawidek , Kip Macy , Suleiman Souhlal , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:19:15 -0000 John Baldwin wrote: > On Tuesday 16 January 2007 15:36, Attilio Rao wrote: >> 2007/1/16, John Baldwin : >>> On Tuesday 16 January 2007 11:51, Attilio Rao wrote: >>>> 2006/7/28, Attilio Rao : >>>>> After some thinking, I think it's better using init/fini methods >>>>> (since they hide the sizeof(struct turnstile) with size parameter). >>>>> >>>>> Feedbacks and comments are welcome: >>>>> http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff >>>> [CC'ed all the interested people] >>>> >>>> Even if a long time is passed I did some benchmarks based on ebizzy > tool. >>>> This program claims to reproduce a real httpd server behaviour and is >>>> used into the Linux world for benchmarks, AFAIK. >>>> I think that results of the comparison on this patch is very >>>> interesting, and I think it worths a commit :) >>>> I think that results can be even better on a Xeon machine (I had no >>>> chance to reproduce this on some of these). >>>> (Results taken in consideration have been measured after some starts, >>>> in order to minimize caching differences). >>>> >>>> The patch: >>>> http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff >>> Looks good. Some minor nits are that in subr_turnstile.c in the comment I >>> would say "a turnstile is allocated" rather than "a turnstile is got from > a >>> specific UMA zone" as it reads a little bit clearer. Also, I would >>> say "Allocate a" rather than "Get a" for the two _alloc() functions. > Also, >>> why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on > i386 >>> and amd64 rather than adding a new UMA_ALIGN_SYNC? >> I was thinking that in this way anyone who wants to replace the >> syncronizing primitive boundary to an appropriate value can do it. >> I just used UMA_ALIGN_CACHE as default value beacause I don't know the >> better boundary (for syncronizing primitives) for other arches. > > Is there a good reason to not cache-align synch primitives? That is, why > would an arch not use cache-align? Also, is there a reason to not update > UMA_ALIGN_CACHE on x86? > If you always cache-line-align them, that also addresses the Intel recommendation to always keep them from sharing cache lines. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:41:14 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D33F216A47C; Tue, 16 Jan 2007 21:41:14 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id 78EF713C4F9; Tue, 16 Jan 2007 21:41:14 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id l0GLfCa6078806; Tue, 16 Jan 2007 13:41:12 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3bbf2fe10701161300jc53b707h408fc0848767511f@mail.gmail.com> Date: Tue, 16 Jan 2007 13:41:12 -0800 (PST) From: John Polstra To: Attilio Rao X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (blake.polstra.com [64.81.189.66]); Tue, 16 Jan 2007 13:41:12 -0800 (PST) Cc: Kip Macy , freebsd-current@freebsd.org, Suleiman Souhlal , Pawel Jakub Dawidek , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:41:15 -0000 On 16-Jan-2007 Attilio Rao wrote: > 2007/1/16, John Polstra : >> Also, instead of calling bzero in the _init functions, I think you >> could pass UMA_ZONE_ZINIT to uma_zcreate. > > Since it doesn't seem to be documented, it automatically zeros all the > initializations or just the first one? It looks like it acts upon whole chunks of memory, just like the user _init function. But after unsuccessfully trying to wind my way through the UMA code for a few minutes, it's not totally clear to me whether or not UMA_ZONE_ZINIT overrides the user _init function entirely. Maybe somebody who has used it will clear up the confusion. John From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 21:55:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0522B16A415 for ; Tue, 16 Jan 2007 21:55:40 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9002913C448 for ; Tue, 16 Jan 2007 21:55:39 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1658135uge for ; Tue, 16 Jan 2007 13:55:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MkyNchNm1YRdR3U+I/6oZfrJv9PVpaOmlnklZxupmy4zhDqsAfTjSuVDVaa8UzoP/2IRMGbGtGAd9kiaqnazOXE22qMp5N/vj4CGyX7F+LDOxiRAaD7AcYzZXA8Nwv/EKShW2DCt2PS6uynJEGJ1vPcbCLSZjt85jz22QVpMN38= Received: by 10.82.139.17 with SMTP id m17mr1365704bud.1168984536548; Tue, 16 Jan 2007 13:55:36 -0800 (PST) Received: by 10.82.191.16 with HTTP; Tue, 16 Jan 2007 13:55:36 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 13:55:36 -0800 From: "Kip Macy" To: "Nick Evans" In-Reply-To: <20070116154258.568e1aaf@pleiades.nextvenue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> Cc: Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 21:55:40 -0000 x86 pre-P4 had 32-byte cache lines. Thus older processors will not benefit. -Kip On 1/16/07, Nick Evans wrote: > On Tue, 16 Jan 2007 17:51:03 +0100 > "Attilio Rao" wrote: > > > 2006/7/28, Attilio Rao : > > > > > > After some thinking, I think it's better using init/fini methods > > > (since they hide the sizeof(struct turnstile) with size parameter). > > > > > > Feedbacks and comments are welcome: > > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff > > > > [CC'ed all the interested people] > > > > Even if a long time is passed I did some benchmarks based on ebizzy tool. > > This program claims to reproduce a real httpd server behaviour and is > > used into the Linux world for benchmarks, AFAIK. > > I think that results of the comparison on this patch is very > > interesting, and I think it worths a commit :) > > I think that results can be even better on a Xeon machine (I had no > > chance to reproduce this on some of these). > > (Results taken in consideration have been measured after some starts, > > in order to minimize caching differences). > > > > The patch: > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff > > > > The benchmark results: > > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.benchmark > > > > The kernel options file: > > http://users.gufi.org/~rookie/works/patches/ts-sq/CURRENT > > > > For any information, comment, etc. please feel free to contact me. > > > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Some preliminary results: > > PREEMPTION: 4BSD, Quad P3-Xeon, 2GB ram > > pre-patch > > 1. 176.36 real 703.75 user 0.01 sys > 2. 176.73 real 704.34 user 0.03 sys > 3. 176.49 real 703.72 user 0.04 sys > 4. 175.81 real 701.36 user 0.03 sys > 5. 176.57 real 700.98 user 0.02 sys > > post-patch > > 1. 179.17 real 714.39 user 0.01 sys > 2. 178.33 real 711.50 user 0.04 sys > 3. 178.32 real 711.04 user 0.03 sys > 4. 177.34 real 707.51 user 0.03 sys > 5. 178.25 real 710.17 user 0.03 sys > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 22:06:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A620316A4A7 for ; Tue, 16 Jan 2007 22:06:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 35F7A13C4A6 for ; Tue, 16 Jan 2007 22:06:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H6wRn-0000cX-4B for freebsd-current@freebsd.org; Tue, 16 Jan 2007 23:06:27 +0100 Received: from 89-172-60-11.adsl.net.t-com.hr ([89.172.60.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Jan 2007 23:06:27 +0100 Received: from ivoras by 89-172-60-11.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Jan 2007 23:06:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 16 Jan 2007 23:09:30 +0100 Lines: 28 Message-ID: References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85FA9D62F9B27DE831EA7659" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-60-11.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: X-Enigmail-Version: 0.94.1.2 Sender: news Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 22:06:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85FA9D62F9B27DE831EA7659 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kip Macy wrote: > x86 pre-P4 had 32-byte cache lines. Thus older processors will not bene= fit. But it does seem to hurt the performance a bit - maybe it's time to add another CPU option like I586_CPU and I686_CPU? --------------enig85FA9D62F9B27DE831EA7659 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrU0nldnAQVacBcgRAuLyAKCfLnGOu+7S5pEpSSIjtGpF6x1DVQCeMbPo WTFiYzs6fOJ9bD1ucl3MoXA= =cJl2 -----END PGP SIGNATURE----- --------------enig85FA9D62F9B27DE831EA7659-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 22:25:08 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 329A116A558 for ; Tue, 16 Jan 2007 22:25:08 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id A20B613C441 for ; Tue, 16 Jan 2007 22:25:07 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1663977uge for ; Tue, 16 Jan 2007 14:25:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qPQWnL4/4RRCvudoZHOUzW6JnkRNyO7wdLL98jxX+P92M1Ei+7Ys8VjWWoMqk1T+YJannuYUjOajeW7ZWZsKTFkEYmUmLj0Ruf5IkblP3h4fCQ0CeKFBVJfrEZWSczrenbXCIZYsaiqN/+4qxNpf9aBKc7HirnGoVcxO/OFLNP8= Received: by 10.82.107.15 with SMTP id f15mr1381445buc.1168986306133; Tue, 16 Jan 2007 14:25:06 -0800 (PST) Received: by 10.82.191.16 with HTTP; Tue, 16 Jan 2007 14:25:06 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 14:25:06 -0800 From: "Kip Macy" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 22:25:08 -0000 On 1/16/07, Ivan Voras wrote: > Kip Macy wrote: > > x86 pre-P4 had 32-byte cache lines. Thus older processors will not benefit. > > But it does seem to hurt the performance a bit - maybe it's time to add > another CPU option like I586_CPU and I686_CPU? Unless there is a compelling reason not to do so, I think that that would be a good idea. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 22:52:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90E1A16A415; Tue, 16 Jan 2007 22:52:46 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0ED13C4A5; Tue, 16 Jan 2007 22:52:44 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.178.194] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1H6xAW3SKI-00057L; Tue, 16 Jan 2007 23:52:43 +0100 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Tue, 16 Jan 2007 23:52:37 +0100 User-Agent: KMail/1.9.5 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org Subject: FreeBSD Status Report Fourth Quarter 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 22:52:46 -0000 --Boundary-00=_3cVrFyZxpZGOqso Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_3cVrFyZxpZGOqso Content-Type: text/plain; charset="us-ascii"; name="report-oct-2006-dec-2006.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="report-oct-2006-dec-2006.txt" =46reeBSD Status Report Introduction Happy New Year. This Report covers the last quarter of a exciting year 2006 for FreeBSD development. FreeBSD 6.2 is finally out of the door and work towards FreeBSD 7.0 is gearing up. Some of the projects in this report will be part of that effort, others are already in the tree. Many projects need your help with testing and otherwise. Please see the "Open tasks" sections for more information. The BSD crowd will meet at AsiaBSDCon March 8-10th in Tokyo and a two day FreeBSD developer summit will be held at BSDCan May 16-19th in Ottawa. Finally, EuroBSDCon September 14-15th in Copenhagen is already looking for papers. Thanks to all the reporters for the excellent work! We hope you enjoy reading. _________________________________________________________________ Projects * FreeSBIE * iSCSI Initiator * Network Stack Virtualization * New USB Stack * Past and Future PR Closing Events * Porting ZFS to FreeBSD * TrustedBSD Audit * TrustedBSD MAC Framework * TrustedBSD priv(9) =46reeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Security Officer and Security Team * Release Engineering * The FreeBSD Foundation Network Infrastructure * Automatic TCP Send and Receive Socket Buffer Sizing * FAST_IPSEC Upgrade * ipfw NAT and libalias * Multi-link PPP daemon (MPD) * Wireless Networking Kernel * Cryptographic Subsystem * GEOM Multipath * Interrupt Filtering * Sound Subsystem Improvements * Update of the Linux Compatibility Environment in the Kernel Hardware Drivers * Bt878 Audio Driver (aka FusionHDTV 5 Lite driver) * Intel 3945ABG Wireless LAN Driver: wpi * MPT LSI-Logic Host Adapters: mpt * QLogic SCSI and Fibre Channel: isp Documentation * Hungarian Translation of the Webpages * The FreeBSD Dutch Documentation Project Userland Programs * BSNMP - More Ongoing and Upcoming Work * BSNMP Bridge Module * BSNMP Client Tools * Libelf Architectures * ARM/XScale Port * FreeBSD/powerpc on Freescale MPC8555 Ports * FreeBSD GNOME Project * FreshPorts * Ports Collection * Updating X.org FreeBSD Ports to 7.2 Miscellaneous * BSDCan 2007 * EuroBSDCon 2007 _________________________________________________________________ ARM/XScale Port Contact: Olivier Houchard Contact: Sam Leffler FreeBSD is running multi-user on a variety of Gateworks Avila boards with most of the on-board devices supported. These include the compact flash/IDE slot, wired network interfaces, realtime clock, and environmental sensors. Several different minipci cards have been tested including those supported by the ath(4) and hifn(4) drivers. Remaining devices that need support are the onboard flash, optional 4-port network switch, and optional USB interface. Crypto acceleration for IXP425 parts is planned but will likely be done at a later time. The Network Processor Engine (NPE) support is done with an entirely new replacement for the Intel Access Layer (IAL). The most important hardware facilities are supported (e.g. the hardware Q manager) and the wired NIC driver was also done from scratch. The resulting code is approximately 1/10th the number of lines of the equivalent IAL code. Open tasks: 1. Bootstrap support needs work to enable booting from the compact flash device. _________________________________________________________________ Automatic TCP Send and Receive Socket Buffer Sizing URL: http://people.FreeBSD.org/~andre/tcp_auto_buf-20061212.diff URL: http://people.FreeBSD.org/~andre/tcp_auto_buf-20061212-RELENG_6.diff Contact: Andre Oppermann Normally the socket buffers are static (either derived from global defaults or set with setsockopt) and do not adapt to real network conditions. Two things happen: a) your socket buffers are too small and you can't reach the full potential of the network between both hosts; b) your socket buffers are too big and you waste a lot of kernel memory for data just sitting around. With automatic TCP send and receive socket buffers we can start with a small buffer and quickly grow it in parallel with the TCP congestion window to match real network conditions. FreeBSD has a default 32K send socket buffer. This supports a maximal transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans-continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer auto scaling and the default values below it supports 20Mbit/s at 100ms and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. For the receive side it looks slightly better with a default of 64K buffer size. The automatic send buffer sizing patch is currently running on one half of the FTP.FreeBSD.ORG cluster w/o any problems so far. Against this machine with the automatic receive buffer sizing patch I can download at 5.7 MBytes per second. Without patch it maxed out at 1.6 MBytes per second as the delay bandwidth product became equal to the static socket buffer size without hitting the limits of the physical link between the machines. My test machine is about 35ms from that FTP.FreeBSD.ORG and connected through a moderately loaded 100Mbit Internet link. New sysctls are: * net.inet.tcp.sendbuf_auto=3D1 (enabled) * net.inet.tcp.sendbuf_inc=3D8192 (8K, step size) * net.inet.tcp.sendbuf_max=3D262144 (256K, growth limit) * net.inet.tcp.recvbuf_auto=3D1 (enabled) * net.inet.tcp.recvbuf_inc=3D16384 (16K, step size) * net.inet.tcp.recvbuf_max=3D262144 (256K, growth limit) _________________________________________________________________ BSDCan 2007 URL: http://www.bsdcan.org/2007/ Contact: Dan Langille Folks! It is that time of year. You may have missed the call for papers , but please put in your proposal right away. This is often a busy time of year, but please take the time to consider presenting at BSDCan. Please read the submission instructions and send in your proposal today! You may be interested in our sister conference: PGCon. If you have an interest in PostgreSQL , a leading relational database, which just happens to be open source, then we have the conference for you! PGCon 2007 will be held immediately after BSDCan 2007, at the same venue, and will follow a similar format. Open tasks: 1. Waiting for papers _________________________________________________________________ BSNMP - More Ongoing and Upcoming Work URL: http://wikitest.FreeBSD.org/BsnmpTODO Contact: Shteryana Shopova Contact: Harti Brandt Contact: Bjoern A. Zeeb In addition to other more detailed reports this is intended to give a summary about other ongoing or upcoming BSNMP related work. To collect some ideas from users and coordinate work a BSNMP TODO Wiki page was created. Feel free to add your ideas or let us know about them. * A contributor, Tsvetan Erenditsov, has volunteered to implement a VLAN module for BSNMP. Shteryana is helping him. * Sam Leffler has asked for a wireless networking monitoring module, which will most likely be the next module to be implemented. * Some major work is currently going on in the main BSNMP tree: + SNMP transports have been factored out into loadable modules. The old port tables are still there and will remain at least for the next release. Later they will be removed. The following modules and transports are already implemented as loadable modules: o snmp_trans_udp: SNMP over UDP over IPv4, IPv6 and scoped IPv6 o snmp_trans_tcp: SNMP over TCP over IPv4, IPv6 and scoped IPv6 o snmp_trans_ldgram: SNMP over local datagram sockets o snmp_trans_lstream: SNMP over local stream sockets + Some I/O functions have been moved from the daemon to libbsnmp. + libisa has been imported into the bsnmp tree. This library aims at easy implementation of command line tools for remote and local system administration with a special focus on administration via SNMP. The library contains command line parsing functions, a function for automatically handling help text. Actual administration modules are implemented as loadable modules. The atmconfig tool in the FreeBSD tree contains some old parts of this library. + lisa_snmp is a module which implements SNMP functionality for libisa. + lisa_snmpd is a module for remote administration of the bsnmpd. + The config file parser of bsnmpd has been rewritten so that each section of the file is handled as a transaction (in contrast to the previous behavior where the entire file was one transaction). _________________________________________________________________ BSNMP Bridge Module URL: http://wikitest.FreeBSD.org/SnmpBridgeModule Contact: Shteryana Shopova The BSNMP bridge module for FreeBSD's BSNMP daemon, which was implemented during SoC 2006, was committed to HEAD. In addition to RFC 4188 single bridge support it also supports monitoring multiple bridges via a private MIB. Since SoC 2006 Rapid Spanning Tree (RSTP) support (RSTP-MIB defined in RFC4318 and additions to the private MIB) was added to the module as well. A patch for RELENG_6 is available and will be merged to STABLE the next weeks. Open tasks: 1. MFC to RELENG_6. 2. More feedback from users is always welcome. _________________________________________________________________ BSNMP Client Tools URL: http://wikitest.FreeBSD.org/BsnmpTools URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/syr inx/ bsnmp/contrib/bsnmp/snmptools URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/bz/ bsnmp%5fsyrinx/usr.sbin/bsnmpd/tools Contact: Shteryana Shopova Contact: Bjoern A. Zeeb During SoC 2005 BSNMP client tools (bsnmptools) were implemented and have since then been available via Shteryana's P4 tree or port net-mgmt/bsnmptools. In order to finally get the code committed some cleanup was needed which ended in a partly rewrite to minimize duplicate code and to reduce the size of the binaries. This ongoing work is available via Bjoern's P4 tree and will be merged back to upstream trees before it will be committed to HEAD. Open tasks: 1. Update Wiki Page to reflect latest work. 2. Finish cleanup and have it reviewed. 3. User feedback is always welcome. _________________________________________________________________ Bt878 Audio Driver (aka FusionHDTV 5 Lite driver) URL: http://perforce.freebsd.org/fileSearch.cgi?FSPC=3D%2F%2Fdepot%2Fuser%2Fj mg%2Fbktrau%2F...&ignore=3DGO%21 Contact: John-Mark Gurney Basic audio capture is working. All of the parameters are set by userland, while the RISC program generation is by kernel. No real audio has been captured as there are no drivers for the NTSC tuner yet. Someone with a real Bt878 NTSC card that is supported by bktr(4) could use this to capture audio without using the sound card. Due to lack of documentation from DViCO and LG, I have copied magic values from the Linux driver and managed to get ATSC capturing working. There was a bug in the capture driver that was releasing buffers to userland early causing what appeared to be reception issues. Now that we use the RISC status bits as buffer completion bits, capture works cleanly. This does mean that even if you provide more than 4 buffers to the driver, the buffers will be divided into four segments, and returned in segments. A Python module is available, along with a sample capture application using it. The module is now known to work well with threads so that tuning (expensive due to i2c ioctls) can happen in another thread without causing program slow down. The module is working well with a custom PVR backend. Additional ioctls have been added to get sibling devices. This allows one to open a bktrau device, and get the correct bktr(4) device that is in the same slot. This is necessary so that when adjusting GPIO pins or sending i2c commands, they are to the correct device. Open tasks: 1. Provide support for NTSC and FM tuning. 2. Add support for other cards and tuners that use the Bt878 chip. _________________________________________________________________ Cryptographic Subsystem Contact: Sam Leffler Michael Richardson has been spearheading work to improve the crypto subsystem used by various parts of the kernel including Fast IPSec and geli. This work is sponsored by Hifn and has been happening outside the CVS repository. A main focus of this work is to add support for higher-level hardware operations that can significantly improve the performance of IPSec and SSL protocols. Results of this work are now being readied for CVS. These redesign the core/driver APIs to use the kobj facilities and recast software crypto drivers as pseudo devices. The changes greatly improve the system and permit new functionality such as specifying which crypto device to use when multiple are available. The redesign will also enable load balancing of crypto work across multiple devices and the addition of virtual crypto sessions by which small operations can be done in software when the overhead to set up a hardware device is too costly. In addition to the changes to the core crypto system several crypto drivers have been updated to improve their operation. Top of this list is the hifn(4) driver where many longstanding bugs have been fixed for 7955/756 parts. _________________________________________________________________ EuroBSDCon 2007 URL: http://2007.EuroBSDCon.org/ URL: http://www.EuroBSDCon.dk/ Contact: Sidsel Jensen The sixth EuroBSDCon will take place in Copenhagen, Denmark on Friday the 14th and Saturday 15th of September 2007 . The conference will be held at Symbion Science Park . Sunday the 16th there will be an optional tour to LEGOland. The call for papers was sent out right after EuroBSDCon 2006 in Milan in November and abstracts are due February 1st! So hurry up and send in all your fantastic and amazing papers to papers at eurobsdcon dot dk. _________________________________________________________________ =46AST_IPSEC Upgrade URL: http://www.FreeBSD.org/~gnn/fast_ipv6.patch URL: http://blogs.FreeBSDish.org/gnn/ Contact: George Neville-Neil Contact: Bjoern Zeeb Just this week I got routing working for the FAST_IPSEC and IPv6 code. Now there are memory smash problems, and then we need to remove the old GIANT lock. I hope to produce another patch with the routing code working in the next week. Open tasks: 1. Test the patch!!!! _________________________________________________________________ =46reeBSD Bugbusting Team URL: http://www.FreeBSD.org/doc/en/articles/pr-guidelines/ URL: http://www.FreeBSD.org/doc/en/articles/problem-reports/ Contact: Mark Linimon Contact: Ceri Davis Contact: Remko Lodder The FreeBSD Bugbusting team is a team of volunteers keeping track of various PR tickets in the GNATS application. Currently the Bugbusting team is investigating old PR tickets, checking whether they are still accurate, checking what needs to be done to fix the issues reported and make sure that the developers team can focus on the latest releases. The team is always in need of volunteers willing to give a hand to resolve the old tickets and get the best feedback that is needed for the open tickets. Please contact FreeBSD-bugbusters@FreeBSD.org if you want more information about the things that need to be done. Open tasks: 1. Checkout old PR tickets, getting the proper feedback and finally fix and/or resolve the tickets. _________________________________________________________________ =46reeBSD GNOME Project URL: http://www.FreeBSD.org/gnome/ Contact: FreeBSD GNOME Project Where have we been?! Not doing status reports, that's for sure. But the FreeBSD GNOME project has been very busy with regular GNOME releases, and other side projects. We are currently shipping GNOME 2.16.2 in the ports tree, and we are testing GNOME 2.17.5 in the MarcusCom tree. Most recently, work has completed on a cleanup of the FreeBSD backend to libgtop. This module has needed a lot of work, and should now be reporting correct system statistics. The cleaned up version is currently being tested in the MarcusCom tree, and will make it into the FreeBSD ports tree along with GNOME 2.18. The GStreamer framework has been taken out of direct gnome@ maintainership, and put under a new multimedia@ umbrella. This will give multimedia-savvy developers a chance to collaborate on this important piece of the GNOME Desktop along with other important audio and video components. The biggest accomplishment of 2006 for the FreeBSD GNOME team had to have been the port of HAL . This effort was started to give FreeBSD users a richer desktop experience. Since the initial FreeBSD release of HAL with GNOME 2.16, it has been incorporated into the FreeBSD release of KDE 3.5.5 as well as PC-BSD 1.3. The FreeBSD backend has also made it upstream into the HAL git repository so future releases of HAL will have FreeBSD support out-of-the-box. Finally, it is with sadness that we say good-bye to one of our team members. Adam Weinberger stepped down from the FreeBSD GNOME team to save lives instead (priorities, man!). His splash screens and grammar nit-picking will be missed. Open tasks: 1. Now that HAL has been ported to FreeBSD, there is a strong desire to see NetworkManager ported. The big parts will be porting NM to use our 80211 framework, and extending some of the base utilities such as ifconfig. Contact marcus@FreeBSD.org if you are interested in helping. 2. Our system-tools-backends module needs some attention. This module is responsible for system configuration tasks in GNOME such as user management, network shares administration, etc. A knowledge of Perl is highly recommended. Contact marcus@FreeBSD.org if you are interested in helping. 3. We need good documentation writers to help update our FAQ and other documentation. If you would like to take on the responsibility full-time, or just contribute some pieces, please notify gnome@FreeBSD.org . 4. We are always in need of GNOME development testers. See our development branch FAQ for ways on how you can help make the next release of GNOME the best release. _________________________________________________________________ =46reeBSD Security Officer and Security Team URL: http://www.FreeBSD.org/security/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.FreeBSD.org/ Contact: Security Officer Contact: Security Team In the time since the last status report, four security advisories have been issued concerning problems in the base system of FreeBSD (three in 2006 and one in 2007); of these, one problem was in "contributed" code, while the remaining three were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 55 new entries have been added, bringing the total up to 869. In order to streamline security team operations and ensure that incoming emails are promptly acknowledged, Remko Lodder has been appointed the security team secretary. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.11, FreeBSD 5.5, FreeBSD 6.0, FreeBSD 6.1, and FreeBSD 6.2. The respective End of Life dates of supported releases are listed on the web site; of particular note, FreeBSD 4.11 and FreeBSD 6.0 will cease to be supported at the end of January 2007. _________________________________________________________________ =46reeBSD/powerpc on Freescale MPC8555 Contact: Rafal Jaworowski Contact: Marcel Moolenaar Platform summary: * PowerQuiccIII integrated controller * e500 CPU core * compliant with PowerPC BookE specification (significantly different from the 'traditional' PowerPC architecture the current FreeBSD/powerpc supports, particularly in the areas of MMU design, exceptions model, specific e500 machine instructions etc.) Currently the machine is booting FreeBSD 6.1-RELEASE-p10 and operating both single- and multi-user modes; below are highlights of available functionality: 1. Low-level support 2. + booting from U-Boot bootloader + locore machine initialization + e500 exceptions + VM: a new pmap module developed 3. On-chip peripherals 4. + introduced ocpbus hierarchy (nexus and descendants) + interrupt controller: using generic OpenPIC driver + serial console: using uart(4) driver + barebones serial support using the QUICC's SCC + host/PCI bridge: a new driver developed for the built-in bridge + networking: a new driver developed for TSEC (3-speed Ethernet) 5. Booting 6. + from ATA disk and USB memory stick (both through a secondary PCI VIA82C686B controller) + from network (NFS-mounted rootfs) 7. Basic TCP/IP protocols and apps work (DHCP, NFS, SSH, FTP, Telnet etc.) 8. Userland 9. + integrated SoftFloat emulation lib (required due to e500 not being equipped with the old-style PowerPC FPU) + almost all applications seem to work Open tasks: 1. Work out extensible layout for sys/powerpc architecture directory so we can easily add support for new core variations and platforms to come in the future. 2. Integrate with FreeBSD source tree. 3. Release and tinderbox related options and settings. _________________________________________________________________ =46reeSBIE URL: http://www.FreeSBIE.org URL: http://users.gufi.org/~rionda/20relnotes/ URL: http://users.gufi.org/~rionda/20screen/ Contact: Matteo Riondato Contact: FreeSBIE Staff Contact: FreeSBIE Mailing List FreeSBIE is approaching the 2.0-RELEASE. The first release candidate proved to be good enough but a second one will probably be released. An external developer is working on integrating BSDInstaller in FreeSBIE 2.0 and this may cause a little delay of the release date. Release Notes were written and need to be updated with the current list of packages. A script which allows to switch Tor+Privoxy on and off was added and its usage was documented. The 2.0-RELEASE is near, hopefully near the end of January but this will also depend on when FreeBSD 6.2-RELEASE will be released. _________________________________________________________________ =46reshPorts URL: http://www.freshports.org/ URL: http://news.freshports.org/ Contact: Dan Langille There have been a number of improvements to FreshPorts over the last quarter of 2006. The following are just a few of them. The links take you to the relevant article within the FreshPorts News website . * Better pagination of larger result sets * Listing of sanity test failures * Inclusion of latest vulnerabilities on the front page * Started working on adding tools to make FreshSource/FreshPorts more useful as a developer tool * The new dual opteron server has been deployed! My thanks to the many people who have contributed suggestions, ideas, and code over the years. Most of you are documented at the above URLs. Open tasks: 1. FreshPorts/FreshSource as a developer tool _________________________________________________________________ GEOM Multipath Contact: Matthew Jacob A toy implementation of GEOM based active/passive multipath is now done and in a perforce repository. Seems to work. _________________________________________________________________ Hungarian Translation of the Webpages URL: http://www.FreeBSD.org/hu/ Contact: G=E1bor K=F6vesd=E1n Contact: Giorgos Keramidas G=E1bor K=F6vesd=E1n (gabor@) has submitted the Hungarian translation of= the webpages and Giorgos Keramidas (keramida@) has reviewed and committed the pages. The initial rendering issues have also been fixed and the webpage is in a pretty good shape now. As usual, this translation does not contain every part of the English version, but the most important and useful parts are there. G=E1bor will maintain this translation and regularly sync the content with the English version and add new translations if such become available. Open tasks: 1. Fix typos and mistakes that will be revealed after a deeper review by the public 2. Get more people involved _________________________________________________________________ Intel 3945ABG Wireless LAN Driver: wpi URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/ben jsc/wpi URL: http://www.clearchain.com/wiki/wpi Contact: Benjamin Close An initial port of the NetBSD wpi driver has been done and development is happening fast to get this driver ready for the tree. At present basic functionality works. The driver can associate with a non encrypted peer and pass data in 11b and 11g modes. There is still lots to do and testing is welcome. Many thanks have to go to Sam, Max and Kip for helping the driver reach this point. Open tasks: 1. Solve bus dma alignment issues 2. Support WEP and WPA 3. Testing and more testing _________________________________________________________________ Interrupt Filtering URL: http://wikitest.FreeBSD.org/Interrupts Contact: Paolo Pisati Contact: John Baldwin Contact: Scott Long Interrupt filtering is a new method to handle interrupts in FreeBSD that retains backward compatibility with the previous models (FAST and ITHREAD), while improving over them in some aspects. With interrupt filtering, the interrupt handler is divided into 2 parts: the filter (that checks if the actual interrupt belongs to a device) and a private per-handler ithread (that is scheduled in case some blocking work has to be done). The main benefits of this work are: * Feedback from filters (the operating system finally knows what's the state of an event and can react consequently). * Lower latency/overhead for shared interrupt line. * Previous experiments with interrupt filtering showed an increase in performance against the plain ithread model in some cases. * General shrink of the machine dependent code - part of the interrupting handling code was turned into machine independent code. During the last quarter many improvements were made up to the point where 3 archs (i386, amd64 and arm) are reported to work, and the project can be considered feature complete. I definitely want to make it part of the 7.0 release. Open tasks: 1. Define a road map to commit the code into the tree. 2. Rethink the interrupt stray handling (?!?!). 3. Finish off support for powerpc, sparc64 and ia64 (sun4v support is known to be broken now). _________________________________________________________________ ipfw NAT and libalias Contact: Paolo Pisati Support for in-kernel NAT, redirect and LSNAT for ipfw was committed to HEAD, and i encourage people to test it so we can quickly discover/fix bugs. To add these features to ipfw, compile a new kernel adding "options IPFIREWALL_NAT" to your kernel config or, in case you use modules, add "CFLAGS +=3D -DIPFIREWALL_NAT" to your make.conf. Open tasks: 1. Teach libalias to handle mbufs (this will fix TSO-capable NICs). 2. Add support for hardware checksum offloading. _________________________________________________________________ iSCSI Initiator URL: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.0.1.tar.bz2 Contact: Daniel Braniss Though it is still a work in progress, it now supports more targets, has login CHAP authentication and header/data digest. It will also recover from a lost connection - most of the time. Open tasks: 1. instrumentation 2. task management support 3. improve the error recovery _________________________________________________________________ Libelf URL: http://wiki.FreeBSD.org/LibElf URL: http://wiki.FreeBSD.org/PmcTools URL: http://people.FreeBSD.org/~jkoshy/projects/perf-measurement/ Contact: Joseph Koshy Libelf is a BSD-licensed library for ELF parsing & manipulation implementing the SysV/SVR4 (g)ELF[3] API. Current status: The library is now in -CURRENT. Work continues on its test suite and tutorial, and on deploying it in PmcTools. _________________________________________________________________ MPT LSI-Logic Host Adapters: mpt Contact: Matthew Jacob The 'mpt' project is support for the MPT LSI-Logic Host Adapters (SCSI, Fibre Channel, SAS). The last quarter saw a lot of change supported by Yahoo! and LSI-Logic and many others as things settled out for better support for U320. Some initial Big Endian support was offered by John Birrel and Scott Long. Open tasks: 1. Finish SAS Integrated RAID support. 2. Try and get U320 RAID working better than it currently does. 3. Finish Big Endian support, including that for target mode. _________________________________________________________________ Multi-link PPP daemon (MPD) URL: http://sourceforge.net/projects/mpd/ URL: http://mpd.cvs.sourceforge.net/*checkout*/mpd/mpd/doc/changes.sgml Contact: Alexander Motin Contact: Archie Cobbs MPD is moving to the next major release - mpd4_0. At the end of October one more beta version (4_0b5) was released and first RC is planned soon. Since 3_18 and 4_0b4 numerous bugs and cases of incorrect internal handling have been fixed. Performance has been increased and system requirements reduced. Many new features have been implemented: * IPv6 support * NAT (using the ng_nat(4) node) * integrated web server * Deflate and Predictor-1 CCP compression Some historically broken features have been reimplemented: * TCP and UDP link types * CCP compression * ECP encryption To support compression, two new Netgraph nodes ng_deflate and ng_pred1 have been created and the ng_ppp node has been modified. Open tasks: 1. ng_ppp node refactoring. 2. Implement packet loss notification in related Netgraph nodes (ng_ppp, ng_pptp, ng_async, ng_deflate, ng_pred1, ng_vjc, ...) to reduce recovery time and probability of incorrect packet decompression. 3. MPD auth subsystem refactoring. _________________________________________________________________ Network Stack Virtualization URL: http://imunes.tel.fer.hr/virtnet/ Contact: Marko Zec The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This will allow for complete networking independence between jails on a system, including giving each jail its own firewall, virtual network interfaces, rate limiting, routing tables, and IPSEC configuration. The prototype currently virtualizes the basic INET and INET6 kernel structures and subsystems, including the TCP machinery and the IPFW firewall. The focus is currently being kept on resolving bugs and sporadic lockups, and defining the internal and management APIs. It is expected that within the next month the code will become sufficiently complete and stable for testing by early adopters. _________________________________________________________________ New USB Stack URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects /usb/src/sys/dev/usb URL: http://www.turbocat.net/~hselasky/usb4bsd Contact: Hans Petter Sirevaag Selasky During the last three months there has not been so much activity in the USB project. Some regression issues have been reported and fixed. Bernd Walter reports that he has got the new USB stack working on ARM processors with some minor tweaks. Markus Brueffer reports that he is working on the USB HID parser and support. A current issue with the new USB stack is that the EHCI driver does not work on the Sparc64 architecture. If someone has got a Sparc64 with FreeBSD 7-CURRENT on and can lend the USB project the root password, a serial console and a USB test device, for example a USB memory stick, that would be much appreciated. Another unresolved issue is that the ural(4) USB device driver does not always work. This is currently being worked on. If you want to test the new USB stack, check out the USB perforce tree or download the SVN version of the USB driver from my USB homepage. At the moment the tarballs are a little out of date. Ideas and comments with regard to the new USB API are welcome at freebsd-usb@FreeBSD.org . _________________________________________________________________ Past and Future PR Closing Events URL: http://wikitest.freebsd.org/Bugathons Contact: Florent Thoumie Following the example of our NetBSD friends, we organized a couple of Bugathons to help decreasing the open PR count. At first, it was decided to make it a monthly event focused on both src, ports and doc. Audience decreased with each Bugathon organized and less non-ports committers attended the events. So from now on, we will focus on ports (making it a Portathon) and organize a new event after the end of each ports freeze (that should be twice a year, at most). _________________________________________________________________ Porting ZFS to FreeBSD URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/pjd /zfs URL: http://www.opensolaris.org/os/community/zfs/porting/ URL: http://docs.FreeBSD.org/cgi/mid.cgi?20060822104516.GB16033 Contact: Pawel Jakub Dawidek The ZFS file system works quite well on FreeBSD now. The first patchset has already been published on the freebsd-fs@FreeBSD.org mailing list . All file system methods are already implemented (except ACL-related). Basically all stress tests I tried work, even under very high load. There is still a problem with memory allocation, which can get out of control, but from what I know the SUN guys also work on this. Recently I have been working on a file system regression test suite. From what I found, there are no such test suites for free. I've already more than 3000 tests and I'm testing correctness of most file system related syscalls (chflags, chmod, chown, link, mkdir, mkfifo, open, rename, rmdir, symlink, truncate, unlink). I'm also working to make it usable on other operating systems (like Solaris, where it already works and Linux). Few days ago I also (almost) finished NFS support. You can't use the 'zfs share' command yet, but you can export file systems via /etc/exports and you can also access snapshots. It was quite hard, because snapshots are separate file systems and after exporting the main file system, we need to also serve data from snapshots under it. The one big thing which is missing is ACL support. This is not an easy task, because we first have to make some decisions. Currently we use POSIX ACLs in our UFS, but the market is moving slowly to NTFS/NFSv4-type ACLs. In Solaris they use POSIX ACLs for UFS and NFSv4-type ACLs for ZFS and we probably also want to use NFSv4-type ACLs in our ZFS, which requires some work outside ZFS. _________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports / URL: http://people.FreeBSD.org/~fenner/portsurvey/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has jumped to 16347. The PR count, despite a jump, has gone back down to around 700. Not much work has been committed on the ports infrastructure due to the long 6.2 release cycle. However, many test runs have been done for several upcoming features, such as making sure that ports will work with the new release of gcc (4.1), and do not have /usr/X11R6 hard-coded into them. The intention of the latter is to move all ports to $LOCALBASE, which can then be selected by the user. This should help consistency going forwards, albeit at the cost of a one-time conversion. GNOME was updated to 2.16 during the release cycle. In addition, we are in the process of moving the FORTRAN default from f77 to gfortran. See the ports mailing list for details. The new xorg ports are still being worked on as well; they are intended to all live in $LOCALBASE. Hopefully this can get done in the early 6.3 development cycle. See the wiki for more information. A new version of the ports Tinderbox code is available, which is mostly a bugfix release. We have also added Pav Lucistnik as a new portmgr member, who we hope will help us work on the portmgr PR backlog. Welcome! We have also added 8 new committers since the last report. linimon continues to work on resetting committers who are no longer interested in their ports; as well, several ports commit bits have been stored for safekeeping. This is part of an attempt to keep the best match between volunteers and work to be done. Open tasks: 1. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 2. Although we have added many maintainers, we still have many unmaintained ports. As well, the packages on amd64 and sparc64 are lagging behind. _________________________________________________________________ QLogic SCSI and Fibre Channel: isp Contact: Matthew Jacob This project is for support for QLogic SCSI and Fibre Channel host adapters. The last quarter saw the addition of 4Gb Fibre Channel support and a complete rewrite of fabric management (which is still settling out). _________________________________________________________________ Release Engineering URL: http://www.FreeBSD.org/releng/ URL: http://www.FreeBSD.org/releases/6.2R/announce.html URL: http://www.FreeBSD.org/snapshots/ Contact: Release Engineering Team The recent activities of the Release Engineering team have centered around FreeBSD 6.2-RELEASE, which is now available for downloading. This is the latest release from the RELENG_6 branch, and includes many new performance and stability improvements, bug fixes, and new features. The release notes and errata notes for FreeBSD 6.2 contain more specific information about what's new in this version. We thank the FreeBSD developer and user community for their efforts towards making this release possible. The Release Engineering Team also produced snapshots of FreeBSD CURRENT in November 2006 and January 2007. These snapshots have not received extensive testing, and should not be used in production environments. However, they can be used for testing or experimentation, and show the kinds of functionality that can be expected in future FreeBSD releases. _________________________________________________________________ Sound Subsystem Improvements URL: http://people.FreeBSD.org/~ariff/ URL: http://www.FreeBSD.org/projects/ideas/ URL: http://wiki.FreeBSD.org/soundsystem Contact: Ariff Abdullah Contact: Alexander Leidinger Contact: Multimedia Mailinglist Since the last status report there were improvements to the emu10kx driver for High Definition Audio (HDA) compatible chips. Some more chips are supported now and already supported chips should provide a better zero-configuration experience. The generic sound code got some very nice low latency changes, and fixes which make it multichannel/endian/format safe. We do not support multichannel operation yet, but this work is a prerequisite to work on implementing multichannel operation. This work also fixed some bugs which people may experience as clicks, hickups, truncation or similar behavior in the sound-output. So far there is no merge to 5.x or 6.x planned for this code, especially because there are API/ABI changes, e.g., several sysctls changed. People who do not care about this can download binary sound modules from Ariff's download page for 6.x and 5.x. We thank all people who tested the changes / submitted patches and thus helped improving the sound system. Open tasks: 1. Have a look at the sound related entries on the ideas list. 2. Add multichannel support. 3. sndctl(1): tool to control non-mixer parts of the sound system (e.g. spdif switching, virtual-3D effects) by a user (instead of the sysctl approach in -CURRENT); pcmplay(1), pcmrec(1), pcmutil(1). 4. Plugable FEEDER infrastructure. For ease of debugging various feeder stuff and/or as userland library and test suite. 5. Extend the wiki page. _________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.FreeBSD.org/doc/nl/books/handbook URL: http://www.evilcoder.org/content/section/6/39/ URL: http://www.FreeBSD-nl.org/doc/nl/ URL: http://www.FreeBSD-nl.org/www/ Contact: Remko Lodder The FreeBSD Dutch Documentation Project is an ongoing project to translate the FreeBSD Handbook to the Dutch Language. Currently we almost translated the entire handbook, and we translated parts of the website, sadly the project went into a slush lately, so we seek out for fresh and new translators that are willing to join the team to continue the effort. Open tasks: 1. Translate the rest of the handbook 2. Make the documentation up to date 3. Translate the rest of the website _________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin The FreeBSD Foundation ended 2006 raising over $100,000. We received commitments for another $55,000 in donations for the Fall Fundraiser. We fell short of our goal of raising $200,000. But, we are working hard to fill this gap, early in 2007, so we can continue with the same level of support for the project and community. Please go to http://www.freebsdfoundation.org/donate/ to find out how to make a donation to the foundation. We added a donors page to our website to acknowledge our generous donors. We negotiated and are now actively managing a joint technology project with NLNet and the University of Zagreb to develop virtualized network stack support for FreeBSD. We sponsored AsiaBSDCon and are now accepting travel grant applications for this conference. We are working to upgrade the project's network testbed with 10Gigabit interconnects. Cisco has generously donated a 10Gigabit switch and we have received network adapters from Myricom, Neterion, Intel, and Chelsio. Adapters from other vendors are being solicited so that we can do interoperability testing. For more information on what we've been up to, check out our end-of-year newsletter at http://www.freebsdfoundation.org/press/2006Dec-newsletter.shtml . _________________________________________________________________ TrustedBSD Audit URL: http://www.TrustedBSD.org/audit.html URL: http://www.OpenBSM.org/ Contact: Robert Watson Contact: Christian Peron Contact: Wayne Salamon FreeBSD 6.2-RELEASE, the first release of FreeBSD with experimental audit support is now available. The plan is to make audit a full production feature as of FreeBSD 6.3-RELEASE, with "options AUDIT" compiled in by default. A TODO list has been posted to trustedbsd-audit. OpenBSM 1.0 alpha 13, which includes support for XML record printing, additional 64-bit token types, additional audit events, and more cross-platform build support, has been released. OpenBSM 1.0 alpha 14, which adds support for warnings clean building with gcc 4.1, will be released shortly. The new OpenBSM release will be merged to FreeBSD CVS in late January or early February. Open tasks: 1. Complete assignment of audit events to non-native and a few remaining native system calls. Add additional system call argument auditing. 2. Merge MAC Framework hooks allowing MAC modules to control access to kernel audit services. Refine and merge MAC labeling support in audit, including support for MAC annotations in the audit trail. 3. Complete pass through user space services adding audit support to system management tools (and ftpd). Work with third party software maintainers to add audit support for applications like xdm/kdm/gdm. 4. Merge latest OpenBSM, including XML output support. _________________________________________________________________ TrustedBSD MAC Framework URL: http://www.TrustedBSD.org/mac.html Contact: Robert Watson Contact: Most work on the MAC Framework during this period, other than as relates to the priv(9) project described in a separate status report, has been in refinement of the structure of the framework. * Add two new entry points allowing MAC Framework policy modules to grant or limit fine-grained system privileges. * A sample mac_priv(4) policy module has been created demonstrating how a MAC Framework policy module can grant specific system privileges to specific users. * Commenting throughout the MAC Framework significantly extended. * Correct a bug in which the original ifnet label was copied to user space via ioctl, rather than the thread-local copy. * mac_enforce_subsystem debugging sysctls removed, as some policies rely on access control checks being called even when non-enforcing (specifically, information flow related policies). * Break out mac.h include file into mac.h (user API, system calls) and mac_framework.h (in-kernel interface to the MAC Framework). Move non-user MAC include files from src/sys to src/sys/security/mac. Move and break out kern_mac.c into mac_framework.c and mac_syscalls.c. The MAC Framework is now entirely located in src/sys/security/mac. * Export the MAC Framework version via a read-only sysctl and provide a #define version usable by policies. * MAC Framework locking optimized to optimistically expect no write lock contention during read locking. Open tasks: 1. Now that the MAC Framework has been fully moved to src/sys/security/mac, embark on the 'mac2' interface cleanup, in which many MAC Framework entry points are renamed for consistency. This will require most MAC Framework policy modules to be modified between FreeBSD 6.x and FreeBSD 7.x, although in a way that can be largely done using sed. 2. Add accessor functions for policies retrieving per-policy label data from labels, so that policy modules do not compile in the binary layout of struct label. This will allow future optimization of the label layout. 3. Complete integration of audit and MAC support, allowing MAC policy modules to control access to audit interfaces, and allowing them to annotate audit records. _________________________________________________________________ TrustedBSD priv(9) URL: http://www.TrustedBSD.org/ Contact: Robert Watson TrustedBSD priv(9) replaces suser(9) as an in-kernel interface for checking privilege in FreeBSD 7.x. Each privilege check now takes a specific named privilege. This allows both centralization of jail logic relating to privilege, which is currently distributed around the kernel at the point of each call to suser(9), and allows instrumentation of the privilege logic by the MAC Framework. Two new MAC Framework entry points, one to grant and the other to limit privilege, are now available, providing fine-grained control of kernel privilege by policy modules. This lays the kernel infrastructure groundwork for further refinement and extension of the kernel privilege model. The priv(9) implementation has been committed to FreeBSD 7-CURRENT. This software was developed by Robert N. M. Watson for the TrustedBSD Project under contract to nCircle Network Security, Inc. Open tasks: 1. Complete review of kernel privilege checks, removal of suser(9) jail flag now that checks are centralized. 2. Explore possible changes to kernel privilege model along lines of POSIX.1e privileges, the Solaris privilege interface, etc. This has been explored previously as part of the TrustedBSD Capabilities project also. _________________________________________________________________ Update of the Linux Compatibility Environment in the Kernel URL: http://wiki.FreeBSD.org/linux-kernel Contact: Alexander Leidinger Contact: Roman Divacky Contact: Emulation Mailinglist Since the last status report we made good progress in improving the compatibility environment. We fixed more than 30 testcases on i386 (130 testcases =3D 16% still failing) and more than 60 testcases on amd64 (140 testcases =3D 17% still failing) in the Linux 2.4 compatibility. These numbers compare FreeBSD 6.2 with -CURRENT. Some of those fixes are edge cases in the error handling, and some of them fix real issues -- e.g. hangs -- and improve the stability and correctness of the emulation. Regarding the Linux 2.6 compatibility there are 140 testcases (17%) on i386 and 150 testcases (18%) on amd64 still failing in -CURRENT. After fixing some showstopper problems with real applications, we should be able to give the 2.6 emulation a more widespread exposure "soon" to find more bugs and to determine the importance of those Linux syscalls which we did not implement yet. The severity of the broken testcases varies, and some of them will never be fixed, e.g., we will never be able to load Linux kernel modules into a FreeBSD kernel, being able to add swap with a Linux command has very low priority, and fixing stuff which is used by applications like IPC type 17 has high priority. Some differences in the 2.6 compatibility are because not all i386 changes are merged into the amd64 code, and some testcases are already fixed in our perforce repository but need more review before they can be committed to -CURRENT. We need some more testers and bug reporters. So if you have a little bit of time and a favorite Linux application, please play around with it on -CURRENT. If there is a problem, have a look at the wiki if we already know about it and report on emulation@ . We are especially interested in reports about the 2.6 compatibility (sysctl compat.linux.osversion=3D2.6.16), but only with the most recent -CURRENT and maybe with some patches we have in the perforce repository (mandatory on amd64). We thank all people who tested the changes / submitted patches and thus helped improving the Linux compatibility environment. _________________________________________________________________ Updating X.org FreeBSD Ports to 7.2 URL: http://xorg.freedesktop.org/ URL: http://git.xbsd.org/?p=3Dfreebsd/ports.git;a=3Dshortlog;h=3Dxorg URL: http://blog.xbsd.org/ URL: http://lists.freebsd.org/pipermail/freebsd-x11/ Contact: Florent Thoumie Contact: Eric Anholt Contact: Dejan Lesjak X.org 7.2 release has been delayed more than a month, which gave us more time to fix build failures, to work on a few runtime issues and to determine the easiest way to upgrade from 6.9 to 7.2 (mostly with the help of people on the freebsd-x11@ mailing list ). Everything is in a rather good shape but there's still a little amount of work to do. The merge of new ports is most likely to happen before the end of January. Open tasks: 1. Do a global review of the diff between the original tree and the experimental one (git-diff origin xorg for git users) 2. Fix the remaining (9 I think, 3 being lang/jdk's) build errors 3. Continue testing 4. Do another experimental build on pointyhat _________________________________________________________________ Wireless Networking Contact: Sam Leffler Work on wireless support has continued to evolve in the public CVS tree while other work has been going on behind the scenes in the developer's perforce repository. Support was recently added to HEAD for half- and quarter-rate channels as found in the 4.9 GHz FCC Public Safety Band. This work was a prerequisite to adding similar support in the 900 MHz band as found in Ubiquiti's SR9 cards. Adding this functionality was straightforward due to the design of the net80211 layer, requiring only some additions to handle the unusual mapping between frequencies and IEEE channel numbers. The ath(4) driver currently supports hardware capable of operating on half- and quarter-rate channels. Kip Macy recently made significant advances preparing legacy drivers for the re-architected net80211 layer that has been languishing in perforce. With his efforts this code is nearly ready for public testing after which it can be merged into CVS. Our goal is to complete this merge in time for the 7.x branch (otherwise it will be forced to wait for 8.0 before it appears in a public release). This revised net80211 layer includes advanced station mode facilities such as background scanning and roaming and support for Atheros' SuperG extensions. Getting the revised scanning work into CVS will greatly simplify public distribution of the Virtual AP (VAP) code as a patch as well as enable addition of 802.11n support. Benjamin Close is working on support for the Intel 3945 parts commonly found in laptops. The work is going on in the perforce repository with public code drops for testing. Atheros PCI/Cardbus support was updated with a new HAL that fixes a few minor issues and corrects a problem that kept AR2424 parts from working. The new HAL also enables more efficient use of the hardware keycache for TKIP keys; on newer hardware you can now support up to 57 stations without faulting keys into the cache. Support for the latest 802.11n parts found in the new Lenovo and Apple laptops (among others) is in development; initial release will support only legacy operation. Support for Atheros USB devices is coming. Atheros has agreed to license their firmware with the same license applied to the HAL which means it can be committed to the tree and distributed as part of releases. The driver is still in development. wpa_supplicant and hostapd were updated to the latest stable build releases from Jouni Malinen. Shortly the in-tree code base will switch to the 0.5.x tree which will bring in much new functionality including dynamic VLAN tagging that will be especially useful once the multi-bss support is available. The support for injection of raw 802.11 frames was committed to HEAD. This work was done in collaboration with Andrea Bittau. At this point there are no plans to commit this to the STABLE branch as it requires API changes. _________________________________________________________________ Legal Notices | =A9 1995-2007 The FreeBSD Project. All rights reserved. --Boundary-00=_3cVrFyZxpZGOqso-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 22:54:05 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B66BB16A415 for ; Tue, 16 Jan 2007 22:54:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF0813C442 for ; Tue, 16 Jan 2007 22:54:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so19645nfc for ; Tue, 16 Jan 2007 14:54:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FQXxjNI+hmujRtHN43EE6O3G07cq3vnDWSzdVlOwM/oqSL488XRwzoR9Fgf+P9kBLDsrjjFv0/CCBAR8yWM6thRDvc2zFFHzWSNX7krMvsKyM3VDNIeFXJAiHiWbHnQcNweGCopyEOvSMM5ET1NLP8VBmvjaVjvtlhPgN8mkeUs= Received: by 10.49.12.4 with SMTP id p4mr33046nfi.1168988043791; Tue, 16 Jan 2007 14:54:03 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 14:54:03 -0800 (PST) Message-ID: <3bbf2fe10701161454m74bd9356i3999187515c60596@mail.gmail.com> Date: Tue, 16 Jan 2007 23:54:03 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> X-Google-Sender-Auth: c9bda9979a1f9f15 Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 22:54:05 -0000 2007/1/16, Ivan Voras : > Kip Macy wrote: > > x86 pre-P4 had 32-byte cache lines. Thus older processors will not benefit. > > But it does seem to hurt the performance a bit - maybe it's time to add > another CPU option like I586_CPU and I686_CPU? Well, it is my feeling that probabilly the align_cache parameter should be a run-time settled parameter (in particular for ia32 CPUs which changed a lot along the years). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:01:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 661E516A416 for ; Tue, 16 Jan 2007 23:01:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 426C613C461 for ; Tue, 16 Jan 2007 23:01:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2007 15:01:24 -0800 X-IronPort-AV: i="4.13,198,1167638400"; d="scan'208"; a="457708155:sNHT41510732" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0GN1N1j024041 for ; Tue, 16 Jan 2007 15:01:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0GN1NDk020375 for ; Tue, 16 Jan 2007 15:01:23 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 15:01:23 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 15:01:23 -0800 Message-ID: <45AD5908.6090105@cisco.com> Date: Tue, 16 Jan 2007 18:00:24 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 23:01:23.0340 (UTC) FILETIME=[3E3444C0:01C739C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=575; t=1168988483; x=1169852483; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20A=20panic=20with=20the=20latest... |Sender:=20; bh=QIq9oK39uPi4SXIsQuJpXmIBldX/g7/YQDHwdKe95aI=; b=hGYgd+TljkbPOr0mBGODUSMSovtt0VbFZAwNAFUaB/y06xMvsqhHvsgKDYW4zAG7dQ1falGx pZpotQYjVIaBprsowYnVtzME1HcTPqpfQfIcTZqJiWztP+QL+yMD2NPy; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Subject: A panic with the latest... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:01:24 -0000 Well: I updated everything this AM.. and just got around to rebuilding my XEON machine (Dell 2.8 gig .. hyperthreaded). Built a witness kernel (I have been running with that lately).. and rebooted it... It never came back.. so out to the barn to check on it.. and I see: panic: lock(htploc) sleep mutex does not match earlier(spin mutex) lock Anyone ever see this yet? I am rebuilding with a non-witness (invariants only) kernel.. and see if that boots :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:05:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62A1516A417 for ; Tue, 16 Jan 2007 23:05:46 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E0A4913C45D for ; Tue, 16 Jan 2007 23:05:45 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H6xMz-0002Ig-03 for freebsd-current@freebsd.org; Wed, 17 Jan 2007 00:05:33 +0100 Received: from 89-172-46-21.adsl.net.t-com.hr ([89.172.46.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Jan 2007 00:05:32 +0100 Received: from ivoras by 89-172-46-21.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Jan 2007 00:05:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 17 Jan 2007 00:09:09 +0100 Lines: 41 Message-ID: References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE32799F86C4C2698F5B23009" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-46-21.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) In-Reply-To: X-Enigmail-Version: 0.94.1.2 Sender: news Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:05:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE32799F86C4C2698F5B23009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kip Macy wrote: > On 1/16/07, Ivan Voras wrote: >> But it does seem to hurt the performance a bit - maybe it's time to ad= d >> another CPU option like I586_CPU and I686_CPU? >=20 > Unless there is a compelling reason not to do so, I think that that > would be a good idea. Maybe even someone finds a way to get optimized versions of memcpy in the kernel :) I was thinking: AFAIK the only major stopper is context saving of the various "auxiliary" registers - FPU, MMX, SSE, right? But is it an all-or-nothing situation? I.e. does it make sense (can it be done?) to just elect to save the MMX context? (AFAIK they are different registers than SSE, but overlay FPU registers?) The idea is to save something smaller than the full set. --------------enigE32799F86C4C2698F5B23009 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrVsWldnAQVacBcgRAsWdAJ0b0wADILB8XkF3D6/6N6mmrfQ4XQCeII3v ApZ4f6CQNj9+nB+FcULfH3A= =82nr -----END PGP SIGNATURE----- --------------enigE32799F86C4C2698F5B23009-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:25:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8835116A4B3 for ; Tue, 16 Jan 2007 23:25:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1A38213C459 for ; Tue, 16 Jan 2007 23:25:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so25917nfc for ; Tue, 16 Jan 2007 15:25:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=unHSmBAgHBl2oawC1ES6U9y1AHkT+ydZlxTw7hRj/fNl9TncmL0vLUd0KMpElLvdSzj4QkZaa6C1cv+HLfJBMIdYXsJmu23u1wwdyTH7P97Sxn/dOtLg80KoKHblMY77yuQlBhsceo/vvFtcJqdzrAd2jzyTKI6rq9aXY/418/4= Received: by 10.49.28.3 with SMTP id f3mr32690nfj.1168989914143; Tue, 16 Jan 2007 15:25:14 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 15:25:14 -0800 (PST) Message-ID: <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> Date: Wed, 17 Jan 2007 00:25:14 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> X-Google-Sender-Auth: 81be34d649c48d7f Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:25:19 -0000 2007/1/17, Ivan Voras : > Kip Macy wrote: > > On 1/16/07, Ivan Voras wrote: > >> But it does seem to hurt the performance a bit - maybe it's time to add > >> another CPU option like I586_CPU and I686_CPU? > > > > Unless there is a compelling reason not to do so, I think that that > > would be a good idea. > > Maybe even someone finds a way to get optimized versions of memcpy in > the kernel :) > > I was thinking: AFAIK the only major stopper is context saving of the > various "auxiliary" registers - FPU, MMX, SSE, right? But is it an > all-or-nothing situation? I.e. does it make sense (can it be done?) to > just elect to save the MMX context? (AFAIK they are different registers > than SSE, but overlay FPU registers?) The idea is to save something > smaller than the full set. When I implemented fpu copy into the kernel I had a lot of thinking about this and I think it is possible at least with some restrictions. For example, for an xmm copy you would just save 8 registers content but you have to ensure no pending FPU exceptions will break your kernel and so you should preserve a clean copy of FPU state or, treact the corner cases you can get. For xmm, after some very productive discussions with bde@, we arrived at the conclusion that should be pretty safe to just have an 16 byte aligned buffer for registers saving (in this way you can use 8 movdqa for saving them) but I didn't end to play with it. (My implementation should deal with the problem of pinning the scheduler too, in order to avoid a wrong reading of per-cpu datas). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:31:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDBB516A407 for ; Tue, 16 Jan 2007 23:31:57 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 654EB13C44C for ; Tue, 16 Jan 2007 23:31:57 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 15:31:57 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0GNVv5l017300 for ; Tue, 16 Jan 2007 15:31:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0GNVQiS012974 for ; Tue, 16 Jan 2007 15:31:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 15:31:56 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 15:31:56 -0800 Message-ID: <45AD6031.7090809@cisco.com> Date: Tue, 16 Jan 2007 18:30:57 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Randall Stewart References: <45AD5908.6090105@cisco.com> In-Reply-To: <45AD5908.6090105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 23:31:56.0403 (UTC) FILETIME=[82CB7C30:01C739C6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=700; t=1168990317; x=1169854317; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20panic=20with=20the=20latest... |Sender:=20; bh=aqDn9ezGDJNqTbMVFQ/McQWDAsSCGMgAsNgaUblUmrA=; b=jS2EfWE03oDKtr/rTI2cK+zloWpTaYMGz30ycNK480KFeiH1MskAOInzDpfz6xhlcZGqRRDO z1Yid32qzzK3S6A5643Jh9l2vnNfK4pXBY2P+dNAVul9nhbSrPDTmS2f; Authentication-Results: sj-dkim-8; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); Cc: freebsd-current@freebsd.org Subject: Re: A panic with the latest... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:31:57 -0000 Randall Stewart wrote: > Well: > > I updated everything this AM.. and just > got around to rebuilding my XEON machine > (Dell 2.8 gig .. hyperthreaded). > > Built a witness kernel (I have been running > with that lately).. and rebooted it... > > It never came back.. so out to the barn to check > on it.. and I see: > > panic: lock(htploc) sleep mutex does not match earlier(spin mutex) lock > > Anyone ever see this yet? > > I am rebuilding with a non-witness (invariants only) kernel.. and > see if that boots :-) > > R Ok I just confirmed.. with witness off it boots.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:34:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ED5116A407 for ; Tue, 16 Jan 2007 23:34:35 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 35D2F13C45E for ; Tue, 16 Jan 2007 23:34:34 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1676854uge for ; Tue, 16 Jan 2007 15:34:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fjFFFicid4J/XuJ2aXt+yqFDvE31qfqqMiQjz3JEoKG2p7A3UvBVYmXfyGy2YTHefsrOb07BTEamNCZezDDEjZueHSgHk8dPr9rx8wtOywkDrOD/9VlLD0ce45FWSG9FQ+rsrN1eJ0yYfQd1n16NW3okE9XkdibYjJtR+RqMlzs= Received: by 10.82.138.6 with SMTP id l6mr1382937bud.1168990471744; Tue, 16 Jan 2007 15:34:31 -0800 (PST) Received: by 10.82.191.16 with HTTP; Tue, 16 Jan 2007 15:34:31 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 15:34:31 -0800 From: "Kip Macy" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:34:35 -0000 > Maybe even someone finds a way to get optimized versions of memcpy in > the kernel :) > > I was thinking: AFAIK the only major stopper is context saving of the > various "auxiliary" registers - FPU, MMX, SSE, right? But is it an > all-or-nothing situation? I.e. does it make sense (can it be done?) to > just elect to save the MMX context? (AFAIK they are different registers > than SSE, but overlay FPU registers?) The idea is to save something > smaller than the full set. It makes a huge difference in a proprietary file serving appliance that I know of. However, past measurements on FreeBSD have supposedly indicated that it isn't that big win as a result of increased context switch time. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:39:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FFB416A412 for ; Tue, 16 Jan 2007 23:39:30 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.freebsd.org (Postfix) with SMTP id 9F7B513C441 for ; Tue, 16 Jan 2007 23:39:29 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 35412 invoked from network); 16 Jan 2007 23:12:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zSFLsghiXjulBTZCcIRVCjplH+OWHij39z72w2IuJoltkw/RlgspnswMeIZGI1q1zJmgIqmHdZ0IkMH6S/KdZj/cGIiXXFhIQKJm02iLZAD7CB+VYZSOt5e0FsWFjzhaOoi5QByXihZNywbteMy3TdEtimClkFFLQsbd9vihnx8= ; Received: from unknown (HELO ?172.16.0.200?) (mikej@rogers.com@74.111.253.239 with plain) by smtp102.rog.mail.re2.yahoo.com with SMTP; 16 Jan 2007 23:12:48 -0000 X-YMail-OSG: ChVx5UEVM1nYP7s3yXEkA45MXBPi3bOsH.GWJSV_5KF1E4SJD21vhF9TfYFtgbuefA-- Message-ID: <45AD5BEF.4070406@rogers.com> Date: Tue, 16 Jan 2007 18:12:47 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kip Macy References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607250814m1a476f09p2d962dedc0c99be1@mail.gmail.com> <200607251232.51230.jhb@freebsd.org> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nick Evans , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:39:30 -0000 Kip Macy wrote: > x86 pre-P4 had 32-byte cache lines. Thus older processors will not > benefit. What about AMDs line of processors? From owner-freebsd-current@FreeBSD.ORG Tue Jan 16 23:53:07 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 147C716A412 for ; Tue, 16 Jan 2007 23:53:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id A3CF413C46A for ; Tue, 16 Jan 2007 23:53:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so31316nfc for ; Tue, 16 Jan 2007 15:53:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sjITAHlp4rzTPLQkmYHBU6fTr6OSEaJnUg5wG7abqBnZ4tZRmBAxrjDXjbOSMBgnjYGdxS7+ysdNFwHVDMV6LRGercJYg+94GQyHIifa3RfCpCYEh/s02jtcUvjyYqtuI8a4Ge0iW9CFZhAs54chOD1rEI4PuEbrUzKqPiEMyKc= Received: by 10.48.14.4 with SMTP id 4mr92782nfn.1168991585474; Tue, 16 Jan 2007 15:53:05 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 15:53:05 -0800 (PST) Message-ID: <3bbf2fe10701161553t4de63940nc6ca7538eb9f264f@mail.gmail.com> Date: Wed, 17 Jan 2007 00:53:05 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Randall Stewart" In-Reply-To: <45AD6031.7090809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45AD5908.6090105@cisco.com> <45AD6031.7090809@cisco.com> X-Google-Sender-Auth: 8c5717d54ead03d0 Cc: freebsd-current@freebsd.org Subject: Re: A panic with the latest... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 23:53:07 -0000 2007/1/17, Randall Stewart : > Randall Stewart wrote: > > Well: > > > > I updated everything this AM.. and just > > got around to rebuilding my XEON machine > > (Dell 2.8 gig .. hyperthreaded). > > > > Built a witness kernel (I have been running > > with that lately).. and rebooted it... > > > > It never came back.. so out to the barn to check > > on it.. and I see: > > > > panic: lock(htploc) sleep mutex does not match earlier(spin mutex) lock > > > > Anyone ever see this yet? > > > > I am rebuilding with a non-witness (invariants only) kernel.. and > > see if that boots :-) > > > > R > Ok > > I just confirmed.. with witness off it boots.. Probabilly the htploc just changed its nature inside the code and has not been updated into the witness static table of locks (kern/subr_witness.c). Change the entry. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 00:52:05 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7FB316A407; Wed, 17 Jan 2007 00:52:05 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 281E313C457; Wed, 17 Jan 2007 00:52:05 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.6) with ESMTP id l0H0U0NS095908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 16:30:04 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <45AD6DFA.6030808@FreeBSD.org> Date: Tue, 16 Jan 2007 16:29:46 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Attilio Rao References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> In-Reply-To: <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 00:52:06 -0000 Attilio Rao wrote: > 2007/1/17, Ivan Voras : >> Kip Macy wrote: >> > On 1/16/07, Ivan Voras wrote: >> >> But it does seem to hurt the performance a bit - maybe it's time to >> add >> >> another CPU option like I586_CPU and I686_CPU? >> > >> > Unless there is a compelling reason not to do so, I think that that >> > would be a good idea. >> >> Maybe even someone finds a way to get optimized versions of memcpy in >> the kernel :) >> >> I was thinking: AFAIK the only major stopper is context saving of the >> various "auxiliary" registers - FPU, MMX, SSE, right? But is it an >> all-or-nothing situation? I.e. does it make sense (can it be done?) to >> just elect to save the MMX context? (AFAIK they are different registers >> than SSE, but overlay FPU registers?) The idea is to save something >> smaller than the full set. > > When I implemented fpu copy into the kernel I had a lot of thinking > about this and I think it is possible at least with some restrictions. > For example, for an xmm copy you would just save 8 registers content > but you have to ensure no pending FPU exceptions will break your > kernel and so you should preserve a clean copy of FPU state or, treact > the corner cases you can get. > For xmm, after some very productive discussions with bde@, we arrived > at the conclusion that should be pretty safe to just have an 16 byte > aligned buffer for registers saving (in this way you can use 8 movdqa > for saving them) but I didn't end to play with it. > (My implementation should deal with the problem of pinning the > scheduler too, in order to avoid a wrong reading of per-cpu datas). I might be wrong, but I think the DragonFly has solved this issue (i.e. optimized memcpy in the kernel) somehow quite some time ago. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 00:55:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5AF016A412 for ; Wed, 17 Jan 2007 00:55:12 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3C7ED13C45E for ; Wed, 17 Jan 2007 00:55:12 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so42429nfc for ; Tue, 16 Jan 2007 16:55:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UiWS5XqcE4hMR3V9L1sJu0rEyJ43vIfQY1xCZqsykuUJFCH64ppkLmql5nbeHtAYPLjGJLDhzwuPsaHGcisnLBC1mzda88EWN9xjuonM1rOwyPQYRR4DaIJhxT/40VrHZKzEs8pfFQz6U4OL6byknKGo8GTbCLzuzJA7NOuSVIE= Received: by 10.49.93.4 with SMTP id v4mr109303nfl.1168995309825; Tue, 16 Jan 2007 16:55:09 -0800 (PST) Received: by 10.48.238.9 with HTTP; Tue, 16 Jan 2007 16:55:09 -0800 (PST) Message-ID: <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> Date: Wed, 17 Jan 2007 01:55:09 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Maxim Sobolev" In-Reply-To: <45AD6DFA.6030808@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> X-Google-Sender-Auth: 156349cc4e226549 Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 00:55:13 -0000 2007/1/17, Maxim Sobolev : > Attilio Rao wrote: > > 2007/1/17, Ivan Voras : > >> Kip Macy wrote: > >> > On 1/16/07, Ivan Voras wrote: > >> >> But it does seem to hurt the performance a bit - maybe it's time to > >> add > >> >> another CPU option like I586_CPU and I686_CPU? > >> > > >> > Unless there is a compelling reason not to do so, I think that that > >> > would be a good idea. > >> > >> Maybe even someone finds a way to get optimized versions of memcpy in > >> the kernel :) > >> > >> I was thinking: AFAIK the only major stopper is context saving of the > >> various "auxiliary" registers - FPU, MMX, SSE, right? But is it an > >> all-or-nothing situation? I.e. does it make sense (can it be done?) to > >> just elect to save the MMX context? (AFAIK they are different registers > >> than SSE, but overlay FPU registers?) The idea is to save something > >> smaller than the full set. > > > > When I implemented fpu copy into the kernel I had a lot of thinking > > about this and I think it is possible at least with some restrictions. > > For example, for an xmm copy you would just save 8 registers content > > but you have to ensure no pending FPU exceptions will break your > > kernel and so you should preserve a clean copy of FPU state or, treact > > the corner cases you can get. > > For xmm, after some very productive discussions with bde@, we arrived > > at the conclusion that should be pretty safe to just have an 16 byte > > aligned buffer for registers saving (in this way you can use 8 movdqa > > for saving them) but I didn't end to play with it. > > (My implementation should deal with the problem of pinning the > > scheduler too, in order to avoid a wrong reading of per-cpu datas). > > I might be wrong, but I think the DragonFly has solved this issue (i.e. > optimized memcpy in the kernel) somehow quite some time ago. Dragonfly saves the whole context (xmm + mmx + fpu state). It is a too heavy mechanism ATM for us (and for them too I suspect). The don't need to deal with pinning too, BTW. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 01:39:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A562216A412; Wed, 17 Jan 2007 01:39:11 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 85BF113C448; Wed, 17 Jan 2007 01:39:11 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0H1d89A012638; Tue, 16 Jan 2007 17:39:08 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0H1d8tO012637; Tue, 16 Jan 2007 17:39:08 -0800 (PST) (envelope-from rizzo) Date: Tue, 16 Jan 2007 17:39:08 -0800 From: Luigi Rizzo To: freebsd-current@freebsd.org Message-ID: <20070116173908.B11177@xorpc.icir.org> References: <200701162352.39225.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200701162352.39225.max@love2party.net>; from max@love2party.net on Tue, Jan 16, 2007 at 11:52:37PM +0100 Cc: Max Laier , hselasky@freebsd.org, freebsd-usb@freebsd.org Subject: new usb stack (was Re: FreeBSD Status Report Fourth Quarter 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 01:39:11 -0000 [i avoid the cross-post to hackers as my reply mostly affects -current and -usb. hope i don't miss anyone interested. I am also Bcc-ing a few people who might have something to say on the subject] On Tue, Jan 16, 2007 at 11:52:37PM +0100, Max Laier wrote: ... > FreeBSD Status Report thanks all for the long and interesting report, i see lot of stuff going on. I have a couple of usb-related comments: > New USB Stack > > URL: > http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects > /usb/src/sys/dev/usb > URL: http://www.turbocat.net/~hselasky/usb4bsd > > Contact: Hans Petter Sirevaag Selasky > > During the last three months there has not been so much activity in > the USB project. Some regression issues have been reported and fixed. > Bernd Walter reports that he has got the new USB stack working on ARM > processors with some minor tweaks. Markus Brueffer reports that he is > working on the USB HID parser and support. A current issue with the > new USB stack is that the EHCI driver does not work on the Sparc64 > architecture. If someone has got a Sparc64 with FreeBSD 7-CURRENT on > and can lend the USB project the root password, a serial console and a > USB test device, for example a USB memory stick, that would be much > appreciated. Another unresolved issue is that the ural(4) USB device > driver does not always work. This is currently being worked on. > > If you want to test the new USB stack, check out the USB perforce tree > or download the SVN version of the USB driver from my USB homepage. At > the moment the tarballs are a little out of date. > > Ideas and comments with regard to the new USB API are welcome at > freebsd-usb@FreeBSD.org . I just happen to have spent some time on the USB stack trying to put together support for some webcams i have. Apart from the details on this specific work, which i started summarising at http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html there are a few things that i would like to say/ask: 1. Migration strategy to the new usb stack One of the reasons to move to the new usb stack that Hans mentions above, is the lack of high speed isochronous support in the 'old' usb stack (i.e. the one in HEAD and RELENG_6 and below) I am particularly concerned about because it has to do with camera support. One issue with the new stack, however, is the different kernel API which is not backward compatible, and, as i discussed with Hans at length, this could be a significant obstacle to its adoption as it basically cuts support for third party drivers. The obvious solution to this problem is building an emulation layer on top of the new stack to offer a backward compatible API to old style drivers. This would serve both as a tool to support re-building of old-style drivers, and as an indirect source of documentation for adapting drivers to the new style. Building this emulation layer poses some difficulties, but in a relatively long phone call with Hans tonight we probably came up with a reasonable plan to solve the locking issues that existed in his previous implementation of the compatibility layer (removed some time ago because of these locking issues, you can see some detail in perforce http://perforce.freebsd.org/changeView.cgi?CH=107765 ). I hope Hans will follow up with more details, but i am confident that this approach will provide us with a suitable upgrade path that does not cost us regressions. 2. Linux compatibility layer. The discussion, as well as my recent work on webcams and other work from Raaf on DVB drivers (see http://raaf.atspace.org/dvbusb/index.html; and Raaf is in Bcc so he may comment if he likes) raised another issue, namely a linux compatibility layer. The linux community has developed a relatively large set of drivers for USB devices, for many sort of devices which we do not support at the moment e.g. webcams, DVB receivers, even 802.11 cards. Because a lot of these driver are built by reverse-engineering, the code tends to be on the obfuscated side, and doing a 'clueful' rewrite is typically not a viable option unless one has plenty of time to dedicate to the task. What one ends up doing is, instead, is a mechanical conversion, #ifdef'ing out the glue module and device hooks that gets replaced with FreeBSD equivalents, and then trying to translate the linux kernel API into more-or-less equivalent FreeBSD code. As i said this is a mechanical conversion, and it would be a tremendous help to have a linux-compatibility layer (library + macros) to support this work at least partially. More than comments like "yeah it would be great" i am wondering if there is any work around already done on this area. Surely people who ported linux drivers to FreeBSD have some clue, and maybe their set of macros/working notes used in the process. I have done something like this myself. I would be grateful if people interested in this could provide their input and/or contact me so we can hopefully set up a small project to implement such a compatibility layer. Part of it is generic, e.g. the module glue, the basic kernel services such as *malloc(), printk() and so on; part of it is usb-specific e.g. providing an emulation of linux mechanism for using the usb subsystems, e.g. urb's and so on. Finally, part of it could be related to the network subsystem as a number of devices we might be interested in are the various 802.11 USB dongles, none of them is currently supported on FreeBSD. Feedback welcome cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 05:39:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 162DA16A407 for ; Wed, 17 Jan 2007 05:39:23 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A69B113C428 for ; Wed, 17 Jan 2007 05:39:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-97.lns1.adl2.internode.on.net [203.122.211.97]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0H5d73O048623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 16:09:15 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 17 Jan 2007 16:08:48 +1030 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1339046.n1MFc1YG3j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701171608.49339.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Subject: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 05:39:23 -0000 --nextPart1339046.n1MFc1YG3j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have a WPA-EAP network setup (to a WRT54G with OpenRadius which=20 authenticates against an OpenLDAP server on my FreeBSD server), however qui= te=20 often dhclient fails to get a lease at first go. My wpa_supplicant file looks like.. network=3D{ =A0 =A0 =A0 =A0 ssid=3D"dons" =A0 =A0 =A0 =A0 scan_ssid=3D1 =A0 =A0 =A0 =A0 key_mgmt=3DWPA-EAP =A0 =A0 =A0 =A0 identity=3D"username" =A0 =A0 =A0 =A0 password=3D"password" =A0 =A0 =A0 =A0 phase2=3D"auth=3DPAP" } I have the following in rc.conf.. ifconfig_ath0=3D"WPA DHCP" background_dhclient=3D"YES" If I kill dhclient and restart it I can get a lease just fine. I don't see = the=20 problem on a WPA-TKIP network. I think the problem is that the ath interface comes up but no packets can b= e=20 transferred because WPA stuff is still happening the initial requests get=20 lost. I note that it takes Windows a long time to get a lease - it spends a while= =20 saying "waiting for network to become ready". =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1339046.n1MFc1YG3j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFrbZp5ZPcIHs/zowRArKNAKClS3RWhJF97QF5Ccu7Bk+5DuPxPQCgn5b1 vua/7L3HDg9kFY4Izch0Ups= =l6Wc -----END PGP SIGNATURE----- --nextPart1339046.n1MFc1YG3j-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 05:47:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED9AD16A407 for ; Wed, 17 Jan 2007 05:47:13 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8991B13C457 for ; Wed, 17 Jan 2007 05:47:13 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so93373nfc for ; Tue, 16 Jan 2007 21:47:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FNGODHNIAYbVJJRZkt+8d6xswg/e6FqAUrh80V+zBO6/ZR4o/cU7fF6+m4FYfNo746NvlVpf9B/EVwQ2GmSBYCjPNm7frexnTBFIvbmvOiLxHe8aJJz4GsUpiJnTe0OauYN7tMjn90HjNxBzpMJHluPEDQxUcCNZeMyuYBqPpIA= Received: by 10.82.179.9 with SMTP id b9mr1440760buf.1169012831258; Tue, 16 Jan 2007 21:47:11 -0800 (PST) Received: by 10.82.191.16 with HTTP; Tue, 16 Jan 2007 21:47:11 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 21:47:11 -0800 From: "Kip Macy" To: "Daniel O'Connor" In-Reply-To: <200701171608.49339.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200701171608.49339.doconnor@gsoft.com.au> Cc: freebsd-current@freebsd.org Subject: Re: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 05:47:14 -0000 > > I note that it takes Windows a long time to get a lease - it spends a while > saying "waiting for network to become ready". > How long is "a long time"? If it is greater than 60 seconds you can set the timeout to greater than 60s in dhclient.conf. Alternatively, you can set the retry to a short interval. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 06:32:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86A2F16A40F for ; Wed, 17 Jan 2007 06:32:52 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE3413C465 for ; Wed, 17 Jan 2007 06:32:52 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.105] ([10.0.0.105]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l0H6Wnsb046963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 22:32:49 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45ADC311.90008@errno.com> Date: Tue, 16 Jan 2007 22:32:49 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Daniel O'Connor" References: <200701171608.49339.doconnor@gsoft.com.au> In-Reply-To: <200701171608.49339.doconnor@gsoft.com.au> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 06:32:52 -0000 Daniel O'Connor wrote: > Hi, > I have a WPA-EAP network setup (to a WRT54G with OpenRadius which > authenticates against an OpenLDAP server on my FreeBSD server), however quite > often dhclient fails to get a lease at first go. > > My wpa_supplicant file looks like.. > network={ > ssid="dons" > scan_ssid=1 > key_mgmt=WPA-EAP > identity="username" > password="password" > phase2="auth=PAP" > } > > I have the following in rc.conf.. > ifconfig_ath0="WPA DHCP" > background_dhclient="YES" > > If I kill dhclient and restart it I can get a lease just fine. I don't see the > problem on a WPA-TKIP network. Sounds like an issue with dhclient. I rarely use anything but WPA-PSK so haven't noticed issues. It would be useful to get a wpa log to see how long it's taking to authenticate. It'd be nice if dhclient were triggered by authentication rather than association as packets cannot pass until before. I've considered changing things to work in this way. > > I think the problem is that the ath interface comes up but no packets can be > transferred because WPA stuff is still happening the initial requests get > lost. But dhclient should retry and get a lease w/o your restarting it. > > I note that it takes Windows a long time to get a lease - it spends a while > saying "waiting for network to become ready". > From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 06:50:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6438116A40F for ; Wed, 17 Jan 2007 06:50:59 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E705F13C448 for ; Wed, 17 Jan 2007 06:50:58 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-97.lns1.adl2.internode.on.net [203.122.211.97]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0H6odA1051519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 17:20:53 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Kip Macy" Date: Wed, 17 Jan 2007 17:20:04 +1030 User-Agent: KMail/1.9.5 References: <200701171608.49339.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1490697.69p0qNRZdv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701171720.14983.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 06:50:59 -0000 --nextPart1490697.69p0qNRZdv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 January 2007 16:17, Kip Macy wrote: > > I note that it takes Windows a long time to get a lease - it spends a > > while saying "waiting for network to become ready". > > How long is "a long time"? If it is greater than 60 seconds you can > set the timeout to greater than 60s in dhclient.conf. Alternatively, > you can set the retry to a short interval. 60 seconds wouldn't be far off the mark.. Good point about dhclient.conf I hadn't though about checking it for knobs.. I am wondering if there is something peculiar with my (AP) setup that cause= s=20 it to take so long to auth.. Although I am loathe to fiddle with it because= =20 it was a bit of a PITA to debug in the first place :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1490697.69p0qNRZdv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFrccm5ZPcIHs/zowRAlwIAKCD9ol8N/8KUJ/M65Lga8Src/eUaQCeK6Ac WryjjZDl0bzV/3nm4YxSWN0= =EchP -----END PGP SIGNATURE----- --nextPart1490697.69p0qNRZdv-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 10:46:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 870C916A494 for ; Wed, 17 Jan 2007 10:46:11 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC2E13C469 for ; Wed, 17 Jan 2007 10:46:10 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-97.lns1.adl2.internode.on.net [203.122.211.97]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id l0HAhqc6060852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 21:14:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Sam Leffler Date: Wed, 17 Jan 2007 21:12:39 +1030 User-Agent: KMail/1.9.5 References: <200701171608.49339.doconnor@gsoft.com.au> <45ADC311.90008@errno.com> In-Reply-To: <45ADC311.90008@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2664443.hPtS97LCoD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701172113.27380.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.57 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 10:46:11 -0000 --nextPart2664443.hPtS97LCoD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 January 2007 17:02, Sam Leffler wrote: > > If I kill dhclient and restart it I can get a lease just fine. I don't > > see the problem on a WPA-TKIP network. > > Sounds like an issue with dhclient. I rarely use anything but WPA-PSK > so haven't noticed issues. I just noticed I had added some stuff to my dhclient.conf file which will=20 cause problems > It would be useful to get a wpa log to see how long it's taking to > authenticate. It'd be nice if dhclient were triggered by authentication > rather than association as packets cannot pass until before. I've > considered changing things to work in this way. I think currently dhclient gets run by devd because the interface comes up. > > I think the problem is that the ath interface comes up but no packets c= an > > be transferred because WPA stuff is still happening the initial requests > > get lost. > > But dhclient should retry and get a lease w/o your restarting it. Yes but its default time for this is 5 minutes. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2664443.hPtS97LCoD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFrf3P5ZPcIHs/zowRAmnUAJ9LQ0lgDm0CSmNA4VZxomXw3AiZIACfX89c 1bydYS7ZZQVldo/Ikuz2USA= =mURT -----END PGP SIGNATURE----- --nextPart2664443.hPtS97LCoD-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 04:50:45 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EDD416A40F; Wed, 17 Jan 2007 04:50:45 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3A90F13C428; Wed, 17 Jan 2007 04:50:45 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id D19F46E2C7; Wed, 17 Jan 2007 15:50:41 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id C6C8A2741B; Wed, 17 Jan 2007 15:50:42 +1100 (EST) Date: Wed, 17 Jan 2007 15:50:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ivan Voras In-Reply-To: Message-ID: <20070117134022.V18339@besplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 17 Jan 2007 12:35:46 +0000 Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 04:50:45 -0000 On Wed, 17 Jan 2007, Ivan Voras wrote: > Kip Macy wrote: >>> Maybe even someone finds a way to get optimized versions of memcpy in >>> the kernel :) > >> It makes a huge difference in a proprietary file serving appliance >> that I know of. > > Beneficial difference? Heheh. >> However, past measurements on FreeBSD have supposedly >> indicated that it isn't that big win as a result of increased context >> switch time. No, they indicated that the win is not very large (sometimes negative), and is very machine dependent. E.g., it is a small pessimization all 64 bit i386's running 64-bit mode -- that's just all i386's you would want to buy now. On other CPU classes: P2 (my old Celeron): +- epsilon difference P3 (freefall): +- epsilon difference P4 (nosedive's Xeon): movdqa 17% faster than movsl, but all other cached moves slower using MMX or SSE[1-2]; movnt with block prefetch 60% faster than movsl with no prefetch, but < 5% faster with no prefetch for both. AXP: (my 5 year old system with a newer CPU): movq through MMX is 60% faster than movsl for cached moves, but movdqa through XMM is only 4% faster. movnt with block prefetch is 155% faster than movsl with no prefetch, and 73% faster with no prefetch for both. A64 in 32-bit mode: in between P4 and AXP (closer to AXP). movsl doesn't lose by so much, and prefetchnta actually works so block prefetch is not needed and there is a better chance of prefetching helping more than benchmarks. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 12:00:46 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D73B16A5B3; Wed, 17 Jan 2007 12:00:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id EDACB13C44B; Wed, 17 Jan 2007 12:00:45 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 5DC1D6E17F; Wed, 17 Jan 2007 23:00:42 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 580638C02; Wed, 17 Jan 2007 23:00:43 +1100 (EST) Date: Wed, 17 Jan 2007 23:00:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ivan Voras In-Reply-To: <20070117134022.V18339@besplex.bde.org> Message-ID: <20070117224812.Q23194@besplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <20070117134022.V18339@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 17 Jan 2007 12:36:37 +0000 Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 12:00:46 -0000 On Wed, 17 Jan 2007, I wrote: > ... > P4 (nosedive's Xeon): movdqa 17% faster than movsl, but all other cached > moves slower using MMX or SSE[1-2]; movnt with block prefetch 60% faster > than movsl with no prefetch, but < 5% faster with no prefetch for both. > AXP: (my 5 year old system with a newer CPU): movq through MMX is 60% > faster than movsl for cached moves, but movdqa through XMM is only 4% > faster. movnt with block prefetch is 155% faster than movsl with no > prefetch, and 73% faster with no prefetch for both. > A64 in 32-bit mode: in between P4 and AXP (closer to AXP). movsl doesn't > lose by so much, and prefetchnta actually works so block prefetch is > not needed and there is a better chance of prefetching helping more > than benchmarks. And MMX/XMM registers ar not needed to get movnt on machines with SSE2, since movnti is part of SSE2. This reduces the advantages of using MMX/XMM registers on P4's and A64's in 32-bit mode to the non-nt parts of the above (fully cached case), which I think are less important than the nt parts. Another complication with movnt is that its semantics are very machine- dependent. On AXP, movnt to a target that happens to be in the L1 cache goes at L1 cache speed, so it is probably good to use movnt blindly (except movnti doesn't exist so you can't just substitute movl with movnti and must use XMM registers with all their complications), but on P4 and A64, movnt to a cached target goes at main memory speed so you only want to use it intentionally to avoid thrashing the caches. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 15:41:17 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B97516A417 for ; Wed, 17 Jan 2007 15:41:17 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a19.dreamhost.com (sd-green-bigip-74.dreamhost.com [208.97.132.74]) by mx1.freebsd.org (Postfix) with ESMTP id EDBA413C4F0 for ; Wed, 17 Jan 2007 15:41:09 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.203.29.31]) by spunkymail-a19.dreamhost.com (Postfix) with ESMTP id EA9C710CDA; Wed, 17 Jan 2007 07:41:05 -0800 (PST) Date: Wed, 17 Jan 2007 13:41:00 -0200 From: Ricardo Nabinger Sanchez To: Bruce Evans Message-Id: <20070117134100.94bb6137.rnsanchez@wait4.org> In-Reply-To: <20070117134022.V18339@besplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <20070117134022.V18339@besplex.bde.org> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.3.0+svn (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 15:41:17 -0000 On Wed, 17 Jan 2007 15:50:41 +1100 (EST) Bruce Evans wrote: > AXP: (my 5 year old system with a newer CPU): movq through MMX is 60% > faster than movsl for cached moves, but movdqa through XMM is only 4% > faster. movnt with block prefetch is 155% faster than movsl with no > prefetch, and 73% faster with no prefetch for both. > A64 in 32-bit mode: in between P4 and AXP (closer to AXP). movsl doesn't > lose by so much, and prefetchnta actually works so block prefetch is > not needed and there is a better chance of prefetching helping more > than benchmarks. This PDF is somewhat dated, but perhaps some of it still applies today: http://cdrom.amd.com/devconn/events/AMD_block_prefetch_paper.pdf -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 16:10:33 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E3816A415 for ; Wed, 17 Jan 2007 16:10:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 7A48D13C4BA for ; Wed, 17 Jan 2007 16:10:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l0HG997J001702; Wed, 17 Jan 2007 10:09:10 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l0HG96uj001701; Wed, 17 Jan 2007 10:09:06 -0600 (CST) (envelope-from brooks) Date: Wed, 17 Jan 2007 10:09:06 -0600 From: Brooks Davis To: Sam Leffler Message-ID: <20070117160906.GB1333@lor.one-eyed-alien.net> References: <200701171608.49339.doconnor@gsoft.com.au> <45ADC311.90008@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <45ADC311.90008@errno.com> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 17 Jan 2007 10:09:10 -0600 (CST) Cc: freebsd-current@freebsd.org Subject: Re: WPA-EAP problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 16:10:33 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 16, 2007 at 10:32:49PM -0800, Sam Leffler wrote: > Daniel O'Connor wrote: > > Hi, > > I have a WPA-EAP network setup (to a WRT54G with OpenRadius which=20 > > authenticates against an OpenLDAP server on my FreeBSD server), however= quite=20 > > often dhclient fails to get a lease at first go. > >=20 > > My wpa_supplicant file looks like.. > > network=3D{ > > ssid=3D"dons" > > scan_ssid=3D1 > > key_mgmt=3DWPA-EAP > > identity=3D"username" > > password=3D"password" > > phase2=3D"auth=3DPAP" > > } > >=20 > > I have the following in rc.conf.. > > ifconfig_ath0=3D"WPA DHCP" > > background_dhclient=3D"YES" > >=20 > > If I kill dhclient and restart it I can get a lease just fine. I don't = see the=20 > > problem on a WPA-TKIP network. >=20 > Sounds like an issue with dhclient. I rarely use anything but WPA-PSK > so haven't noticed issues. >=20 > It would be useful to get a wpa log to see how long it's taking to > authenticate. It'd be nice if dhclient were triggered by authentication > rather than association as packets cannot pass until before. I've > considered changing things to work in this way. This seems like a good idea. The link isn't really up until you can actually pass packets on it. > > I think the problem is that the ath interface comes up but no > > packets can be transferred because WPA stuff is still happening the > > initial requests get lost. >=20 > But dhclient should retry and get a lease w/o your restarting it. I think this should happen, but I think the back off is random exponential so it doesn't take long to get to the point where it will appear hung because it tries for >60s. Is there an 802.11 event we could key off of to reset the timeouts when authentication occurs? -- Brooks --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFrkohXY6L6fI4GtQRAg6WAJwNzi2FBuYSaaQNhXrDw/qDOED0fwCg0c1p nbCc9giQpvPGUFEBKOweoq4= =zOf9 -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 17:31:37 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9823416A407; Wed, 17 Jan 2007 17:31:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2200813C474; Wed, 17 Jan 2007 17:31:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0HHVTRJ055288; Wed, 17 Jan 2007 12:31:29 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 17 Jan 2007 12:09:53 -0500 User-Agent: KMail/1.9.1 References: <20061130105537.A69725@xorpc.icir.org> <20061201100821.A85139@xorpc.icir.org> In-Reply-To: <20061201100821.A85139@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701171209.54142.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 17 Jan 2007 12:31:30 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2459/Tue Jan 16 17:03:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Luigi Rizzo , current@freebsd.org Subject: Re: [bug found] Re: byte swapped udp length in diskless bootp request ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 17:31:37 -0000 On Friday 01 December 2006 13:08, Luigi Rizzo wrote: > On Thu, Nov 30, 2006 at 10:55:37AM -0800, Luigi Rizzo wrote: > > i was just trying to diskless-boot a -current kernel, > > and when it was time for the kernel to acquire the address > > i was getting the usual > > > > DHCP/BOOTP timeout for server 255.255.255.255 > > > > Usually it is because of lack of connectivity, but > > a bit of inspection on the server showed (as you can see > > below) that the UDP len field is byte-swapped - the 05bc > > in the packet is in little-endian format, causing the > > server to reject it. > > [ actually, it is the IP len that is byte-swapped ] > > > I am trying to follow the code in sys/nfsclient/bootp_subr.c > > (which should send the packet) but it seemd to call sosend() > > (at line 755) to generate the packet, so it looks really strange > > that the bug is in such a central place... any ideas ? > > as a followup: > > Downgrading sys/kern/uipc_socket.c to version 1.284 make HEAD > work again with in-kernel bootp.. > > i managed to locate the bug in the following commit: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.284&r2=1.285 > > Revision 1.285 Thu Nov 2 17:45:28 2006 UTC (4 weeks ago) by andre > Branch: MAIN > Changes since 1.284: +29 -1 lines > Diff to previous 1.284 (colored) > > Use the improved m_uiotombuf() function instead of home grown sosend_copyin() > to do the userland to kernel copying in sosend_generic() and sosend_dgram(). > > sosend_copyin() is retained for ZERO_COPY_SOCKETS which are not yet supported > by m_uiotombuf(). > > I don't know exactly where the problem is, but the bug i found is triggered > by in-kernel sockets (such as the one used by the internal bootp client) > so maybe this was a case not tested by andre. > > I am unclear on where is the actual bug. hopefully something simple... Does the bootp code try to send a 0 byte packet per chance? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 17:31:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9823416A407; Wed, 17 Jan 2007 17:31:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2200813C474; Wed, 17 Jan 2007 17:31:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0HHVTRJ055288; Wed, 17 Jan 2007 12:31:29 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 17 Jan 2007 12:09:53 -0500 User-Agent: KMail/1.9.1 References: <20061130105537.A69725@xorpc.icir.org> <20061201100821.A85139@xorpc.icir.org> In-Reply-To: <20061201100821.A85139@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701171209.54142.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 17 Jan 2007 12:31:30 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2459/Tue Jan 16 17:03:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Luigi Rizzo , current@freebsd.org Subject: Re: [bug found] Re: byte swapped udp length in diskless bootp request ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 17:31:37 -0000 On Friday 01 December 2006 13:08, Luigi Rizzo wrote: > On Thu, Nov 30, 2006 at 10:55:37AM -0800, Luigi Rizzo wrote: > > i was just trying to diskless-boot a -current kernel, > > and when it was time for the kernel to acquire the address > > i was getting the usual > > > > DHCP/BOOTP timeout for server 255.255.255.255 > > > > Usually it is because of lack of connectivity, but > > a bit of inspection on the server showed (as you can see > > below) that the UDP len field is byte-swapped - the 05bc > > in the packet is in little-endian format, causing the > > server to reject it. > > [ actually, it is the IP len that is byte-swapped ] > > > I am trying to follow the code in sys/nfsclient/bootp_subr.c > > (which should send the packet) but it seemd to call sosend() > > (at line 755) to generate the packet, so it looks really strange > > that the bug is in such a central place... any ideas ? > > as a followup: > > Downgrading sys/kern/uipc_socket.c to version 1.284 make HEAD > work again with in-kernel bootp.. > > i managed to locate the bug in the following commit: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.284&r2=1.285 > > Revision 1.285 Thu Nov 2 17:45:28 2006 UTC (4 weeks ago) by andre > Branch: MAIN > Changes since 1.284: +29 -1 lines > Diff to previous 1.284 (colored) > > Use the improved m_uiotombuf() function instead of home grown sosend_copyin() > to do the userland to kernel copying in sosend_generic() and sosend_dgram(). > > sosend_copyin() is retained for ZERO_COPY_SOCKETS which are not yet supported > by m_uiotombuf(). > > I don't know exactly where the problem is, but the bug i found is triggered > by in-kernel sockets (such as the one used by the internal bootp client) > so maybe this was a case not tested by andre. > > I am unclear on where is the actual bug. hopefully something simple... Does the bootp code try to send a 0 byte packet per chance? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 18:00:13 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48AC716A54F; Wed, 17 Jan 2007 18:00:13 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1C313C455; Wed, 17 Jan 2007 18:00:13 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0HI0CTj022728; Wed, 17 Jan 2007 10:00:12 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0HI0CQR022727; Wed, 17 Jan 2007 10:00:12 -0800 (PST) (envelope-from rizzo) Date: Wed, 17 Jan 2007 10:00:12 -0800 From: Luigi Rizzo To: John Baldwin Message-ID: <20070117100012.A22625@xorpc.icir.org> References: <20061130105537.A69725@xorpc.icir.org> <20061201100821.A85139@xorpc.icir.org> <200701171209.54142.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200701171209.54142.jhb@freebsd.org>; from jhb@freebsd.org on Wed, Jan 17, 2007 at 12:09:53PM -0500 Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [bug found] Re: byte swapped udp length in diskless bootp request ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 18:00:13 -0000 On Wed, Jan 17, 2007 at 12:09:53PM -0500, John Baldwin wrote: > On Friday 01 December 2006 13:08, Luigi Rizzo wrote: > > On Thu, Nov 30, 2006 at 10:55:37AM -0800, Luigi Rizzo wrote: > > > i was just trying to diskless-boot a -current kernel, > > > and when it was time for the kernel to acquire the address > > > i was getting the usual > > > > > > DHCP/BOOTP timeout for server 255.255.255.255 > > > > > > Usually it is because of lack of connectivity, but > > > a bit of inspection on the server showed (as you can see > > > below) that the UDP len field is byte-swapped - the 05bc > > > in the packet is in little-endian format, causing the > > > server to reject it. > > > > [ actually, it is the IP len that is byte-swapped ] > > > > > I am trying to follow the code in sys/nfsclient/bootp_subr.c > > > (which should send the packet) but it seemd to call sosend() > > > (at line 755) to generate the packet, so it looks really strange > > > that the bug is in such a central place... any ideas ? > > > > as a followup: > > > > Downgrading sys/kern/uipc_socket.c to version 1.284 make HEAD > > work again with in-kernel bootp.. > > > > i managed to locate the bug in the following commit: > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.284&r2=1.285 > > > > Revision 1.285 Thu Nov 2 17:45:28 2006 UTC (4 weeks ago) by andre > > Branch: MAIN > > Changes since 1.284: +29 -1 lines > > Diff to previous 1.284 (colored) > > > > Use the improved m_uiotombuf() function instead of home grown > sosend_copyin() > > to do the userland to kernel copying in sosend_generic() and > sosend_dgram(). > > > > sosend_copyin() is retained for ZERO_COPY_SOCKETS which are not yet > supported > > by m_uiotombuf(). > > > > I don't know exactly where the problem is, but the bug i found is triggered > > by in-kernel sockets (such as the one used by the internal bootp client) > > so maybe this was a case not tested by andre. > > > > I am unclear on where is the actual bug. hopefully something simple... > > Does the bootp code try to send a 0 byte packet per chance? no, the problem was a long standing bug in the code that loops back a copy of the packet in the case of simplex interfaces doing only a shallow copy of the mbuf chain. Before the change 1.285 above, the bug was not triggered because the ip header (modified in the copy looped back) was in an mbuf so the shallow copy was enough. With 1.285, somehow the IP header ended up in the cluster and so the modifications affected also the packet that was about to be transmitted. I committed a fix shortly after the bug was detected. it needs to be revisited but for the time being it should be enough to keep us running. cheers luigi mbuf. and modifies the (shared) mbuf before it is actually transmitted on the wire. It was triggered by the above change because in the past the IP header was in a separate mbuf > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 18:00:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48AC716A54F; Wed, 17 Jan 2007 18:00:13 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1C313C455; Wed, 17 Jan 2007 18:00:13 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0HI0CTj022728; Wed, 17 Jan 2007 10:00:12 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0HI0CQR022727; Wed, 17 Jan 2007 10:00:12 -0800 (PST) (envelope-from rizzo) Date: Wed, 17 Jan 2007 10:00:12 -0800 From: Luigi Rizzo To: John Baldwin Message-ID: <20070117100012.A22625@xorpc.icir.org> References: <20061130105537.A69725@xorpc.icir.org> <20061201100821.A85139@xorpc.icir.org> <200701171209.54142.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200701171209.54142.jhb@freebsd.org>; from jhb@freebsd.org on Wed, Jan 17, 2007 at 12:09:53PM -0500 Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [bug found] Re: byte swapped udp length in diskless bootp request ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 18:00:13 -0000 On Wed, Jan 17, 2007 at 12:09:53PM -0500, John Baldwin wrote: > On Friday 01 December 2006 13:08, Luigi Rizzo wrote: > > On Thu, Nov 30, 2006 at 10:55:37AM -0800, Luigi Rizzo wrote: > > > i was just trying to diskless-boot a -current kernel, > > > and when it was time for the kernel to acquire the address > > > i was getting the usual > > > > > > DHCP/BOOTP timeout for server 255.255.255.255 > > > > > > Usually it is because of lack of connectivity, but > > > a bit of inspection on the server showed (as you can see > > > below) that the UDP len field is byte-swapped - the 05bc > > > in the packet is in little-endian format, causing the > > > server to reject it. > > > > [ actually, it is the IP len that is byte-swapped ] > > > > > I am trying to follow the code in sys/nfsclient/bootp_subr.c > > > (which should send the packet) but it seemd to call sosend() > > > (at line 755) to generate the packet, so it looks really strange > > > that the bug is in such a central place... any ideas ? > > > > as a followup: > > > > Downgrading sys/kern/uipc_socket.c to version 1.284 make HEAD > > work again with in-kernel bootp.. > > > > i managed to locate the bug in the following commit: > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.284&r2=1.285 > > > > Revision 1.285 Thu Nov 2 17:45:28 2006 UTC (4 weeks ago) by andre > > Branch: MAIN > > Changes since 1.284: +29 -1 lines > > Diff to previous 1.284 (colored) > > > > Use the improved m_uiotombuf() function instead of home grown > sosend_copyin() > > to do the userland to kernel copying in sosend_generic() and > sosend_dgram(). > > > > sosend_copyin() is retained for ZERO_COPY_SOCKETS which are not yet > supported > > by m_uiotombuf(). > > > > I don't know exactly where the problem is, but the bug i found is triggered > > by in-kernel sockets (such as the one used by the internal bootp client) > > so maybe this was a case not tested by andre. > > > > I am unclear on where is the actual bug. hopefully something simple... > > Does the bootp code try to send a 0 byte packet per chance? no, the problem was a long standing bug in the code that loops back a copy of the packet in the case of simplex interfaces doing only a shallow copy of the mbuf chain. Before the change 1.285 above, the bug was not triggered because the ip header (modified in the copy looped back) was in an mbuf so the shallow copy was enough. With 1.285, somehow the IP header ended up in the cluster and so the modifications affected also the packet that was about to be transmitted. I committed a fix shortly after the bug was detected. it needs to be revisited but for the time being it should be enough to keep us running. cheers luigi mbuf. and modifies the (shared) mbuf before it is actually transmitted on the wire. It was triggered by the above change because in the past the IP header was in a separate mbuf > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:09:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D05516A415; Wed, 17 Jan 2007 20:09:24 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9C413C428; Wed, 17 Jan 2007 20:09:23 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls242.t-com.hr (ls242.t-com.hr [195.29.150.134]) by ls405.t-com.hr (Postfix) with ESMTP id 0730C143C02; Wed, 17 Jan 2007 20:37:52 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id E272410F805F; Wed, 17 Jan 2007 20:37:51 +0100 (CET) Received: from ls242.t-com.hr (localhost.localdomain [127.0.0.1]) by ls242.t-com.hr (Qmlai) with ESMTP id C847310F803E; Wed, 17 Jan 2007 20:37:51 +0100 (CET) X-Envelope-Sender-Info: qNMqIwJL6pMxrLsv6Bv6Q4WPdw3S56b2lZWSpOFx2GhM9iIFzLoPeE8q5w/auABt X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.101] (89-172-39-6.adsl.net.t-com.hr [89.172.39.6]) by ls242.t-com.hr (Qmali) with ESMTP id 7F25B6C0036; Wed, 17 Jan 2007 20:37:51 +0100 (CET) Message-ID: <45AE7BF8.10703@fer.hr> Date: Wed, 17 Jan 2007 20:41:44 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bruce Evans References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607251004wf94e238xb5ea7a31c973817f@mail.gmail.com> <3bbf2fe10607261127p3f01a6c3w80027754f7d4e594@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <20070117134022.V18339@besplex.bde.org> <20070117224812.Q23194@besplex.bde.org> In-Reply-To: <20070117224812.Q23194@besplex.bde.org> X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig238686BF5CDEB8B50F4252DA" Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Optimized copy&move (was: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:09:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig238686BF5CDEB8B50F4252DA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bruce Evans wrote: > And MMX/XMM registers ar not needed to get movnt on machines with SSE2,= > since movnti is part of SSE2. This reduces the advantages of using MMX= /XMM > registers on P4's and A64's in 32-bit mode to the non-nt parts of the > above (fully cached case), which I think are less important than the nt= > parts. Hmm, I'm looking at i386/i386/support.s and there are several versions of bcopy and bmove functions, including some that optimize by using FPU registers (large_i586_bcopy_loop), and a version that uses movnti (sse2_pagezero), but I can't find the bit of magic which glues them to bzero() call. Also, as as I can tell by the comments, the FPU version works by manually saving context... why is this possible (i.e. won't something preempt it?) --------------enig238686BF5CDEB8B50F4252DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrnv5ldnAQVacBcgRAiR4AKCDQ6LnV8f1easSMto1WjFvD74GPgCfdciE 08MOyCrxIQhroC5tgvhqJo0= =7h/R -----END PGP SIGNATURE----- --------------enig238686BF5CDEB8B50F4252DA-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:12:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0791C16A415 for ; Wed, 17 Jan 2007 20:12:19 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4E48513C428 for ; Wed, 17 Jan 2007 20:12:18 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 17 Jan 2007 19:45:36 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.95.52] by mail.gmx.net (mp031) with SMTP; 17 Jan 2007 20:45:36 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Wed, 17 Jan 2007 20:45:34 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701172045.35137.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Subject: very high memory usage in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:12:19 -0000 Some time (probably some months) ago I occasionally noticed very high memory usage on my CURRENT notebook. I don't think this has always been the case, but I'm not 100% sure. For me, this is reproducable very easily if I view some large (3000x2000 pixels) .jpg files in konqueror. On my 6.2 system, memory usage goes up quite a bit while decoding the image, then it drops a bit. If I close the image, memory usage is normal again. On my current system, sometimes memory usage goes up very high when opening an image and doesn't go back to normal, even if I close the image. It only goes back to normal if I close konqueror. Note that I see this also with a gtk app, so this is not a KDE bug. Also, at least in konqueror, I can reproduce this with .png files, so it's also not a jpeg library bug. CURRENT and ports on both systems are up to date. I don't really know what's causing this problem. Maybe it's related to jemalloc, but I'd be surprised if no one else has noticed this before. size/res values reported by top 6.2 desktop pc with nvidia binary driver konqueror 40M/30M CURRENT notebook with the i810 driver konqueror 290M/250M Any clues or more information needed? Thanks, Stefan From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:29:55 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB71516A51B; Wed, 17 Jan 2007 20:29:55 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from relay.talkpoint.com (pobox.talkpoint.com [204.141.15.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8146A13C467; Wed, 17 Jan 2007 20:29:55 +0000 (UTC) (envelope-from nevans@talkpoint.com) Received: from ASSP-nospam ([127.0.0.1]) by relay.talkpoint.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Jan 2007 15:29:54 -0500 Received: from 204.141.15.136 ([204.141.15.136] helo=postal.talkpoint.com) by ASSP-nospam ; 17 Jan 07 20:29:54 -0000 Received: from pleiades.nextvenue.com ([204.141.15.194]) by postal.talkpoint.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZN3V7MJS; Wed, 17 Jan 2007 15:29:50 -0500 Date: Wed, 17 Jan 2007 15:29:50 -0500 From: Nick Evans To: Ivan Voras Message-ID: <20070117152950.6c372f24@pleiades.nextvenue.com> In-Reply-To: <45AE7BF8.10703@fer.hr> References: <45AE7BF8.10703@fer.hr> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 20:29:54.0310 (UTC) FILETIME=[3F221A60:01C73A76] Cc: freebsd-current@freebsd.org, Bruce Evans , freebsd-arch@freebsd.org Subject: Re: Optimized copy&move (was: Re: [PATCH] Mantaining turnstile aligne d to 128 bytes in i386 CPUs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:29:55 -0000 On Wed, 17 Jan 2007 14:41:44 -0500 Ivan Voras wrote: > Bruce Evans wrote: > > > And MMX/XMM registers ar not needed to get movnt on machines with > SSE2, > > since movnti is part of SSE2. This reduces the advantages of using > MMX/XMM > > registers on P4's and A64's in 32-bit mode to the non-nt parts of the > > above (fully cached case), which I think are less important than the > nt > > parts. > > Hmm, I'm looking at i386/i386/support.s and there are several versions > of bcopy and bmove functions, including some that optimize by using FPU > registers (large_i586_bcopy_loop), and a version that uses movnti > (sse2_pagezero), but I can't find the bit of magic which glues them to > bzero() call. > > Also, as as I can tell by the comments, the FPU version works by > manually saving context... why is this possible (i.e. won't something > preempt it?) > Potentially stupid question but, is it not possible to benchmark these variations at build or boot time and use the most appropriate method? Or at least the one most appropriate 90% of the time? Nick From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:47:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B34A16A412; Wed, 17 Jan 2007 20:47:42 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7926613C457; Wed, 17 Jan 2007 20:47:41 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.7) with ESMTP id l0HKMYFV053838; Wed, 17 Jan 2007 12:25:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id l0HKMYV8053837; Wed, 17 Jan 2007 12:22:34 -0800 (PST) Date: Wed, 17 Jan 2007 12:22:34 -0800 (PST) From: Matthew Dillon Message-Id: <200701172022.l0HKMYV8053837@apollo.backplane.com> To: "Attilio Rao" References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:47:42 -0000 The cost of using the FPU can simply be thought of in terms of how many bytes you have to have to copy for it to become worth using the FPU over a far less complex integer copy loop. This is really easy to find out, and it is also fairly easy to instrument a sysctl to set the value used in the comparison and run benchmarks to determine at what point using the FP unit becomes the better choice. * Saving the FP state. The kernel doesn't have to save or restore anything if userland was not using the floating point unit. In fact, the kernel doesn't even need to FNINIT! All the kernel needs to do is CLTS and FNCLEX to make the FP unit usable for media copy instructions, then set CR0_TS when it is finished. Gee, that's nice! But if on the otherhand userland is using the floating point unit inbetween every system call then having the kernel try to use it does require calling fxsave and clearing npxthread == serious inefficiencies if userland is using the FP unit heavily. Or, alternatively, it can fxsave AND restore the state when it is done at a total cost of around 70ns plus write bandwidth cruft. In fact, I would say that if userland is not using the FP unit, that is npxthread == NULL or npxthread != curthread, you should *DEFINITELY* use the FP unit. Hands down, no question about it. * First, raw memory bandwidth is governed by RAS cycles. The fewer RAS cycles you have, the higher the bandwidth. This means that the more data you can load into the cpu on the 'read' side of the copy before transitioning to the 'write' side, the better. With XMM you can load 128 *BYTES* a shot (8 128 bit registers). For large copies, nothing beats it. * Modern cpu hardware uses a 128 bit data path for 128 bit media instructions and can optimize the 128 bit operation all the way through to a cache line or to main memory. It can't be beat. Alignment is critical. If the data is not aligned, don't bother. 128 bits means 16 byte alignment. * No extranious memory writes, no uncached extranious memory reads. If you do any writes to memory other then to the copy destination in your copy loop you screw up the cpu's write fifo and destroy performance. Systems are so sensitive to this that it is even better to spend the time linearly mapping large copy spaces into KVM and do a single block copy then to have an inner per-PAGE loop. * Use of prefetch or use of movntdq instead of movdqa is highly problematic. It is possible to use these to optimize very particular cases but the problem is they tend to nerf all OTHER cases. I've given up trying to use either mechanism. Instead, I prefer copying as large a block as possible to remove these variables from the cpu pipeline entirely. The cpu has a write fifo anyway, you don't need prefetch instructions if you can use instructions to write to memory faster then available L2 cache bandwidth. On some cpus this mandates the use of 64 or 128 bit media instructions or the cpu can't keep the write FIFO full and starts interleaving reads and writes on the wrong boundaries (creating more RAS cycles, which is what kills copy bandwidth). * RAS transitions also have to be aligned or you get boundary cases when the memory address transitions a RAS line. This again mandates maximal alignment (even more then 16 bytes, frankly, which is why being able to do 128 byte blocks with XMM registers is so nice). Even though reads and writes are reblocked to the cache line size by the cpu, your inner loop can still transition a RAS boundary in the middle of a large block read if it isn't aligned. But at this point the alignment requirements start to get kinda silly. 128 byte alignment requirement? I don't think so. I do a 16-byte alignment check in DragonFly as a pre-req for using XMM and that's it. But, as I said in the beginning... all you need is just one variable. Copying data below that threshold is faster without the FP unit, copying data above that threshold is faster with the FP unit. Implement it, test it, and see how you fare. If you are paranoid about having to save the FP state, then only use the FP unit when npxthread == NULL (no save required) or npxthread != curthread (save on behalf of a different thread required, which is ok)... It's that simple. Pinning is an issue with FreeBSD, one whos effect I cannot comment on. I don't know about AMD64. You only have 64 bit general registers in 64 bit mode so you may not be able to keep the write pipeline full. But you do have 8 of them so you are roughly equivalent to MMX (but not XMM's 8 128 bit registers). -Matt From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:58:06 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3717016A407 for ; Wed, 17 Jan 2007 20:58:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9B22E13C44C for ; Wed, 17 Jan 2007 20:58:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so879ana for ; Wed, 17 Jan 2007 12:58:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pItgPkHaEDbrkTAjGN71hv0qcZZ3IouKdHWYpGWW8idPlsIpydF/Xu41wiT/rxXufbn/d4EYnRpwkpTbwkgOW/1RMcHq1q9hQlUEZd/XDZ17PkBwvj7R2iIvE9MV+wOQWye3GWP6dCUT6AL63mxytKDiQEeTQQbRo2cTL+AXEsw= Received: by 10.100.138.2 with SMTP id l2mr3714510and.1169067484872; Wed, 17 Jan 2007 12:58:04 -0800 (PST) Received: by 10.100.112.17 with HTTP; Wed, 17 Jan 2007 12:58:04 -0800 (PST) Message-ID: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> Date: Wed, 17 Jan 2007 12:58:04 -0800 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net , freebsd-current , "Jon Otterholm" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Lenovo X60 em workaround X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:58:06 -0000 Since this was just seen, and the patch below validated as working I wanted to send general email to capture this: The Lenovo X60 can have issues with long ping times, this is a KNOWN hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has not been decided on yet. Nevertheless, the patch below will work, but I do not want to check it in as its still temporary. Address questions to me, Jack PS This is based on 6.2, but is needed for CURRENT as well. --- if_em.dist.c Wed Jan 17 17:59:46 2007 +++ if_em.c Wed Jan 17 18:03:13 2007 @@ -3348,6 +3348,10 @@ E1000_WRITE_REG(&adapter->hw, RXCSUM, reg_rxcsum); } + /* TEMPORARY WORKAROUND for X60 */ + if (adapter->hw.mac_type == em_82573) + E1000_WRITE_REG(&adapter->hw, RDTR, 32); + /* Enable Receives */ E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); /* From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 20:58:11 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D432716A55C; Wed, 17 Jan 2007 20:58:11 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8827C13C45B; Wed, 17 Jan 2007 20:58:11 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls422.t-com.hr (ls422.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 4B01F146443; Wed, 17 Jan 2007 21:58:10 +0100 (CET) Received: from ls422.t-com.hr (localhost.localdomain [127.0.0.1]) by ls422.t-com.hr (Qmlai) with ESMTP id 336E5C90053; Wed, 17 Jan 2007 21:58:10 +0100 (CET) X-Envelope-Sender-Info: KDHLkYIFXCRHG7zIR7FVXvx6MUdRkOwZZsfH4/buQTKKesY80THoNSngionnLwUP X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.101] (89-172-39-6.adsl.net.t-com.hr [89.172.39.6])by ls422.t-com.hr (Qmlai) with ESMTP id AFA961308056; Wed, 17 Jan 2007 21:58:05 +0100 (CET) Message-ID: <45AE8DDC.8030402@fer.hr> Date: Wed, 17 Jan 2007 21:58:04 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Matthew Dillon References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bb f2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe107011608 51r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleia des.nextvenue.com> <3bbf2fe10701161525j6ad929 2y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe1 0701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> In-Reply-To: <200701172022.l0HKMYV8053837@apollo.backplane.com> X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/mixed; boundary=------------enig5EF4019AFDFB80A298524055 X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:0.00000 C:100 M:100 S:100 R:100 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 20:58:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EF4019AFDFB80A298524055 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Matthew Dillon wrote: > * Saving the FP state. The kernel doesn't have to save or restore > anything if userland was not using the floating point unit. In > fact, the kernel doesn't even need to FNINIT! All the kernel nee= ds > to do is CLTS and FNCLEX to make the FP unit usable for media cop= y > instructions, then set CR0_TS when it is finished. Does the same hold true with kernel threads in FreeBSD (e.g. two threads using FPU)? --------------enig5EF4019AFDFB80A298524055-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 21:15:10 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21F1B16A40F for ; Wed, 17 Jan 2007 21:15:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9EEC713C46A for ; Wed, 17 Jan 2007 21:15:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so299356nfc for ; Wed, 17 Jan 2007 13:15:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eRHA2G6sBSGuU/pxc8QwbYPRDp+e254PBnXyNIbj6NWRafkXrTOCX/187SbMoh5DzEJ9GTJmsKzUPrUoWtQ6WiS2Bx4QC5QaAEzpsIPA4DIDz9BreSVKo2hrgQ0qXpWQqUHzqWzYhB9TK/rdDuVF00apNH41aZlrEjwVlXuEtTs= Received: by 10.48.48.13 with SMTP id v13mr11083nfv.1169068508050; Wed, 17 Jan 2007 13:15:08 -0800 (PST) Received: by 10.48.238.9 with HTTP; Wed, 17 Jan 2007 13:15:07 -0800 (PST) Message-ID: <3bbf2fe10701171315g696bca4fi3bf676b62c06f4d@mail.gmail.com> Date: Wed, 17 Jan 2007 22:15:07 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Ivan Voras" In-Reply-To: <45AE7BF8.10703@fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <20070117134022.V18339@besplex.bde.org> <20070117224812.Q23194@besplex.bde.org> <45AE7BF8.10703@fer.hr> X-Google-Sender-Auth: 540a52cd6fbe718e Cc: freebsd-current@freebsd.org, Bruce Evans , freebsd-arch@freebsd.org Subject: Re: Optimized copy&move (was: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 21:15:10 -0000 2007/1/17, Ivan Voras : > Bruce Evans wrote: > > > And MMX/XMM registers ar not needed to get movnt on machines with SSE2, > > since movnti is part of SSE2. This reduces the advantages of using MMX/XMM > > registers on P4's and A64's in 32-bit mode to the non-nt parts of the > > above (fully cached case), which I think are less important than the nt > > parts. > > Hmm, I'm looking at i386/i386/support.s and there are several versions > of bcopy and bmove functions, including some that optimize by using FPU > registers (large_i586_bcopy_loop), and a version that uses movnti > (sse2_pagezero), but I can't find the bit of magic which glues them to > bzero() call. > > Also, as as I can tell by the comments, the FPU version works by > manually saving context... why is this possible (i.e. won't something > preempt it?) They are just broken. My implementation, which follows DragonFlyBSD patterns, just use a bts (which is atomic) in order to set a "lock" and avoid thread migration with scheduler pinning. This is enough to solve concurrency problems. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Jan 17 22:52:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0089816A40F; Wed, 17 Jan 2007 22:52:21 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id CD8B413C45D; Wed, 17 Jan 2007 22:52:20 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.7) with ESMTP id l0HMhEx9054400; Wed, 17 Jan 2007 14:46:14 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id l0HMhECY054399; Wed, 17 Jan 2007 14:43:14 -0800 (PST) Date: Wed, 17 Jan 2007 14:43:14 -0800 (PST) From: Matthew Dillon Message-Id: <200701172243.l0HMhECY054399@apollo.backplane.com> To: Ivan Voras References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bb f2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe107011608 51r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleia des.nextvenue.com> <3bbf2fe10701161525j6ad929 2y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe1 0701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <45AE8DDC.8030402@fer.hr> Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 22:52:21 -0000 :Does the same hold true with kernel threads in FreeBSD (e.g. two threads :using FPU)? Preemption and pinning make the issue a bit more difficult for FreeBSD, but the basic idea remains valid. From the point of view of NPXTHREAD the situation is very simple: * NPXTHREAD = NULL nobody owns the FP, nobody is using the FP. If the kernel wants to use the FP it just FNCLEX + CLTS and sets NPXTHREAD = curthread. When it is finished, it undoes that sequence (NPXTHREAD = NULL, set CR0_TS again). PLUSES: FP state does not need to be saved or restored ISSUES: due to cpu migration and preemption the setup and teardown sequence must be done with the cpu pinned, inside a critical section. But the actual use of the FP does not need to occur inside a critical section or with the cpu pinned. * NPXTHREAD = other_thread Some other thread owns the FP, but it isn't our thread so we can safely save the FP state for the other thread without worrying about creating a situation where we thrash the T_DNA exception. Save FP state, FNCLEX, CLTS, set NPXTHREAD = curthread. When finished, NPXTHREAD = NULL, set CR0_TS, do *not* restore the 'other' thread's FP state. PLUSES: The FP state probably had to be saved anyway, it's no big deal or at least it is not as big a deal as the NPXTHREAD = curthread case. ISSUES: Same as above. * NPXTHREAD = curthread The current thread (either userland or a pushed kernel FP context) is using the FP. If the kernel decides it needs the FP it must save the FP state, FNCLEX, CLTS, do its thing. When finished it can decide to set NPXTHREAD = NULL and set CR0_TS, or it can restore the previously saved state and leave NPXTHREAD = curthread. PLUSES: Very few ISSUES: Same as above, but here the kernel must decide whether it is worth stealing the FP or not, because it might get into a thrashing situation with the T_DNA exception under certain userland loads. Note that there are many cases where userland may use the FP unit very occassionally. In such cases you *DO* want to be able to steal it, so perhaps some heuristic is needed to determine the cost of stealing the FP unit dynamically. It is possible to abstract it even more... for example, one can set CR0_TS when going from userland to the kernel and completely abstract out the kernel's use of the FP unit at the cost of a higher entrance fee to get in and out of the kernel. I decided NOT to do this in DragonFly. If the DragonFly kernel wants to use the FP it has to check and adjust the NPXTHREAD state. But, to be absolutely clear here, it costs virtually *nothing* to use the FP in the kernel for non-FP media instructions (i.e. movdq and friends) if userland has not used the FP recently. You push a temporary save area, set NPXTHREAD, FNCLEX, CLTS, use the FP, then pop the save area pointer, set NPXTHREAD to NULL, and set CR0_TS, and that's it. It may seem like a lot of steps but those are all very fast instructions verses having to actually save and restore the 512 byte FP state. The biggest overhead would actually be the critical section and cpu pinning required to properly transition the NPXTHREAD state. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 00:16:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F1B816A40F; Thu, 18 Jan 2007 00:16:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id B036F13C428; Thu, 18 Jan 2007 00:16:23 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 260B06E29F; Thu, 18 Jan 2007 11:16:20 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 82F4727406; Thu, 18 Jan 2007 11:16:20 +1100 (EST) Date: Thu, 18 Jan 2007 11:16:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Attilio Rao In-Reply-To: <3bbf2fe10701171315g696bca4fi3bf676b62c06f4d@mail.gmail.com> Message-ID: <20070118094808.F11834@delplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <20070117134022.V18339@besplex.bde.org> <20070117224812.Q23194@besplex.bde.org> <45AE7BF8.10703@fer.hr> <3bbf2fe10701171315g696bca4fi3bf676b62c06f4d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 18 Jan 2007 00:47:52 +0000 Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: Optimized copy&move (was: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 00:16:24 -0000 On Wed, 17 Jan 2007, Attilio Rao wrote: > 2007/1/17, Ivan Voras : >> Bruce Evans wrote: >> >> > And MMX/XMM registers ar not needed to get movnt on machines with SSE2, >> > since movnti is part of SSE2. This reduces the advantages of using >> MMX/XMM >> > registers on P4's and A64's in 32-bit mode to the non-nt parts of the >> > above (fully cached case), which I think are less important than the nt >> > parts. One more point on movnt*: - The i386 (32-bit) kernel already uses movnti in the one place where it is certain to be an optimization (for zeroing pages but not for copying anything) if and only if movnti is known for sure to be available (esentially, if the CPU supports SSE2). See i386/pmap.c and i386/support.s. >> Hmm, I'm looking at i386/i386/support.s and there are several versions >> of bcopy and bmove functions, including some that optimize by using FPU >> registers (large_i586_bcopy_loop), and a version that uses movnti >> (sse2_pagezero), but I can't find the bit of magic which glues them to >> bzero() call. sse2_pagezero() is the SSE2 optimization mentioned above. It is glued in pmap.c. The i586 bcopy functions are my old mistakes which I'm trying to bury :-). They are glued in isa/npx.c. There is a runtime test for their efficiency there, and config-time configuration by npx flags (see NOTES). All use of the FPU routines is disabled in all released versions of FreeBSD later than FreeBSD-4 (the config-time configuration is ignored and the dynamic test and the glueing are not done; only the actual routines are compiled, so in theory you could enable them by glueing them in a kmod). >> Also, as as I can tell by the comments, the FPU version works by >> manually saving context... why is this possible (i.e. won't something >> preempt it?) In RELENG_4, the kernel is not preemptible so preemption isn't a problem. In later versions, preemption is a problem so the FPU routines are disabled. RELENG_4 has a limited amount of preemption for interrupt handlers, and the FPU routines have a limited amount of recursive saving of contexts to support this. No bugs are known in this under RELENG_4. Under later versions, the recursive saving doesn't quite work. RELENG_4 has a limited amount of support for SMP, and the FPU routines have a limited amount of locking to support this. No bugs are known in this under RELENG_4, but I wouldn't trust it without testing. It has probably been tested enough under RELENG_4 by now, but it might never have been tested before 2001 when the FPU routines were turned off in -current, because there were no machines with the critical combination of features until relatively recently: - SMP machines with Pentium-1's were rare and are now rarer - the FPU routines are slower on P2-P4, K5 and K6 so the dynamic configuration should prevent them being used on machines with P2-P4, K5 and K6. - the FPU routines are faster on Athlons (XP and 64 at least), but these didn't exist until 2001. The introduction of these CPUs may have been the trigger for turning off the FPU routines in -current in 2001. Until then problems were limited to Pentium-1's since the dynamic configuration prevented the routines being used on all other machines. > They are just broken. > My implementation, which follows DragonFlyBSD patterns, just use a bts > (which is atomic) in order to set a "lock" and avoid thread migration > with scheduler pinning. This is enough to solve concurrency problems. There is a bit more to it than that :-). The old implementation uses a sar instruction for the same purpose. Neither bts nor sar is atomic, but both can be made atomic using a lock prefix. The old implementation neglects to do this, so the instruction is only atomic with respect to interrupts. If it works at all for the SMP case under RELENG_4, then it is because Giant locking prevents all types of preemption. Giant locking certainly prevents process preemption, but it is less clear that it prevents interrupt handlers running on other CPUs from getting far enough to clobber the lock. I think it does. The unlocked sar just doesn't work under -current, especially starting much later than 2001 when the kernel became fully preemptible. (I like to use sar instead of bts/cmpxchg/ whatever since it is more portable.) Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 05:14:58 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC82516A415; Thu, 18 Jan 2007 05:14:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB0013C459; Thu, 18 Jan 2007 05:14:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0I5EvqL068428; Thu, 18 Jan 2007 00:14:57 -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.8/8.13.8) with ESMTP id l0I5EvBO025794; Thu, 18 Jan 2007 00:14:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 54ED573034; Thu, 18 Jan 2007 00:14:57 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118051457.54ED573034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 00:14:57 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 05:14:58 -0000 TB --- 2007-01-18 03:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 03:35:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-18 03:35:00 - cleaning the object tree TB --- 2007-01-18 03:35:50 - checking out the source tree TB --- 2007-01-18 03:35:50 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-18 03:35:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 03:46:42 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 03:46:42 - cd /src TB --- 2007-01-18 03:46:42 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 03:46:43 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jan 18 05:03:20 UTC 2007 TB --- 2007-01-18 05:03:20 - generating LINT kernel config TB --- 2007-01-18 05:03:20 - cd /src/sys/amd64/conf TB --- 2007-01-18 05:03:20 - /usr/bin/make -B LINT TB --- 2007-01-18 05:03:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 05:03:20 - cd /src TB --- 2007-01-18 05:03:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 05:03:20 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/io_apic.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/legacy.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/local_apic.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/machdep.c /src/sys/amd64/amd64/machdep.c:180: error: conflicting types for '__pcpu' ./machine/md_var.h:60: error: previous declaration of '__pcpu' was here /src/sys/amd64/amd64/machdep.c:180: error: conflicting types for '__pcpu' ./machine/md_var.h:60: error: previous declaration of '__pcpu' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 05:14:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 05:14:56 - ERROR: failed to build lint kernel TB --- 2007-01-18 05:14:56 - tinderbox aborted TB --- 0.87 user 3.48 system 5996.20 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 08:04:28 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DEFDA16A412; Thu, 18 Jan 2007 08:04:28 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C30D113C45A; Thu, 18 Jan 2007 08:04:28 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.100] (c-67-188-127-3.hsd1.ca.comcast.net [67.188.127.3]) by elvis.mu.org (Postfix) with ESMTP id EA1D71A3C19; Wed, 17 Jan 2007 23:39:10 -0800 (PST) Message-ID: <45AF23DE.6030801@FreeBSD.org> Date: Wed, 17 Jan 2007 23:38:06 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> In-Reply-To: <20070118113831.A11834@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ivan Voras , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 08:04:29 -0000 Bruce Evans wrote: > On Wed, 17 Jan 2007, Matthew Dillon wrote: >> * No extranious memory writes, no uncached extranious memory reads. >> If you do any writes to memory other then to the copy destination >> in your copy loop you screw up the cpu's write fifo and destroy >> performance. >> >> Systems are so sensitive to this that it is even better to spend the >> time linearly mapping large copy spaces into KVM and do a single >> block copy then to have an inner per-PAGE loop. > > > I haven't tried this, but have seen and partly worked sensitivity to > linear KVA maps not being physically (non)linear enough. Some CPUs > and/or memory systems are remarkably sensitive to bank interleave. > FreeBSD's page coloring doesn't know anything about banks, and > accidentally starts up with perfect miscoloring for banks. This can > make a difference of 30% for bzero bandwidth in benchmarks (not so > much for bcopy bandwidth, and an insignificant amount for normal use). > After the system warms up, the coloring becomes random with respect > to banks, and random coloring works much better than perfect miscoloring. About page coloring: Don't amd64 CPUs have virtually indexed, physically tagged caches? If so, wouldn't it make sense to turn off page coloring, since it's useless for virtually indexed caches (and probably hurts things a bit)? -- Suleiman From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 11:11:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71FDA16A407 for ; Thu, 18 Jan 2007 11:11:59 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id 455CC13C4C8 for ; Thu, 18 Jan 2007 11:11:59 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2007 03:11:59 -0800 X-IronPort-AV: i="4.13,204,1167638400"; d="scan'208"; a="102878102:sNHT46695672" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IBBwrS019514 for ; Thu, 18 Jan 2007 03:11:58 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0IBBwDk015429 for ; Thu, 18 Jan 2007 03:11:58 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 03:11:58 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 03:11:58 -0800 Message-ID: <45AF55DE.1070700@cisco.com> Date: Thu, 18 Jan 2007 06:11:26 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2007 11:11:58.0199 (UTC) FILETIME=[783AB070:01C73AF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=326; t=1169118719; x=1169982719; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20mbuf=20large=20clusters |Sender:=20 |To:=20freebsd-current@freebsd.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowe d |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=yfgqOoaHzTikSJHszdJLnH7mrUhdpo99P+mEbyZgG4Q=; b=OS1W+aIk5tiORFcJY49NfmfZmCW8W+cwnTv26l7hfzBe93r9dvd02hnq/OEZm3Dwr2ey1m8F 15ACe2h8CkkLsRdCbINYOcLdQxWhysDEqcKsnoYsG5M4+YGSjPhpMwZ2ZR/PoeEg2A7eofjEbu 0IIwE9mFyJBGZETq9As8a0m08=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Subject: mbuf large clusters X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 11:11:59 -0000 Question: I see that the 2k clusters are defaulted in tunable_mbinit() to: nmbclusters = 1024 + maxusers * 64; But there are NO limits what so ever set on the larger clusters... Any particular reason why that is so? R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 07:03:39 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5706216A415; Thu, 18 Jan 2007 07:03:39 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 84E2D13C459; Thu, 18 Jan 2007 07:03:38 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id B39865A7C93; Thu, 18 Jan 2007 18:03:30 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 638EF8C22; Thu, 18 Jan 2007 18:03:26 +1100 (EST) Date: Thu, 18 Jan 2007 18:03:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Matthew Dillon In-Reply-To: <200701172022.l0HKMYV8053837@apollo.backplane.com> Message-ID: <20070118113831.A11834@delplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 18 Jan 2007 12:29:41 +0000 Cc: Attilio Rao , freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 07:03:39 -0000 On Wed, 17 Jan 2007, Matthew Dillon wrote: > The cost of using the FPU can simply be thought of in terms of how > many bytes you have to have to copy for it to become worth using > the FPU over a far less complex integer copy loop. It's not that simple... > ... > In fact, I would say that if userland is not using the FP unit, > that is npxthread == NULL or npxthread != curthread, you should > *DEFINITELY* use the FP unit. Hands down, no question about it. Only if the raw FPU is actually faster. > * First, raw memory bandwidth is governed by RAS cycles. The fewer RAS > cycles you have, the higher the bandwidth. > > This means that the more data you can load into the cpu on the 'read' > side of the copy before transitioning to the 'write' side, the better. > > With XMM you can load 128 *BYTES* a shot (8 128 bit registers). For > large copies, nothing beats it. No, this is very machine-dependent. Read-write transitioning is slow, but it is almost a non-problem since it can be avoided by prefetchiung the read side. Dirtying the cache with the read side is unavoidable on current i386-amd64 CPUs. Prefetching makes this a feature: prefetch N bytes, preferably using a working prefetchnta (1) write N bytes, possibly to the cache (2), possibly many less than just one XMM register's worth at a time (3) Just make N much larger than 128 for this to easily beat simply loading and storing 128 bytes at a time (4) (5). (1) If the source is already in the cache, the extra instructions for the prefetch are a bit wasteful. Using prefetchnta limits the waste, perhaps to 0 depending on whether prefetchnta can be executed in an otherwise unised pipeline. However, a working prefetchnta is required for the prefetch to actually occur in the case that the source isn't already in the cache. A64's have a working prefetchnta, but AXP's don't. (2) Reads and writes through the L1 cache give much the same benefits as reads and writes through many registers. Reads must go through the L1 cache. (3) Write combining of sequential writes makes the number of memory accesses independent of the instruction operand size, at least for cached writes. If writes are direct, then the issues are different. I've never seen 128-bit nontemporal writes go faster than 64-bit ones so maybe they are combined too. (I may have seen this on AXP while writing this.) (4) Using only registers 128 bytes at a time may beat prefetch in cases where the prefetch is too wasteful. However, I think these cases are limited ones where the copy size is small so you wouldn't want to use prefetch or nontemporal writes and any benefits from using XMM registers are marginal (because of the context switching overheads). Such cases are handled well by caching. If the cache line size is 128, then read/write through the cache gives RAS cycles that are independent of the instruction operand sizes. Using 8*16 bytes from registers can only win if the cache line size is 64. (5) A64's have 16 not-very general integer 64-bit integer registers and 16 XMM registers, so you can get close to 128 bytes using integer registers (16*8) and can get 256 bytes using XMM registers (16*16). Caching and/or write buffering turns writes of the "small" 64-bit registers or even 32-bit registers into much larger writes, so levels of the memory system below L1 don't notice if we write tiny amounts at a time provided there is enough instruction bandwidth to keep up. > * Modern cpu hardware uses a 128 bit data path for 128 bit media > instructions and can optimize the 128 bit operation all the way through > to a cache line or to main memory. It can't be beat. Actually, integer instructions beat it easily on A64: Fully cached case: % copy0: 16907105855 B/s ( 242265 us) (movsq) % ... % copyQ: 13658478027 B/s ( 299887 us) (movdqa) % ... % copyT: 16456408196 B/s ( 248900 us) (movq (i)) This doesn't contradict your claim since main memory is not really involved. Everything should be limited by instruction and cache bandwidth, but for some reason movdqa is quite slow despite or because of my attempts to schedule it perfectly. Fully uncached case: % copy0: 829571300 B/s ( 493749 us) (movsq) % ... % copyQ: 835822845 B/s ( 490056 us) (movdqa) % copyR: 908423544 B/s ( 450891 us) (movdqa with prefetchnta) % copyS: 919026496 B/s ( 445689 us) (movdqa with block prefetch) % copyT: 828993732 B/s ( 494093 us) (movq (i)) % copyU: 905141362 B/s ( 452526 us) (movq (i) with prefetchnta) % copyV: 910626945 B/s ( 449800 us) (movq (i) with block prefetch) % copyW: 1350397932 B/s ( 303318 us) (movnti) % copyX: 1662594069 B/s ( 246362 us) (movnti with prefetchnta) % copyY: 1608204355 B/s ( 254694 us) (movnti with block prefetch) Now movdqa beats movsq by a bit, at least with prefetch, but has the same speed as integer moves of half the size (or MMX moves of half the size (benchmark data not shown)). It is necessary to use movnt to get anywhere near memory bandwidth, and any form of movnt can be used for this (I test mainly movntps in addition to the above, since it is most portable). There is apparently some magic to combine 8-byte writes if necessary for efficient main memory accesses. The above was run on an old A64 overclocked a lot to 2204 MHz, with mediocre DDR-1 PC3200 memory overclocked a bit and tuned a lot. The maximum bandwidth achieved is almost exactly PC3200 but the theoretical maximum is more like PC3400. > > Alignment is critical. If the data is not aligned, don't bother. 128 > bits means 16 byte alignment. The above benchmark output is for aligned data :-). I don't try hard to optimize or benchmark misaligned cases. > * No extranious memory writes, no uncached extranious memory reads. > If you do any writes to memory other then to the copy destination > in your copy loop you screw up the cpu's write fifo and destroy > performance. > > Systems are so sensitive to this that it is even better to spend the > time linearly mapping large copy spaces into KVM and do a single > block copy then to have an inner per-PAGE loop. I haven't tried this, but have seen and partly worked sensitivity to linear KVA maps not being physically (non)linear enough. Some CPUs and/or memory systems are remarkably sensitive to bank interleave. FreeBSD's page coloring doesn't know anything about banks, and accidentally starts up with perfect miscoloring for banks. This can make a difference of 30% for bzero bandwidth in benchmarks (not so much for bcopy bandwidth, and an insignificant amount for normal use). After the system warms up, the coloring becomes random with respect to banks, and random coloring works much better than perfect miscoloring. > > * Use of prefetch or use of movntdq instead of movdqa is highly > problematic. It is possible to use these to optimize very particular > cases but the problem is they tend to nerf all OTHER cases. This is very machine-dependent: - prefetchnta seems to work fine on A64 but not on AXP or P4 (see above and other postings. I haven't tested it much for small copy sizes. I never saw older prefetch instructions that give more control doing anything useful. - movntps may be free (once you use XMM and if ps instead of dq is OK) on AXP, since it runs at cache speed if the target is already cached, It is not free on A64 since it always runs at memory speed. I think ps instead of dq is not OK since ps is slow if there are denormals in the data, but don't remember if benchmarks support this. Unfortunately, the only movnt instruction in AXP is movntps. - movnt* is a clear win in at least one case: zeroing pages in idle. FreeBSD on i386 uses movnti for all zeroing of pages in the SSE2 case. This might not be best for non-idle zeroing. Maybe it should be used only for multiple pages. For single pages, it is probably for a pagefault and you want at least the data near the fault address in the cache. FreeBSD on amd64 also uses movnti for all copying of pages. I think SunOS on amd64 uses movnt* whenever the copy size is >= 128. This seems too small. > I've given up trying to use either mechanism. Instead, I prefer > copying as large a block as possible to remove these variables from > the cpu pipeline entirely. The cpu has a write fifo anyway, you > don't need prefetch instructions if you can use instructions to write > to memory faster then available L2 cache bandwidth. On some cpus > this mandates the use of 64 or 128 bit media instructions or the > cpu can't keep the write FIFO full and starts interleaving reads > and writes on the wrong boundaries (creating more RAS cycles, which > is what kills copy bandwidth). Which modern CPUs can't keep up with L2? On amd64 for the fully-L2-cached case: % copy0: 4382675165 B/s ( 934589 us) (movsq) % ... % copyN: 3432351420 B/s (1193351 us) (movntq) % copyO: 1777008820 B/s (2304997 us) (movntq with prefetchnta) % copyP: 3278961491 B/s (1249176 us) (movntq with block prefetch) % copyQ: 4369052686 B/s ( 937503 us) (movdqa) % copyR: 2785886655 B/s (1470268 us) (movdqa with prefetchnta) % copyS: 4553271385 B/s ( 899573 us) (movdqa with block prefetch) % copyT: 4401466152 B/s ( 930599 us) (movq (i)) % copyU: 2817507895 B/s (1453767 us) (movq (i) with prefetchnta) % copyV: 4523562615 B/s ( 905481 us) (movq (i) with block prefetch) % copyW: 3432429080 B/s (1193324 us) (movnti) % copyX: 1776507852 B/s (2305647 us) (movnti with prefetchnta) % copyY: 3136767185 B/s (1305803 us) (movnti with block prefetch) So here is a case where prefetchnta is bad. OTOH, movnti is quite fast provided prefetchnta is not used with it. movnti is even more competitive with L2 if main memory is DDR-2. > * RAS transitions also have to be aligned or you get boundary cases > when the memory address transitions a RAS line. This again mandates > maximal alignment (even more then 16 bytes, frankly, which is why > being able to do 128 byte blocks with XMM registers is so nice). > Even though reads and writes are reblocked to the cache line size > by the cpu, your inner loop can still transition a RAS boundary in > the middle of a large block read if it isn't aligned. > > But at this point the alignment requirements start to get kinda > silly. 128 byte alignment requirement? I don't think so. I > do a 16-byte alignment check in DragonFly as a pre-req for using > XMM and that's it. :-). There are just too many combinations to even think about. I prefer to reduce the number of cases by depending on the prefetching working reasonably well. > I don't know about AMD64. You only have 64 bit general registers in 64 > bit mode so you may not be able to keep the write pipeline full. But > you do have 8 of them so you are roughly equivalent to MMX (but not 16, almost > XMM's 8 128 bit registers). On A64 and AXP, most things are limited by the load/store unit (LSU), the 3 integer pipelines, and SSE latency (but latency is not a problem here). Load/store-unit: On A64, the LSU can do the following number of interesting L1 cache accesses per cycle: 2 64-bit loads 2 64-bit stores 1 64-bit load and 1 64-bit store all to the L1 cache. When you load or store a 128-bit XMM register, it takes the same load/store-unit resources as 2 64-bit integer loads or stores of the same type. Thus XMM and integer operations can both achieve the maximum L1 cache bandwidth, but no more of course, so XMM vs integer is irrelevant for bandwidth considerations for the L1 level, and since lower levels need less bandwidth, it is irrelevant for all levels except possibly the non-cache-level given by nontemporal stores. On AXP, the LSU can do the following number of interesting L1 cache accesses per cycle: 2 64-bit loads 2 32-bit store 1 64-bit store 1 64-bit load and 1 64-bit store Since there are no 64-bit integer registers, you have to use MMX or XMM to get the 64-bit accesses. It doesn't matter whether you use 2*MMX or 1*XMM to get to 128 bits -- both become 2*64 bits. 32-bit integer stores can only use half of the L1 cache bandwidth. 32-bit integer loads are also limited to 2 per cycle since they apparently aren't combined at this level. Combining also doesn't happen for movsl (this is apparently implemented as a 32-bit load/store). On A64 in 32-bit mode, the LSU can do 2 64-bit stores/cycle, but this only helps using XMM registers -- 32-bit accesses apparently never get combined at this level, so they always go at half speed. The asymmetric load/store capabilities on the AXP can't be good for using 128-bit XMM registers, especially using 8 loads followed by 8 stores in the instruction stream. They make 128 stores want to take twice as long as 2 64-bits ones, and it takes a large amount of out of order execution to reorder things to reach the "1 64-bit load and 1 64-bit store" per cycle pattern. Reordering is exactly what you don't want for controlling the interleaving of access to main memory. Even with a simple load-store- load-store with 64-bit accesses in the instruction, stream, the there will be some reordering -- the reads will get 1 ahead of the writes. This explains why my movdqa benchmark is slow on AXP but not why it is slow on A64. Benchmark output on AXP, fully cached case: % copy0: 5275909727 B/s ( 776359 us) (1417037051 tsc) (movsl) % ... % copyD: 6301722666 B/s ( 649981 us) (1175886987 tsc) (kernel bcopy (unroll 64 fp i-prefetch)) % copyH: 4336676894 B/s ( 944502 us) (1708211441 tsc) (movntps) % ... % copyK: 8750902650 B/s ( 468066 us) (846786401 tsc) (movq) % ... % copyN: 3029184746 B/s (1352179 us) (2445280543 tsc) (movntq) % ... % copyQ: 5487174266 B/s ( 746468 us) (1350423254 tsc) (movdqa) This shows: - movsl is quite slow - even the old kernel bcopy is barely worth using on AXP - movntps isn't too bad in the fully cached case (AXP implemenmtation detail) - movq (through 64-bit MMX) is quite fast, but not quite twice as fast as movsl. I thought that mainly instruction execution bandwidth limits prevented it being twice as fast, but maybe it is affected by the asymmetry. It does load-load-store-store repeated through 4 pairs of different MMX registers. I think it was written before I knoew anything about the CPU resource issues (I keep some mistakes for comparison). Now I think using different registers is unnecessary, and the limit of 8 or 16 MMX or 16 registers need not be hit. load-store repeated to the same register, or load-store-load-store repeated actually uses a large machine-dependent number of registers via register renaming. Even old AXP's have this. I think the register renaming works across loop boundaries and gives you many more than the 8 registers that you might think you are using. This goes with out of order execution and might be controllable only in the same way, by stalling at page boundaries. - movntq is much slower than movntps. movntps does 4 128-bit loads followed by 4 128-bit stores. movntq does 8 64-bit loads followed by 8 64-bit stores. This seems to show that 128-bit accesses are faster. - movdqa is quite slow. It uses load-store... of a single 128-bit register. Perhaps it is too optimized away from using multiple registers. In fact, rewriting it to use 8 loads followed by 8 stores shows one case where it beats movnti (64 bits) -- in the fullyL2-cached case, this speeds it up from 4.37GB/S to 4.77GB/S, making it about 0.4GB/S faster than both the other version of itself and movnti. But in the fully-L1-cached case, this speeds it down from 13.7GB/S to 9.2GB/S, making it much slower than itself and almost twice as slow as movsq. This is hard to explain, especially for the L1 case. In the L2 case, it might be explained by the 8 stores followed by 8 loads not being reordered very much so that they work almost like you want. Integer pipeline resources: Both AXP and A64 have 3 integer pipelines (they are remarkably similer in this and many other respects). It's easy to do a load/store in parallel using 2 of the pipelines. This saturates the LSU (loads must be at least 1 in advance of stores). The load/store can also be from FPU/SSE pipelines, but not independently, and on AXP the integer pipelines lose LSU bandwidth since they can only do 32-bit accesses. Other integer operations can run in the 3rd pipeline, but there are many restrictions which I don't quite understand or remember. These result in it being hard to keep the 3rd pipeline full. The above movq (i) benchmark for A64 indicates that it may be being used to hide all the loop control overhead -- I only unrolled the loop to 64 bytes, and that gives almost full speed. The loop must be unrolled a bit since a single load-store runs too fast for loop control. For the movnti benchmarks, the load-store runs slower than the loop control so unrolling is not needed. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 10:01:46 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1378816A494; Thu, 18 Jan 2007 10:01:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id C5B3913C4BD; Thu, 18 Jan 2007 10:01:45 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 6A13C5AFC73; Thu, 18 Jan 2007 21:01:44 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id CFF998C0B; Thu, 18 Jan 2007 21:01:42 +1100 (EST) Date: Thu, 18 Jan 2007 21:01:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Suleiman Souhlal In-Reply-To: <45AF23DE.6030801@FreeBSD.org> Message-ID: <20070118204641.M3613@besplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <45AF23DE.6030801@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 18 Jan 2007 12:29:52 +0000 Cc: Maxim Sobolev , Ivan Voras , Attilio Rao , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 10:01:46 -0000 On Wed, 17 Jan 2007, Suleiman Souhlal wrote: > Bruce Evans wrote: >> I haven't tried this, but have seen and partly worked sensitivity to >> linear KVA maps not being physically (non)linear enough. Some CPUs >> and/or memory systems are remarkably sensitive to bank interleave. >> FreeBSD's page coloring doesn't know anything about banks, ... > > About page coloring: Don't amd64 CPUs have virtually indexed, physically > tagged caches? If so, wouldn't it make sense to turn off page coloring, > since it's useless for virtually indexed caches (and probably hurts things > a bit)? I think superpages will soon turn off coloring. Not sure if this is right. How is copying and zeroing a whole superpage at a time avoided? IIRC, my benchmarks (and LMbench) show some small positive benefits for page coloring on amd64. I don't remember exactly what they are, just that they are smaller than on AthlonXP. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 13:49:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E74D716A40F for ; Thu, 18 Jan 2007 13:49:37 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.192.82]) by mx1.freebsd.org (Postfix) with ESMTP id CCCD513C428 for ; Thu, 18 Jan 2007 13:49:37 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (rwcrmhc12) with ESMTP id <20070118134936m12002gpk9e>; Thu, 18 Jan 2007 13:49:37 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l0IDnald007431; Thu, 18 Jan 2007 08:49:36 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l0IDna8w007430; Thu, 18 Jan 2007 08:49:36 -0500 (EST) (envelope-from rodrigc) Date: Thu, 18 Jan 2007 08:49:36 -0500 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20070118134936.GA7391@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 13:49:38 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This is a different version of the patch I posted here: http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005439.html One of the pet peeves I have with FreeBSD is that if I have a device with a local filesystem that I want to mount, I need to explicitly know what type of filesystem is on the device in order to mount it from the command-line. For example, mount -t cd9660 mount -t udf mount -t ext2fs mount -t msdosfs Where this is particularly annoying is if I have multiple USB thumb drives with different filesystems on them. What I usually end up doing is something like: file - < /dev/ad0s4 to figure out the filesystem type, and then mount -t [whatever] to mount it. What I would like to do is: mount /dev/ad0s4 /mnt and if I do not specify a filesystem type with -t, the mount program should "magically" figure out how to mount the disk. This is closer to how the mount program behaves on Linux for example. In this patch, I only modified the userland mount program. If the user does not specify "-t vfstype" to mount, the mount program gets a list of local filesystems from the vfs.conflist sysctl. It then tries to mount the filesystem, always starting with "ufs", and then iterating through the list if the nmount() fails with EINVAL. Using this patch, I have been able to do: mount /dev/blah /mnt and mount a UFS, cd9660, or FAT filesystem, depending on what filesystem is on the /dev/blah device. Comments? -- Craig Rodrigues rodrigc@crodrigues.org --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mount_patch.txt" Index: mount.c =================================================================== RCS file: /home/ncvs/src/sbin/mount/mount.c,v retrieving revision 1.92 diff -u -u -r1.92 mount.c --- mount.c 14 Nov 2006 01:07:42 -0000 1.92 +++ mount.c 18 Jan 2007 13:41:53 -0000 @@ -139,6 +139,9 @@ NULL }; + if (vfstype == NULL) + return (0); + for (i = 0; fs[i] != NULL; ++i) { if (strcmp(vfstype, fs[i]) == 0) return (1); @@ -219,7 +222,7 @@ ro = 0; options = NULL; vfslist = NULL; - vfstype = "ufs"; + vfstype = NULL; while ((ch = getopt(argc, argv, "adF:flo:prt:uvw")) != -1) switch (ch) { case 'a': @@ -516,7 +519,7 @@ optbuf = catopt(optbuf, "update"); /* Compatibility glue. */ - if (strcmp(vfstype, "msdos") == 0) + if (vfstype != NULL && strcmp(vfstype, "msdos") == 0) vfstype = "msdosfs"; /* Construct the name of the appropriate mount command */ @@ -532,8 +535,11 @@ if (debug) { if (use_mountprog(vfstype)) printf("exec: mount_%s", vfstype); - else - printf("mount -t %s", vfstype); + else { + printf("mount "); + if (vfstype != NULL) + printf("-t %s", vfstype); + }; for (i = 1; i < argc; i++) (void)printf(" %s", argv[i]); (void)printf("\n"); Index: mount_fs.c =================================================================== RCS file: /home/ncvs/src/sbin/mount/mount_fs.c,v retrieving revision 1.3 diff -u -u -r1.3 mount_fs.c --- mount_fs.c 7 Dec 2006 03:24:43 -0000 1.3 +++ mount_fs.c 18 Jan 2007 13:41:53 -0000 @@ -50,8 +50,10 @@ #include #include +#include #include +#include #include #include #include @@ -62,6 +64,8 @@ #include "extern.h" #include "mntopts.h" +extern int debug, verbose; + struct mntopt mopts[] = { MOPT_STDOPTS, MOPT_END @@ -75,8 +79,9 @@ exit(1); } -int -mount_fs(const char *vfstype, int argc, char *argv[]) +static int +do_mount_fs(const char *vfstype, int argc, char *argv[], int *nmount_errno, + char *msg, size_t msg_len) { struct iovec *iov; int iovlen; @@ -131,8 +136,83 @@ build_iovec(&iov, &iovlen, "errmsg", errmsg, sizeof(errmsg)); ret = nmount(iov, iovlen, mntflags); + if (nmount_errno != NULL) + *nmount_errno = errno; if (ret < 0) - err(1, "%s %s", dev, errmsg); + snprintf(msg, msg_len, "%s : %s : %s", dev, errmsg, + strerror(errno)); + + return (ret); +} + +static int +mount_fs_try(int argc, char *argv[]) +{ + struct xvfsconf *vfsp; + char msg[512]; + unsigned int cnt, i; + int ret, j, nmount_errno; + size_t buflen; + + /* First, see if mounting mounting with vfstype "ufs" works. */ + ret = do_mount_fs("ufs", argc, argv, &nmount_errno, msg, sizeof(msg)); + if (ret == 0) + return (0); + + /* Get a list of registered vfs types */ + if (sysctlbyname("vfs.conflist", NULL, &buflen, NULL, 0) < 0) + err(1, "sysctl(vfs.conflist)"); + vfsp = malloc(buflen); + if (vfsp == NULL) + errx(1, "malloc failed"); + if (sysctlbyname("vfs.conflist", vfsp, &buflen, NULL, 0) < 0) + err(1, "sysctl(vfs.conflist)"); + cnt = buflen / sizeof(struct xvfsconf); + + for (i = 0; i < cnt; i++) { + /* We already tried "ufs" above, so skip it. */ + if (strcmp("ufs", vfsp[i].vfc_name) == 0) + continue; + /* + * Only try local filesystems. Skip network, synthetic, + * and loopback filesystems. + */ + if (vfsp[i].vfc_flags & + (VFCF_NETWORK | VFCF_SYNTHETIC | VFCF_LOOPBACK)) + continue; + + if (debug || verbose) { + printf("mount -t %s ", vfsp[i].vfc_name); + for (j = 1; j < argc; j++) + (void)printf(" %s", argv[j]); + (void)printf("\n"); + } + ret = do_mount_fs(vfsp[i].vfc_name, argc, argv, &nmount_errno, + msg, sizeof(msg)); + if (ret == 0 || nmount_errno != EINVAL) + break; + } + free(vfsp); + + if (ret < 0) + printf("%s", msg); + return (ret); +} + +int +mount_fs(const char *vfstype, int argc, char *argv[]) +{ + char msg[512]; + int ret, nmount_errno; + + if (vfstype != NULL) { + ret = do_mount_fs(vfstype, argc, argv, &nmount_errno, msg, + sizeof(msg)); + if (ret < 0) + printf("%s", msg); + } + else + ret = mount_fs_try(argc, argv); return (ret); } --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 13:55:40 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D09D16A60B for ; Thu, 18 Jan 2007 13:55:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 6B05513C455 for ; Thu, 18 Jan 2007 13:55:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2007 05:55:40 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0IDtdqW030400 for ; Thu, 18 Jan 2007 05:55:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0IDtcGk003338 for ; Thu, 18 Jan 2007 05:55:39 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 05:55:37 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 05:55:37 -0800 Message-ID: <45AF7C3A.2080303@cisco.com> Date: Thu, 18 Jan 2007 08:55:06 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2007 13:55:37.0849 (UTC) FILETIME=[55325E90:01C73B08] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1200; t=1169128540; x=1169992540; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Zone=20memory=20for=20UMA |Sender:=20; bh=yWravBXhL4Kr0FmE9zg4Wws/hJ7aXcsE+2fmqY2fHLk=; b=rEvP8kbu4Tcfo06Q89jDGm78jAiKZ0ooC0l+jVo9IpSvUSJEv4oyASd6VFzFxl9WFncqZILr K3NaZISpT8O9zTtRzGP2ZUU7aWYrIlinym/u9ga0c68OTypxXpyRJ2hV; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: Subject: Zone memory for UMA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 13:55:40 -0000 Hi all: Query (with flame suit in place :-D) Currently the UMA zone's will hold all memory in them until .. well until the page deamon runs.. or so the "zone_drain()" comment says.. but I can't find that connection either. So I guess not at all :-0 The only zone that seems to get drain'ed is the zone for ZONE headers it would appear as part of its destructor ... So this means we have no real way that I can see to give back memory to the system. So.. here is a question.. Should we think about adding some sort of garbage collector thread.. that could hang around slowly and periodically look for a zone with large numbers of free pages... and then drain that zone? Or maybe this already exists and I just can't find the connection??? Yes, I know there are pluses and minuses to GC's and we would have to have a way to turn it on/off as well as set up thresholds and control its timing... But it seems to me that it would be something worth doing... I am willing to build such a critter .. if folks are interested... Comments/thoughts (yes even flames)?? R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 14:15:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E07016A541 for ; Thu, 18 Jan 2007 14:15:42 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D01C13C44B for ; Thu, 18 Jan 2007 14:15:42 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7Y30-0002c9-TS for freebsd-current@freebsd.org; Thu, 18 Jan 2007 15:15:26 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Jan 2007 15:15:22 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Jan 2007 15:15:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 18 Jan 2007 15:15:15 +0100 Lines: 12 Message-ID: References: <45AF7C3A.2080303@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <45AF7C3A.2080303@cisco.com> Sender: news Subject: Re: Zone memory for UMA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 14:15:42 -0000 Randall Stewart wrote: > Should we think about adding some sort of garbage > collector thread.. that could hang around slowly and > periodically look for a zone with large numbers of free > pages... and then drain that zone? > > Or maybe this already exists and I just can't find the > connection??? If it doesn't exist, it would probably be better to piggyback that to some already existing garbage collector thread. From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 14:43:17 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4140116A40F for ; Thu, 18 Jan 2007 14:43:17 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id DEB5B13C4B9 for ; Thu, 18 Jan 2007 14:43:16 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so185572wri for ; Thu, 18 Jan 2007 06:43:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CM1ZIaHEYDletkS0zFuIe+I8fm0u9eDLBCxKg8jYWWaOvSKfhUt7k9ZGxhs6swPi3MEndBljtQoGf32EPB0e7dD1g3Om439HGVLSfb/vpujdjDgzOdVBLzM6vemZx3Wj+dUp8uyNSdT7ch1w+0oFUNDkkst99dzd7jawPH1UXrA= Received: by 10.78.123.4 with SMTP id v4mr839939huc.1169129689470; Thu, 18 Jan 2007 06:14:49 -0800 (PST) Received: by 10.78.164.20 with HTTP; Thu, 18 Jan 2007 06:14:49 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 17:14:49 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Craig Rodrigues" In-Reply-To: <20070118134936.GA7391@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070118134936.GA7391@crodrigues.org> X-Google-Sender-Auth: 5fe0465356a9b5cb Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 14:43:17 -0000 On 1/18/07, Craig Rodrigues wrote: > Hi, > > This is a different version of the patch I posted here: > http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005439.html > > One of the pet peeves I have with FreeBSD is that > if I have a device with a local filesystem that I want to mount, > I need to explicitly know what type of filesystem is on the > device in order to mount it from the command-line. > > For example, > > mount -t cd9660 > mount -t udf > mount -t ext2fs > mount -t msdosfs > > Where this is particularly annoying is if I have multiple > USB thumb drives with different filesystems on them. > > What I usually end up doing is something like: > file - < /dev/ad0s4 > > to figure out the filesystem type, and then mount -t [whatever] to mount it. > > What I would like to do is: > > mount /dev/ad0s4 /mnt > > and if I do not specify a filesystem type with -t, the mount > program should "magically" figure out how to mount the disk. > This is closer to how the mount program behaves on Linux for example. > > In this patch, I only modified the userland mount program. > If the user does not specify "-t vfstype" to mount, > the mount program gets a list of local filesystems from the vfs.conflist > sysctl. It then tries to mount the filesystem, always > starting with "ufs", and then iterating through the list if > the nmount() fails with EINVAL. > > Using this patch, I have been able to do: > mount /dev/blah /mnt > > and mount a UFS, cd9660, or FAT filesystem, depending on what filesystem > is on the /dev/blah device. > > Comments? I would love to have this usability enhancement around! 1. Are there any (what are the) security implications? 2. "mount -t auto" might be closer to POLA I might have other comments later :) Thanks Craig! From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 14:49:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930AF16A412; Thu, 18 Jan 2007 14:49:38 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB4813C44B; Thu, 18 Jan 2007 14:49:33 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0IEnCAD039877; Thu, 18 Jan 2007 06:49:13 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0IEnCDM039876; Thu, 18 Jan 2007 06:49:12 -0800 (PST) (envelope-from rizzo) Date: Thu, 18 Jan 2007 06:49:12 -0800 From: Luigi Rizzo To: Andrew Pantyukhin Message-ID: <20070118064912.A39777@xorpc.icir.org> References: <20070118134936.GA7391@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from infofarmer@freebsd.org on Thu, Jan 18, 2007 at 05:14:49PM +0300 Cc: Craig Rodrigues , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 14:49:38 -0000 On Thu, Jan 18, 2007 at 05:14:49PM +0300, Andrew Pantyukhin wrote: > On 1/18/07, Craig Rodrigues wrote: ... > > One of the pet peeves I have with FreeBSD is that > > if I have a device with a local filesystem that I want to mount, > > I need to explicitly know what type of filesystem is on the > > device in order to mount it from the command-line. ... > > Where this is particularly annoying is if I have multiple > > USB thumb drives with different filesystems on them. ... > > What I would like to do is: > > > > mount /dev/ad0s4 /mnt > > > > and if I do not specify a filesystem type with -t, the mount > > program should "magically" figure out how to mount the disk. > > This is closer to how the mount program behaves on Linux for example. > > > > In this patch, I only modified the userland mount program. ... > 2. "mount -t auto" might be closer to POLA great feature. I probably agree that "mount -t auto" might be a safer way to implement it, but other than that i'd love to have it too. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 15:14:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A22216A407; Thu, 18 Jan 2007 15:14:32 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1100313C457; Thu, 18 Jan 2007 15:14:32 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 4608C91; Thu, 18 Jan 2007 09:49:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on filt2.ece.cmu.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=BAYES_50 autolearn=no version=3.1.4 Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 4F71B8E; Thu, 18 Jan 2007 09:49:21 -0500 (EST) In-Reply-To: References: <20070118134936.GA7391@crodrigues.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Thu, 18 Jan 2007 09:49:19 -0500 To: "Andrew Pantyukhin" X-Mailer: Apple Mail (2.752.2) Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 15:14:32 -0000 On Jan 18, 2007, at 9:14 , Andrew Pantyukhin wrote: > On 1/18/07, Craig Rodrigues wrote: >> In this patch, I only modified the userland mount program. >> If the user does not specify "-t vfstype" to mount, >> the mount program gets a list of local filesystems from the >> vfs.conflist >> sysctl. It then tries to mount the filesystem, always >> starting with "ufs", and then iterating through the list if >> the nmount() fails with EINVAL. > > I would love to have this usability enhancement around! > > 1. Are there any (what are the) security implications? > 2. "mount -t auto" might be closer to POLA ISTR from back when Linux added this that the bigger problem is that the msdos filesystem may sometimes accept filesystems it shouldn't, because the only way to catch an invalid filesystem is heuristics. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 15:48:35 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 170AC16A417; Thu, 18 Jan 2007 15:48:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id CC1A513C442; Thu, 18 Jan 2007 15:48:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AD56A2089; Thu, 18 Jan 2007 16:13:44 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 3205B2087; Thu, 18 Jan 2007 16:13:44 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 1001) id 9C047B86E; Thu, 18 Jan 2007 16:15:00 +0100 (CET) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Craig Rodrigues References: <20070118134936.GA7391@crodrigues.org> Date: Thu, 18 Jan 2007 16:15:00 +0100 In-Reply-To: <20070118134936.GA7391@crodrigues.org> (Craig Rodrigues's message of "Thu, 18 Jan 2007 08:49:36 -0500") Message-ID: <86lkk02wp7.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 15:48:35 -0000 Craig Rodrigues writes: > This is a different version of the patch I posted here: > http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005439.html Didn't somebody mention ordering issues back then? Your revised patch still doesn't even try to address those. If we ever get ext3 support, for instance, mounting an ext2 file system as ext3 might cause it to be silently upgraded to ext3. Not to mention the slew of error messages this will result in as you walk the list of filesystems trying to find the right one... A better way would be to have a userland utility attempt to identify the file system, and if necessary load the appropriate module, before mounting it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 16:31:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 859DA16A407; Thu, 18 Jan 2007 16:31:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 42CFD13C461; Thu, 18 Jan 2007 16:31:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0IGVUaW055389; Thu, 18 Jan 2007 11:31:30 -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.8/8.13.8) with ESMTP id l0IGVTOd057263; Thu, 18 Jan 2007 11:31:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B5D5773034; Thu, 18 Jan 2007 11:31:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118163129.B5D5773034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 11:31:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner4 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 16:31:31 -0000 TB --- 2007-01-18 15:19:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 15:19:06 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-18 15:19:06 - cleaning the object tree TB --- 2007-01-18 15:19:38 - checking out the source tree TB --- 2007-01-18 15:19:38 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-18 15:19:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 15:26:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 15:26:50 - cd /src TB --- 2007-01-18 15:26:50 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 15:26:52 UTC 2007 >>> 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 >>> World build completed on Thu Jan 18 16:22:32 UTC 2007 TB --- 2007-01-18 16:22:32 - generating LINT kernel config TB --- 2007-01-18 16:22:32 - cd /src/sys/sun4v/conf TB --- 2007-01-18 16:22:32 - /usr/bin/make -B LINT TB --- 2007-01-18 16:22:32 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 16:22:32 - cd /src TB --- 2007-01-18 16:22:32 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 16:22:32 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 16:31:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 16:31:29 - ERROR: failed to build lint kernel TB --- 2007-01-18 16:31:29 - tinderbox aborted TB --- 0.59 user 2.00 system 4342.82 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 16:32:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D48516A4A0; Thu, 18 Jan 2007 16:32:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3354D13C455; Thu, 18 Jan 2007 16:32:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0IGW53x055518; Thu, 18 Jan 2007 11:32:05 -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.8/8.13.8) with ESMTP id l0IGW5ws088418; Thu, 18 Jan 2007 11:32:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 58BFC73036; Thu, 18 Jan 2007 11:32:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118163205.58BFC73036@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 11:32:05 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 16:32:06 -0000 TB --- 2007-01-18 15:13:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 15:13:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-01-18 15:13:06 - cleaning the object tree TB --- 2007-01-18 15:13:36 - checking out the source tree TB --- 2007-01-18 15:13:36 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-01-18 15:13:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 15:26:50 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 15:26:50 - cd /src TB --- 2007-01-18 15:26:50 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 15:26:52 UTC 2007 >>> 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 >>> World build completed on Thu Jan 18 16:22:52 UTC 2007 TB --- 2007-01-18 16:22:52 - generating LINT kernel config TB --- 2007-01-18 16:22:52 - cd /src/sys/sparc64/conf TB --- 2007-01-18 16:22:52 - /usr/bin/make -B LINT TB --- 2007-01-18 16:22:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 16:22:52 - cd /src TB --- 2007-01-18 16:22:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 16:22:52 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 16:32:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 16:32:05 - ERROR: failed to build lint kernel TB --- 2007-01-18 16:32:05 - tinderbox aborted TB --- 0.68 user 2.38 system 4738.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 18:13:07 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23D8816A4C2; Thu, 18 Jan 2007 18:13:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E365313C4A5; Thu, 18 Jan 2007 18:13:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0IID6oU069906; Thu, 18 Jan 2007 13:13:06 -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.8/8.13.8) with ESMTP id l0IID5Rn067281; Thu, 18 Jan 2007 13:13:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8D9DE73034; Thu, 18 Jan 2007 13:13:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118181305.8D9DE73034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 13:13:05 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 18:13:07 -0000 TB --- 2007-01-18 16:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 16:35:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-18 16:35:00 - cleaning the object tree TB --- 2007-01-18 16:35:48 - checking out the source tree TB --- 2007-01-18 16:35:48 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-18 16:35:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 16:46:46 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 16:46:46 - cd /src TB --- 2007-01-18 16:46:46 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 16:46:47 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jan 18 18:03:27 UTC 2007 TB --- 2007-01-18 18:03:27 - generating LINT kernel config TB --- 2007-01-18 18:03:27 - cd /src/sys/amd64/conf TB --- 2007-01-18 18:03:27 - /usr/bin/make -B LINT TB --- 2007-01-18 18:03:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 18:03:28 - cd /src TB --- 2007-01-18 18:03:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 18:03:28 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 18:13:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 18:13:05 - ERROR: failed to build lint kernel TB --- 2007-01-18 18:13:05 - tinderbox aborted TB --- 0.77 user 3.55 system 5884.72 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 18:22:09 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7AF616A583; Thu, 18 Jan 2007 18:22:09 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (trang.nuxi.org [66.93.134.19]) by mx1.freebsd.org (Postfix) with ESMTP id BCBD913C457; Thu, 18 Jan 2007 18:22:09 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.8/8.13.8) with ESMTP id l0II0vYJ065911; Thu, 18 Jan 2007 10:00:57 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.8/8.13.7/Submit) id l0II0vJn065910; Thu, 18 Jan 2007 10:00:57 -0800 (PST) (envelope-from obrien) Date: Thu, 18 Jan 2007 10:00:57 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20070118180057.GD65429@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, John Baldwin , Sergey Zaharchenko , freebsd-current@freebsd.org References: <20070110120731.GA1515@shark.localdomain> <200701100910.13167.jhb@freebsd.org> <20070110155331.GA2762@shark.localdomain> <200701101432.41201.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701101432.41201.jhb@freebsd.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Sergey Zaharchenko Subject: Re: nve related LOR triggered by lots of small packets, and a hard hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 18:22:10 -0000 On Wed, Jan 10, 2007 at 02:32:40PM -0500, John Baldwin wrote: > On Wednesday 10 January 2007 10:53, Sergey Zaharchenko wrote: > > Hello John! > > > > Wed, Jan 10, 2007 at 09:10:12AM -0500 you wrote: > > [snip] > > > Have you tried using nfe(4)? :) > > > > Now I have, and it works just fine, thanks (I somehow thought nfe was > > specific to some platform). Why isn't it the default? Smaller range of > > hardware supported? > > It's just newer. I think perhaps current@ should switch to nfe(4) rather > than nve(4) by default. David, any objections to that? nfe(4) is not ready - I recently got two new machines that nve(4) works fine on and nfe(4) is totally broken on. I had hoped to make nfe(4) the default already and MFC it to RELENG_6, but I think that will only bring PR's to us. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 18:59:13 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 310F616A49E; Thu, 18 Jan 2007 18:59:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id DC09613C448; Thu, 18 Jan 2007 18:59:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0IIxCJW077563; Thu, 18 Jan 2007 13:59:12 -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.8/8.13.8) with ESMTP id l0IIxCZt017226; Thu, 18 Jan 2007 13:59:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1141373034; Thu, 18 Jan 2007 13:59:12 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118185912.1141373034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 13:59:11 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 18:59:13 -0000 TB --- 2007-01-18 17:43:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 17:43:03 - starting HEAD tinderbox run for i386/i386 TB --- 2007-01-18 17:43:03 - cleaning the object tree TB --- 2007-01-18 17:43:47 - checking out the source tree TB --- 2007-01-18 17:43:47 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-01-18 17:43:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 17:52:22 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 17:52:22 - cd /src TB --- 2007-01-18 17:52:22 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 17:52:23 UTC 2007 >>> 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 >>> World build completed on Thu Jan 18 18:48:50 UTC 2007 TB --- 2007-01-18 18:48:50 - generating LINT kernel config TB --- 2007-01-18 18:48:50 - cd /src/sys/i386/conf TB --- 2007-01-18 18:48:50 - /usr/bin/make -B LINT TB --- 2007-01-18 18:48:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 18:48:50 - cd /src TB --- 2007-01-18 18:48:50 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 18:48:50 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 18:59:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 18:59:11 - ERROR: failed to build lint kernel TB --- 2007-01-18 18:59:11 - tinderbox aborted TB --- 0.86 user 2.73 system 4568.61 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 19:27:25 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F3A216A407; Thu, 18 Jan 2007 19:27:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6B23C13C45A; Thu, 18 Jan 2007 19:27:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0IJROnB082281; Thu, 18 Jan 2007 14:27:25 -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.8/8.13.8) with ESMTP id l0IJROhF046818; Thu, 18 Jan 2007 14:27:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8E6BB73034; Thu, 18 Jan 2007 14:27:24 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118192724.8E6BB73034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 14:27:24 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 19:27:25 -0000 TB --- 2007-01-18 18:13:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 18:13:05 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-01-18 18:13:05 - cleaning the object tree TB --- 2007-01-18 18:13:37 - checking out the source tree TB --- 2007-01-18 18:13:37 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-01-18 18:13:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 18:25:43 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 18:25:43 - cd /src TB --- 2007-01-18 18:25:43 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 18:25:45 UTC 2007 >>> 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 >>> World build completed on Thu Jan 18 19:19:04 UTC 2007 TB --- 2007-01-18 19:19:04 - generating LINT kernel config TB --- 2007-01-18 19:19:04 - cd /src/sys/pc98/conf TB --- 2007-01-18 19:19:04 - /usr/bin/make -B LINT TB --- 2007-01-18 19:19:04 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 19:19:04 - cd /src TB --- 2007-01-18 19:19:04 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 19:19:04 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 19:27:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 19:27:24 - ERROR: failed to build lint kernel TB --- 2007-01-18 19:27:24 - tinderbox aborted TB --- 0.80 user 2.72 system 4458.52 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 20:06:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8B3C16A492; Thu, 18 Jan 2007 20:06:51 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6824113C478; Thu, 18 Jan 2007 20:06:51 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.7/8.13.7) with ESMTP id l0IJmebi061674; Thu, 18 Jan 2007 11:51:41 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.7/8.13.4/Submit) id l0IJmdfn061671; Thu, 18 Jan 2007 11:48:39 -0800 (PST) Date: Thu, 18 Jan 2007 11:48:39 -0800 (PST) From: Matthew Dillon Message-Id: <200701181948.l0IJmdfn061671@apollo.backplane.com> To: Bruce Evans References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> Cc: Attilio Rao , freebsd-current@freebsd.org, Ivan Voras , freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 20:06:51 -0000 :Fully cached case: :% copy0: 16907105855 B/s ( 242265 us) (movsq) :% ... :% copyQ: 13658478027 B/s ( 299887 us) (movdqa) :% ... :% copyT: 16456408196 B/s ( 248900 us) (movq (i)) : :This doesn't contradict your claim since main memory is not really involved. :Everything should be limited by instruction and cache bandwidth, but for :some reason movdqa is quite slow despite or because of my attempts to :schedule it perfectly. Well, that's one of the problems. Actually two of the problems. First, prefetching tends to add more confusion then it solves when used in a copy loop, because for all intents and purposes you are already keeping the memory pipeline full simply by the fact that the writes are buffered. By the time the loop gets back around to the read it has to stall anyway because the writes are still being pushed out to memory (read-before-write ordering doesn't help because all that accomplishes is to force the write buffer to stay perpetually full (possibly in a non-optimal fashion), and the cpu stalls anyway. I've tried every combination of prefetching and non-temporal instructions imagineable and it has reduced performance more often then it has improved it. I can write an optimal copy loop for particular situations but the problem is that the same loop becomes extremely inefficient under any *OTHER* conditions. The behavior of any given copy algorithm is radically different if either the source or target are present in the L1 or L2 caches, verses if they aren't. The algorithm one uses to do tiny mostly in-cache copies is totally different from the algorithm one uses to do large bulk copies. The algorithm one uses where the source data is partially or fully cached is totally different from the one used if the target data is partially or fully cached, or if neither is cached, or if both are cached. :Fully uncached case: :% copy0: 829571300 B/s ( 493749 us) (movsq) :% ... :% copyQ: 835822845 B/s ( 490056 us) (movdqa) :% copyR: 908423544 B/s ( 450891 us) (movdqa with prefetchnta) :% copyS: 919026496 B/s ( 445689 us) (movdqa with block prefetch) :% copyT: 828993732 B/s ( 494093 us) (movq (i)) :% copyU: 905141362 B/s ( 452526 us) (movq (i) with prefetchnta) :% copyV: 910626945 B/s ( 449800 us) (movq (i) with block prefetch) :% copyW: 1350397932 B/s ( 303318 us) (movnti) :% copyX: 1662594069 B/s ( 246362 us) (movnti with prefetchnta) :% copyY: 1608204355 B/s ( 254694 us) (movnti with block prefetch) : :Now movdqa beats movsq by a bit, at least with prefetch, but has the :same speed as integer moves of half the size (or MMX moves of half the :size (benchmark data not shown)). It is necessary to use movnt to get :anywhere near memory bandwidth, and any form of movnt can be used for :this (I test mainly movntps in addition to the above, since it is most :portable). There is apparently some magic to combine 8-byte writes :if necessary for efficient main memory accesses. The above was run :on an old A64 overclocked a lot to 2204 MHz, with mediocre DDR-1 PC3200 :memory overclocked a bit and tuned a lot. The maximum bandwidth :achieved is almost exactly PC3200 but the theoretical maximum is more :like PC3400. But you can't safely use *ANY* non-temporal instruction unless you know, specifically, that the data is uncached. If you use a non-temporal instruction in a situation where the data is cached or can be easily cached, you destroy the performance for that case by causing the cpu not to cache data that it really should cache. Use of non-temporal instructions results in a non-self-healing algorithm... it is possible to get into a situation the is permanently non-optimal. That's why I don't use those instructions. Sometimes I wish the non-temporal instructions had a random component. That is, that they randomly operates as normal moves instead of nt moves for a small percentage of executions (~1-25%) in order to create a self-healing (performance wise) algorithm. :> :> Alignment is critical. If the data is not aligned, don't bother. 128 :> bits means 16 byte alignment. : :The above benchmark output is for aligned data :-). I don't try hard to :optimize or benchmark misaligned cases. Neither do I. I expect if the program wants to copy a large amount of data that the programmer is smart enough to align it. :... :- movnt* is a clear win in at least one case: zeroing pages in idle. : FreeBSD on i386 uses movnti for all zeroing of pages in the SSE2 case. : This might not be best for non-idle zeroing. Maybe it should be used : only for multiple pages. For single pages, it is probably for a : pagefault and you want at least the data near the fault address in : the cache. FreeBSD on amd64 also uses movnti for all copying of pages. Use of non-temporal instructions for non performance-critical operations is a clear win when executed from the idle loop, I agree. Use of NT instructions in any other case is difficult because it is virtually impossible to predict the conditions under which other cases occur. :I think SunOS on amd64 uses movnt* whenever the copy size is >= 128. This :seems too small. : :> I've given up trying to use either mechanism. Instead, I prefer :> copying as large a block as possible to remove these variables from :> the cpu pipeline entirely. The cpu has a write fifo anyway, you :> don't need prefetch instructions if you can use instructions to write :> to memory faster then available L2 cache bandwidth. On some cpus :> this mandates the use of 64 or 128 bit media instructions or the :> cpu can't keep the write FIFO full and starts interleaving reads :> and writes on the wrong boundaries (creating more RAS cycles, which :> is what kills copy bandwidth). : :Which modern CPUs can't keep up with L2? The instruction pipeline is the problem, not the L2 cache bandwidth. Things get a bit weird when every single instruction is reading or writing memory. I try to design algorithms that work reasonably well across a large swath of cpus. It turns out that algorithms which do block loads followed by block stores tend to maintain consistent and good performance across a large swath of cpus. I outline the reasons why later on. :On amd64 for the fully-L2-cached case: :% copy0: 4382675165 B/s ( 934589 us) (movsq) :% ... :% copyN: 3432351420 B/s (1193351 us) (movntq) :% copyO: 1777008820 B/s (2304997 us) (movntq with prefetchnta) :% copyP: 3278961491 B/s (1249176 us) (movntq with block prefetch) :% copyQ: 4369052686 B/s ( 937503 us) (movdqa) :% copyR: 2785886655 B/s (1470268 us) (movdqa with prefetchnta) :% copyS: 4553271385 B/s ( 899573 us) (movdqa with block prefetch) :% copyT: 4401466152 B/s ( 930599 us) (movq (i)) :% copyU: 2817507895 B/s (1453767 us) (movq (i) with prefetchnta) :% copyV: 4523562615 B/s ( 905481 us) (movq (i) with block prefetch) :% copyW: 3432429080 B/s (1193324 us) (movnti) :% copyX: 1776507852 B/s (2305647 us) (movnti with prefetchnta) :% copyY: 3136767185 B/s (1305803 us) (movnti with block prefetch) : :So here is a case where prefetchnta is bad. OTOH, movnti is quite fast :provided prefetchnta is not used with it. movnti is even more competitive :with L2 if main memory is DDR-2. It also depends *WHERE* in the loop you put the prefetchnta. I was able to get fairly close to block prefetching speeds using prefetchnta by carefully locating the instruction and adjusting the read-ahead point. For example, by locating the instruction before the write side and indexing the prefetched memory address 128 bytes ahead of the curve. The placement of the instruction is sensitive down to the instruction slot... moving it one forward or one back can result in crazy differences in performance (due to forced RAS cycles I believe, in particular with prefetchnta). So two variables.. how far ahead you try to prefetch (which depends heavily on the memory architecture, banking, instruction pipeline size, etc), and where you locate the instruction. Two impossible variables. I could optimize a particular case, but wound up nerfing every *OTHER* case. I finally gave up. :... :> But at this point the alignment requirements start to get kinda :> silly. 128 byte alignment requirement? I don't think so. I :> do a 16-byte alignment check in DragonFly as a pre-req for using :> XMM and that's it. : ::-). There are just too many combinations to even think about. I prefer :to reduce the number of cases by depending on the prefetching working :reasonably well. Yup. :> I don't know about AMD64. You only have 64 bit general registers in 64 :> bit mode so you may not be able to keep the write pipeline full. But :> you do have 8 of them so you are roughly equivalent to MMX (but not : 16, almost :> XMM's 8 128 bit registers). : :On A64 and AXP, most things are limited by the load/store unit (LSU), :the 3 integer pipelines, and SSE latency (but latency is not a problem :here). : :Load/store-unit: : : (lots of good information about load-store units) Well, but these are for very specific flavor-of-the-day hardware tweaks. The designers change these parameters literally every other month. All that can really be said here is: Avoid 32 bit accesses if you can, 64 bit accesses seem to be the most dependable, and 128 bit accesses are the up-and-coming thing. In particular I remember reading that AMD had been spending a lot of time optimizing XMM register loads and stores. I presume that Intel is doing the same thing since both are going face forward into gaming. I'm not surprised at all about movs* performance. That instruction was originally microcoded. AMD tried harder to optimize it then Intel, but it still doesn't work very well simply due to instruction pipeline constraints. The hardware goes nuts trying to optimize movs*. :The asymmetric load/store capabilities on the AXP can't be good for using :128-bit XMM registers, especially using 8 loads followed by 8 stores in :the instruction stream. They make 128 stores want to take twice as long :as 2 64-bits ones, and it takes a large amount of out of order execution :to reorder things to reach the "1 64-bit load and 1 64-bit store" per :cycle pattern. Reordering is exactly what you don't want for controlling :the interleaving of access to main memory. Even with a simple load-store- :load-store with 64-bit accesses in the instruction, stream, the there :will be some reordering -- the reads will get 1 ahead of the writes. :This explains why my movdqa benchmark is slow on AXP but not why it is :slow on A64. The advantages of doing N loads followed by N stores (where N >= 4 and operates on 64 or 128 bit entities) are as follows: * There is no instruction or register reordering (or very little) because the data loaded by any given instruction is not used until e.g. 8 instructions later. * The write buffer is ordered (either through to the L2 cache or to main memory, it doesn't matter). This enforces a degree of resynchronization of the instruction stream. That is, it creates a self-healing situation that makes it possible to write code that works very well under all sorts of conditions. * The read instructions should theoretically tend not to be reordered simply because the memory pipeline imposes a stall due to handling previously buffered writes and because of the burst nature of linear reads from main memory. Even if the cpu DID reorder the reads, it can only actually retire instructions as the data actually comes in from main memory. Such data will always be fairly well ordered in either 0-1-2-3 or 3-2-1-0 bursts, or at the minimum cache-line bursts. Some reordering might occur if some of the read instructions access cached data, but even in that case I just don't think it happens. There is simply nothing there for the cpu to reorder. * I don't think the cpu could reorder reads or reorder reads and writes under these conditions even if it wanted to, and we don't want it to. * Write combining is overrated. It serves an important purpose, but it is a bad idea to actually depend on it unless your algorithm is self-healing from the point of view of resynchronizing the pipeline and/or memory read and write ordering. Instruction pipelines and cache pipelines are quite evenly matched these days (usually no more then 1:2 performance) so depending on write combining will actually cause chain stalls in the cache pipeline (not using a cache cycle that was potentially available to use) when the instruction pipeline stalls on a memory read, because the cpu wanted to try to combine the writes. These are boundary conditions for sure. It is best to remember that the instruction pipeline is stalling several times on every loop due to main memory accesses. You can't avoid it, but you can try to manage it. I am not familiar enough with the architectures to know whether the cpu does burst reads from main memory into the cache... e.g. 4 cache line bursts at a time. My assumption has always been that the cpu does do burst reads, because it's so easy to do. Any sort of burst reading into the cache by the cpu only creates an advantage for this architecture because there are no dependancies between instructions for 8 instruction slots and because it enforces an ordering to both read and write instructions that tends to self-heal the algorithm from a performance standpoint. So, in summary... the reason I use block loads and stores (sequences of 8 MMX or XMM loads followed by 8 MMX or XMM stores) is that these sorts of inner loops appear to generate very good results under all operating conditions. When I have attempted to use prefetcha, prefetchnta, or non-temporal moves (movnt* instead of movdq*) the result has been better performance only under certain very carefully controlled circumstances, and terrible performance otherwise. IMHO, I do believe that 64 bit loads and stores is plenty good enough for today's cpus, but it is also clear that 128 bit loads and stores will be better for tomorrow's cpus and works at least as well on today's cpus as 64 bit loads and stores, at least insofar as 128 bit registers can be made available to the kernel. -- It should be possible to use MMX/XMM registers in the kernel simply as call-saved registers by issuing a FWAIT or equivalent at the user-kernel boundary to take care of any exceptions (instead of saving the state and calling clts ; fnclex). Presumably by the time the cpu actually gets the integer and cpu state context pushed any FP operations will have long sinced completed. But I haven't timed it to find out whether that actually works. The nice thing about most MMX/XMM media instructions is that they don't actually care about what state the FP unit is in because they aren't actually doing any FP math. It is just a matter of synchronizing the free FP registers from some prior user FP operation which may not have posted results yet. If this IS possible then it removes most of the NPXTHREAD junk from the kernel bcopy path for the case where NPXTHREAD != NULL, giving you the ability to use the FP optimally whether NPXTHREAD == NULL or NPXTHREAD != NULL. And, in such a case, it might be more beneficial for small copies to only save two or four XMM registers instead of all eight. What do you think? -Matt Matthew Dillon :Bruce : From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 20:35:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04BF616A412; Thu, 18 Jan 2007 20:35:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B425313C441; Thu, 18 Jan 2007 20:35:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0IKZAgR082794; Thu, 18 Jan 2007 15:35:10 -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.8/8.13.8) with ESMTP id l0IKZAlf083123; Thu, 18 Jan 2007 15:35:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5D1FF73034; Thu, 18 Jan 2007 15:35:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070118203510.5D1FF73034@freebsd-current.sentex.ca> Date: Thu, 18 Jan 2007 15:35:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 20:35:12 -0000 TB --- 2007-01-18 18:59:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-18 18:59:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-01-18 18:59:12 - cleaning the object tree TB --- 2007-01-18 18:59:44 - checking out the source tree TB --- 2007-01-18 18:59:44 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-01-18 18:59:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-18 19:08:16 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-18 19:08:16 - cd /src TB --- 2007-01-18 19:08:16 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 18 19:08:17 UTC 2007 >>> 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 >>> World build completed on Thu Jan 18 20:23:05 UTC 2007 TB --- 2007-01-18 20:23:05 - generating LINT kernel config TB --- 2007-01-18 20:23:05 - cd /src/sys/ia64/conf TB --- 2007-01-18 20:23:05 - /usr/bin/make -B LINT TB --- 2007-01-18 20:23:05 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-18 20:23:05 - cd /src TB --- 2007-01-18 20:23:05 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 18 20:23:05 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_lmi.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_mppc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_nat.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_one2many.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_parse.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/netgraph/ng_ppp.c /src/sys/netgraph/ng_ppp.c: In function `ng_ppp_rcvdata': /src/sys/netgraph/ng_ppp.c:1287: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-18 20:35:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-18 20:35:10 - ERROR: failed to build lint kernel TB --- 2007-01-18 20:35:10 - tinderbox aborted TB --- 0.71 user 2.43 system 5758.02 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 20:43:54 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AD8716A412 for ; Thu, 18 Jan 2007 20:43:54 +0000 (UTC) (envelope-from rosti.bsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id E530413C457 for ; Thu, 18 Jan 2007 20:43:53 +0000 (UTC) (envelope-from rosti.bsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so289554nfc for ; Thu, 18 Jan 2007 12:43:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=RmlnNMHa1WCIQJeEUA6JIYbkVhcT7oX+OAMbUn8sxW+1ky/hrWF7SWnVZs6U4XQ2jd+q3MnThcnZF9FJc36w09E6lT6/6RRkz70YUhSDUAnx6YdCdLwgsK/SyUptqty3Cx8XGkkk+WdASnSR8kdexeUriKKdxggcmom0vC+oWd4= Received: by 10.49.21.8 with SMTP id y8mr1300082nfi.1169151474631; Thu, 18 Jan 2007 12:17:54 -0800 (PST) Received: from saturn.lan ( [80.179.18.46]) by mx.google.com with ESMTP id k23sm3174124nfc.2007.01.18.12.17.53; Thu, 18 Jan 2007 12:17:54 -0800 (PST) Date: Thu, 18 Jan 2007 22:17:49 +0200 From: Rostislav Krasny To: Craig Rodrigues Message-Id: <20070118221749.3be589d9.rosti.bsd@gmail.com> In-Reply-To: <20070118134936.GA7391@crodrigues.org> References: <20070118134936.GA7391@crodrigues.org> X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 20:43:54 -0000 On Thu, 18 Jan 2007 08:49:36 -0500 Craig Rodrigues wrote: > Using this patch, I have been able to do: > mount /dev/blah /mnt > > and mount a UFS, cd9660, or FAT filesystem, depending on what filesystem > is on the /dev/blah device. > > Comments? OpenBSD already has such a functionality. It uses readlabelfs(3) for this. What disadvantages or advantages does it have beside your implementation? From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 22:01:46 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09B8616A492; Thu, 18 Jan 2007 22:01:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id A907F13C441; Thu, 18 Jan 2007 22:01:45 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.6) with ESMTP id l0ILwFPe064875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 13:58:17 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <45AFED63.7020009@FreeBSD.org> Date: Thu, 18 Jan 2007 13:57:55 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Matthew Dillon References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <200701181948.l0IJmdfn061671@apollo.backplane.com> In-Reply-To: <200701181948.l0IJmdfn061671@apollo.backplane.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@FreeBSD.org, Ivan Voras , Bruce Evans , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 22:01:46 -0000 Heh, it's so complex, so machine-dependent.... That makes me wonder why we still don't have 3 simple to use instructions that do equivalent of memmove(), memcpy() and memset() all in hardware in the best possible way with the respect of block size, alignment, caches, chipset, you-name-it? Virtually every program would benefit from such instructions. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 22:17:59 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7896816A47E for ; Thu, 18 Jan 2007 22:17:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8AD13C468 for ; Thu, 18 Jan 2007 22:17:59 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l0IMHw6Q026931; Thu, 18 Jan 2007 14:17:58 -0800 (PST) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 8E07330020; Thu, 18 Jan 2007 14:17:58 -0800 (PST) X-AuditID: 11807125-a3250bb000006e4c-93-45aff2160105 Received: from [17.214.13.96] (unknown [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id 798A230002; Thu, 18 Jan 2007 14:17:58 -0800 (PST) In-Reply-To: <45AFED63.7020009@FreeBSD.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <200701181948.l0IJmdfn061671@apollo.backplane.com> <45AFED63.7020009@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25EB3FED-71A9-4AE1-9A38-5D2DC27D0DF7@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 18 Jan 2007 14:17:57 -0800 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 22:17:59 -0000 On Jan 18, 2007, at 1:57 PM, Maxim Sobolev wrote: > Heh, it's so complex, so machine-dependent.... Well, yes. :) > That makes me wonder why we still don't have 3 simple to use > instructions that do equivalent of memmove(), memcpy() and memset() > all in hardware in the best possible way with the respect of block > size, alignment, caches, chipset, you-name-it? Virtually every > program would benefit from such instructions. Unfortunately, there are simply different tradeoffs between mechanisms for copying depending on whether you want to use or avoid using/thrashing the L1/L2 caches, whether the data is cache-aligned, and so forth; the CPU can't infer what you want to occur-- you have to tell it. I find it interesting that some of the architectures (PA- RISC, SPARC) do allow for simple instructions with cache-control hinting: http://gcc.gnu.org/projects/prefetch.html -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 22:28:40 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A17DC16A412; Thu, 18 Jan 2007 22:28:40 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4E84513C455; Thu, 18 Jan 2007 22:28:40 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.6) with ESMTP id l0IMSYJd065671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 14:28:37 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <45AFF47E.3020905@FreeBSD.org> Date: Thu, 18 Jan 2007 14:28:14 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Chuck Swiger References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <200701181948.l0IJmdfn061671@apollo.backplane.com> <45AFED63.7020009@FreeBSD.org> <25EB3FED-71A9-4AE1-9A38-5D2DC27D0DF7@mac.com> In-Reply-To: <25EB3FED-71A9-4AE1-9A38-5D2DC27D0DF7@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 22:28:40 -0000 Chuck Swiger wrote: > Unfortunately, there are simply different tradeoffs between mechanisms > for copying depending on whether you want to use or avoid > using/thrashing the L1/L2 caches, whether the data is cache-aligned, and > so forth; the CPU can't infer what you want to occur-- you have to tell > it. I find it interesting that some of the architectures (PA-RISC, Well, of course there are some special cases, but in general there should be some baseline suitable for most of uses. That's why we (and most other operating systems) only provide single version for the mem*(3) APIs. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Jan 18 22:47:57 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5460616A415; Thu, 18 Jan 2007 22:47:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 30DDA13C44B; Thu, 18 Jan 2007 22:47:57 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l0IMluNl014484; Thu, 18 Jan 2007 14:47:56 -0800 (PST) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 7B0EA29C002; Thu, 18 Jan 2007 14:47:56 -0800 (PST) X-AuditID: 11807123-a3b5bbb0000039f2-94-45aff91c36f4 Received: from [17.214.13.96] (unknown [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 6322730400B; Thu, 18 Jan 2007 14:47:56 -0800 (PST) In-Reply-To: <45AFF47E.3020905@FreeBSD.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <200701181948.l0IJmdfn061671@apollo.backplane.com> <45AFED63.7020009@FreeBSD.org> <25EB3FED-71A9-4AE1-9A38-5D2DC27D0DF7@mac.com> <45AFF47E.3020905@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B6D259B-618B-466C-844E-3F79FDE272BB@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 18 Jan 2007 14:47:55 -0800 To: Maxim Sobolev X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 22:47:57 -0000 On Jan 18, 2007, at 2:28 PM, Maxim Sobolev wrote: >> Unfortunately, there are simply different tradeoffs between >> mechanisms for copying depending on whether you want to use or >> avoid using/thrashing the L1/L2 caches, whether the data is cache- >> aligned, and so forth; the CPU can't infer what you want to >> occur-- you have to tell it. I find it interesting that some of >> the architectures (PA-RISC, > > Well, of course there are some special cases, but in general there > should be some baseline suitable for most of uses. That's why we > (and most other operating systems) only provide single version for > the mem*(3) APIs. Well, a truly generic version in is lib/libc/string/bcopy.c; it's architecture-neutral (ie, it's pure C code) and it handles all kinds of things like overlapping source and destination addresses, non- aligned access, and so forth. The downside is that it's slower than using movl/movsl, much less some of the fancier variants that Bruce and Matt have been discussing (in considerable, interesting detail) earlier: http://now.cs.berkeley.edu/Td/bcopy.html If you're only moving, say, 5 bytes, the overhead of fancy loop unrolling and prefetching and so forth isn't going to help compared with a simple movb/movl combination, so it really depends. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 00:34:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D548916A49E for ; Fri, 19 Jan 2007 00:34:56 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) by mx1.freebsd.org (Postfix) with ESMTP id B100D13C428 for ; Fri, 19 Jan 2007 00:34:56 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [127.0.0.1] (24-38-119-150-st.losaca.adelphia.net [24.38.119.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTP id 528831298C0; Thu, 18 Jan 2007 16:09:12 -0800 (PST) Message-ID: <45B00BF5.6030200@FreeBSD.org> Date: Thu, 18 Jan 2007 16:08:21 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stefan Ehmann References: <200701172045.35137.shoesoft@gmx.net> In-Reply-To: <200701172045.35137.shoesoft@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: very high memory usage in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 00:34:56 -0000 Stefan Ehmann wrote: > [huge jpeg/png images cause memory bloat with konqueror and gtk apps, on -CURRENT.] > > I don't really know what's causing this problem. Maybe it's related to > jemalloc, but I'd be surprised if no one else has noticed this before. > > size/res values reported by top > > 6.2 desktop pc with nvidia binary driver > konqueror 40M/30M > > CURRENT notebook with the i810 driver > konqueror 290M/250M > > Any clues or more information needed? If you think jemalloc is involved, the easiest way to check is by reverting src/lib/libc/stdlib/malloc.c to revision 1.92, which is phkmalloc. If this substantially changes memory usage, then there are further diagnostics that can be used to help understand the issue. ----- If jemalloc is involved, here's what could cause such behavior. First, you would have to be running on a 32-bit platform, so that sbrk() is in use (rather than pure mmap() as for the 64-bit platforms). 1) The application would allocate some large chunks of memory for image processing. These data would be allocated in the data segment. 2) The application would allocate some additional long-lived object for which no existing memory region could be recycled. This would cause the object to be allocated in the data segment, at the end of the sbrk()ed memory. 3) The application would free most/all of the memory that was used for image processing. Unfortunately, due to the long-lived object from step (2), this would be in the middle of the sbrk()ed memory, and so malloc would have to hold onto the memory for possible future use, unable to return it to the kernel. The right solution to the problem is to get rid of the hard line between data segment and heap, and use the address space that is currently reserved for sbrk() as the last resort for mmap() requests, thus allowing the data segment and heap to gracefully grow toward each other until memory is exhausted. We really don't need the data segment anymore except for legacy support of applications that do their own memory management via sbrk(). However, when I talked with the VM wizards, I was sufficiently intimidated by the difficulty of removing the hard-coded data segment size that I did not pursue it any further. Personally, in the absence of a dynamic boundary between the data segment and the heap, I would be quite happy to completely disable sbrk() support in jemalloc, and let those who really need that last 512 MB of address space adjust resource limits for their applications as necessary. In practice, I expect this would cause people far less trouble than does the current state of affairs. Jason From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 02:37:12 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 857E416A415; Fri, 19 Jan 2007 02:37:12 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0CB13C44C; Fri, 19 Jan 2007 02:37:12 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (rwcrmhc12) with ESMTP id <20070119023711m12002l9rce>; Fri, 19 Jan 2007 02:37:11 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l0J2bA2o001761; Thu, 18 Jan 2007 21:37:10 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l0J2b9Hi001760; Thu, 18 Jan 2007 21:37:09 -0500 (EST) (envelope-from rodrigc) Date: Thu, 18 Jan 2007 21:37:09 -0500 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20070119023709.GA1524@crodrigues.org> References: <20070118134936.GA7391@crodrigues.org> <20070118221749.3be589d9.rosti.bsd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070118221749.3be589d9.rosti.bsd@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 02:37:12 -0000 On Thu, Jan 18, 2007 at 10:17:49PM +0200, Rostislav Krasny wrote: > OpenBSD already has such a functionality. It uses readlabelfs(3) for > this. What disadvantages or advantages does it have beside your > implementation? Thanks for the pointer, I did not know about readlabelfs on OpenBSD! From what I understand from reading the code: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/readlabel.c http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/disklabel.h the readlabelfs() function tries to open the device and do a DIOCGDINFO ioctl() on the device to read the disklabel. Once the disklabel is read, (i.e. DIOCDINFO returns a 'struct disklabel'), the p_fstype member of 'struct partition' which is inside the 'struct disklabel' is converted to a string name based on the fstypesnames array in . This approach relies heavily on disklabels, and correct information being stored in disklabels. For FreeBSD, I do not like the idea of introducing a new dependency between mount(8) and BSD disklabels. The existing FreeBSD mount(8) program just tries to open a device, does an nmount() with a "fstype" parameter, and then relies on the underlying file system code (i.e. "ufs", "msdosfs", etc.) to read the superblock from the device, figure out if it can mount it, and return an error if it cannot. That's the behavior I tried to preserve with my patch. It's kind of simplistic, but it does work. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 02:55:23 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E150916A415; Fri, 19 Jan 2007 02:55:23 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [204.127.225.94]) by mx1.freebsd.org (Postfix) with ESMTP id AB68413C441; Fri, 19 Jan 2007 02:55:23 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (alnrmhc14) with ESMTP id <20070119025522b1400rmue9e>; Fri, 19 Jan 2007 02:55:22 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l0J2tLTl001935; Thu, 18 Jan 2007 21:55:21 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l0J2tL3X001934; Thu, 18 Jan 2007 21:55:21 -0500 (EST) (envelope-from rodrigc) Date: Thu, 18 Jan 2007 21:55:20 -0500 From: Craig Rodrigues To: Luigi Rizzo Message-ID: <20070119025520.GA1891@crodrigues.org> References: <20070118134936.GA7391@crodrigues.org> <20070118064912.A39777@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070118064912.A39777@xorpc.icir.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 02:55:24 -0000 On Thu, Jan 18, 2007 at 06:49:12AM -0800, Luigi Rizzo wrote: > great feature. I probably agree that "mount -t auto" might > be a safer way to implement it, but other than that i'd > love to have it too. I understand the motivation for "mount -t auto"....I wanted to get away from hijacking the "-t" parameter with values other than an "fstype". Also, if someone implements the autofs file system again for FreeBSD, there could be confusion. My tack for dealing with POLA was to always start with UFS when iterating through the vfs.conflist sysctl. I thought that having it as the default behavior if "-t" is not specified would be nice, especially for people coming from Linux. When I moved from Linux to FreeBSD, I found it a bit weird that I needed to specify a "-t" parameter to mount my CD-ROM...and figuring out that it was -t cd9660, which is not the same as Linux was odd too. :) -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 03:24:25 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F63216A412; Fri, 19 Jan 2007 03:24:25 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from alnrmhc12.comcast.net (alnrmhc12.comcast.net [206.18.177.52]) by mx1.freebsd.org (Postfix) with ESMTP id 59A7F13C478; Fri, 19 Jan 2007 03:24:25 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from c-66-31-35-94.hsd1.ma.comcast.net ([66.31.35.94]) by comcast.net (alnrmhc12) with ESMTP id <20070119032423b1200jtatde>; Fri, 19 Jan 2007 03:24:24 +0000 Received: from c-66-31-35-94.hsd1.ma.comcast.net (localhost.crodrigues.org [127.0.0.1]) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8) with ESMTP id l0J3OMMr002121; Thu, 18 Jan 2007 22:24:22 -0500 (EST) (envelope-from rodrigc@c-66-31-35-94.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-31-35-94.hsd1.ma.comcast.net (8.13.8/8.13.8/Submit) id l0J3OMQE002120; Thu, 18 Jan 2007 22:24:22 -0500 (EST) (envelope-from rodrigc) Date: Thu, 18 Jan 2007 22:24:22 -0500 From: Craig Rodrigues To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20070119032422.GB1891@crodrigues.org> References: <20070118134936.GA7391@crodrigues.org> <86lkk02wp7.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lkk02wp7.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 03:24:25 -0000 On Thu, Jan 18, 2007 at 04:15:00PM +0100, Dag-Erling Smrgrav wrote: > Didn't somebody mention ordering issues back then? Your revised patch > still doesn't even try to address those. If we ever get ext3 support, > for instance, mounting an ext2 file system as ext3 might cause it to > be silently upgraded to ext3. Since FreeBSD doesn't have any ext3 support right now, I think a more concrete example of ordering issues is to look at cd9660 vs. udf, which FreeBSD currently supports. In my patch, the mount_fs_try() function does deal with one ordering issue.....no matter what is in the vfs.conflist sysctl, it always tries to mount "ufs" first. This approximates the existing mount(8) behavior. It would not be hard to modify mount_fs_try() to deal with ordering of ext3 vs. ext2, udf vs. cd9660, or whatever. Not the most elegant solution, but workable for the limited subset of file systems that FreeBSD supports. > Not to mention the slew of error messages this will result in as you > walk the list of filesystems trying to find the right one... This is true, but in my tests, the "slew of error messages" is not too bad. Also, with my patch, if you specify the "-t" parameter, mount_fs_try() is not used, so things like mounting via /etc/fstab, where the fstype is specified, will behave the same way as now, and not iterate through a list of file systems. > A better way would be to have a userland utility attempt to identify > the file system, and if necessary load the appropriate module, before > mounting it. I disagree. To go down this road, instead of a separate utility, I think the best approach would be to put all this logic inside mount(8), the way Linux does, as Christoph Hellwig mentioned here: http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005447.html I've looked at the Linux mount utility source.....it maintains a table of magic numbers and offsets and tries them in a well defined order. The logic is quite involved, but it does work. The Linux code is under GPL though.... The other suggestion that someone had was to use libmagic in mount(8). libmagic is good, but using it in mount(8) would introduce link dependencies on libmagic and libz, and also introduce dependencies on files in /usr/share/misc/magic. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 03:28:19 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14B5316A40F for ; Fri, 19 Jan 2007 03:28:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0230F13C442 for ; Fri, 19 Jan 2007 03:28:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D4DC31A4D9F; Thu, 18 Jan 2007 19:28:18 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 08407514B7; Thu, 18 Jan 2007 22:28:14 -0500 (EST) Date: Thu, 18 Jan 2007 22:28:14 -0500 From: Kris Kennaway To: "W. Josephson" Message-ID: <20070119032814.GA83278@xor.obsecurity.org> References: <20070119025156.GB77180@mero.morphisms.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20070119025156.GB77180@mero.morphisms.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: building a new fileserver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 03:28:19 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 18, 2007 at 09:51:56PM -0500, W. Josephson wrote: > I'd like to solicit people's opinions about configuring > CURRENT for a new fileserver that we'll be using internally. > I have only recently had hardware available for running anything > other than 6-STABLE so: >=20 > 1. We'd like to use the 16-port 3Ware 9650SE-16. > Does anyone here have experience with this card in > RAID-6 mode under FreeBSD? >=20 > 2. Any one have advice for setting up UFS+gjournal? > I've been using FFS+SU for some time on a number of machines > with filesystems up to about 1TB, but I'm not looking forward > to fsck, even background fsck, on multiple 10TB filesystems. > Does anyone here have experience with UFS+gjournal on large > filesystems? Are there any gotchas to be aware of when > configuring? Can someone describe briefly what guarantees > UFS+gjournal makes? One gotcha with gjournal is that there is apparently still at least one pretty obscure data corruption bug lurking. I see this when doing concurrent package builds on a 12 cpu system with a single gjournal data store, although I haven't run this configuration for a few months. Kris --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFsDrOWry0BWjoQKURAjFoAKD6Zbebie5LcVL2hhyzi6SIuxS2uwCfTl/Z qNX7C7RbTS8VojfCR6+1lQ0= =za7I -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 05:48:38 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1398416A415; Fri, 19 Jan 2007 05:48:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C05C213C457; Fri, 19 Jan 2007 05:48:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l0J5jnQ2004773; Thu, 18 Jan 2007 22:45:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 18 Jan 2007 22:46:09 -0700 (MST) Message-Id: <20070118.224609.709403207.imp@bsdimp.com> To: rodrigc@crodrigues.org From: "M. Warner Losh" In-Reply-To: <20070119023709.GA1524@crodrigues.org> References: <20070118134936.GA7391@crodrigues.org> <20070118221749.3be589d9.rosti.bsd@gmail.com> <20070119023709.GA1524@crodrigues.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 18 Jan 2007 22:45:50 -0700 (MST) Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount(8) can figure out fstype X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 05:48:38 -0000 In message: <20070119023709.GA1524@crodrigues.org> Craig Rodrigues writes: : This approach relies heavily on disklabels, and correct information : being stored in disklabels. : : For FreeBSD, I do not like the idea of introducing a new dependency : between mount(8) and BSD disklabels. It's worse than you might think. On OpenBSD, the line between partition and slice that we have in FreeBSD doesn't exist. Everything is a partition, and they create the necessary labeling when the label is read. Since FreeBSD lacks that feature, for the most part, you are going to have to implement some kind of 'file'-like magic number recognition for filesystems if you want to use a similar approach. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 06:02:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3385816A412; Fri, 19 Jan 2007 06:02:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id A996D13C428; Fri, 19 Jan 2007 06:02:01 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l0IIkpr9003184; Fri, 19 Jan 2007 05:46:51 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l0IIkojM003183; Fri, 19 Jan 2007 05:46:50 +1100 (EST) (envelope-from peter) Date: Fri, 19 Jan 2007 05:46:50 +1100 From: Peter Jeremy To: Bruce Evans Message-ID: <20070118184650.GB845@turion.vk2pj.dyndns.org> References: <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <20070118113831.A11834@delplex.bde.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Ivan Voras , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 06:02:02 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2007-Jan-18 18:03:20 +1100, Bruce Evans wrote: >On Wed, 17 Jan 2007, Matthew Dillon wrote: >> Alignment is critical. If the data is not aligned, don't bother. 1= 28 >> bits means 16 byte alignment. > >The above benchmark output is for aligned data :-). I don't try hard to >optimize or benchmark misaligned cases. How realistic is this? Has anyone collected statistics on the size and alignment of bzero/bcopy calls? How much of the time is the size known at compile time? --=20 Peter Jeremy --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFr8Ca/opHv/APuIcRAqZsAJsHlCSLkdmwl1x/AD/7FV3TJ+K7pgCghDLv lEQ/MSu+HFYDfsQNmk9KIYg= =mPQs -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 05:59:53 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89BA516A4D2; Fri, 19 Jan 2007 05:59:53 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id BD13C13C469; Fri, 19 Jan 2007 05:59:52 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 42E2811108E; Fri, 19 Jan 2007 16:59:49 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 91A388C18; Fri, 19 Jan 2007 16:59:47 +1100 (EST) Date: Fri, 19 Jan 2007 16:59:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Matthew Dillon In-Reply-To: <200701181948.l0IJmdfn061671@apollo.backplane.com> Message-ID: <20070119165802.Q1583@besplex.bde.org> References: <3bbf2fe10607250813w8ff9e34pc505bf290e71758@mail.gmail.com> <3bbf2fe10607281004o6727e976h19ee7e054876f914@mail.gmail.com> <3bbf2fe10701160851r79b04464m2cbdbb7f644b22b6@mail.gmail.com> <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <200701181948.l0IJmdfn061671@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 19 Jan 2007 12:26:41 +0000 Cc: Attilio Rao , Maxim Sobolev , freebsd-current@FreeBSD.org, Ivan Voras , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 05:59:53 -0000 I'll try to keep this shorter :-). On Thu, 18 Jan 2007, Matthew Dillon wrote: > > :Fully cached case: > :% copy0: 16907105855 B/s ( 242265 us) (movsq) > :% ... > :% copyQ: 13658478027 B/s ( 299887 us) (movdqa) > :% ... > :% copyT: 16456408196 B/s ( 248900 us) (movq (i)) > : > :This doesn't contradict your claim since main memory is not really involved. > :Everything should be limited by instruction and cache bandwidth, but for > :some reason movdqa is quite slow despite or because of my attempts to > :schedule it perfectly. > > Well, that's one of the problems. Actually two of the problems. > First, prefetching tends to add more confusion then it solves when > used in a copy loop, because for all intents and purposes you are > already keeping the memory pipeline full simply by the fact that > the writes are buffered. The above is for the non-prefetched case (except for the target of nontemporal writes). Handling and interpreting prefetching is certainly confusing in other cases. I'd better describe what my benchmark does in a bit more detail: to get reasonably accuracy, it is necessary to iterate many times, but that gives the same not-very-real-world cache state for all iterations except the first. I just run it with different block sizes. 4K gives the "fully (L1) cached case", somewhere between 40K and 400K gives the "fully (L2) cached case", and 4M-200M gives the "fully uncached case". I don't test lower levels except by accidentally starting swapping. There is an option to pre-cache the target before starting the iterations. This can only make a difference if the block size is small enough for the target to remain cached (or there number of iterations is too small), and the copying used nontemporal stores so that the copying itself doesn't pre-cache the target. I didn't use this option in the benchmark results quoted in this thread. > By the time the loop gets back around to > the read it has to stall anyway because the writes are still being > pushed out to memory (read-before-write ordering doesn't help because > all that accomplishes is to force the write buffer to stay perpetually > full (possibly in a non-optimal fashion), and the cpu stalls anyway. I had mostly forgotten about read/write ordering. It is going to limit execution reordering in a MD way. I only have good/handy documentation of it for A64. On A64, write ordering is fairly strict, but almost any order is possible for a combination of reads and writes provided the writes can be held in the write buffer and the reads and writes are to different locations. Read ordering is fairly non-strict. Reads can be reordered ahead of writes. This doesn't quite agree with what you said. It allows enough reordering to prevent stalls provided the CPU is clever enough and the copy is not overlapped. The CPU can take almost any ordering of sequential reads and writes and turn it into: setup for (;;) { read next cache line write previous cache line from write buffer (write buffer size must be >= cache line size) } I don't know which CPUs are clever enough to do this or exactly which static instruction order makes it easiest for them, but have noticed reasonable orders which give mysterious slowdowns that are probably related to this. > I've tried every combination of prefetching and non-temporal > instructions imagineable and it has reduced performance more often > then it has improved it. I can write an optimal copy loop for > particular situations but the problem is that the same loop becomes > extremely inefficient under any *OTHER* conditions. Same here, except I wouldn't call most of the non-optimal cases _extremely_ inefficient. Do you have real-world tests? > The behavior of any given copy algorithm is radically different > if either the source or target are present in the L1 or L2 caches, > verses if they aren't. The algorithm one uses to do tiny mostly > in-cache copies is totally different from the algorithm one uses > to do large bulk copies. The algorithm one uses where the > source data is partially or fully cached is totally different from the > one used if the target data is partially or fully cached, or if neither > is cached, or if both are cached. And it's hard to know whether/where the data is cached. The only simplification is that if an FPU switch is required, then very small copy sizes need not be considered. > :Fully uncached case: > :% copy0: 829571300 B/s ( 493749 us) (movsq) > :% ... > :% copyQ: 835822845 B/s ( 490056 us) (movdqa) > : ... > :% copyW: 1350397932 B/s ( 303318 us) (movnti) > : ... > :Now movdqa beats movsq by a bit, at least with prefetch, but has the > :same speed as integer moves of half the size (or MMX moves of half the > :size (benchmark data not shown)). It is necessary to use movnt to get > :anywhere near memory bandwidth, and any form of movnt can be used for > : ... > > But you can't safely use *ANY* non-temporal instruction unless you > know, specifically, that the data is uncached. If you use a non-temporal I think you mean "optimally", not "safely". sfence is supposed to give coherent data. > instruction in a situation where the data is cached or can be easily > cached, you destroy the performance for that case by causing the cpu > not to cache data that it really should cache. Use of non-temporal > instructions results in a non-self-healing algorithm... it is possible > to get into a situation the is permanently non-optimal. That's why > I don't use those instructions. Not caching the target is part of the point of using movnt. It can win not only in copy speed but also by not thrashing useful things out of the cache. Unfortunately we don't really know when this happens (except for idle pagezero). You may be right that it happens so rarely that never doing it is best. > Sometimes I wish the non-temporal instructions had a random component. > That is, that they randomly operates as normal moves instead of nt > moves for a small percentage of executions (~1-25%) in order to create > a self-healing (performance wise) algorithm. Wouldn't normal (non-copy) accesses cache the data reasonably if it is actually used? Multiple copying of the same data doesn't seem to be an important case. I just remembered on case where nontemporal should win: for writes of data that will be DMAed to disks but not read soon by anything except the DMA. Even if disk drivers read it, the disk writes should be delayed by a few seconds on average so the data wouldn't remain in caches except on idle systems. > Use of non-temporal instructions for non performance-critical operations > is a clear win when executed from the idle loop, I agree. Use of NT > instructions in any other case is difficult because it is virtually > impossible to predict the conditions under which other cases occur. Do you use it for copying pages? > :Which modern CPUs can't keep up with L2? > > The instruction pipeline is the problem, not the L2 cache bandwidth. > Things get a bit weird when every single instruction is reading or > writing memory. I try to design algorithms that work reasonably well > across a large swath of cpus. It turns out that algorithms which do > block loads followed by block stores tend to maintain consistent and > good performance across a large swath of cpus. I outline the reasons > why later on. I think it's not mainly the instruction pipeline throughput (except on very old CPUs), but latency issues caused by interactions with the memory accesses. > :On amd64 for the fully-L2-cached case: > :% ... > :% copyQ: 4369052686 B/s ( 937503 us) (movdqa) > :% copyR: 2785886655 B/s (1470268 us) (movdqa with prefetchnta) > :% copyS: 4553271385 B/s ( 899573 us) (movdqa with block prefetch) > :% ... > : > :So here is a case where prefetchnta is bad. OTOH, movnti is quite fast > :provided prefetchnta is not used with it. movnti is even more competitive > :with L2 if main memory is DDR-2. > > It also depends *WHERE* in the loop you put the prefetchnta. I was > able to get fairly close to block prefetching speeds using > prefetchnta by carefully locating the instruction and adjusting > the read-ahead point. For example, by locating the instruction > before the write side and indexing the prefetched memory address > 128 bytes ahead of the curve. The placement of the instruction is > sensitive down to the instruction slot... moving it one forward or > one back can result in crazy differences in performance (due to > forced RAS cycles I believe, in particular with prefetchnta). I've only tried that for block prefetch. It was too MD to maintain. I hoped prefetchnta was easier to use. I tried several things, and just noticed that I missed a point in the AMD docs -- block prefetch should be in reverse order to confuse the hardware into not competing with the explicit prefetch. > :Load/store-unit: > : > : (lots of good information about load-store units) > > Well, but these are for very specific flavor-of-the-day hardware tweaks. > The designers change these parameters literally every other month. > > All that can really be said here is: Avoid 32 bit accesses if you can, > 64 bit accesses seem to be the most dependable, and 128 bit accesses > are the up-and-coming thing. I think the using the FPU and 128-bit accesses are also flavor-of-the-day (yesterday for the FPU). Let the cache and write buffer handle combining of accesses. > In particular I remember reading that AMD had been spending a lot > of time optimizing XMM register loads and stores. I presume that > Intel is doing the same thing since both are going face forward > into gaming. Bah, I wish the would spend more time optimizing important things like FPU latency and wider integer registers :-). > :The asymmetric load/store capabilities on the AXP can't be good for using > :128-bit XMM registers, especially using 8 loads followed by 8 stores in > :the instruction stream. They make 128 stores want to take twice as long > ... > > The advantages of doing N loads followed by N stores (where N >= 4 > and operates on 64 or 128 bit entities) are as follows: > > * There is no instruction or register reordering (or very little) > because the data loaded by any given instruction is not used until > e.g. 8 instructions later. But I think I want to maximize reordering possibilities. > * The write buffer is ordered (either through to the L2 cache or to > main memory, it doesn't matter). This enforces a degree of > resynchronization of the instruction stream. That is, it creates > a self-healing situation that makes it possible to write code > that works very well under all sorts of conditions. Ordered relative to reads? BTW, do you order the instruction stream so that the reader is 1 cache line ahead of the writer? I only do this for old methods optimized for P1's. It saves about 1 read access time per loop unless this time can be hidden by reordering or loop overhead. The cache line size is MD so it is better for this to happen automatically, but perhaps less confusing to program it explicitly for a preferred CPU. > * The read instructions should theoretically tend not to be reordered > simply because the memory pipeline imposes a stall due to handling > previously buffered writes and because of the burst nature of linear > reads from main memory. Even if the cpu DID reorder the reads, > ... > * I don't think the cpu could reorder reads or reorder reads and writes > under these conditions even if it wanted to, and we don't want it > to. > > * Write combining is overrated. It serves an important purpose, but > it is a bad idea to actually depend on it unless your algorithm > is self-healing from the point of view of resynchronizing the > pipeline and/or memory read and write ordering. Instruction Er, don't you depend on it even with 128-bit registers? 16 bytes isn't very large. Even an AthlonXP has a 64-byte write buffer to combine 4 of these. > ... > -- > > It should be possible to use MMX/XMM registers in the kernel simply as > call-saved registers by issuing a FWAIT or equivalent at the user-kernel > boundary to take care of any exceptions (instead of saving the state > and calling clts ; fnclex). Presumably by the time the cpu actually > gets the integer and cpu state context pushed any FP operations will > have long sinced completed. But I haven't timed it to find out whether > that actually works. I thought about making some XMM registers call-used (switched on every boundary crossing). Copying only needs 1 and switching just 1 doesn't have much overhead. Call-saved has different tradeoffs. Both mehods should drop the semi-lazy FPU context switching and do a full switch at context switch time so that DNA traps never occur and the FPU/XMM can just be used. This also hopefully doesn't have much additional overhead, since the FPU instructions run in an otherwise-idle pipeline and the extra memory traffic is either small enough of can be scheduled better. MMX would have complications for the tag word. I think new code shouldn't support MMX. The fnclex is unnecessary (see below). I don't quite understand what your fwait does or how call-saved XMM context switching could work well for preemptible kernels. Doesn't it give all the old problems with the state saved where the general context switcher can't see it? Call-used XMM context switching works using normal stack discipline. > The nice thing about most MMX/XMM media instructions is that they don't > actually care about what state the FP unit is in because they aren't > actually doing any FP math. It is just a matter of synchronizing the > free FP registers from some prior user FP operation which may not have > posted results yet. XMM doesn't even need the synchronization. It runs independently of the i387 state, and if it is not used for FP math then it also runs independently of mxcsr. Thus fnclex and fwait have no effect on it, but if it is used for FP math then something would have to be done to ignore (user) exceptions and mode bits in mxcsr. > If this IS possible then it removes most of the NPXTHREAD junk from the > kernel bcopy path for the case where NPXTHREAD != NULL, giving you the > ability to use the FP optimally whether NPXTHREAD == NULL or > NPXTHREAD != NULL. And, in such a case, it might be more beneficial > for small copies to only save two or four XMM registers instead of > all eight. > > What do you think? One XMM register is enough for even large copies :-). Sorry, didn't succeed in keeping this shorter. Bruce From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 07:14:26 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D1A116A60D; Fri, 19 Jan 2007 07:14:26 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 36A8713C45E; Fri, 19 Jan 2007 07:14:26 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 1709F5A7CAA; Fri, 19 Jan 2007 18:14:24 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 3DF8227423; Fri, 19 Jan 2007 18:14:22 +1100 (EST) Date: Fri, 19 Jan 2007 18:14:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Jeremy In-Reply-To: <20070118184650.GB845@turion.vk2pj.dyndns.org> Message-ID: <20070119172335.O2216@besplex.bde.org> References: <20070116154258.568e1aaf@pleiades.nextvenue.com> <3bbf2fe10701161525j6ad9292y93502b8df0f67aa9@mail.gmail.com> <45AD6DFA.6030808@FreeBSD.org> <3bbf2fe10701161655p5e686b52n7340b3100ecfab93@mail.gmail.com> <200701172022.l0HKMYV8053837@apollo.backplane.com> <20070118113831.A11834@delplex.bde.org> <20070118184650.GB845@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 19 Jan 2007 12:26:56 +0000 Cc: Ivan Voras , Attilio Rao , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 07:14:26 -0000 On Fri, 19 Jan 2007, Peter Jeremy wrote: > On Thu, 2007-Jan-18 18:03:20 +1100, Bruce Evans wrote: >> On Wed, 17 Jan 2007, Matthew Dillon wrote: >>> Alignment is critical. If the data is not aligned, don't bother. 128 >>> bits means 16 byte alignment. >> >> The above benchmark output is for aligned data :-). I don't try hard to >> optimize or benchmark misaligned cases. > > How realistic is this? Has anyone collected statistics on the size and > alignment of bzero/bcopy calls? How much of the time is the size known > at compile time? I think perfect alignment is very realistic. If not, it is an application bug :), just like for misaligned integer accesses on arches that allow this. In the kernel, other parts of the kernel are the application and it is reasonable to require perfect alignment. I recently did a dynamic search for misaligned (but only 32-bit non-aligned) bxx's (maybe only bzeros) in low-level network code and found only a couple. For the original i586 FPU optimizations, I gatherer statistics for bcopy/bzero. IIRC, alignment (64-bit?) was normal, at least for the large copies of interest, and large bcopys were so uncommon that it was a complete waste of time to optimize them (at least for my applications). Large bzeros/copyins/copyouts are more common. FreeBSD has some optimizations in low-level networking code for bcopys with a small size that is known at compile time (just use gcc's builtin_memcpy). These were lost to -ffreestanding and/or gcc's aggressive optimization of things like printf using the builtin printf. (-ffreestanding implies -fno-builtin, and no one cared enough about the loss to turn builtins back on. If you turn them back on, then they should be turned on individually as recommended in gcc.info to avoid conflicts. This is easy enough for the memcpy builtin but messy if you want all the old builtins starting with strlen.) I looked at these lost optimizations again while trying to optimize the low- level networking code for packets-per-second. The difficulty of implementing memcpy/bcopy perfectly is shown by gcc's builtin not being very close to getting it right for small fixed sizes even with -march=... I lost interest in this for now when I found that optimizations were impossible to measure because the packet rate depends mysteriously on the layout of the text section. My changes may have given +10%, but unrelated changes gave +-30%. The most mysterious one was -20% when cvs updated added ~500 bytes of object code that is never executed. Using builtin memcpy didn't have a noticeable effect here. Bruce From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 13:45:31 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B559D16A404 for ; Fri, 19 Jan 2007 13:45:31 +0000 (UTC) (envelope-from mb@imp.ch) Received: from mx2.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2663213C44B for ; Fri, 19 Jan 2007 13:45:30 +0000 (UTC) (envelope-from mb@imp.ch) Received: from dan.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l0JDJPNm021304; Fri, 19 Jan 2007 14:19:26 +0100 (CET) (envelope-from mb@imp.ch) Date: Fri, 19 Jan 2007 14:19:25 +0100 (CET) From: Martin Blapp To: freebsd-current@freebsd.org Message-ID: <20070119125246.P821@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Patrick Guelat Subject: IBM system X-3250 always hangs after/before reboot/power off X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 13:45:31 -0000 Hi all, We are experiencing a freezing system calling reboot(8) or shutdown(8) -r, shutdown(8) -p. I can also do a CTRL ALT DELETE. After syncing disks the system stops responding. From time to time there is still some hd activity, but maybe that's the controller itself. Something like: Syncing disks, syncing disks, buffers remaining 2 1 1 0 Uptime: 10m10s -> FREEZE <-- Any ideas ? The problem happens with 6.2-RELEASE. I see some unhandled mpt events during the boot phase. Maybe it's mpt0 which blocks or locks up the system after each boot ? A very strange issue is, that if I press the power-off button after such a lookup, I don't have any graphic output after the reboot, after a poweron on the same button until I plug the power out and turn it on again. Something is fundamentally broken here. But why does linux work here ? Martin Some facts: - Linux 2.4 or Linux 2.6 works perfectly, an acpi reboot works fine there. - The server is brand new. And no - there is no new bios upgrade available, we already checked that. - It happens with or without acpi - Disable or enable acpi in the loader doesn't help. It looks like the freeze happens before acpi can do anything. Even if ACPI_DEBUG is set, but doesn't help anything here. hw.acpi.handle_reboot=1 has no effect. After syncing disks we don't see any acpi messages. I don't see any output after syncing disk, even if hw.acpi.handle_reboot=1 is set. - hw.acpi.disable_on_reboot hasn't any effect too ... - The box has one dual core processor. It doesn't change anything if the GENERIC kernel is booted or the SMP kernel is used. Here's the full dmesg: CPU: Intel(R) Xeon(R) CPU 3060 @ 2.40GHz (2400.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd,CX16,,> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146238464 (2046 MB) avail memory = 2095136768 (1998 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci8: on pcib1 pcib2: irq 16 at device 3.0 on pci0 pci6: on pcib2 pcib3: irq 17 at device 28.0 on pci0 pci5: on pcib3 mpt0: port 0x4000-0x40ff mem 0xd8010000-0xd8013fff,0xd8000000-0xd8 00ffff irq 16 at device 0.0 on pci5 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.5.13.0 mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0xb mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required). pcib4: irq 17 at device 28.4 on pci0 pci1: on pcib4 bge0: mem 0xd8300000-0xd830ffff irq 16 at device 0.0 o n pci1 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:14:5e:6b:14:8b pcib5: irq 16 at device 28.5 on pci0 pci3: on pcib5 bge1: mem 0xd8400000-0xd840ffff irq 17 at device 0.0 o n pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:14:5e:6b:14:8c uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8600000-0xd86003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci10: on pcib6 pci10: at device 4.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30a f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xe0000-0xe17ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: P.I. Engineering PC Keyboard/Mouse to USB Adapter, rev 1.10/3.11, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: P.I. Engineering PC Keyboard/Mouse to USB Adapter, rev 1.10/3.11, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. Timecounters tick every 1.000 msec acd0: CDRW at ata0-master UDMA33 ses0 at mpt0 bus 0 target 4 lun 0 ses0: Fixed Enclosure Services SCSI-3 device ses0: 300.000MB/s transfers ses0: SCSI-3 SES Device da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers, Tagged Queueing Enabled da0: 237464MB (486326272 512 byte sectors: 255H 63S/T 30272C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 14:04:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EA4F16A400 for ; Fri, 19 Jan 2007 14:04:21 +0000 (UTC) (envelope-from n.marjoram@adastral.ucl.ac.uk) Received: from vscano-c.ucl.ac.uk (vscano-c.ucl.ac.uk [144.82.100.156]) by mx1.freebsd.org (Postfix) with ESMTP id 0076313C448 for ; Fri, 19 Jan 2007 14:04:20 +0000 (UTC) (envelope-from n.marjoram@adastral.ucl.ac.uk) Received: from lowestoft.adastral.ucl.ac.uk ([128.40.159.4]) by vscano-c.ucl.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1H7u20-0000In-0P for freebsd-current@freebsd.org; Fri, 19 Jan 2007 13:43:48 +0000 Received: from [128.40.159.50] (gromit.adastral.ucl.ac.uk [128.40.159.50]) (authenticated bits=0) by lowestoft.adastral.ucl.ac.uk (8.13.1/8.13.1) with ESMTP id l0JDhhRU004730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jan 2007 13:43:44 GMT Message-ID: <45B0CB0F.8020201@adastral.ucl.ac.uk> Date: Fri, 19 Jan 2007 13:43:43 +0000 From: Neil Marjoram User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UCL-Adastral-Park-MailScanner-Information: Please contact mailhelp@adastral.ucl.ac.uk for more information X-UCL-Adastral-Park-MailScanner: Found to be clean X-UCL-Adastral-Park-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-UCL-Adastral-Park-MailScanner-From: n.marjoram@adastral.ucl.ac.uk X-UCL-MailScanner-Information: Please contact the UCL Helpdesk, helpdesk@ucl.ac.uk for more information X-UCL-MailScanner: Found to be clean X-UCL-MailScanner-From: n.marjoram@adastral.ucl.ac.uk X-Spam-Status: No Subject: New to FreeBSD - Suspend / Resume problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 14:04:21 -0000 This is the first serious FreeBSD install I have done on a laptop, and I have run into an issue with suspend resume. I have an IBM Thinkpad X31 on which I have loaded 6.1. Most things work very well except suspend and resume. I have played with several options and have working acpiconf -s S3, which starts up again on lid open or button press. I have had to add in a few thing to /etc/rc.resume and /etc/rc.suspend for mouse and wireless. I have read several accounts of 6.1 running out of the box, but this does not seem to be the case. What I don't seem to be able to get running is the [FN][F4] sleep button, it sleeps fine, but does not execute the /etc/rc.suspend and resume scripts. Lastly I would like to activate suspend to disk [FN][F12] but this does not seem to function at all and I cannot find any notes on how to get this working. Is it possible to define the action of these buttons? I tried sysctl dev.acpi_ibm.0.events=1, and it seems all the fuctions return codes. Can anyone help? Do I need the acpi_tpkey? If so how do I load it. Customisations : /boot/loader.conf snd_ich_load=yes acpi_ibm_load=yes if_ipw_load=yes /etc/sysctl.conf debuf.acpi.do_powerstate=1 hw.acpi.lid_switch_state=S0 hw.acpi.standby_state=S0 hw.acpi.suspend_state=S3 hw.acpi-sleep_button_state=S3 vfs.usermount=1 hw.acpi.sleep_delay=3 |$ sysctl -a | grep sleep hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.sleep_button_state: S1 hw.acpi.sleep_delay: 3 Many thanks, Neil. | -- Neil Marjoram Systems Manager Adastral Park Campus University College London Ross Building Adastral Park Martlesham Heath Ipswich - Suffolk IP5 3RE Tel: 01473 663711 Fax: 01473 635199 Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 15:31:30 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E69716A401 for ; Fri, 19 Jan 2007 15:31:30 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 2872213C468 for ; Fri, 19 Jan 2007 15:31:28 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 19 Jan 2007 15:31:27 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.95.52] by mail.gmx.net (mp044) with SMTP; 19 Jan 2007 16:31:27 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Fri, 19 Jan 2007 16:31:26 +0100 User-Agent: KMail/1.9.5 References: <200701172045.35137.shoesoft@gmx.net> <45B00BF5.6030200@FreeBSD.org> In-Reply-To: <45B00BF5.6030200@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701191631.27034.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Jason Evans Subject: Re: very high memory usage in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 15:31:30 -0000 On Friday 19 January 2007 01:08, Jason Evans wrote: > Stefan Ehmann wrote: > > [huge jpeg/png images cause memory bloat with konqueror and gtk apps, on > > -CURRENT.] > > > > I don't really know what's causing this problem. Maybe it's related to > > jemalloc, but I'd be surprised if no one else has noticed this before. > > If you think jemalloc is involved, the easiest way to check is by > reverting src/lib/libc/stdlib/malloc.c to revision 1.92, which is > phkmalloc. If this substantially changes memory usage, then there are > further diagnostics that can be used to help understand the issue. When reverting to r1.92 konqueror memory usage goes back to normal values (i.e. as on 6.2-Release) > If jemalloc is involved, here's what could cause such behavior. First, > you would have to be running on a 32-bit platform, so that sbrk() is in > use (rather than pure mmap() as for the 64-bit platforms). Yes, I'm on i386. Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 15:31:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81F3D16A412 for ; Fri, 19 Jan 2007 15:31:37 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 43F1413C44B for ; Fri, 19 Jan 2007 15:31:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7viC-0001uy-NK for freebsd-current@freebsd.org; Fri, 19 Jan 2007 16:31:29 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 16:31:28 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 16:31:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Fri, 19 Jan 2007 07:31:12 -0800 Lines: 36 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.4 Sender: news Subject: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 15:31:37 -0000 I upgraded a box to -current yesterday with the following pci card in it, (this is the msi disabled verbose boot below) but upon bootup, any heavy network activity caused watchdog timeouts and resets. Disabling msi via the two tunables fixed the problem. What info do you need on this problem? found-> vendor=0x8086, dev=0x1076, revid=0x00 bus=4, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good map[18]: type 4, range 32, base 0xdcc0, size 6, enabled pcib4: requested I/O range 0xdcc0-0xdcff: in range pcib4: matched entry for 4.2.INTA pcib4: slot 2 INTA hardwired to IRQ 18 em0: port 0xdcc0-0xdcff m em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device 2.0 on pci4 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 em0: bpf attached em0: Ethernet address: 00:0e:0c:6e:a1:39 em0: [FAST] -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 17:08:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F74A16A400 for ; Fri, 19 Jan 2007 17:08:44 +0000 (UTC) (envelope-from kyrosthebravekingofpersia@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id C7B3613C45B for ; Fri, 19 Jan 2007 17:08:43 +0000 (UTC) (envelope-from kyrosthebravekingofpersia@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so269900ana for ; Fri, 19 Jan 2007 09:08:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fViRqULGKB0P13D1rSjRuzxXa7Xo89ZTLdKT3to3DedNQpMIQT0ucVTwNEObRDFa/kbGMfikedFBy3An5jirbZKeC9I/zEdQLLL2CwPMiMdPGztOLWA91I7BGLHi+YfLB59Brn5O3Xg6ip+QyLAaN8QM4RCxOtHS0Vcf/LzYwLw= Received: by 10.65.251.1 with SMTP id d1mr3236590qbs.1169224829730; Fri, 19 Jan 2007 08:40:29 -0800 (PST) Received: by 10.65.157.15 with HTTP; Fri, 19 Jan 2007 08:40:29 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 17:40:29 +0100 From: "Bartek Dedersen" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Updating the ports from STABLE to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 17:08:44 -0000 Hi. I thought of trying out the bleeding edge and hoped my knowledge of BSD is high enough to handle it without any major problems. But: I installed FreeBSD-6.1 with the provided ISO package available on freebsd.org. Some packages were installed via pkg_add. After one week, the technician of the German telecommunication firm managed to visit me and put his finger on the cables in the cellar. Well, I thought of upgrading some packages with the ports-subsystem. It was pretty easy and nice. But then I wanted more and installed CURRENT from the CVS-source. Some buildworlds and kernel configuration later, I had a 7.0 Current. Ok, after a startx I got some error that libXmmu cannot be found. Ok, so I tried to recompile xorg-libraries. Ok, but there were lots of broken packages due to a filesystem breakdown after a kernel panic. Well, I tried to delete it with pkg_delete -f and it worked. Now, I am recompiling it from the updated ports-collection. Do I have to expect more failures and do I see an upcoming recompiling week due to broken libraries which do not work on CURRENT? Is it more useful to reinstall BSD from scratch and update it first? I know, CURRENT is not for productive use but I need something to put my fingers on. Maybe I will learn. Is there a command to recompile, deinstall and reinstall every installed package from the ports-system? If not, it will be hell. Bartek From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 17:22:41 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4845816A401 for ; Fri, 19 Jan 2007 17:22:41 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id CA9E413C441 for ; Fri, 19 Jan 2007 17:22:40 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l0JHMYVH076881; Fri, 19 Jan 2007 11:22:34 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <45B0FE5E.7090201@centtech.com> Date: Fri, 19 Jan 2007 11:22:38 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: Kris Kennaway References: <20070119025156.GB77180@mero.morphisms.net> <20070119032814.GA83278@xor.obsecurity.org> In-Reply-To: <20070119032814.GA83278@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2466/Thu Jan 18 17:49:11 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: "W. Josephson" , freebsd-current@freebsd.org Subject: Re: building a new fileserver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 17:22:41 -0000 On 01/18/07 21:28, Kris Kennaway wrote: > On Thu, Jan 18, 2007 at 09:51:56PM -0500, W. Josephson wrote: >> I'd like to solicit people's opinions about configuring >> CURRENT for a new fileserver that we'll be using internally. >> I have only recently had hardware available for running anything >> other than 6-STABLE so: >> >> 1. We'd like to use the 16-port 3Ware 9650SE-16. >> Does anyone here have experience with this card in >> RAID-6 mode under FreeBSD? >> >> 2. Any one have advice for setting up UFS+gjournal? >> I've been using FFS+SU for some time on a number of machines >> with filesystems up to about 1TB, but I'm not looking forward >> to fsck, even background fsck, on multiple 10TB filesystems. >> Does anyone here have experience with UFS+gjournal on large >> filesystems? Are there any gotchas to be aware of when >> configuring? Can someone describe briefly what guarantees >> UFS+gjournal makes? > > One gotcha with gjournal is that there is apparently still at least > one pretty obscure data corruption bug lurking. I see this when doing > concurrent package builds on a 12 cpu system with a single gjournal > data store, although I haven't run this configuration for a few > months. > > Kris As a data point, I've been using gjournal with two 10Tb file systems (same host) for some time now, and it has been doing the job quite well. I don't have nearly the number of CPU's as you, and I dedicate a journal for each fs. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology An undefined problem has an infinite number of solutions. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 17:30:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EF9316A404 for ; Fri, 19 Jan 2007 17:30:34 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 86D5113C461 for ; Fri, 19 Jan 2007 17:30:33 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so468596uge for ; Fri, 19 Jan 2007 09:30:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GtAr5lwuoXHBIN5KBGFlttPgo88eKqN1dEqVf5q+dxj/vCOarBH2HrVkWJoN3n1BgQ2hUn2NgxCc296aSOHxzG+eXe5aVO85AAm6MFNYEyTSEn00jcAozcN2f7Egc+L4rhnH3Tl16FjObpYoKPJFUxw7j+EVlLZeJ6FDuZDdqXQ= Received: by 10.82.135.13 with SMTP id i13mr724663bud.1169227832152; Fri, 19 Jan 2007 09:30:32 -0800 (PST) Received: by 10.78.164.20 with HTTP; Fri, 19 Jan 2007 09:30:32 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 20:30:32 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Bartek Dedersen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: e9c7d5c68ae400ec Cc: current@freebsd.org Subject: Re: Updating the ports from STABLE to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 17:30:34 -0000 On 1/19/07, Bartek Dedersen wrote: > Hi. > > I thought of trying out the bleeding edge and hoped my knowledge of > BSD is high enough to handle it without any major problems. > > But: I installed FreeBSD-6.1 with the provided ISO package available > on freebsd.org. Some packages were installed via pkg_add. After one > week, the technician of the German telecommunication firm managed to > visit me and put his finger on the cables in the cellar. Well, I > thought of upgrading some packages with the ports-subsystem. It was > pretty easy and nice. But then I wanted more and installed CURRENT > from the CVS-source. Some buildworlds and kernel configuration later, > I had a 7.0 Current. Ok, after a startx I got some error that libXmmu > cannot be found. Ok, so I tried to recompile xorg-libraries. Ok, but > there were lots of broken packages due to a filesystem breakdown after > a kernel panic. > Well, I tried to delete it with pkg_delete -f and it worked. Now, I am > recompiling it from the updated ports-collection. > > Do I have to expect more failures and do I see an upcoming recompiling > week due to broken libraries which do not work on CURRENT? Is it more > useful to reinstall BSD from scratch and update it first? > > I know, CURRENT is not for productive use but I need something to put > my fingers on. Maybe I will learn. > > Is there a command to recompile, deinstall and reinstall every > installed package from the ports-system? If not, it will be hell. "portupgrade -af", but I'd advise to "pkg_delete -af" (which has a custom to fail miserably, you might have to pkg_delete in portions of 50-200 packages) and reinstall everything you need later. From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 18:02:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B88816A400 for ; Fri, 19 Jan 2007 18:02:20 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from heave.ugcs.caltech.edu (heave.ugcs.caltech.edu [131.215.176.104]) by mx1.freebsd.org (Postfix) with ESMTP id 02E8B13C459 for ; Fri, 19 Jan 2007 18:02:19 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by heave.ugcs.caltech.edu (Postfix, from userid 3640) id 937578F482; Fri, 19 Jan 2007 10:02:19 -0800 (PST) Date: Fri, 19 Jan 2007 10:02:19 -0800 From: Paul Allen To: Jason Evans Message-ID: <20070119180219.GD8574@heave.ugcs.caltech.edu> References: <200701172045.35137.shoesoft@gmx.net> <45B00BF5.6030200@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B00BF5.6030200@FreeBSD.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: very high memory usage in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 18:02:20 -0000 >From Jason Evans , Thu, Jan 18, 2007 at 04:08:21PM -0800: > Personally, in the absence of a dynamic boundary between the data > segment and the heap, I would be quite happy to completely disable > sbrk() support in jemalloc, and let those who really need that last 512 > MB of address space adjust resource limits for their applications as > necessary. In practice, I expect this would cause people far less > trouble than does the current state of affairs. Well it might be reasonable to use a malloc flag. Nonetheless, it should be possible for you to MADV_FREE brk memory without moving the brk point. While munmap has some advantages in better coexisting with direct use of mmap by a program, MADV_FREE has the advantage that virtual pages can be immediately reused without incurring a syscall cost. It isn't obvious a priori what the right balance of these operations is. Paul From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 18:12:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A86DC16A401 for ; Fri, 19 Jan 2007 18:12:32 +0000 (UTC) (envelope-from SRS1=bbdd40e8c34c09456d4044abde7b940503d33709=es.net==bbdd40e8c34c09456d4044abde7b940503d33709=220=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC8A13C459 for ; Fri, 19 Jan 2007 18:12:32 +0000 (UTC) (envelope-from SRS1=bbdd40e8c34c09456d4044abde7b940503d33709=es.net==bbdd40e8c34c09456d4044abde7b940503d33709=220=es.net=oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id YSA23039 for ; Fri, 19 Jan 2007 09:59:39 -0800 Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id YSA26635 for ; Fri, 19 Jan 2007 09:59:35 -0800 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id YSA80433; Fri, 19 Jan 2007 09:59:33 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 82E1245053; Fri, 19 Jan 2007 09:59:33 -0800 (PST) To: "Bartek Dedersen" In-Reply-To: Your message of "Fri, 19 Jan 2007 17:40:29 +0100." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1169229573_82965P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 19 Jan 2007 09:59:33 -0800 From: "Kevin Oberman" Message-Id: <20070119175933.82E1245053@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Updating the ports from STABLE to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 18:12:32 -0000 --==_Exmh_1169229573_82965P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Fri, 19 Jan 2007 17:40:29 +0100 > From: "Bartek Dedersen" > Sender: owner-freebsd-current@freebsd.org > > Hi. > > I thought of trying out the bleeding edge and hoped my knowledge of > BSD is high enough to handle it without any major problems. > > But: I installed FreeBSD-6.1 with the provided ISO package available > on freebsd.org. Some packages were installed via pkg_add. After one > week, the technician of the German telecommunication firm managed to > visit me and put his finger on the cables in the cellar. Well, I > thought of upgrading some packages with the ports-subsystem. It was > pretty easy and nice. But then I wanted more and installed CURRENT > from the CVS-source. Some buildworlds and kernel configuration later, > I had a 7.0 Current. Ok, after a startx I got some error that libXmmu > cannot be found. Ok, so I tried to recompile xorg-libraries. Ok, but > there were lots of broken packages due to a filesystem breakdown after > a kernel panic. > Well, I tried to delete it with pkg_delete -f and it worked. Now, I am > recompiling it from the updated ports-collection. > > Do I have to expect more failures and do I see an upcoming recompiling > week due to broken libraries which do not work on CURRENT? Is it more > useful to reinstall BSD from scratch and update it first? > > I know, CURRENT is not for productive use but I need something to put > my fingers on. Maybe I will learn. > > Is there a command to recompile, deinstall and reinstall every > installed package from the ports-system? If not, it will be hell. Welcome to the world of the bleeding edge. The problem you are seeing is probably a result of the changing APIs and ABIs in current. The effect of this is that ports will need to be rebuilt fairly often and the libraries to which they are linked change. The ABI is frozen within a major version and compatibility shims are built to allow binaries from older versions to run after a new version is released, but while it is still "current", there is no alternative to frequent re-builds of ports. In the future (post V7), it is hoped that symbol versioning will eliminate this problem and make running current easier. There are two tools that can make life easier by automating much of this. You should install sysutils/portupgrade and sysutils/portmanager. These do similar things to maintain ports, but in different ways. I have only used portupgrade, but have seen reports that portmanager has some advantages at the cost of more time spent in the initial setup. Another import detail is that you update the ports tree and, if you initially installed the ports tree from the install media, you need to 'rm -rf /usr/ports/*' and then download a full clean tree with csup. csup will delete old files only if it knows about them and it will not know about any that were not fetched by csup. This can result in broken ports. Good luck! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1169229573_82965P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFFsQcFkn3rs5h7N1ERAm+DAJ42TIEDAILBuv0/ANvsqRG4EUqjfgCcDl3g +x2mMsctN1ahlw503pZ5Q8k= =XvTC -----END PGP SIGNATURE----- --==_Exmh_1169229573_82965P-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 18:55:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BCDB16A400 for ; Fri, 19 Jan 2007 18:55:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id 92A0413C44B for ; Fri, 19 Jan 2007 18:55:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so520014wri for ; Fri, 19 Jan 2007 10:55:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tLpYsfwtBYgSvWRxvK6XxqS4qCR0ZZgfkmXrcvz+rAhySfAZ7MAmXn3XbwAs3HXQXj7taftrAlZICapeiIan+AnG7F+8UQ/VOg1b/eReAVcBevVgjs4szLcLTbDMX0C12f/CYXDYddERV14ktdtjNmV97KWLMNFiyCbQYpRZCEU= Received: by 10.90.51.17 with SMTP id y17mr3215264agy.1169232950891; Fri, 19 Jan 2007 10:55:50 -0800 (PST) Received: by 10.90.74.7 with HTTP; Fri, 19 Jan 2007 10:55:50 -0800 (PST) Message-ID: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> Date: Fri, 19 Jan 2007 10:55:50 -0800 From: "Jack Vogel" To: "Mark Atkinson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 18:55:52 -0000 On 1/19/07, Mark Atkinson wrote: > I upgraded a box to -current yesterday with the following pci card in it, > (this is the msi disabled verbose boot below) but upon bootup, any heavy > network activity caused watchdog timeouts and resets. Disabling msi via > the two tunables fixed the problem. > > What info do you need on this problem? > > found-> vendor=0x8086, dev=0x1076, revid=0x00 > bus=4, slot=2, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good > map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled > pcib4: requested I/O range 0xdcc0-0xdcff: in range > pcib4: matched entry for 4.2.INTA > pcib4: slot 2 INTA hardwired to IRQ 18 > em0: port > 0xdcc0-0xdcff m > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device 2.0 on pci4 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 > em0: bpf attached > em0: Ethernet address: 00:0e:0c:6e:a1:39 > em0: [FAST] Talked about this internally, and the advise here is that the em driver change so that only PCI-E adapters can use MSI, this would eliminate the need to blacklist in the kernel PCI code. Jack From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 21:27:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43FFA16A405 for ; Fri, 19 Jan 2007 21:27:40 +0000 (UTC) (envelope-from hika@bsdmon.com) Received: from bigfugu.bsdmon.com (218.128.101-84.rev.gaoland.net [84.101.128.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7850613C478 for ; Fri, 19 Jan 2007 21:27:33 +0000 (UTC) (envelope-from hika@bsdmon.com) Received: from localhost (localhost [127.0.0.1]) by bigfugu.bsdmon.com (Postfix) with ESMTP id 7930B627C for ; Fri, 19 Jan 2007 22:04:54 +0100 (CET) Received: from bigfugu.bsdmon.com ([127.0.0.1]) by localhost (bigfugu.bsdmon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79594-05 for ; Fri, 19 Jan 2007 22:04:52 +0100 (CET) Received: from sdf1.bsdmon.com (sdf1.macross.vfx [10.0.1.1]) by bigfugu.bsdmon.com (Postfix) with ESMTP id A7C416268 for ; Fri, 19 Jan 2007 22:04:52 +0100 (CET) Date: Fri, 19 Jan 2007 22:05:00 +0100 From: Gilbert Cao To: freebsd-current@freebsd.org Message-ID: <20070119210500.GB1163@bsdmon.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline X-Operating-System: FreeBSD 6.1-RELEASE i386 Organization: BSDMon X-GPG-Key: http://www.bsdmon.com/public_key.gpg User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new at bsdmon.com Subject: Incorrect kernel time on laptop boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 21:27:40 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, =20 I currently experienced a problem with my Sony Vaio VGN-FE31B laptop. Each time I boot, from my user point of view, the kernel time seems to be set with the wrong date time. I have poweroff the machine, wait for a whole day, and I reboot again, the kernel time is set with yesterday's date and time. It is like some clock has completely stopped on power off. However, if I boot it with a FreeBSD 7.0-CURRENT-200610 kernel, its date and time is set correctly. So, I might concluded that something has changed between 200610 and 200611 snapshots. Any ideas ? If anybody can point me to the right kernel source file(s) so I can try to figure out what has changed, it would be a good start for me ;) Anyway, I don't know if it can help but here is a result from : $ sysctl kern.timecounter >> -------------------------------------------------------------------- kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 17348 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 15466075 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 886479930 kern.timecounter.tc.TSC.frequency: 1662511500 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.stepwarnings: 0 kern.timecounter.nbinuptime: 1387464 kern.timecounter.nnanouptime: 8 kern.timecounter.nmicrouptime: 74273 kern.timecounter.nbintime: 92905 kern.timecounter.nnanotime: 13 kern.timecounter.nmicrotime: 92892 kern.timecounter.ngetbinuptime: 120493 kern.timecounter.ngetnanouptime: 173 kern.timecounter.ngetmicrouptime: 174462 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 2 kern.timecounter.ngetmicrotime: 330562 kern.timecounter.nsetclock: 3 kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.tick: 1 kern.timecounter.smp_tsc: 0 =2E. and a dmesg output from my laptop: >> -------------------------------------------------------------------- Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Sun Jan 14 15:35:13 CET 2007 root@vaio.bsdmon.com:/usr/obj/usr/src/sys/VAIO WARNING: WITNESS option enabled, expect reduced performance. WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.51-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0xe39d> AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 1609105408 (1534 MB) avail memory =3D 1558872064 (1486 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xd1000000-0xd1ffffff,0xb0000000-0xbfffffff,= 0xd0000000-0xd0ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] pcm0: mem 0xd2300000-0xd230= 3fff irq 22 at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci4: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci6: on pcib4 pci6: at device 0.0 (no driver attached) pcib5: irq 21 at device 28.3 on pci0 pci8: on pcib5 uhci0: port 0x1800-0x181f irq 23 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 17 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 16 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd2304000-0xd23043f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci10: on pcib6 cbb0: at device 3.0 on pci10 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xd2006000-0xd20067ff,0x= d2000000-0xd2003fff irq 16 at device 3.1 on pci10 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:02:2e:b7:82 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 0a:00:46:2e:b7:82 fwe0: Ethernet address: 0a:00:46:2e:b7:82 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci10: at device 3.2 (no driver attached) fxp0: port 0x6000-0x603f mem 0xd20050= 00-0xd2005fff irq 20 at device 8.0 on pci10 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:13:a9:48:cf:09 fxp0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x18c8-0x18cf,0x18ac-0x18af,= 0x18c0-0x18c7,0x18a8-0x18ab,0x18b0-0x18bf mem 0xd2304400-0xd23047ff irq 19 = at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xdc000-0xdffff,0xe0000-0x= e17ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub1 ums0: 16 buttons and Z dir. Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 76319MB at ata2-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s3a --=20 -------------------------------- (hika) Gilbert Cao http://www.miaouirc.com - MiaouIRC Project 2002-2003 http://www.bsdmon.com - The BSD DMON Power to serve IRC : #miaule at IRCNET Network -------------------------------- --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFsTJ6SyQfFTqAEpcRAnWUAKCBpoOR0zToB2RJ67Q/OukxkZOINgCgjy5w s+Rj0xQb2uM8lB+WWgc8Yq8= =xzIg -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 19 22:07:08 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80DFB16A404 for ; Fri, 19 Jan 2007 22:07:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5910213C448 for ; Fri, 19 Jan 2007 22:07:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [10.0.0.1] (63-226-247-187.tukw.qwest.net [63.226.247.187]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l0JM74bP036281 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jan 2007 17:07:06 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 19 Jan 2007 14:07:21 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org Message-ID: <20070119135849.D558@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Improved ULE load balancing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2007 22:07:08 -0000 I'd like those of you that reported relatively poor SMP performance on ULE to update to revision 1.179. This improved performance on my dual xeon to about 10% better than 4BSD running supersmack. It is also highly tunable. Some options of interest: kern.sched. : pick_pri - The default is on. Turning this off will revert to the older algorithm which is now called pickidle. pick_pri tries to always run the highest priority threads. pickidle really just tries to balance cpu load and doesn't take priority into consideration. pick_pri_affinity - Number of ticks a thread has slept for before we stop considering it as having affinity for a given cpu. busy_thresh - Length of run queue allowed before idle cpus will try to steal some of our work. This defaults to 4 but on some workloads I see improvement with values as low as 2. ipi_thresh - Priorities below this generate IPIs to preempt the target cpu. Can decrease latency for some workloads but at the expense of extra context switches and interrupt overhead. The default configuration was fastest on the most workloads on my 8way opteron and 2x xeon (+2xHTT). I tested parallel compiles and super-smack with select-key.smack doing different workloads on both machines and with different numbers of processors enabled on the 8way opteron. The opteron in 8way mode shows about 300% speedup compared to 4BSD on super-smack. compile times are nearly identical across all schedulers and platforms. I get a more modest 5-10% faster on super-smack on my xeon running super-smack depending on the configuration. Please report back your findings. Hopefully with the tunables present I can experiment and get the settings ride for a wide array of machines. Thanks, Jeff ---------- Forwarded message ---------- Date: Fri, 19 Jan 2007 21:56:08 +0000 (UTC) From: Jeff Roberson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern sched_ule.c jeff 2007-01-19 21:56:08 UTC FreeBSD src repository Modified files: sys/kern sched_ule.c Log: Major revamp of ULE's cpu load balancing: - Switch back to direct modification of remote CPU run queues. This added a lot of complexity with questionable gain. It's easy enough to reimplement if it's shown to help on huge machines. - Re-implement the old tdq_transfer() call as tdq_pickidle(). Change sched_add() so we have selectable cpu choosers and simplify the logic a bit here. - Implement tdq_pickpri() as the new default cpu chooser. This algorithm is similar to Solaris in that it tries to always run the threads with the best priorities. It is actually slightly more complex than solaris's algorithm because we also tend to favor the local cpu over other cpus which has a boost in latency but also potentially enables cache sharing between the waking thread and the woken thread. - Add a bunch of tunables that can be used to measure effects of different load balancing strategies. Most of these will go away once the algorithm is more definite. - Add a new mechanism to steal threads from busy cpus when we idle. This is enabled with kern.sched.steal_busy and kern.sched.busy_thresh. The threshold is the required length of a tdq's run queue before another cpu will be able to steal runnable threads. This prevents most queue imbalances that contribute the long latencies. Revision Changes Path 1.179 +293 -240 src/sys/kern/sched_ule.c From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 05:55:46 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 969B216A402; Sat, 20 Jan 2007 05:55:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 704BC13C45A; Sat, 20 Jan 2007 05:55:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K5tjKP066155; Sat, 20 Jan 2007 00:55:45 -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.8/8.13.8) with ESMTP id l0K5tjZa075904; Sat, 20 Jan 2007 00:55:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7A3B273034; Sat, 20 Jan 2007 00:55:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120055545.7A3B273034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 00:55:45 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 05:55:46 -0000 TB --- 2007-01-20 04:23:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 04:23:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-01-20 04:23:12 - cleaning the object tree TB --- 2007-01-20 04:23:47 - checking out the source tree TB --- 2007-01-20 04:23:47 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-01-20 04:23:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 04:33:29 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 04:33:29 - cd /src TB --- 2007-01-20 04:33:29 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 04:33:31 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 05:49:35 UTC 2007 TB --- 2007-01-20 05:49:35 - generating LINT kernel config TB --- 2007-01-20 05:49:35 - cd /src/sys/ia64/conf TB --- 2007-01-20 05:49:35 - /usr/bin/make -B LINT TB --- 2007-01-20 05:49:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 05:49:35 - cd /src TB --- 2007-01-20 05:49:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 05:49:35 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/dev/isp/isp_target.c /src/sys/dev/isp/isp_target.c: In function `isp_got_tmf_24xx': /src/sys/dev/isp/isp_target.c:967: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:972: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:977: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:982: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:988: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:993: warning: long long unsigned int format, uint64_t arg (arg 7) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 05:55:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 05:55:45 - ERROR: failed to build lint kernel TB --- 2007-01-20 05:55:45 - tinderbox aborted TB --- 0.73 user 2.50 system 5552.66 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 06:53:21 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id DB61216A405; Sat, 20 Jan 2007 06:53:21 +0000 (UTC) In-Reply-To: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> from Jack Vogel at "Jan 17, 2007 12:58:04 pm" To: jfvogel@gmail.com (Jack Vogel) Date: Sat, 20 Jan 2007 06:53:21 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070120065321.DB61216A405@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, jon.otterholm@ide.resurscentrum.se Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 06:53:22 -0000 > Since this was just seen, and the patch below validated as working I wanted > to send general email to capture this: > > The Lenovo X60 can have issues with long ping times, this is a KNOWN > hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > not been decided on yet. Nevertheless, the patch below will work, but > I do not want to check it in as its still temporary. > > Address questions to me, Okay, I have a question. Could you elaborate on just what the problem is? (I mean, since it's KNOWN and all...) I'm just having a hard time figuring out what problem could possibly be fixed by setting the RX interrupt delay timer to a non-zero value (especially since elsewhere in the em(4) source it says that doing so is a Bad Thing (tm)). -Bill > Jack > > PS This is based on 6.2, but is needed for CURRENT as well. > > > --- if_em.dist.c Wed Jan 17 17:59:46 2007 > +++ if_em.c Wed Jan 17 18:03:13 2007 > @@ -3348,6 +3348,10 @@ > E1000_WRITE_REG(&adapter->hw, RXCSUM, reg_rxcsum); > } > > + /* TEMPORARY WORKAROUND for X60 */ > + if (adapter->hw.mac_type == em_82573) > + E1000_WRITE_REG(&adapter->hw, RDTR, 32); > + > /* Enable Receives */ > E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); > /* > From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:00:03 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A34AC16A402 for ; Sat, 20 Jan 2007 07:00:03 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 682E713C457 for ; Sat, 20 Jan 2007 07:00:03 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l0K6xvcc028132 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Jan 2007 02:00:02 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 19 Jan 2007 23:00:19 -0800 (PST) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: current@freebsd.org In-Reply-To: <20070119135849.D558@10.0.0.1> Message-ID: <20070119225918.P629@10.0.0.1> References: <20070119135849.D558@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Improved ULE load balancing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:00:03 -0000 I have a few reports that pickpri disturbs interactive performance. If you're running ULE on a SMP desktop machine please set kern.sched.pick_pri = 0. I'll look into this asap. Unfortunately my primary desktop is not SMP and I didn't notice this regression. Thanks, Jeff On Fri, 19 Jan 2007, Jeff Roberson wrote: > I'd like those of you that reported relatively poor SMP performance on ULE to > update to revision 1.179. This improved performance on my dual xeon to about > 10% better than 4BSD running supersmack. It is also highly tunable. Some > options of interest: > > kern.sched. : > pick_pri - The default is on. Turning this off will revert to the older > algorithm which is now called pickidle. pick_pri tries to always run the > highest priority threads. pickidle really just tries to balance cpu load and > doesn't take priority into consideration. > > pick_pri_affinity - Number of ticks a thread has slept for before we stop > considering it as having affinity for a given cpu. > > busy_thresh - Length of run queue allowed before idle cpus will try to steal > some of our work. This defaults to 4 but on some workloads I see improvement > with values as low as 2. > > ipi_thresh - Priorities below this generate IPIs to preempt the target cpu. > Can decrease latency for some workloads but at the expense of extra context > switches and interrupt overhead. > > The default configuration was fastest on the most workloads on my 8way > opteron and 2x xeon (+2xHTT). I tested parallel compiles and super-smack > with select-key.smack doing different workloads on both machines and with > different numbers of processors enabled on the 8way opteron. The opteron in > 8way mode shows about 300% speedup compared to 4BSD on super-smack. compile > times are nearly identical across all schedulers and platforms. I get a more > modest 5-10% faster on super-smack on my xeon running super-smack depending > on the configuration. > > Please report back your findings. Hopefully with the tunables present I can > experiment and get the settings ride for a wide array of machines. > > Thanks, > Jeff > > ---------- Forwarded message ---------- > Date: Fri, 19 Jan 2007 21:56:08 +0000 (UTC) > From: Jeff Roberson > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org > Subject: cvs commit: src/sys/kern sched_ule.c > > jeff 2007-01-19 21:56:08 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_ule.c > Log: > Major revamp of ULE's cpu load balancing: > - Switch back to direct modification of remote CPU run queues. This added > a lot of complexity with questionable gain. It's easy enough to > reimplement if it's shown to help on huge machines. > - Re-implement the old tdq_transfer() call as tdq_pickidle(). Change > sched_add() so we have selectable cpu choosers and simplify the logic > a bit here. > - Implement tdq_pickpri() as the new default cpu chooser. This algorithm > is similar to Solaris in that it tries to always run the threads with > the best priorities. It is actually slightly more complex than > solaris's algorithm because we also tend to favor the local cpu over > other cpus which has a boost in latency but also potentially enables > cache sharing between the waking thread and the woken thread. > - Add a bunch of tunables that can be used to measure effects of different > load balancing strategies. Most of these will go away once the > algorithm is more definite. > - Add a new mechanism to steal threads from busy cpus when we idle. This > is enabled with kern.sched.steal_busy and kern.sched.busy_thresh. The > threshold is the required length of a tdq's run queue before another > cpu will be able to steal runnable threads. This prevents most queue > imbalances that contribute the long latencies. > > Revision Changes Path > 1.179 +293 -240 src/sys/kern/sched_ule.c > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:05:04 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF13516A401; Sat, 20 Jan 2007 07:05:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id B381E13C44C; Sat, 20 Jan 2007 07:05:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K753Kq069678; Sat, 20 Jan 2007 02:05:03 -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.8/8.13.8) with ESMTP id l0K753m7056158; Sat, 20 Jan 2007 02:05:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EAFE273034; Sat, 20 Jan 2007 02:05:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120070502.EAFE273034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 02:05:02 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:05:04 -0000 TB --- 2007-01-20 05:55:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 05:55:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-01-20 05:55:45 - cleaning the object tree TB --- 2007-01-20 05:56:25 - checking out the source tree TB --- 2007-01-20 05:56:25 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2007-01-20 05:56:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 06:06:31 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 06:06:31 - cd /src TB --- 2007-01-20 06:06:31 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 06:06:33 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 07:00:14 UTC 2007 TB --- 2007-01-20 07:00:14 - generating LINT kernel config TB --- 2007-01-20 07:00:14 - cd /src/sys/sparc64/conf TB --- 2007-01-20 07:00:14 - /usr/bin/make -B LINT TB --- 2007-01-20 07:00:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 07:00:15 - cd /src TB --- 2007-01-20 07:00:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 07:00:15 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_target.c /src/sys/dev/isp/isp_target.c: In function `isp_got_tmf_24xx': /src/sys/dev/isp/isp_target.c:967: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:972: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:977: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:982: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:988: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:993: warning: long long unsigned int format, uint64_t arg (arg 7) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 07:05:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 07:05:02 - ERROR: failed to build lint kernel TB --- 2007-01-20 07:05:02 - tinderbox aborted TB --- 0.73 user 2.34 system 4157.12 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:28:32 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24F4016A401 for ; Sat, 20 Jan 2007 07:28:32 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id E109D13C44B for ; Sat, 20 Jan 2007 07:28:31 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so341110pyh for ; Fri, 19 Jan 2007 23:28:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KCbRYR5AG2P0aqMtKNf8JCiZ5gl8hdRNXQ0smKRZFcN5dMF2ywv//LlMeWICycsxsAwkW8G6VLLaeuBeJwHy9NH7/X2CRrB1ofz5UkBh/Eb7gGtQwqnVSchDyGWHBuxfWlt5bfu4KHjRYkpQaxnTRGWbL178xNK+/F/ueU+yE0o= Received: by 10.114.190.6 with SMTP id n6mr1082waf.1169278110941; Fri, 19 Jan 2007 23:28:30 -0800 (PST) Received: by 10.115.19.4 with HTTP; Fri, 19 Jan 2007 23:28:30 -0800 (PST) Message-ID: <6eb82e0701192328v4e44515bvcb3adeca8fcae115@mail.gmail.com> Date: Sat, 20 Jan 2007 15:28:30 +0800 From: "Rong-en Fan" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: HEADS UP: ncurses update on the way X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:28:32 -0000 In the next hour, I'm going to import ncurses 5.6 into base. There will be a short breakage. I will send out another message when it's done. Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:42:47 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31EC016A400; Sat, 20 Jan 2007 07:42:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0C56513C467; Sat, 20 Jan 2007 07:42:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K7gkFT071734; Sat, 20 Jan 2007 02:42:46 -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.8/8.13.8) with ESMTP id l0K7gkd4052163; Sat, 20 Jan 2007 02:42:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EBFCA73034; Sat, 20 Jan 2007 02:42:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120074245.EBFCA73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 02:42:45 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:42:47 -0000 TB --- 2007-01-20 06:40:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 06:40:03 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-20 06:40:03 - cleaning the object tree TB --- 2007-01-20 06:40:32 - checking out the source tree TB --- 2007-01-20 06:40:32 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-20 06:40:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 06:50:13 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 06:50:13 - cd /src TB --- 2007-01-20 06:50:13 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 06:50:14 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 07:38:28 UTC 2007 TB --- 2007-01-20 07:38:28 - generating LINT kernel config TB --- 2007-01-20 07:38:28 - cd /src/sys/sun4v/conf TB --- 2007-01-20 07:38:28 - /usr/bin/make -B LINT TB --- 2007-01-20 07:38:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 07:38:28 - cd /src TB --- 2007-01-20 07:38:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 07:38:28 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/isp/isp_target.c /src/sys/dev/isp/isp_target.c: In function `isp_got_tmf_24xx': /src/sys/dev/isp/isp_target.c:967: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:972: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:977: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:982: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:988: warning: long long unsigned int format, uint64_t arg (arg 7) /src/sys/dev/isp/isp_target.c:993: warning: long long unsigned int format, uint64_t arg (arg 7) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 07:42:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 07:42:45 - ERROR: failed to build lint kernel TB --- 2007-01-20 07:42:45 - tinderbox aborted TB --- 0.58 user 2.04 system 3762.28 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:42:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EF4F16A405 for ; Sat, 20 Jan 2007 07:42:56 +0000 (UTC) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.freebsd.org (Postfix) with ESMTP id 0431313C44C for ; Sat, 20 Jan 2007 07:42:55 +0000 (UTC) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.8/8.13.8) with ESMTP id l0K7F38d089393; Sat, 20 Jan 2007 15:15:03 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.8/8.13.8/Submit) id l0K7F3jt021922; Sat, 20 Jan 2007 15:15:03 +0800 (CST) (envelope-from rafan) Date: Sat, 20 Jan 2007 15:15:03 +0800 From: Rong-En Fan To: freebsd-current@freebsd.org Message-ID: <20070120071503.GP74325@svm.csie.ntu.edu.tw> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: delphij@freebsd.org, peter@freebsd.org Subject: HEADS UP: ncurses update on the way X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:42:56 -0000 --AsxXAMtlQ5JHofzM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the next hour, I'm going to import ncurses 5.6 into base. There will be a short breakage. I will send out another message when it's done. Regards, Rong-En Fan --AsxXAMtlQ5JHofzM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFscF2144QkYb9jGgRAsPTAJ95d6gQuqxcsv5mjv9xTVP/wh4WCACeJC+S 7hEK5sbOIOh1jHxxxoWm9kQ= =3Db7 -----END PGP SIGNATURE----- --AsxXAMtlQ5JHofzM-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:58:31 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF4C016A402; Sat, 20 Jan 2007 07:58:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7273613C45B; Sat, 20 Jan 2007 07:58:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K7wUET072706; Sat, 20 Jan 2007 02:58:30 -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.8/8.13.8) with ESMTP id l0K7wUli043615; Sat, 20 Jan 2007 02:58:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8D60A73034; Sat, 20 Jan 2007 02:58:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120075830.8D60A73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 02:58:30 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:58:31 -0000 TB --- 2007-01-20 07:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 07:45:00 - starting HEAD tinderbox run for arm/arm TB --- 2007-01-20 07:45:00 - cleaning the object tree TB --- 2007-01-20 07:45:31 - checking out the source tree TB --- 2007-01-20 07:45:31 - cd /tinderbox/HEAD/arm/arm TB --- 2007-01-20 07:45:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 07:56:39 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 07:56:39 - cd /src TB --- 2007-01-20 07:56:39 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 07:56:40 UTC 2007 >>> 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 [...] ./term.h:676: error: stray '@' in program ./term.h:676: error: syntax error before "NCURSES_SBOOL" ./term.h:676: error: stray '@' in program In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:254, from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/include/nc_tparm.h:44:5: token "@" is not valid in preprocessor expressions In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:540: error: syntax error before "mmask_t" *** Error code 1 Stop in /src/lib/libncurses. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 07:58:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 07:58:30 - ERROR: failed to build world TB --- 2007-01-20 07:58:30 - tinderbox aborted TB --- 0.52 user 1.60 system 809.29 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 07:58:33 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FC7C16A400; Sat, 20 Jan 2007 07:58:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F239A13C44C; Sat, 20 Jan 2007 07:58:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0K7wWZ6074098; Sat, 20 Jan 2007 02:58:32 -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.8/8.13.8) with ESMTP id l0K7wWBl088557; Sat, 20 Jan 2007 02:58:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E9F1C73036; Sat, 20 Jan 2007 02:58:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120075831.E9F1C73036@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 02:58:31 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 07:58:33 -0000 TB --- 2007-01-20 07:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 07:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-20 07:45:00 - cleaning the object tree TB --- 2007-01-20 07:45:48 - checking out the source tree TB --- 2007-01-20 07:45:48 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-20 07:45:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 07:56:39 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 07:56:39 - cd /src TB --- 2007-01-20 07:56:39 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 07:56:40 UTC 2007 >>> 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 [...] ./term.h:676: error: stray '@' in program ./term.h:676: error: syntax error before "NCURSES_SBOOL" ./term.h:676: error: stray '@' in program In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:254, from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/include/nc_tparm.h:44:5: token "@" is not valid in preprocessor expressions In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:540: error: syntax error before "mmask_t" *** Error code 1 Stop in /src/lib/libncurses. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 07:58:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 07:58:31 - ERROR: failed to build world TB --- 2007-01-20 07:58:31 - tinderbox aborted TB --- 0.95 user 3.45 system 811.02 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 08:14:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAE2516A480; Sat, 20 Jan 2007 08:14:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7076113C4A7; Sat, 20 Jan 2007 08:14:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K8EY8Z073988; Sat, 20 Jan 2007 03:14:34 -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.8/8.13.8) with ESMTP id l0K8EYR0025946; Sat, 20 Jan 2007 03:14:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6FD0A73034; Sat, 20 Jan 2007 03:14:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120081434.6FD0A73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 03:14:34 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 08:14:36 -0000 TB --- 2007-01-20 07:58:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 07:58:32 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-01-20 07:58:32 - cleaning the object tree TB --- 2007-01-20 07:59:24 - checking out the source tree TB --- 2007-01-20 07:59:24 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-01-20 07:59:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 08:12:16 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 08:12:16 - cd /src TB --- 2007-01-20 08:12:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 08:12:17 UTC 2007 >>> 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 [...] ./term.h:676: error: stray '@' in program ./term.h:676: error: syntax error before "NCURSES_SBOOL" ./term.h:676: error: stray '@' in program In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:254, from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/include/nc_tparm.h:44:5: token "@" is not valid in preprocessor expressions In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:540: error: syntax error before "mmask_t" *** Error code 1 Stop in /src/lib/libncurses. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 08:14:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 08:14:33 - ERROR: failed to build world TB --- 2007-01-20 08:14:33 - tinderbox aborted TB --- 0.91 user 2.60 system 961.94 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 08:14:38 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3C5B16A480; Sat, 20 Jan 2007 08:14:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8759713C4B9; Sat, 20 Jan 2007 08:14:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0K8EcGq073991; Sat, 20 Jan 2007 03:14:38 -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.8/8.13.8) with ESMTP id l0K8EbBb053167; Sat, 20 Jan 2007 03:14:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C1CDA73036; Sat, 20 Jan 2007 03:14:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120081437.C1CDA73036@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 03:14:37 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 08:14:39 -0000 TB --- 2007-01-20 07:58:30 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 07:58:30 - starting HEAD tinderbox run for i386/i386 TB --- 2007-01-20 07:58:30 - cleaning the object tree TB --- 2007-01-20 07:59:19 - checking out the source tree TB --- 2007-01-20 07:59:19 - cd /tinderbox/HEAD/i386/i386 TB --- 2007-01-20 07:59:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 08:12:16 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 08:12:16 - cd /src TB --- 2007-01-20 08:12:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 08:12:18 UTC 2007 >>> 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 [...] ./term.h:676: error: stray '@' in program ./term.h:676: error: syntax error before "NCURSES_SBOOL" ./term.h:676: error: stray '@' in program In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:254, from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/include/nc_tparm.h:44:5: token "@" is not valid in preprocessor expressions In file included from /src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_hash.c:42: /src/lib/libncurses/../../contrib/ncurses/ncurses/curses.priv.h:540: error: syntax error before "mmask_t" *** Error code 1 Stop in /src/lib/libncurses. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 08:14:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 08:14:36 - ERROR: failed to build world TB --- 2007-01-20 08:14:36 - tinderbox aborted TB --- 0.82 user 2.82 system 966.35 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 08:15:22 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EC7716A475 for ; Sat, 20 Jan 2007 08:15:22 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 337E113C4BB for ; Sat, 20 Jan 2007 08:15:22 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so345078pyh for ; Sat, 20 Jan 2007 00:15:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YpiyubM3Mn4NHnG9FZ4q/1XrERyc8rvnks7u+eomkyeZ32/dP0iCkKUfzLYAQQF+sQcFwExBwxq3mLp/Tb9rslP0lnAgKYVEyYcqRxs/sPnCUZ2tCqax/FstRjoOEunxhbz+3skKlGEm77ETV0opzWS3P+/eONK7rs1iL44D26E= Received: by 10.114.181.1 with SMTP id d1mr758waf.1169280913386; Sat, 20 Jan 2007 00:15:13 -0800 (PST) Received: by 10.115.19.4 with HTTP; Sat, 20 Jan 2007 00:15:13 -0800 (PST) Message-ID: <6eb82e0701200015u1cf12019xd2ad65298ba87ead@mail.gmail.com> Date: Sat, 20 Jan 2007 16:15:13 +0800 From: "Rong-en Fan" To: freebsd-current@freebsd.org In-Reply-To: <6eb82e0701192328v4e44515bvcb3adeca8fcae115@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0701192328v4e44515bvcb3adeca8fcae115@mail.gmail.com> Cc: delphij@freebsd.org, peter@freebsd.org Subject: Re: HEADS UP: ncurses update on the way X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 08:15:22 -0000 On 1/20/07, Rong-en Fan wrote: > In the next hour, I'm going to import ncurses 5.6 into base. > There will be a short breakage. I will send out another > message when it's done. It's done. > Regards, > Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 08:32:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E77A316A405; Sat, 20 Jan 2007 08:32:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AC9A313C474; Sat, 20 Jan 2007 08:32:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0K8WmHp075721; Sat, 20 Jan 2007 03:32:48 -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.8/8.13.8) with ESMTP id l0K8WmNi064543; Sat, 20 Jan 2007 03:32:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D4E4C73034; Sat, 20 Jan 2007 03:32:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120083247.D4E4C73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 03:32:47 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 08:32:50 -0000 TB --- 2007-01-20 08:14:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 08:14:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-01-20 08:14:37 - cleaning the object tree TB --- 2007-01-20 08:15:43 - checking out the source tree TB --- 2007-01-20 08:15:43 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-01-20 08:15:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 08:30:33 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 08:30:33 - cd /src TB --- 2007-01-20 08:30:33 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 08:30:34 UTC 2007 >>> 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 [...] cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -c /src/bin/sh/mkinit.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -L/obj/powerpc/src/tmp/legacy/usr/lib mkinit.o -o mkinit cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -c /src/bin/sh/mknodes.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -L/obj/powerpc/src/tmp/legacy/usr/lib mknodes.o -o mknodes cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -c /src/bin/sh/mksyntax.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/powerpc/src/tmp/legacy/usr/include -L/obj/powerpc/src/tmp/legacy/usr/lib mksyntax.o -o mksyntax ===> lib/libncurses (obj,build-tools) cd: can't cd to /src/lib/libncurses *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 08:32:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 08:32:47 - ERROR: failed to build world TB --- 2007-01-20 08:32:47 - tinderbox aborted TB --- 0.77 user 2.26 system 1089.68 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 08:32:54 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F88F16A400; Sat, 20 Jan 2007 08:32:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D1C5913C468; Sat, 20 Jan 2007 08:32:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0K8Wrqh075727; Sat, 20 Jan 2007 03:32:53 -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.8/8.13.8) with ESMTP id l0K8Wq5N064598; Sat, 20 Jan 2007 03:32:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D3B1C73036; Sat, 20 Jan 2007 03:32:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120083252.D3B1C73036@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 03:32:52 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 08:32:54 -0000 TB --- 2007-01-20 08:14:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 08:14:34 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-01-20 08:14:34 - cleaning the object tree TB --- 2007-01-20 08:15:27 - checking out the source tree TB --- 2007-01-20 08:15:27 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-01-20 08:15:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 08:30:33 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 08:30:33 - cd /src TB --- 2007-01-20 08:30:33 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 08:30:34 UTC 2007 >>> 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 [...] cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -c /src/bin/sh/mkinit.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -L/obj/ia64/src/tmp/legacy/usr/lib mkinit.o -o mkinit cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -c /src/bin/sh/mknodes.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -L/obj/ia64/src/tmp/legacy/usr/lib mknodes.o -o mknodes cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -c /src/bin/sh/mksyntax.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -I/obj/ia64/src/tmp/legacy/usr/include -L/obj/ia64/src/tmp/legacy/usr/lib mksyntax.o -o mksyntax ===> lib/libncurses (obj,build-tools) cd: can't cd to /src/lib/libncurses *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 08:32:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 08:32:52 - ERROR: failed to build world TB --- 2007-01-20 08:32:52 - tinderbox aborted TB --- 0.52 user 1.91 system 1098.20 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 13:46:49 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17B8A16A400; Sat, 20 Jan 2007 13:46:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id D734B13C44C; Sat, 20 Jan 2007 13:46:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0KDkmTh095805; Sat, 20 Jan 2007 08:46:48 -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.8/8.13.8) with ESMTP id l0KDkmIT019331; Sat, 20 Jan 2007 08:46:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ED80A73034; Sat, 20 Jan 2007 08:46:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120134647.ED80A73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 08:46:47 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 13:46:49 -0000 TB --- 2007-01-20 12:32:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 12:32:15 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-01-20 12:32:15 - cleaning the object tree TB --- 2007-01-20 12:32:25 - checking out the source tree TB --- 2007-01-20 12:32:25 - cd /tinderbox/HEAD/i386/pc98 TB --- 2007-01-20 12:32:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 12:43:21 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 12:43:21 - cd /src TB --- 2007-01-20 12:43:21 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 12:43:22 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 13:37:07 UTC 2007 TB --- 2007-01-20 13:37:07 - generating LINT kernel config TB --- 2007-01-20 13:37:07 - cd /src/sys/pc98/conf TB --- 2007-01-20 13:37:07 - /usr/bin/make -B LINT TB --- 2007-01-20 13:37:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 13:37:07 - cd /src TB --- 2007-01-20 13:37:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 13:37:07 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_dirhash.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_extattr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_gjournal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_inode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_lookup.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/ufs/ufs/ufs_quota.c /src/sys/ufs/ufs/ufs_quota.c: In function `chkdquot': /src/sys/ufs/ufs/ufs_quota.c:418: warning: `return' with a value, in function returning void *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 13:46:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 13:46:47 - ERROR: failed to build lint kernel TB --- 2007-01-20 13:46:47 - tinderbox aborted TB --- 0.12 user 0.16 system 4472.01 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 15:00:09 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFC8E16A402; Sat, 20 Jan 2007 15:00:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 87AC913C442; Sat, 20 Jan 2007 15:00:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0KExu9O001039; Sat, 20 Jan 2007 09:59: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.8/8.13.8) with ESMTP id l0KExuYE085725; Sat, 20 Jan 2007 09:59:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 929E873034; Sat, 20 Jan 2007 09:59:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120145956.929E873034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 09:59:56 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 15:00:09 -0000 TB --- 2007-01-20 13:46:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 13:46:48 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-01-20 13:46:48 - cleaning the object tree TB --- 2007-01-20 13:46:54 - checking out the source tree TB --- 2007-01-20 13:46:54 - cd /tinderbox/HEAD/powerpc/powerpc TB --- 2007-01-20 13:46:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 13:55:09 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 13:55:09 - cd /src TB --- 2007-01-20 13:55:09 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 13:55:10 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 14:50:49 UTC 2007 TB --- 2007-01-20 14:50:49 - generating LINT kernel config TB --- 2007-01-20 14:50:49 - cd /src/sys/powerpc/conf TB --- 2007-01-20 14:50:49 - /usr/bin/make -B LINT TB --- 2007-01-20 14:50:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 14:50:49 - cd /src TB --- 2007-01-20 14:50:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 14:50:49 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_dirhash.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_extattr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_gjournal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_inode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_lookup.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/ufs/ufs/ufs_quota.c /src/sys/ufs/ufs/ufs_quota.c: In function `chkdquot': /src/sys/ufs/ufs/ufs_quota.c:418: warning: `return' with a value, in function returning void *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 14:59:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 14:59:56 - ERROR: failed to build lint kernel TB --- 2007-01-20 14:59:56 - tinderbox aborted TB --- 0.09 user 0.19 system 4388.29 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 15:02:16 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5274D16A400; Sat, 20 Jan 2007 15:02:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 040D713C4B9; Sat, 20 Jan 2007 15:02:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0KF2F7g001237; Sat, 20 Jan 2007 10:02:15 -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.8/8.13.8) with ESMTP id l0KF2FwE087781; Sat, 20 Jan 2007 10:02:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 092B873034; Sat, 20 Jan 2007 10:02:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120150215.092B873034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 10:02:15 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070102, clamav-milter version devel-111206 on clamscanner5 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 15:02:16 -0000 TB --- 2007-01-20 13:23:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 13:23:23 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-01-20 13:23:23 - cleaning the object tree TB --- 2007-01-20 13:23:30 - checking out the source tree TB --- 2007-01-20 13:23:30 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2007-01-20 13:23:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 13:33:02 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 13:33:02 - cd /src TB --- 2007-01-20 13:33:02 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 13:33:03 UTC 2007 >>> 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 >>> World build completed on Sat Jan 20 14:47:45 UTC 2007 TB --- 2007-01-20 14:47:45 - generating LINT kernel config TB --- 2007-01-20 14:47:45 - cd /src/sys/ia64/conf TB --- 2007-01-20 14:47:45 - /usr/bin/make -B LINT TB --- 2007-01-20 14:47:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 14:47:45 - cd /src TB --- 2007-01-20 14:47:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 14:47:46 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_dirhash.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_extattr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_gjournal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_inode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_lookup.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /src/sys/ufs/ufs/ufs_quota.c /src/sys/ufs/ufs/ufs_quota.c: In function `chkdquot': /src/sys/ufs/ufs/ufs_quota.c:418: warning: `return' with a value, in function returning void *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 15:02:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 15:02:15 - ERROR: failed to build lint kernel TB --- 2007-01-20 15:02:15 - tinderbox aborted TB --- 0.09 user 0.20 system 5931.91 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 15:53:59 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D978016A402 for ; Sat, 20 Jan 2007 15:53:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 57DCB13C468 for ; Sat, 20 Jan 2007 15:53:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0KFrpqn081614; Sat, 20 Jan 2007 10:53:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Sat, 20 Jan 2007 10:41:10 -0500 User-Agent: KMail/1.9.4 References: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> In-Reply-To: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701201041.10752.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Sat, 20 Jan 2007 10:53:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2467/Fri Jan 19 23:42:15 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Jack Vogel , Mark Atkinson Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 15:53:59 -0000 On Friday 19 January 2007 13:55, Jack Vogel wrote: > On 1/19/07, Mark Atkinson wrote: > > I upgraded a box to -current yesterday with the following pci card in it, > > (this is the msi disabled verbose boot below) but upon bootup, any heavy > > network activity caused watchdog timeouts and resets. Disabling msi via > > the two tunables fixed the problem. > > > > What info do you need on this problem? > > > > found-> vendor=0x8086, dev=0x1076, revid=0x00 > > bus=4, slot=2, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good > > map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good > > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled > > pcib4: requested I/O range 0xdcc0-0xdcff: in range > > pcib4: matched entry for 4.2.INTA > > pcib4: slot 2 INTA hardwired to IRQ 18 > > em0: port > > 0xdcc0-0xdcff m > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device 2.0 on pci4 > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 > > em0: bpf attached > > em0: Ethernet address: 00:0e:0c:6e:a1:39 > > em0: [FAST] > > Talked about this internally, and the advise here is that the em driver change > so that only PCI-E adapters can use MSI, this would eliminate the need to > blacklist in the kernel PCI code. It's not em(4) that is the problem, but the system, and I'd rather we fix it generically rather than in each driver. Maybe we should disable MSI for non-PCIe systems? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 15:54:24 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E41016A402 for ; Sat, 20 Jan 2007 15:54:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4153B13C442 for ; Sat, 20 Jan 2007 15:54:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0KFrpqm081614; Sat, 20 Jan 2007 10:53:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Sat, 20 Jan 2007 10:06:16 -0500 User-Agent: KMail/1.9.4 References: <45AF7C3A.2080303@cisco.com> In-Reply-To: <45AF7C3A.2080303@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701201006.17619.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Sat, 20 Jan 2007 10:53:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2467/Fri Jan 19 23:42:15 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Randall Stewart Subject: Re: Zone memory for UMA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 15:54:24 -0000 On Thursday 18 January 2007 08:55, Randall Stewart wrote: > Hi all: > > Query (with flame suit in place :-D) > > Currently the UMA zone's will hold all memory > in them until .. well until the page deamon > runs.. or so the "zone_drain()" comment says.. but > I can't find that connection either. So I guess > not at all :-0 uma_reclaim() drains all zones when it is called. It is called by the pagedaemon when it is woken up to free some memory. > Should we think about adding some sort of garbage > collector thread.. that could hang around slowly and > periodically look for a zone with large numbers of free > pages... and then drain that zone? pagedaemon is a sort of GC thread, but it kicks in whenever the system is low on memory and asks other subsystems like UMA to free up some memory. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 16:07:34 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C545116A405; Sat, 20 Jan 2007 16:07:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 5341713C45D; Sat, 20 Jan 2007 16:07:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5DAA7.dip.t-dialin.net [84.165.218.167]) by redbull.bpaserver.net (Postfix) with ESMTP id B589F2E05E; Sat, 20 Jan 2007 17:15:58 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 3C4A45B482A; Sat, 20 Jan 2007 17:07:24 +0100 (CET) Date: Sat, 20 Jan 2007 17:07:23 +0100 From: Alexander Leidinger To: current@freebsd.org Message-ID: <20070120170723.34c223fb@Magellan.Leidinger.net> Followup-To: emulation@freebsd.org X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: emulation@freebsd.org Subject: CFT/HEADS-UP: linux 2.6.16 emulation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 16:07:34 -0000 Hi, today I committed the last fixes for the showstopper problems (panics) in the linux 2.6.16 emulation. I intend to switch the default version to 2.6.16 on i386 "soon" (see below), so please help testing it. More recent linux distributions (e.g. FC5) require a 2.6 kernel and don't work with 2.4.2 anymore. And because FC4 is "abandon-ware" (no security fixes from fedoralegacy anymore), getting 2.6.16 emulation up an running is very important. If you use a linux program, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desktop is running with 2.6.16 emulation since some days already). After the next boot (or after running "sysctl compat.linux.osrelease=2.6.16", please make sure no linux program is running already) any linux program will start with a linux kernel version of 2.6.16 instead of 2.4.2. The default linux base port (FC4) will then use different code paths (e.g. within glibc). In case you want to switch back to the 2.4.2 emulation without a reboot, please make sure no linux program is running anymore. So far we fixed all known/repeatable problems with acroread, realplayer, skype and linux firefox. If you encounter strange behavior with any linux program, please tell us (emulation@freebsd.org) which program you used, how to repeat the problem, what the problem is, and if it only is visible with 2.6.16 or with 2.4.2 too. You should also watch out for messages in the dmesg (unimplemented system calls or other stuff, this is used to determine the priority of missing syscalls). Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I intend to document the known problems there. If you find your problem there, please tell us about it if you are willing to test fixes. We are specially interested in reports (good or bad) on SMP systems. Please beat the hell out of the linuxulator! On amd64 systems we have not the same functionality as on i386, missing are futexes and TLS. In P4 we already have the futex part covered, but the TLS part is still missing (anyone with a clue about the kernel side of TLS on amd64 is welcome to give a hint or two to jkim@ and rdivacky@). So if you get a message about missing futexes or TLS on amd64: we know about it (testers for the futex stuff are welcome, but first you need to use a program which uses futexes and complains). As long as we get problem reports with 2.6.16 I will not switch the default to 2.6.16. If we don't get a report at all, I will switch the default on i386 to 2.6.16 in two weeks. If we get some problem reports, we will push back the switch a little bit depending on the severity of the problem. Bye, Alexander. -- Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ... http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 18:22:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D90016A477; Sat, 20 Jan 2007 18:22:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C3F9B13C50E; Sat, 20 Jan 2007 18:22:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l0KIMAdi014483; Sat, 20 Jan 2007 13:22:10 -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.8/8.13.8) with ESMTP id l0KIMAVc043893; Sat, 20 Jan 2007 13:22:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 56EBD73034; Sat, 20 Jan 2007 13:22:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120182210.56EBD73034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 13:22:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 18:22:12 -0000 TB --- 2007-01-20 16:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 16:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2007-01-20 16:40:01 - cleaning the object tree TB --- 2007-01-20 16:40:47 - checking out the source tree TB --- 2007-01-20 16:40:47 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2007-01-20 16:40:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 16:52:16 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 16:52:16 - cd /src TB --- 2007-01-20 16:52:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 16:52:18 UTC 2007 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jan 20 18:10:05 UTC 2007 TB --- 2007-01-20 18:10:05 - generating LINT kernel config TB --- 2007-01-20 18:10:05 - cd /src/sys/amd64/conf TB --- 2007-01-20 18:10:05 - /usr/bin/make -B LINT TB --- 2007-01-20 18:10:05 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-01-20 18:10:05 - cd /src TB --- 2007-01-20 18:10:05 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 20 18:10:05 UTC 2007 >>> 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 -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/ia32/ia32_syscall.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/freebsd32/freebsd32_misc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/freebsd32/freebsd32_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/freebsd32/freebsd32_sysent.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/ia32/ia32_sysvec.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linprocfs/linprocfs.c /src/sys/compat/linprocfs/linprocfs.c: In function `linprocfs_doprocstat': /src/sys/compat/linprocfs/linprocfs.c:478: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 18:22:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 18:22:10 - ERROR: failed to build lint kernel TB --- 2007-01-20 18:22:10 - tinderbox aborted TB --- 0.87 user 3.54 system 6128.87 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 19:32:55 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1A0116A481 for ; Sat, 20 Jan 2007 19:32:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id AA34213C44C for ; Sat, 20 Jan 2007 19:32:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5DAA7.dip.t-dialin.net [84.165.218.167]) by redbull.bpaserver.net (Postfix) with ESMTP id 962B82E18F; Sat, 20 Jan 2007 20:41:22 +0100 (CET) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 2F4965B482A; Sat, 20 Jan 2007 20:32:43 +0100 (CET) Date: Sat, 20 Jan 2007 20:32:42 +0100 From: Alexander Leidinger To: FreeBSD Tinderbox Message-ID: <20070120203242.61bf253d@Magellan.Leidinger.net> In-Reply-To: <20070120182210.56EBD73034@freebsd-current.sentex.ca> References: <20070120182210.56EBD73034@freebsd-current.sentex.ca> X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.8; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 19:32:56 -0000 Quoting FreeBSD Tinderbox (Sat, 20 Jan 2007 13:22:10 -0500 (EST)): > /src/sys/compat/linprocfs/linprocfs.c: In function `linprocfs_doprocstat': > /src/sys/compat/linprocfs/linprocfs.c:478: warning: int format, different type arg (arg 3) > *** Error code 1 Does someone has a table of common 32/64 bit printf issues and the corresponding DTRT handling of the issues? To fix this I used something which I did found somewhere in the kernel, but I'm not sure if it is the best way to fix it. I could have casted it to int instead of keeping the precision sizeof() is offering (casting to intmax_t and using a different printf format type). At this place this would have been enough. Bye, Alexander. -- The last person who quit or was fired will be held responsible for everything that goes wrong -- until the next person quits or is fired. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 19:57:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 298AA16A400 for ; Sat, 20 Jan 2007 19:57:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id A982013C459 for ; Sat, 20 Jan 2007 19:57:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.30.98] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1H8MKc47Fr-000322; Sat, 20 Jan 2007 20:56:55 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sat, 20 Jan 2007 20:56:44 +0100 User-Agent: KMail/1.9.5 References: <20070120182210.56EBD73034@freebsd-current.sentex.ca> <20070120203242.61bf253d@Magellan.Leidinger.net> In-Reply-To: <20070120203242.61bf253d@Magellan.Leidinger.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart584704435.sdW9kyYMz7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200701202056.53825.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: amd64@freebsd.org, Alexander Leidinger , FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 19:57:02 -0000 --nextPart584704435.sdW9kyYMz7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 20 January 2007 20:32, Alexander Leidinger wrote: > Quoting FreeBSD Tinderbox (Sat, 20 Jan 2007=20 13:22:10 -0500 (EST)): > > /src/sys/compat/linprocfs/linprocfs.c: In function > > `linprocfs_doprocstat': /src/sys/compat/linprocfs/linprocfs.c:478: > > warning: int format, different type arg (arg 3) *** Error code 1 > > Does someone has a table of common 32/64 bit printf issues and the > corresponding DTRT handling of the issues? To fix this I used something > which I did found somewhere in the kernel, but I'm not sure if it is > the best way to fix it. I could have casted it to int instead of > keeping the precision sizeof() is offering (casting to intmax_t and > using a different printf format type). At this place this would have > been enough. The root of the problem is that we have different typedefs for (u_)int64_t= =20 in 32 and 64 bit archs. Specifically, we use "(unsigned) long" on 64 bit=20 archs while 32 bit archs use "(unsigned) long long". As intmax_t is an=20 alias for int64_t this means also that intmax_t is "shorter" (for some=20 definition) than "long long". I still think that we should make it "long=20 long" on all archs as Net- and OpenBSD do. There are the dreaded PRI... macros that are supposed to fix this, but=20 that is really ugly. In general, a cast to intmax_t and %j or long long=20 and %ll seems to be the preferred sollution. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart584704435.sdW9kyYMz7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFsnQFXyyEoT62BG0RAvHjAJ9JEbOr12nICI4+Sh1ayBNpTcqdJgCfWrhB BCY66HZOcWvpVbdcgl+NM9U= =Nx2H -----END PGP SIGNATURE----- --nextPart584704435.sdW9kyYMz7-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 21:56:56 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40A3816A46C for ; Sat, 20 Jan 2007 21:56:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id D921513C457 for ; Sat, 20 Jan 2007 21:56:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so848720wxc for ; Sat, 20 Jan 2007 13:56:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VuIdeilDKIZD6m82aci32ryvC8Y584wue26of2nTWYL5nf5LAKAS8uUTAuLI0cHxHOlqgevIBCP7AGhJE9citWUDtjPs+xfbKUvPibcQStW21T3VQVVxq2x2T/MRAAvfLilU9GuW0WXmszrNwayosVof/nURVZsNBjKTTdQDbvg= Received: by 10.90.113.18 with SMTP id l18mr4576916agc.1169330214900; Sat, 20 Jan 2007 13:56:54 -0800 (PST) Received: by 10.90.74.7 with HTTP; Sat, 20 Jan 2007 13:56:54 -0800 (PST) Message-ID: <2a41acea0701201356u53dbbd94m877d4e46615d0b2f@mail.gmail.com> Date: Sat, 20 Jan 2007 13:56:54 -0800 From: "Jack Vogel" To: "John Baldwin" In-Reply-To: <200701201041.10752.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> <200701201041.10752.jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Mark Atkinson Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 21:56:56 -0000 On 1/20/07, John Baldwin wrote: > On Friday 19 January 2007 13:55, Jack Vogel wrote: > > On 1/19/07, Mark Atkinson wrote: > > > I upgraded a box to -current yesterday with the following pci card in it, > > > (this is the msi disabled verbose boot below) but upon bootup, any heavy > > > network activity caused watchdog timeouts and resets. Disabling msi via > > > the two tunables fixed the problem. > > > > > > What info do you need on this problem? > > > > > > found-> vendor=0x8086, dev=0x1076, revid=0x00 > > > bus=4, slot=2, func=0 > > > class=02-00-00, hdrtype=0x00, mfdev=0 > > > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) > > > intpin=a, irq=10 > > > powerspec 2 supports D0 D3 current D0 > > > MSI supports 1 message, 64 bit > > > map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled > > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good > > > map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled > > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good > > > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled > > > pcib4: requested I/O range 0xdcc0-0xdcff: in range > > > pcib4: matched entry for 4.2.INTA > > > pcib4: slot 2 INTA hardwired to IRQ 18 > > > em0: port > > > 0xdcc0-0xdcff m > > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device 2.0 on pci4 > > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 > > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 > > > em0: bpf attached > > > em0: Ethernet address: 00:0e:0c:6e:a1:39 > > > em0: [FAST] > > > > Talked about this internally, and the advise here is that the em driver change > > so that only PCI-E adapters can use MSI, this would eliminate the need to > > blacklist in the kernel PCI code. > > It's not em(4) that is the problem, but the system, and I'd rather we fix it > generically rather than in each driver. Maybe we should disable MSI for non-PCIe > systems? Depends what that means, say a system HAS PCI-E, but also a PCI and/or a PCI-X slot will MSI be unavailable in those slots, that's what I would prefer. Jack From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 22:07:48 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F0A16A400; Sat, 20 Jan 2007 22:07:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBB113C44C; Sat, 20 Jan 2007 22:07:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l0KM7f3b003303; Sat, 20 Jan 2007 15:07:47 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45B292AB.7050503@samsco.org> Date: Sat, 20 Jan 2007 15:07:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> <200701201041.10752.jhb@freebsd.org> <2a41acea0701201356u53dbbd94m877d4e46615d0b2f@mail.gmail.com> In-Reply-To: <2a41acea0701201356u53dbbd94m877d4e46615d0b2f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sat, 20 Jan 2007 15:07:47 -0700 (MST) X-Spam-Status: No, score=-1.2 required=3.8 tests=ALL_TRUSTED, MAILTO_TO_SPAM_ADDR autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Mark Atkinson Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:07:49 -0000 Jack Vogel wrote: > On 1/20/07, John Baldwin wrote: >> On Friday 19 January 2007 13:55, Jack Vogel wrote: >> > On 1/19/07, Mark Atkinson wrote: >> > > I upgraded a box to -current yesterday with the following pci card >> in it, >> > > (this is the msi disabled verbose boot below) but upon bootup, any >> heavy >> > > network activity caused watchdog timeouts and resets. Disabling >> msi via >> > > the two tunables fixed the problem. >> > > >> > > What info do you need on this problem? >> > > >> > > found-> vendor=0x8086, dev=0x1076, revid=0x00 >> > > bus=4, slot=2, func=0 >> > > class=02-00-00, hdrtype=0x00, mfdev=0 >> > > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) >> > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), >> maxlat=0x00 (0 ns) >> > > intpin=a, irq=10 >> > > powerspec 2 supports D0 D3 current D0 >> > > MSI supports 1 message, 64 bit >> > > map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled >> > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good >> > > map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled >> > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good >> > > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled >> > > pcib4: requested I/O range 0xdcc0-0xdcff: in range >> > > pcib4: matched entry for 4.2.INTA >> > > pcib4: slot 2 INTA hardwired to IRQ 18 >> > > em0: port >> > > 0xdcc0-0xdcff m >> > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device >> 2.0 on pci4 >> > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 >> > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 >> > > em0: bpf attached >> > > em0: Ethernet address: 00:0e:0c:6e:a1:39 >> > > em0: [FAST] >> > >> > Talked about this internally, and the advise here is that the em >> driver change >> > so that only PCI-E adapters can use MSI, this would eliminate the >> need to >> > blacklist in the kernel PCI code. >> >> It's not em(4) that is the problem, but the system, and I'd rather we >> fix it >> generically rather than in each driver. Maybe we should disable MSI >> for non-PCIe >> systems? > > Depends what that means, say a system HAS PCI-E, but also a PCI and/or > a PCI-X slot will MSI be unavailable in those slots, that's what I would > prefer. > > Jack Are you saying that MSI should only be available to PCIe devices? That will break legitimate PCI-X devices. Scott From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 22:10:15 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E15D16A407 for ; Sat, 20 Jan 2007 22:10:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id B8E3313C457 for ; Sat, 20 Jan 2007 22:10:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so851244wxc for ; Sat, 20 Jan 2007 14:10:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Izla5EW1fIIzXQ/6kg6hq7iYkbPwensSsZvHtmeV41+ZhO7t+2l2n/DChtBNIjAjkvpxx1Z+/T9XXL8qe2QLS3VG+j6ySW+7gflkh8HxbknFkoOIK/Aczm9OL2b9gOH6vMx7EGBlKnia2t6VAzb+QTTt61bqveD7kYJwlxsga/0= Received: by 10.90.94.2 with SMTP id r2mr4646222agb.1169331013835; Sat, 20 Jan 2007 14:10:13 -0800 (PST) Received: by 10.90.74.7 with HTTP; Sat, 20 Jan 2007 14:10:13 -0800 (PST) Message-ID: <2a41acea0701201410m3ce52c0y7942182b9403037d@mail.gmail.com> Date: Sat, 20 Jan 2007 14:10:13 -0800 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <45B292AB.7050503@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701191055u20b91c84tfabb242c9b6815fd@mail.gmail.com> <200701201041.10752.jhb@freebsd.org> <2a41acea0701201356u53dbbd94m877d4e46615d0b2f@mail.gmail.com> <45B292AB.7050503@samsco.org> Cc: freebsd-current@freebsd.org, Mark Atkinson Subject: Re: another msi blacklist candidate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:10:15 -0000 On 1/20/07, Scott Long wrote: > Jack Vogel wrote: > > On 1/20/07, John Baldwin wrote: > >> On Friday 19 January 2007 13:55, Jack Vogel wrote: > >> > On 1/19/07, Mark Atkinson wrote: > >> > > I upgraded a box to -current yesterday with the following pci card > >> in it, > >> > > (this is the msi disabled verbose boot below) but upon bootup, any > >> heavy > >> > > network activity caused watchdog timeouts and resets. Disabling > >> msi via > >> > > the two tunables fixed the problem. > >> > > > >> > > What info do you need on this problem? > >> > > > >> > > found-> vendor=0x8086, dev=0x1076, revid=0x00 > >> > > bus=4, slot=2, func=0 > >> > > class=02-00-00, hdrtype=0x00, mfdev=0 > >> > > cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) > >> > > lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), > >> maxlat=0x00 (0 ns) > >> > > intpin=a, irq=10 > >> > > powerspec 2 supports D0 D3 current D0 > >> > > MSI supports 1 message, 64 bit > >> > > map[10]: type 1, range 32, base 0xdf9c0000, size 17, enabled > >> > > pcib4: requested memory range 0xdf9c0000-0xdf9dffff: good > >> > > map[14]: type 1, range 32, base 0xdf9e0000, size 17, enabled > >> > > pcib4: requested memory range 0xdf9e0000-0xdf9fffff: good > >> > > map[18]: type 4, range 32, base 0xdcc0, size 6, enabled > >> > > pcib4: requested I/O range 0xdcc0-0xdcff: in range > >> > > pcib4: matched entry for 4.2.INTA > >> > > pcib4: slot 2 INTA hardwired to IRQ 18 > >> > > em0: port > >> > > 0xdcc0-0xdcff m > >> > > em 0xdf9c0000-0xdf9dffff,0xdf9e0000-0xdf9fffff irq 18 at device > >> 2.0 on pci4 > >> > > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdf9c0000 > >> > > em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdcc0 > >> > > em0: bpf attached > >> > > em0: Ethernet address: 00:0e:0c:6e:a1:39 > >> > > em0: [FAST] > >> > > >> > Talked about this internally, and the advise here is that the em > >> driver change > >> > so that only PCI-E adapters can use MSI, this would eliminate the > >> need to > >> > blacklist in the kernel PCI code. > >> > >> It's not em(4) that is the problem, but the system, and I'd rather we > >> fix it > >> generically rather than in each driver. Maybe we should disable MSI > >> for non-PCIe > >> systems? > > > > Depends what that means, say a system HAS PCI-E, but also a PCI and/or > > a PCI-X slot will MSI be unavailable in those slots, that's what I would > > prefer. > > > > Jack > > Are you saying that MSI should only be available to PCIe devices? That > will break legitimate PCI-X devices. True, the question is how many of those devices are problematic and need blacklisting anyway? I don't have a feel for this, do you Scott? Jack From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 22:35:20 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7D7116A406 for ; Sat, 20 Jan 2007 22:35:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.freebsd.org (Postfix) with ESMTP id 6E74613C47E for ; Sat, 20 Jan 2007 22:35:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so486207wri for ; Sat, 20 Jan 2007 14:35:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WhU0KIZ4utgKEPQiwip7dcO3x2mccg6I/LFc6ezTxqg5VF5rvAh92YZ7wDR9pDyFGRD60+3C0hvVqmWwS937k4dJrRZRE52ZcJRPf8iz1i7BK7Cp8/OSUtu6/xrcZwXfMKdxxrT3nOWctRrObps6AeV9ly/U2R/+WR2ygYybFrQ= Received: by 10.90.88.13 with SMTP id l13mr4696479agb.1169332517725; Sat, 20 Jan 2007 14:35:17 -0800 (PST) Received: by 10.90.74.7 with HTTP; Sat, 20 Jan 2007 14:35:17 -0800 (PST) Message-ID: <2a41acea0701201435g6f960b40r3cf0552d87ab2bfd@mail.gmail.com> Date: Sat, 20 Jan 2007 14:35:17 -0800 From: "Jack Vogel" To: "Bill Paul" In-Reply-To: <20070120065321.DB61216A405@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0701171258k16b4c6ebuf1d4794b89d0749b@mail.gmail.com> <20070120065321.DB61216A405@hub.freebsd.org> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, jon.otterholm@ide.resurscentrum.se Subject: Re: Lenovo X60 em workaround X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:35:20 -0000 On 1/19/07, Bill Paul wrote: > > > Since this was just seen, and the patch below validated as working I wanted > > to send general email to capture this: > > > > The Lenovo X60 can have issues with long ping times, this is a KNOWN > > hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has > > not been decided on yet. Nevertheless, the patch below will work, but > > I do not want to check it in as its still temporary. > > > > Address questions to me, > > Okay, I have a question. Could you elaborate on just what the problem is? > (I mean, since it's KNOWN and all...) I'm just having a hard time figuring > out what problem could possibly be fixed by setting the RX interrupt > delay timer to a non-zero value (especially since elsewhere in the em(4) > source it says that doing so is a Bad Thing (tm)). saying its known to be a problem doesnt mean its cause is known :) They discovered that setting this eliminated the problem, but we immediately pointed out that this is, as you pointed out, a Bad Thing on other hardware, so the investigation continues, there is always a communication lag on these kind of things, so I dont know if it has been resolved yet or not. I just dont think this patch will become the final way to solve this, but we shall see :) Cheers, Jack From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 22:42:02 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDF5116A401; Sat, 20 Jan 2007 22:42:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 80ED713C467; Sat, 20 Jan 2007 22:42:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id l0KMg1wp038965; Sat, 20 Jan 2007 17:42:01 -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.8/8.13.8) with ESMTP id l0KMg1qa023563; Sat, 20 Jan 2007 17:42:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A457273034; Sat, 20 Jan 2007 17:42:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20070120224201.A457273034@freebsd-current.sentex.ca> Date: Sat, 20 Jan 2007 17:42:01 -0500 (EST) X-Virus-Scanned: ClamAV version devel-20070108, clamav-milter version devel-111206 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 22:42:02 -0000 TB --- 2007-01-20 21:43:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-01-20 21:43:27 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-01-20 21:43:27 - cleaning the object tree TB --- 2007-01-20 21:44:04 - checking out the source tree TB --- 2007-01-20 21:44:04 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2007-01-20 21:44:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2007-01-20 21:52:41 - building world (CFLAGS=-O2 -pipe) TB --- 2007-01-20 21:52:41 - cd /src TB --- 2007-01-20 21:52:41 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 20 21:52:42 UTC 2007 >>> 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 [...] gzip -cn /src/usr.sbin/mountd/exports.5 > exports.5.gz gzip -cn /src/usr.sbin/mountd/netgroup.5 > netgroup.5.gz gzip -cn /src/usr.sbin/mountd/mountd.8 > mountd.8.gz ===> usr.sbin/mount_portalfs (all) cc -O2 -pipe -I/src/usr.sbin/mount_portalfs/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/usr.sbin/mount_portalfs/mount_portalfs.c cc -O2 -pipe -I/src/usr.sbin/mount_portalfs/../../sbin/mount -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/usr.sbin/mount_portalfs/activate.c /src/usr.sbin/mount_portalfs/activate.c: In function `send_reply': /src/usr.sbin/mount_portalfs/activate.c:126: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/mount_portalfs. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-01-20 22:42:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-01-20 22:42:01 - ERROR: failed to build world TB --- 2007-01-20 22:42:01 - tinderbox aborted TB --- 0.59 user 2.18 system 3514.34 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 20 23:05:52 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04F2F16A400 for ; Sat, 20 Jan 2007 23:05:52 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.freebsd.org (Postfix) with ESMTP id AACCC13C471 for ; Sat, 20 Jan 2007 23:05:51 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from [192.168.0.64] (abyss.local [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 62CC962D4B0; Sun, 21 Jan 2007 01:49:45 +0300 (MSK) Message-ID: <45B29C7E.9050608@irbis.net.ru> Date: Sun, 21 Jan 2007 01:49:34 +0300 From: Yuri Pankov User-Agent: Thunderbird 1.5.0.9 (X11/20070116) MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0701192328v4e44515bvcb3adeca8fcae115@mail.gmail.com> <6eb82e0701200015u1cf12019xd2ad65298ba87ead@mail.gmail.com> In-Reply-To: <6eb82e0701200015u1cf12019xd2ad65298ba87ead@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=CE301A55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/2473/Sun Jan 21 00:12:15 2007 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Sun, 21 Jan 2007 01:49:46 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: ncurses update on the way X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 23:05:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rong-en Fan wrote: > On 1/20/07, Rong-en Fan wrote: >> In the next hour, I'm going to import ncurses 5.6 into base. >> There will be a short breakage. I will send out another >> message when it's done. > > It's done. > >> Regards, >> Rong-En Fan Is there a plan to build libncursesw as well? Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFspx+rfDNc84wGlURApiXAJ4/jF8mJUhY5ziGl/d/0hPhLEIA8QCcDjW4 VKFacB5cSMEgbQEaHjVyqfc= =dXqA -----END PGP SIGNATURE-----