From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 04:03:38 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5268B37B401 for ; Sun, 18 May 2003 04:03:36 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id F065743FBF for ; Sun, 18 May 2003 04:03:33 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 5005D530E; Sun, 18 May 2003 13:03:30 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: alpha@freebsd.org From: Dag-Erling Smorgrav Date: Sun, 18 May 2003 13:03:30 +0200 Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Alpha release X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 11:03:38 -0000 JFYI, my PWS just finished a 'release' tinderbox run... I used NOCDROM, NODOC, NOPORTS to save disk space, but otherwise it was a complete 'make release' of top-of-tree -CURRENT. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 07:46:20 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67F8E37B404 for ; Sun, 18 May 2003 07:46:20 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8883E43FE0 for ; Sun, 18 May 2003 07:46:17 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h4IEkGEB030740; Sun, 18 May 2003 16:46:16 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h4IEkGox030739; Sun, 18 May 2003 16:46:16 +0200 (CEST) Date: Sun, 18 May 2003 16:46:16 +0200 From: Wilko Bulte To: Dag-Erling Smorgrav Message-ID: <20030518144616.GA30720@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-STABLE X-PGP: finger wilko@freebsd.org cc: alpha@freebsd.org Subject: Re: Alpha release X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 14:46:20 -0000 On Sun, May 18, 2003 at 01:03:30PM +0200, Dag-Erling Smorgrav wrote: > JFYI, my PWS just finished a 'release' tinderbox run... I used > NOCDROM, NODOC, NOPORTS to save disk space, but otherwise it was a > complete 'make release' of top-of-tree -CURRENT. Did the floppies run out of inodes, like Ruslan reported? They did for my build. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 09:39:11 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD12937B401 for ; Sun, 18 May 2003 09:39:11 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B88F43F75 for ; Sun, 18 May 2003 09:39:08 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B6B385310; Sun, 18 May 2003 18:39:06 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Wilko Bulte References: <20030518144616.GA30720@freebie.xs4all.nl> From: Dag-Erling Smorgrav Date: Sun, 18 May 2003 18:39:06 +0200 In-Reply-To: <20030518144616.GA30720@freebie.xs4all.nl> (Wilko Bulte's message of "Sun, 18 May 2003 16:46:16 +0200") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: alpha@freebsd.org Subject: Re: Alpha release X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 16:39:12 -0000 Wilko Bulte writes: > On Sun, May 18, 2003 at 01:03:30PM +0200, Dag-Erling Smorgrav wrote: > > JFYI, my PWS just finished a 'release' tinderbox run... I used > > NOCDROM, NODOC, NOPORTS to save disk space, but otherwise it was a > > complete 'make release' of top-of-tree -CURRENT. > Did the floppies run out of inodes, like Ruslan reported? They > did for my build. Yes, they did, but the release still completed... DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 10:40:36 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 167EA37B401 for ; Sun, 18 May 2003 10:40:36 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4DE43F93 for ; Sun, 18 May 2003 10:40:34 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h4IHeXEB031163; Sun, 18 May 2003 19:40:33 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h4IHeTFo031158; Sun, 18 May 2003 19:40:29 +0200 (CEST) Date: Sun, 18 May 2003 19:40:29 +0200 From: Wilko Bulte To: Dag-Erling Smorgrav Message-ID: <20030518174029.GA31140@freebie.xs4all.nl> References: <20030518144616.GA30720@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-STABLE X-PGP: finger wilko@freebsd.org cc: alpha@freebsd.org Subject: Re: Alpha release X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 17:40:36 -0000 On Sun, May 18, 2003 at 06:39:06PM +0200, Dag-Erling Smorgrav wrote: > Wilko Bulte writes: > > On Sun, May 18, 2003 at 01:03:30PM +0200, Dag-Erling Smorgrav wrote: > > > JFYI, my PWS just finished a 'release' tinderbox run... I used > > > NOCDROM, NODOC, NOPORTS to save disk space, but otherwise it was a > > > complete 'make release' of top-of-tree -CURRENT. > > Did the floppies run out of inodes, like Ruslan reported? They > > did for my build. > > Yes, they did, but the release still completed... Same here. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 12:49:19 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09D3E37B401 for ; Sun, 18 May 2003 12:49:19 -0700 (PDT) Received: from dove.penix.org (dove.penix.org [216.144.7.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39DFD43FAF for ; Sun, 18 May 2003 12:49:18 -0700 (PDT) (envelope-from dp@dove.penix.org) Received: from dove.penix.org (dp@localhost.nls.net [127.0.0.1]) by dove.penix.org (8.12.9/8.12.9) with ESMTP id h4IJnGNe002490 for ; Sun, 18 May 2003 15:49:17 -0400 (EDT) (envelope-from dp@dove.penix.org) Received: from localhost (dp@localhost) by dove.penix.org (8.12.9/8.12.9/Submit) with ESMTP id h4IJnG5T002487 for ; Sun, 18 May 2003 15:49:16 -0400 (EDT) Date: Sun, 18 May 2003 15:49:15 -0400 (EDT) From: Paul Halliday To: alpha@freebsd.org Message-ID: <20030518154236.F2486@dove.penix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Serial ports. X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 19:49:19 -0000 Has anyone experienced a system crash while using something like minicom? I am trying to reinstall familiar on my ipaq (~11MB transfer) and the machine just simply dies, err.. freezes. This has happened to me before pre-5.0 on my AS200 and currently on my PC164 w/ 5.0-R. open to suggestions.. Thanks. Paul Halliday. http://dp.penix.org ------------------- From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 14:48:26 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C51FB37B401 for ; Sun, 18 May 2003 14:48:26 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 246AA43FAF for ; Sun, 18 May 2003 14:48:26 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h4ILmLm2004431; Sun, 18 May 2003 14:48:25 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h4ILmKsT004430; Sun, 18 May 2003 14:48:20 -0700 (PDT) Date: Sun, 18 May 2003 14:48:20 -0700 From: "David O'Brien" To: Dag-Erling Smorgrav Message-ID: <20030518214820.GB1393@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Dag-Erling Smorgrav , alpha@freebsd.org References: <20030517113906.GA25329@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: alpha@freebsd.org Subject: Re: floating point exception 8 in awk X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: alpha@freebsd.org List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 21:48:27 -0000 On Sat, May 17, 2003 at 03:52:40PM +0200, Dag-Erling Smorgrav wrote: > Dag-Erling Smorgrav writes: > > Wilko Bulte writes: > > > FAQ, more of less. If you rebuild & install your awk with -mieee from then > > > on everything works again. -mieee is now the default on alpha. > > Yes, but this shouldn't happen inside the chroot since it's using > > either the awk from the buildworld preceding make relese, or the awk > > from the cross-tools stage of the chrooted buildworld, and both of > > these should have been built with -mieee... though it seems they > > weren't, I can't find the string 'mieee' anywhere in the build logs. > > Grrr... found the bug: bsd.sys.mk adds -mieee to the _CPUCFLAGS > variable, which is ignored if NO_CPU_CFLAGS is set. This is arguably > a bug since _CPUCFLAGS is supposed to control optimization, not > correctness, and setting NO_CPU_CFLAGS should improve correctness at > the expense of performance and not the other way around. > > Any suggestions on how to fix this? Not sure what the best way to change this is. We can't just do: .if ${MACHINE_ARCH} == "alpha" CFLAGS+= -mieee .endif as a user needs a way to not have -mieee. Calling -mieee a "correctness" thing is debatable. Some feel our code is buggy, some feel the Alpha default of not doing IEEE math is bogus. Personally I think it is a bug NO_CPU_CFLAGS is unconditionally used in src/Makefile.inc1. It should only be used in the cross or very-old-native case. From owner-freebsd-alpha@FreeBSD.ORG Mon May 19 00:49:15 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BE0637B401 for ; Mon, 19 May 2003 00:49:15 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858B143FA3 for ; Mon, 19 May 2003 00:49:14 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h4J7nEQg051717 for ; Mon, 19 May 2003 00:49:14 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4J7nEi1051716 for freebsd-alpha@freebsd.org; Mon, 19 May 2003 00:49:14 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 May 2003 00:49:14 -0700 From: Luigi Rizzo To: freebsd-alpha@freebsd.org Message-ID: <20030519004914.B46011@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 07:49:15 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, in the past there have been reports about panics on 64 bit architectures due to unaligned accesses to parts of the ipfw2 rules. The attached patch tries to fix them. I tested that it compiles, but couldn't run it on the relevant architectures for lack of hardware, and have not found yet anyone who wanted to try it. If you care and want to spend a few minutes to test the patch on a Sparc64 or Alpha box and provide feedback, I'd ask you to do the following: STEP 1: try to reproduce the panic + compile a kernel (a recent CURRENT or STABLE) WITHOUT THE PATCH (i.e. with standard sources) with the following options: options IPFIREWALL options DUMMYNET options IPFW2 # only in STABLE (on STABLE, make sure you also have rebuilt ipfw with make -DIPFW2) + [THIS SHOULD TRIGGER A PANIC] reboot with the new kernel and configure ipfw with one of the following configurations, and fire some traffic at the firewall (e.g. "ssh localhost") to try and cause a panic. If these configuration do not cause a panic and you know a better one, please post it. ipfw pipe 1 config ipfw add pipe 1 tcp from any to any 1-65535,1-65535 or ipfw pipe 1 config ipfw add pipe 1 tcp from any to any 1-65535,1-65535,1-65535 or ipfw add allow tcp from any to any 1-65535,1-65535 or ipfw add allow tcp from any to any 1-65535,1-65535,1-65535 STEP 2: test the patch + patch sys/netinet/ and sbin/ipfw/ with the attached patch, rebuild and reinstall kernel and ipfw, and try again to see if the panic does not occur anymore. The patch is for -current, but it should apply to -stable with relatively little effort (see the description below). Feedback would be really appreciated if you want to have this fixed for 5.1 cheers luigi --------------------------------------- Description and proposed patch for ipfw[2] panics on 64-bit architectures. BACKGROUND ipfw2 has been designed so that rules are made of a standard header, followed by a sequence of [micro]instructions (represented by C struct's), each one having a length of a multiple of 32 bits. Because instructions are written one after the other without padding, variables of size > 32bit which reside within each struct might end up unaligned, and the compiler cannot help fixing this. I am listing below some of the approaches that can be used to avoid the problem; because such occurences are extremely rare (there is actually only one instance, "void *pipe_ptr" within "struct _ipfw_insn_pipe"), i believe the first approach to be the easiest to implement and also the most effective in terms of memory occupation and code modifications. Solution #1: handle the critical 64-bit objects with bcopy/bcmp instead of accessing them directly. This is slightly inefficient but fortunately the only instance when it needs to be done is when passing a packet to a dummynet pipe. Also, the size of the copy/compare is known at compile time, so i suppose it might be candidate to some compiler optimizations. Solution #2: make the size of each microinstruction a multiple of 64 bits, so the alignment can be guaranteed by the compiler. This would generate quite an increase of the instruction sizes, and more importantly, would require a significant revision of the ipfw code. The good thing of this approach is that, once done, would put on the compiler the burden of providing the alignment. Solution #3: possibly introduce a padding (in the form of NOP instructions) before those instructions which need alignment. This also requires some amount of extra code to introduce the padding when necessary, and leaves the burden of providing the aligment on the programmer. DESCRIPTION OF THE ATTACHED PATCH The attached patch modifies the following files: src/sys/netinet/ip_dummynet.c src/sys/netinet/ip_fw.h src/sys/netinet/ip_fw2.c src/sbin/ipfw2.c and the changes are the following: sys/netinet/ip_dummynet.c: use bcopy to read/write the "pipe_ptr" field of "struct _ipfw_insn_pipe" on non-i386 architectures (which might be sensitive to alignment problems). This is invoked only in two places, when passing a packet to a dummynet pipe. src/sys/netinet/ip_fw.h @@ -32,11 +32,16 @@ add a comment to explain the alignment problems. @@ -211,7 +216,7 @@ change "int unit" to "int32_t unit" to save space on those architectures where int are 64 bits. @@ -220,10 +225,13 @@ add a comment explaining that "void *pipe_ptr" must be treated carefully @@ -278,7 +286,9 @@ remove the unnecessary field "set_disable" from "struct ip_fw". The set of disabled rulesets is passed up to userspace through the "next rule" pointer (unused otherwise, in that context), which is manipulated using bcopy to avoid aligmnent problems. NOTE: by doing this, we revert to the method used by ipfw2 in 4.x, so we should save the change in that branch. @@ -319,12 +329,12 @@ reorder some fields of _ipfw_dyn_rule to reduce the amount of padding. NOTE: This change is not strictly necessary, and could be omitted if we want to keep the struct unchanged (this is only true for the to 4.x branch, because the "rulenum" field from the same struct should be removed anyways, see the diff below). @@ -334,7 +344,9 @@ remove the "rulenum" field from struct _ipfw_dyn_rule, same as done for "set_disable" in "struct ip_fw". sys/netinet/ip_fw2.c @@ -2017,8 +2017,15 @@ use bcmp/bzero to manipulate pipe_ptr. As the comment says, this is done very infrequently so efficiency is not a concern. @@ -2559,7 +2566,8 @@ @@ -2571,7 +2579,8 @@ use bcopy to pass up info from the kernel to userland through an unused pointer, to avoid aligmnent problems. sbin/ipfw/ipfw2.c @@ -813,8 +813,9 @@ @@ -1454,7 +1458,9 @@ use bcopy to fetch the "set_disable" info into a u_int32_t variable @@ -1213,13 +1214,16 @@ @@ -1690,9 +1696,12 @@ use bcopy to fetch the "rulenum" info into a uint16_t variable. ------------------------------ Index: sys/netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.63 diff -u -r1.63 ip_dummynet.c --- sys/netinet/ip_dummynet.c 27 Mar 2003 15:00:10 -0000 1.63 +++ sys/netinet/ip_dummynet.c 11 May 2003 07:19:56 -0000 @@ -1027,7 +1027,11 @@ if (cmd->opcode == O_LOG) cmd += F_LEN(cmd); +#ifdef I386 fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; +#else + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); +#endif if (fs != NULL) return fs; @@ -1049,7 +1053,11 @@ } /* record for the future */ #if IPFW2 +#ifdef I386 ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; +#else + bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); +#endif #else if (fs != NULL) rule->pipe_ptr = fs; Index: sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.76 diff -u -r1.76 ip_fw.h --- sys/netinet/ip_fw.h 15 Mar 2003 01:13:00 -0000 1.76 +++ sys/netinet/ip_fw.h 11 May 2003 07:20:28 -0000 @@ -32,11 +32,16 @@ * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet - * (or its metatada) should be analysed. + * (or its metadata) should be analysed. * * Each instruction is stored in a structure which begins with * "ipfw_insn", and can contain extra fields depending on the * instruction type (listed below). + * Note that the code is written so that individual instructions + * have a size which is a multiple of 32 bits. This means that, if + * such structures contain pointers or other 64-bit entities, + * (there is just one instance now) they may end up unaligned on + * 64-bit architectures, so the must be handled with care. * * "enum ipfw_opcodes" are the opcodes supported. We can have up * to 256 different opcodes. @@ -211,7 +216,7 @@ ipfw_insn o; union { struct in_addr ip; - int unit; + int32_t unit; } p; char name[IFNAMSIZ]; } ipfw_insn_if; @@ -220,10 +225,13 @@ * This is used for pipe and queue actions, which need to store * a single pointer (which can have different size on different * architectures. + * Note that, because of previous instructions, pipe_ptr might + * be unaligned in the overall structure, so it needs to be + * manipulated with care. */ typedef struct _ipfw_insn_pipe { ipfw_insn o; - void *pipe_ptr; + void *pipe_ptr; /* XXX */ } ipfw_insn_pipe; /* @@ -278,7 +286,9 @@ struct ip_fw { struct ip_fw *next; /* linked list of rules */ struct ip_fw *next_rule; /* ptr to next [skipto] rule */ +#if 0 /* passed up using 'next_rule' */ u_int32_t set_disable; /* disabled sets (for userland) */ +#endif u_int16_t act_ofs; /* offset of action in 32-bit units */ u_int16_t cmd_len; /* # of 32-bit words in cmd */ u_int16_t rulenum; /* rule number */ @@ -319,12 +329,12 @@ struct _ipfw_dyn_rule { ipfw_dyn_rule *next; /* linked list of rules. */ - struct ipfw_flow_id id; /* (masked) flow id */ struct ip_fw *rule; /* pointer to rule */ ipfw_dyn_rule *parent; /* pointer to parent rule */ - u_int32_t expire; /* expire time */ u_int64_t pcnt; /* packet match counter */ u_int64_t bcnt; /* byte match counter */ + struct ipfw_flow_id id; /* (masked) flow id */ + u_int32_t expire; /* expire time */ u_int32_t bucket; /* which bucket in hash table */ u_int32_t state; /* state of this rule (typically a * combination of TCP flags) @@ -334,7 +344,9 @@ /* to generate keepalives) */ u_int16_t dyn_type; /* rule type */ u_int16_t count; /* refcount */ +#if 0 /* passed up with 'rule' */ u_int16_t rulenum; /* rule number (for userland) */ +#endif }; /* Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.28 diff -u -r1.28 ip_fw2.c --- sys/netinet/ip_fw2.c 15 Mar 2003 01:13:00 -0000 1.28 +++ sys/netinet/ip_fw2.c 11 May 2003 07:21:40 -0000 @@ -2017,8 +2017,15 @@ if (cmd->o.opcode != O_PIPE && cmd->o.opcode != O_QUEUE) continue; - if (match == NULL || cmd->pipe_ptr == match) - cmd->pipe_ptr = NULL; + /* + * XXX Use bcmp/bzero to handle pipe_ptr to overcome + * possible alignment problems on 64-bit architectures. + * This code is seldom used so we do not worry too + * much about efficiency. + */ + if (match == NULL || + !bcmp(&cmd->pipe_ptr, &match, sizeof(match)) ) + bzero(&cmd->pipe_ptr, sizeof(cmd->pipe_ptr)); } } @@ -2559,7 +2566,8 @@ for (rule = layer3_chain; rule ; rule = rule->next) { int i = RULESIZE(rule); bcopy(rule, bp, i); - ((struct ip_fw *)bp)->set_disable = set_disable; + bcopy(&set_disable, &(bp->next_rule), + sizeof(set_disable)); bp = (struct ip_fw *)((char *)bp + i); } if (ipfw_dyn_v) { @@ -2571,7 +2579,8 @@ for ( p = ipfw_dyn_v[i] ; p != NULL ; p = p->next, dst++ ) { bcopy(p, dst, sizeof *p); - dst->rulenum = p->rule->rulenum; + bcopy(&(p->rule->rulenum), &(dst->rule), + sizeof(p->rule->rulenum)); /* * store a non-null value in "next". * The userland code will interpret a Index: sbin/ipfw/ipfw2.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.23 diff -u -r1.23 ipfw2.c --- sbin/ipfw/ipfw2.c 15 Mar 2003 01:12:59 -0000 1.23 +++ sbin/ipfw/ipfw2.c 11 May 2003 09:00:26 -0000 @@ -813,8 +813,9 @@ int flags = 0; /* prerequisites */ ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */ int or_block = 0; /* we are in an or block */ + u_int32_t set_disable; - u_int32_t set_disable = rule->set_disable; + bcopy(rule->next_rule, &set_disable, sizeof(set_disable)); if (set_disable & (1 << rule->set)) { /* disabled */ if (!show_sets) @@ -1213,13 +1214,16 @@ { struct protoent *pe; struct in_addr a; + uint16_t rulenum; if (!do_expired) { if (!d->expire && !(d->dyn_type == O_LIMIT_PARENT)) return; } - printf("%05d %*llu %*llu (%ds)", d->rulenum, pcwidth, d->pcnt, bcwidth, + bcopy(d->rule, &rulenum, sizeof(rulenum)); + + printf("%05d %*llu %*llu (%ds)", rulenum, pcwidth, d->pcnt, bcwidth, d->bcnt, d->expire); switch (d->dyn_type) { case O_LIMIT_PARENT: @@ -1454,7 +1458,9 @@ err(EX_OSERR, "malloc"); if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, &nbytes) < 0) err(EX_OSERR, "getsockopt(IP_FW_GET)"); - set_disable = ((struct ip_fw *)data)->set_disable; + bcopy(((struct ip_fw *)data)->next_rule, + &set_disable, sizeof(set_disable)); + for (i = 0, msg = "disable" ; i < 31; i++) if ( (set_disable & (1<rulenum > rnum) + uint16_t rulenum; + + bcopy(d->rule, &rulenum, sizeof(rulenum)); + if (rulenum > rnum) break; - if (d->rulenum == rnum) + if (rulenum == rnum) show_dyn_ipfw(d, pcwidth, bcwidth); } } _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" ----- End forwarded message ----- --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw2.diff" Index: sys/netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.63 diff -u -r1.63 ip_dummynet.c --- sys/netinet/ip_dummynet.c 27 Mar 2003 15:00:10 -0000 1.63 +++ sys/netinet/ip_dummynet.c 11 May 2003 07:19:56 -0000 @@ -1027,7 +1027,11 @@ if (cmd->opcode == O_LOG) cmd += F_LEN(cmd); +#ifdef I386 fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; +#else + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); +#endif if (fs != NULL) return fs; @@ -1049,7 +1053,11 @@ } /* record for the future */ #if IPFW2 +#ifdef I386 ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; +#else + bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); +#endif #else if (fs != NULL) rule->pipe_ptr = fs; Index: sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.76 diff -u -r1.76 ip_fw.h --- sys/netinet/ip_fw.h 15 Mar 2003 01:13:00 -0000 1.76 +++ sys/netinet/ip_fw.h 11 May 2003 07:20:28 -0000 @@ -32,11 +32,16 @@ * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet - * (or its metatada) should be analysed. + * (or its metadata) should be analysed. * * Each instruction is stored in a structure which begins with * "ipfw_insn", and can contain extra fields depending on the * instruction type (listed below). + * Note that the code is written so that individual instructions + * have a size which is a multiple of 32 bits. This means that, if + * such structures contain pointers or other 64-bit entities, + * (there is just one instance now) they may end up unaligned on + * 64-bit architectures, so the must be handled with care. * * "enum ipfw_opcodes" are the opcodes supported. We can have up * to 256 different opcodes. @@ -211,7 +216,7 @@ ipfw_insn o; union { struct in_addr ip; - int unit; + int32_t unit; } p; char name[IFNAMSIZ]; } ipfw_insn_if; @@ -220,10 +225,13 @@ * This is used for pipe and queue actions, which need to store * a single pointer (which can have different size on different * architectures. + * Note that, because of previous instructions, pipe_ptr might + * be unaligned in the overall structure, so it needs to be + * manipulated with care. */ typedef struct _ipfw_insn_pipe { ipfw_insn o; - void *pipe_ptr; + void *pipe_ptr; /* XXX */ } ipfw_insn_pipe; /* @@ -278,7 +286,9 @@ struct ip_fw { struct ip_fw *next; /* linked list of rules */ struct ip_fw *next_rule; /* ptr to next [skipto] rule */ +#if 0 /* passed up using 'next_rule' */ u_int32_t set_disable; /* disabled sets (for userland) */ +#endif u_int16_t act_ofs; /* offset of action in 32-bit units */ u_int16_t cmd_len; /* # of 32-bit words in cmd */ u_int16_t rulenum; /* rule number */ @@ -319,12 +329,12 @@ struct _ipfw_dyn_rule { ipfw_dyn_rule *next; /* linked list of rules. */ - struct ipfw_flow_id id; /* (masked) flow id */ struct ip_fw *rule; /* pointer to rule */ ipfw_dyn_rule *parent; /* pointer to parent rule */ - u_int32_t expire; /* expire time */ u_int64_t pcnt; /* packet match counter */ u_int64_t bcnt; /* byte match counter */ + struct ipfw_flow_id id; /* (masked) flow id */ + u_int32_t expire; /* expire time */ u_int32_t bucket; /* which bucket in hash table */ u_int32_t state; /* state of this rule (typically a * combination of TCP flags) @@ -334,7 +344,9 @@ /* to generate keepalives) */ u_int16_t dyn_type; /* rule type */ u_int16_t count; /* refcount */ +#if 0 /* passed up with 'rule' */ u_int16_t rulenum; /* rule number (for userland) */ +#endif }; /* Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.28 diff -u -r1.28 ip_fw2.c --- sys/netinet/ip_fw2.c 15 Mar 2003 01:13:00 -0000 1.28 +++ sys/netinet/ip_fw2.c 11 May 2003 07:21:40 -0000 @@ -2017,8 +2017,15 @@ if (cmd->o.opcode != O_PIPE && cmd->o.opcode != O_QUEUE) continue; - if (match == NULL || cmd->pipe_ptr == match) - cmd->pipe_ptr = NULL; + /* + * XXX Use bcmp/bzero to handle pipe_ptr to overcome + * possible alignment problems on 64-bit architectures. + * This code is seldom used so we do not worry too + * much about efficiency. + */ + if (match == NULL || + !bcmp(&cmd->pipe_ptr, &match, sizeof(match)) ) + bzero(&cmd->pipe_ptr, sizeof(cmd->pipe_ptr)); } } @@ -2559,7 +2566,8 @@ for (rule = layer3_chain; rule ; rule = rule->next) { int i = RULESIZE(rule); bcopy(rule, bp, i); - ((struct ip_fw *)bp)->set_disable = set_disable; + bcopy(&set_disable, &(bp->next_rule), + sizeof(set_disable)); bp = (struct ip_fw *)((char *)bp + i); } if (ipfw_dyn_v) { @@ -2571,7 +2579,8 @@ for ( p = ipfw_dyn_v[i] ; p != NULL ; p = p->next, dst++ ) { bcopy(p, dst, sizeof *p); - dst->rulenum = p->rule->rulenum; + bcopy(&(p->rule->rulenum), &(dst->rule), + sizeof(p->rule->rulenum)); /* * store a non-null value in "next". * The userland code will interpret a Index: sbin/ipfw/ipfw2.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.23 diff -u -r1.23 ipfw2.c --- sbin/ipfw/ipfw2.c 15 Mar 2003 01:12:59 -0000 1.23 +++ sbin/ipfw/ipfw2.c 11 May 2003 09:00:26 -0000 @@ -813,8 +813,9 @@ int flags = 0; /* prerequisites */ ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */ int or_block = 0; /* we are in an or block */ + u_int32_t set_disable; - u_int32_t set_disable = rule->set_disable; + bcopy(rule->next_rule, &set_disable, sizeof(set_disable)); if (set_disable & (1 << rule->set)) { /* disabled */ if (!show_sets) @@ -1213,13 +1214,16 @@ { struct protoent *pe; struct in_addr a; + uint16_t rulenum; if (!do_expired) { if (!d->expire && !(d->dyn_type == O_LIMIT_PARENT)) return; } - printf("%05d %*llu %*llu (%ds)", d->rulenum, pcwidth, d->pcnt, bcwidth, + bcopy(d->rule, &rulenum, sizeof(rulenum)); + + printf("%05d %*llu %*llu (%ds)", rulenum, pcwidth, d->pcnt, bcwidth, d->bcnt, d->expire); switch (d->dyn_type) { case O_LIMIT_PARENT: @@ -1454,7 +1458,9 @@ err(EX_OSERR, "malloc"); if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, &nbytes) < 0) err(EX_OSERR, "getsockopt(IP_FW_GET)"); - set_disable = ((struct ip_fw *)data)->set_disable; + bcopy(((struct ip_fw *)data)->next_rule, + &set_disable, sizeof(set_disable)); + for (i = 0, msg = "disable" ; i < 31; i++) if ( (set_disable & (1<rulenum > rnum) + uint16_t rulenum; + + bcopy(d->rule, &rulenum, sizeof(rulenum)); + if (rulenum > rnum) break; - if (d->rulenum == rnum) + if (rulenum == rnum) show_dyn_ipfw(d, pcwidth, bcwidth); } } --tThc/1wpZn/ma/RB-- From owner-freebsd-alpha@FreeBSD.ORG Sun May 18 22:48:07 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98FA237B401; Sun, 18 May 2003 22:48:07 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 281A743FD7; Sun, 18 May 2003 22:47:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h4J5lNQg036073; Sun, 18 May 2003 22:47:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4J5lNbK036072; Sun, 18 May 2003 22:47:23 -0700 (PDT) (envelope-from rizzo) Date: Sun, 18 May 2003 22:47:23 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20030518224723.A35944@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Mailman-Approved-At: Mon, 19 May 2003 04:54:58 -0700 Subject: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 05:48:08 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Bcc to alpha@ and sparc64@ -- sorry for the crosspost, but i need feedback from people using these boxes] Hi, in the past there have been reports about panics on 64 bit architectures due to unaligned accesses to parts of the ipfw2 rules. The attached patch tries to fix them. I tested that it compiles, but couldn't run it on the relevant architectures for lack of hardware, and have not found yet anyone who wanted to try it. If you care and want to spend a few minutes to test the patch on a Sparc64 or Alpha box and provide feedback, I'd ask you to do the following: STEP 1: try to reproduce the panic + compile a kernel (a recent CURRENT or STABLE) WITHOUT THE PATCH (i.e. with standard sources) with the following options: options IPFIREWALL options DUMMYNET options IPFW2 # only in STABLE (on STABLE, make sure you also have rebuilt ipfw with make -DIPFW2) + [THIS SHOULD TRIGGER A PANIC] reboot with the new kernel and configure ipfw with one of the following configurations, and fire some traffic at the firewall (e.g. "ssh localhost") to try and cause a panic. If these configuration do not cause a panic and you know a better one, please post it. ipfw pipe 1 config ipfw add pipe 1 tcp from any to any 1-65535,1-65535 or ipfw pipe 1 config ipfw add pipe 1 tcp from any to any 1-65535,1-65535,1-65535 or ipfw add allow tcp from any to any 1-65535,1-65535 or ipfw add allow tcp from any to any 1-65535,1-65535,1-65535 STEP 2: test the patch + patch sys/netinet/ and sbin/ipfw/ with the attached patch, rebuild and reinstall kernel and ipfw, and try again to see if the panic does not occur anymore. The patch is for -current, but it should apply to -stable with relatively little effort (see the description below). Feedback would be really appreciated if you want to have this fixed for 5.1 cheers luigi --------------------------------------- Description and proposed patch for ipfw[2] panics on 64-bit architectures. BACKGROUND ipfw2 has been designed so that rules are made of a standard header, followed by a sequence of [micro]instructions (represented by C struct's), each one having a length of a multiple of 32 bits. Because instructions are written one after the other without padding, variables of size > 32bit which reside within each struct might end up unaligned, and the compiler cannot help fixing this. I am listing below some of the approaches that can be used to avoid the problem; because such occurences are extremely rare (there is actually only one instance, "void *pipe_ptr" within "struct _ipfw_insn_pipe"), i believe the first approach to be the easiest to implement and also the most effective in terms of memory occupation and code modifications. Solution #1: handle the critical 64-bit objects with bcopy/bcmp instead of accessing them directly. This is slightly inefficient but fortunately the only instance when it needs to be done is when passing a packet to a dummynet pipe. Also, the size of the copy/compare is known at compile time, so i suppose it might be candidate to some compiler optimizations. Solution #2: make the size of each microinstruction a multiple of 64 bits, so the alignment can be guaranteed by the compiler. This would generate quite an increase of the instruction sizes, and more importantly, would require a significant revision of the ipfw code. The good thing of this approach is that, once done, would put on the compiler the burden of providing the alignment. Solution #3: possibly introduce a padding (in the form of NOP instructions) before those instructions which need alignment. This also requires some amount of extra code to introduce the padding when necessary, and leaves the burden of providing the aligment on the programmer. DESCRIPTION OF THE ATTACHED PATCH The attached patch modifies the following files: src/sys/netinet/ip_dummynet.c src/sys/netinet/ip_fw.h src/sys/netinet/ip_fw2.c src/sbin/ipfw2.c and the changes are the following: sys/netinet/ip_dummynet.c: use bcopy to read/write the "pipe_ptr" field of "struct _ipfw_insn_pipe" on non-i386 architectures (which might be sensitive to alignment problems). This is invoked only in two places, when passing a packet to a dummynet pipe. src/sys/netinet/ip_fw.h @@ -32,11 +32,16 @@ add a comment to explain the alignment problems. @@ -211,7 +216,7 @@ change "int unit" to "int32_t unit" to save space on those architectures where int are 64 bits. @@ -220,10 +225,13 @@ add a comment explaining that "void *pipe_ptr" must be treated carefully @@ -278,7 +286,9 @@ remove the unnecessary field "set_disable" from "struct ip_fw". The set of disabled rulesets is passed up to userspace through the "next rule" pointer (unused otherwise, in that context), which is manipulated using bcopy to avoid aligmnent problems. NOTE: by doing this, we revert to the method used by ipfw2 in 4.x, so we should save the change in that branch. @@ -319,12 +329,12 @@ reorder some fields of _ipfw_dyn_rule to reduce the amount of padding. NOTE: This change is not strictly necessary, and could be omitted if we want to keep the struct unchanged (this is only true for the to 4.x branch, because the "rulenum" field from the same struct should be removed anyways, see the diff below). @@ -334,7 +344,9 @@ remove the "rulenum" field from struct _ipfw_dyn_rule, same as done for "set_disable" in "struct ip_fw". sys/netinet/ip_fw2.c @@ -2017,8 +2017,15 @@ use bcmp/bzero to manipulate pipe_ptr. As the comment says, this is done very infrequently so efficiency is not a concern. @@ -2559,7 +2566,8 @@ @@ -2571,7 +2579,8 @@ use bcopy to pass up info from the kernel to userland through an unused pointer, to avoid aligmnent problems. sbin/ipfw/ipfw2.c @@ -813,8 +813,9 @@ @@ -1454,7 +1458,9 @@ use bcopy to fetch the "set_disable" info into a u_int32_t variable @@ -1213,13 +1214,16 @@ @@ -1690,9 +1696,12 @@ use bcopy to fetch the "rulenum" info into a uint16_t variable. ------------------------------ --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw2.diff" Index: sys/netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.63 diff -u -r1.63 ip_dummynet.c --- sys/netinet/ip_dummynet.c 27 Mar 2003 15:00:10 -0000 1.63 +++ sys/netinet/ip_dummynet.c 11 May 2003 07:19:56 -0000 @@ -1027,7 +1027,11 @@ if (cmd->opcode == O_LOG) cmd += F_LEN(cmd); +#ifdef I386 fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; +#else + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); +#endif if (fs != NULL) return fs; @@ -1049,7 +1053,11 @@ } /* record for the future */ #if IPFW2 +#ifdef I386 ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; +#else + bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); +#endif #else if (fs != NULL) rule->pipe_ptr = fs; Index: sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.76 diff -u -r1.76 ip_fw.h --- sys/netinet/ip_fw.h 15 Mar 2003 01:13:00 -0000 1.76 +++ sys/netinet/ip_fw.h 11 May 2003 07:20:28 -0000 @@ -32,11 +32,16 @@ * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet - * (or its metatada) should be analysed. + * (or its metadata) should be analysed. * * Each instruction is stored in a structure which begins with * "ipfw_insn", and can contain extra fields depending on the * instruction type (listed below). + * Note that the code is written so that individual instructions + * have a size which is a multiple of 32 bits. This means that, if + * such structures contain pointers or other 64-bit entities, + * (there is just one instance now) they may end up unaligned on + * 64-bit architectures, so the must be handled with care. * * "enum ipfw_opcodes" are the opcodes supported. We can have up * to 256 different opcodes. @@ -211,7 +216,7 @@ ipfw_insn o; union { struct in_addr ip; - int unit; + int32_t unit; } p; char name[IFNAMSIZ]; } ipfw_insn_if; @@ -220,10 +225,13 @@ * This is used for pipe and queue actions, which need to store * a single pointer (which can have different size on different * architectures. + * Note that, because of previous instructions, pipe_ptr might + * be unaligned in the overall structure, so it needs to be + * manipulated with care. */ typedef struct _ipfw_insn_pipe { ipfw_insn o; - void *pipe_ptr; + void *pipe_ptr; /* XXX */ } ipfw_insn_pipe; /* @@ -278,7 +286,9 @@ struct ip_fw { struct ip_fw *next; /* linked list of rules */ struct ip_fw *next_rule; /* ptr to next [skipto] rule */ +#if 0 /* passed up using 'next_rule' */ u_int32_t set_disable; /* disabled sets (for userland) */ +#endif u_int16_t act_ofs; /* offset of action in 32-bit units */ u_int16_t cmd_len; /* # of 32-bit words in cmd */ u_int16_t rulenum; /* rule number */ @@ -319,12 +329,12 @@ struct _ipfw_dyn_rule { ipfw_dyn_rule *next; /* linked list of rules. */ - struct ipfw_flow_id id; /* (masked) flow id */ struct ip_fw *rule; /* pointer to rule */ ipfw_dyn_rule *parent; /* pointer to parent rule */ - u_int32_t expire; /* expire time */ u_int64_t pcnt; /* packet match counter */ u_int64_t bcnt; /* byte match counter */ + struct ipfw_flow_id id; /* (masked) flow id */ + u_int32_t expire; /* expire time */ u_int32_t bucket; /* which bucket in hash table */ u_int32_t state; /* state of this rule (typically a * combination of TCP flags) @@ -334,7 +344,9 @@ /* to generate keepalives) */ u_int16_t dyn_type; /* rule type */ u_int16_t count; /* refcount */ +#if 0 /* passed up with 'rule' */ u_int16_t rulenum; /* rule number (for userland) */ +#endif }; /* Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.28 diff -u -r1.28 ip_fw2.c --- sys/netinet/ip_fw2.c 15 Mar 2003 01:13:00 -0000 1.28 +++ sys/netinet/ip_fw2.c 11 May 2003 07:21:40 -0000 @@ -2017,8 +2017,15 @@ if (cmd->o.opcode != O_PIPE && cmd->o.opcode != O_QUEUE) continue; - if (match == NULL || cmd->pipe_ptr == match) - cmd->pipe_ptr = NULL; + /* + * XXX Use bcmp/bzero to handle pipe_ptr to overcome + * possible alignment problems on 64-bit architectures. + * This code is seldom used so we do not worry too + * much about efficiency. + */ + if (match == NULL || + !bcmp(&cmd->pipe_ptr, &match, sizeof(match)) ) + bzero(&cmd->pipe_ptr, sizeof(cmd->pipe_ptr)); } } @@ -2559,7 +2566,8 @@ for (rule = layer3_chain; rule ; rule = rule->next) { int i = RULESIZE(rule); bcopy(rule, bp, i); - ((struct ip_fw *)bp)->set_disable = set_disable; + bcopy(&set_disable, &(bp->next_rule), + sizeof(set_disable)); bp = (struct ip_fw *)((char *)bp + i); } if (ipfw_dyn_v) { @@ -2571,7 +2579,8 @@ for ( p = ipfw_dyn_v[i] ; p != NULL ; p = p->next, dst++ ) { bcopy(p, dst, sizeof *p); - dst->rulenum = p->rule->rulenum; + bcopy(&(p->rule->rulenum), &(dst->rule), + sizeof(p->rule->rulenum)); /* * store a non-null value in "next". * The userland code will interpret a Index: sbin/ipfw/ipfw2.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.23 diff -u -r1.23 ipfw2.c --- sbin/ipfw/ipfw2.c 15 Mar 2003 01:12:59 -0000 1.23 +++ sbin/ipfw/ipfw2.c 11 May 2003 09:00:26 -0000 @@ -813,8 +813,9 @@ int flags = 0; /* prerequisites */ ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */ int or_block = 0; /* we are in an or block */ + u_int32_t set_disable; - u_int32_t set_disable = rule->set_disable; + bcopy(rule->next_rule, &set_disable, sizeof(set_disable)); if (set_disable & (1 << rule->set)) { /* disabled */ if (!show_sets) @@ -1213,13 +1214,16 @@ { struct protoent *pe; struct in_addr a; + uint16_t rulenum; if (!do_expired) { if (!d->expire && !(d->dyn_type == O_LIMIT_PARENT)) return; } - printf("%05d %*llu %*llu (%ds)", d->rulenum, pcwidth, d->pcnt, bcwidth, + bcopy(d->rule, &rulenum, sizeof(rulenum)); + + printf("%05d %*llu %*llu (%ds)", rulenum, pcwidth, d->pcnt, bcwidth, d->bcnt, d->expire); switch (d->dyn_type) { case O_LIMIT_PARENT: @@ -1454,7 +1458,9 @@ err(EX_OSERR, "malloc"); if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, &nbytes) < 0) err(EX_OSERR, "getsockopt(IP_FW_GET)"); - set_disable = ((struct ip_fw *)data)->set_disable; + bcopy(((struct ip_fw *)data)->next_rule, + &set_disable, sizeof(set_disable)); + for (i = 0, msg = "disable" ; i < 31; i++) if ( (set_disable & (1<rulenum > rnum) + uint16_t rulenum; + + bcopy(d->rule, &rulenum, sizeof(rulenum)); + if (rulenum > rnum) break; - if (d->rulenum == rnum) + if (rulenum == rnum) show_dyn_ipfw(d, pcwidth, bcwidth); } } --qDbXVdCdHGoSgWSk-- From owner-freebsd-alpha@FreeBSD.ORG Tue May 20 19:46:30 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77CC537B401 for ; Tue, 20 May 2003 19:46:30 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D23743FB1 for ; Tue, 20 May 2003 19:46:29 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4L2kHrN008288 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 21 May 2003 04:46:24 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4L2kFOs011571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2003 04:46:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h4L2kFPY041895; Wed, 21 May 2003 04:46:15 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h4L2kD8a041894; Wed, 21 May 2003 04:46:13 +0200 (CEST) Date: Wed, 21 May 2003 04:46:13 +0200 From: Bernd Walter To: Wilko Bulte Message-ID: <20030521024613.GH21312@cicely12.cicely.de> References: <20030518144616.GA30720@freebie.xs4all.nl> <20030518174029.GA31140@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030518174029.GA31140@freebie.xs4all.nl> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-BETA alpha User-Agent: Mutt/1.5.4i cc: alpha@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: Alpha release X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 02:46:30 -0000 On Sun, May 18, 2003 at 07:40:29PM +0200, Wilko Bulte wrote: > On Sun, May 18, 2003 at 06:39:06PM +0200, Dag-Erling Smorgrav wrote: > > Wilko Bulte writes: > > > On Sun, May 18, 2003 at 01:03:30PM +0200, Dag-Erling Smorgrav wrote: > > > > JFYI, my PWS just finished a 'release' tinderbox run... I used > > > > NOCDROM, NODOC, NOPORTS to save disk space, but otherwise it was a > > > > complete 'make release' of top-of-tree -CURRENT. > > > Did the floppies run out of inodes, like Ruslan reported? They > > > did for my build. > > > > Yes, they did, but the release still completed... > > Same here. I'm not through yet with fresh source, but I got the following on console: May 21 03:37:53 cicely12 kernel: pid 23354 (tbl), uid 0: exited on signal 4 (core dumped) May 21 03:37:58 cicely12 kernel: pid 23439 (tbl), uid 0: exited on signal 4 (core dumped) May 21 03:42:29 cicely12 kernel: pid 27535 (tbl), uid 0: exited on signal 4 (core dumped) These must have been from the make release run, but the make release did not stop. Next time I will pipe the make release output into a file so I can find out where those happened. /var/d3/alpha-release/usr/obj/usr/src/lib/libutil/tbl.core /var/d3/alpha-release/usr/obj/usr/src/lib/libalias/tbl.core /var/d3/alpha-release/usr/obj/usr/src/lib/libc_r/tbl.core -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-alpha@FreeBSD.ORG Wed May 21 15:19:51 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12FF737B401 for ; Wed, 21 May 2003 15:19:51 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA6A43F3F for ; Wed, 21 May 2003 15:19:49 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4LMJirN023032 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 22 May 2003 00:19:47 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4LMJgOs016614 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 22 May 2003 00:19:43 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.6/8.12.6) with ESMTP id h4LMJfFP030933 for ; Thu, 22 May 2003 00:19:42 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.6/8.12.6/Submit) id h4LMJfda030932 for freebsd-alpha@freebsd.org; Thu, 22 May 2003 00:19:41 +0200 (CEST) Date: Thu, 22 May 2003 00:19:41 +0200 From: Bernd Walter To: freebsd-alpha@freebsd.org Message-ID: <20030521221940.GB30678@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Subject: KN300 testers needed for irq patch X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:19:51 -0000 http://www.cosmo-project.de/~bernd/mcbus.int.patch The patch handles interrupt routing over PCI-PCI bridges on kn300 systems. It was tested on a 4100, but I would like to see results from other systems too. If you test with bridged cards, you may need to add some kind of *MEMIO into your kernel config, as IO space may not be configured behind bridges. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-alpha@FreeBSD.ORG Wed May 21 16:19:18 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 130F937B401 for ; Wed, 21 May 2003 16:19:18 -0700 (PDT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6CB843F85 for ; Wed, 21 May 2003 16:19:16 -0700 (PDT) (envelope-from tilman@arved.de) Received: from sauna.arved.de (sauna.arved.de [192.168.2.4]) h4LNJFDp019478 for ; Thu, 22 May 2003 01:19:15 +0200 (CEST) (envelope-from tilman@arved.de) Received: from sauna.arved.de (sauna.arved.de [127.0.0.1]) by sauna.arved.de (8.12.9/8.12.9) with ESMTP id h4LNJFIZ037488 for ; Thu, 22 May 2003 01:19:15 +0200 (CEST) (envelope-from tilman@arved.de) Received: (from tilman@localhost) by sauna.arved.de (8.12.9/8.12.9/Submit) id h4LNJF7s037487; Thu, 22 May 2003 01:19:15 +0200 (CEST) Message-Id: <200305212319.h4LNJF7s037487@sauna.arved.de> X-Authentication-Warning: sauna.arved.de: tilman set sender to tilman@arved.de using -f Date: Thu, 22 May 2003 01:19:15 +0200 From: Tilman Linneweh To: freebsd-alpha@FreeBSD.org X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Netbooting KSP INVAL X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 23:19:18 -0000 Hi, Probably a FAQ but i haven't figured it out on my own. I am trying to netboot a 3000er. >>> boot ez0 [..] AUDIT_BOOT_STARTS AUDIT_BOOT_REQ kernel.alpha Host Server IP address 192.168.2.4 AUDIT_BSERVER_FOUND AUDIT_LOAD_BEGINS ................ AUDIT_LOAD_DONE ?02 KSP INVAL What am I doing wrong? kernel.alpha is the gunzipped kernel from the 4.8 or 5.0 boot Floppy. (I know I need a customized kernel for nfs mounting, but the GENERIC should at least load, before I start to crossbuilding.) regards tilman -- From owner-freebsd-alpha@FreeBSD.ORG Wed May 21 16:55:21 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20A6037B401 for ; Wed, 21 May 2003 16:55:21 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id F12B143F85 for ; Wed, 21 May 2003 16:55:19 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4LNt4rN024240 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 May 2003 01:55:13 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4LNt2Os017077 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 May 2003 01:55:03 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.6/8.12.6) with ESMTP id h4LNt1FP031195; Thu, 22 May 2003 01:55:01 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.6/8.12.6/Submit) id h4LNt1OW031194; Thu, 22 May 2003 01:55:01 +0200 (CEST) Date: Thu, 22 May 2003 01:55:01 +0200 From: Bernd Walter To: Tilman Linneweh Message-ID: <20030521235500.GE30678@cicely8.cicely.de> References: <200305212319.h4LNJF7s037487@sauna.arved.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305212319.h4LNJF7s037487@sauna.arved.de> X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i cc: freebsd-alpha@freebsd.org Subject: Re: Netbooting KSP INVAL X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 23:55:21 -0000 On Thu, May 22, 2003 at 01:19:15AM +0200, Tilman Linneweh wrote: > Hi, > > Probably a FAQ but i haven't figured it out on my own. > > I am trying to netboot a 3000er. > > >>> boot ez0 > [..] > AUDIT_BOOT_STARTS > AUDIT_BOOT_REQ kernel.alpha > Host Server IP address 192.168.2.4 > AUDIT_BSERVER_FOUND > AUDIT_LOAD_BEGINS > ................ > AUDIT_LOAD_DONE > > ?02 KSP INVAL > > What am I doing wrong? kernel.alpha is the gunzipped kernel from the 4.8 > or 5.0 boot Floppy. > (I know I need a customized kernel for nfs mounting, but the GENERIC > should at least load, before I start to crossbuilding.) You have to boot the netboot image which then loads the kernel from your / filesystem. Support for 3000 was droped from 5.x because it never got further than netbooting. NetBSD has much better support for your system than FreeBSD ever had. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-alpha@FreeBSD.ORG Thu May 22 09:40:31 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDEF37B401 for ; Thu, 22 May 2003 09:40:31 -0700 (PDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CA8643F75 for ; Thu, 22 May 2003 09:40:30 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5825 invoked from network); 22 May 2003 16:40:29 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 22 May 2003 16:40:29 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h4MGeRp0061395; Thu, 22 May 2003 12:40:28 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030521221940.GB30678@cicely8.cicely.de> Date: Thu, 22 May 2003 12:40:39 -0400 (EDT) From: John Baldwin To: ticso@cicely.de cc: freebsd-alpha@freebsd.org Subject: RE: KN300 testers needed for irq patch X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:40:31 -0000 On 21-May-2003 Bernd Walter wrote: > http://www.cosmo-project.de/~bernd/mcbus.int.patch > The patch handles interrupt routing over PCI-PCI bridges on kn300 > systems. > It was tested on a 4100, but I would like to see results from other > systems too. > If you test with bridged cards, you may need to add some kind of > *MEMIO into your kernel config, as IO space may not be configured > behind bridges. Cool! It's good to see cleaner use of our pci bridge interface! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-alpha@FreeBSD.ORG Fri May 23 11:01:17 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88F4537B401 for ; Fri, 23 May 2003 11:01:17 -0700 (PDT) Received: from priv-edtnes03-hme0.telusplanet.net (outbound01.telus.net [199.185.220.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B87B43FA3 for ; Fri, 23 May 2003 11:01:16 -0700 (PDT) (envelope-from kevin.d@telus.net) Received: from oemcomputer ([64.180.17.104]) by priv-edtnes03-hme0.telusplanet.netSMTP <20030523180115.UBZV23619.priv-edtnes03-hme0.telusplanet.net@oemcomputer>; Fri, 23 May 2003 12:01:15 -0600 Message-ID: <001301c32154$d934ee00$6811b440@bc.hsia.telus.net> From: "Kevin Miller" To: , Date: Fri, 23 May 2003 10:57:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Contact information for Vadim Mikhailov X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 18:01:17 -0000 Hi, I'm planning a trip to Moscow in June, and I'd like to meet Vadim Mikhailov, leader of the Diggers of the Underground Planet. Do you have any contact information for him? Kevin Miller Author/Editor/Educator Visit my web site at www.kevinwrites.com See my latest books, All About Time, All About Money, and Kiddictionary at www.amazon.com Check out my online course at: http://www.coffeehouseforwriters.com/hero.html From owner-freebsd-alpha@FreeBSD.ORG Sat May 24 13:26:52 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D40EB37B401; Sat, 24 May 2003 13:26:52 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8149043F3F; Sat, 24 May 2003 13:26:52 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 68A9F2A7EA; Sat, 24 May 2003 13:26:52 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Luigi Rizzo In-Reply-To: <20030519004914.B46011@xorpc.icir.org> Date: Sat, 24 May 2003 13:26:52 -0700 From: Peter Wemm Message-Id: <20030524202652.68A9F2A7EA@canning.wemm.org> cc: freebsd-alpha@freebsd.org Subject: Re: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 20:26:53 -0000 Luigi Rizzo wrote: > if (cmd->opcode == O_LOG) > cmd += F_LEN(cmd); > +#ifdef I386 > fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; > +#else > + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); > +#endif > This is not a 'reviewed-by:', but these should be #ifdef __i386__ rather than #ifdef I386. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-alpha@FreeBSD.ORG Sat May 24 13:30:24 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC82637B401 for ; Sat, 24 May 2003 13:30:24 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1317243F85 for ; Sat, 24 May 2003 13:30:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h4OKUNQg099468; Sat, 24 May 2003 13:30:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4OKUNdi099467; Sat, 24 May 2003 13:30:23 -0700 (PDT) (envelope-from rizzo) Date: Sat, 24 May 2003 13:30:23 -0700 From: Luigi Rizzo To: Peter Wemm Message-ID: <20030524133023.A99306@xorpc.icir.org> References: <20030519004914.B46011@xorpc.icir.org> <20030524202652.68A9F2A7EA@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030524202652.68A9F2A7EA@canning.wemm.org>; from peter@wemm.org on Sat, May 24, 2003 at 01:26:52PM -0700 cc: freebsd-alpha@freebsd.org Subject: Re: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 20:30:25 -0000 On Sat, May 24, 2003 at 01:26:52PM -0700, Peter Wemm wrote: > Luigi Rizzo wrote: > > > if (cmd->opcode == O_LOG) > > cmd += F_LEN(cmd); > > +#ifdef I386 > > fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; > > +#else > > + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); > > +#endif > > > > This is not a 'reviewed-by:', but these should be #ifdef __i386__ > rather than #ifdef I386. yes, i posted the wrong one... thanks luigi > From owner-freebsd-alpha@FreeBSD.ORG Sat May 24 13:44:06 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 563E137B401 for ; Sat, 24 May 2003 13:44:06 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id E633243F85 for ; Sat, 24 May 2003 13:44:04 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17029 invoked from network); 24 May 2003 20:44:04 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 24 May 2003 20:44:04 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h4OKi2p0070921; Sat, 24 May 2003 16:44:02 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030524202652.68A9F2A7EA@canning.wemm.org> Date: Sat, 24 May 2003 16:44:15 -0400 (EDT) From: John Baldwin To: Peter Wemm cc: Luigi Rizzo cc: freebsd-alpha@freebsd.org Subject: Re: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 20:44:06 -0000 On 24-May-2003 Peter Wemm wrote: > Luigi Rizzo wrote: > >> if (cmd->opcode == O_LOG) >> cmd += F_LEN(cmd); >> +#ifdef I386 >> fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; >> +#else >> + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); >> +#endif >> > > This is not a 'reviewed-by:', but these should be #ifdef __i386__ > rather than #ifdef I386. Why is the #ifdef even there? Why not use bcopy all the time? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-alpha@FreeBSD.ORG Sat May 24 14:04:20 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B20D37B401; Sat, 24 May 2003 14:04:20 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A42F43F75; Sat, 24 May 2003 14:04:19 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h4OL4JQg003634; Sat, 24 May 2003 14:04:19 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4OL4Jqe003633; Sat, 24 May 2003 14:04:19 -0700 (PDT) (envelope-from rizzo) Date: Sat, 24 May 2003 14:04:19 -0700 From: Luigi Rizzo To: John Baldwin Message-ID: <20030524140419.A3621@xorpc.icir.org> References: <20030524202652.68A9F2A7EA@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Sat, May 24, 2003 at 04:44:15PM -0400 cc: freebsd-alpha@FreeBSD.org Subject: Re: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 21:04:20 -0000 On Sat, May 24, 2003 at 04:44:15PM -0400, John Baldwin wrote: ... > >> +#ifdef I386 > >> fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; > >> +#else > >> + bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); > >> +#endif > >> > > > > This is not a 'reviewed-by:', but these should be #ifdef __i386__ > > rather than #ifdef I386. > > Why is the #ifdef even there? Why not use bcopy all the time? performance maybe ? This particular one is called everytime you deliver a packet to a dummynet pipe. cheers luigi > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/