From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 00:52:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F301F106566C for ; Sun, 8 Feb 2009 00:52:56 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id CA7178FC18 for ; Sun, 8 Feb 2009 00:52:56 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KEQ00IYK2G2SMC0@mta1.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Sat, 07 Feb 2009 19:52:50 -0500 (EST) Received: from flosoft.no-ip.biz (localhost [IPv6:::1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n180qnmn002435; Sat, 07 Feb 2009 19:52:50 -0500 Date: Sat, 07 Feb 2009 19:52:49 -0500 From: "Aryeh M. Friedman" In-reply-to: <498DE640.4090904@gmail.com> To: freebsd-hackers@freebsd.org Message-id: <498E2CE1.6020606@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <498DE640.4090904@gmail.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090202) Subject: Re: setting up net/cvsup-mirror correctly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 00:52:57 -0000 Aryeh M. Friedman wrote: > I have installed net/cvsup-mirror with all the defaults but when I > attempt to actually run cvsupd I get the following: > > prod# cvsupd & > [1] 99334 > prod# cvsup -g -h localhost /usr/share/examples/cvsup/cvs-supfile > Connected to localhost > 2009.02.07 14:48:28 EST [99334]: +0 aryeh@localhost > (prod.istudentunion.com) [SNAP_16_1h/17.0] > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "src-all" > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "ports-all" > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "doc-all" > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "www" > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "projects-all" > 2009.02.07 14:48:28 EST [99334]: =0 Unknown collection "cvsroot-all" > Server message: Unknown collection "src-all" > Server message: Unknown collection "ports-all" > Server message: Unknown collection "doc-all" > Server message: Unknown collection "www" > Server message: Unknown collection "projects-all" > Server message: Unknown collection "cvsroot-all" > Skipping collection src-all/cvs > Skipping collection ports-all/cvs > Skipping collection doc-all/cvs > Skipping collection www/cvs > Skipping collection projects-all/cvs > Skipping collection cvsroot-all/cvs > Finished successfully > 2009.02.07 14:48:28 EST [99334]: -0 [0Kin+0Kout] Finished successfully > 2009.02.07 14:48:28 EST [99334]: Going down > [1] + Done cvsupd > prod# > > After reading through some examples on the web of how to set cvsupd up > I can not see any difference between my setup and other peoples except > most of the examples on the web use something else then > /usr/local/etc/cvsup as the base dir. Any ideas on what I need to do > to get it working? BTW once I get it going since I have a 20 MB/s > upload on my fios I am going to make this an official > cvsupXXX.us.freebsd.org server (Only one in the NYC metro area I know of) > > > Problem fixed... I am going to file a bug report on it though because cvsup-master.freebsd.org is an inapproriate default upstream for most sites (you need a password) From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 09:21:08 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDFAD1065680 for ; Sun, 8 Feb 2009 09:21:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A90658FC14 for ; Sun, 8 Feb 2009 09:21:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW5Ht-0000VH-D8; Sun, 08 Feb 2009 10:45:13 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org, hackers@freebsd.org In-reply-to: Your message of Fri, 06 Feb 2009 08:32:27 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 10:45:13 +0200 From: Danny Braniss Message-ID: Cc: Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:21:09 -0000 I'm reposting this to hackers, and there is some more info. > Hi, > on 2 different servers, running 7.1-stable + zfs, I get this > error rather frequently: > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from > nfs server sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server > sunfire:/dist > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from > nfs server sunfire:/dist > > in this case the server is running Freebsd-7.0-stable, but I also get it when > the server is a > netapp. > > is there a connection? > > thanks, > danny going through the logs, after it happened again, I got a glimps of this: Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o leading ethernet header (len 0 pkt len 0) Feb 6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not responding, timed out ... Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value for /defaults in hesiod.local Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig#^ZM-^KoM- abase" Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length (2068989523) from nfs server sunfire:/dist which seems to point fingers at bce... danny From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 09:26:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5725C106566C; Sun, 8 Feb 2009 09:26:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BAC948FC08; Sun, 8 Feb 2009 09:26:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <498EA55F.5020904@FreeBSD.org> Date: Sun, 08 Feb 2009 10:26:55 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Omer Faruk Sen References: <75a268720902070000r7dbe758aq60454092fcab0198@mail.gmail.com> In-Reply-To: <75a268720902070000r7dbe758aq60454092fcab0198@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: FreeBSD 6.3/7.1 and Linux disk performance test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:26:58 -0000 Omer Faruk Sen wrote: > as you can see there is a big difference in just simple dd test. Is > there additional steps that I can follow to increase performance? Use a benchmark that matches your actual workload, and then see how things look. I would be surprised if your target workload was "dd" :-) Kris From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 09:31:46 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E53321065672; Sun, 8 Feb 2009 09:31:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEE08FC18; Sun, 8 Feb 2009 09:31:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LW60v-0000zC-B2; Sun, 08 Feb 2009 11:31:45 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Peter Jeremy In-reply-to: <20090208091656.GA31876@test71.vk2pj.dyndns.org> References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> Comments: In-reply-to Peter Jeremy message dated "Sun, 08 Feb 2009 20:16:56 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Feb 2009 11:31:45 +0200 From: Danny Braniss Message-ID: Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 09:31:47 -0000 > > --jI8keyz6grp/JLjh > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On 2009-Feb-08 10:45:13 +0200, Danny Braniss wrote: > >Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o=20 > >leading ethernet header (len 0 pkt len 0) > =2E.. > >Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20 > >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- a= > base" > >Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= > =20 > >(2068989523) from nfs server sunfire:/dist > > > >which seems to point fingers at bce... > > It does rather suggest that bce is not behaving. What happens if you > turn off checksum off-loading? This should make the kernel drop the > corrupt packets instead of trying to process them. If practical, you > could also try (temporarily) plugging in a different NIC. > I have, and now it's a matter of waiting... Q: with rxcsum on, and a bad checksum packet is received, is it dropped by the NIC? if not, then it somewhat explains the behaviour changing the nic is tough, but if needed will be done. danny > Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 11:23:05 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757B8106566C; Sun, 8 Feb 2009 11:23:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 18E3B8FC16; Sun, 8 Feb 2009 11:23:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LW7kc-000Pvh-K9; Sun, 08 Feb 2009 13:23:02 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n18BMxvG043700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 13:22:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n18BMx5D073851; Sun, 8 Feb 2009 13:22:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n18BMxne073850; Sun, 8 Feb 2009 13:22:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Feb 2009 13:22:59 +0200 From: Kostik Belousov To: Danny Braniss Message-ID: <20090208112259.GW9427@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+rRWuC8ZLvVekNoN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LW7kc-000Pvh-K9 d21d0ec89b31b8a031564676a3620c67 X-Terabit: YES Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 11:23:05 -0000 --+rRWuC8ZLvVekNoN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 08, 2009 at 10:45:13AM +0200, Danny Braniss wrote: > I'm reposting this to hackers, and there is some more info. >=20 > > Hi, > > on 2 different servers, running 7.1-stable + zfs, I get this > > error rather frequently: > >=20 > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) = from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1667787057)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (976040755) = from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1953459488)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1348825156)= from=20 > > nfs server sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs= server=20 > > sunfire:/dist > > Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1647208041)= from=20 > > nfs server sunfire:/dist > >=20 > > in this case the server is running Freebsd-7.0-stable, but I also get i= t when=20 > > the server is a > > netapp. > >=20 > > is there a connection? > >=20 > > thanks, > > danny >=20 > going through the logs, after it happened again, I got a glimps of this: >=20 > Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o= =20 > leading ethernet header (len 0 pkt len 0) > Feb 6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not= =20 > responding, timed out > ... > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single valu= e for=20 > /defaults in hesiod.local > Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in= =20 > "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- = abase" > Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= =20 > (2068989523) from nfs server sunfire:/dist >=20 > which seems to point fingers at bce... bce(4) is broken in stable, your best option is to revert to the driver in releng 7.1. --+rRWuC8ZLvVekNoN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmOwJIACgkQC3+MBN1Mb4gqewCfXNYj8DTBWnqWlXiPpw4y5IFz 3EcAnjnvq1Lwt9hZia6JhvuAcT2byaVw =HaQ+ -----END PGP SIGNATURE----- --+rRWuC8ZLvVekNoN-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 12:11:47 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450E51065673; Sun, 8 Feb 2009 12:11:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E010D8FC08; Sun, 8 Feb 2009 12:11:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LW8Vl-0002ZX-LK; Sun, 08 Feb 2009 14:11:45 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n18CBgmi048792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 14:11:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n18CBgq9076765; Sun, 8 Feb 2009 14:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n18CBgf0076762; Sun, 8 Feb 2009 14:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Feb 2009 14:11:42 +0200 From: Kostik Belousov To: stable@freebsd.org, hackers@freebsd.org Message-ID: <20090208121142.GX9427@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zll6mx50Q8J7qlLQ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LW8Vl-0002ZX-LK 44c56a764e0f31fb4b1e982e561e474f X-Terabit: YES Cc: Subject: Possible VFS KPI and KBI breakage on stable/7 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:11:47 -0000 --Zll6mx50Q8J7qlLQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There are three sets of changes that would benefit stable/7. Namely, there are 1. Improvements for the UFS unmount or rw->ro remount, that perform suspension during the operation. The changes depend on the the suspension mechanism path, that introduced the suspension owner, and added new VFS OP into the mount method table. This might also fix the hangs with gjournal or gjournal together with snapshots experienced by some users. Since the only real consumer of the suspension is UFS, I believe that MFC would have quite low impact, if any. Corresponding revision is 183073. 2. The openat(2) and similar syscalls. The new ZFS requires openat() functionality. We have to change struct nameidata to merge NDINIT_ATVP(). All modules using namei() need to be recompiled. 3. The Marcus' work on vn_fullpath() support for synthetic filesystems introduces new VOP, vop_vptocnp. This would allow procstat(1) to work on devfs and pseudofs vnodes. As I understand, this would also improve Gnome experience on FreeBSD. All fs modules need to be recompiled. There was one very magisterial voice that objected against KBI breakage on stable branch in principle. In my opinion, the benefits of the bug fixes and functionality improvements with the proposed merges are much greater then inconvenience of the need to recompile out-of-tree fs modules. Changes were discussed with re@ to some extent. In case there is vocal objection against the merge, I would abstain from doing this. --Zll6mx50Q8J7qlLQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmOy/0ACgkQC3+MBN1Mb4gcogCfSUjXSk3CsUNuDcr1eMvOB96O ER4AoPYtlw+M3VN8c21AxyVG6Vq0ZQck =aEg3 -----END PGP SIGNATURE----- --Zll6mx50Q8J7qlLQ-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 12:17:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 983B21065673; Sun, 8 Feb 2009 12:17:47 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16F2D8FC13; Sun, 8 Feb 2009 12:17:46 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n18CHZgc014127; Sun, 8 Feb 2009 13:17:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n18CHYlx014125; Sun, 8 Feb 2009 13:17:34 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200902081217.n18CHYlx014125@lurza.secnetix.de> To: matt@chronos.org.uk (Matt Dawson) Date: Sun, 8 Feb 2009 13:17:34 +0100 (CET) In-Reply-To: <200902081001.04075.matt@chronos.org.uk> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sun, 08 Feb 2009 13:17:35 +0100 (CET) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:17:48 -0000 Matt Dawson wrote: > On Saturday 07 February 2009 18:59:43 Oliver Fromme wrote: > > In fact I have prepared a theme with beastie; here's > > a screen shot (preliminary): > > > > http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png > > Perfect. Clean, logical, concise, the three words I associate above all with > FreeBSD. I would change all machines' loaders to this in a heartbeat, although > others may have different ideas, which is where the space hopper comes in, I > suppose. Nothing against the horned ball and your variant of the new graphics > looks very neat and clean, but I'm used to having Beastie around. For some > reason, this strikes the correct balance for me between nice graphics and too > much "bling." My personal tastes only, naturally. > > That screenshot looks very professional. Well done, Oliver. Any chance > of rolling another tarball with that theme for we traditionalists? Please? > Good news: I don't have to roll another tarball for that, because this is quite easy to configure. Please download the existing tarball and follow the instructions that I posted. Please verify that it works. Then download the background image that contains beastie: http://www.secnetix.de/olli/FreeBSD/vloader/background/beastie.pcx Create a directory /boot/themes/beastie and save the image as beastie.pcx in that directory. Then create a text file themes.conf in the same directory, containing these lines: theme_background="/boot/themes/beastie/beastie.pcx" theme_font="/boot/themes/default/stdfont" theme_fgcolor="0 0 0" # black theme_bgcolor="255 255 255" # white theme_litcolor="255 64 32" # bright red theme_dimcolor="64 64 128" # dark bluish grey theme_options_xy="17 170" theme_actions_xy="17 281" Finally, change the beastie_theme line in /boot/loader.conf like this: beastie_theme="/boot/themes/beastie/theme.conf" Done. Of course, you can also use your own image if you want to create one. Just make sure it's 640 x 480 pixels at 4 bit depth (16 colors maximum). I recommend to use ppmtopcx (from ports/graphics/netpbm), because I have used this extensively for testing with my PCX decoder. Also note that there should be appropriate palette entries for the text (e.g. black and white). The code will try to use the closest possible palette entry if there is no exact match for the given RGB values. There's ONE IMPORTANT THING I have to say: I cannot take credit for any of the artwork. I am not an artist. All of the graphics images where taken from the FreeBSD website. I only scaled and arranged it a little bit, adapted the palette etc. The only thing I created myself is the proportional font; the "source code" is here: http://www.secnetix.de/olli/FreeBSD/vloader/stdfont.txt Modifying the font or creating a completely new font is also very easy. There's a tool that "compiles" the text source code (like the one above) to binary format. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Software gets slower faster than hardware gets faster." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 12:39:55 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD6F106564A; Sun, 8 Feb 2009 12:39:55 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 021938FC0A; Sun, 8 Feb 2009 12:39:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n18CdnRe015299; Sun, 8 Feb 2009 13:39:49 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n18CdnOk015298; Sun, 8 Feb 2009 13:39:49 +0100 (CET) (envelope-from olli) Date: Sun, 8 Feb 2009 13:39:49 +0100 (CET) Message-Id: <200902081239.n18CdnOk015298@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, paul@fletchermoorland.co.uk In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sun, 08 Feb 2009 13:39:52 +0100 (CET) Cc: Subject: Re: ZFS and Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:39:56 -0000 Paul Wootton wrote: > Hi Oliver, > > This doesn?t work for me. > > I am booting off a ZFS mirror with GPT partitions (built from current on an > amd64). I'm sorry, I've compiled this loader binary with the default options, which does not include ZFS support. > Is there any change of a version of gloader but with ZFS support? I'll put it on my to-do list. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Software gets slower faster than hardware gets faster." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 12:52:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB857106564A; Sun, 8 Feb 2009 12:52:53 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 422388FC21; Sun, 8 Feb 2009 12:52:53 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n18Cqh0h016156; Sun, 8 Feb 2009 13:52:44 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n18CqhZf016155; Sun, 8 Feb 2009 13:52:43 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200902081252.n18CqhZf016155@lurza.secnetix.de> To: mwm@mired.org (Mike Meyer) Date: Sun, 8 Feb 2009 13:52:43 +0100 (CET) In-Reply-To: <20090208073927.77e2c829@bhuda.mired.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sun, 08 Feb 2009 13:52:44 +0100 (CET) Cc: freebsd-hackers@freebsd.org, Matt Dawson , freebsd-current@freebsd.org Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:52:54 -0000 Mike Meyer wrote: > I'm curious - is there a reason that the numbers from the old screen > have turned into function keys on this one? No. That screen shot is an old one. In the current code, the number keys are used as usual, no function keys. In fact, it is not possible to use function keys from the FORTH code without resorting to dirty hacks. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Share your knowledge. It is a way to achieve immortality." -- The Dalai Lama From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 12:39:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E3CE1065675; Sun, 8 Feb 2009 12:39:58 +0000 (UTC) (envelope-from matt@chronos.org.uk) Received: from chronos.org.uk (chronos-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:12b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 739298FC16; Sun, 8 Feb 2009 12:39:57 +0000 (UTC) (envelope-from matt@chronos.org.uk) Received: from workstation1.localnet (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.3/8.14.3) with ESMTP id n18CdsOL022222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 12:39:54 GMT (envelope-from matt@chronos.org.uk) X-DKIM: Sendmail DKIM Filter v2.8.1 chronos.org.uk n18CdsOL022222 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1234096796; bh=uu4zSGdhdR9wh/EFjOxiP/JBtzXvUsS83Fawe42+pI0=; h=From:To:Subject:Date:Cc:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=lWMANPBAtoJWZ+01l+rcORaQtbbdWnZrHaMQQoUpr33Bi/Kwcu7/3Mst+PD6NyJ3Z ntOZF4yKSVuP3fW9lWTmd6nnapaLL20t1fNCO5teo0IAQXJBbSGYqjM8XLQSlAhqU5 kS5w2yR9Z7ka59E8FNCjUqCbLhppbJRPdBWrE2CM= From: Matt Dawson To: Oliver Fromme Date: Sun, 8 Feb 2009 12:39:53 +0000 User-Agent: KMail/1.10.4 (FreeBSD/7.1-STABLE; KDE/4.1.4; amd64; ; ) References: <200902081217.n18CHYlx014125@lurza.secnetix.de> In-Reply-To: <200902081217.n18CHYlx014125@lurza.secnetix.de> X-Face: Uq{{&_!oO{M&ydj?-f%{D]bN7/|/]a+utod35[+IyH#R>F~YPffK,=?utf-8?q?=25=60=7D=25=0A?=FTMbmzo,]0X3K:N&{h7],FI{?EkORzB; f:V3"vKXsUNw5Yh`}ef4MZ*a4,=?utf-8?q?ObuJ=5F=26=5B1S=27zP=5CK0wcKZP=0A?==?utf-8?q?_=60=23L=25=5Dq*OUPQ-4T=3FHZ=7EAKX0=7D3W=25o=3DP?= X-Spam-Status: No, score=-2.1 required=3.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on central.local.chronos.org.uk X-Virus-Scanned: ClamAV 0.94.2/8963/Sat Feb 7 05:53:02 2009 on central.local.chronos.org.uk X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (chronos.org.uk [IPv6:2001:470:1f09:12b::1]); Sun, 08 Feb 2009 12:39:56 +0000 (GMT) X-Mailman-Approved-At: Sun, 08 Feb 2009 12:56:37 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 12:39:58 -0000 On Sunday 08 February 2009 12:17:34 Oliver Fromme wrote: > http://www.secnetix.de/olli/FreeBSD/vloader/background/beastie.pcx > > Create a directory /boot/themes/beastie and save the image > as beastie.pcx in that directory. =A0Then create a text file > themes.conf in the same directory, containing these lines: > > theme_background=3D"/boot/themes/beastie/beastie.pcx" > theme_font=3D"/boot/themes/default/stdfont" > theme_fgcolor=3D"0 0 0" =A0 =A0 =A0 =A0 =A0 # black > theme_bgcolor=3D"255 255 255" =A0 =A0 # white > theme_litcolor=3D"255 64 32" =A0 =A0 =A0# bright red > theme_dimcolor=3D"64 64 128" =A0 =A0 =A0# dark bluish grey > theme_options_xy=3D"17 170" > theme_actions_xy=3D"17 281" > > Finally, change the beastie_theme line in /boot/loader.conf > like this: > > beastie_theme=3D"/boot/themes/beastie/theme.conf" > > Done. =2E..and it is. Thanks, Oliver! =2D-=20 Matt Dawson MTD15-RIPE matt@chronos.org.uk From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 13:06:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6961065672 for ; Sun, 8 Feb 2009 13:06:49 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (two.mired.org [74.143.213.43]) by mx1.freebsd.org (Postfix) with ESMTP id 3194C8FC1B for ; Sun, 8 Feb 2009 13:06:49 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 72603 invoked by uid 1001); 8 Feb 2009 07:39:28 -0500 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda (tmda-ofmipd) with ESMTP; Sun, 08 Feb 2009 07:39:28 -0500 Date: Sun, 8 Feb 2009 07:39:27 -0500 To: Oliver Fromme Message-ID: <20090208073927.77e2c829@bhuda.mired.org> In-Reply-To: <200902081217.n18CHYlx014125@lurza.secnetix.de> References: <200902081001.04075.matt@chronos.org.uk> <200902081217.n18CHYlx014125@lurza.secnetix.de> Organization: Meyer Consulting X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Matt Dawson , freebsd-current@freebsd.org Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:06:50 -0000 I'm curious - is there a reason that the numbers from the old screen have turned into function keys on this one? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 13:39:24 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7315106578B; Sun, 8 Feb 2009 13:39:24 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 565958FC19; Sun, 8 Feb 2009 13:39:23 +0000 (UTC) (envelope-from peter@vk2pj.dyndns.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n189HRv8015816; Sun, 8 Feb 2009 20:17:29 +1100 Received: from test71.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n189Gv6d006676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 20:16:58 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from test71.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by test71.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n189GuDa064604; Sun, 8 Feb 2009 20:16:56 +1100 (EST) (envelope-from peter@test71.vk2pj.dyndns.org) Received: (from peter@localhost) by test71.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n189GuxW064603; Sun, 8 Feb 2009 20:16:56 +1100 (EST) (envelope-from peter) Date: Sun, 8 Feb 2009 20:16:56 +1100 From: Peter Jeremy To: Danny Braniss Message-ID: <20090208091656.GA31876@test71.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Sun, 08 Feb 2009 15:51:46 +0000 Cc: hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:39:25 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Feb-08 10:45:13 +0200, Danny Braniss wrote: >Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o=20 >leading ethernet header (len 0 pkt len 0) =2E.. >Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20 >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM-^KoM- a= base" >Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length= =20 >(2068989523) from nfs server sunfire:/dist > >which seems to point fingers at bce... It does rather suggest that bce is not behaving. What happens if you turn off checksum off-loading? This should make the kernel drop the corrupt packets instead of trying to process them. If practical, you could also try (temporarily) plugging in a different NIC. --=20 Peter Jeremy --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmOowgACgkQ/opHv/APuIezPgCZAfCn11OW1g/XoLQ7O0NXfWNe Re4AoIij1aRiYCYM+YTXlg01ZPtDrUVa =Qm+c -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 04:09:32 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54861065674; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 484C98FC19; Mon, 9 Feb 2009 04:09:32 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.0.7.197] (r74-193-77-79.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.77.79]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id n193ImYQ045191; Sun, 8 Feb 2009 21:18:49 -0600 (CST) (envelope-from anderson@freebsd.org) Message-Id: <205598DD-B746-4236-9140-855811BAE21C@freebsd.org> From: Eric Anderson To: Danny Braniss In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Feb 2009 21:47:01 -0600 References: <20090208091656.GA31876@test71.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94.1/8966/Sun Feb 8 17:43:40 2009 on ns.trinitel.com X-Virus-Status: Clean X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ns.trinitel.com Cc: Ross Dickey , Peter Jeremy , hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: impossible packet length ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:09:34 -0000 On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote: >> >> --jI8keyz6grp/JLjh >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On 2009-Feb-08 10:45:13 +0200, Danny Braniss >> wrote: >>> Feb 6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard >>> frame w/o=20 >>> leading ethernet header (len 0 pkt len 0) >> =2E.. >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ >>> sequence in=20 >>> "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig#^ZM- >>> ^KoM- a= >> base" >>> Feb 6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet >>> length= >> =20 >>> (2068989523) from nfs server sunfire:/dist >>> >>> which seems to point fingers at bce... >> >> It does rather suggest that bce is not behaving. What happens if you >> turn off checksum off-loading? This should make the kernel drop the >> corrupt packets instead of trying to process them. If practical, you >> could also try (temporarily) plugging in a different NIC. >> > I have, and now it's a matter of waiting... > Q: with rxcsum on, and a bad checksum packet is received, is it > dropped by the NIC? if not, then it somewhat explains the behaviour > > changing the nic is tough, but if needed will be done. > danny > >> Peter Jeremy We were hitting this quite a bit (also bce), and updated to a recent 7- branch and it seems to be behaving better for now. Running 12 days so far (which is better than what we had been seeing). Eric From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 22:09:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3265F106566B for ; Mon, 9 Feb 2009 22:09:17 +0000 (UTC) (envelope-from davidcollins001@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id A94058FC17 for ; Mon, 9 Feb 2009 22:09:16 +0000 (UTC) (envelope-from davidcollins001@gmail.com) Received: by fk-out-0910.google.com with SMTP id f40so1734714fka.11 for ; Mon, 09 Feb 2009 14:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Tq7PcM+Ka9PXwDrwuovq8HP8HhkRwefUzIgIUGclgzo=; b=HGC5wiWN0stgpAKWHT5nXyqnzqaK7uv/+RxAFJp3LQRTQPWVLeuMjNCFnNL658zPcW NIlwCB9wKS8Sn/nMOYk/8P05TAzQM+M7sKwqKxbbVii1Df9FOtwEgPfWzjIJdkFI4jlY Cvearp8aXSeFVqvZE0sVSPfMmKdUn+oc9/r54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=osClSspncrE260jHvzAzNvE0soF+TtsKb1TyZFPnu4HTzF4gIeviLvew2YUkCpvynA 82H23//y52tbDh/qNrOU8dDCBFYHkTOYa/nigOIeFpWh9Bsv/UbQ8aXOlNpzjtTKGH/t 02n8ebC78ezIxXDZTGNsNYr6uC4mmNIUdOXQ0= MIME-Version: 1.0 Received: by 10.223.110.3 with SMTP id l3mr1875768fap.49.1234216126431; Mon, 09 Feb 2009 13:48:46 -0800 (PST) In-Reply-To: <20090209213249.GA4401@melon.esperance-linux.co.uk> References: <20090207075521.GA93084@melon.esperance-linux.co.uk> <20090208203553.GA99661@melon.esperance-linux.co.uk> <1b30fd140902081424p1d75e304y9f4ef9f9b472328c@mail.gmail.com> <20090209055634.GA2116@melon.esperance-linux.co.uk> <1b30fd140902082330m21b4aecyf99cb83a080e972a@mail.gmail.com> <20090209083338.GA2666@melon.esperance-linux.co.uk> <1b30fd140902090108m292ef929tdce1ce2c946ead6b@mail.gmail.com> <20090209093505.GA2835@melon.esperance-linux.co.uk> <1b30fd140902091152x17ed90e5sf915b361927067e@mail.gmail.com> <20090209213249.GA4401@melon.esperance-linux.co.uk> Date: Mon, 9 Feb 2009 21:48:46 +0000 Message-ID: <1b30fd140902091348j56068545hb90905eb87050acc@mail.gmail.com> From: David Collins To: Frank Shute , David Collins , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: broken ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidcollins001@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 22:09:17 -0000 Thank you for your input. I feel like this problem is too far over my head to be able to give adequate enough debugging. I am not against any alternative methods of resolving this (even removing and reinstalling ports) rather than fixing, I just don't want to have to jump into sysinstall or reinstall because i believe that is a soluion. David On 09/02/2009, Frank Shute wrote: > On Mon, Feb 09, 2009 at 07:52:58PM +0000, David Collins wrote: >> >> > Then you should be able to build rtorrent. >> > >> > Then what I'd do is deinstall gcc42: >> > >> > # pkg_deinstall -f gcc-4.2.5_20080702 >> > >> > Comment out the CC line in /etc/make.conf & run ldconfig: >> > >> > # /etc/rc.d/ldconfig start >> > >> > and hopefully your system is then back to normal. >> >> I tried all this and rtorrent would still not install, with the same >> error at configure. I was however able to pkg_deinstall the gcc it >> installed. That didn't solve any problems though. >> >> I feel that it might be easier to focus on the following compiling >> problem that still exists: >> >> viper:~$ gcc -o hello hello.c >> /usr/bin/ld: cannot find -lgcc_s > > What this is telling you is the linker, ld(1), can't find the gcc_s > library. ldconfig(8) tells ld where to look. > > What does: > > $ ldconfig -r | grep gcc_s > > tell you now that you've removed that compiler? You should get > something like: > > $ ldconfig -r | grep gcc_s > 30:-lgcc_s.1 => /lib/libgcc_s.so.1 > > i.e. It's looking in the system libs. > > If it still tells you that the lib is under /usr/local/lib, then > there's your problem & you have to regenerate a fresh hints file, I > think. > > The problem is that I've never (IIRC) installed a compiler from > ports & I don't know how it screws with the compiler toolchain & hence > how to put it right. Hence, I've cc'd this to hackers@ in the hope that > someone who is more familiar with the toolchain can give advice. > > > Regards, > > -- > > Frank > > > Contact info: http://www.shute.org.uk/misc/contact.html > > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 21:48:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 206981065674 for ; Mon, 9 Feb 2009 21:48:11 +0000 (UTC) (envelope-from frank@esperance-linux.co.uk) Received: from mailout.zetnet.co.uk (mailout.zetnet.co.uk [194.247.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEA08FC24 for ; Mon, 9 Feb 2009 21:48:10 +0000 (UTC) (envelope-from frank@esperance-linux.co.uk) Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 4.63) (envelope-from ) id 1LWdkN-0008Gq-Cz; Mon, 09 Feb 2009 21:32:55 +0000 Received: from melon.esperance-linux.co.uk (54-144.adsl.zetnet.co.uk [194.247.54.144]) by zetnet.co.uk (8.14.1/8.14.1/Debian-9) with ESMTP id n19LWsq3026574; Mon, 9 Feb 2009 21:32:55 GMT Received: by melon.esperance-linux.co.uk (Postfix, from userid 1001) id 8502FFCA4DB; Mon, 9 Feb 2009 21:32:49 +0000 (GMT) Date: Mon, 9 Feb 2009 21:32:49 +0000 From: Frank Shute To: David Collins Message-ID: <20090209213249.GA4401@melon.esperance-linux.co.uk> Mail-Followup-To: David Collins , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <20090207075521.GA93084@melon.esperance-linux.co.uk> <1b30fd140902080816v7dfb8bb6g6f3c9a3d162f48c0@mail.gmail.com> <20090208203553.GA99661@melon.esperance-linux.co.uk> <1b30fd140902081424p1d75e304y9f4ef9f9b472328c@mail.gmail.com> <20090209055634.GA2116@melon.esperance-linux.co.uk> <1b30fd140902082330m21b4aecyf99cb83a080e972a@mail.gmail.com> <20090209083338.GA2666@melon.esperance-linux.co.uk> <1b30fd140902090108m292ef929tdce1ce2c946ead6b@mail.gmail.com> <20090209093505.GA2835@melon.esperance-linux.co.uk> <1b30fd140902091152x17ed90e5sf915b361927067e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b30fd140902091152x17ed90e5sf915b361927067e@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Face: *}~{PHnDTzvXPe'wl_-f%!@+r5; VLhb':*DsX%wEOPg\fDrXWQJf|2\,92"DdS%63t*BHDyQ|OWo@Gfjcd72eaN!4%NE{0]p)ihQ1MyFNtWL X-Operating-System: FreeBSD 6.4-RELEASE-p2 i386 X-Organisation: 'http://www.shute.org.uk/' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.1.7 (zetnet.co.uk [194.247.46.1]); Mon, 09 Feb 2009 21:32:55 +0000 (GMT) X-Mailman-Approved-At: Mon, 09 Feb 2009 22:44:47 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: broken ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Shute List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:48:11 -0000 On Mon, Feb 09, 2009 at 07:52:58PM +0000, David Collins wrote: > > > Then you should be able to build rtorrent. > > > > Then what I'd do is deinstall gcc42: > > > > # pkg_deinstall -f gcc-4.2.5_20080702 > > > > Comment out the CC line in /etc/make.conf & run ldconfig: > > > > # /etc/rc.d/ldconfig start > > > > and hopefully your system is then back to normal. > > I tried all this and rtorrent would still not install, with the same > error at configure. I was however able to pkg_deinstall the gcc it > installed. That didn't solve any problems though. > > I feel that it might be easier to focus on the following compiling > problem that still exists: > > viper:~$ gcc -o hello hello.c > /usr/bin/ld: cannot find -lgcc_s What this is telling you is the linker, ld(1), can't find the gcc_s library. ldconfig(8) tells ld where to look. What does: $ ldconfig -r | grep gcc_s tell you now that you've removed that compiler? You should get something like: $ ldconfig -r | grep gcc_s 30:-lgcc_s.1 => /lib/libgcc_s.so.1 i.e. It's looking in the system libs. If it still tells you that the lib is under /usr/local/lib, then there's your problem & you have to regenerate a fresh hints file, I think. The problem is that I've never (IIRC) installed a compiler from ports & I don't know how it screws with the compiler toolchain & hence how to put it right. Hence, I've cc'd this to hackers@ in the hope that someone who is more familiar with the toolchain can give advice. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 22:59:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A2F106567C for ; Mon, 9 Feb 2009 22:59:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 076868FC16 for ; Mon, 9 Feb 2009 22:59:22 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from mail1.rawbw.com (mail1.rawbw.com [198.144.192.43]) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n19MagfL072747; Mon, 9 Feb 2009 14:36:42 -0800 (PST) Received: from c-67-188-87-159.hsd1.ca.comcast.net (c-67-188-87-159.hsd1.ca.comcast.net [67.188.87.159]) by webmail.rawbw.com (Horde Framework) with HTTP; Mon, 09 Feb 2009 14:36:42 -0800 Message-ID: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> Date: Mon, 09 Feb 2009 14:36:42 -0800 From: Yuri To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2.1-RC1) Subject: How to troubleshoot why ath0 can't connect to a passwordless wireless network? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 22:59:24 -0000 I have a several wireless networks without password that my linux box easily connects to. On FreeBSD 'ifconfig ath0 up scan' command shows it. 'ifconfig ath0 ssid up' brings interface to 'associated' state. But dhclient fails to set it up. I have another device on the same system: ral0. It sometimes connects to these networks ok, sometimes has the same problem. What can I do to understand what may be a problem with ath0 in my case? I tried to use tcpdump. It shows outbound DHCP packets and nothing is inbound. I asked similar question here before, somebody asked me to downgrade atheros driver to one particular lower version. But this didn't help. Relevant dmesg lines are: ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5216, RF5111, RF5112, RF2413, RF5413, RF2133) ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on pci0 ath0: mac 7.8 phy 4.5 radio 5.6 I use 71-PRERELEASE Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 11:42:06 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFA5106566B for ; Tue, 10 Feb 2009 11:42:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 814C68FC0C for ; Tue, 10 Feb 2009 11:42:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA01162 for ; Tue, 10 Feb 2009 13:42:03 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4991680A.5010905@icyb.net.ua> Date: Tue, 10 Feb 2009 13:42:02 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: superio and "shared" io port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 11:42:06 -0000 Here I am with Super I/O question again. There is a certain Super I/O that is configured to use the same port for entering/exiting configuration mode as the one that is used by fdc in the same Super I/O. This is port 0x3f0. I guess the hardware works by examining a value written to this port and forwarding non-magic accesses to the fdc. I wonder what is the best way to handle this double-use of an io port with newbus isa code. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 14:42:11 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B6D1065672 for ; Tue, 10 Feb 2009 14:42:11 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6B98FC16 for ; Tue, 10 Feb 2009 14:42:11 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (HPooka@thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id n1AEg9Ac039535; Tue, 10 Feb 2009 08:42:09 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Tue, 10 Feb 2009 08:42:09 -0600 (CST) From: "Sean C. Farley" To: Yuri In-Reply-To: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> Message-ID: References: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: How to troubleshoot why ath0 can't connect to a passwordless wireless network? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 14:42:11 -0000 On Mon, 9 Feb 2009, Yuri wrote: > I have a several wireless networks without password that my linux box > easily connects to. What version of wpa_supplicant does the Linux box run? > On FreeBSD 'ifconfig ath0 up scan' command shows it. 'ifconfig ath0 > ssid up' brings interface to 'associated' state. But > dhclient fails to set it up. > > I have another device on the same system: ral0. It sometimes connects > to these networks ok, sometimes has the same problem. > > What can I do to understand what may be a problem with ath0 in my > case? > > I tried to use tcpdump. It shows outbound DHCP packets and nothing is > inbound. > > I asked similar question here before, somebody asked me to downgrade > atheros driver to one particular lower version. But this didn't help. > > Relevant dmesg lines are: > ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5216, RF5111, RF5112, RF2413, > RF5413, RF2133) > ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on pci0 > ath0: mac 7.8 phy 4.5 radio 5.6 I had a lot of trouble with ath(4) and my work's wireless network (Aruba Networks based). After patching wpa_supplicant from 0.5.10 to 0.5.11, everything has worked well. Before, it would associate, yet DHCP would not work. Sam Leffler (sam@) has since committed it to CURRENT. I still have the original patch to RELENG_7[1] that the CURRENT patch was based upon. It is a bit old, yet I think it may still apply at least for the most part. Sean 1. http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch -- scf@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 16:39:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CC710656C7 for ; Tue, 10 Feb 2009 16:39:19 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 175528FC4A for ; Tue, 10 Feb 2009 16:39:18 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1AGdHjQ027527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 08:39:17 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4991ADB5.9050803@freebsd.org> Date: Tue, 10 Feb 2009 08:39:17 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Yuri References: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> In-Reply-To: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org Subject: Re: How to troubleshoot why ath0 can't connect to a passwordless wireless network? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 16:39:28 -0000 Yuri wrote: > I have a several wireless networks without password that my linux box > easily connects to. > > On FreeBSD 'ifconfig ath0 up scan' command shows it. 'ifconfig ath0 > ssid up' brings interface to 'associated' state. But > dhclient fails to set it up. > > I have another device on the same system: ral0. It sometimes connects > to these networks ok, sometimes has the same problem. > > What can I do to understand what may be a problem with ath0 in my case? > > I tried to use tcpdump. It shows outbound DHCP packets and nothing is > inbound. > > I asked similar question here before, somebody asked me to downgrade > atheros driver to one particular lower version. But this didn't help. > > Relevant dmesg lines are: > ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5216, RF5111, RF5112, > RF2413, RF5413, RF2133) > ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on > pci0 > ath0: mac 7.8 phy 4.5 radio 5.6 > > I use 71-PRERELEASE You seem to say your network is open (no security). If not you need to show your network configuration. wlanstats shows statistics collected by the 802.11 layer. athstats show stats collected by the ath driver. Both are important tools for diagnosing problems. tcpdump can be used to tap traffic at 3 layers: 802.3, 802.11, and driver. It can be used to identify where packets are lost in the hierarchy (if at all). Assuming packets are going out but not coming back you can sniff from a 3rd station to look for traffic in the air but not received. Given how little info you posted it's virtually impossible to advise you what is wrong. When in doubt c&p real output; describing a problem often causes useful info to be left out. BTW hal version 0.9.30.13 was a test build; RELENG_7 has 0.9.20.3 and HEAD has source code for a much newer version. Sam From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 19:21:22 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7578C106566C for ; Tue, 10 Feb 2009 19:21:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 90C558FC17 for ; Tue, 10 Feb 2009 19:21:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA15765 for ; Tue, 10 Feb 2009 21:21:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4991D3AF.1070001@icyb.net.ua> Date: Tue, 10 Feb 2009 21:21:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:21:22 -0000 I've detected so far several postings on the lists where people ask about such a small nits of having c++ kernel code that some people already have some code in [subset of] c++ working kernel. I wonder if there is any howto about that or maybe somebody is willing to share his experience. What interests me the most: 1. what subset of c++ is used 2. what compilation options/tricks are used 3. how much of run-time support had to be added to kernel (and if that's code is available) 4. what else had to be changed in kernel code 5. so, how is it? :-) I think that I am not the only with such interest. P.S. no, I am not interested in re-writing the whole kernel in c++ or any discussion on that topic, I am interested in a small controlled injection. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 19:25:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA6951065676 for ; Tue, 10 Feb 2009 19:25:55 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9123D8FC12 for ; Tue, 10 Feb 2009 19:25:55 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from mail1.rawbw.com (mail1.rawbw.com [198.144.192.43]) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n1AJPsEC092836; Tue, 10 Feb 2009 11:25:54 -0800 (PST) Received: from c-67-188-87-159.hsd1.ca.comcast.net (c-67-188-87-159.hsd1.ca.comcast.net [67.188.87.159]) by webmail.rawbw.com (Horde Framework) with HTTP; Tue, 10 Feb 2009 11:25:54 -0800 Message-ID: <20090210112554.15896t24mpahwggs@webmail.rawbw.com> Date: Tue, 10 Feb 2009 11:25:54 -0800 From: Yuri To: "Sam Leffler" References: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> <4991ADB5.9050803@freebsd.org> In-Reply-To: <4991ADB5.9050803@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2.1-RC1) Cc: freebsd-hackers@freebsd.org Subject: Re: How to troubleshoot why ath0 can't connect to a passwordless wireless network? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 19:25:56 -0000 Quoting "Sam Leffler" : > You seem to say your network is open (no security). If not you need =20 > to show your network configuration. That's right, network is open (no security). > tcpdump can be used to tap traffic at 3 layers: 802.3, 802.11, and =20 > driver. It can be used to identify where packets are lost in the =20 > hierarchy (if at all). 'tcpdump -vv -i ath0' shows nothing when I run 'dhclient ath0' or 'dhcping -s 255.255.255.255'. dhclient always fails, dhcping says "no answer". But tcpdump shows traffic between other hosts on the same network. > Assuming packets are going out but not coming back you can sniff =20 > from a 3rd station to look for traffic in the air but not received. No, now packets don't seem to go out at all. I said before that packets went out when interface in fact was in 'monitor' mode. > Given how little info you posted it's virtually impossible to advise =20 > you what is wrong. When in doubt c&p real output; describing a =20 > problem often causes useful info to be left out. There is no "real output" from tcpdump, this is a problem. How to find out for example why 'sendto' call from dhcping doesn't =20 result in any packets on ath0 interface which is 'UP' and 'associated'? I used this same system to connect to other open WiFi networks without =20 the problem. So it seems to be network-specific. And it fails only for =20 certain networks. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 20:21:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF4D81065678 for ; Tue, 10 Feb 2009 20:21:50 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 707A58FC21 for ; Tue, 10 Feb 2009 20:21:50 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so40720fgb.35 for ; Tue, 10 Feb 2009 12:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fqbDhVZQS/W0imWlV6312PYnvvzlyCuUM9bTfSymQcI=; b=jvISmm8cr0XF8H12YxDx91rZGvXpDNqZ5P437i2N0GN8WdSrwzcAZbdUf1whDph1OD 9Josppsbcl7v84x0mfXBps8w+y6xKrOAKKF30K1rKyGKZXzmS3bA+hRcs07pgiXuxH/r X0VoiawNy6nJqS6j/zu13m/8PG5bWLG1sw3V4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JpbdsmAnnjXk3xZGwBqbB1leqbakUAA9tBP1ym1kufhkeY08aWT39e6HdwwaN0bNyC ZJD/EkAkaN8WaRbay/hQnShcdKr0C18GvnCqvTNY04lEJG/+weZea8+PZKM01caMuhPq l7TOJolHsekO4gP/mEyFtszllda25BEHFWdQo= MIME-Version: 1.0 Received: by 10.86.92.7 with SMTP id p7mr70894fgb.74.1234297309577; Tue, 10 Feb 2009 12:21:49 -0800 (PST) Date: Tue, 10 Feb 2009 21:21:49 +0100 Message-ID: <671bb5fc0902101221n2dbb1cf0hbc43164ffa6f6124@mail.gmail.com> From: Alexej Sokolov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: taskqueue (9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 20:21:51 -0000 Hello, the structure task(9) contain field ta_priority. Which role plays this priority if the task will wake up for run. Or it is used only for order of task in waitqueue while pending ? Thanks Alexej From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 21:04:46 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2F50106564A for ; Tue, 10 Feb 2009 21:04:46 +0000 (UTC) (envelope-from abohra@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3DE8FC1C for ; Tue, 10 Feb 2009 21:04:46 +0000 (UTC) (envelope-from abohra@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so30300ywt.13 for ; Tue, 10 Feb 2009 13:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IqL3uAM3aXqq9da4/4M0mtqjhYhAGUoTIARtsLZeZ2M=; b=h4EsiFTNgopOb3nE3RRc36pv9MvJjY6DXMRo0LU5koNntyYlXlO2TfKDpzACVPDC0+ 5WgVv9HY9/xxDf7BwZCNOtG5Q/yX78kSRPunt/cXTiOOHALW78NLTeTq6NsGvl+FH/GD X7SbLJfOGG82Bn8NAk4Qf+PQmzMc2BsXl1ya8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rm4moZvCK2oviIo+q8NCal1AkROctnovp0dvEo5ZAk3o19XTbAe8MuBDVF2D6IGYx5 XiFTxHVYWkSisooBMnppbg/b4kjXXWP502dXL/78Dw7TJieMLIE+CCk9RRTfyyeU/jc2 onPdj5yZwwWiTWPnF5neqiyoDQ4aEdGNZIs7c= MIME-Version: 1.0 Received: by 10.100.108.20 with SMTP id g20mr4521822anc.3.1234298597969; Tue, 10 Feb 2009 12:43:17 -0800 (PST) Date: Tue, 10 Feb 2009 15:43:17 -0500 Message-ID: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> From: Aniruddha Bohra To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Feb 2009 21:10:11 +0000 Cc: avg@icyb.net.ua Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:04:47 -0000 You can see Click: http://read.cs.ucla.edu/click/ It does not run on FreeBSD >4. I have an old diff which builds on the work by Marko Zec and Bruce Simpson, that allows me to load the click module. http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff Hope this helps Aniruddha From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 11:02:37 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53BE61065680 for ; Wed, 11 Feb 2009 11:02:37 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 954878FC27 for ; Wed, 11 Feb 2009 11:02:35 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 19973 invoked from network); 11 Feb 2009 11:02:34 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 11 Feb 2009 11:02:34 -0000 Message-ID: <4992B049.30903@FreeBSD.org> Date: Wed, 11 Feb 2009 12:02:33 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: Oliver Fromme References: <200902061139.n16BdB6b058473@lurza.secnetix.de> In-Reply-To: <200902061139.n16BdB6b058473@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 11:02:38 -0000 Oliver Fromme ha scritto: > The problem is related to the fact that a 64bit kernel > cannot use VESA BIOS functions. You should be able to > use standard VGA modes though, which don't require VESA > support. Actually I cannot see any splash screen on amd64, at least on the machines I tried (most with ATI ES1000 cards), with a 320x200x8 bitmap. No problems with i386 (on the same machines). -- Alex Dupre From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 12:01:00 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22C81065728; Wed, 11 Feb 2009 12:01:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 13B228FC14; Wed, 11 Feb 2009 12:00:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n1BC0wqH006844; Wed, 11 Feb 2009 13:00:58 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n1BC0wni006842; Wed, 11 Feb 2009 13:00:58 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200902111200.n1BC0wni006842@lurza.secnetix.de> To: ale@FreeBSD.org (Alex Dupre) Date: Wed, 11 Feb 2009 13:00:58 +0100 (CET) In-Reply-To: <4992B049.30903@FreeBSD.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 11 Feb 2009 13:00:58 +0100 (CET) Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:01:07 -0000 Alex Dupre wrote: > Oliver Fromme ha scritto: > > The problem is related to the fact that a 64bit kernel > > cannot use VESA BIOS functions. You should be able to > > use standard VGA modes though, which don't require VESA > > support. > > Actually I cannot see any splash screen on amd64, at least on the > machines I tried (most with ATI ES1000 cards), with a 320x200x8 bitmap. > No problems with i386 (on the same machines). Yeah, my fingers were faster than my brain. The current syscons code cannot switch modes (no matter if VESA or standard VGA) if there is no BIOS support. It probably makes sense to let the boot loader set up graphics mode (including VESA support), so it is already active when the kernel comes up. Then the kernel will only have to deal with the frame buffer, not with the BIOS. That will work on both i386 and amd64 platforms. The only drawback is that the mode cannot be changed by the kernel once it is running, i.e. you have to stay in that mode till reboot. That solution requires support by the loader and by syscons. It is my plan to look into that, as soon as the basic graphics support in the loader is finished. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 12:53:59 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39BFC106566C for ; Wed, 11 Feb 2009 12:53:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7433F8FC15 for ; Wed, 11 Feb 2009 12:53:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA11321 for ; Wed, 11 Feb 2009 14:53:56 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4992CA63.8080601@icyb.net.ua> Date: Wed, 11 Feb 2009 14:53:55 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: generalizing fd allocation code to id allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:53:59 -0000 Guys, anybody has ideas (or code) for generalizing code in sys/kern/kern_descrip.c for managing fd-s ("small" integer numbers)? I mean divorcing that code from filedesc and making it re-usable wherever we need some (constrained) id allocation. By constrained I mean that either ids are allocated from a sufficiently small limited pool or it is desirable to keep ids at small values. I needed this in a small driver that I am slowly writing and here's some bits from it: #define NDSLOTTYPE uint64_t #define NDSLOTSIZE sizeof(NDSLOTTYPE) #define NDENTRIES (NDSLOTSIZE * __CHAR_BIT) #define NDSLOT(x) ((x) / NDENTRIES) #define NDBIT(x) ((NDSLOTTYPE)1 << ((x) % NDENTRIES)) #define NDSLOTS(x) (((x) + NDENTRIES - 1) / NDENTRIES) ... /* XXX ugly */ NDSLOTTYPE host_addr_map[NDSLOTS(sizeof(uint8_t) * __CHAR_BIT)]; ... static uint8_t alloc_host_addr(struct heci_softc *sc) { static const int maxoff = sizeof(sc->host_addr_map) / sizeof(sc->host_addr_map[0]); NDSLOTTYPE *map = sc->host_addr_map; int off; for (off = 0; off < maxoff; ++off) { if (map[off] != ~0UL) { uint8_t addr = off * NDENTRIES + ffsl(~map[off]) - 1; map[NDSLOT(addr)] |= NDBIT(addr); return (addr); } } /* XXX what to return if all addresses are in use? */ /* use the fact that zero is a reserved address */ return 0; } static void release_host_addr(struct heci_softc *sc, uint8_t addr) { NDSLOTTYPE *map = sc->host_addr_map; if (!(map[NDSLOT(addr)] & NDBIT(addr))) /* XXX make KASSERT? */ device_printf(sc->dev, "release for unused host addr 0x%02x\n", addr); map[NDSLOT(addr)] &= ~NDBIT(addr); } Essentially this is almost a copy/paste. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 13:09:49 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EC01065672 for ; Wed, 11 Feb 2009 13:09:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E55218FC21 for ; Wed, 11 Feb 2009 13:09:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA11867 for ; Wed, 11 Feb 2009 15:09:47 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4992CE1A.6060106@icyb.net.ua> Date: Wed, 11 Feb 2009 15:09:46 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <4992CA63.8080601@icyb.net.ua> In-Reply-To: <4992CA63.8080601@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: generalizing fd allocation code to id allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:09:50 -0000 My nose has just been rubbed into alloc_unr(9) :) Thanks, Roman! on 11/02/2009 14:53 Andriy Gapon said the following: > Guys, > > anybody has ideas (or code) for generalizing code in > sys/kern/kern_descrip.c for managing fd-s ("small" integer numbers)? > > I mean divorcing that code from filedesc and making it re-usable > wherever we need some (constrained) id allocation. > By constrained I mean that either ids are allocated from a sufficiently > small limited pool or it is desirable to keep ids at small values. > > I needed this in a small driver that I am slowly writing and here's some > bits from it: > > #define NDSLOTTYPE uint64_t > #define NDSLOTSIZE sizeof(NDSLOTTYPE) > #define NDENTRIES (NDSLOTSIZE * __CHAR_BIT) > #define NDSLOT(x) ((x) / NDENTRIES) > #define NDBIT(x) ((NDSLOTTYPE)1 << ((x) % NDENTRIES)) > #define NDSLOTS(x) (((x) + NDENTRIES - 1) / NDENTRIES) > ... > /* XXX ugly */ > NDSLOTTYPE host_addr_map[NDSLOTS(sizeof(uint8_t) * __CHAR_BIT)]; > ... > static uint8_t alloc_host_addr(struct heci_softc *sc) > { > static const int maxoff = sizeof(sc->host_addr_map) / > sizeof(sc->host_addr_map[0]); > NDSLOTTYPE *map = sc->host_addr_map; > int off; > > for (off = 0; off < maxoff; ++off) { > if (map[off] != ~0UL) { > uint8_t addr = off * NDENTRIES + ffsl(~map[off]) > - 1; > map[NDSLOT(addr)] |= NDBIT(addr); > return (addr); > } > } > > /* XXX what to return if all addresses are in use? */ > /* use the fact that zero is a reserved address */ > return 0; > } > > static void > release_host_addr(struct heci_softc *sc, uint8_t addr) > { > NDSLOTTYPE *map = sc->host_addr_map; > if (!(map[NDSLOT(addr)] & NDBIT(addr))) /* XXX make KASSERT? */ > device_printf(sc->dev, "release for unused host addr > 0x%02x\n", addr); > map[NDSLOT(addr)] &= ~NDBIT(addr); > } > > > Essentially this is almost a copy/paste. > > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 13:23:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53B44106566B for ; Wed, 11 Feb 2009 13:23:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id E03F38FC17 for ; Wed, 11 Feb 2009 13:23:19 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=-VmeWncGuDwA:10 a=Xl7yW04Lv0gA:10 a=kw03RjmKpLm8ql5X2xOdcA==:17 a=XwRVTZnAGrRaiR8A6skA:9 a=0yO7PdgZPYkV-XKUKTYSMc2857AA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO laptop) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1192418371; Wed, 11 Feb 2009 14:23:18 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 11 Feb 2009 14:25:45 +0100 User-Agent: KMail/1.9.7 References: <4992CA63.8080601@icyb.net.ua> <4992CE1A.6060106@icyb.net.ua> In-Reply-To: <4992CE1A.6060106@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111425.45981.hselasky@c2i.net> Cc: Andriy Gapon Subject: Re: generalizing fd allocation code to id allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:23:20 -0000 On Wednesday 11 February 2009, Andriy Gapon wrote: > My nose has just been rubbed into alloc_unr(9) :) > Thanks, Roman! The only problem about alloc_unr() is that you cannot allocate multiple contiguous units? --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 13:28:33 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA97310656CE for ; Wed, 11 Feb 2009 13:28:33 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 79E748FC12 for ; Wed, 11 Feb 2009 13:28:33 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id CAC036D41A; Wed, 11 Feb 2009 14:13:37 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBoiv1r8icU4; Wed, 11 Feb 2009 14:13:31 +0100 (CET) Received: by mx1.rink.nu (Postfix, from userid 1000) id 723E56D439; Wed, 11 Feb 2009 14:13:31 +0100 (CET) Date: Wed, 11 Feb 2009 14:13:31 +0100 From: Rink Springer To: Oliver Fromme Message-ID: <20090211131331.GA78543@rink.nu> References: <4992B049.30903@FreeBSD.org> <200902111200.n1BC0wni006842@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902111200.n1BC0wni006842@lurza.secnetix.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, Alex Dupre Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:28:35 -0000 On Wed, Feb 11, 2009 at 01:00:58PM +0100, Oliver Fromme wrote: > It probably makes sense to let the boot loader set up > graphics mode (including VESA support), so it is already > active when the kernel comes up. Then the kernel will > only have to deal with the frame buffer, not with the BIOS. > That will work on both i386 and amd64 platforms. The only > drawback is that the mode cannot be changed by the kernel > once it is running, i.e. you have to stay in that mode > till reboot. FWIW, this is exactly what FreeBSD/xbox does; the boot loader is responsible for setting up the video mode, and all it does is remap the framebuffer to a more sensible location (the way to do this is just writing to a register which is the same for any Xbox, and most bootloaders set the framebuffer to 4MB, which is a bit much for 640x480x16M especially if your machine only has 64MB of memory :-) > That solution requires support by the loader and by > syscons. It is my plan to look into that, as soon as the > basic graphics support in the loader is finished. I think that is a good approach. Go for it! Regards, -- Rink P.W. Springer - http://rink.nu "Chance favours the prepared mind" - Penn From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 13:40:30 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D38A2106564A for ; Wed, 11 Feb 2009 13:40:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 121138FC1E for ; Wed, 11 Feb 2009 13:40:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12335; Wed, 11 Feb 2009 15:25:05 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4992D1B0.8020708@icyb.net.ua> Date: Wed, 11 Feb 2009 15:25:04 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Aniruddha Bohra , hackers@freebsd.org References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> In-Reply-To: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:40:31 -0000 on 10/02/2009 22:43 Aniruddha Bohra said the following: > You can see Click: http://read.cs.ucla.edu/click/ > It does not run on FreeBSD >4. > I have an old diff which builds on the work by Marko Zec and Bruce > Simpson, that allows me to load the click module. > http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff > Aniruddha, thank you very much for the feedback! I looked through the code and the patch and I see the following: 1. options -fpermissive -fno-exceptions -fno-rtti are passed to c++ compiler 2. there are new/delete implementations that use kernel malloc I think that #1 means that there are no exceptions, (non-trivial) dynamic_cast and typeid for kernel c++ code. The questions that I have left: 1. do you use any global/static objects with constructors? did you have to write any code to call on those constructors when the module is loaded? 2. did you have to write any other run-time support code or platform glue code (besides new/delete)? 3. I assume virtual inheritance can be used in kernel code? do you use it? Thank you again! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 13:45:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DC110657D4 for ; Wed, 11 Feb 2009 13:45:11 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id C61118FC1C for ; Wed, 11 Feb 2009 13:45:09 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so106976ywt.13 for ; Wed, 11 Feb 2009 05:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=u80k1Vyseen35ympi0fyKTtgOpFtcEyqxB3RLP3oPR0=; b=lfqr3o5SEbO1cQXLr7NYd8MrrBZjcxkup+ROonhonnwADkt4D4l6uyH/9ioyyfia6O vNACuKYiiqsBNBMuz4Ug/V3ol+PtY0N6mF3ALJwRWX7fxpNM5awnwddd0ALMdjI+URkA AHJSwKuhszp2rkPhuqSXiMOAA4p/QbOfqnJgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ERsFVD109L4EOUwRbGuJXPoAMyzozZL/RnjSTE/2nyIiYZ1kG1ff/nK3HQmR4hmOMP leSqI+6p7nKHNzaFhDP2BJidClHdPQMVUREh3sfUch/FXhIhvqPI+R3f/ywKnsDxiwAt OTXfgHvj2qwQ5S6zu6VJfURvaIca3eTn3UR3Y= MIME-Version: 1.0 Received: by 10.142.86.4 with SMTP id j4mr662350wfb.111.1234359908839; Wed, 11 Feb 2009 05:45:08 -0800 (PST) Date: Wed, 11 Feb 2009 19:15:08 +0530 Message-ID: <251d650c0902110545w7c521e66tcb74f8ecc83e17a1@mail.gmail.com> From: Mehul Chadha To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: understanding of PTD symbol X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 13:45:12 -0000 Hello all, I am having doubts in understanding the usage of the symbol PTD. Could anyone pls explain the usage of PTD in the FreeBSD kernel?? In pmap_growkernel when we execute the following instruction wht is returned by pdir_pde ? Is it the physical address of a page table for KVA addressing?? while (pdir_pde(PTD, kernel_vm_end)) When I used objdump on the kernel executable i found the address of PTD symbol to be 0xBFEFF000 , I could not understand this , as in a virtual memory with 1G/3G split the kernel addressing must be between the addresses 0xC0000000 and 0xFFFFFFFF. Regards, Mehul From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 14:15:10 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCD9F1065672 for ; Wed, 11 Feb 2009 14:15:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DF10D8FC0A for ; Wed, 11 Feb 2009 14:15:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA14182 for ; Wed, 11 Feb 2009 16:15:08 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4992DD6B.3050507@icyb.net.ua> Date: Wed, 11 Feb 2009 16:15:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: userland driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:15:11 -0000 has anybody tried anything in the area of userland drivers on FreeBSD? I mean a driver for something sufficiently simple and standalone and not driven by interrupts. E.g. some sort of a watchdog driver that simply reads/writes some io registers from time to time. Brute-force and a very bad way is to go through /dev/mem, /dev/io, /dev/pci, but I am thinking about something that would allow to plug into newbus framework from userland. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 14:50:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 139FD106574B for ; Wed, 11 Feb 2009 14:50:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C227E8FC08 for ; Wed, 11 Feb 2009 14:50:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 6FD3946B65; Wed, 11 Feb 2009 09:50:21 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1BEo9FA025248; Wed, 11 Feb 2009 09:50:15 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 11 Feb 2009 09:25:49 -0500 User-Agent: KMail/1.9.7 References: <671bb5fc0902101221n2dbb1cf0hbc43164ffa6f6124@mail.gmail.com> In-Reply-To: <671bb5fc0902101221n2dbb1cf0hbc43164ffa6f6124@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902110925.49633.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, 11 Feb 2009 09:50:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8979/Wed Feb 11 07:23:15 2009 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: Alexej Sokolov Subject: Re: taskqueue (9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:50:23 -0000 On Tuesday 10 February 2009 3:21:49 pm Alexej Sokolov wrote: > Hello, > the structure task(9) contain field ta_priority. Which role plays this > priority if the task will wake up for run. > Or it is used only for order of task in waitqueue while pending ? It is solely used to order requests within the queue. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 15:30:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78867106566B for ; Wed, 11 Feb 2009 15:30:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 331008FC0A for ; Wed, 11 Feb 2009 15:30:53 +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.14.3/8.14.3) with ESMTP id n1BF15hR054323; Wed, 11 Feb 2009 09:01:05 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1BF15k9054322; Wed, 11 Feb 2009 09:01:05 -0600 (CST) (envelope-from brooks) Date: Wed, 11 Feb 2009 09:01:04 -0600 From: Brooks Davis To: Hans Petter Selasky Message-ID: <20090211150104.GA54097@lor.one-eyed-alien.net> References: <4992CA63.8080601@icyb.net.ua> <4992CE1A.6060106@icyb.net.ua> <200902111425.45981.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <200902111425.45981.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 11 Feb 2009 09:01:06 -0600 (CST) Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: generalizing fd allocation code to id allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:30:53 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2009 at 02:25:45PM +0100, Hans Petter Selasky wrote: > On Wednesday 11 February 2009, Andriy Gapon wrote: > > My nose has just been rubbed into alloc_unr(9) :) > > Thanks, Roman! >=20 > The only problem about alloc_unr() is that you cannot allocate multiple= =20 > contiguous units? You might want rman for that. The thing I would like to see alloc_urn() grow is that ability to request a particular value so we could use it in the ifnet cloning code. -- Brooks --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJkugwXY6L6fI4GtQRAvsoAKC9lhlFpjmblOSlfpiAEeH1jdfRjwCgregf WoaI41iNE/tAPwElDxP5OtE= =BChb -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 15:43:32 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B92091065670 for ; Wed, 11 Feb 2009 15:43:32 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0438FC1D for ; Wed, 11 Feb 2009 15:43:32 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n1BFMheg011630; Wed, 11 Feb 2009 10:22:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n1BFMhM1011629; Wed, 11 Feb 2009 10:22:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 11 Feb 2009 10:22:43 -0500 From: David Schultz To: Hans Petter Selasky Message-ID: <20090211152243.GA11468@zim.MIT.EDU> Mail-Followup-To: Hans Petter Selasky , freebsd-hackers@FreeBSD.ORG, Andriy Gapon References: <4992CA63.8080601@icyb.net.ua> <4992CE1A.6060106@icyb.net.ua> <200902111425.45981.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902111425.45981.hselasky@c2i.net> Cc: freebsd-hackers@FreeBSD.ORG, Andriy Gapon Subject: Re: generalizing fd allocation code to id allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 15:43:33 -0000 On Wed, Feb 11, 2009, Hans Petter Selasky wrote: > On Wednesday 11 February 2009, Andriy Gapon wrote: > > My nose has just been rubbed into alloc_unr(9) :) > > Thanks, Roman! > > The only problem about alloc_unr() is that you cannot allocate multiple > contiguous units? Both Solaris' vmem(9) and NetBSD's extent(9) can do this... might be worth looking into. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 16:40:07 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FCB11065679 for ; Wed, 11 Feb 2009 16:40:07 +0000 (UTC) (envelope-from abohra@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 272FA8FC23 for ; Wed, 11 Feb 2009 16:40:07 +0000 (UTC) (envelope-from abohra@gmail.com) Received: by an-out-0708.google.com with SMTP id b38so173593ana.13 for ; Wed, 11 Feb 2009 08:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P2et229lLzMOZus2+r28x2WHodSmAFlyRmsCesNnwZ0=; b=uwtegfKEUNGinTM8F8yzWmB7POZ/ZJ1ZPaB0HCkLutrqUfjjw7BhbxDLwzVGmxYBkj 0yBBx2PGZS8bTpDq1tLB4w4bHUbB7jwK5654OmX8+5gcvzkG3OXofyWBvqJ8bpSklMDN Ujxu+STw+PlQ4KqzIqMnylt8plYih2GmZG3W4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cJeZjR8fmJ6NQ4HXfk7+VBe0Vl5eEbfCGAEoB23/dVX2jDCOs8+AgDhZ51hBHst1IS wUxzpy1IXkWALgJFjHa3uIZQHbMMdXeQFsOqrAT3OxB81hmfC6tDcG0ObfHfxGn/9e9f NcWilMYdOAvjr4Ea44jwFXeI7bNOSZWWqxy0Q= MIME-Version: 1.0 Received: by 10.100.8.17 with SMTP id 17mr6171791anh.85.1234370406229; Wed, 11 Feb 2009 08:40:06 -0800 (PST) In-Reply-To: <4992D1B0.8020708@icyb.net.ua> References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> <4992D1B0.8020708@icyb.net.ua> Date: Wed, 11 Feb 2009 11:40:06 -0500 Message-ID: <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> From: Aniruddha Bohra To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Feb 2009 16:45:09 +0000 Cc: hackers@freebsd.org Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:40:07 -0000 On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon wrote: > on 10/02/2009 22:43 Aniruddha Bohra said the following: >> You can see Click: http://read.cs.ucla.edu/click/ >> It does not run on FreeBSD >4. >> I have an old diff which builds on the work by Marko Zec and Bruce >> Simpson, that allows me to load the click module. >> http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff > > 1. options -fpermissive -fno-exceptions -fno-rtti are passed to c++ compiler > 2. there are new/delete implementations that use kernel malloc > > I think that #1 means that there are no exceptions, (non-trivial) > dynamic_cast and typeid for kernel c++ code. Correct. > 1. do you use any global/static objects with constructors? did you have > to write any code to call on those constructors when the module is loaded? Not sure about this one. But AFAIK, there are no global static objects with constructors in Click code. There is one router object that is always initialized and it is updated by writing to the clickfs file system. The other objects are created with new. > 2. did you have to write any other run-time support code or platform > glue code (besides new/delete)? Apart from the new and delete, I think the other things were the pseudofs code to initialize the file system, the locks in include/click/sync.hh, the glue code in atomic.hh. > 3. I assume virtual inheritance can be used in kernel code? do you use it? Yes. For example, all objects inherit from "Element" and that defines virtual functions. (include/click/element.hh) Hope this helps. Aniruddha From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 18:32:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015A91065670 for ; Wed, 11 Feb 2009 18:32:02 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 945118FC14 for ; Wed, 11 Feb 2009 18:32:01 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n1BIFdnB036623; Wed, 11 Feb 2009 12:15:39 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1234376139; bh=Fe1jWPEMEOwayGHcbU+IKkwE7N/uMy8sN3pSRvwhwAc=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=YV+px/fSM7D5eZPdXnNqht7QDK0uGTJeAgI3XtsrDI5Tl6b7p/8lhLJ7TL+hzC8ac +e6TipkXQ0n2pPLzbm9hqEqVcjLaclIwzUjzZEJJfieqRdjGypVNWAWPsv6wAMr3Xq a7tUBKHLhiDr9nNb+IRrVFpYko5y9CkOAP1xQbR4= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n1BIFdYa036622; Wed, 11 Feb 2009 12:15:39 -0600 (CST) (envelope-from tinguely) Date: Wed, 11 Feb 2009 12:15:39 -0600 (CST) From: Mark Tinguely Message-Id: <200902111815.n1BIFdYa036622@casselton.net> To: freebsd-hackers@freebsd.org, mehulc87@gmail.com In-Reply-To: <251d650c0902110545w7c521e66tcb74f8ecc83e17a1@mail.gmail.com> X-Mailman-Approved-At: Wed, 11 Feb 2009 18:35:54 +0000 Cc: Subject: Re: understanding of PTD symbol X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:32:02 -0000 > Hello all, > I am having doubts in understanding the usage of the > symbol PTD. Could anyone pls explain the usage of PTD in the FreeBSD > kernel?? > > In pmap_growkernel when we execute the following instruction wht is > returned by pdir_pde ? Is it the physical address of a page table for > KVA addressing?? > > while (pdir_pde(PTD, kernel_vm_end)) > > When I used objdump on the kernel executable i found the address of > PTD symbol to be 0xBFEFF000 , I could not understand this , as in a > virtual memory with 1G/3G split the kernel addressing must be between > the addresses 0xC0000000 and 0xFFFFFFFF. > > Regards, > Mehul On the i386/amd64, the page table sits just below the kernel virtual memory. The recursive virtual address reference to the page table is inside this address. Assume i386 with 4 byte pointers and 4GB virtual address space with the 3GB user vm and 1GB kernel vm: the PTmap will start at 0xbfc00000 (which is one 4MB entry below the KVA). the PTD page directory descripters for the page table descripter will be 0xdeff000 which is 767 4K entries into the page table. Note: 768 is the 3G mark, so 767 is one less than 3/4 into the page table. PTDpde is the page table descriptor the the page table. It is PTD + 767 * 4 I found it easier to draw the various layouts and the page table itself. The i386 in 32 bit mode is 10 bits for the page directory, 10 bits for the page table and 12 bits for the physical page. The ARM processor is funner with 12/8/12 bits. --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 21:51:06 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0598F1065680 for ; Wed, 11 Feb 2009 21:51:06 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 602138FC13 for ; Wed, 11 Feb 2009 21:51:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 11 Feb 2009 21:51:03 -0000 Received: from p54A3F0A0.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.160] by mail.gmx.net (mp069) with SMTP; 11 Feb 2009 22:51:03 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/lt1YaEmbln9zXdvyYJhIz4mYUpX0I7LrarUT65A ejXH5xTEsaAbVO Message-ID: <49934846.10905@gmx.de> Date: Wed, 11 Feb 2009 22:51:02 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Aniruddha Bohra References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> <4992D1B0.8020708@icyb.net.ua> <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> In-Reply-To: <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: hackers@freebsd.org, Andriy Gapon Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:51:09 -0000 Aniruddha Bohra schrieb: > On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon wrote: >> on 10/02/2009 22:43 Aniruddha Bohra said the following: >>> You can see Click: http://read.cs.ucla.edu/click/ >>> It does not run on FreeBSD >4. >>> I have an old diff which builds on the work by Marko Zec and Bruce >>> Simpson, that allows me to load the click module. >>> http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff >> 1. options -fpermissive -fno-exceptions -fno-rtti are passed to c++ compiler >> 2. there are new/delete implementations that use kernel malloc >> >> I think that #1 means that there are no exceptions, (non-trivial) >> dynamic_cast and typeid for kernel c++ code. > > Correct. That's a pity. Lack of exceptions negates some major benefits of C++. >> 1. do you use any global/static objects with constructors? did you have >> to write any code to call on those constructors when the module is loaded? > > Not sure about this one. But AFAIK, there are no global static objects > with constructors in Click code. > There is one router object that is always initialized and it is > updated by writing to the clickfs file system. > The other objects are created with new. > >> 2. did you have to write any other run-time support code or platform >> glue code (besides new/delete)? > > Apart from the new and delete, I think the other things were the > pseudofs code to initialize the file system, > the locks in include/click/sync.hh, the glue code in atomic.hh. > > >> 3. I assume virtual inheritance can be used in kernel code? do you use it? Virtual inheritence needs no support from the "outside", so it is available. > Yes. For example, all objects inherit from "Element" and that defines > virtual functions. (include/click/element.hh) Virtual inheritance is something completely different than virtual methods. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 22:22:20 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8A010656C3 for ; Wed, 11 Feb 2009 22:22:20 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7EA8FC29 for ; Wed, 11 Feb 2009 22:22:20 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9E43919256; Wed, 11 Feb 2009 22:22:18 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 11 Feb 2009 22:22:18 +0000 (GMT) Date: Wed, 11 Feb 2009 22:22:13 +0000 From: Bruce Cran To: Christoph Mallon Message-ID: <20090211222213.7509f5e3@gluon> In-Reply-To: <49934846.10905@gmx.de> References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> <4992D1B0.8020708@icyb.net.ua> <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> <49934846.10905@gmx.de> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.4; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Aniruddha Bohra , Andriy Gapon Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:22:21 -0000 On Wed, 11 Feb 2009 22:51:02 +0100 Christoph Mallon wrote: > Aniruddha Bohra schrieb: > > On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon > > wrote: > >> on 10/02/2009 22:43 Aniruddha Bohra said the following: > >>> You can see Click: http://read.cs.ucla.edu/click/ > >>> It does not run on FreeBSD >4. > >>> I have an old diff which builds on the work by Marko Zec and Bruce > >>> Simpson, that allows me to load the click module. > >>> http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff > >> 1. options -fpermissive -fno-exceptions -fno-rtti are passed to > >> c++ compiler 2. there are new/delete implementations that use > >> kernel malloc > >> > >> I think that #1 means that there are no exceptions, (non-trivial) > >> dynamic_cast and typeid for kernel c++ code. > > > > Correct. > > That's a pity. Lack of exceptions negates some major benefits of C++. > > >> 1. do you use any global/static objects with constructors? did you > >> have to write any code to call on those constructors when the > >> module is loaded? > > > > Not sure about this one. But AFAIK, there are no global static > > objects with constructors in Click code. > > There is one router object that is always initialized and it is > > updated by writing to the clickfs file system. > > The other objects are created with new. > > > >> 2. did you have to write any other run-time support code or > >> platform glue code (besides new/delete)? > > > > Apart from the new and delete, I think the other things were the > > pseudofs code to initialize the file system, > > the locks in include/click/sync.hh, the glue code in atomic.hh. > > > > > >> 3. I assume virtual inheritance can be used in kernel code? do you > >> use it? > > Virtual inheritence needs no support from the "outside", so it is > available. > > > Yes. For example, all objects inherit from "Element" and that > > defines virtual functions. (include/click/element.hh) > > Virtual inheritance is something completely different than virtual > methods. Microsoft has an overview of using C++ in kernel drivers at http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx . It sounds like the situation on FreeBSD may be somewhat similar. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 22:49:36 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9327F106566B for ; Wed, 11 Feb 2009 22:49:36 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 37B518FC12 for ; Wed, 11 Feb 2009 22:49:35 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n1BMoJiT013840; Wed, 11 Feb 2009 17:50:19 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n1BMoJhe013839; Wed, 11 Feb 2009 17:50:19 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 11 Feb 2009 17:50:19 -0500 From: David Schultz To: Bruce Cran Message-ID: <20090211225019.GA13784@zim.MIT.EDU> Mail-Followup-To: Bruce Cran , hackers@FreeBSD.ORG References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> <4992D1B0.8020708@icyb.net.ua> <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> <49934846.10905@gmx.de> <20090211222213.7509f5e3@gluon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090211222213.7509f5e3@gluon> Cc: hackers@FreeBSD.ORG Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:49:37 -0000 On Wed, Feb 11, 2009, Bruce Cran wrote: > On Wed, 11 Feb 2009 22:51:02 +0100 > Christoph Mallon wrote: > > > Aniruddha Bohra schrieb: > > > On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon > > > wrote: > > >> on 10/02/2009 22:43 Aniruddha Bohra said the following: > > >>> You can see Click: http://read.cs.ucla.edu/click/ > > >>> It does not run on FreeBSD >4. > > >>> I have an old diff which builds on the work by Marko Zec and Bruce > > >>> Simpson, that allows me to load the click module. > > >>> http://www.cs.rutgers.edu/~bohra/click-1.5.0.diff > > >> 1. options -fpermissive -fno-exceptions -fno-rtti are passed to > > >> c++ compiler 2. there are new/delete implementations that use > > >> kernel malloc > > >> > > >> I think that #1 means that there are no exceptions, (non-trivial) > > >> dynamic_cast and typeid for kernel c++ code. > > > > > > Correct. > > > > That's a pity. Lack of exceptions negates some major benefits of C++. > > > > >> 1. do you use any global/static objects with constructors? did you > > >> have to write any code to call on those constructors when the > > >> module is loaded? > > > > > > Not sure about this one. But AFAIK, there are no global static > > > objects with constructors in Click code. > > > There is one router object that is always initialized and it is > > > updated by writing to the clickfs file system. > > > The other objects are created with new. > > > > > >> 2. did you have to write any other run-time support code or > > >> platform glue code (besides new/delete)? > > > > > > Apart from the new and delete, I think the other things were the > > > pseudofs code to initialize the file system, > > > the locks in include/click/sync.hh, the glue code in atomic.hh. > > > > > > > > >> 3. I assume virtual inheritance can be used in kernel code? do you > > >> use it? > > > > Virtual inheritence needs no support from the "outside", so it is > > available. > > > > > Yes. For example, all objects inherit from "Element" and that > > > defines virtual functions. (include/click/element.hh) > > > > Virtual inheritance is something completely different than virtual > > methods. > > Microsoft has an overview of using C++ in kernel drivers at > http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx . It sounds > like the situation on FreeBSD may be somewhat similar. FreeBSD doesn't support loading kernel code and data into pageable memory like Windows does, so a lot of the paging-related problems they're talking about aren't issues for us. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 11:37:11 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D32401065672 for ; Thu, 12 Feb 2009 11:37:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4138FC15 for ; Thu, 12 Feb 2009 11:37:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA21855; Thu, 12 Feb 2009 13:37:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <499409DF.4070404@icyb.net.ua> Date: Thu, 12 Feb 2009 13:37:03 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Christoph Mallon References: <43a2dc1a0902101243w5ce35609x35dbe440c39d80a8@mail.gmail.com> <4992D1B0.8020708@icyb.net.ua> <43a2dc1a0902110840t1e4c8856lb5b33cc153ea4acb@mail.gmail.com> <49934846.10905@gmx.de> In-Reply-To: <49934846.10905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Aniruddha Bohra Subject: Re: a little bit of c++ in kernel [module] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:37:12 -0000 on 11/02/2009 23:51 Christoph Mallon said the following: > Aniruddha Bohra schrieb: >> On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon wrote: [snip] >>> 3. I assume virtual inheritance can be used in kernel code? do you >>> use it? > > Virtual inheritence needs no support from the "outside", so it is > available. > >> Yes. For example, all objects inherit from "Element" and that defines >> virtual functions. (include/click/element.hh) > > Virtual inheritance is something completely different than virtual methods. The foul is on me, I should have known to write in proper terms. I meant virtual methods and their overriding, but used the wrong term. Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 12:08:59 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112F11065B5D for ; Thu, 12 Feb 2009 12:08:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 449218FC26 for ; Thu, 12 Feb 2009 12:08:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C5ABB46B5C; Thu, 12 Feb 2009 07:08:54 -0500 (EST) Date: Thu, 12 Feb 2009 12:08:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <4992DD6B.3050507@icyb.net.ua> Message-ID: References: <4992DD6B.3050507@icyb.net.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org Subject: Re: userland driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 12:09:04 -0000 On Wed, 11 Feb 2009, Andriy Gapon wrote: > has anybody tried anything in the area of userland drivers on FreeBSD? I > mean a driver for something sufficiently simple and standalone and not > driven by interrupts. E.g. some sort of a watchdog driver that simply > reads/writes some io registers from time to time. > > Brute-force and a very bad way is to go through /dev/mem, /dev/io, /dev/pci, > but I am thinking about something that would allow to plug into newbus > framework from userland. I recently had a related question from a colleague about implementing a synthetic USB device in userspace so that software part development can occur concurrently with hardware part development. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 12:17:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B73A1065742; Thu, 12 Feb 2009 12:17:06 +0000 (UTC) (envelope-from onemda@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 68D648FC16; Thu, 12 Feb 2009 12:17:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nf-out-0910.google.com with SMTP id e27so64203nfd.33 for ; Thu, 12 Feb 2009 04:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zwz+AQhzgc1KMtgsvp7wfKnPX8Via5THzu6aAYfCTow=; b=xI3pMIPKUvn9wW3CuF76fwV2vS2v/+4iBR2AlcvrpqcemRDGk8Ekn3fGYv7iSdQo3a DqDwRpjtODBPpRlIDbnC4wr4JQXty9hSJOJjDzRPaxYSsqfRlpzE0FnNEm8CTFrWWVfP 51qq5ajwSaXd14hrEFiS1FFYFLnOO9vNetwhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=djgR5v78+bXt/ueyXKzWHJl0XRXehK5LR4/JiBQELdn8nvHDvVA47vNYnDVsb/LiG7 5MKcBd4uH5b5JIbEPhHO/2vEDoD3oteVQgMsLySnmpwfFawFq3njykPV2w1tOqK60Xzf vsV4tB00bnfR5/t+BkVYW0RVfyiHnoXvGNgEU= MIME-Version: 1.0 Received: by 10.210.127.13 with SMTP id z13mr629025ebc.141.1234441024491; Thu, 12 Feb 2009 04:17:04 -0800 (PST) In-Reply-To: <20090210112554.15896t24mpahwggs@webmail.rawbw.com> References: <20090209143642.168421bp9jjvs7i8@webmail.rawbw.com> <4991ADB5.9050803@freebsd.org> <20090210112554.15896t24mpahwggs@webmail.rawbw.com> Date: Thu, 12 Feb 2009 13:17:04 +0100 Message-ID: <3a142e750902120417mee92d86m5a3a871c9145fa54@mail.gmail.com> From: "Paul B. Mahol" To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Sam Leffler Subject: Re: How to troubleshoot why ath0 can't connect to a passwordless wireless network? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 12:17:07 -0000 On 2/10/09, Yuri wrote: > Quoting "Sam Leffler" : > >> You seem to say your network is open (no security). If not you need >> to show your network configuration. > > That's right, network is open (no security). > >> tcpdump can be used to tap traffic at 3 layers: 802.3, 802.11, and >> driver. It can be used to identify where packets are lost in the >> hierarchy (if at all). > > 'tcpdump -vv -i ath0' shows nothing when I run 'dhclient ath0' or > 'dhcping -s 255.255.255.255'. dhclient always fails, dhcping > says "no answer". > But tcpdump shows traffic between other hosts on the same network. > >> Assuming packets are going out but not coming back you can sniff >> from a 3rd station to look for traffic in the air but not received. > > No, now packets don't seem to go out at all. I said before that packets > went out when interface in fact was in 'monitor' mode. Really? Try wlandebug(8) to see what 802.11 code is doing vs ath driver. >> Given how little info you posted it's virtually impossible to advise >> you what is wrong. When in doubt c&p real output; describing a >> problem often causes useful info to be left out. > > There is no "real output" from tcpdump, this is a problem. > > How to find out for example why 'sendto' call from dhcping doesn't > result in any packets on ath0 interface which is 'UP' and 'associated'? > > I used this same system to connect to other open WiFi networks without > the problem. So it seems to be network-specific. And it fails only for > certain networks. > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Paul From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 14:08:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9174B1065672 for ; Thu, 12 Feb 2009 14:08:24 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id F16678FC25 for ; Thu, 12 Feb 2009 14:08:23 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy14 with SMTP id 14so663602ewy.19 for ; Thu, 12 Feb 2009 06:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ds+Why8ppsRdR+K6zfp+LNKZRb8F+n1aq7396uHipV8=; b=CGSPjEmxyMMqepTCl+FmRP6pnlLQag3PxsOPC+aTAlMxGwDyeFx8PbN0ntVZX/e/Y9 C8RxrJf0km8MBq9DXgzuf6vQULn9a1bijBn3GT2Fmr118cLZ4RMV1+urWAd1qh2kLTeY Ddd2LJ8fCTMWBnAVF0YmAIwVmBjQUni8VJOg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=eoX7+wpv3bFQSR+zP45rCvaM/Qgzwj641wEwbcjB+KyTnXJBknUwrd7L7eVFePR0Jp U3XoEXQoRntXGMhXtgdsvp3CNJ+LIFl2SWnn7r+Il5cxLFPuXzuWIPoWjsE1BVcT5MVz Q/nZyY5fAoeooAxB9/nh0JZDftkWleaSJumEQ= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.210.66.13 with SMTP id o13mr203497eba.157.1234447702498; Thu, 12 Feb 2009 06:08:22 -0800 (PST) Date: Thu, 12 Feb 2009 14:08:22 +0000 X-Google-Sender-Auth: b7a73b16aebe9d38 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:08:25 -0000 I found this useful tool called pahole[1]. It basically finds holes within structs, so for example on my 64bit machine this struct: struct test { int foo; const char *bar; int blah; } Would have a hole between foo and bar of 4 bytes because both for and bar have been aligned on a 8 byte boundary, and the struct would also have 4 bytes of padding on the end. However, if I simply moved blah between foo and bar then the struct has shrunk by 8 bytes, which could be a good thing. This could also help keep structs within single cache lines, and just generally keep memory usage to a minimum when the struct is used many times (for example in an array). So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that many of the struct had holes, and some of which could be rearranged to fill the gap. I've made the list available here[2]. So my questions are two fold: 1) Is it worth my time trying to rearrange structs? If so do you think many of my patches would be accepted? 2) Is there a way to find out the most heavily used structs? There are ~3600 structs, and ~2000 holes, it might be a waste of my time fixing the structs which are only used once. thanks Andrew [1] http://lwn.net/Articles/206805/ [2] http://bramp.net/projects/kernel.pahole.bz2 (~260kB) From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 14:13:18 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C796C1065673 for ; Thu, 12 Feb 2009 14:13:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACD18FC19 for ; Thu, 12 Feb 2009 14:13:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LXcJY-0004Zb-QW; Thu, 12 Feb 2009 16:13:16 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1CEDD8W021433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 16:13:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1CEDDD1047069; Thu, 12 Feb 2009 16:13:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1CEDDjN047030; Thu, 12 Feb 2009 16:13:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Feb 2009 16:13:13 +0200 From: Kostik Belousov To: Andrew Brampton Message-ID: <20090212141313.GD2723@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W5WqUoFLvi1M7tJE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LXcJY-0004Zb-QW 39f6ed7cbb064556bbe5d84c66d1ad75 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:13:19 -0000 --W5WqUoFLvi1M7tJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2009 at 02:08:22PM +0000, Andrew Brampton wrote: > I found this useful tool called pahole[1]. It basically finds holes > within structs, so for example on my 64bit machine this struct: >=20 > struct test { > int foo; > const char *bar; > int blah; > } >=20 > Would have a hole between foo and bar of 4 bytes because both for and > bar have been aligned on a 8 byte boundary, and the struct would also > have 4 bytes of padding on the end. However, if I simply moved blah > between foo and bar then the struct has shrunk by 8 bytes, which could > be a good thing. This could also help keep structs within single cache > lines, and just generally keep memory usage to a minimum when the > struct is used many times (for example in an array). >=20 > So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that Did you ported it to FreeBSD, or run on the Linux host ? > many of the struct had holes, and some of which could be rearranged to > fill the gap. I've made the list available here[2]. So my questions > are two fold: >=20 > 1) Is it worth my time trying to rearrange structs? If so do you think > many of my patches would be accepted? >=20 > 2) Is there a way to find out the most heavily used structs? There are > ~3600 structs, and ~2000 holes, it might be a waste of my time fixing > the structs which are only used once. >=20 > thanks > Andrew >=20 > [1] http://lwn.net/Articles/206805/ > [2] http://bramp.net/projects/kernel.pahole.bz2 (~260kB) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --W5WqUoFLvi1M7tJE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmULm0ACgkQC3+MBN1Mb4joYwCfSkvwNVqw3CxhBwtylz2H09AE u44AnjQ5EJklVTyfp+a6bshkWMsRuD/i =50k3 -----END PGP SIGNATURE----- --W5WqUoFLvi1M7tJE-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 14:45:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6898310656D9 for ; Thu, 12 Feb 2009 14:45:22 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id EC43B8FC26 for ; Thu, 12 Feb 2009 14:45:21 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy14 with SMTP id 14so678665ewy.19 for ; Thu, 12 Feb 2009 06:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=cpEWA4ypl40SHd+sp8ISc7i8kWm3UgN0m5XiRIi1Jt0=; b=ch+25RkZJD8ClBAf5v1xy4ON1YY4yzKFDzgVvTifZJbJp5tIuLlVUa1R0Ormhu32vQ ySIpgyaYGW8z51d2nVV1MV8oCUcbctnarchejya6gl+6zhNZ/W0KJu8GFEnc8vfo8lDF kqBz1VnIkGwQDzM6Q4eqZUajXV5JV4FrImE8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bWEIeGdFkO5dMTdapYc1eXhE0y7zwmmstFTVyt+th7SjtuYga6FBzqqqqlCWfenIcz q355DS/DVQFOBjPvlfmbuZ/EAPUKfoIfxzeZf3UmQ3h8LdjhRVUqjtYDIxzC02sw4Lag AZpwlJsvTE2aqK24BeRVW7m9ky64r2FEgaJmw= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.210.16.10 with SMTP id 10mr739670ebp.80.1234449920671; Thu, 12 Feb 2009 06:45:20 -0800 (PST) In-Reply-To: <20090212141313.GD2723@deviant.kiev.zoral.com.ua> References: <20090212141313.GD2723@deviant.kiev.zoral.com.ua> Date: Thu, 12 Feb 2009 14:45:20 +0000 X-Google-Sender-Auth: a759e9d42e356326 Message-ID: From: Andrew Brampton To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:45:24 -0000 2009/2/12 Kostik Belousov : > On Thu, Feb 12, 2009 at 02:08:22PM +0000, Andrew Brampton wrote: >> >> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > Did you ported it to FreeBSD, or run on the Linux host ? > Sorry no, I just ran it from a Linux host, but to my surprised it seemed to work fine. Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 14:52:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03281065677 for ; Thu, 12 Feb 2009 14:52:28 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0F77B8FC13 for ; Thu, 12 Feb 2009 14:52:27 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: by bwz18 with SMTP id 18so1328816bwz.19 for ; Thu, 12 Feb 2009 06:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tn7pyRkjX3y8cML8BrZyXn6nFaW60gvL/31dwOEKKOc=; b=Aux9IJfjjrB2QVXx45XEMiPDwOwg5NiYFq6IE5MZ+iZq2RV4TNfpJujIkABRbNocEL FDBiKWrBkvzdeOAzpGWNatJC2z9zqWxH4UfLEXX4xjeGOOYgYnVukJRRAWhYkow9+0C2 PJhSCiECGObebHCAd1owkwnsLkg2yB51//AJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N7DrA65cyUSuURFAVnK8ZJjSibe1Gf6Gg2B7X6vtNSUN2/JuOlxRQrwQym5A9enpY6 j4mlmYxbSc5Lznqy8fAqwqbndWdyr10rJoNejd8DpdDwQ5hqFYtRLzBvQxg4vY2tjXE2 EBwuN08vQQQQemV/+IMJurtKpOfSGiUtmEz+4= MIME-Version: 1.0 Received: by 10.223.113.194 with SMTP id b2mr1051067faq.80.1234448490389; Thu, 12 Feb 2009 06:21:30 -0800 (PST) In-Reply-To: <20090212141313.GD2723@deviant.kiev.zoral.com.ua> References: <20090212141313.GD2723@deviant.kiev.zoral.com.ua> Date: Thu, 12 Feb 2009 15:21:30 +0100 Message-ID: From: Harald Servat To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:52:29 -0000 On Thu, Feb 12, 2009 at 3:13 PM, Kostik Belousov wrote: > On Thu, Feb 12, 2009 at 02:08:22PM +0000, Andrew Brampton wrote: > > I found this useful tool called pahole[1]. It basically finds holes > > within structs, so for example on my 64bit machine this struct: > > > > struct test { > > int foo; > > const char *bar; > > int blah; > > } > > > > Would have a hole between foo and bar of 4 bytes because both for and > > bar have been aligned on a 8 byte boundary, and the struct would also > > have 4 bytes of padding on the end. However, if I simply moved blah > > between foo and bar then the struct has shrunk by 8 bytes, which could > > be a good thing. This could also help keep structs within single cache > > lines, and just generally keep memory usage to a minimum when the > > struct is used many times (for example in an array). > > > > So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > Did you ported it to FreeBSD, or run on the Linux host ? > > > many of the struct had holes, and some of which could be rearranged to > > fill the gap. I've made the list available here[2]. So my questions > > are two fold: > > > > 1) Is it worth my time trying to rearrange structs? If so do you think > > many of my patches would be accepted? > > > > 2) Is there a way to find out the most heavily used structs? There are > > ~3600 structs, and ~2000 holes, it might be a waste of my time fixing > > the structs which are only used once. > > > > thanks > > Andrew > Interesting utility Andrew! Remember that size of some types depend on the memory ABI (32 or 64 bits), so this influences on the result of this utility. > > > [1] http://lwn.net/Articles/206805/ > > [2] http://bramp.net/projects/kernel.pahole.bz2 (~260kB) > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:01:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADAD106566B for ; Thu, 12 Feb 2009 16:01:15 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 513F58FC1E for ; Thu, 12 Feb 2009 16:01:15 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A78F8.dip.t-dialin.net [84.154.120.248]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id n1CFmxrk045317; Thu, 12 Feb 2009 16:49:00 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id n1CFmn9p031671; Thu, 12 Feb 2009 16:48:49 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n1CFnLdt002361; Thu, 12 Feb 2009 16:49:26 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200902121549.n1CFnLdt002361@fire.js.berklix.net> To: Andrew Brampton From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Thu, 12 Feb 2009 14:08:22 GMT." Date: Thu, 12 Feb 2009 16:49:21 +0100 Sender: jhs@berklix.org Cc: freebsd-hackers@freebsd.org Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:01:16 -0000 > 1) Is it worth my time trying to rearrange structs? I wondered whether as a sensitivity test, some version of gcc (or its competitor ?) might have capability to automatically re-order variables ? but found nothing in man gcc "Optimization Options". Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:17:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192841065672 for ; Thu, 12 Feb 2009 16:17:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6988FC08 for ; Thu, 12 Feb 2009 16:17:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-026-076.pools.arcor-ip.net [88.66.26.76]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1LXeG71gyW-0007Cw; Thu, 12 Feb 2009 17:17:51 +0100 Received: (qmail 32556 invoked from network); 12 Feb 2009 16:17:48 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by router.laiers.local with SMTP; 12 Feb 2009 16:17:48 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Thu, 12 Feb 2009 17:17:47 +0100 User-Agent: KMail/1.10.4 (FreeBSD/8.0-CURRENT; KDE/4.1.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902121717.47841.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+1Tbhx41z2rCGOvclTXX4lh1l6M7iJH8toREZ cBCSztrU6MsAN7/MC3Q/VOrOC/qYPXj+sWK0s3p11JvplJQNIv dxsRkunET37YCYH1NKMTw== Cc: Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:17:53 -0000 On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote: > So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > many of the struct had holes, and some of which could be rearranged to > fill the gap. Interesting tool ... > I've made the list available here[2]. So my questions > are two fold: > > 1) Is it worth my time trying to rearrange structs? If so do you think > many of my patches would be accepted? > > 2) Is there a way to find out the most heavily used structs? There are > ~3600 structs, and ~2000 holes, it might be a waste of my time fixing > the structs which are only used once. That's the tricky part. Rearranging the structs itself is not that difficult, but identifying which should be rearranged and if, how ... that's the problem. The fact that gaps might be different for 64 vs. 32 bit architectures has already been mentioned. In addition one needs to keep in mind that changing a struct layout is a ABI change. So if we do identify structs that we want to change we should do them all at once to keep the different versions down to a minimum. So to answer your first question, submitting 101 patches to rearrange 101 structs is certainly a wasted effort. However, if you take a good look at the 2000 holes, identify an interesting subset and submit a patch to fix that subset ... that would be a worthwhile effort ... IMHO. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:33:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A59C10656C4 for ; Thu, 12 Feb 2009 16:33:46 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E94E28FC18 for ; Thu, 12 Feb 2009 16:33:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id F14591CDD2; Thu, 12 Feb 2009 17:33:44 +0100 (CET) Date: Thu, 12 Feb 2009 17:33:44 +0100 From: Ed Schouten To: FreeBSD Hackers Message-ID: <20090212163344.GR79178@hoeg.nl> References: <200902121717.47841.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3sseE1tnmEs+TkKq" Content-Disposition: inline In-Reply-To: <200902121717.47841.max@love2party.net> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:33:46 -0000 --3sseE1tnmEs+TkKq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Max Laier wrote: > So to answer your first question, submitting 101 patches to rearrange 101= =20 > structs is certainly a wasted effort. However, if you take a good look a= t the=20 > 2000 holes, identify an interesting subset and submit a patch to fix that= =20 > subset ... that would be a worthwhile effort ... IMHO. I guess it's also a wasted effort to reduce struct tty from 8xx to 7xx bytes, because it still allocates 1024 bytes of memory using malloc(9). I guess we should mainly focus on structures that are allocated using uma(9) or are slightly bigger than 2^n. --=20 Ed Schouten WWW: http://80386.nl/ --3sseE1tnmEs+TkKq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmUT2gACgkQ52SDGA2eCwX4CgCbBWWHMVpf3rWgHyw2c2djCycj +6sAn2cXisPzxeE1GAa4/fHGjd7WuQvk =pEmH -----END PGP SIGNATURE----- --3sseE1tnmEs+TkKq-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:42:20 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA10106564A for ; Thu, 12 Feb 2009 16:42:20 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id A0B468FC1A for ; Thu, 12 Feb 2009 16:42:20 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1CGgJsI042831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 08:42:20 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4994516B.8060703@freebsd.org> Date: Thu, 12 Feb 2009 08:42:19 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Max Laier References: <200902121717.47841.max@love2party.net> In-Reply-To: <200902121717.47841.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:42:21 -0000 Max Laier wrote: > On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote: > >> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that >> many of the struct had holes, and some of which could be rearranged to >> fill the gap. >> > > Interesting tool ... > Someone should be able to do the same thing with coverity but it's obviously less effort to use something that exists. If I recall this and related tools like sparse use dwarf symbols which we don't generate by default. But with dtrace support I think we now can in fact generate the symbols easily so maybe someone can look at porting the tools... > >> I've made the list available here[2]. So my questions >> are two fold: >> >> 1) Is it worth my time trying to rearrange structs? If so do you think >> many of my patches would be accepted? >> >> 2) Is there a way to find out the most heavily used structs? There are >> ~3600 structs, and ~2000 holes, it might be a waste of my time fixing >> the structs which are only used once. >> > > That's the tricky part. Rearranging the structs itself is not that difficult, > but identifying which should be rearranged and if, how ... that's the problem. > The fact that gaps might be different for 64 vs. 32 bit architectures has > already been mentioned. > > In addition one needs to keep in mind that changing a struct layout is a ABI > change. So if we do identify structs that we want to change we should do them > all at once to keep the different versions down to a minimum. > > So to answer your first question, submitting 101 patches to rearrange 101 > structs is certainly a wasted effort. However, if you take a good look at the > 2000 holes, identify an interesting subset and submit a patch to fix that > subset ... that would be a worthwhile effort ... IMHO. > > The other thing to keep in mind is that structure layout can have a noticeable effect on cache locality. Arbitrarily rearranging structure members can generate many more cache misses so one should sanity check changes w/ something like hwpmc. However as noted because layout may be platform-dependent even if something shows no change on x86 it may be a loss on another architecture and finding that performance drop may be really hard. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:50:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9DC106564A for ; Thu, 12 Feb 2009 16:50:10 +0000 (UTC) (envelope-from jille@quis.cx) Received: from mulgore.hexon-is.nl (mulgore.hexon-is.nl [82.94.237.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7D58FC19 for ; Thu, 12 Feb 2009 16:50:09 +0000 (UTC) (envelope-from jille@quis.cx) Received: from [10.0.0.142] (gw.hexon-nijmegen.nl [82.93.241.107]) (authenticated bits=0) by mulgore.hexon-is.nl (8.14.1/8.13.8) with ESMTP id n1CGYMDV017094; Thu, 12 Feb 2009 17:34:23 +0100 Message-ID: <49944F8F.5080104@quis.cx> Date: Thu, 12 Feb 2009 17:34:23 +0100 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Julian Stacey References: <200902121549.n1CFnLdt002361@fire.js.berklix.net> In-Reply-To: <200902121549.n1CFnLdt002361@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Hexon-MailScanner-Information: Please contact the ISP for more information X-Hexon-MailScanner-ID: n1CGYMDV017094 X-Hexon-MailScanner: Found to be clean X-Hexon-MailScanner-From: jille@quis.cx X-Hexon-MailScanner-Watermark: 1235061266.61968@ppP5W5Ss1URf75CK2+cshQ Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:50:10 -0000 Julian Stacey schreef: >> 1) Is it worth my time trying to rearrange structs? > > I wondered whether as a sensitivity test, some version of gcc (or > its competitor ?) might have capability to automatically re-order > variables ? but found nothing in man gcc "Optimization Options". There is a __packed attribute, I don't know what it exactly does and whether it is an improvement. -- Jille > > Cheers, > Julian From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:54:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 478F61065675 for ; Thu, 12 Feb 2009 16:54:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id E06998FC1D for ; Thu, 12 Feb 2009 16:54:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-026-076.pools.arcor-ip.net [88.66.26.76]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1LXepV0Bi8-00012F; Thu, 12 Feb 2009 17:54:25 +0100 Received: (qmail 33260 invoked from network); 12 Feb 2009 16:54:24 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by ns1.laiers.local with SMTP; 12 Feb 2009 16:54:24 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Thu, 12 Feb 2009 17:54:24 +0100 User-Agent: KMail/1.10.4 (FreeBSD/8.0-CURRENT; KDE/4.1.4; i386; ; ) References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> In-Reply-To: <4994516B.8060703@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902121754.24536.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19Pq6d11gbo29w1WJHvVM02ZJdSecYi7XkJX5R m85kfUfOtAZM+trnYQR40S4dPLsVC8ASuEXX0Ph5rQ4TJI0AOc XzJRKqRmUWyqbOt/aVd9w== Cc: Sam Leffler , Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:54:27 -0000 On Thursday 12 February 2009 17:42:19 Sam Leffler wrote: > Max Laier wrote: > > On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote: > >> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > >> many of the struct had holes, and some of which could be rearranged to > >> fill the gap. > > > > Interesting tool ... > > Someone should be able to do the same thing with coverity but it's > obviously less effort to use something that exists. If I recall this > and related tools like sparse use dwarf symbols which we don't generate > by default. But with dtrace support I think we now can in fact generate > the symbols easily so maybe someone can look at porting the tools... > > >> I've made the list available here[2]. So my questions > >> are two fold: > >> > >> 1) Is it worth my time trying to rearrange structs? If so do you think > >> many of my patches would be accepted? > >> > >> 2) Is there a way to find out the most heavily used structs? There are > >> ~3600 structs, and ~2000 holes, it might be a waste of my time fixing > >> the structs which are only used once. > > > > That's the tricky part. Rearranging the structs itself is not that > > difficult, but identifying which should be rearranged and if, how ... > > that's the problem. The fact that gaps might be different for 64 vs. 32 > > bit architectures has already been mentioned. > > > > In addition one needs to keep in mind that changing a struct layout is a > > ABI change. So if we do identify structs that we want to change we > > should do them all at once to keep the different versions down to a > > minimum. > > > > So to answer your first question, submitting 101 patches to rearrange 101 > > structs is certainly a wasted effort. However, if you take a good look > > at the 2000 holes, identify an interesting subset and submit a patch to > > fix that subset ... that would be a worthwhile effort ... IMHO. > > The other thing to keep in mind is that structure layout can have a > noticeable effect on cache locality. Arbitrarily rearranging structure > members can generate many more cache misses so one should sanity check > changes w/ something like hwpmc. However as noted because layout may be > platform-dependent even if something shows no change on x86 it may be a > loss on another architecture and finding that performance drop may be > really hard. Let's not be too "glass half empty" about it, though. The same is true in the opposite direction. If we can identify and eliminate an unnecessary hole in an important structure we might gain that same performance just by reshuffling a few lines. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 16:57:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C843F106566B for ; Thu, 12 Feb 2009 16:57:39 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0578FC0A for ; Thu, 12 Feb 2009 16:57:38 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so369389fgb.35 for ; Thu, 12 Feb 2009 08:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KnbKFrB8RxvgI1zYdftI4wDIxBS1doZOVHf+wYyVTpA=; b=IaqwN5wEBIkUZf6j12d5C33cTZkpuABRQ1rjPka+SRLZQ0N0LpsuQznVQ3/0LpqZbK 2hhKMShj3Ff6hGY0PY1CZrkg4+nHiEZU3SLlff6fqnyJFyw9PakrGu8UDRzFe5C62OO7 KjACOC0Q90qMdIy5SM9JUc3fSXM7O7WmXKMKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=po+1hEtq0+gJZpEyKv5xsJwpMQoWRl+aggYBh0UIHBnUriUhfFn2QMH3c3BF8EpDRj JU/y5OKwIdQNsi/xoX1C2tsq0pMSJ5cql/52Z9u7hBQ10kPjwDnG0wchlPuGFmgbf+r5 UkTlIRWOSXBdFnhnuetOhNIQEgvbZdmRXnkdo= MIME-Version: 1.0 Received: by 10.86.95.20 with SMTP id s20mr466429fgb.40.1234457858289; Thu, 12 Feb 2009 08:57:38 -0800 (PST) Date: Thu, 12 Feb 2009 17:57:38 +0100 Message-ID: <671bb5fc0902120857h3b789447q64a8c396728bdbd6@mail.gmail.com> From: Alexej Sokolov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: strange output in /var/log/messages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:57:40 -0000 Hello, I try now to debug a kernel module and I make some output with printf(9). But the text appears in /var/log/messages in very strange form: Feb 12 17:54:34 myhost kernel: b Feb 12 17:54:34 myhost kernel: eg Feb 12 17:54:34 myhost kernel: in Feb 12 17:54:34 myhost kernel: . Feb 12 17:54:34 myhost kernel: De Feb 12 17:54:34 myhost kernel: vice Feb 12 17:54:34 myhost kernel: U Feb 12 17:54:34 myhost kernel: ni Feb 12 17:54:34 myhost kernel: t: Could anyone explain the reason of this kind of output. And how can I correct it? Alexej From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:02:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1A9106564A; Thu, 12 Feb 2009 17:02:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4691B8FC18; Thu, 12 Feb 2009 17:02:34 +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.14.3/8.14.3) with ESMTP id n1CH1Jds014153; Thu, 12 Feb 2009 11:01:19 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1CH1JkT014152; Thu, 12 Feb 2009 11:01:19 -0600 (CST) (envelope-from brooks) Date: Thu, 12 Feb 2009 11:01:19 -0600 From: Brooks Davis To: Max Laier Message-ID: <20090212170119.GA7951@lor.one-eyed-alien.net> References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <200902121754.24536.max@love2party.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 12 Feb 2009 11:01:19 -0600 (CST) Cc: freebsd-hackers@freebsd.org, Sam Leffler , Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:02:35 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2009 at 05:54:24PM +0100, Max Laier wrote: > On Thursday 12 February 2009 17:42:19 Sam Leffler wrote: > > Max Laier wrote: > > > On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote: > > >> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > > >> many of the struct had holes, and some of which could be rearranged = to > > >> fill the gap. > > > > > > Interesting tool ... > > > > Someone should be able to do the same thing with coverity but it's > > obviously less effort to use something that exists. If I recall this > > and related tools like sparse use dwarf symbols which we don't generate > > by default. But with dtrace support I think we now can in fact generate > > the symbols easily so maybe someone can look at porting the tools... > > > > >> I've made the list available here[2]. So my questions > > >> are two fold: > > >> > > >> 1) Is it worth my time trying to rearrange structs? If so do you thi= nk > > >> many of my patches would be accepted? > > >> > > >> 2) Is there a way to find out the most heavily used structs? There a= re > > >> ~3600 structs, and ~2000 holes, it might be a waste of my time fixing > > >> the structs which are only used once. > > > > > > That's the tricky part. Rearranging the structs itself is not that > > > difficult, but identifying which should be rearranged and if, how ... > > > that's the problem. The fact that gaps might be different for 64 vs. = 32 > > > bit architectures has already been mentioned. > > > > > > In addition one needs to keep in mind that changing a struct layout i= s a > > > ABI change. So if we do identify structs that we want to change we > > > should do them all at once to keep the different versions down to a > > > minimum. > > > > > > So to answer your first question, submitting 101 patches to rearrange= 101 > > > structs is certainly a wasted effort. However, if you take a good lo= ok > > > at the 2000 holes, identify an interesting subset and submit a patch = to > > > fix that subset ... that would be a worthwhile effort ... IMHO. > > > > The other thing to keep in mind is that structure layout can have a > > noticeable effect on cache locality. Arbitrarily rearranging structure > > members can generate many more cache misses so one should sanity check > > changes w/ something like hwpmc. However as noted because layout may be > > platform-dependent even if something shows no change on x86 it may be a > > loss on another architecture and finding that performance drop may be > > really hard. >=20 > Let's not be too "glass half empty" about it, though. The same is true i= n the=20 > opposite direction. If we can identify and eliminate an unnecessary hole= in=20 > an important structure we might gain that same performance just by reshuf= fling=20 > a few lines. Remember however, that any structure that is exposed to userland can't just be changed. If it's part a syscall interface then the old layout must be supported. If that's going to be done, it's worth showing an actual, measurable improvement before writing the compatibility code. -- Brooks --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJlFXeXY6L6fI4GtQRAnSLAJ9G+i+7RJgY8FTkpq8itACSuPG9GgCfQdwV dWgA09bSR2xoZpaEM3+Xjd4= =8qBf -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:06:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AD761065673 for ; Thu, 12 Feb 2009 17:06:54 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6ED8FC1F for ; Thu, 12 Feb 2009 17:06:53 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A771B.dip.t-dialin.net [84.154.119.27]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id n1CH6nm5046032; Thu, 12 Feb 2009 18:06:52 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id n1CH6bVH032358; Thu, 12 Feb 2009 18:06:37 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n1CH75XW003391; Thu, 12 Feb 2009 18:07:10 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200902121707.n1CH75XW003391@fire.js.berklix.net> To: Jille Timmermans From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Thu, 12 Feb 2009 17:34:23 +0100." <49944F8F.5080104@quis.cx> Date: Thu, 12 Feb 2009 18:07:05 +0100 Sender: jhs@berklix.org Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:06:54 -0000 Hi, Reference: > From: Jille Timmermans > Date: Thu, 12 Feb 2009 17:34:23 +0100 > Message-id: <49944F8F.5080104@quis.cx> Jille Timmermans wrote: > Julian Stacey schreef: > >> 1) Is it worth my time trying to rearrange structs? > > > > I wondered whether as a sensitivity test, some version of gcc (or > > its competitor ?) might have capability to automatically re-order > > variables ? but found nothing in man gcc "Optimization Options". > There is a __packed attribute, I don't know what it exactly does and > whether it is an improvement. Ah: gcc -fpack-struct Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:51:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1300D106566C for ; Thu, 12 Feb 2009 17:51:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E21668FC1D for ; Thu, 12 Feb 2009 17:51:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8691C46B52; Thu, 12 Feb 2009 12:51:04 -0500 (EST) Date: Thu, 12 Feb 2009 17:51:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200902121717.47841.max@love2party.net> Message-ID: References: <200902121717.47841.max@love2party.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:51:05 -0000 On Thu, 12 Feb 2009, Max Laier wrote: > That's the tricky part. Rearranging the structs itself is not that > difficult, but identifying which should be rearranged and if, how ... that's > the problem. The fact that gaps might be different for 64 vs. 32 bit > architectures has already been mentioned. > > In addition one needs to keep in mind that changing a struct layout is a ABI > change. So if we do identify structs that we want to change we should do > them all at once to keep the different versions down to a minimum. Leaving aside the potential memory savings, etc, another potential use for a tool like this is actually in ABI monitoring and maintenance. I.e., run a tool that generates a description of the structure ABI of the kernel and user interfaces of the system, then run it intermittently to detect and report changes, perhaps correlated with symbol version information, etc. Right now we discover ABI changes in three ways: a developer changing the ABI realizes it has changed and (probably) deals with it, a developer reviews changes later and finds it, or a user finds it the hardware way due to application crashes, data loss, etc. Mechanizing tracking of API signatures, structure layout, etc, would help make all of this a lot more deterministic. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:52:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 482C91065692 for ; Thu, 12 Feb 2009 17:52:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2373B8FC1D for ; Thu, 12 Feb 2009 17:52:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B942246B53; Thu, 12 Feb 2009 12:52:09 -0500 (EST) Date: Thu, 12 Feb 2009 17:52:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Schouten In-Reply-To: <20090212163344.GR79178@hoeg.nl> Message-ID: References: <200902121717.47841.max@love2party.net> <20090212163344.GR79178@hoeg.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:52:10 -0000 On Thu, 12 Feb 2009, Ed Schouten wrote: > * Max Laier wrote: >> So to answer your first question, submitting 101 patches to rearrange 101 >> structs is certainly a wasted effort. However, if you take a good look at the >> 2000 holes, identify an interesting subset and submit a patch to fix that >> subset ... that would be a worthwhile effort ... IMHO. > > I guess it's also a wasted effort to reduce struct tty from 8xx to 7xx > bytes, because it still allocates 1024 bytes of memory using malloc(9). I > guess we should mainly focus on structures that are allocated using uma(9) > or are slightly bigger than 2^n. There are two things we can do: we can allocate using a specific UMA zone, but we could also retune our malloc buckets to waste less space while avoiding commiting memory to specific types where it's unhelpful (when UMA is used, we populate caches of pre-initialized instances, so we don't want to use UMA for things allocated, say, six times). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:52:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E867D1065742 for ; Thu, 12 Feb 2009 17:52:22 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 33DE88FC21 for ; Thu, 12 Feb 2009 17:52:21 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 0CA451B1212E; Thu, 12 Feb 2009 18:36:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 8580B1B12126; Thu, 12 Feb 2009 18:36:00 +0100 (CET) Message-Id: From: Stefan Lambrev To: Alexej Sokolov In-Reply-To: <671bb5fc0902120857h3b789447q64a8c396728bdbd6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 19:36:00 +0200 References: <671bb5fc0902120857h3b789447q64a8c396728bdbd6@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94/8984/Thu Feb 12 15:24:21 2009 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: strange output in /var/log/messages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:52:23 -0000 Hi, On Feb 12, 2009, at 6:57 PM, Alexej Sokolov wrote: > Hello, > I try now to debug a kernel module and I make some output with > printf(9). > But the text appears in /var/log/messages in very strange form: > > Feb 12 17:54:34 myhost kernel: b > Feb 12 17:54:34 myhost kernel: eg > Feb 12 17:54:34 myhost kernel: in > Feb 12 17:54:34 myhost kernel: . > Feb 12 17:54:34 myhost kernel: De > Feb 12 17:54:34 myhost kernel: vice > Feb 12 17:54:34 myhost kernel: U > Feb 12 17:54:34 myhost kernel: ni > Feb 12 17:54:34 myhost kernel: t: > > Could anyone explain the reason of this kind of output. And how can I > correct it? But those kernel messages are displayed properly if you type dmesg? If yes I think you can blame syslogd. > > > Alexej > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:53:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B2961065799 for ; Thu, 12 Feb 2009 17:53:19 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFA38FC2D for ; Thu, 12 Feb 2009 17:53:19 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1CHrI67043230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 09:53:18 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4994620E.5000804@freebsd.org> Date: Thu, 12 Feb 2009 09:53:18 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Max Laier References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> In-Reply-To: <200902121754.24536.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:53:19 -0000 Max Laier wrote: > On Thursday 12 February 2009 17:42:19 Sam Leffler wrote: > >> Max Laier wrote: >> >>> On Thursday 12 February 2009 15:08:22 Andrew Brampton wrote: >>> >>>> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that >>>> many of the struct had holes, and some of which could be rearranged to >>>> fill the gap. >>>> >>> Interesting tool ... >>> >> Someone should be able to do the same thing with coverity but it's >> obviously less effort to use something that exists. If I recall this >> and related tools like sparse use dwarf symbols which we don't generate >> by default. But with dtrace support I think we now can in fact generate >> the symbols easily so maybe someone can look at porting the tools... >> >> >>>> I've made the list available here[2]. So my questions >>>> are two fold: >>>> >>>> 1) Is it worth my time trying to rearrange structs? If so do you think >>>> many of my patches would be accepted? >>>> >>>> 2) Is there a way to find out the most heavily used structs? There are >>>> ~3600 structs, and ~2000 holes, it might be a waste of my time fixing >>>> the structs which are only used once. >>>> >>> That's the tricky part. Rearranging the structs itself is not that >>> difficult, but identifying which should be rearranged and if, how ... >>> that's the problem. The fact that gaps might be different for 64 vs. 32 >>> bit architectures has already been mentioned. >>> >>> In addition one needs to keep in mind that changing a struct layout is a >>> ABI change. So if we do identify structs that we want to change we >>> should do them all at once to keep the different versions down to a >>> minimum. >>> >>> So to answer your first question, submitting 101 patches to rearrange 101 >>> structs is certainly a wasted effort. However, if you take a good look >>> at the 2000 holes, identify an interesting subset and submit a patch to >>> fix that subset ... that would be a worthwhile effort ... IMHO. >>> >> The other thing to keep in mind is that structure layout can have a >> noticeable effect on cache locality. Arbitrarily rearranging structure >> members can generate many more cache misses so one should sanity check >> changes w/ something like hwpmc. However as noted because layout may be >> platform-dependent even if something shows no change on x86 it may be a >> loss on another architecture and finding that performance drop may be >> really hard. >> > > Let's not be too "glass half empty" about it, though. The same is true in the > opposite direction. If we can identify and eliminate an unnecessary hole in > an important structure we might gain that same performance just by reshuffling > a few lines. > > Certainly plugging holes can also be beneficial but just cautioning that changes of this sort need to be checked if made to critical data structures. OTOH there aren't that many that matter in practice. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:55:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5356C10656C8; Thu, 12 Feb 2009 17:55:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1088FC13; Thu, 12 Feb 2009 17:55:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C110346B53; Thu, 12 Feb 2009 12:55:09 -0500 (EST) Date: Thu, 12 Feb 2009 17:55:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200902121754.24536.max@love2party.net> Message-ID: References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Sam Leffler , Andrew Brampton , Joseph Koshy Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:55:11 -0000 On Thu, 12 Feb 2009, Max Laier wrote: >>> So to answer your first question, submitting 101 patches to rearrange 101 >>> structs is certainly a wasted effort. However, if you take a good look at >>> the 2000 holes, identify an interesting subset and submit a patch to fix >>> that subset ... that would be a worthwhile effort ... IMHO. >> >> The other thing to keep in mind is that structure layout can have a >> noticeable effect on cache locality. Arbitrarily rearranging structure >> members can generate many more cache misses so one should sanity check >> changes w/ something like hwpmc. However as noted because layout may be >> platform-dependent even if something shows no change on x86 it may be a >> loss on another architecture and finding that performance drop may be >> really hard. > > Let's not be too "glass half empty" about it, though. The same is true in > the opposite direction. If we can identify and eliminate an unnecessary > hole in an important structure we might gain that same performance just by > reshuffling a few lines. Well, I think we want to inform this through actual measurement. Right now, tools like hwpmc track cache misses by point in executable code, but what would be nice is if we could post-process to generate cache miss information by data structure field... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 18:03:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 225EC1065670 for ; Thu, 12 Feb 2009 18:03:15 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 98E3C8FC1A for ; Thu, 12 Feb 2009 18:03:14 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so385651fgb.35 for ; Thu, 12 Feb 2009 10:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pSpx4MgILOmNZbzA+yZfQuhHo+iUtcpkGwWob2F2VUQ=; b=IP5dRJ1funDfUg5eTdnzawRKyK0e2Hwucc5xlw1gDO7yXArNhCoErTdkTpqURWQgRf ZY016RP3rpE7+fOoaKvpX9vm2r5/wXQ6aQa5NHP+rcfZH5etxT1SyDeYHisN6mc5exQi quksFUyV5gAz251UEC9uzry4OhmEe/7GP1p2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XHsWIT6a2qQvuVCPh2UbKl5gpCkAeLaSYGt7W1bCqj5YFSaEZ201pxue8V3QwC0mOw 2VKzHLI5pp4LY1jZ/Mhqp+0/aP6Bm14xE+ASf8vQVqnMz2KXdk4epbStRfmacZA98TPA I5j87v8ub+USCR7LyJpsNQ1kGqOlYn4xigqIg= MIME-Version: 1.0 Received: by 10.86.76.20 with SMTP id y20mr123996fga.37.1234461793610; Thu, 12 Feb 2009 10:03:13 -0800 (PST) In-Reply-To: References: <671bb5fc0902120857h3b789447q64a8c396728bdbd6@mail.gmail.com> Date: Thu, 12 Feb 2009 19:03:13 +0100 Message-ID: <671bb5fc0902121003i4f9e606drc70e35bb0a91d0f8@mail.gmail.com> From: Alexej Sokolov To: Stefan Lambrev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: strange output in /var/log/messages X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:03:15 -0000 2009/2/12 Stefan Lambrev > Hi, > On Feb 12, 2009, at 6:57 PM, Alexej Sokolov wrote: > > Hello, > I try now to debug a kernel module and I make some output with printf(9). > But the text appears in /var/log/messages in very strange form: > > Feb 12 17:54:34 myhost kernel: b > Feb 12 17:54:34 myhost kernel: eg > Feb 12 17:54:34 myhost kernel: in > Feb 12 17:54:34 myhost kernel: . > Feb 12 17:54:34 myhost kernel: De > Feb 12 17:54:34 myhost kernel: vice > Feb 12 17:54:34 myhost kernel: U > Feb 12 17:54:34 myhost kernel: ni > Feb 12 17:54:34 myhost kernel: t: > > Could anyone explain the reason of this kind of output. And how can I > correct it? > > > But those kernel messages are displayed properly if you type dmesg? > If yes I think you can blame syslogd. > Yes , dmesg makes correct output :( > > > > Alexej > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > -- > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 20:31:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 253021065674 for ; Thu, 12 Feb 2009 20:31:51 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id A53BE8FC12 for ; Thu, 12 Feb 2009 20:31:50 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by bwz18 with SMTP id 18so1625497bwz.19 for ; Thu, 12 Feb 2009 12:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ma1VBqeEIk1y3bBe9mzEr4NP3lWv1JM4GGI6OXU2p2s=; b=fb0pDJDDsT+8e3bzuRbL9cUxObP7Nz1Os0aAQEw29uf1EJSfvO0hscX4FQNb4SBPiS ZSt9BasCNUOkEJiEJVggiI0Mw5sCQ+5mb+exXB9YTyGW8RkFWGzseWu93ARudYxSaKNR zsJingLhKI0Igg/2iq9Eb8u5ziaHjauztX+bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MugoObR5NzQXaV0woEE1elhYqDVTEmv31xUtj3TmCHepqgqIvVXI/HGIs2CVZIXp+v h1YLbxKGPCrNpp8zT5gNI1yB8k1Z4MbP30wbZFR4k4xYFIrcxzRSwWGOUd6pdBYJ/Zmt Be5e6dVJM3hLU6ql4A9y6/XQhL0n/ctdvgj38= MIME-Version: 1.0 Received: by 10.86.82.6 with SMTP id f6mr1646619fgb.42.1234470709411; Thu, 12 Feb 2009 12:31:49 -0800 (PST) Date: Thu, 12 Feb 2009 21:31:49 +0100 Message-ID: <671bb5fc0902121231v45317860ne3ff399c688261b1@mail.gmail.com> From: Alexej Sokolov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bus_setup_intr (9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 20:31:51 -0000 hello, from man: int bus_setup_intr(device_t dev, struct resource *r, int flags, driver_filter_t filter, driver_intr_t ithread, void *arg, void **cookiep); The function filter returns value of type driver_filter_t (int). This function will run if interrupt happen. Question: Which function will get this returned "int value" of filter function. Or How/where can I catch it ? Alexej From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 21:15:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E1031065672 for ; Thu, 12 Feb 2009 21:15:09 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 43A988FC08 for ; Thu, 12 Feb 2009 21:15:09 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 7CF795B21 for ; Thu, 12 Feb 2009 13:15:08 -0800 (PST) To: freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 12 Feb 2009 09:53:18 PST." <4994620E.5000804@freebsd.org> References: <200902121717.47841.max@love2party.net> <4994516B.8060703@freebsd.org> <200902121754.24536.max@love2party.net> <4994620E.5000804@freebsd.org> Date: Thu, 12 Feb 2009 13:15:08 -0800 From: Bakul Shah Message-Id: <20090212211508.7CF795B21@mail.bitblocks.com> Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:15:09 -0000 > >>>> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that > >>>> many of the struct had holes, and some of which could be rearranged to > >>>> fill the gap. ... > Certainly plugging holes can also be beneficial but just cautioning that > changes of this sort need to be checked if made to critical data > structures. OTOH there aren't that many that matter in practice. But why do it? Are the benefits worth churning any ABIs? From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 21:22:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E2810656C7 for ; Thu, 12 Feb 2009 21:22:09 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9D98FC16 for ; Thu, 12 Feb 2009 21:22:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from rajreddy-lnx.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KEY00E65Z7O2F50@asmtp021.mac.com> for freebsd-hackers@freebsd.org; Thu, 12 Feb 2009 12:21:25 -0800 (PST) Message-id: From: Marcel Moolenaar To: Jille Timmermans In-reply-to: <49944F8F.5080104@quis.cx> Date: Thu, 12 Feb 2009 12:21:24 -0800 References: <200902121549.n1CFnLdt002361@fire.js.berklix.net> <49944F8F.5080104@quis.cx> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-hackers@freebsd.org, Julian Stacey , Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:22:10 -0000 On Feb 12, 2009, at 8:34 AM, Jille Timmermans wrote: > Julian Stacey schreef: >>> 1) Is it worth my time trying to rearrange structs? >> I wondered whether as a sensitivity test, some version of gcc (or >> its competitor ?) might have capability to automatically re-order >> variables ? but found nothing in man gcc "Optimization Options". > There is a __packed attribute, I don't know what it exactly does and > whether it is an improvement. > __packed is always a gross pessimization. The side-effect of packing a structure is that the alignment of the structure drops to 1. That means that any field will be read 1 byte at a time and reconstructed by logical operations. For best results, __packed should be used with __aligned(X), in case __packed is needed of course to address the side- effect. Of course multi-byte fields that are unaligned in the structure as the result of packing, will still be read in parts. In other words: don't use __packed when you don't have to. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 21:24:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D541065670 for ; Thu, 12 Feb 2009 21:24:37 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from joe.mail.tiscali.it (joe.mail.tiscali.it [213.205.33.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42FED8FC14 for ; Thu, 12 Feb 2009 21:24:37 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from newluxor.wired.org (94.36.93.23) by joe.mail.tiscali.it (8.0.022) id 496E020E01A1CD73; Thu, 12 Feb 2009 22:13:00 +0100 Message-ID: <499490D7.5020306@oltrelinux.com> Date: Thu, 12 Feb 2009 22:12:55 +0100 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.18 (X11/20081214) MIME-Version: 1.0 To: Alexej Sokolov References: <671bb5fc0902121231v45317860ne3ff399c688261b1@mail.gmail.com> In-Reply-To: <671bb5fc0902121231v45317860ne3ff399c688261b1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: bus_setup_intr (9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:24:37 -0000 Alexej Sokolov wrote: > from man: > int > bus_setup_intr(device_t dev, struct resource *r, int flags, > driver_filter_t filter, driver_intr_t ithread, void *arg, > void **cookiep); > > The function filter returns value of type driver_filter_t (int). This > function will run if interrupt happen. > > Question: Which function will get this returned "int value" of filter > function. Or How/where can I catch it ? > the interrupt handling framework: see sys/kern/kern_intr.c::intr_event_handle(). bye, P. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 21:40:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD49C1065704 for ; Thu, 12 Feb 2009 21:40:13 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id AD2608FC1F for ; Thu, 12 Feb 2009 21:40:13 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so478863rvb.43 for ; Thu, 12 Feb 2009 13:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eygl0YBoxqzJaS4xgdx8AXDccsX0Lt4W8qpbt8cTHd4=; b=bq8fPW2ec8Nzuxh7s2W4FoFMABqq27U63UppxH7LkJyYvLqIOO3Xo6+a3vwautPeh4 ZSizDvLoTdSxbRfVWKVLYMUpppz0Bk0fgSAY2AerIaoMS+qHPRJcVDalF00pZ3aql8R6 1IEt145+mK3PDqNBgbT2kFjpvVslat2LGWkU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GhMMQdet+bbP/hWK1OyLVbaSQxnrirBgz/dH/QOk2JW1KzBsrUyUqTwBAfi9L3GLTi OQxNHsLaHvgGajeZaoB1R7wuVvv3PTyb8/hnRkUs3ffhtGo9sRRFWTQNXtV4u8+T6Wl7 at2MYPJTFDTw3S9X9LrsX2X5tg6F8MHyapNfo= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.141.179.5 with SMTP id g5mr102520rvp.76.1234472875792; Thu, 12 Feb 2009 13:07:55 -0800 (PST) In-Reply-To: <671bb5fc0902121231v45317860ne3ff399c688261b1@mail.gmail.com> References: <671bb5fc0902121231v45317860ne3ff399c688261b1@mail.gmail.com> Date: Thu, 12 Feb 2009 13:07:55 -0800 X-Google-Sender-Auth: 2b1ecfdd7aad97a8 Message-ID: <3c1674c90902121307k7cbe71d0of4940f3876f7a01c@mail.gmail.com> From: Kip Macy To: Alexej Sokolov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: bus_setup_intr (9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:40:15 -0000 in HEAD, see intr_event_handle in sys/kern/kern_intr.c Cheers, Kip On Thu, Feb 12, 2009 at 12:31 PM, Alexej Sokolov wrote: > hello, > > from man: > int > bus_setup_intr(device_t dev, struct resource *r, int flags, > driver_filter_t filter, driver_intr_t ithread, void *arg, > void **cookiep); > > The function filter returns value of type driver_filter_t (int). This > function will run if interrupt happen. > > Question: Which function will get this returned "int value" of filter > function. Or How/where can I catch it ? > > Alexej > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 22:05:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A7DA106566B for ; Thu, 12 Feb 2009 22:05:43 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 688968FC16 for ; Thu, 12 Feb 2009 22:05:43 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n1CM5bo09672; Thu, 12 Feb 2009 14:05:37 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n1CM5bV04513; Thu, 12 Feb 2009 14:05:37 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 12 Feb 2009 14:05:37 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Marcel Moolenaar In-Reply-To: Message-ID: References: <200902121549.n1CFnLdt002361@fire.js.berklix.net> <49944F8F.5080104@quis.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Julian Stacey , Jille Timmermans , Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:05:44 -0000 On Thu, 12 Feb 2009, Marcel Moolenaar wrote: > > On Feb 12, 2009, at 8:34 AM, Jille Timmermans wrote: > >> Julian Stacey schreef: >>>> 1) Is it worth my time trying to rearrange structs? >>> I wondered whether as a sensitivity test, some version of gcc (or >>> its competitor ?) might have capability to automatically re-order >>> variables ? but found nothing in man gcc "Optimization Options". >> There is a __packed attribute, I don't know what it exactly does and >> whether it is an improvement. >> > > __packed is always a gross pessimization. The side-effect of > packing a structure is that the alignment of the structure > drops to 1. That means that any field will be read 1 byte at > a time and reconstructed by logical operations. The other alternative is to read/write that member by unaligned operations, on platforms that support it. This also typically comes with a performance penalty, of course. Usually it means the hardware reads the two words that overlap the member and pieces it back together. But on such a platform the software does not need to handle it specially; it executes the same instruction, but it takes more time. The only reason to use this would be (1) if you needed to have your structure occupy as little memory as possible; for instance, if your structure had two elements, one 'int' and one 'char', and you had 1 billion of them, using __packed__ would save you 3 gigabytes. Or (2) if you need to conform to an externally defined data structure that already does this. Most places in the kernel, I don't think either of these would be true. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 02:41:28 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D200E10656DD for ; Fri, 13 Feb 2009 02:41:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 945B18FC0A for ; Fri, 13 Feb 2009 02:41:28 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n1D2fO06016122; Thu, 12 Feb 2009 21:41:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 12 Feb 2009 21:41:24 -0500 To: Andrew Brampton , freebsd-hackers@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:41:29 -0000 At 2:08 PM +0000 2/12/09, Andrew Brampton wrote: >I found this useful tool called pahole[1]. It basically finds holes >within structs, so for example on my 64bit machine this struct: > >struct test { > int foo; > const char *bar; > int blah; >} > >Would have a hole between foo and bar of 4 bytes because both for and >bar have been aligned on a 8 byte boundary, and the struct would also >have 4 bytes of padding on the end. However, if I simply moved blah >between foo and bar then the struct has shrunk by 8 bytes, which could >be a good thing. This could also help keep structs within single cache >lines, and just generally keep memory usage to a minimum when the >struct is used many times (for example in an array). > >So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that >many of the struct had holes, and some of which could be rearranged to >fill the gap. I've made the list available here[2]. So my questions >are two fold: > >1) Is it worth my time trying to rearrange structs? If so do you >think many of my patches would be accepted? In most cases, re-arranging things is probably not worth it. That's just my opinion, though. >2) Is there a way to find out the most heavily used structs? There >are ~3600 structs, and ~2000 holes, it might be a waste of my time >fixing the structs which are only used once. I used a similar tool (which I wrote myself) when making some changes to 'struct kinfo_proc' some time ago. The first issue which comes up is that a hole on one hardware platform may not be a hole on other platforms. I think it is perhaps useful to shuffle around fields in a struct if you're doing some *other* change at the same time. A tool like this pahole program seems like a good idea at those times. And I do think it can be useful to document the holes which exist, especially if you take the time to figure out what is happening on different platforms which have different alignment requirements. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 12:21:09 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AC821065670 for ; Fri, 13 Feb 2009 12:21:09 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 820348FC29 for ; Fri, 13 Feb 2009 12:21:08 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 15958 invoked from network); 13 Feb 2009 11:54:26 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 13 Feb 2009 11:54:26 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id 7473E1031D; Fri, 13 Feb 2009 11:54:26 +0000 (UTC) Date: Fri, 13 Feb 2009 11:54:26 +0000 From: ttw+bsd@cobbled.net To: hackers@freebsd.org Message-ID: <20090213115426.GA15211@holyman.cobbled.net> Mail-Followup-To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline X-Mailman-Approved-At: Fri, 13 Feb 2009 12:58:48 +0000 Cc: Subject: removal of NGROUPS_MAX dependancy from base X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 12:21:09 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline attached is the first in a series of patches that is intended to remove the current limitation on group membership. this patch should remove the dependancy on the definition of NGROUPS_MAX as a static constant and implement it as a writable sysconf variable of the same. it should also make the necessary changes to the codebase to support those. i need some guidance as to what i should re-define NGROUPS_MAX to be (so that code that depends on it can continue to operate, i'm thinking just make it 16 but perhaps it would be worth extending the default while we're at it to something like 64??). i also need feedback on any braindamage in the current changes. the next step will be to extend the kernel groups and map them back to the user structs / calls. finally i'll extend the user groups and implement those calls. nb: not tested the code (it builds) ... was intending to test it on my XEN box but only just realised that Xen on amd64 isn't working. :-( happy for any questions that may help guide the process. --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="remove-ngroups_max,v1r2.patch" Index: contrib/openpam/lib/openpam_borrow_cred.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_borrow_cred.c,v retrieving revision 1.1.1.9 diff -b -u -r1.1.1.9 openpam_borrow_cred.c --- contrib/openpam/lib/openpam_borrow_cred.c 21 Dec 2007 11:49:29 -0000 1.1.1.9 +++ contrib/openpam/lib/openpam_borrow_cred.c 4 Feb 2009 16:38:46 -0000 @@ -60,6 +60,7 @@ struct pam_saved_cred *scred; const void *scredp; int r; + int ngroups ; ENTERI(pwd->pw_uid); r = pam_get_data(pamh, PAM_SAVED_CRED, &scredp); @@ -73,26 +74,55 @@ (int)geteuid()); RETURNC(PAM_PERM_DENIED); } - scred = calloc(1, sizeof *scred); - if (scred == NULL) - RETURNC(PAM_BUF_ERR); - scred->euid = geteuid(); - scred->egid = getegid(); - r = getgroups(NGROUPS_MAX, scred->groups); - if (r < 0) { - FREE(scred); - RETURNC(PAM_SYSTEM_ERR); - } - scred->ngroups = r; +/* get the maximum number of system groups */ +#if _POSIX_VERSION > 199212 + ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + ngroups = NGROUPS_MAX ; +#else + ngroups = _NGROUPS_COMPAT ; +#endif +/* initally allocate enough memory for max_groups */ + scred = malloc( sizeof(struct pam_saved_cred) + + ngroups*sizeof(gid_t) ) ; + if( scred == NULL ) + RETURNC( PAM_BUF_ERR ) ; +/* set the save values */ + scred->euid = geteuid() ; + scred->egid = getegid() ; +/* save groups into our (probably) oversized memory allocation */ + r = getgroups( ngroups, scred->groups ) ; + if( r < 0 ) { + FREE( scred ) ; /* call PAM's free macro */ + RETURNC( PAM_SYSTEM_ERR ) ; + } ; + scred->ngroups = r ; + ngroups = r < ngroups ? r : ngroups ; /* choose the smallest */ + /* ... number of groups to allocate */ + ngroups = ngroups < _NGROUPS_COMPAT ? ngroups : _NGROUPS_COMPAT ; + /* but keep it within expected minimum value */ + /* XXX: we don't really want this but until we get + * educated on the implications this is probably safe + * and certainaly compatible */ +/* realloc, releasing unneeded memory */ + scred = realloc( (void*)scred, + sizeof(struct pam_saved_cred)+ngroups*sizeof(gid_t) ) ; + /* nb: we ignore failure and try to store the larger + * ... structure as initially requested. catching the + * ... error in 'pam_set_data' if neccessary. */ +/* save the credentials to PAM user data area */ r = pam_set_data(pamh, PAM_SAVED_CRED, scred, &openpam_free_data); if (r != PAM_SUCCESS) { FREE(scred); RETURNC(r); } +/* set the new credentials */ if (geteuid() == pwd->pw_uid) RETURNC(PAM_SUCCESS); if (initgroups(pwd->pw_name, pwd->pw_gid) < 0 || - setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0) { + setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0) + { + /* if any of the set calls failed, then restore and fail */ openpam_restore_cred(pamh); RETURNC(PAM_SYSTEM_ERR); } Index: contrib/openpam/lib/openpam_impl.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_impl.h,v retrieving revision 1.1.1.17 diff -b -u -r1.1.1.17 openpam_impl.h --- contrib/openpam/lib/openpam_impl.h 21 Dec 2007 11:49:29 -0000 1.1.1.17 +++ contrib/openpam/lib/openpam_impl.h 5 Feb 2009 15:41:19 -0000 @@ -110,13 +110,17 @@ int env_size; }; -#ifdef NGROUPS_MAX +#if _POSIX_VERSION > 199212 #define PAM_SAVED_CRED "pam_saved_cred" struct pam_saved_cred { uid_t euid; gid_t egid; - gid_t groups[NGROUPS_MAX]; int ngroups; + gid_t groups[]; + /* keep this last so that we can simply + .. over-allocate the amount of space + .. nb: don't use sizeof' unless you adjust + .. for the number of groups */ }; #endif Index: include/rpc/auth_unix.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/include/rpc/auth_unix.h,v retrieving revision 1.11 diff -b -u -r1.11 auth_unix.h --- include/rpc/auth_unix.h 23 Mar 2002 17:24:55 -0000 1.11 +++ include/rpc/auth_unix.h 14 Jan 2009 11:15:21 -0000 @@ -52,7 +52,7 @@ #define MAX_MACHINE_NAME 255 /* gids compose part of a credential; there may not be more than 16 of them */ -#define NGRPS 16 +#define AUTH_UNIX_NGROUPS 16 /* * Unix style credentials. Index: lib/libc/rpc/auth_unix.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/auth_unix.c,v retrieving revision 1.18 diff -b -u -r1.18 auth_unix.c --- lib/libc/rpc/auth_unix.c 14 Jun 2007 20:07:35 -0000 1.18 +++ lib/libc/rpc/auth_unix.c 4 Feb 2009 15:31:57 -0000 @@ -182,27 +182,48 @@ * Returns an auth handle with parameters determined by doing lots of * syscalls. */ -AUTH * +AUTH* authunix_create_default() { - int len; char machname[MAXHOSTNAMELEN + 1]; + AUTH* auth_unix ; uid_t uid; gid_t gid; - gid_t gids[NGROUPS_MAX]; - - if (gethostname(machname, sizeof machname) == -1) - abort(); - machname[sizeof(machname) - 1] = 0; + gid_t *gids ; + uint ngroups ; + uint max_ngroups ; + +/* get hostname or fail */ + if( gethostname(machname,sizeof(machname)) == -1 ) + abort() ; + machname[sizeof(machname)-1] = 0 ; /* add a null terminator */ +/* set uid/gid from current effective values */ uid = geteuid(); gid = getegid(); - if ((len = getgroups(NGROUPS_MAX, gids)) < 0) - abort(); - if (len > NGRPS) - len = NGRPS; - /* XXX: interface problem; those should all have been unsigned */ - return (authunix_create(machname, (int)uid, (int)gid, len, - (int *)gids)); +/* set the group set */ +#if _POSIX_VERSION > 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = 16 ; +#endif + gids = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( gids == NULL ) + abort () ; + if( (ngroups=getgroups(max_ngroups,gids)) < 0 ) { + free( gids ) ; + abort() ; + } +/* clip the groups to a transmissable size */ + if( ngroups > AUTH_UNIX_NGROUPS ) + ngroups = AUTH_UNIX_NGROUPS ; +/* XXX: interface problem; those should all have been unsigned */ + auth_unix = authunix_create( machname, + (int)uid, (int)gid, (int)ngroups, + (int*)gids ) ; + free( (void*)gids ) ; + return( auth_unix ) ; } /* Index: lib/libc/rpc/authunix_prot.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/authunix_prot.c,v retrieving revision 1.10 diff -b -u -r1.10 authunix_prot.c --- lib/libc/rpc/authunix_prot.c 20 Nov 2007 01:51:20 -0000 1.10 +++ lib/libc/rpc/authunix_prot.c 4 Feb 2009 16:03:29 -0000 @@ -67,13 +67,14 @@ paup_gids = &p->aup_gids; - if (xdr_u_long(xdrs, &(p->aup_time)) - && xdr_string(xdrs, &(p->aup_machname), MAX_MACHINE_NAME) - && xdr_int(xdrs, &(p->aup_uid)) - && xdr_int(xdrs, &(p->aup_gid)) - && xdr_array(xdrs, (char **) paup_gids, - &(p->aup_len), NGRPS, sizeof(int), (xdrproc_t)xdr_int) ) { - return (TRUE); + if( xdr_u_long(xdrs,&(p->aup_time)) && + xdr_string(xdrs,&(p->aup_machname),MAX_MACHINE_NAME) && + xdr_int(xdrs,&(p->aup_uid)) && + xdr_int(xdrs,&(p->aup_gid)) && + xdr_array(xdrs,(char**)paup_gids,&(p->aup_len), + AUTH_UNIX_NGROUPS,sizeof(int),(xdrproc_t)xdr_int) ) + { + return( TRUE ) ; } - return (FALSE); + return( FALSE ) ; } Index: lib/libc/rpc/netname.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/netname.c,v retrieving revision 1.8 diff -b -u -r1.8 netname.c --- lib/libc/rpc/netname.c 16 Oct 2004 06:11:35 -0000 1.8 +++ lib/libc/rpc/netname.c 14 Jan 2009 01:29:47 -0000 @@ -61,6 +61,7 @@ #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 256 #endif + #ifndef NGROUPS #define NGROUPS 16 #endif Index: lib/libc/rpc/netnamer.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/netnamer.c,v retrieving revision 1.12 diff -b -u -r1.12 netnamer.c --- lib/libc/rpc/netnamer.c 10 Mar 2005 00:58:21 -0000 1.12 +++ lib/libc/rpc/netnamer.c 3 Feb 2009 17:55:48 -0000 @@ -69,7 +69,6 @@ #ifndef NGROUPS #define NGROUPS 16 #endif - /* * Convert network-name into unix credential */ @@ -104,7 +103,7 @@ return (0); } *gidp = (gid_t) atol(p); - for (gidlen = 0; gidlen < NGROUPS; gidlen++) { + for (gidlen = 0; gidlen < _NGROUPS_RPC_MAX; gidlen++) { p = strsep(&res, "\n,"); if (p == NULL) break; @@ -157,7 +156,7 @@ static int _getgroups(uname, groups) char *uname; - gid_t groups[NGROUPS]; + gid_t groups[_NGROUPS_RPC_MAX]; { gid_t ngroups = 0; struct group *grp; @@ -169,10 +168,11 @@ while ((grp = getgrent())) { for (i = 0; grp->gr_mem[i]; i++) if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups == NGROUPS) { + if( ngroups == _NGROUPS_RPC_MAX ) { #ifdef DEBUG - fprintf(stderr, - "initgroups: %s is in too many groups\n", uname); + fprintf( stderr, + "initgroups: %s is in too many groups\n", + uname ) ; #endif goto toomany; } Index: lib/libc/rpc/svc_auth_des.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/svc_auth_des.c,v retrieving revision 1.9 diff -b -u -r1.9 svc_auth_des.c --- lib/libc/rpc/svc_auth_des.c 22 Mar 2002 23:18:37 -0000 1.9 +++ lib/libc/rpc/svc_auth_des.c 3 Feb 2009 17:51:01 -0000 @@ -452,7 +452,7 @@ short uid; /* cached uid */ short gid; /* cached gid */ short grouplen; /* length of cached groups */ - short groups[NGROUPS]; /* cached groups */ + short groups[_NGROUPS_RPC_MAX]; /* cached groups */ }; /* Index: lib/libc/rpc/svc_auth_unix.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/svc_auth_unix.c,v retrieving revision 1.11 diff -b -u -r1.11 svc_auth_unix.c --- lib/libc/rpc/svc_auth_unix.c 16 Oct 2004 06:11:35 -0000 1.11 +++ lib/libc/rpc/svc_auth_unix.c 4 Feb 2009 16:04:10 -0000 @@ -68,7 +68,7 @@ struct area { struct authunix_parms area_aup; char area_machname[MAX_MACHINE_NAME+1]; - int area_gids[NGRPS]; + int area_gids[AUTH_UNIX_NGROUPS] ; } *area; u_int auth_len; size_t str_len, gid_len; @@ -98,7 +98,7 @@ aup->aup_uid = (int)IXDR_GET_INT32(buf); aup->aup_gid = (int)IXDR_GET_INT32(buf); gid_len = (size_t)IXDR_GET_U_INT32(buf); - if (gid_len > NGRPS) { + if( gid_len > AUTH_UNIX_NGROUPS ) { stat = AUTH_BADCRED; goto done; } Index: lib/librpcsec_gss/svc_rpcsec_gss.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/librpcsec_gss/svc_rpcsec_gss.c,v retrieving revision 1.4 diff -b -u -r1.4 svc_rpcsec_gss.c --- lib/librpcsec_gss/svc_rpcsec_gss.c 3 Nov 2008 10:38:00 -0000 1.4 +++ lib/librpcsec_gss/svc_rpcsec_gss.c 5 Feb 2009 16:09:37 -0000 @@ -127,7 +127,7 @@ rpc_gss_ucred_t cl_ucred; /* unix-style credentials */ bool_t cl_done_callback; /* TRUE after call */ void *cl_cookie; /* user cookie from callback */ - gid_t cl_gid_storage[NGRPS]; + gid_t cl_gid_storage[AUTH_UNIX_NGROUPS]; gss_OID cl_mech; /* mechanism */ gss_qop_t cl_qop; /* quality of protection */ u_int cl_seq; /* current sequence number */ @@ -578,7 +578,7 @@ getpwuid_r(uid, &pwd, buf, sizeof(buf), &pw); if (pw) { - int len = NGRPS; + int len = AUTH_UNIX_NGROUPS; uc->uid = pw->pw_uid; uc->gid = pw->pw_gid; uc->gidlist = client->cl_gid_storage; Index: sys/compat/svr4/svr4_misc.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/compat/svr4/svr4_misc.c,v retrieving revision 1.101 diff -b -u -r1.101 svr4_misc.c --- sys/compat/svr4/svr4_misc.c 21 Apr 2008 21:24:08 -0000 1.101 +++ sys/compat/svr4/svr4_misc.c 14 Jan 2009 11:58:47 -0000 @@ -710,7 +710,12 @@ *retval = 0; break; case SVR4_CONFIG_NGROUPS: - *retval = NGROUPS_MAX; + *retval = _NGROUPS_COMPAT; + /* XXX: this should pull the value + * from sysctl but i cannot find + * the definitions for the similar + * varaibles here (i.e. 'maxproc') + */ break; case SVR4_CONFIG_CHILD_MAX: *retval = maxproc; Index: sys/fs/portalfs/portal.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/fs/portalfs/portal.h,v retrieving revision 1.10 diff -b -u -r1.10 portal.h --- sys/fs/portalfs/portal.h 6 Jan 2005 18:10:40 -0000 1.10 +++ sys/fs/portalfs/portal.h 16 Jan 2009 23:44:50 -0000 @@ -43,7 +43,7 @@ int pcr_flag; /* File open mode */ uid_t pcr_uid; /* From ucred */ short pcr_ngroups; /* From ucred */ - gid_t pcr_groups[NGROUPS]; /* From ucred */ + gid_t pcr_groups[_NGROUPS_COMPAT]; /* From ucred */ }; #ifdef _KERNEL Index: sys/i386/ibcs2/ibcs2_misc.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/i386/ibcs2/ibcs2_misc.c,v retrieving revision 1.70 diff -b -u -r1.70 ibcs2_misc.c --- sys/i386/ibcs2/ibcs2_misc.c 13 Jan 2008 14:44:07 -0000 1.70 +++ sys/i386/ibcs2/ibcs2_misc.c 14 Jan 2009 12:24:56 -0000 @@ -659,14 +659,14 @@ struct thread *td; struct ibcs2_getgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t iset[_NGROUPS_COMPAT]; + gid_t gp[_NGROUPS_COMPAT]; u_int i, ngrp; int error; if (uap->gidsetsize < 0) return (EINVAL); - ngrp = MIN(uap->gidsetsize, NGROUPS_MAX); + ngrp = MIN(uap->gidsetsize, _NGROUPS_COMPAT); error = kern_getgroups(td, &ngrp, gp); if (error) return (error); @@ -685,11 +685,11 @@ struct thread *td; struct ibcs2_setgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t iset[_NGROUPS_COMPAT]; + gid_t gp[_NGROUPS_COMPAT]; int error, i; - if (uap->gidsetsize < 0 || uap->gidsetsize > NGROUPS_MAX) + if (uap->gidsetsize < 0 || uap->gidsetsize > _NGROUPS_COMPAT) return (EINVAL); if (uap->gidsetsize && uap->gidset) { error = copyin(uap->gidset, iset, sizeof(ibcs2_gid_t) * @@ -789,8 +789,13 @@ return 0; case IBCS2_SC_NGROUPS_MAX: - mib[1] = KERN_NGROUPS; - break; + /* XXX: IBCS2 compat with group limits not known to + * me, so i'll just return a compatibile/safe limit + * for now */ + PROC_LOCK(p) ; + td->td_retval[0] = _NGROUPS_COMPAT ; + PROC_UNLOCK(p) ; + return( 0 ) ; case IBCS2_SC_OPEN_MAX: PROC_LOCK(p); Index: sys/kern/kern_mib.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/kern/kern_mib.c,v retrieving revision 1.93 diff -b -u -r1.93 kern_mib.c --- sys/kern/kern_mib.c 28 Jan 2009 19:58:05 -0000 1.93 +++ sys/kern/kern_mib.c 4 Feb 2009 13:15:06 -0000 @@ -124,8 +124,8 @@ SYSCTL_INT(_kern, KERN_POSIX1, posix1version, CTLFLAG_RD, 0, _POSIX_VERSION, "Version of POSIX attempting to comply to"); -SYSCTL_INT(_kern, KERN_NGROUPS, ngroups, CTLFLAG_RD, - 0, NGROUPS_MAX, "Maximum number of groups a user can belong to"); +SYSCTL_INT(_kern, KERN_NGROUPS, ngroups, CTLFLAG_RW, + 0, _NGROUPS_COMPAT, "Maximum number of groups allocated to a user"); SYSCTL_INT(_kern, KERN_JOB_CONTROL, job_control, CTLFLAG_RD, 0, 1, "Whether job control is available"); Index: sys/sys/param.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/sys/param.h,v retrieving revision 1.382 diff -b -u -r1.382 param.h --- sys/sys/param.h 28 Jan 2009 17:57:16 -0000 1.382 +++ sys/sys/param.h 4 Feb 2009 14:11:55 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800062 /* Master, propagated to newvers */ +#define __FreeBSD_version 800060 /* Master, propagated to newvers */ #ifndef LOCORE #include @@ -77,7 +77,8 @@ #define MAXLOGNAME 17 /* max login name length (incl. NUL) */ #define MAXUPRC CHILD_MAX /* max simultaneous processes */ #define NCARGS ARG_MAX /* max bytes for an exec function */ -#define NGROUPS NGROUPS_MAX /* max number groups */ +#define NGROUPS _NGROUPS_COMPAT + /* depreciated check sysctl/sysconf for NGROUPS_MAX value instead */ #define NOFILE OPEN_MAX /* max open files per process */ #define NOGROUP 65535 /* marker for empty group set member */ #define MAXHOSTNAMELEN 256 /* max hostname size */ Index: sys/sys/syslimits.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/sys/syslimits.h,v retrieving revision 1.23 diff -b -u -r1.23 syslimits.h --- sys/sys/syslimits.h 29 May 2007 15:14:46 -0000 1.23 +++ sys/sys/syslimits.h 3 Feb 2009 18:02:22 -0000 @@ -54,7 +54,6 @@ #define MAX_CANON 255 /* max bytes in term canon input line */ #define MAX_INPUT 255 /* max bytes in terminal input */ #define NAME_MAX 255 /* max bytes in a file name */ -#define NGROUPS_MAX 16 /* max supplemental group id's */ #ifndef OPEN_MAX #define OPEN_MAX 64 /* max open files per process */ #endif @@ -66,9 +65,35 @@ * We leave the following values undefined to force applications to either * assume conservative values or call sysconf() to get the current value. * - * HOST_NAME_MAX + * HOST_NAME_MAX NGROUPS_MAX * * (We should do this for most of the values currently defined here, * but many programs are not prepared to deal with this yet.) */ +/* + * here are some reference values in respect of the obsoleted + * NGROUPS_MAX value. + * nb: some apps appear to check NGROUPS_MAX as meaning that + * ... system has user groups (i.e. to #ifdef chunks of code). + * ... this is easy to change but maybe historically defined? + */ +#define _NGROUPS_RPC_MAX 16 /* reference only */ + /* nb: this is the old system max, so named + * ... because it's limit appears to + * ... have been derived from a limitation + * ... in RPC (and thereby NFS), where it's + * ... the max number of groups we can exchange */ +#define _NGROUPS_COMPAT _NGROUPS_RPC_MAX /* reference only */ + /* nb: although this is defined as equal to the rpc + * ... limit, i have defined it distintly so that + * ... we may distinguish (whilst updating) usage + * ... that is correctly explicit (i.e. should be 16) + * ... and usage that is only 16 because of an expected + * ... convention. hopefully we may remove these and + * ... define additional _NGROUPS_*_MAX for those defined + * ... uses. */ +#define _NGROUPS_SYS_MAX 65536 /* reference only */ + /* nb: the idea's to have this extensible + * ... indefinately, this is what linux have and + * ... should more than cover immediate needs */ #endif Index: usr.bin/catman/catman.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.bin/catman/catman.c,v retrieving revision 1.14 diff -b -u -r1.14 catman.c --- usr.bin/catman/catman.c 5 Dec 2005 14:22:12 -0000 1.14 +++ usr.bin/catman/catman.c 8 Feb 2009 22:51:44 -0000 @@ -93,8 +93,9 @@ enum Ziptype {NONE, BZIP, GZIP}; static uid_t uid; -static gid_t gids[NGROUPS_MAX]; +static gid_t *gids; static int ngids; +static int max_ngroups ; static int starting_dir; static char tmp_file[MAXPATHLEN]; struct stat test_st; @@ -789,7 +790,15 @@ /* NOTREACHED */ } } - ngids = getgroups(NGROUPS_MAX, gids); +/* allocate memory for group ids */ +#if _POSIX_VERSION > 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + ngids = getgroups( max_ngroups, gids ) ; if ((starting_dir = open(".", 0)) < 0) { err(1, "."); } Index: usr.bin/newgrp/newgrp.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.bin/newgrp/newgrp.c,v retrieving revision 1.2 diff -b -u -r1.2 newgrp.c --- usr.bin/newgrp/newgrp.c 30 Oct 2003 15:14:34 -0000 1.2 +++ usr.bin/newgrp/newgrp.c 9 Feb 2009 22:05:53 -0000 @@ -146,9 +146,10 @@ static void addgroup(const char *grpname) { - gid_t grps[NGROUPS_MAX]; + gid_t *grps; long lgid; - int dbmember, i, ngrps; + int dbmember, i, ngrps, max_ngroups ; + /* XXX: should 'max_ngroups' be a static const variable? */ gid_t egid; struct group *grp; char *ep, *pass; @@ -185,9 +186,21 @@ } } - if ((ngrps = getgroups(NGROUPS_MAX, (gid_t *)grps)) < 0) { +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + grps = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( grps == NULL ) { + warn( "group set memory allocation" ) ; + return ; + } + if( (ngrps=getgroups(max_ngroups,(gid_t*)grps)) < 0 ) { warn("getgroups"); - return; + goto error_free ; } /* Remove requested gid from supp. list if it exists. */ @@ -201,7 +214,7 @@ if (setgroups(ngrps, (const gid_t *)grps) < 0) { PRIV_END; warn("setgroups"); - return; + goto error_free ; } PRIV_END; } @@ -210,14 +223,14 @@ if (setgid(grp->gr_gid)) { PRIV_END; warn("setgid"); - return; + goto error_free ; } PRIV_END; grps[0] = grp->gr_gid; /* Add old effective gid to supp. list if it does not exist. */ if (egid != grp->gr_gid && !inarray(egid, grps, ngrps)) { - if (ngrps == NGROUPS_MAX) + if( ngrps == max_ngroups ) warnx("too many groups"); else { grps[ngrps++] = egid; @@ -225,12 +238,15 @@ if (setgroups(ngrps, (const gid_t *)grps)) { PRIV_END; warn("setgroups"); - return; + goto error_free ; } PRIV_END; } } +error_free: + free( grps ) ; + return ; } static int Index: usr.sbin/chown/chown.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/chown/chown.c,v retrieving revision 1.29 diff -b -u -r1.29 chown.c --- usr.sbin/chown/chown.c 7 Aug 2004 04:19:37 -0000 1.29 +++ usr.sbin/chown/chown.c 8 Feb 2009 16:22:31 -0000 @@ -269,7 +269,8 @@ { static uid_t euid = -1; static int ngroups = -1; - gid_t groups[NGROUPS_MAX]; + static int max_groups ; + gid_t *groups; /* Check for chown without being root. */ if (errno != EPERM || (uid != (uid_t)-1 && @@ -279,16 +280,31 @@ } /* Check group membership; kernel just returns EPERM. */ +#if _POSIX_VERSION >= 199212 + max_groups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_groups = NGROUPS_MAX ; +#else + max_groups = _NGROUPS_COMPAT ; +#endif + groups = (gid_t*)calloc( max_groups, sizeof(gid_t) ) ; + if( groups == NULL ) { + warnx( "failed to allocate memory for group set" ) ; + goto exit_cleanup ; + } if (gid != (gid_t)-1 && ngroups == -1 && euid == (uid_t)-1 && (euid = geteuid()) != 0) { - ngroups = getgroups(NGROUPS_MAX, groups); + ngroups = getgroups( max_groups, groups ) ; while (--ngroups >= 0 && gid != groups[ngroups]); if (ngroups < 0) { warnx("you are not a member of group %s", gname); - return; + goto exit_cleanup ; } } warn("%s", file); +exit_cleanup: + free( groups ) ; + return ; } void Index: usr.sbin/chroot/chroot.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/chroot/chroot.c,v retrieving revision 1.11 diff -b -u -r1.11 chroot.c --- usr.sbin/chroot/chroot.c 7 Aug 2004 04:19:37 -0000 1.11 +++ usr.sbin/chroot/chroot.c 5 Feb 2009 23:29:48 -0000 @@ -59,6 +59,7 @@ char *user; /* user to switch to before running program */ char *group; /* group to switch to ... */ char *grouplist; /* group list to switch to ... */ +int max_ngroups; /* max number of groups allowable */ int main(argc, argv) @@ -69,12 +70,25 @@ struct passwd *pw; char *endp, *p; const char *shell; - gid_t gid, gidlist[NGROUPS_MAX]; + gid_t gid, *gidlist ; uid_t uid; - int ch, gids; + int ch, gids ; +/* set some defaults */ gid = 0; uid = 0; + user = NULL ; + group = NULL ; + grouplist = NULL ; +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + +/* process command line options */ while ((ch = getopt(argc, argv, "G:g:u:")) != -1) { switch(ch) { case 'u': @@ -103,9 +117,12 @@ if (argc < 1) usage(); +/* if a group argument was passed then process it */ if (group != NULL) { + /* if the first char's a digit then assume it's a gid ... */ if (isdigit((unsigned char)*group)) { gid = (gid_t)strtoul(group, &endp, 0); + /* ... and back out that assumption if it proves wrong */ if (*endp != '\0') goto getgroup; } else { @@ -117,8 +134,15 @@ } } - for (gids = 0; - (p = strsep(&grouplist, ",")) != NULL && gids < NGROUPS_MAX; ) { +/* process command line group list */ + if( grouplist != NULL ) { + gidlist = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( gidlist == NULL ) + errx( 1, "inadquate memory for group list" ) ; + for( gids = 0 ; + gids < max_ngroups && + (p=strsep(&grouplist,",")) != NULL ; ) + { if (*p == '\0') continue; @@ -135,9 +159,11 @@ } gids++; } - if (p != NULL && gids == NGROUPS_MAX) + if( p != NULL && gids == max_ngroups ) errx(1, "too many supplementary groups provided"); + } +/* set user from command line option, if supplied */ if (user != NULL) { if (isdigit((unsigned char)*user)) { uid = (uid_t)strtoul(user, &endp, 0); @@ -152,9 +178,11 @@ } } +/* change root */ if (chdir(argv[0]) == -1 || chroot(".") == -1) err(1, "%s", argv[0]); +/* set credentials */ if (gids && setgroups(gids, gidlist) == -1) err(1, "setgroups"); if (group && setgid(gid) == -1) @@ -162,11 +190,14 @@ if (user && setuid(uid) == -1) err(1, "setuid"); +/* exec the remaining arguments as the chroot'd command ... */ if (argv[1]) { execvp(argv[1], &argv[1]); err(1, "%s", argv[1]); + /* NOTREACHED */ } +/* ... or execute the default system shell */ if (!(shell = getenv("SHELL"))) shell = _PATH_BSHELL; execlp(shell, shell, "-i", (char *)NULL); Index: usr.sbin/gssd/gssd.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/gssd/gssd.c,v retrieving revision 1.1 diff -b -u -r1.1 gssd.c --- usr.sbin/gssd/gssd.c 3 Nov 2008 10:38:00 -0000 1.1 +++ usr.sbin/gssd/gssd.c 5 Feb 2009 16:16:37 -0000 @@ -464,8 +464,8 @@ result->uid = uid; getpwuid_r(uid, &pwd, buf, sizeof(buf), &pw); if (pw) { - int len = NGRPS; - int groups[NGRPS]; + int len = AUTH_UNIX_NGROUPS ; + int groups[AUTH_UNIX_NGROUPS] ; result->gid = pw->pw_gid; getgrouplist(pw->pw_name, pw->pw_gid, groups, &len); Index: usr.sbin/mount_portalfs/cred.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/mount_portalfs/cred.c,v retrieving revision 1.1 diff -b -u -r1.1 cred.c --- usr.sbin/mount_portalfs/cred.c 11 Mar 2005 08:39:58 -0000 1.1 +++ usr.sbin/mount_portalfs/cred.c 16 Jan 2009 23:49:36 -0000 @@ -46,7 +46,7 @@ set_user_credentials(struct portal_cred *user, struct portal_cred *save) { save->pcr_uid = geteuid(); - if ((save->pcr_ngroups = getgroups(NGROUPS_MAX, save->pcr_groups)) < 0) + if( (save->pcr_ngroups=getgroups(_NGROUPS_COMPAT,save->pcr_groups)) < 0 ) return (-1); if (setgroups(user->pcr_ngroups, user->pcr_groups) < 0) return (-1); Index: usr.sbin/pppd/options.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/pppd/options.c,v retrieving revision 1.26 diff -b -u -r1.26 options.c --- usr.sbin/pppd/options.c 7 Nov 2007 10:53:38 -0000 1.26 +++ usr.sbin/pppd/options.c 10 Feb 2009 09:11:47 -0000 @@ -72,10 +72,6 @@ char *strdup(char *); #endif -#ifndef GIDSET_TYPE -#define GIDSET_TYPE gid_t -#endif - /* * Option variables and default values. */ @@ -779,23 +775,64 @@ int fd; { uid_t uid; - int ngroups, i; + int ngroups, max_ngroups, i; struct stat sbuf; - GIDSET_TYPE groups[NGROUPS_MAX]; + gid_t *groups; +/* get the uid */ uid = getuid(); +/* ... and return true if root */ +/* XXX: needs credential check */ if (uid == 0) return 1; + +/* if we're not root, get some info about the file */ if (fstat(fd, &sbuf) != 0) return 0; + +/* test for owner match with current process */ if (sbuf.st_uid == uid) return sbuf.st_mode & S_IRUSR; +/* ... and a group match */ if (sbuf.st_gid == getgid()) return sbuf.st_mode & S_IRGRP; - ngroups = getgroups(NGROUPS_MAX, groups); - for (i = 0; i < ngroups; ++i) - if (sbuf.st_gid == groups[i]) - return sbuf.st_mode & S_IRGRP; + +/* if we've still no luck then check the group list for permission match */ +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + groups = (gid_t*) calloc( max_ngroups, sizeof(gid_t) ) ; + if( groups == NULL ) { + /* if we cannot check groups correctly then assume 'fd' is unreadable + * XXX: this may be false as the converse is more likely. + * i.e. it would be failed readable on available groups + * and granted on full list, however, we just can't be + * psychic and i'm not about to code some idiotic loop that tries + * to get 'some' memory for partial testing. probably a better + * recourse would be to simply die here but that seems severe + * for a 'readable' test. + * NB: we don't need a 'full' allocation of memory to test the + * group list, only to store it. one idea would be to do this in + * 'blocks' + */ + option_error( 1, "unable to allocate memory for group list" ) ; + return( 0 ) ; + } +/* get groups */ + ngroups = getgroups( max_ngroups, groups ) ; +/* ... and test the group permission if matching */ + for( i = 0 ; i < ngroups ; ++i ) { + if (sbuf.st_gid == groups[i]) { + free( (void*)groups) ; + return( sbuf.st_mode & S_IRGRP ) ; + } + } +/* otherwise return other permissions match */ + free( (void*)groups ) ; return sbuf.st_mode & S_IROTH; } Index: usr.sbin/rpc.lockd/kern.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/rpc.lockd/kern.c,v retrieving revision 1.21 diff -b -u -r1.21 kern.c --- usr.sbin/rpc.lockd/kern.c 17 Aug 2006 05:55:20 -0000 1.21 +++ usr.sbin/rpc.lockd/kern.c 5 Feb 2009 16:22:17 -0000 @@ -239,15 +239,15 @@ int ngroups; ngroups = xucred->cr_ngroups - 1; - if (ngroups > NGRPS) - ngroups = NGRPS; - if (cl->cl_auth != NULL) - cl->cl_auth->ah_ops->ah_destroy(cl->cl_auth); - cl->cl_auth = authunix_create(hostname, + if( ngroups > AUTH_UNIX_NGROUPS ) + ngroups = AUTH_UNIX_NGROUPS ; + if( cl->cl_auth != NULL ) + cl->cl_auth->ah_ops->ah_destroy( cl->cl_auth ) ; + cl->cl_auth = authunix_create( hostname, xucred->cr_uid, xucred->cr_groups[0], ngroups, - &xucred->cr_groups[1]); + &xucred->cr_groups[1] ) ; } --jRHKVT23PllUwdXP-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 14:39:42 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D56271065670 for ; Fri, 13 Feb 2009 14:39:42 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 994728FC17 for ; Fri, 13 Feb 2009 14:39:42 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (81-65-128-47.rev.numericable.fr [81.65.128.47]) by smtp.lamaiziere.net (Postfix) with ESMTPA id A90D1633302 for ; Fri, 13 Feb 2009 15:39:40 +0100 (CET) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 3528DC1B0 for ; Fri, 13 Feb 2009 15:22:07 +0100 (CET) Date: Fri, 13 Feb 2009 15:22:05 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-hackers@FreeBSD.org Message-ID: <20090213152205.0eccafb0@baby-jane.lamaiziere.net> Organization: /dave/nulle X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: bus_dmamem_alloc() and BUS_DMA_WAITOK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:39:43 -0000 Hello, I would like to know if it is safe to use the BUS_DMA_WAITOK flag with bus_dmamem_alloc(), in the context of the device_attach routine? Many drivers use BUS_DMA_NOWAIT. I need a 32Ko buffer and on low memory my driver cannot attach (bus_dmamem_alloc returns ENOMEM). Will BUS_DMA_WAITOK help in this case? Thanks in advance, regards. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 15:39:58 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDAB510657CE for ; Fri, 13 Feb 2009 15:39:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB078FC14 for ; Fri, 13 Feb 2009 15:39:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3732746B2D; Fri, 13 Feb 2009 10:39:58 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1DFd49N044500; Fri, 13 Feb 2009 10:39:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 13 Feb 2009 09:57:10 -0500 User-Agent: KMail/1.9.7 References: <20090213152205.0eccafb0@baby-jane.lamaiziere.net> In-Reply-To: <20090213152205.0eccafb0@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902130957.10997.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]); Fri, 13 Feb 2009 10:39:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8987/Fri Feb 13 05:32:33 2009 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: Patrick =?iso-8859-1?q?Lamaizi=E8re?= Subject: Re: bus_dmamem_alloc() and BUS_DMA_WAITOK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:40:00 -0000 On Friday 13 February 2009 9:22:05 am Patrick Lamaizi=E8re wrote: > Hello, >=20 > I would like to know if it is safe to use the BUS_DMA_WAITOK flag with > bus_dmamem_alloc(), in the context of the device_attach routine? Many > drivers use BUS_DMA_NOWAIT. Yes, it is ok to use in an attach routine. > I need a 32Ko buffer and on low memory my driver cannot attach > (bus_dmamem_alloc returns ENOMEM). Will BUS_DMA_WAITOK help in this > case? I'm not sure if it will really help, though. You might end up blocking=20 forever (or a long time) until a 32k region is freed. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 18:14:53 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95CED1065679 for ; Fri, 13 Feb 2009 18:14:53 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from lorca.tdx.co.uk (lorca.tdx.co.uk [62.13.128.6]) by mx1.freebsd.org (Postfix) with ESMTP id 117E58FC0A for ; Fri, 13 Feb 2009 18:14:52 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from Octa64 (rainbow.tdx.co.uk [62.13.130.232] (may be forged)) (authenticated bits=0) by lorca.tdx.co.uk (8.14.0/8.14.0/Kp) with ESMTP id n1DI0Ojm011954 for ; Fri, 13 Feb 2009 18:00:25 GMT Date: Fri, 13 Feb 2009 18:00:31 +0000 From: Karl Pielorz To: freebsd-hackers@FreeBSD.org Message-ID: <12320CD678FB9B76CA7A29F1@Octa64> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Tyan S2895 7.1 amd64 >4Gb RAM support? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 18:14:54 -0000 Hi, I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Opteron 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing video production, ray tracing etc.) I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it, but I've been having horrific problems with it. Basically, with more than ~3Gb of RAM usable in the system - it shows signs of chronic RAM problems (everything from sig11's through to failing to compile the kernel with 'weird' errors - as well as kernel panics, and spontaneous reboots). I've tested all the RAM (ECC is enabled on the BIOS) - it all tests fine (even if I jumble it up between different simms in different sockets etc.) By setting: hw.physmem="3G" In loader.conf - I get a stable system. I've not setup any ZFS pools or anything yet, until I get the system stable. I've also tried changing the BIOS settings for the Memory Hole, IOMMU, MTRR etc. - all to no avail (nor does a BIOS 'use safe defaults' make any difference). It boots off the onboard nVidia RAID controller (a pair of 36Gb drives configured as RAID1), this shows up as: " atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x1440-0x1447,0x1434-0x1437,0x1438-0x143f,0x1430-0x1433,0x1410-0x141f mem 0xc0002000-0xc0002fff irq 22 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x1458-0x145f,0x144c-0x144f,0x1450-0x1457,0x1448-0x144b,0x1420-0x142f mem 0xc0003000-0xc0003fff irq 23 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ... ad8: 35304MB at ata4-master SATA150 ad10: 35304MB at ata5-master SATA150 ... ar0: 35304MB status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad8 at ata4-master Trying to mount root from ufs:/dev/ar0s1a " Anyone got any ideas? - At this time, I can't prove 100% whether it's the disk controller messing up and corrupting data as it's loaded into RAM, or data getting corrupt once in RAM that's causing the crashes - all I know is with ~3Gb RAM - either by physically pulling SIMMs or using the hw.physmem option - it works fine. I tried booting 8.0-CURRENT-200812-amd64-disc1.iso - to see if anything was different with this hardware in 8.0 - but unfortunately that doesn't boot past the BTX loader on this machine, regardless of how much RAM is / isn't in it :( -Kp From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 18:53:45 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5CB8106564A for ; Fri, 13 Feb 2009 18:53:45 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5008FC1C for ; Fri, 13 Feb 2009 18:53:45 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E1E4D9CB097 for ; Fri, 13 Feb 2009 19:32:31 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeXtt8gZQajd for ; Fri, 13 Feb 2009 19:32:29 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B38909CB141 for ; Fri, 13 Feb 2009 19:32:29 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n1DIWT3G094491 for hackers@freebsd.org; Fri, 13 Feb 2009 19:32:29 +0100 (CET) (envelope-from rdivacky) Date: Fri, 13 Feb 2009 19:32:29 +0100 From: Roman Divacky To: hackers@freebsd.org Message-ID: <20090213183229.GA94272@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: TUNABLE_INT question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 18:53:46 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi =20 #define TUNABLE_INT(path, var) \ static struct tunable_int __CONCAT(__tunable_int_, __LINE__) =3D { \ (path), \ (var), \ }; \ SYSINIT(__CONCAT(__Tunable_init_, __LINE__), \ SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_int_init, \ &__CONCAT(__tunable_int_, __LINE__)) =20 =20 this is the code for TUNABLE_INT macro, the first param to SYSINIT is an "uniquifier" which is "__Tunable_init_X" where is is a number specifying line. =20 if I read it correctly there is no protection from collisions, am I right? is it a proper fix to concat __FILE__ there too? =20 thnx =20 roman --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmVvLcACgkQLVEj6D3CBEwOJQCfUBgvia0XT8kqUzMbXMwKpLlk zacAnRZzTtfyeS3NNeNBK2sM67tvhFu8 =kLJV -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 19:08:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E7A2106566B for ; Fri, 13 Feb 2009 19:08:40 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id F13EA8FC17 for ; Fri, 13 Feb 2009 19:08:39 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-252-047.pools.arcor-ip.net [88.67.252.47]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1LY3Ow2IMA-00061i; Fri, 13 Feb 2009 20:08:38 +0100 Received: (qmail 55331 invoked from network); 13 Feb 2009 19:08:38 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by laiers.local with SMTP; 13 Feb 2009 19:08:38 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Fri, 13 Feb 2009 20:08:37 +0100 User-Agent: KMail/1.10.4 (FreeBSD/8.0-CURRENT; KDE/4.1.4; i386; ; ) References: <12320CD678FB9B76CA7A29F1@Octa64> In-Reply-To: <12320CD678FB9B76CA7A29F1@Octa64> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902132008.38110.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/1XzMXZqNOM2pgo3z6wOoEuRRlO/XBhDGWeC0 MNqPivC9OZGFduTpJCuR0ba5R2bUWI3VflwqPgZR8ripggwnhI k1N8Y9v+pxpZliK8m5WLQ== Cc: Karl Pielorz Subject: Re: Tyan S2895 7.1 amd64 >4Gb RAM support? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 19:08:40 -0000 On Friday 13 February 2009 19:00:31 Karl Pielorz wrote: > Hi, > > I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Opteron > 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing video > production, ray tracing etc.) > > I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it, > but I've been having horrific problems with it. > > Basically, with more than ~3Gb of RAM usable in the system - it shows signs > of chronic RAM problems (everything from sig11's through to failing to > compile the kernel with 'weird' errors - as well as kernel panics, and > spontaneous reboots). > > I've tested all the RAM (ECC is enabled on the BIOS) - it all tests fine > (even if I jumble it up between different simms in different sockets etc.) > > By setting: > > hw.physmem="3G" > > In loader.conf - I get a stable system. > > I've not setup any ZFS pools or anything yet, until I get the system > stable. I've also tried changing the BIOS settings for the Memory Hole, > IOMMU, MTRR etc. - all to no avail (nor does a BIOS 'use safe defaults' > make any difference). I have a S2882-D populated with 6GB (6x1G) running FreeBSD since early 7. It took some tuning of the memory timing in the BIOS to get it to work, but ever since it works like a charm. > It boots off the onboard nVidia RAID controller (a pair of 36Gb drives > configured as RAID1), this shows up as: Can you maybe try to take the nVidia RAID out of the equation? I figure the "professional" version of the chip is not that common so maybe the corruption stems from the disk controller. > " > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x1440-0x1447,0x1434-0x1437,0x1438-0x143f,0x1430-0x1433,0x1410-0x141f mem > 0xc0002000-0xc0002fff irq 22 at device 7.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x1458-0x145f,0x144c-0x144f,0x1450-0x1457,0x1448-0x144b,0x1420-0x142f mem > 0xc0003000-0xc0003fff irq 23 at device 8.0 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > ... > ad8: 35304MB at ata4-master SATA150 > ad10: 35304MB at ata5-master SATA150 > ... > ar0: 35304MB status: READY > ar0: disk0 READY (master) using ad10 at ata5-master > ar0: disk1 READY (mirror) using ad8 at ata4-master > Trying to mount root from ufs:/dev/ar0s1a > " > > Anyone got any ideas? - At this time, I can't prove 100% whether it's the > disk controller messing up and corrupting data as it's loaded into RAM, or > data getting corrupt once in RAM that's causing the crashes - all I know is > with ~3Gb RAM - either by physically pulling SIMMs or using the hw.physmem > option - it works fine. > > I tried booting 8.0-CURRENT-200812-amd64-disc1.iso - to see if anything was > different with this hardware in 8.0 - but unfortunately that doesn't boot > past the BTX loader on this machine, regardless of how much RAM is / isn't > in it :( Any more details on how it fails would help. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 21:28:49 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3867C106566B for ; Fri, 13 Feb 2009 21:28:48 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id E60F58FC1B for ; Fri, 13 Feb 2009 21:28:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so807986yxl.13 for ; Fri, 13 Feb 2009 13:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SLv4we0SKX/BXuK8lQVGnz9K3/Ua5lBTOp2E41g6/r0=; b=mQdmC4mKqTbDZYit1MACVyMnSpewRdxqC8Qqvkl2NncPEwiQ0EVUp4dUiio3iiAoZC M61LIafy259+F10E9fxr6SaR37sW6ar+ZzTeTaxuUZ3w62rWmEG6CLmXPhzoJ4rXQ1BU u91+t6tVcPXQImKxoXu581vsGGWNUMOomTZ54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tOdfULC7mvCOdMpCjmZbiVaA6hCw46s0XfgZCz3A6pGe9pdn6uFzF3biAruS2rr0ES pgwkL3GvjIMpXBOya6NvXTpzcvpzbAj+wH+yWPUrp55gy1hwNGOv86381Rd6Tx7QBoxd cI3JLjdKVtpHimoJ5q9me96nfKWDdGEMvNgok= MIME-Version: 1.0 Received: by 10.150.196.20 with SMTP id t20mr1674592ybf.76.1234558544844; Fri, 13 Feb 2009 12:55:44 -0800 (PST) In-Reply-To: <20090213183229.GA94272@freebsd.org> References: <20090213183229.GA94272@freebsd.org> Date: Fri, 13 Feb 2009 15:55:44 -0500 Message-ID: From: Ryan Stone To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: TUNABLE_INT question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:28:50 -0000 __FILE__ is a string so you can't concat that with anything to produce an identifier. In any case, the variable is static so there can't be any collision problems with other files. Ryan Stone From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 22:19:05 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38D0F106566B for ; Fri, 13 Feb 2009 22:19:05 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id E73308FC08 for ; Fri, 13 Feb 2009 22:19:04 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 2EFDA9CB092; Fri, 13 Feb 2009 23:16:10 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLbknifEZmNd; Fri, 13 Feb 2009 23:16:08 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 09ACB9CB17F; Fri, 13 Feb 2009 23:16:08 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n1DMG71i025388; Fri, 13 Feb 2009 23:16:07 +0100 (CET) (envelope-from rdivacky) Date: Fri, 13 Feb 2009 23:16:07 +0100 From: Roman Divacky To: Ryan Stone Message-ID: <20090213221607.GA25161@freebsd.org> References: <20090213183229.GA94272@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: TUNABLE_INT question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 22:19:05 -0000 On Fri, Feb 13, 2009 at 03:55:44PM -0500, Ryan Stone wrote: > __FILE__ is a string so you can't concat that with anything to produce an > identifier. In any case, the variable is static so there can't be any > collision problems with other files. I was talking about the SYSINIT parameter. thats a section in a .o file, and I am getting collisions there... From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 14 09:53:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D5411065670 for ; Sat, 14 Feb 2009 09:53:26 +0000 (UTC) (envelope-from yamagi@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 310518FC0C for ; Sat, 14 Feb 2009 09:53:25 +0000 (UTC) (envelope-from yamagi@yamagi.org) Received: from localhost (unknown [10.0.0.3]) by mail.yamagi.org (Postfix) with ESMTP id 9B6A71085286; Sat, 14 Feb 2009 10:23:06 +0100 (CET) X-Virus-Scanned: amavisd-new at yamagi.org Received: from mail.yamagi.org ([10.0.0.3]) by localhost (mail.yamagi.org [10.0.0.3]) (amavisd-new, port 10024) with LMTP id GT488SvOeOUM; Sat, 14 Feb 2009 10:22:51 +0100 (CET) Received: from saya.home.yamagi.org (p4FDF5749.dip.t-dialin.net [79.223.87.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 258071085281; Sat, 14 Feb 2009 10:22:50 +0100 (CET) Received: from saya.home.yamagi.org (localhost [127.0.0.1]) by saya.home.yamagi.org (8.14.3/8.14.3) with ESMTP id n1E9MmlX001392; Sat, 14 Feb 2009 10:22:48 +0100 (CET) (envelope-from yamagi@saya.home.yamagi.org) Received: (from yamagi@localhost) by saya.home.yamagi.org (8.14.3/8.14.3/Submit) id n1E9MmYY001391; Sat, 14 Feb 2009 10:22:48 +0100 (CET) (envelope-from yamagi) Date: Sat, 14 Feb 2009 10:22:48 +0100 From: Yamagi Burmeister To: Karl Pielorz Message-ID: <20090214092248.GA1281@yamagi.org> References: <12320CD678FB9B76CA7A29F1@Octa64> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <12320CD678FB9B76CA7A29F1@Octa64> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@freebsd.org Subject: Re: Tyan S2895 7.1 amd64 >4Gb RAM support? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 09:53:27 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am Fri, Feb 13, 2009 at 06:00:31PM +0000 schrieb Karl Pielorz: >=20 > Hi, >=20 > I've a Tyan S2895 (bios 1.04), w/10Gb of ECC RAM onboard using 2 * Optero= n=20 > 285's. The machine used to run WinXP x64, and Vista x64 (mostly doing vid= eo=20 > production, ray tracing etc.) >=20 > I recently switched this machine to FreeBSD 7.1 amd64 - to run ZFS on it,= =20 > but I've been having horrific problems with it. Hello, I'm using some S2895 for various purposes, as webservers, databaseservers and workstations. Most of them are populated using 2 * Opteron 265 in stepping E2. They work like a charm _after_ upgrading the BIOS to version 1.05e_beta or later[1]. But it's necessary to use /boot/loader from 7.0 since later version won't work to some bios-bugs. Ciao, Yamagi 1: http://www.tyan.de/support_download_bios.aspx?model=3DS.S2895 --=20 Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmWjWYACgkQWTjlg++8y8su3QCfazJg9B42OhjY1WFDW64TOYBf 0ugAoNlc5NZ1Qj5mAYFSllyDwbZrDKKg =ZRBN -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 14 19:25:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0019106566B for ; Sat, 14 Feb 2009 19:25:40 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 6A21D8FC08 for ; Sat, 14 Feb 2009 19:25:40 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so907488yxl.13 for ; Sat, 14 Feb 2009 11:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=WmWK55j3cuqx+gO0TtNPy07rYRbqlXkJBL9yD+PgpzM=; b=sLh3aWJWu/0IQGbLYJtjrtNcix12iEKyfaTLICVVNWJkFZ6b4mhAujo0DgolIaoAzx 162gM57txLAUqYXQ/vzcKF4G9gIEMj81og5rlHiAeMOavc8LWFCsfC7MPlhDcbOGD+YA Hoc0nLRmmYMy9klxJPoyrSyg7Mo5sQ5nQ+BrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IqpsjYQikh6ehsX3Z1DlE+QHicCTm3HiAOTeS9gHng4iJTBVOqIH3UxdIZjnvMCXle Yfmn0hckiPP0CLB64WjaZ+4NsXAjUpSTqL6p+zm914eImBfge5zPhFQjjLG782X/wrIW koZD72d+sXwIuIYlOrb9ukke3P//nFb7MOFN8= MIME-Version: 1.0 Received: by 10.151.149.6 with SMTP id b6mr1486081ybo.122.1234638023079; Sat, 14 Feb 2009 11:00:23 -0800 (PST) Date: Sat, 14 Feb 2009 14:00:23 -0500 Message-ID: <5f67a8c40902141100w406b0a73h7cf487369e15ec8f@mail.gmail.com> From: Zaphod Beeblebrox To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: When does the pool get bigger? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 19:25:41 -0000 I have a ZFS raid-Z array (FreeBSD-7.1p2) that I use for storing backups and media. I'm keenly awaiting the MFC of the ZFS v13 code, but I'm not in a hurry to run -CURRENT on this box. Anyways... The array was 5x 750G drives and I decided to upgrade to 5x 1.5T drives. I removed one 750G drive and inserted a 1.5T drive each time. All 5 are done resilvering now. When does the pool get bigger? The resilver of the last drive has finished, but the pool still reads [1:20:320]root@virtual:/usr/local/etc> zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT vr2 3.41T 3.16T 251G 92% ONLINE - ... which is the size with 750G drives. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 14 20:58:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD35C1065710; Sat, 14 Feb 2009 20:58:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 425928FC1A; Sat, 14 Feb 2009 20:58:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n1EKdNHr078343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Feb 2009 21:39:23 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n1EKdKQa080294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2009 21:39:20 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n1EKdKX6083533; Sat, 14 Feb 2009 21:39:20 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n1EKdKIl083532; Sat, 14 Feb 2009 21:39:20 +0100 (CET) (envelope-from ticso) Date: Sat, 14 Feb 2009 21:39:20 +0100 From: Bernd Walter To: Zaphod Beeblebrox Message-ID: <20090214203919.GV84964@cicely7.cicely.de> References: <5f67a8c40902141100w406b0a73h7cf487369e15ec8f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f67a8c40902141100w406b0a73h7cf487369e15ec8f@mail.gmail.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.050, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: When does the pool get bigger? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 20:58:30 -0000 On Sat, Feb 14, 2009 at 02:00:23PM -0500, Zaphod Beeblebrox wrote: > I have a ZFS raid-Z array (FreeBSD-7.1p2) that I use for storing backups and > media. I'm keenly awaiting the MFC of the ZFS v13 code, but I'm not in a > hurry to run -CURRENT on this box. > > Anyways... The array was 5x 750G drives and I decided to upgrade to 5x 1.5T > drives. I removed one 750G drive and inserted a 1.5T drive each time. All > 5 are done resilvering now. > > When does the pool get bigger? The resilver of the last drive has finished, > but the pool still reads > > [1:20:320]root@virtual:/usr/local/etc> zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > vr2 3.41T 3.16T 251G 92% ONLINE - > > ... which is the size with 750G drives. You need to export/import the pool once. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.