From owner-freebsd-sparc64@FreeBSD.ORG Mon May 19 01:20:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D84937B401 for ; Mon, 19 May 2003 01:20:19 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB8343FB1 for ; Mon, 19 May 2003 01:20:18 -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 h4J8KIQg061670 for ; Mon, 19 May 2003 01:20:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4J8KIRQ061669 for freebsd-sparc64@freebsd.org; Mon, 19 May 2003 01:20:18 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 May 2003 01:20:17 -0700 From: Luigi Rizzo To: freebsd-sparc64@freebsd.org Message-ID: <20030519012017.A61450@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 08:20:20 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ----- Forwarded message from Luigi Rizzo ----- Date: Sun, 18 May 2003 22:47:23 -0700 From: Luigi Rizzo Subject: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 To: ipfw@freebsd.org [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. ------------------------------ 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 ----- --3MwIy2ne0vdjdPXF 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); } } --3MwIy2ne0vdjdPXF-- From owner-freebsd-sparc64@FreeBSD.ORG Sun May 18 22:48:07 2003 Return-Path: Delivered-To: freebsd-sparc64@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:55:49 -0700 Subject: [FEEDBACK REQUIRED] patch for ipfw/ipfw2 on alpha/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc 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-sparc64@FreeBSD.ORG Mon May 19 12:40:00 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C787037B401 for ; Mon, 19 May 2003 12:40:00 -0700 (PDT) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47E8643F85 for ; Mon, 19 May 2003 12:40:00 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) C16053BF572 for ; Mon, 19 May 2003 13:39:59 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h4JJdxZ14659 for ; Mon, 19 May 2003 13:39:59 -0600 (MDT) Date: Mon, 19 May 2003 13:45:39 -0600 (MDT) From: Fred Clift X-X-Sender: fred@vespa.dmz.orem.verio.net To: freebsd-sparc64@freebsd.org Message-ID: <20030519133345.Y34980@irfcn.qzm.berz.irevb.arg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: usage of boot.flp X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 19:40:01 -0000 I have a SPARCengine(tm)Ultra(tm) AXi (UltraSPARC-IIi 360MHz), No Keyboard OpenBoot 3.10.4 SME, 128 MB memory installed, Serial #10425614. which I want to put FreeBSD 5.1-BETA on. I grabbed the boot.flp (a bit over 4 MB), dropped it into my ftfp/rarp/bootparams server and made made all the setup right afaik. The file is properly tftp'd when I 'boot net' and I get ... Boot device: /pci@1f,0/pci@1,1/network@1,1 File and args: - 404000 (this line counts up as it loads the file...) The file just loaded does not appear to be executable. ... Should I be doing something different with this? I was hoping not to have to download and burn a CD... Or am I just doing this wrong? Hm -- perhaps i should boot into my network recovery shell and dd this over the first slice? I'm new to FreeBSD on sparc64 - thanks for your patience and help. Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-sparc64@FreeBSD.ORG Mon May 19 15:28:35 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3546A37B401 for ; Mon, 19 May 2003 15:28:35 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6114243F85 for ; Mon, 19 May 2003 15:28:34 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.9/8.12.9) with ESMTP id h4JMTKxw018299; Mon, 19 May 2003 18:29:20 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.9/8.12.9/Submit) id h4JMTJLC018298; Mon, 19 May 2003 18:29:19 -0400 (EDT) Date: Mon, 19 May 2003 18:29:19 -0400 From: Jake Burkholder To: Fred Clift Message-ID: <20030519222919.GA18282@locore.ca> References: <20030519133345.Y34980@irfcn.qzm.berz.irevb.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030519133345.Y34980@irfcn.qzm.berz.irevb.arg> User-Agent: Mutt/1.4i cc: freebsd-sparc64@freebsd.org Subject: Re: usage of boot.flp X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2003 22:28:35 -0000 Apparently, On Mon, May 19, 2003 at 01:45:39PM -0600, Fred Clift said words to the effect of; > > I have a > > SPARCengine(tm)Ultra(tm) AXi (UltraSPARC-IIi 360MHz), No Keyboard > OpenBoot 3.10.4 SME, 128 MB memory installed, Serial #10425614. > > > which I want to put FreeBSD 5.1-BETA on. I grabbed the boot.flp (a bit > over 4 MB), dropped it into my ftfp/rarp/bootparams server and made made > all the setup right afaik. > > The file is properly tftp'd when I 'boot net' and I get > > ... > Boot device: /pci@1f,0/pci@1,1/network@1,1 File and args: - > 404000 (this line counts up as it loads the file...) > The file just loaded does not appear to be executable. > ... > > > Should I be doing something different with this? I was hoping not to have > to download and burn a CD... > > > Or am I just doing this wrong? Hm -- perhaps i should boot into my > network recovery shell and dd this over the first slice? I'm new to > FreeBSD on sparc64 - thanks for your patience and help. Yes. dd it to a slice and boot from that. Jake From owner-freebsd-sparc64@FreeBSD.ORG Mon May 19 17:50:15 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA88D37B401 for ; Mon, 19 May 2003 17:50:15 -0700 (PDT) Received: from web41312.mail.yahoo.com (web41312.mail.yahoo.com [66.218.93.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 488BF43FAF for ; Mon, 19 May 2003 17:50:15 -0700 (PDT) (envelope-from baby_p_nut@yahoo.com) Message-ID: <20030520005015.45487.qmail@web41312.mail.yahoo.com> Received: from [198.80.171.28] by web41312.mail.yahoo.com via HTTP; Mon, 19 May 2003 17:50:15 PDT Date: Mon, 19 May 2003 17:50:15 -0700 (PDT) From: Baby Peanut To: freebsd-sparc64@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: FreeBSD/sparc64 5.1-BETA on MP Suns? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 00:50:16 -0000 My Ultra-2 with ISP SCSI is still panicing with: db> t panic() at panic+0x134 initiate_write_inodeblock_ufs1() at initiate_write_inodeblock_ufs1+0x32c softdep_disk_io_initiation() at softdep_disk_io_initiation+0x80 spec_xstrategy() at spec_xstrategy+0x134 spec_specstrategy() at spec_specstrategy+0x8 spec_vnoperate() at spec_vnoperate+0x1c bwrite() at bwrite+0x3b8 vfs_bio_awrite() at vfs_bio_awrite+0x1a0 vop_stdfsync() at vop_stdfsync+0x120 spec_fsync() at spec_fsync+0x20 spec_vnoperate() at spec_vnoperate+0x1c ffs_sync() at ffs_sync+0x348 sync() at sync+0xcc syscall() at syscall+0x2a8 -- syscall (36, FreeBSD ELF64, sync) %o7=0x100344 -- userland() at 0x100df8 user trace: trap %o7=0x100344 pc 0x100df8, sp 0x7fdfffff0f1 pc 0x1001f0, sp 0x7fdfffff1b1 pc 0, sp 0x7fdfffff271 done db> When I boot it up, ssh in and type "sync". Does anyone have FreeBSD 5.1-BETA working on a multi-processor Sun box? Thanks, BP __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-freebsd-sparc64@FreeBSD.ORG Mon May 19 18:36:18 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4893237B401 for ; Mon, 19 May 2003 18:36:18 -0700 (PDT) Received: from ms-smtp-01.nyroc.rr.com (ms-smtp-01.nyroc.rr.com [24.92.226.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68F0843F75 for ; Mon, 19 May 2003 18:36:17 -0700 (PDT) (envelope-from klmac@usadatanet.net) Received: from usadatanet.net (syr-24-95-174-30.twcny.rr.com [24.95.174.30]) h4K1aFGm021205 for ; Mon, 19 May 2003 21:36:16 -0400 (EDT) Date: Mon, 19 May 2003 21:37:50 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Ken McKittrick To: freebsd-sparc64@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: developer access for Sparc64 FreeBSD development X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 01:36:18 -0000 Hello I have two Sparc64 machines that I'm willing to contribute for FreeBSD Sparc64 development. I can't give them away, but I can setup user accounts and serial port access. One machine is a Netra T-1 with 2x 18 gig drives and 1 Gig of RAM. The other is a HAL??? Sparc64 clone with a 333MHz processor 9 gig drive and at least 256Meg of RAM. I'll install whatever version of FreeBSD5.x that is needed. I can run console cable to a 3rd machine for serial port access. Email me if your interested. Ken McKittrick Network Engineer USADatanet From owner-freebsd-sparc64@FreeBSD.ORG Mon May 19 18:39:51 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAC6637B401 for ; Mon, 19 May 2003 18:39:51 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-67-115-75-172.dsl.lsan03.pacbell.net [67.115.75.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id DABFB43FB1 for ; Mon, 19 May 2003 18:39:50 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id A2B1E66B9B; Mon, 19 May 2003 18:39:50 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 83BF23B7; Mon, 19 May 2003 18:39:50 -0700 (PDT) Date: Mon, 19 May 2003 18:39:50 -0700 From: Kris Kennaway To: Ken McKittrick Message-ID: <20030520013950.GA9797@rot13.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-sparc64@freebsd.org Subject: Re: developer access for Sparc64 FreeBSD development X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 01:39:52 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 19, 2003 at 09:37:50PM -0400, Ken McKittrick wrote: > Hello >=20 >=20 > I have two Sparc64 machines that I'm willing to contribute for FreeBSD=20 > Sparc64 development. I can't give them away, but I can setup user=20 > accounts and serial port access. >=20 > One machine is a Netra T-1 with 2x 18 gig drives and 1 Gig of RAM. > The other is a HAL??? Sparc64 clone with a 333MHz processor 9 gig drive= =20 > and at least 256Meg of RAM. >=20 > I'll install whatever version of FreeBSD5.x that is needed. I can run=20 > console cable to a 3rd machine for serial port access. >=20 > Email me if your interested. I periodically get enquiries from port maintainers looking for access to non-i386 machines for testing port fixes on. If you're willing to give out access to non-committers this would be a valuable resource, and I suggest advertising on ports@. Kris --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+yYdmWry0BWjoQKURAtEIAJ42T6CVvZ0URgEJNlTlbMCCwHOabACgvZd9 SpFFpMrRhVN8whDyBRTX7kQ= =cTsP -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 02:23:58 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A580437B401 for ; Tue, 20 May 2003 02:23:58 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 723D943FB1 for ; Tue, 20 May 2003 02:23:57 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (inaxyd@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h4K9NsB5001225 for ; Tue, 20 May 2003 11:23:55 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h4K9NsH0001224; Tue, 20 May 2003 11:23:54 +0200 (CEST) Date: Tue, 20 May 2003 11:23:54 +0200 (CEST) Message-Id: <200305200923.h4K9NsH0001224@lurza.secnetix.de> From: Oliver Fromme To: freebsd-sparc64@FreeBSD.ORG X-Newsgroups: list.freebsd-sparc64 User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.8-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: XFree86 on Ultra 5? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-sparc64@FreeBSD.ORG List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 09:23:59 -0000 Hi, Does XFree86 run with FreeBSD on an Ultra 5? I have this Ultra 5 on my desktop and need to decide whether to install Solaris 9 or FreeBSD. I'd rather prefer FreeBSD, because (a) the box has only 128 Mbyte of RAM, and (b) I prefer FreeBSD anyway. :-) However, X11 is a must, because it will be primarily used as an X terminal (only few local programs will be run). I've searched the archive, but haven't found any information whether XFree86 runs with FreeBSD/sparc64 on an Ultra 5 ... Thanks in advance! Regards Oliver PS: No need to Cc me. I read the list. -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 08:40:29 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB3737B401 for ; Tue, 20 May 2003 08:40:29 -0700 (PDT) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E53643FBF for ; Tue, 20 May 2003 08:40:28 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) 34F533BFE33 for ; Tue, 20 May 2003 09:40:28 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h4KFeMZ49199; Tue, 20 May 2003 09:40:22 -0600 (MDT) Date: Tue, 20 May 2003 09:46:06 -0600 (MDT) From: Fred Clift X-X-Sender: fred@vespa.dmz.orem.verio.net To: freebsd-sparc64@freebsd.org In-Reply-To: <20030519222919.GA18282@locore.ca> Message-ID: <20030520093238.X37246@irfcn.qzm.berz.irevb.arg> References: <20030519133345.Y34980@irfcn.qzm.berz.irevb.arg> <20030519222919.GA18282@locore.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 5.1-BETA problems (minor) was Re: usage of boot.flp X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:40:29 -0000 On Mon, 19 May 2003, Jake Burkholder wrote: > Apparently, On Mon, May 19, 2003 at 01:45:39PM -0600, > Fred Clift said words to the effect of; > > Or am I just doing this wrong? Hm -- perhaps i should boot into my > > network recovery shell and dd this over the first slice? I'm new to > > FreeBSD on sparc64 - thanks for your patience and help. > > Yes. dd it to a slice and boot from that. For some reason this didn't work - I got unaligned access traps (hm could be remembering the phrase wrong...) from the boot loader. I dl'd the mini-iso burnt it to a CD, scrounged up a scsi cdrom drive and booted off of that The install is still running as I write this. A couple of minor nits which you all probably know about. I'm using tip running in an xterm as my serial console to this machine. At the beginning of the install, I was presented with a set of 4 choices about terminal type - when I choose xterm, my screen was all garbled and I ended up having to reboot and restart - at which point I chose vt100 and things work just fine. Second, the installer doesn't appear to be aware that krb5 is now part of the base system as it complained about not being able to find that package to install. Similarly, I tried to install the ports tree - no package found... And (using ftp2.freebsd.org for my ftp install) it complained once or twice about not being able to find the index file for the packages that should be there... sure looks like there is a bunch of stuff in /pub/FreeBSD/ports/sparc64/packages-5-current/All on that box, but shrug. I'll try and cvsup ports once the box is up. I guess that since there isn't console support on these machines yet that there probably isn't X support? :). This is mostly just a toy for me to play with. Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 08:54:31 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDFD937B404 for ; Tue, 20 May 2003 08:54:31 -0700 (PDT) Received: from catflap.home.slightlystrange.org (pc1-cmbg1-4-cust43.cmbg.cable.ntl.com [62.253.133.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64B1843F3F for ; Tue, 20 May 2003 08:54:28 -0700 (PDT) (envelope-from dan@slightlystrange.org) Received: from danielby by catflap.home.slightlystrange.org with local (Exim 3.36 #1) id 19I9TM-000Fuz-00 for freebsd-sparc64@FreeBSD.ORG; Tue, 20 May 2003 16:56:16 +0100 Date: Tue, 20 May 2003 16:56:16 +0100 From: Daniel Bye To: freebsd-sparc64@FreeBSD.ORG Message-ID: <20030520155616.GA61022@catflap.home.slightlystrange.org> Mail-Followup-To: freebsd-sparc64@FreeBSD.ORG References: <200305200923.h4K9NsH0001224@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200305200923.h4K9NsH0001224@lurza.secnetix.de> User-Agent: Mutt/1.4.1i X-Scanner: exiscan *19I9TM-000Fuz-00*q1Wo1EBC4/c* (SlightlyStrange.org, Using NOD32 http://www.nod32.com) Subject: Re: XFree86 on Ultra 5? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dan@slightlystrange.org List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 15:54:32 -0000 On Tue, May 20, 2003 at 11:23:54AM +0200, Oliver Fromme wrote: > Hi, > > Does XFree86 run with FreeBSD on an Ultra 5? No - see this page: http://www.freebsd.org/releases/5.0R/DP2/hardware-sparc64.html#AEN29 Particularly section 3.5, unsupported hardware. So far, only a serial console will work, so it's not yet ready to act as a workstation. You *may* be able to get it running as an X server, but you will need to run the display on another machine. A friend of mine tried this a couple of months ago with -CURRENT, but never got it working properly - whether because it can't be done, or because he didn't try hard enough, I couldn't say. ;-) Dan > > I have this Ultra 5 on my desktop and need to decide whether > to install Solaris 9 or FreeBSD. I'd rather prefer FreeBSD, > because (a) the box has only 128 Mbyte of RAM, and (b) I prefer > FreeBSD anyway. :-) > > However, X11 is a must, because it will be primarily used as > an X terminal (only few local programs will be run). > > I've searched the archive, but haven't found any information > whether XFree86 runs with FreeBSD/sparc64 on an Ultra 5 ... > > Thanks in advance! > > Regards > Oliver > > PS: No need to Cc me. I read the list. > > -- > Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 09:21:04 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82B0737B401 for ; Tue, 20 May 2003 09:21:04 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6850D43FAF for ; Tue, 20 May 2003 09:21:03 -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 h4KGKtA9068573 for ; Tue, 20 May 2003 09:20:56 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h4KGKtGF068572 for freebsd-sparc64@FreeBSD.ORG; Tue, 20 May 2003 09:20:55 -0700 (PDT) Date: Tue, 20 May 2003 09:20:55 -0700 From: "David O'Brien" To: freebsd-sparc64@FreeBSD.ORG Message-ID: <20030520161125.GA68325@dragon.nuxi.com> References: <200305200923.h4K9NsH0001224@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305200923.h4K9NsH0001224@lurza.secnetix.de> 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 Subject: Re: XFree86 on Ultra 5? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-sparc64@FreeBSD.ORG List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 16:21:04 -0000 On Tue, May 20, 2003 at 11:23:54AM +0200, Oliver Fromme wrote: > Does XFree86 run with FreeBSD on an Ultra 5? Not at this moment. If you can wait a few weeks, this will probably change. Jake is hacking on X and proper console support right now. From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 09:37:42 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAABC37B401 for ; Tue, 20 May 2003 09:37:42 -0700 (PDT) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F0F43FB1 for ; Tue, 20 May 2003 09:37:40 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) BAE5A3BFE54 for ; Tue, 20 May 2003 10:35:35 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h4KGZZZ62740 for ; Tue, 20 May 2003 10:35:35 -0600 (MDT) Date: Tue, 20 May 2003 10:41:20 -0600 (MDT) From: Fred Clift X-X-Sender: fred@vespa.dmz.orem.verio.net To: freebsd-sparc64@freebsd.org Message-ID: <20030520103752.H37360@irfcn.qzm.berz.irevb.arg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: cvsup binary would be nice X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 16:37:42 -0000 So there don't appear to be any cvsup binary pacakges laying around for sparc64 - I guess I can ftp the ports tree and build it - but it sure would be nice for newcommers to find a few necessary tools available :). Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 09:41:18 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00A7737B401 for ; Tue, 20 May 2003 09:41:18 -0700 (PDT) Received: from analog.databits.net (analog.databits.net [198.78.65.155]) by mx1.FreeBSD.org (Postfix) with SMTP id 90D1F43F75 for ; Tue, 20 May 2003 09:41:17 -0700 (PDT) (envelope-from petef@analog.databits.net) Received: (qmail 89815 invoked by uid 1000); 20 May 2003 16:38:02 -0000 Date: Tue, 20 May 2003 11:38:02 -0500 From: Pete Fritchman To: Fred Clift Message-ID: <20030520163802.GA79521@absolutbsd.org> References: <20030520103752.H37360@irfcn.qzm.berz.irevb.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030520103752.H37360@irfcn.qzm.berz.irevb.arg> User-Agent: Mutt/1.4i cc: freebsd-sparc64@freebsd.org Subject: Re: cvsup binary would be nice X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 16:41:18 -0000 ++ 20/05/03 10:41 -0600 - Fred Clift: | So there don't appear to be any cvsup binary pacakges laying around for | sparc64 - I guess I can ftp the ports tree and build it - but it sure | would be nice for newcommers to find a few necessary tools available :). http://people.freebsd.org/~jdp/cvsup-sparc64/ --pete From owner-freebsd-sparc64@FreeBSD.ORG Tue May 20 15:22:42 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5141A37B401 for ; Tue, 20 May 2003 15:22:42 -0700 (PDT) Received: from dmz2.unixjunkie.com (adsl-65-70-175-250.dsl.rcsntx.swbell.net [65.70.175.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E3D243F93 for ; Tue, 20 May 2003 15:22:39 -0700 (PDT) (envelope-from strgout@unixjunkie.com) Received: from mail.unixjunkie.com (mail [10.253.254.36]) by dmz2.unixjunkie.com (8.12.6p2/8.12.6) with ESMTP id h4KMdb6i023069 for ; Tue, 20 May 2003 17:39:37 -0500 (CDT) (envelope-from strgout@mail.unixjunkie.com) Received: from mail.unixjunkie.com (mail [10.253.254.36]) by mail.unixjunkie.com (8.12.6p2/8.12.6) with ESMTP id h4KMdbns023066 for ; Tue, 20 May 2003 17:39:37 -0500 (CDT) (envelope-from strgout@mail.unixjunkie.com) Received: (from strgout@localhost) by mail.unixjunkie.com (8.12.6p2/8.12.6/Submit) id h4KMdaTi023065 for freebsd-sparc64@freebsd.org; Tue, 20 May 2003 17:39:36 -0500 (CDT) (envelope-from strgout) Date: Tue, 20 May 2003 17:39:36 -0500 From: John To: freebsd-sparc64@freebsd.org Message-ID: <20030520223936.GA23043@mail.unixjunkie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: 5.1-B sync + ping X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 22:22:42 -0000 I just noticed that when i run sync a few times in a row my ping times go from 0.5 to 300-600 untill the syncs are complete. This is a E450 running Generic kernel. dmesg follows. also the hme1 timeout happend when i iped the wrong interface. If anyone would like me to test anything on this just drop me a line. stray vector interrupt 2029 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-BETA #0: Thu May 8 01:11:28 GMT 2003 root@sparkle.attlabs.net:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0488000. Timecounter "tick" frequency 296000000 Hz real memory = 4268269568 (4070 MB) avail memory = 4161200128 (3968 MB) cpu0: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) cpu2: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) cpu3: Sun Microsystems UltraSparc-II Processor (296.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs nexus0: nexus0: , type (unknown) (no driver attached) pcib0: on nexus0 pcib0: Psycho, impl 0, version 4, ign 0x7c0 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfc000000 to 0xffffffff pci0: on pcib0 ebus0: revision 0x01 ebus0: mem 0x71000000-0x717fffff,0x70000000-0x70ffffff at device 1.0 on pci0 ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x 140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 irq 2034,2021 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) ebus0: addr 0x1400500000-0x1400500007 (no driver attached) sab0: addr 0x1400400000-0x140040007f irq 43 on ebus0 sabtty0: on sab0 sabtty1: on sab0 ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) ebus0: addr 0x1400700000-0x140070000f,0x1400300398-0x1400300399,0x14003043bc-0x1 4003043cb irq 2018 (no driver attached) ebus0: addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003023f0- 0x14003023f7 irq 2023 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 80b652a7 ebus0: addr 0x1000000000-0x10000fffff,0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 2021,2024 (no driver attached) hme0: mem 0x8000-0xffff irq 33 at device 1.1 on pci0 hme0: Ethernet address: 08:00:20:b6:52:a7 miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <875> port 0x800-0x8ff mem 0x16000-0x16fff,0x14000-0x140ff irq 38 at device 2.0 o n pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x400-0x4ff mem 0x12000-0x12fff,0x10000-0x100ff irq 32 at device 3.0 o n pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pci0: at device 4.0 (no driver attached) pcib1: on nexus0 pcib1: Psycho, impl 0, version 4, ign 0x7c0 pci1: on pcib1 nexus0: , type memory-controller (no driver attached) pcib2: on nexus0 pcib2: Psycho, impl 0, version 4, ign 0x100 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfc000000 to 0xffffffff pci2: on pcib2 pci2: at device 2.0 (no driver attached) hme1: mem 0x4000000-0x4007fff irq 2 at device 2.1 on pci2 hme1: Ethernet address: 08:00:20:b6:52:a7 miibus1: on hme1 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: on nexus0 pcib3: Psycho, impl 0, version 4, ign 0x100 pci3: on pcib3 pcib4: on nexus0 pcib4: Psycho, impl 0, version 4, ign 0x180 initialializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz DVMA map: 0xfc000000 to 0xffffffff pci4: on pcib4 pcib5: on nexus0 pcib5: Psycho, impl 0, version 4, ign 0x180 pci5: on pcib5 Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle cd0 at sym0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: cd present [494792 x 512 byte records] da0 at sym1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) da1 at sym1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) da3 at sym1 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da3: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) da2 at sym1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da2: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da2a Invalid time in real time clock. Check and reset the date immediately! hme1: device timeout hme1: device timeout From owner-freebsd-sparc64@FreeBSD.ORG Wed May 21 11:18:30 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAFA637B401 for ; Wed, 21 May 2003 11:18:30 -0700 (PDT) Received: from main.onix.ro (main.onix.ro [194.102.104.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320AC43F85 for ; Wed, 21 May 2003 11:18:29 -0700 (PDT) (envelope-from mari@onix.ro) Received: from webmail.onix.ro (localhost [127.0.0.1]) by main.onix.ro (8.11.6/8.11.6) with SMTP id h4LIaSh15968 for ; Wed, 21 May 2003 21:36:28 +0300 Received: from 80.96.131.3 (OnixMail authenticated user mari) by webmail.onix.ro with HTTP; Wed, 21 May 2003 21:36:28 +0300 (EEST) Message-ID: <4190.80.96.131.3.1053542188.squirrel@webmail.onix.ro> Date: Wed, 21 May 2003 21:36:28 +0300 (EEST) From: "Marian Dobre" To: freebsd-sparc64@freebsd.org User-Agent: OnixMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-RAVMilter-Version: 8.4.2(snapshot 20021217) (main) Subject: Qmail X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 18:18:31 -0000 Hi, I'm having a hard time getting qmail to work with daemon tools on my E450 running FreeBSD 5.0 current. This is the output from uname -a FreeBSD freebsd.onix.ro 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #12: Fri May 2 20:15:11 EEST 2003 root@freebsd.onix.ro:/usr/obj/usr/src/sys/CUSTOM sparc64 I've installed qmail and daemontools from ports and it wont start qmail-smtpd. This is the error im getting in /var/log/qmail/smtpd/current @400000003ecbb3470d6c458c /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb34810682454 /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb349136e2cac /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb34a16713f34 /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb34b192da7e4 /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb34c1c5b2d9c /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory @400000003ecbb34d1f8c1a6c /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: mmap of entire address space failed: Cannot allocate memory If you have any ideas why its doing that please let me know. Thanks, Marian ----------------------------------------- This email was sent using OnixWebmail. Onix Internet http://www.onix.ro/ From owner-freebsd-sparc64@FreeBSD.ORG Wed May 21 16:06:21 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2E3C37B401 for ; Wed, 21 May 2003 16:06:20 -0700 (PDT) Received: from thea.blinkenlights.nl (thea.blinkenlights.nl [62.58.162.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10C2143F3F for ; Wed, 21 May 2003 16:06:20 -0700 (PDT) (envelope-from sten@blinkenlights.nl) Received: by thea.blinkenlights.nl (Postfix, from userid 101) id B129F22518; Thu, 22 May 2003 01:06:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by thea.blinkenlights.nl (Postfix) with ESMTP id A6C09F415; Thu, 22 May 2003 01:06:16 +0200 (CEST) Date: Thu, 22 May 2003 01:06:16 +0200 (CEST) From: Sten To: Marian Dobre In-Reply-To: <4190.80.96.131.3.1053542188.squirrel@webmail.onix.ro> Message-ID: References: <4190.80.96.131.3.1053542188.squirrel@webmail.onix.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: Qmail X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 23:06:21 -0000 On Wed, 21 May 2003, Marian Dobre wrote: > Hi, > > I'm having a hard time getting qmail to work with daemon tools on my E450 > running FreeBSD 5.0 current. > This is the output from uname -a > FreeBSD freebsd.onix.ro 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #12: Fri May > 2 20:15:11 EEST 2003 root@freebsd.onix.ro:/usr/obj/usr/src/sys/CUSTOM > sparc64 > > I've installed qmail and daemontools from ports and it wont start > qmail-smtpd. This is the error im getting in /var/log/qmail/smtpd/current > > @400000003ecbb3470d6c458c /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: > mmap of entire address space failed: Cannot allocate memory > @400000003ecbb34d1f8c1a6c /usr/libexec/ld-elf.so.1: /usr/lib/libc.so.5: > mmap of entire address space failed: Cannot allocate memory > > > If you have any ideas why its doing that please let me know. are you using softlimit ? 64bit binaries are larger than 32bit ones. please send the output of the run file which you are using. -- Sten Spans There is a crack in everything that's how the light gets in. From owner-freebsd-sparc64@FreeBSD.ORG Thu May 22 16:51:26 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65EB337B401 for ; Thu, 22 May 2003 16:51:26 -0700 (PDT) Received: from hotmail.com (f44.law10.hotmail.com [64.4.15.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A0243F85 for ; Thu, 22 May 2003 16:51:26 -0700 (PDT) (envelope-from chrishellriegel@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 22 May 2003 16:51:25 -0700 Received: from 68.211.207.72 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 22 May 2003 23:51:25 GMT X-Originating-IP: [68.211.207.72] X-Originating-Email: [chrishellriegel@hotmail.com] From: "chris hellriegel" To: freebsd-sparc@freebsd.org Date: Thu, 22 May 2003 19:51:25 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 May 2003 23:51:25.0904 (UTC) FILETIME=[0E66ED00:01C320BD] Subject: sparc 5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 23:51:26 -0000 Dear Sir or Madam, I have recently acquired some sun microsystems sparc hardware. Noticing that Solaris seems to have a good bit of overhead that makes the systems slow down i tried out FreeBSD. Currently I have an Ultra 5 (64bit) and a SparcStation 5. I noticed that you didn't have the SparcStation 5 on the hardware supported list for sparc hardware. I was wondering if it is supported and that if it isn't if there was any way i could help. Sincerely, Chris Hellriegel _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-freebsd-sparc64@FreeBSD.ORG Thu May 22 16:59:29 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9617937B449 for ; Thu, 22 May 2003 16:59:25 -0700 (PDT) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2405143F3F for ; Thu, 22 May 2003 16:59:25 -0700 (PDT) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id B242B9C8E; Thu, 22 May 2003 19:43:35 -0400 (EDT) Date: Thu, 22 May 2003 19:43:35 -0400 From: Mike Barcroft To: chris hellriegel Message-ID: <20030522194335.A79611@espresso.bsdmike.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from chrishellriegel@hotmail.com on Thu, May 22, 2003 at 07:51:25PM -0400 Organization: The FreeBSD Project cc: freebsd-sparc@freebsd.org Subject: Re: sparc 5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 23:59:30 -0000 chris hellriegel writes: > Dear Sir or Madam, > > I have recently acquired some sun microsystems sparc hardware. Noticing > that Solaris seems to have a good bit of overhead that makes the systems > slow down i tried out FreeBSD. Currently I have an Ultra 5 (64bit) and a > SparcStation 5. I noticed that you didn't have the SparcStation 5 on the > hardware supported list for sparc hardware. I was wondering if it is > supported and that if it isn't if there was any way i could help. This is a FAQ. There are no plans to support old sparc systems. Best regards, Mike Barcroft From owner-freebsd-sparc64@FreeBSD.ORG Thu May 22 17:38:06 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D17CD37B404 for ; Thu, 22 May 2003 17:38:06 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-67-115-75-172.dsl.lsan03.pacbell.net [67.115.75.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B84D43F3F for ; Thu, 22 May 2003 17:38:06 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id DB8C366BE5; Thu, 22 May 2003 17:38:05 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id C3DCB5C4; Thu, 22 May 2003 17:38:05 -0700 (PDT) Date: Thu, 22 May 2003 17:38:05 -0700 From: Kris Kennaway To: chris hellriegel Message-ID: <20030523003805.GA43597@rot13.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-sparc@freebsd.org Subject: Re: sparc 5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 00:38:07 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2003 at 07:51:25PM -0400, chris hellriegel wrote: > Dear Sir or Madam, >=20 > I have recently acquired some sun microsystems sparc hardware. Notici= ng=20 > that Solaris seems to have a good bit of overhead that makes the systems= =20 > slow down i tried out FreeBSD. Currently I have an Ultra 5 (64bit) and a= =20 > SparcStation 5. I noticed that you didn't have the SparcStation 5 on the= =20 > hardware supported list for sparc hardware. I was wondering if it is=20 > supported and that if it isn't if there was any way i could help. NetBSD supports sparc32. Kris --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+zW1tWry0BWjoQKURAiX1AJ43zlevMpqmMQJSz9qP5S5ROQgV4ACg1VjV OK2r7Tts2Q+wLN828XsGHZM= =gQRl -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--