From owner-freebsd-hackers Sun Nov 19 0:54: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from jason.argos.org (jason.argos.org [216.233.245.106]) by hub.freebsd.org (Postfix) with ESMTP id 8592A37B4C5 for ; Sun, 19 Nov 2000 00:54:02 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id eAJ8nop20327 for ; Sun, 19 Nov 2000 03:49:50 -0500 Date: Sun, 19 Nov 2000 03:49:49 -0500 (EST) From: Mike Nowlin To: freebsd-hackers@freebsd.org Subject: occasional serial line hangups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Running mgetty on a bunch of modems on various machines, I will occasionally run across one that looks like: rimmer:/usr4/mike$ ps alx|grep cuaR11 0 1371 1 0 4 0 916 8 ttywai IE ?? 0:00.02 /usr/local/sbin/mgetty cuaR11 ...with "ttywai" as the WCHAN and "E" in the STAT field. Sometimes this can be reset by power-cycling the modem & killing the mgetty process, but sometimes (ick) it requires a reboot to free up the line - "kill -9 pid" won't make the process go away. I'm using a fairly-stock mgetty config, and this happens on various brands of modems. (As a rule that I can't think of any exceptions to right now, they're connected via RocketPort and Cyclades cards.) This is happening on 3.5 and 4.1.1. These modems make a LOT of outgoing calls - usually about 800-1000 a day per modem - UUCP, PPP, and a custom "use 'chat' to dial the modem and log in, then kick off an XMODEM transfer" program. I'd love a "real" fix, but even some way that doesn't force me to reboot or cycle the modems would be great... Some of them are 100 miles away... mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 8: 0:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 8EED337B479 for ; Sun, 19 Nov 2000 08:00:44 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 0339C3E5B; Sun, 19 Nov 2000 17:00:42 +0100 (CET) Date: Sun, 19 Nov 2000 17:00:42 +0100 From: Jesper Skriver To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119170042.A18095@skriver.dk> References: <20001117211013.C9227@skriver.dk> <20001117142904.T18037@fw.wintelcom.net> <20001118155446.A81075@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001118155446.A81075@skriver.dk>; from jesper@skriver.dk on Sat, Nov 18, 2000 at 03:54:46PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 18, 2000 at 03:54:46PM +0100, Jesper Skriver wrote: > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote: > > * Jesper Skriver [001117 12:11] wrote: > > [snip] > > > > > > This timeout could be avoided if the sending mail server reacted to the > > > 'ICMP administratively prohibited' they got from our router. > > [snip] > > > > > > $ telnet nemo.dyndns.dk 25 > > > Trying 193.89.247.125... > > > telnet: Unable to connect to remote host: No route to host > > > $ uname -a > > > Linux xyz.dk 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown > > > > > > Wouldn't it be a idea to implement a similar behaviour in FreeBSD ? > > > > Probably not, what if one started a stream of spoofed ICMP lying > > about the state of the route between the two machines? I have > > the impression that the Linux box wouldn't be able to connect > > because of this behavior. > > Correct, a attacker could in theory make sure we couldn't connect to > a given remote box, but as I see it, it's mostly in teory. > > We could only react to this if we had a TCP session where we was > waiting for a SYN/ACK from this specific host, this only leaves a very > narrow window for a attacker to abuse, as he had to know both > destination and time. > > Do you agree ? A coworker of mine got into "rfc mode" and found the below, as we both read it, it says that we MUST treat a ICMP unreachable like a TCP RST. ########## ... A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. ########## A more complete quote. ########## RFC1122 (Requirements for Internet Hosts -- Communication Layers): [...] 3.2.2.1 Destination Unreachable: RFC-792 The following additional codes are hereby defined: 6 = destination network unknown 7 = destination host unknown 8 = source host isolated 9 = communication with destination network administratively prohibited 10 = communication with destination host administratively prohibited 11 = network unreachable for type of service 12 = host unreachable for type of service A host SHOULD generate Destination Unreachable messages with code: 2 (Protocol Unreachable), when the designated transport protocol is not supported; or 3 (Port Unreachable), when the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender. A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. Again in (experimental) RFC2498 (IPPM Metrics for Measuring Connectivity): [...] 6.6.5. Specific methodology for TCP: A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source port N1 and dest port N2 at address A2. Network traffic incoming to A1 is interpreted as follows: [...] + An ICMP port-unreachable from A2 to A1 indicates temporal connectivity between the addresses (and again a *lack* of service connectivity for TCP-port-N1-port-N2). {Comment: TCP implementations generally do not need to send ICMP port- unreachable messages because a separate mechanism is available (sending a RST). However, RFC 1122 states that a TCP receiving an ICMP port-unreachable MUST treat it the same as the equivalent transport-level mechanism (for TCP, a RST).} /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 12:54: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 71E6037B479 for ; Sun, 19 Nov 2000 12:54:02 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 4852A3E4F; Sun, 19 Nov 2000 21:53:57 +0100 (CET) Date: Sun, 19 Nov 2000 21:53:57 +0100 From: Jesper Skriver To: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119215357.A41281@skriver.dk> References: <20001118155446.A81075@skriver.dk> <20001118183632.A99512@skriver.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001118183632.A99512@skriver.dk>; from jesper@skriver.dk on Sat, Nov 18, 2000 at 06:36:32PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Nov 18, 2000 at 06:36:32PM +0100, Jesper Skriver wrote: > I'll see if I can get code together which will do this. I've now got this working (diff attached), it was actually quite simple when I got a grip on what was going on in sys/netinet/, I'm gratefull for comments. Now I need to get this under the control of a sysctl, 'man 3 sysctl' gives some information on how to read the setting of a sysctl, in sys/netinet/ip_icmp.c I see how some of the others was implemented, but should I put this here ? static int drop_unreachable = 1; SYSCTL_INT(_net_inet_icmp, OID_AUTO, drop_unreachable, CTLFLAG_RW, &drop_unreachable, 0, ""); /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="drop_unreachable.diff" diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c --- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000 +++ sys/netinet/ip_icmp.c Sun Nov 19 21:49:27 2000 @@ -328,6 +328,9 @@ case ICMP_UNREACH_NET_UNKNOWN: case ICMP_UNREACH_NET_PROHIB: + code = PRC_UNREACH_PORT; + break; + case ICMP_UNREACH_TOSNET: code = PRC_UNREACH_NET; break; @@ -335,11 +338,17 @@ case ICMP_UNREACH_HOST_UNKNOWN: case ICMP_UNREACH_ISOLATED: case ICMP_UNREACH_HOST_PROHIB: + code = PRC_UNREACH_PORT; + break; + case ICMP_UNREACH_TOSHOST: code = PRC_UNREACH_HOST; break; case ICMP_UNREACH_FILTER_PROHIB: + code = PRC_UNREACH_PORT; + break; + case ICMP_UNREACH_HOST_PRECEDENCE: case ICMP_UNREACH_PRECEDENCE_CUTOFF: code = PRC_UNREACH_PORT; diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c --- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000 +++ sys/netinet/tcp_subr.c Sun Nov 19 21:17:40 2000 @@ -961,6 +961,8 @@ if (cmd == PRC_QUENCH) notify = tcp_quench; + else if ((cmd == PRC_UNREACH_PORT) && (ip)) + notify = tcp_drop_syn_sent; else if (cmd == PRC_MSGSIZE) notify = tcp_mtudisc; else if (!PRC_IS_REDIRECT(cmd) && @@ -1071,6 +1073,20 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; +} + +/* + * When a ICMP unreachable is recieved, drop the + * TCP connection, but only if in SYN SENT + */ +void +tcp_drop_syn_sent(inp, errno) + struct inpcb *inp; + int errno; +{ + struct tcpcb *tp = intotcpcb(inp); + if((tp) && (tp->t_state == TCPS_SYN_SENT)) + tcp_drop(tp, errno); } /* diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h --- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000 +++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000 @@ -387,6 +387,7 @@ void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); +void tcp_drop_syn_sent __P((struct inpcb *, int)); void tcp_mtudisc __P((struct inpcb *, int)); struct tcpcb * tcp_newtcpcb __P((struct inpcb *)); --ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 13: 3:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 69C0837B4CF for ; Sun, 19 Nov 2000 13:03:13 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id eAJL34713541; Sun, 19 Nov 2000 16:03:04 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011192103.eAJL34713541@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jesper Skriver Cc: hackers@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: React to ICMP administratively prohibited ? References: <20001118155446.A81075@skriver.dk> <20001118183632.A99512@skriver.dk> <20001119215357.A41281@skriver.dk> In-reply-to: Your message of "Sun, 19 Nov 2000 21:53:57 +0100." <20001119215357.A41281@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Nov 2000 16:03:04 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This patch seems like it will do the wrong thing for ICMP messages that are associated with non-TCP packets. It looks like ICMP unreachable messages for UDP packets will never get delivered to UDP sockets. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 13: 4:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id A3EA637B479 for ; Sun, 19 Nov 2000 13:04:52 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 872543E4F; Sun, 19 Nov 2000 22:04:51 +0100 (CET) Date: Sun, 19 Nov 2000 22:04:51 +0100 From: Jesper Skriver To: "Louis A. Mamakos" Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119220451.B41281@skriver.dk> References: <20001118155446.A81075@skriver.dk> <20001118183632.A99512@skriver.dk> <20001119215357.A41281@skriver.dk> <200011192103.eAJL34713541@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011192103.eAJL34713541@whizzo.transsys.com>; from louie@TransSys.COM on Sun, Nov 19, 2000 at 04:03:04PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote: > > This patch seems like it will do the wrong thing for ICMP messages that > are associated with non-TCP packets. It looks like ICMP unreachable > messages for UDP packets will never get delivered to UDP sockets. Yep - I've come to think of this too, I think I'll make it behave like before for non-TCP packets, or do you have a better idea ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 13:38:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 9703037B479 for ; Sun, 19 Nov 2000 13:38:19 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 2E48F3E5B; Sun, 19 Nov 2000 22:38:18 +0100 (CET) Date: Sun, 19 Nov 2000 22:38:18 +0100 From: Jesper Skriver To: "Louis A. Mamakos" Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119223818.A79237@skriver.dk> References: <20001118155446.A81075@skriver.dk> <20001118183632.A99512@skriver.dk> <20001119215357.A41281@skriver.dk> <200011192103.eAJL34713541@whizzo.transsys.com> <20001119220451.B41281@skriver.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001119220451.B41281@skriver.dk>; from jesper@skriver.dk on Sun, Nov 19, 2000 at 10:04:51PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 19, 2000 at 10:04:51PM +0100, Jesper Skriver wrote: > On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote: > > > > This patch seems like it will do the wrong thing for ICMP messages that > > are associated with non-TCP packets. It looks like ICMP unreachable > > messages for UDP packets will never get delivered to UDP sockets. > > Yep - I've come to think of this too, I think I'll make it behave like > before for non-TCP packets, or do you have a better idea ? New version attached, this time I check that it's a ICMP unreachable for a TCP packet, if not this code behaves like the current code. I still need some hints on the sysctl stuff. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="drop_unreachable2.diff" diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c --- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000 +++ sys/netinet/ip_icmp.c Sun Nov 19 22:08:52 2000 @@ -328,6 +328,11 @@ case ICMP_UNREACH_NET_UNKNOWN: case ICMP_UNREACH_NET_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSNET: code = PRC_UNREACH_NET; break; @@ -335,11 +340,21 @@ case ICMP_UNREACH_HOST_UNKNOWN: case ICMP_UNREACH_ISOLATED: case ICMP_UNREACH_HOST_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSHOST: code = PRC_UNREACH_HOST; break; case ICMP_UNREACH_FILTER_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_HOST_PRECEDENCE: case ICMP_UNREACH_PRECEDENCE_CUTOFF: code = PRC_UNREACH_PORT; diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c --- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000 +++ sys/netinet/tcp_subr.c Sun Nov 19 21:17:40 2000 @@ -961,6 +961,8 @@ if (cmd == PRC_QUENCH) notify = tcp_quench; + else if ((cmd == PRC_UNREACH_PORT) && (ip)) + notify = tcp_drop_syn_sent; else if (cmd == PRC_MSGSIZE) notify = tcp_mtudisc; else if (!PRC_IS_REDIRECT(cmd) && @@ -1071,6 +1073,20 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; +} + +/* + * When a ICMP unreachable is recieved, drop the + * TCP connection, but only if in SYN SENT + */ +void +tcp_drop_syn_sent(inp, errno) + struct inpcb *inp; + int errno; +{ + struct tcpcb *tp = intotcpcb(inp); + if((tp) && (tp->t_state == TCPS_SYN_SENT)) + tcp_drop(tp, errno); } /* diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h --- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000 +++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000 @@ -387,6 +387,7 @@ void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); +void tcp_drop_syn_sent __P((struct inpcb *, int)); void tcp_mtudisc __P((struct inpcb *, int)); struct tcpcb * tcp_newtcpcb __P((struct inpcb *)); --pWyiEgJYm5f9v55/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 13:43:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3]) by hub.freebsd.org (Postfix) with ESMTP id 72EDE37B4D7 for ; Sun, 19 Nov 2000 13:43:19 -0800 (PST) Received: from hades.hell.gr (ppp2.patr.hellasnet.gr [212.54.197.17]) by mail.hellasnet.gr (8.9.1/8.9.1) with ESMTP id TAA14056; Sun, 19 Nov 2000 19:43:16 -0200 (GMT) Received: (from charon@localhost) by hades.hell.gr (8.11.1/8.11.1) id eAJGDVT08288; Sun, 19 Nov 2000 18:13:31 +0200 (EET) Date: Sun, 19 Nov 2000 18:13:30 +0200 From: Giorgos Keramidas To: Peter Pentchev Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: changing a running process's credentials Message-ID: <20001119181330.A8174@hades.hell.gr> References: <20001115161316.C309@ringworld.oblivion.bg> <20001115084722.I29448@fw.wintelcom.net> <20001115190135.E309@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001115190135.E309@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Nov 15, 2000 at 07:01:35PM +0200 X-PGP-Fingerprint: 3A 75 52 EB F1 58 56 0D - C5 B8 21 B6 1B 5E 4A C2 X-URL: http://students.ceid.upatras.gr/~keramida/index.html Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 07:01:35PM +0200, Peter Pentchev wrote: > On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote: > > * Peter Pentchev [001115 06:19] wrote: > > > All right, feel free to flame me a LOT for what follows :) > > > > No need for that. (yet) :-) > > ..possibly because I did not make my intentions clear enough :) > > > > There are situations (at least I could think of some :) where it is necessary > > > to change a running process's credentials. I'm thinking specifically of the > > > effective UID and GID, but I might have to tinker with the real and saved > > > UID's, too. > > > > Well there's setuid for you. > > Hmm.. I've also received two private mails so far, pointing me to setuid(). > The problem is, I want to force a new UID on *another* process without > its knowledge. setuid() only works on the process invoking it, so > both the 'force' and the 'without its knowledge' part fall by the wayside :( Yes, but what about the case where the process itself checks to see the uid under which it runs, and modifies it's behavior accordingly? Think of a case like below: if (geteuid() != 0) { ... ptr->field = (struct something *) malloc(BUF); ptr->field->data = FOO; .. } and later in the code: if (geteuid() != 0) { ... free(ptr->field->data); ... } and the process starts with a uid != 0, but you change it's uid while it runs [but before it reaches the second piece of code] to 0. It will incorrectly be forced to derefence a NULL pointer [ptr->field] and gracefully core dump. I think that you are indeed playing with fire here :) - giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 14:56:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 752BE37B479; Sun, 19 Nov 2000 14:56:53 -0800 (PST) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id OAA53236; Sun, 19 Nov 2000 14:56:47 -0800 (PST) (envelope-from rh@matriplex.com) Date: Sun, 19 Nov 2000 14:56:47 -0800 (PST) From: Richard Hodges To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: page fault question In-Reply-To: <200011151129.eAFBToF02993@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 15 Nov 2000, Mike Smith wrote: > > I have been having a great time :-) debugging a device driver, > > and have run into a really fun way to panic. With one type > > of traffic, [something] happens and the kernel drops into > > DDB, just the way I want. [snip panic info] > This is pretty normal; ddb is a little fragile sometimes. You want to go > back and look at the very first trap; it will probably be different and > will be the *real* trap. All the rest are just ddb exploding. Yep. Unfortunately, the original trap led me on a wild goose chase, trying to figure out why system memory was being overwritten by received device data. I really suspected something funny in the DMA... It turns out that the network stack gets really unhappy when you trim an mbuf chain and leave the last mbuf with a negative length :-( > > Now looking back at the panic message, it looks like the stack has > > pushed into the "frame pointer". Is this an actual problem, or > > just some side effect of the page fault? > The frame pointer is a pointer into the stack, so no, it's not a problem. Of course (doh!) I realized that shortly after posting. > Typically stack overruns lead to double faults (because there's no stack > on which to handle the fault) and a spontaneous reboot. This just sounds > like there's something about your first trap that kills DDB (eg. an > invalid instruction pointer, etc.) I did check the SP, and it looks like the kernel stack stays in the "temporary" 8k stack set up in i386/i386/locore.s Does that sound right? > Hope this helps; let us know if the first trap isn't any more > illuminating. You might also try using remote gdb instead of ddb. Thanks. I also had to dig out a couple bugs involving word alignment when doing DMA transfers, and learned NOT to mess with the data inside mbufs with external data ;-) I guess I've left enough offerings at the altar of stupidity, so maybe Loki will leave me alone now. All the best, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 15: 1: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 7649537B479 for <hackers@FreeBSD.ORG>; Sun, 19 Nov 2000 15:01:07 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id eAJN15714300; Sun, 19 Nov 2000 18:01:05 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011192301.eAJN15714300@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jesper Skriver <jesper@skriver.dk> Cc: hackers@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" <louie@TransSys.COM> Subject: Re: React to ICMP administratively prohibited ? References: <20001118155446.A81075@skriver.dk> <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com> <20001118183632.A99512@skriver.dk> <20001119215357.A41281@skriver.dk> <200011192103.eAJL34713541@whizzo.transsys.com> <20001119220451.B41281@skriver.dk> <20001119223818.A79237@skriver.dk> In-reply-to: Your message of "Sun, 19 Nov 2000 22:38:18 +0100." <20001119223818.A79237@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Nov 2000 18:01:05 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It would seem more appropriate, somehow, to push the response to the ICMP message up into the protocols where they can take the appropriate action. Of course, the problem is that the PRC_* abstracted codes may not be rich enough to express all the semantics you'd wish to convey. So one goal might be to see if this sort of process could get pushed into netinet/tcp_sub.c:tcp_ctlinput(). Personally, I don't really like the idea of the icmp_input() function reaching into TCP's private state and doing stuff. There's too many potential interactions (e.g., what about IPSEC security associations?) I dunno, some of this is probably a matter of taste. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 16:30:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 85E9537B4CF for <hackers@FreeBSD.ORG>; Sun, 19 Nov 2000 16:30:05 -0800 (PST) Received: (qmail 54956 invoked by uid 1000); 20 Nov 2000 00:30:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Nov 2000 00:30:04 -0000 Date: Sun, 19 Nov 2000 18:30:04 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Jesper Skriver <jesper@skriver.dk> Cc: Alfred Perlstein <bright@wintelcom.net>, hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? In-Reply-To: <20001119170042.A18095@skriver.dk> Message-ID: <Pine.BSF.4.21.0011191822410.54936-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 19 Nov 2000, Jesper Skriver wrote: > A coworker of mine got into "rfc mode" and found the below, as we both > read it, it says that we MUST treat a ICMP unreachable like a TCP RST. > > ########## > ... A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose. > ########## > > 9 = communication with destination network > administratively prohibited > > 10 = communication with destination host > administratively prohibited Ok, you've got me convinced, it should be implemented. <grumble> There's a problem, though. Later RFCs say to use 13 instead of 10, as 10 was supposed to be for darpa use only. Perhaps you should retest the other OSes and see if they're only responding to one of the two messages. Ok, back to MXes. I've thought about it, and I can't think of any good ways to do your configuration automatically. Perhaps you could have some cgi that would allow you to remove yourself from the firewall ruleset, assuming you were coming from the IP in question. Or, coming from the other direction, the cgi could let you add yourself to the static mail routing table if you were coming from the IP in question. I assume you're using sendmail's "relay if I'm listed as a MX" feature right now? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 17:28: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 4236837B479 for <hackers@FreeBSD.org>; Sun, 19 Nov 2000 17:27:59 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA409210 for <hackers@FreeBSD.org>; Sun, 19 Nov 2000 20:27:58 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p04330101b63e2c0b9192@[128.113.24.47]> Date: Sun, 19 Nov 2000 20:27:56 -0500 To: hackers@FreeBSD.org From: Garance A Drosihn <drosih@rpi.edu> Subject: fclose vs ferror (from libc/getcap) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As mentioned in pr bin/22965, I stumbled across a bug in libc/gen/getcap.c when compiling it under other platforms. The basic problem is some code which does: (void)fclose(pfp); if (ferror(pfp)) { ...do stuff... } I find it surprising that the above works under FreeBSD. (not only that, it seems to work OK under several other OS's too). The fclose is supposed to throw away the stream, but the ferror (apparently) still works with that pointer. The PR includes a patch for getcap.c (which is just to use the result from fclose to determine if an error occurred), but I also wonder if we should do something so that this combination would ALWAYS fail. It seems to me that fclose should clear out whatever fields that ferror is using for sanity-checking, and ferror should always return an errno of 'bad parameter', or something like that. Or is there some reason that we DO want ferror to work on streams which have already been closed? -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 18:31:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 1F98D37B479 for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Nov 2000 18:31:42 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id eAK2VdR93656; Sun, 19 Nov 2000 18:31:39 -0800 (PST) Date: Sun, 19 Nov 2000 18:31:38 -0800 (PST) From: Doug White <dwhite@resnet.uoregon.edu> To: Maxime Henrion <mux@qualys.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kqueue()/kevent(), select() and poll() In-Reply-To: <20001118150445.A260@nebula.cybercable.fr> Message-ID: <Pine.BSF.4.21.0011191830590.81696-100000@resnet.uoregon.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Nov 2000, Maxime Henrion wrote: > Hi, > > I was wondering if it was reasonnable to implement the select() and poll() > system calls as kqueue()/kevent() wrappers. This would make any application > using these system calls benefit from the performance improvements of the new > kernel thread. > > Do you think it's possible and that it won't cause some portability problems ? Also, select() works on more descriptors than kqueue/kevent() does currently (i.e. NFS). Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 20:30:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 7F99A37B4E5 for <freebsd-hackers@freebsd.org>; Sun, 19 Nov 2000 20:30:14 -0800 (PST) Received: by search.sparks.net (Postfix, from userid 100) id 2335FDC74; Sun, 19 Nov 2000 23:22:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id 0D531DC73 for <freebsd-hackers@freebsd.org>; Sun, 19 Nov 2000 23:22:30 -0500 (EST) Date: Sun, 19 Nov 2000 23:22:29 -0500 (EST) From: David Miller <dmiller@search.sparks.net> To: freebsd-hackers@freebsd.org Subject: UDP limits in dns server? Message-ID: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All:) I'm testing a honking reverse resolver system for use in resolving web logs. It's an Abit KT7 system with 1.1 GHz processor and 768 MB of ECC ram running 4.1-stable as of about a month ago. I'm looking up the IP addresses with up to 1500 or so processes each taking a list of addresses and running gethostbyaddr() on them. I've increased net.inet.udp.recvspace to 192k. Is there anything else I can do to tune the system? I'm particularly perplexed that a K6-200 system I had was cpu bound running named and achieved ~200 resolves/sec; my spiffy new 1100 MHz K7 is struggling to double it. Any suggestions welcome! --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 20:33:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B5CB637B4CF for <freebsd-hackers@FreeBSD.ORG>; Sun, 19 Nov 2000 20:33:28 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAK4XRn10965; Sun, 19 Nov 2000 20:33:27 -0800 (PST) Date: Sun, 19 Nov 2000 20:33:27 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: David Miller <dmiller@search.sparks.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UDP limits in dns server? Message-ID: <20001119203327.S18037@fw.wintelcom.net> References: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net>; from dmiller@search.sparks.net on Sun, Nov 19, 2000 at 11:22:29PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * David Miller <dmiller@search.sparks.net> [001119 20:30] wrote: > Hi All:) > > I'm testing a honking reverse resolver system for use in resolving web > logs. It's an Abit KT7 system with 1.1 GHz processor and 768 MB of ECC > ram running 4.1-stable as of about a month ago. > > I'm looking up the IP addresses with up to 1500 or so processes each > taking a list of addresses and running gethostbyaddr() on them. > > I've increased net.inet.udp.recvspace to 192k. Is there anything else I > can do to tune the system? I'm particularly perplexed that a K6-200 > system I had was cpu bound running named and achieved ~200 > resolves/sec; my spiffy new 1100 MHz K7 is struggling to double it. > > Any suggestions welcome! Increasing maxusers to something like 512 should help with the network buffer space and sockets required to achieve your goals. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 20:55: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 254D737B479 for <freebsd-hackers@freebsd.org>; Sun, 19 Nov 2000 20:55:03 -0800 (PST) Received: by search.sparks.net (Postfix, from userid 100) id 5584CDC74; Sun, 19 Nov 2000 23:47:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id 48A86DC73 for <freebsd-hackers@freebsd.org>; Sun, 19 Nov 2000 23:47:24 -0500 (EST) Date: Sun, 19 Nov 2000 23:45:50 -0500 (EST) From: David Miller <dmiller@search.sparks.net> To: Mike Silbersack <silby@silby.com> Subject: Re: UDP limits in dns server? In-Reply-To: <Pine.BSF.4.21.0011192234220.59748-100000@achilles.silby.com> Message-ID: <Pine.BSF.4.21.0011192332420.25661-100000@search.sparks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 19 Nov 2000, Mike Silbersack wrote: > On Sun, 19 Nov 2000, David Miller wrote: > > I've increased net.inet.udp.recvspace to 192k. Is there anything else I > > can do to tune the system? I'm particularly perplexed that a K6-200 > > system I had was cpu bound running named and achieved ~200 > > resolves/sec; my spiffy new 1100 MHz K7 is struggling to double it. > > > > Any suggestions welcome! > > > > --- David > > You may wish to try dan bernstein's dnscache resolver, it's part of the > djbdns port. (Actually, the port may still be named dnscache, I'm not > certain.) > > No clue if it's actually better. Dan says it is of course, and it's not > at all based on the bind resolver, so it'll certainly perform > different. I'm sure people would be interested to hear the results either > way. As a matter of fact, I am using it right now. I tried bind8.x and it worked OK, but seemed to slow down as the cache grew. I was surprised that the CPU could be a limit here, but it certainly seemed to be. I think the best run I had (256K addresses) was just shy of 400/sec. I got half that on 1/5 the mchine, so I went looking elsewhere. I'm trying the dnscache component of the djbdns package and it does have some nice features. You can set limits on the number of requests outstanding, how much memory for it to take, etc, and it works nicely. I haven't tried any other components of the system yet so I can't speak for those. The same run on dnscache seemed to go a bit over half the speed at 227 lookups/second. I've had the suggestion to up maxusers to 512. I'm a little leery of this, having heard of problems > 128 on this list for seemingly years. Is there a better way to size the network buffers and anything else which needs to be adjusted? Thanks Mike, Alfred, and all. --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 21:33:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ME0WVAX.INT.TELE.DK (fw1.inet.tele.dk [193.163.158.4]) by hub.freebsd.org (Postfix) with ESMTP id 60F7A37B4C5 for <hackers@freebsd.org>; Sun, 19 Nov 2000 21:33:43 -0800 (PST) Received: from localhost (FLUFFIE@localhost) by ME0WVAX.INT.TELE.DK (8.9.3/8.9.3) with SMTP id GAA17782 for <hackers@freebsd.org>; Mon, 20 Nov 2000 06:32:06 +0100 (CET) (envelope-from FLUFFIE@FREE-PR0N.NETSCUM.DK) X-Authentication-Warning: ME0WVAX.INT.TELE.DK: FLUFFIE owned process doing -bs Date: Mon, 20 Nov 2000 06:31:06 +0100 (CET) From: "Scumley O'Fluffigan" <FLUFFIE@FREE-PR0N.NETSCUM.DK> X-Sender: FLUFFIE@ME0WVAX.INT.TELE.DK Reply-To: hax0r@netscum.dk To: hackers@freebsd.org Subject: Re: React to ICMP administratively prohibited ? In-Reply-To: <fa.ij2s57v.i7oi1p@ifi.uio.no> Message-ID: <Pine.BSF.3.96.1001120061924.16503D-100000@ME0WVAX.INT.TELE.DK> X-Meow: we meow for fish and chips MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 17 Nov 2000, Alfred Perlstein wrote: > > This timeout could be avoided if the sending mail server reacted to the > > 'ICMP administratively prohibited' they got from our router. > > > > $ telnet nemo.dyndns.dk 25 > > Trying 193.89.247.125... > > telnet: Unable to connect to remote host: No route to host > > $ uname -a > > Linux xyz.dk 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown > > > > Wouldn't it be a idea to implement a similar behaviour in FreeBSD ? > > Probably not, what if one started a stream of spoofed ICMP lying > about the state of the route between the two machines? I have > the impression that the Linux box wouldn't be able to connect > because of this behavior. I wouldn't be surprised if this was introduced to linux because of the ridiculously long timeouts they have for connections to ports other than 23, or at least, used to have back when I experienced them. Eliminating this wait for a timeout would shave maybe a minute off delivery time for most OSen, except for b0rken mailers that will always try to deliver to the firewalled MX machine instead of the lower-priority backups. Not that those will concern me at all. It's more of a relatively minor inconvenience that the primary MX machine isn't reachable for the world any more... I did work some ten years ago through terminal access um, devices that did react to ICMP messages received in the middle of an already established connection. Very annoying. You don't want to do this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 21:58:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 1940637B4C5 for <hackers@FreeBSD.org>; Sun, 19 Nov 2000 21:58:45 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 4CCB219CF; Mon, 20 Nov 2000 00:58:44 -0500 (EST) Date: Mon, 20 Nov 2000 00:58:44 -0500 From: Will Andrews <will@physics.purdue.edu> To: David Miller <dmiller@search.sparks.net> Cc: hackers@FreeBSD.org Subject: Re: UDP limits in dns server? Message-ID: <20001120005844.H23043@puck.firepipe.net> Reply-To: Will Andrews <will@physics.purdue.edu> References: <Pine.BSF.4.21.0011192234220.59748-100000@achilles.silby.com> <Pine.BSF.4.21.0011192332420.25661-100000@search.sparks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011192332420.25661-100000@search.sparks.net>; from dmiller@search.sparks.net on Sun, Nov 19, 2000 at 11:45:50PM -0500 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 19, 2000 at 11:45:50PM -0500, David Miller wrote: > I've had the suggestion to up maxusers to 512. I'm a little leery of > this, having heard of problems > 128 on this list for seemingly years. Is > there a better way to size the network buffers and anything else which > needs to be adjusted? I've run a -stable box on 512 maxusers for close to 2 years now. It has survived 120 days straight uptime under considerable load, so... -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Nov 19 22:57:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6BE0537B479 for <hackers@freebsd.org>; Sun, 19 Nov 2000 22:57:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAK6vDv14479 for hackers@freebsd.org; Sun, 19 Nov 2000 22:57:13 -0800 (PST) Date: Sun, 19 Nov 2000 22:57:13 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: hackers@freebsd.org Subject: res_ functions thread safe? Message-ID: <20001119225712.W18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I need to do MX lookups in a threaded program, does anyone know if the res_ functions are thread safe, or if there's an alternative I can use that is? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 2:18:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from siri.nordier.com (c3-dbn-96.dial-up.net [196.33.200.96]) by hub.freebsd.org (Postfix) with ESMTP id 9364337B479 for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 02:18:43 -0800 (PST) Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id MAA23349; Mon, 20 Nov 2000 12:20:05 +0200 (SAST) From: Robert Nordier <rnordier@nordier.com> Message-Id: <200011201020.MAA23349@siri.nordier.com> Subject: Re: fclose vs ferror (from libc/getcap) To: drosih@rpi.edu (Garance A Drosihn) Date: Mon, 20 Nov 2000 12:19:59 +0200 (SAST) Cc: hackers@FreeBSD.ORG In-Reply-To: <p04330101b63e2c0b9192@[128.113.24.47]> from "Garance A Drosihn" at Nov 19, 2000 08:27:56 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > As mentioned in pr bin/22965, I stumbled across a bug > in libc/gen/getcap.c when compiling it under other > platforms. The basic problem is some code which does: > > (void)fclose(pfp); > if (ferror(pfp)) { > ...do stuff... > } > > I find it surprising that the above works under FreeBSD. > (not only that, it seems to work OK under several other > OS's too). The fclose is supposed to throw away the > stream, but the ferror (apparently) still works with > that pointer. > > The PR includes a patch for getcap.c (which is just to > use the result from fclose to determine if an error > occurred), but I also wonder if we should do something > so that this combination would ALWAYS fail. It seems > to me that fclose should clear out whatever fields that > ferror is using for sanity-checking, and ferror should > always return an errno of 'bad parameter', or something > like that. > > Or is there some reason that we DO want ferror to work > on streams which have already been closed? Bear in mind that ferror is one of a number of stdio functions that are often implemented as macros. For instance: ferror and (say) getc might look like this: #define ferror(f) ((f)->fl & _FERR) #define getc(f) ((f)->p < (f)->xr ? *(f)->p++ : fgetc(f)) Given the intentionally minimalist way those functions are written, to do any consistent and obligatory sanity-checking on (FILE *) would cause a big change in the actual code generated, and the amount of code generated. I think the best way to do what you want is to create a separate debugging library. The point about (void)fclose(pfp); if (ferror(pfp)) { ...do stuff... } is that it's a silly thing to do deliberately, but if I was porting some hairy old C code I'd tend to expect it to work. C is not a language in which you go out of your way to prevent people making mistakes. -- Robert Nordier rnordier@nordier.com rnordier@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 3: 4:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-138.dsl.snfc21.pacbell.net [63.202.178.138]) by hub.freebsd.org (Postfix) with ESMTP id 1961037B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 03:04:39 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAKBAtF12436; Mon, 20 Nov 2000 03:11:03 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011201111.eAKBAtF12436@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Richard Hodges <rh@matriplex.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: page fault question In-reply-to: Your message of "Sun, 19 Nov 2000 14:56:47 PST." <Pine.BSF.4.10.10011191443280.52841-100000@mail.matriplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Nov 2000 03:10:55 -0800 From: Mike Smith <msmith@freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It turns out that the network stack gets really unhappy when you > trim an mbuf chain and leave the last mbuf with a negative length :-( Ouch. 8) > > Typically stack overruns lead to double faults (because there's no stack > > on which to handle the fault) and a spontaneous reboot. This just sounds > > like there's something about your first trap that kills DDB (eg. an > > invalid instruction pointer, etc.) > > I did check the SP, and it looks like the kernel stack stays in the > "temporary" 8k stack set up in i386/i386/locore.s Does that sound right? In some cases. AFAIK it'll also appear in the UPAGES area in userspace if you're calling into the kernel that way. > > Hope this helps; let us know if the first trap isn't any more > > illuminating. You might also try using remote gdb instead of ddb. > > Thanks. I also had to dig out a couple bugs involving word alignment > when doing DMA transfers, and learned NOT to mess with the data inside > mbufs with external data ;-) I guess I've left enough offerings at > the altar of stupidity, so maybe Loki will leave me alone now. *grin* Good luck! -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 4:27:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.ntu-kpi.kiev.ua (www.ntu-kpi.kiev.ua [212.111.192.161]) by hub.freebsd.org (Postfix) with ESMTP id 1C3FE37B479 for <freebsd-hackers@FreeBSD.org>; Mon, 20 Nov 2000 04:27:09 -0800 (PST) Received: from comsys.ntu-kpi.kiev.ua (eth0.comsys.ntu-kpi.kiev.ua [10.0.1.184]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id 1A73A2FB96 for <freebsd-hackers@FreeBSD.org>; Mon, 20 Nov 2000 14:26:46 +0200 (EET) Received: from pm5149 (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) by comsys.ntu-kpi.kiev.ua (8.9.3/8.8.7) with SMTP id OAA67338 for <freebsd-hackers@FreeBSD.org>; Mon, 20 Nov 2000 14:40:18 +0200 (EET) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Message-ID: <004a01c052e4$58cb1820$6d36120a@comsys.ntukpi.kiev.ua> From: "Andrey Simonenko" <simon@comsys.ntu-kpi.kiev.ua> To: <freebsd-hackers@FreeBSD.org> Subject: IP Accounting Daemon Date: Mon, 20 Nov 2000 14:23:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm pleased to announce first public release of IP Accounting Daemon (ipa). Complete documentation and description of IP Accounting Daemon features is availble on its manual pages. I can't describe all features in this mesage. You can download IP Accounting Daemon from the following URL: http://www.simon.org.ua/ IP Accounting Daemon is a highly configurable IP accounting software. It allows to make IP accounting based on IP Firewall and/or IP Filter accounting rules. In most cases IP Accounting Daemon is run on public servers, software routers, etc. It uses powerful IP Firewall and/or IP Filter accounting rules and bases on its configuration allows to escape from writing scripts to manage network accounting. It is not required to be run from the cron daemon. ipa is a daemon. It has flexible configuration file with many section and options. It is possible to make accounting during specified period of week, accounting per some time interval, etc. Limits or quotas are supported and there can be many limits for one accounting rule. It can operate with such time interval as "end of day", "end of week", "end of month", etc. Each accounting rule can be protected by access control list and there is special viewer ipastat. Its configuration file looks like simple program with subroutines, variables and condition statements. Many other features. ipa is developed for FreeBSD. Main features: - support IP Firewall and IP Filter - it is not required to be run from the cron daemon - IP accounting per specified period of week [not implemented] - IP accounting per specified period of time - support byte limits or bytes quotas - support limit's events: reach limit, restart (zero) limit, expire reached limit - support time intervals like "end of week", "end of day", etc. - there is special viewer ipastat - support access control lists for ipastat - flexible configuration for accounting rules and limits - counters overflow control - low processor time and disk space utilization To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 7:18:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pro.lookanswer.com (unknown [195.66.202.99]) by hub.freebsd.org (Postfix) with SMTP id D534337B4CF for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 07:18:00 -0800 (PST) Received: (qmail 47742 invoked by uid 1001); 20 Nov 2000 15:17:52 -0000 From: Alex Koshterek <havoc@lookanswer.com> Reply-To: havoc@lookanswer.com To: freebsd-hackers@freebsd.org Subject: Byte order? Date: Mon, 20 Nov 2000 17:17:00 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00112017175200.47740@pro.lookanswer.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I know, that x86 is big endian architecture but simple programm like this: #include <stdio.h> #include <sys/param.h> main () { /* Are we little or big endian? From Harbison&Steele. */ union { long l; char c[sizeof (long)]; } u; u.l = 1; printf ("Little endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" : "no"); #if BYTE_ORDER == BIG_ENDIAN printf("Big endian\n"); #elif BYTE_ORDER == LITTLE_ENDIAN printf("Little endian\n"); #else printf("Unknown\n"); #endif } Give me a strange result: Little endian? no Little endian On my FreeBSD 4.2-BETA BYTE_ORDER = LITTLE_ENDIAN! I`m very confused and some programms detect my machine as Little Endian, by example freetds. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 7:37:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from air.linkclub.or.jp (air.linkclub.or.jp [210.155.117.20]) by hub.freebsd.org (Postfix) with ESMTP id D8BE337B4C5; Mon, 20 Nov 2000 07:37:27 -0800 (PST) Received: from localhost.jp.FreeBSD.org (kumagaya3-83.ppp-1.dion.ne.jp [210.198.152.83]) by air.linkclub.or.jp (8.9.3/3.7W) with ESMTP id AAA29731; Tue, 21 Nov 2000 00:37:24 +0900 (JST) Date: Tue, 21 Nov 2000 00:36:56 +0900 (JST) Message-Id: <200011201536.AAA34840.toshi@jp.FreeBSD.org> From: Toshihiko ARAI <toshi@jp.FreeBSD.org> To: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: 4.2R CDROM from Walnut Creek CDROM? X-Mailer: VM 5.96 (beta) / Mule 2.3 (SUETSUMUHANA) based on 19.34.1 Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, In src/release/texts/*/RELNOTES.TXT for 4.2R, HEAD and 4-stable branches: |FreeBSD 4.x-RELEASE and 3.x-RELEASE CDs may be ordered on CDROM from: | | Walnut Creek CDROM | 4041 Pike Lane, Suite D | Concord CA 94520 | 1-800-786-9907, +1-925-674-0783, +1-925-674-0821 (FAX) | |Or via the Internet from orders@cdrom.com or http://www.cdrom.com. |Their current catalog can be obtained via ftp from: | | ftp://ftp.cdrom.com/cdrom/catalog Correct needless? -- Toshihiko ARAI / toshi@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 7:40:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id D34BA37B479 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 07:40:47 -0800 (PST) Received: (qmail 3660 invoked by uid 0); 20 Nov 2000 15:40:45 -0000 Received: from p3ee21477.dip.t-dialin.net (HELO forge.local) (62.226.20.119) by mail.gmx.net (mail05) with SMTP; 20 Nov 2000 15:40:45 -0000 Received: from thomas by forge.local with local (Exim 3.12 #1 (Debian)) id 13xt38-0000QR-00 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 16:40:06 +0100 Date: Mon, 20 Nov 2000 16:40:06 +0100 To: freebsd-hackers@freebsd.org Subject: Re: Byte order? Message-ID: <20001120164006.A1624@crow.dom2ip.de> Mail-Followup-To: tmoestl@gmx.net, freebsd-hackers@freebsd.org References: <00112017175200.47740@pro.lookanswer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00112017175200.47740@pro.lookanswer.com>; from havoc@lookanswer.com on Mon, Nov 20, 2000 at 05:17:00PM +0200 From: Thomas Moestl <tmoestl@gmx.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I know, that x86 is big endian architecture > but simple programm like this: > > #include <stdio.h> > #include <sys/param.h> > main () { > /* Are we little or big endian? From Harbison&Steele. */ > union > { > long l; > char c[sizeof (long)]; > } u; > u.l = 1; > printf ("Little endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" : "no"); > #if BYTE_ORDER == BIG_ENDIAN > printf("Big endian\n"); > #elif BYTE_ORDER == LITTLE_ENDIAN > printf("Little endian\n"); > #else > printf("Unknown\n"); > #endif > } > > Give me a strange result: > Little endian? no > Little endian This program gets it wrong. When the last byte of a long is set after the long was set to 1, we have a big endian architecture (the "little" end is at the 4th byte, so the "big end" is at the 1st byte). > On my FreeBSD 4.2-BETA BYTE_ORDER = LITTLE_ENDIAN! > I`m very confused and some programms detect my machine as Little Endian, by > example freetds. The x86 architecture _is_ little endian. - Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 7:52:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pro.lookanswer.com (unknown [195.66.202.99]) by hub.freebsd.org (Postfix) with SMTP id AA65E37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 07:52:15 -0800 (PST) Received: (qmail 51601 invoked by uid 1001); 20 Nov 2000 15:51:33 -0000 From: Alex Koshterek <havoc@lookanswer.com> Reply-To: havoc@lookanswer.com To: Thomas Moestl <tmoestl@gmx.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Byte order? Date: Mon, 20 Nov 2000 17:47:47 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain; charset="us-ascii" References: <00112017175200.47740@pro.lookanswer.com> <20001120164006.A1624@crow.dom2ip.de> In-Reply-To: <20001120164006.A1624@crow.dom2ip.de> MIME-Version: 1.0 Message-Id: <00112017513301.47740@pro.lookanswer.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This program gets it wrong. When the last byte of a long is set after the long was > set to 1, we have a big endian architecture (the "little" end is at the 4th byte, > so the "big end" is at the 1st byte). > The x86 architecture _is_ little endian. > What? on x86 long a =1 in memory is a 01 00 00 00 Lesser significant byte is first and most significant is last To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 7:59: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool137-tch-1.Sofia.0rbitel.net [212.95.170.137]) by hub.freebsd.org (Postfix) with SMTP id 1768F37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 07:59:03 -0800 (PST) Received: (qmail 6780 invoked by uid 1000); 20 Nov 2000 15:58:39 -0000 Date: Mon, 20 Nov 2000 17:58:39 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Alex Koshterek <havoc@lookanswer.com> Cc: Thomas Moestl <tmoestl@gmx.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: Byte order? Message-ID: <20001120175839.B6292@ringworld.oblivion.bg> Mail-Followup-To: Alex Koshterek <havoc@lookanswer.com>, Thomas Moestl <tmoestl@gmx.net>, freebsd-hackers@FreeBSD.ORG References: <00112017175200.47740@pro.lookanswer.com> <20001120164006.A1624@crow.dom2ip.de> <00112017513301.47740@pro.lookanswer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00112017513301.47740@pro.lookanswer.com>; from havoc@lookanswer.com on Mon, Nov 20, 2000 at 05:47:47PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote: > > This program gets it wrong. When the last byte of a long is set after the long was > > set to 1, we have a big endian architecture (the "little" end is at the 4th byte, > > so the "big end" is at the 1st byte). > > The x86 architecture _is_ little endian. > > > What? > on x86 long a =1 > in memory is a 01 00 00 00 > Lesser significant byte is first and most significant is last Exactly - the least significant byte comes first, the number is stored in memory from its 'little' end towards its 'big' end - hence, little-endian. G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8: 3:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.102.143]) by hub.freebsd.org (Postfix) with ESMTP id 6E3AE37B479 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 08:03:25 -0800 (PST) Received: (from sasung@localhost) by ada.snu.ac.kr (8.11.1/8.11.1) id eAKG1TC88958; Tue, 21 Nov 2000 01:01:29 +0900 (KST) (envelope-from sasung) Date: Tue, 21 Nov 2000 01:01:29 +0900 From: Kim Deokhwan <sasung@ada.snu.ac.kr> To: Alex Koshterek <havoc@lookanswer.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Byte order? Message-ID: <20001121010129.A88925@ada.snu.ac.kr> Reply-To: sasung@atropos.snu.ac.kr References: <00112017175200.47740@pro.lookanswer.com> <20001120164006.A1624@crow.dom2ip.de> <00112017513301.47740@pro.lookanswer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00112017513301.47740@pro.lookanswer.com>; from havoc@lookanswer.com on Mon, Nov 20, 2000 at 05:47:47PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote: > > The x86 architecture _is_ little endian. > > > What? > on x86 long a =1 > in memory is a 01 00 00 00 > Lesser significant byte is first and most significant is last That's the very little-endian. http://www.whatis.com/WhatIs_Definition_Page/0,4152,211659,00.html -- Kim Deokhwan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8: 4:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 81DEB37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 08:04:53 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id QAA65173; Mon, 20 Nov 2000 16:59:07 +0100 (CET) (envelope-from sos) From: Soren Schmidt <sos@freebsd.dk> Message-Id: <200011201559.QAA65173@freebsd.dk> Subject: Re: Byte order? In-Reply-To: <00112017175200.47740@pro.lookanswer.com> from Alex Koshterek at "Nov 20, 2000 05:17:00 pm" To: havoc@lookanswer.com Date: Mon, 20 Nov 2000 16:59:07 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Alex Koshterek wrote: > I know, that x86 is big endian architecture > but simple programm like this: Nope the X86 CPU's are all little endian... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8: 5: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from moffetimages.com (unknown [207.251.1.130]) by hub.freebsd.org (Postfix) with ESMTP id A818C37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 08:05:01 -0800 (PST) Received: (from brianm@localhost) by moffetimages.com (8.9.3/8.9.3) id IAA62551; Mon, 20 Nov 2000 08:14:16 -0800 (PST) (envelope-from brianm) Date: Mon, 20 Nov 2000 08:14:16 -0800 (PST) From: "Brian D. Moffet" <brianm@moffetimages.com> Message-Id: <200011201614.IAA62551@moffetimages.com> To: havoc@lookanswer.com Subject: Re: Byte order? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <00112017513301.47740@pro.lookanswer.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG per the Intel Pentium Processor Users Manual, section 1.3.1 "The Pentium processor is a "little endian" machine." The program in question has the algorithm incorrect, a long in little endian would look like: 0x01 0x00 0x00 0x00 the least significant byte comes first in the memory space. Brian Moffet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8:15:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pro.lookanswer.com (unknown [195.66.202.99]) by hub.freebsd.org (Postfix) with SMTP id B25C637B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 08:15:04 -0800 (PST) Received: (qmail 53053 invoked by uid 1001); 20 Nov 2000 16:14:56 -0000 From: Alex Koshterek <havoc@lookanswer.com> Reply-To: havoc@lookanswer.com To: Peter Pentchev <roam@orbitel.bg> Subject: Re: Byte order? Date: Mon, 20 Nov 2000 18:12:48 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain; charset="us-ascii" Cc: Thomas Moestl <tmoestl@gmx.net>, freebsd-hackers@FreeBSD.ORG References: <00112017175200.47740@pro.lookanswer.com> <00112017513301.47740@pro.lookanswer.com> <20001120175839.B6292@ringworld.oblivion.bg> In-Reply-To: <20001120175839.B6292@ringworld.oblivion.bg> MIME-Version: 1.0 Message-Id: <00112018145502.47740@pro.lookanswer.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ÐÎ , 20 ÎÏÑ 2000, Peter Pentchev ÎÁÐÉÓÁÌ: > On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote: > > > This program gets it wrong. When the last byte of a long is set after the long was > > > set to 1, we have a big endian architecture (the "little" end is at the 4th byte, > > > so the "big end" is at the 1st byte). > > > The x86 architecture _is_ little endian. > > > > > What? > > on x86 long a =1 > > in memory is a 01 00 00 00 > > Lesser significant byte is first and most significant is last > > Exactly - the least significant byte comes first, the number is stored > in memory from its 'little' end towards its 'big' end - hence, little-endian. > Thanks. We all mean same thing, but I called it incorrectly ;-) I`m stupid Sorry and thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8:31:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 0643C37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 08:31:44 -0800 (PST) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id IAA54753; Mon, 20 Nov 2000 08:31:13 -0800 (PST) (envelope-from rh@matriplex.com) Date: Mon, 20 Nov 2000 08:31:13 -0800 (PST) From: Richard Hodges <rh@matriplex.com> To: Alex Koshterek <havoc@lookanswer.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Byte order? In-Reply-To: <00112017175200.47740@pro.lookanswer.com> Message-ID: <Pine.BSF.4.10.10011200827300.52841-100000@mail.matriplex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Alex Koshterek wrote: > I know, that x86 is big endian architecture > but simple programm like this: > > #include <stdio.h> > #include <sys/param.h> > main () { > /* Are we little or big endian? From Harbison&Steele. */ > union > { > long l; > char c[sizeof (long)]; > } u; > u.l = 1; > printf ("Little endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" : "no"); > #if BYTE_ORDER == BIG_ENDIAN > printf("Big endian\n"); > #elif BYTE_ORDER == LITTLE_ENDIAN > printf("Little endian\n"); > #else > printf("Unknown\n"); > #endif > } Just to be different, why not use something like: if(htonl(1) == 1) bigendian else littleendian Of course, that spoils the fun of figuring out what the compiler is doing with the union :-) All the best, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. <title> | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 8:50:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 431A437B479; Mon, 20 Nov 2000 08:50:16 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 13xu91-000477-00; Mon, 20 Nov 2000 18:50:15 +0200 Date: Mon, 20 Nov 2000 18:50:15 +0200 (IST) From: Roman Shterenzon <roman@xpert.com> To: <freebsd-hackers@freebsd.org>, <freebsd-questions@freebsd.org> Subject: truss -f Message-ID: <Pine.LNX.4.30.0011201849050.13345-100000@jamus.xpert.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Once, someone told me that he had a patch for truss that allows it to follow children, just like in Solaris (or strace -f in linux). Does anyone have it? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 9:19:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from murphys-outbound.servers.plus.net (unknown [212.159.14.225]) by hub.freebsd.org (Postfix) with SMTP id 75EFE37B479 for <hackers@freebsd.org>; Mon, 20 Nov 2000 09:19:26 -0800 (PST) Received: (qmail 4903 invoked from network); 20 Nov 2000 17:19:13 -0000 Received: from unknown (HELO daemon.lpds.sublink.org) (212.159.55.47) by murphys with SMTP; 20 Nov 2000 17:19:13 -0000 Received: from pelissero.org (hyde.lpds.sublink.org [10.0.0.2]) by daemon.lpds.sublink.org (8.9.3/8.9.3) with ESMTP id QAA09356; Mon, 20 Nov 2000 16:59:05 GMT (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.9.3/8.9.3) id RAA39553; Mon, 20 Nov 2000 17:05:39 GMT (envelope-from wcp) From: "Walter C. Pelissero" <walter@pelissero.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14873.23011.159826.718978@hyde.lpds.sublink.org> Date: Mon, 20 Nov 2000 17:05:39 +0000 (GMT) To: questions@freebsd.org, hackers@freebsd.org Subject: SVR4 missing syscall X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS (invalid system call) at the very beginning. Here is the kdump: 39525 ktrace RET ktrace 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL execve(0xbfbff9a3,0xbfbff880,0xbfbff88c) 39525 ktrace NAMI "./scobin" 39525 ktrace NAMI "/compat/svr4/usr/lib/libc.so.1" 39525 scobin RET execve 0 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL setlogin(0x72,0x805056c) 39525 scobin RET setlogin 0 39525 scobin CALL setlogin(0x28,0x280a9764) 39525 scobin RET setlogin 0 39525 scobin CALL break(0x8051580) 39525 scobin RET break 0 39525 scobin CALL setlogin(0x68,0x8049830) 39525 scobin RET setlogin 0 39525 scobin CALL getpid 39525 scobin RET getpid 39525/0x9a65 39525 scobin CALL old.lstat 39525 scobin PSIG SIGSYS SIG_DFL 39525 scobin NAMI "scobin.core" Which call is it about? I see an "old.lstat" but I couldn't find any reference in the kernel source tree. Is there any doc I could read to see if I can hack this syscall in the emulator? Thanks, -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 11: 3:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id D613B37B479; Mon, 20 Nov 2000 11:03:09 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eAKJ31S19192; Mon, 20 Nov 2000 13:03:01 -0600 (CST) (envelope-from dan) Date: Mon, 20 Nov 2000 13:03:01 -0600 From: Dan Nelson <dnelson@emsphone.com> To: "Walter C. Pelissero" <walter@pelissero.org> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4 missing syscall Message-ID: <20001120130301.A10520@dan.emsphone.com> References: <14873.23011.159826.718978@hyde.lpds.sublink.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <14873.23011.159826.718978@hyde.lpds.sublink.org>; from "Walter C. Pelissero" on Mon Nov 20 17:05:39 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Nov 20), Walter C. Pelissero said: > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > (invalid system call) at the very beginning. Here is the kdump: > > Which call is it about? I see an "old.lstat" but I couldn't find any > reference in the kernel source tree. Is there any doc I could read > to see if I can hack this syscall in the emulator? old.lstat is syscall #40, which is the ibcs2_xenix syscall on SCO. You can add hooks from the svr4 emulation code back to the ibcs2 code, but the svr4 module was really written for Solaris x86 instead of SCO. You'll have to make a lot of changes to get SCO binaries to run under it. I tried to get an SCO SVR4 binary to work about 6 months ago but gave up and simply got the vendor to send me a Linux binary instead. Runs fine under the Linuxulator :) -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 11:11:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.attica.net.nz (mail.attica.net.nz [202.180.64.33]) by hub.freebsd.org (Postfix) with SMTP id 9CE7537B479 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 11:11:46 -0800 (PST) Received: (qmail 11481 invoked from network); 20 Nov 2000 19:11:43 -0000 Received: from 202-180-83-88.iff2.attica.net.nz (HELO davep200.afterswish.com) (202.180.83.88) by mail.attica.net.nz with SMTP; 20 Nov 2000 19:11:43 -0000 Message-Id: <5.0.0.25.1.20001121080718.00a7b910@pop3.i4free.co.nz> X-Sender: dmpreece@pop3.i4free.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 21 Nov 2000 08:08:00 +1300 To: freebsd-hackers@freebsd.org From: David Preece <davep@afterswish.com> Subject: 802.1q, bonding and mpath Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [tried on -questions, will try -hackers, apologies to those who are on both] I just spent the afternoon trying to work out if channel bonding / etherchannel / trunking is possible on FreeBSD. The answers from the mailing list archives say either: 1, Nope. 2, Yup, but it's messy and you have to use PPPoE. 3, Yup, use a kernel hack called mpath. Note that (possibly due to a bad ISP) flirble.org, where mpath should be, appears to be currently unavailable so I'm slightly clue disabled at the moment. None of this seems to answer what, for me, appears to be the basic question: When a client machine ARP's for the servers IP, it has to reply with a link layer (i.e. ethernet MAC) address. All packets from client to server (or nearest router to server) then travel between these two MAC addresses. How does this work with two network cards then? Either: a, Both network cards have the same MAC address, but then how does the switch know which card to send an incoming packet to? This appears to be the approach taken by mpath since "the ARP request is replied by the head of the cluster" (pseudo quote, sorry). Is this something the switch has to understand? b, The cards have different addresses and the ARP reply is cooked such that it comes from one or the other card - like round robin DNS, only for layer 2. This is all well and good, but the next hop router would have an ARP cache, so presumably all connections would go to one card or the next. c, None of the above. I also don't get the connection with 802.1q VLAN's. 802.1q appears to be about marking ethernet packets with a VLAN number such that your one LAN can be considered to be many LAN's electrically isolated. Great, I've even used it on a cisco switch and it worked a treat. I cannot find it's connection with the trunking/bonding problem though... Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 13:16: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id B89BE37B479 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 13:15:58 -0800 (PST) Received: (qmail 15917 invoked by uid 3001); 20 Nov 2000 21:15:57 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 20 Nov 2000 21:15:57 -0000 Received: (qmail 22708 invoked by uid 1001); 20 Nov 2000 21:15:57 -0000 Date: Mon, 20 Nov 2000 16:15:57 -0500 From: Brian Reichert <reichert@numachi.com> To: freebsd-hackers@freebsd.org Subject: find, -delete, and relative paths Message-ID: <20001120161557.R11172@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I didn't find anything after an admittedly quick look intp PRs and the mail list archives: Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete I pointedly am using an absolute path, yes I get this warning repeatedly: find: -delete: /usr/local/logs/lsp: relative path potentially not safe How can I suppress this warning? Is it a bug in find, or did I misunderstand the manpage? -- Brian 'you Bastard' Reichert <reichert@numachi.com> 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 13:20: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FD6B37B4C5 for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 13:19:56 -0800 (PST) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.9.3/8.9.3) with ESMTP id LAA09315; Mon, 20 Nov 2000 11:19:13 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Mon, 20 Nov 2000 11:19:13 -1000 (HST) From: Vincent Poy <vince@oahu.WURLDLINK.NET> To: Brian Somers <brian@Awfulhak.org> Cc: FengYue <fengyue@bluerose.windmoon.nu>, hackers@FreeBSD.ORG Subject: Re: PPPoE w/ nat auto fragmentation hack? In-Reply-To: <200011122200.eACM0sB04688@hak.lan.Awfulhak.org> Message-ID: <Pine.BSF.4.21.0011201115250.1344-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 12 Nov 2000, Brian Somers wrote: > > > > Hi, Any of you happened to hack the PPPoE support on Fbsd 4.x to > > automatically fragment the IP datagram if whatever device behind the > > NAT refuses to adjust its MTU? > > There's a ``tcpmssd'' port. Or one can use Roaring Penguin PPPoE Client which was originally for Linux but works under NetBSD/OpenBSD/FreeBSD as well... This will replace using the PPPoE built into FreeBSD and can be found here: http://www.roaringpenguin.com/pppoe The latest version of the PPPoE client is 2.3. It includes nice shell scripts for managing the connection as well as more manual pages. It also includes the "MSS Clamp" feature which eliminates the need to adjust MTU settings on LAN hosts. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 13:23:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id CC43437B4CF for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 13:23:31 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 3DCC63E4F; Mon, 20 Nov 2000 22:23:30 +0100 (CET) Date: Mon, 20 Nov 2000 22:23:30 +0100 From: Jesper Skriver <jesper@skriver.dk> To: Mike Silbersack <silby@silby.com> Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001120222330.A66051@skriver.dk> References: <20001119170042.A18095@skriver.dk> <Pine.BSF.4.21.0011191822410.54936-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011191822410.54936-100000@achilles.silby.com>; from silby@silby.com on Sun, Nov 19, 2000 at 06:30:04PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 19, 2000 at 06:30:04PM -0600, Mike Silbersack wrote: > > On Sun, 19 Nov 2000, Jesper Skriver wrote: > > > A coworker of mine got into "rfc mode" and found the below, as we both > > read it, it says that we MUST treat a ICMP unreachable like a TCP RST. > > > > ########## > > ... A transport protocol > > that has its own mechanism for notifying the sender that a > > port is unreachable (e.g., TCP, which sends RST segments) > > MUST nevertheless accept an ICMP Port Unreachable for the > > same purpose. > > ########## > > > > 9 = communication with destination network > > administratively prohibited > > > > 10 = communication with destination host > > administratively prohibited > > Ok, you've got me convinced, it should be implemented. <grumble> > > There's a problem, though. Later RFCs say to use 13 instead of 10, as 10 > was supposed to be for darpa use only. My code reacts to all 3. > Perhaps you should retest the other OSes and see if they're only responding > to one of the two messages. I could do this, but does it make much difference ? > Ok, back to MXes. I've thought about it, and I can't think of any good > ways to do your configuration automatically. Perhaps you could have some > cgi that would allow you to remove yourself from the firewall ruleset, > assuming you were coming from the IP in question. Or, coming from the > other direction, the cgi could let you add yourself to the static mail > routing table if you were coming from the IP in question. This would be a option, but it would probably still require more support and manpower than the current solution. > I assume you're using sendmail's "relay if I'm listed as a MX" feature > right now? No, I'm actually using postfix, and a addition I wrote myself, from a previous email in this thread ... This is ensured by a patch(*) I wrote for postfix, from sample-smtpd.cf # permit_auth_mx_backup: accept mail if all ip address(es) of the primary MX is # within $auth_mx_backup_networks, See auth_mx_backup_networks # # The auth_mx_backup_networks parameter specifies a list of networks # where Postfix will act as a backup MX host if the primary MX is # within these networks, and permit_auth_mx_backup is configured. # # The list is used by the anti-UCE software. See permit_auth_mx_backup # in the sample-smtpd.cf file. *) <http://freesbee.wheel.dk/~jesper/permit_auth_mx_backup.20001030.diff> See the postfix.users archive for history (the above patch is the same, only relative to 20001030 instead of 20000531. <http://x71.deja.com/[ST_rn=ps]/getdoc.xp?AN=648703086&CONTEXT=974559861.626524165&hitnum=26> /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 13:41:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id A7F1837B479 for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 13:41:42 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id CDDD13E47; Mon, 20 Nov 2000 22:41:41 +0100 (CET) Date: Mon, 20 Nov 2000 22:41:41 +0100 From: Jesper Skriver <jesper@skriver.dk> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001120224141.A80979@skriver.dk> References: <20001118155446.A81075@skriver.dk> <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com> <20001118183632.A99512@skriver.dk> <20001119215357.A41281@skriver.dk> <200011192103.eAJL34713541@whizzo.transsys.com> <20001119220451.B41281@skriver.dk> <20001119223818.A79237@skriver.dk> <200011192301.eAJN15714300@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011192301.eAJN15714300@whizzo.transsys.com>; from louie@TransSys.COM on Sun, Nov 19, 2000 at 06:01:05PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 19, 2000 at 06:01:05PM -0500, Louis A. Mamakos wrote: > > It would seem more appropriate, somehow, to push the response to the > ICMP message up into the protocols where they can take the appropriate > action. Of course, the problem is that the PRC_* abstracted codes may > not be rich enough to express all the semantics you'd wish to convey. > > So one goal might be to see if this sort of process could get pushed into > netinet/tcp_sub.c:tcp_ctlinput(). Personally, I don't really like the > idea of the icmp_input() function reaching into TCP's private state and > doing stuff. So what you propose is to let netinet/ip_icmp.c all alone, and do something like the below in netinet/tcp_sub.c:tcp_ctlinput() else if ((icmp_admin_prohib_like_rst == 1) && ((cmd == ICMP_UNREACH_NET_PROHIB) || (cmd == ICMP_UNREACH_HOST_PROHIB) || (cmd == ICMP_UNREACH_FILTER_PROHIB)) && (ip)) notify = tcp_drop_syn_sent; instead of else if ((icmp_admin_prohib_like_rst == 1) && (cmd == PRC_UNREACH_PORT) && (ip)) notify = tcp_drop_syn_sent; correct ? Is this ok - from my vague understanding of this part of the code, I thought I had to use the PRC_* abstracted codes ... > There's too many potential interactions (e.g., what about > IPSEC security associations?) Dunno, know very little of IPsec ... Latest diff attached, this implement a sysctl, 'net.inet.tcp.icmp_admin_prohib_like_rst' which default to being disabled. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="icmp_admin_prohib_like_rst.diff" diff -ru sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c --- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000 +++ sys/netinet/ip_icmp.c Mon Nov 20 22:33:43 2000 @@ -328,6 +328,11 @@ case ICMP_UNREACH_NET_UNKNOWN: case ICMP_UNREACH_NET_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSNET: code = PRC_UNREACH_NET; break; @@ -335,11 +340,21 @@ case ICMP_UNREACH_HOST_UNKNOWN: case ICMP_UNREACH_ISOLATED: case ICMP_UNREACH_HOST_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSHOST: code = PRC_UNREACH_HOST; break; case ICMP_UNREACH_FILTER_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_HOST_PRECEDENCE: case ICMP_UNREACH_PRECEDENCE_CUTOFF: code = PRC_UNREACH_PORT; diff -ru sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c --- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000 +++ sys/netinet/tcp_subr.c Mon Nov 20 22:33:48 2000 @@ -134,6 +134,14 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, pcbcount, CTLFLAG_RD, &tcbinfo.ipi_count, 0, "Number of active PCBs"); +/* + * React to ICMP administratively prohibited + */ + +static int icmp_admin_prohib_like_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, icmp_admin_prohib_like_rst, CTLFLAG_RW, + &icmp_admin_prohib_like_rst, 0, "Treat ICMP administratively prohibited messages like TCP RST."); + static void tcp_cleartaocache __P((void)); static void tcp_notify __P((struct inpcb *, int)); @@ -961,6 +969,8 @@ if (cmd == PRC_QUENCH) notify = tcp_quench; + else if ((icmp_admin_prohib_like_rst == 1) && (cmd == PRC_UNREACH_PORT) && (ip)) + notify = tcp_drop_syn_sent; else if (cmd == PRC_MSGSIZE) notify = tcp_mtudisc; else if (!PRC_IS_REDIRECT(cmd) && @@ -1071,6 +1081,20 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; +} + +/* + * When a ICMP unreachable is recieved, drop the + * TCP connection, but only if in SYN SENT + */ +void +tcp_drop_syn_sent(inp, errno) + struct inpcb *inp; + int errno; +{ + struct tcpcb *tp = intotcpcb(inp); + if((tp) && (tp->t_state == TCPS_SYN_SENT)) + tcp_drop(tp, errno); } /* diff -ru sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h --- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000 +++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000 @@ -387,6 +387,7 @@ void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); +void tcp_drop_syn_sent __P((struct inpcb *, int)); void tcp_mtudisc __P((struct inpcb *, int)); struct tcpcb * tcp_newtcpcb __P((struct inpcb *)); --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 14: 2:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id D871237B4D7; Mon, 20 Nov 2000 14:02:02 -0800 (PST) Received: (from newton@localhost) by gizmo.internode.com.au (8.11.0/8.9.3) id eAKM0fq65365; Tue, 21 Nov 2000 08:30:41 +1030 (CST) (envelope-from newton) Date: Tue, 21 Nov 2000 08:30:41 +1030 From: Mark Newton <newton@internode.com.au> To: "Walter C. Pelissero" <walter@pelissero.org> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4 missing syscall Message-ID: <20001121083041.A65344@internode.com.au> References: <14873.23011.159826.718978@hyde.lpds.sublink.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <14873.23011.159826.718978@hyde.lpds.sublink.org> X-PGP-Key: http://www.on.net/~newton/pgpkey.txt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 20, 2000 at 05:05:39PM +0000, Walter C. Pelissero wrote: > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > (invalid system call) at the very beginning. Here is the kdump: > Which call is it about? I see an "old.lstat" but I couldn't find any > reference in the kernel source tree. Is there any doc I could read to > see if I can hack this syscall in the emulator? It's syscall 40, which is from XENIX. Yay, Microsoft UNIX :-) Do you know what the system call is supposed to actually do? With that info I can update the emulation to include it. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 14:42:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lh04.opsion.fr (lh04.opsion.fr [212.73.208.230]) by hub.freebsd.org (Postfix) with SMTP id E096237B4CF for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 14:42:19 -0800 (PST) Received: from 198.168.78.67 [198.168.78.67] by lh04.opsion.fr; Mon, 20 Nov 2000 22:43:20 GMT From: Thierry <tjmsdn@ifrance.com> Reply-To: tjmsdn@ifrance.com To: freebsd-hackers@freebsd.org Subject: "get_eh_context" function ??? Date: Mon, 20 Nov 2000 17:36:20 -0500 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00112017450001.01055@tjonas_dev.eicon.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm trying to implemente our driver for our OSmodem ( sources writed in C++ ) in the FreeBSD Kernel. I resolved a lot of thinks, but I have a problem with the __get_eh_context function. When a link the kernel, I have an error : undefined reference to '__get_eh_context'. Can you help me ? Can you tell me what this function do ? Thank in advance. Thierry Jonas. ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 14:48:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7B42837B4E5 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 14:48:55 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAKMmsr08887; Mon, 20 Nov 2000 14:48:54 -0800 (PST) Date: Mon, 20 Nov 2000 14:48:53 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Brian Reichert <reichert@numachi.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: find, -delete, and relative paths Message-ID: <20001120144853.E18037@fw.wintelcom.net> References: <20001120161557.R11172@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001120161557.R11172@numachi.com>; from reichert@numachi.com on Mon, Nov 20, 2000 at 04:15:57PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian Reichert <reichert@numachi.com> [001120 13:16] wrote: > I didn't find anything after an admittedly quick look intp PRs and the mail > list archives: > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > How can I suppress this warning? Is it a bug in find, or did I > misunderstand the manpage? Blind guess, is /usr/local/logs/lsp a symlink to someplace or is any part of the path a symlink that contains some form of /../ ? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 14:51:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id CD63537B4D7 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 14:51:35 -0800 (PST) Received: (qmail 17273 invoked by uid 3001); 20 Nov 2000 22:51:34 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 20 Nov 2000 22:51:34 -0000 Received: (qmail 23477 invoked by uid 1001); 20 Nov 2000 22:51:33 -0000 Date: Mon, 20 Nov 2000 17:51:33 -0500 From: Brian Reichert <reichert@numachi.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Brian Reichert <reichert@numachi.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: find, -delete, and relative paths Message-ID: <20001120175133.T11172@numachi.com> References: <20001120161557.R11172@numachi.com> <20001120144853.E18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001120144853.E18037@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Nov 20, 2000 at 02:48:53PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 20, 2000 at 02:48:53PM -0800, Alfred Perlstein wrote: > * Brian Reichert <reichert@numachi.com> [001120 13:16] wrote: > > I didn't find anything after an admittedly quick look intp PRs and the mail > > list archives: > > > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > > > How can I suppress this warning? Is it a bug in find, or did I > > misunderstand the manpage? > > Blind guess, is /usr/local/logs/lsp a symlink to someplace or is any > part of the path a symlink that contains some form of /../ ? Nope, no symlinks at all. Nice try, though. :) > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." -- Brian 'you Bastard' Reichert <reichert@numachi.com> 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 15: 4:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 0308037B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 15:04:19 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id SAA21199; Mon, 20 Nov 2000 18:09:59 -0500 (EST) (envelope-from dufault) From: Peter Dufault <dufault@hda.com> Message-Id: <200011202309.SAA21199@hda.hda.com> Subject: Re: "get_eh_context" function ??? In-Reply-To: <00112017450001.01055@tjonas_dev.eicon.com> from Thierry at "Nov 20, 2000 05:36:20 pm" To: tjmsdn@ifrance.com Date: Mon, 20 Nov 2000 18:09:59 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I resolved a lot of thinks, but I have a problem with the __get_eh_context > function. When a link the kernel, I have an error : undefined reference to > '__get_eh_context'. This appears to me to be gcc generated support for exception handling, one of the "heads up!"s that Warner and I gave you earlier. Compile with "-fno-exceptions" and fix anything that needs exception handling or be prepared to work it out carefully for yourself. Be sure you're using the same version of the compiler that the kernel uses. To reiterate another warning - don't forget about static constructors! Static objects will not have their constructors called unless you arrange to do so. For this application I personally would do away with them. Keep compiling until your object code is 100% reentrant and then write your own instantiation stubs and call them using the kernel module facilities. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 17:39:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 43A0137B4C5 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 17:39:25 -0800 (PST) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA12231; Tue, 21 Nov 2000 12:08:57 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: <XFMail.001121120856.doconnor@gsoft.com.au> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001120161557.R11172@numachi.com> Date: Tue, 21 Nov 2000 12:08:56 +1030 (CST) From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Brian Reichert <reichert@numachi.com> Subject: RE: find, -delete, and relative paths Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 20-Nov-00 Brian Reichert wrote: > I didn't find anything after an admittedly quick look intp PRs and the mail > list archives: > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > How can I suppress this warning? Is it a bug in find, or did I > misunderstand the manpage? I don't know why, but I think find prints those messages when you attempt to delete a directory. If you do -> 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete it should work.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 18:10:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 8887837B4C5 for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 18:10:17 -0800 (PST) Received: (qmail 61595 invoked by uid 1000); 21 Nov 2000 02:10:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Nov 2000 02:10:13 -0000 Date: Mon, 20 Nov 2000 20:10:13 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Jesper Skriver <jesper@skriver.dk> Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? In-Reply-To: <20001120222330.A66051@skriver.dk> Message-ID: <Pine.BSF.4.21.0011201939210.61551-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Jesper Skriver wrote: > On Sun, Nov 19, 2000 at 06:30:04PM -0600, Mike Silbersack wrote: > > Ok, you've got me convinced, it should be implemented. <grumble> > > > > There's a problem, though. Later RFCs say to use 13 instead of 10, as 10 > > was supposed to be for darpa use only. > > My code reacts to all 3. > > > Perhaps you should retest the other OSes and see if they're only responding > > to one of the two messages. > > I could do this, but does it make much difference ? Well, it makes a difference in choosing which code you should have the cisco respond with. Perhaps the other OSes are respecting 13 but not 9 or 10. > > I assume you're using sendmail's "relay if I'm listed as a MX" feature > > right now? > > No, I'm actually using postfix, and a addition I wrote myself, from a > previous email in this thread ... The concept seems well thought out. I suppose what you need to do is continue on with the achking until postfix is happy to be the primary MX and deliver to the backups automatically. Other than that, I can't think of any improvements that would be easy for customers to understand. Sorry for assuming you hadn't put much time into this. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 21:39:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 6E61F37B479 for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 21:39:54 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA55619; Mon, 20 Nov 2000 21:39:53 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eAL5drK51737; Mon, 20 Nov 2000 21:39:53 -0800 (PST) (envelope-from archie) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200011210539.eAL5drK51737@curve.dellroad.org> Subject: Re: 802.1q, bonding and mpath In-Reply-To: <5.0.0.25.1.20001121080718.00a7b910@pop3.i4free.co.nz> "from David Preece at Nov 21, 2000 08:08:00 am" To: David Preece <davep@afterswish.com> Date: Mon, 20 Nov 2000 21:39:53 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Preece writes: > I just spent the afternoon trying to work out if channel bonding / > etherchannel / trunking is possible on FreeBSD. The answers from the > mailing list archives say either: > > 1, Nope. > 2, Yup, but it's messy and you have to use PPPoE. > 3, Yup, use a kernel hack called mpath. If you're going FreeBSD <-> FreeBSD you can try ng_one2many(4).. just added in 4.2. See the man page for an example of how to set it up. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 21:49:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 2C37D37B479 for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 21:49:53 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13y6It-0004Tx-00; Tue, 21 Nov 2000 05:49:15 +0000 Date: Tue, 21 Nov 2000 05:49:15 +0000 From: Tony Finch <dot@dotat.at> To: Maxime Henrion <mux@qualys.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kqueue()/kevent(), select() and poll() Message-ID: <20001121054915.G54653@hand.dotat.at> References: <20001118150445.A260@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001118150445.A260@nebula.cybercable.fr> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxime Henrion <mux@qualys.com> wrote: > >I was wondering if it was reasonnable to implement the select() and >poll() system calls as kqueue()/kevent() wrappers. This would make >any application using these system calls benefit from the performance >improvements of the new kernel thread. The performance problem with select and poll that kqueue fixes is that kqueue doesn't require you to notify the kernel of every event you are interested in every time you call it. This is an API problem, not an implementation problem, so you cannot fix it by changing the implementation. Tony. -- f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 21:54:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4A03437B4CF for <freebsd-hackers@freebsd.org>; Mon, 20 Nov 2000 21:54:48 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13y6Na-0004dv-00; Tue, 21 Nov 2000 05:54:06 +0000 Date: Tue, 21 Nov 2000 05:54:06 +0000 From: Tony Finch <dot@dotat.at> To: David Miller <dmiller@search.sparks.net> Cc: freebsd-hackers@freebsd.org Subject: Re: UDP limits in dns server? Message-ID: <20001121055406.H54653@hand.dotat.at> References: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Miller <dmiller@search.sparks.net> wrote: > >I'm looking up the IP addresses with up to 1500 or so processes each >taking a list of addresses and running gethostbyaddr() on them. That's stupid. Use adns instead. http://www.chiark.greenend.org.uk/~ian/adns/ >I'm particularly perplexed that a K6-200 system I had was cpu bound >running named and achieved ~200 resolves/sec; my spiffy new 1100 MHz >K7 is struggling to double it. You should be able to acheive that perfomance with one process running adns. You should be able to do much better if you add a cache (even quite a small one), since IP addresses in web logs are quite repetitive. Tony. -- f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 21:56:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 545F237B4C5 for <hackers@freebsd.org>; Mon, 20 Nov 2000 21:56:15 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13y6P5-0004hL-00; Tue, 21 Nov 2000 05:55:39 +0000 Date: Tue, 21 Nov 2000 05:55:39 +0000 From: Tony Finch <dot@dotat.at> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@freebsd.org Subject: Re: res_ functions thread safe? Message-ID: <20001121055539.I54653@hand.dotat.at> References: <20001119225712.W18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001119225712.W18037@fw.wintelcom.net> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein <bright@wintelcom.net> wrote: >I need to do MX lookups in a threaded program, does anyone know if >the res_ functions are thread safe, or if there's an alternative >I can use that is? http://www.chiark.greenend.org.uk/~ian/adns/ again :-) Tony. -- f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 22: 5:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.netsol.net (mail.netsol.net [216.179.148.10]) by hub.freebsd.org (Postfix) with ESMTP id A52E337B4CF for <hackers@freebsd.org>; Mon, 20 Nov 2000 22:05:19 -0800 (PST) Received: from fire ([63.194.3.101]) by mail1.netsol.net (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id net; Mon, 20 Nov 2000 22:09:38 -0800 Message-ID: <000c01c05381$06c42ba0$6503c23f@XGforce.com> Reply-To: "jl" <tech@scsr.com> From: "jl" <tech@scsr.com> To: "Tony Finch" <dot@dotat.at>, "Alfred Perlstein" <bright@wintelcom.net> Cc: <hackers@freebsd.org> References: <20001119225712.W18037@fw.wintelcom.net> <20001121055539.I54653@hand.dotat.at> Subject: Re: res_ functions thread safe? Date: Mon, 20 Nov 2000 22:05:17 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How about do a fork then call res_()? This may help even if ====================================== WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. ====================================== ----- Original Message ----- From: Tony Finch <dot@dotat.at> To: Alfred Perlstein <bright@wintelcom.net> Cc: <hackers@freebsd.org> Sent: Monday, November 20, 2000 9:55 PM Subject: Re: res_ functions thread safe? > Alfred Perlstein <bright@wintelcom.net> wrote: > >I need to do MX lookups in a threaded program, does anyone know if > >the res_ functions are thread safe, or if there's an alternative > >I can use that is? > > http://www.chiark.greenend.org.uk/~ian/adns/ again :-) > > Tony. > -- > f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 22:44:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D73C037B479 for <hackers@freebsd.org>; Mon, 20 Nov 2000 22:44:15 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAL6iA822160; Mon, 20 Nov 2000 22:44:10 -0800 (PST) Date: Mon, 20 Nov 2000 22:44:10 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Tony Finch <dot@dotat.at> Cc: hackers@freebsd.org Subject: Re: res_ functions thread safe? Message-ID: <20001120224410.O18037@fw.wintelcom.net> References: <20001119225712.W18037@fw.wintelcom.net> <20001121055539.I54653@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121055539.I54653@hand.dotat.at>; from dot@dotat.at on Tue, Nov 21, 2000 at 05:55:39AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Tony Finch <dot@dotat.at> [001120 21:56] wrote: > Alfred Perlstein <bright@wintelcom.net> wrote: > >I need to do MX lookups in a threaded program, does anyone know if > >the res_ functions are thread safe, or if there's an alternative > >I can use that is? > > http://www.chiark.greenend.org.uk/~ian/adns/ again :-) This is useless for a commercial product for obvious reasons. I'm looking for something freely available. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 23: 3:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 4804237B4D7 for <hackers@freebsd.org>; Mon, 20 Nov 2000 23:03:17 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13y7Ru-0006uA-00; Tue, 21 Nov 2000 07:02:38 +0000 Date: Tue, 21 Nov 2000 07:02:38 +0000 From: Tony Finch <dot@dotat.at> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@freebsd.org Subject: Re: res_ functions thread safe? Message-ID: <20001121070238.A19849@hand.dotat.at> References: <20001119225712.W18037@fw.wintelcom.net> <20001121055539.I54653@hand.dotat.at> <20001120224410.O18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001120224410.O18037@fw.wintelcom.net> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein <bright@wintelcom.net> wrote: >* Tony Finch <dot@dotat.at> [001120 21:56] wrote: >> >> http://www.chiark.greenend.org.uk/~ian/adns/ again :-) > >This is useless for a commercial product for obvious reasons. Yes, a shame because it's really nice. Tony. -- f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Nov 20 23:34:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 255D337B479 for <hackers@FreeBSD.ORG>; Mon, 20 Nov 2000 23:34:34 -0800 (PST) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id eAL7V8Y23833; Tue, 21 Nov 2000 13:31:17 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Date: Tue, 21 Nov 2000 13:31:06 +0600 (NS) From: Max Khon <fjoe@iclub.nsu.ru> To: Tony Finch <dot@dotat.at> Cc: Alfred Perlstein <bright@wintelcom.net>, hackers@FreeBSD.ORG Subject: Re: res_ functions thread safe? In-Reply-To: <20001121070238.A19849@hand.dotat.at> Message-ID: <Pine.BSF.4.21.0011211330010.23317-100000@iclub.nsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Tue, 21 Nov 2000, Tony Finch wrote: > >> http://www.chiark.greenend.org.uk/~ian/adns/ again :-) > > > >This is useless for a commercial product for obvious reasons. > > Yes, a shame because it's really nice. if I understand correctly nsswitch patches implement getxxx_r functions as well /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 3:25:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from warrior-outbound.servers.plus.net (unknown [212.159.14.227]) by hub.freebsd.org (Postfix) with SMTP id BD04B37B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 03:25:46 -0800 (PST) Received: (qmail 28780 invoked from network); 21 Nov 2000 11:25:31 -0000 Received: from unknown (HELO daemon.lpds.sublink.org) (212.159.41.48) by warrior with SMTP; 21 Nov 2000 11:25:31 -0000 Received: from pelissero.org (hyde.lpds.sublink.org [10.0.0.2]) by daemon.lpds.sublink.org (8.9.3/8.9.3) with ESMTP id LAA00946; Tue, 21 Nov 2000 11:17:14 GMT (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.9.3/8.9.3) id LAA44208; Tue, 21 Nov 2000 11:22:36 GMT (envelope-from wcp) From: "Walter C. Pelissero" <walter@pelissero.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.23292.748589.450210@hyde.lpds.sublink.org> Date: Tue, 21 Nov 2000 11:22:36 +0000 (GMT) To: Mark Newton <newton@internode.com.au> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4 missing syscall In-Reply-To: <20001121083041.A65344@internode.com.au> References: <14873.23011.159826.718978@hyde.lpds.sublink.org> <20001121083041.A65344@internode.com.au> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Newton writes: > On Mon, Nov 20, 2000 at 05:05:39PM +0000, Walter C. Pelissero wrote: > > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > > (invalid system call) at the very beginning. Here is the kdump: > > Which call is it about? I see an "old.lstat" but I couldn't find any > > reference in the kernel source tree. Is there any doc I could read to > > see if I can hack this syscall in the emulator? > > It's syscall 40, which is from XENIX. Yay, Microsoft UNIX :-) > > Do you know what the system call is supposed to actually do? No idea, sorry. > With that info I can update the emulation to include it. I wish I could do it for you. If only someone could give me the right hints on how to hack the IBCS2. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 3:26: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from warrior-outbound.servers.plus.net (unknown [212.159.14.227]) by hub.freebsd.org (Postfix) with SMTP id 3C86537B4FE for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 03:25:48 -0800 (PST) Received: (qmail 28792 invoked from network); 21 Nov 2000 11:25:33 -0000 Received: from unknown (HELO daemon.lpds.sublink.org) (212.159.41.48) by warrior with SMTP; 21 Nov 2000 11:25:33 -0000 Received: from pelissero.org (hyde.lpds.sublink.org [10.0.0.2]) by daemon.lpds.sublink.org (8.9.3/8.9.3) with ESMTP id LAA00919; Tue, 21 Nov 2000 11:14:23 GMT (envelope-from wcp@pelissero.org) Received: (from wcp@localhost) by pelissero.org (8.9.3/8.9.3) id LAA44192; Tue, 21 Nov 2000 11:19:45 GMT (envelope-from wcp) From: "Walter C. Pelissero" <walter@pelissero.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.23121.801503.448167@hyde.lpds.sublink.org> Date: Tue, 21 Nov 2000 11:19:45 +0000 (GMT) To: Dan Nelson <dnelson@emsphone.com> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4 missing syscall In-Reply-To: <20001120130301.A10520@dan.emsphone.com> References: <14873.23011.159826.718978@hyde.lpds.sublink.org> <20001120130301.A10520@dan.emsphone.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Reply-To: walter@pelissero.org X-Attribution: WP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson writes: > In the last episode (Nov 20), Walter C. Pelissero said: > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > > (invalid system call) at the very beginning. Here is the kdump: > > > > Which call is it about? I see an "old.lstat" but I couldn't find any > > reference in the kernel source tree. Is there any doc I could read > > to see if I can hack this syscall in the emulator? > > old.lstat is syscall #40, which is the ibcs2_xenix syscall on SCO. May I ask you where you got this information from? I was grep-ing around in the kernel source tree but I couldn't figure out that this old.lstat is syscall #40, let alone that it was a Xenix syscall. Is there any doc that can help me hacking this syscall into the ibcs2 emulator? > You can add hooks from the svr4 emulation code back to the ibcs2 > code, but the svr4 module was really written for Solaris x86 > instead of SCO. You'll have to make a lot of changes to get SCO > binaries to run under it. I tried to get an SCO SVR4 binary to > work about 6 months ago but gave up and simply got the vendor to > send me a Linux binary instead. Runs fine under the Linuxulator :) Are you telling me that the IBCS emulator is not really working? Unfortunately I can't ask for a Linux version. Have you ever had a look at the NetBSD one? Is it usable? Thanks for your help. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 5:56:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from star.rila.bg (star.rila.bg [212.39.75.32]) by hub.freebsd.org (Postfix) with ESMTP id AD28D37B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 05:56:40 -0800 (PST) Received: from star (vlady@localhost [127.0.0.1]) by star.rila.bg (8.9.3/8.9.3) with ESMTP id PAA63147 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 15:57:34 +0200 (EET) (envelope-from vlady@star.rila.bg) Message-Id: <200011211357.PAA63147@star.rila.bg> X-Mailer: exmh version 2.1.1 10/15/1999 To: hackers@FreeBSD.ORG From: "Vladimir Terziev" <vladimirt@rila.bg> Subject: Semaphore blocking and signal handling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 15:57:34 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. Am I right for the following: When a process is blocked on semop (trying to get resource) and receives a signal (for which the process has a handler), the process gets unblocked from the semop wait (to handle the signal), and after handling the signal continues with the instruction after semop, as if it was unblocked by successful semop. Is this behaviour normal, and is there a way for the process to distinguish between signal handling unblock and successful semop operation (may be by setting a global variable in the signal-handling function) ? Thank you in advance. Vladimir Terziev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 5:58:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by hub.freebsd.org (Postfix) with ESMTP id 4B78937B4E5 for <hackers@freebsd.org>; Tue, 21 Nov 2000 05:58:48 -0800 (PST) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 6BBF5A828; Wed, 22 Nov 2000 00:58:41 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 69DF65469 for <hackers@freebsd.org>; Tue, 21 Nov 2000 23:58:41 +1000 (EST) Date: Tue, 21 Nov 2000 23:58:41 +1000 (EST) From: andrew@ugh.net.au To: hackers@freebsd.org Subject: Hiding the cursor on the console Message-ID: <Pine.BSF.4.21.0011212356500.34727-100000@starbug.ugh.net.au> X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Is it possible to hide the (text) cursor when using syscons? There is no vi attribute defined for the cons25 termcap record...is this an oversite or is it not possible? Thanks, Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 6: 5:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from exchange.universe.dart.spb (mail.dart.sp.ru [195.131.27.95]) by hub.freebsd.org (Postfix) with ESMTP id 6E82637B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 06:05:08 -0800 (PST) Received: from runnet-gw.marketsite.ru (WILD [192.168.1.24]) by exchange.universe.dart.spb with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XDG3PHN6; Tue, 21 Nov 2000 17:04:58 +0300 Content-Length: 1827 Message-ID: <XFMail.001121170605.diwil@dataart.com> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011211357.PAA63147@star.rila.bg> Date: Tue, 21 Nov 2000 17:06:05 +0300 (MSK) Reply-To: diwil@dataart.com From: Dmitry Dicky <diwil@dataart.com> To: Vladimir Terziev <vladimirt@rila.bg> Subject: RE: Semaphore blocking and signal handling Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, easy: ------------------------------- extern int errno; int sem_lock(int semnumb) { struct sembuf sb[2]; sb[0].sem_num = semnumb; sb[0].sem_op = -1; sb[0].sem_flg = 0; again: if( semop(sh->sem, sb,1) ) { errmsg("Semaphore %d erorr: %s\n",sh->sem, strerror(errno)); // here you'll see the reason why semaphore returned an error if(errno = EINTR) goto again; return -1; } return 0; } ---------------------------------- At least it works in my case. Regards, D. On 21-Nov-00 Vladimir Terziev wrote: > Hi. > > Am I right for the following: > > When a process is blocked on semop (trying to get resource) and receives > a signal (for which the process has a handler), the process gets > unblocked > from the semop wait (to handle the signal), and after handling the > signal > continues with the instruction after semop, as if it was unblocked by > successful semop. > > Is this behaviour normal, and is there a way for the process to > distinguish > between signal handling unblock and successful semop operation (may be > by > setting a global variable in the signal-handling function) ? > > Thank you in advance. > > Vladimir Terziev > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- ********************************************************************** ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) DataArt Enterprises, Inc. (_Y_.)' ._ ) `._ `. ``-..-' Serpukhovskaja street, 10 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 3261780, 5585314 ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 6:44:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E29E337B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 06:44:39 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 0379A193DF; Tue, 21 Nov 2000 08:44:38 -0600 (CST) Date: Tue, 21 Nov 2000 08:44:38 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: Max Khon <fjoe@iclub.nsu.ru> Cc: hackers@FreeBSD.ORG Subject: Re: res_ functions thread safe? Message-ID: <20001121084438.B77911@spawn.nectar.com> References: <20001121070238.A19849@hand.dotat.at> <Pine.BSF.4.21.0011211330010.23317-100000@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011211330010.23317-100000@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Tue, Nov 21, 2000 at 01:31:06PM +0600 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 01:31:06PM +0600, Max Khon wrote: > if I understand correctly nsswitch patches implement getxxx_r functions as > well Yes, but they have to live `on top of' the existing resolver. :-( -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 7:29:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from online.dct.com (online.dct.com [204.29.185.1]) by hub.freebsd.org (Postfix) with ESMTP id 4C6D537B4C5; Tue, 21 Nov 2000 07:29:08 -0800 (PST) Received: (from markm@localhost) by online.dct.com (8.9.3/8.9.3) id JAA19547; Tue, 21 Nov 2000 09:29:02 -0600 (CST) Date: Tue, 21 Nov 2000 09:29:02 -0600 From: Mark <markm@online.dct.com> To: questions@freebsd.org Cc: hackers@freebsd.org Subject: Systems programming questions... Message-ID: <20001121092902.A6568@online.dct.com> Reply-To: markm@gbonline.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey all -- I'm trying to find a "correct" way to add virtual interfaces to my network card via a C program. right now, I've come up with 3 system() calls to do the work. I don't know if there is a better way or not, but if there is, I'd like to use it. Is there a better way to create and make active a virtual interface in a C program other than using system() to call an ifconfig, route, and arp command? Thanks, -- Mark Maurer markm@solinus.com Programmer, Solinus Inc. Play: markm@gbonline.com http://www.dct.com/~markm/ Other: mark@thecity.com mark@mail2go.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 7:37:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool34-tch-1.Sofia.0rbitel.net [212.95.170.34]) by hub.freebsd.org (Postfix) with SMTP id 06A8737B479 for <hackers@freebsd.org>; Tue, 21 Nov 2000 07:37:15 -0800 (PST) Received: (qmail 31990 invoked by uid 1000); 21 Nov 2000 15:36:51 -0000 Date: Tue, 21 Nov 2000 17:36:51 +0200 From: Peter Pentchev <roam@orbitel.bg> To: markm@gbonline.com Cc: questions@freebsd.org, hackers@freebsd.org Subject: Re: Systems programming questions... Message-ID: <20001121173651.C9661@ringworld.oblivion.bg> Mail-Followup-To: markm@gbonline.com, questions@freebsd.org, hackers@freebsd.org References: <20001121092902.A6568@online.dct.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121092902.A6568@online.dct.com>; from markm@online.dct.com on Tue, Nov 21, 2000 at 09:29:02AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 09:29:02AM -0600, Mark wrote: > Hey all -- > > I'm trying to find a "correct" way to add virtual interfaces to my network > card via a C program. right now, I've come up with 3 system() calls to do the > work. I don't know if there is a better way or not, but if there is, I'd like > to use it. Is there a better way to create and make active a virtual > interface in a C program other than using system() to call an ifconfig, route, > and arp command? Generally, the 'most correct' way to do almost anything regarding interfaces can be found in the /sbin/ifconfig source. I do not really know why you also need to do a route and arp though; I admin I know nothing about arp, but I'm pretty sure that the FreeBSD kernel automagically installs a new route for each newly-upped interface. Hope that helps.. G'luck, Peter -- "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 7:43:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 116EB37B4D7; Tue, 21 Nov 2000 07:43:15 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eALFhDJ18349; Tue, 21 Nov 2000 09:43:13 -0600 (CST) (envelope-from dan) Date: Tue, 21 Nov 2000 09:43:13 -0600 From: Dan Nelson <dnelson@emsphone.com> To: "Walter C. Pelissero" <walter@pelissero.org> Cc: emulation@freebsd.org Subject: Re: SVR4 missing syscall Message-ID: <20001121094313.A1118@dan.emsphone.com> References: <14873.23011.159826.718978@hyde.lpds.sublink.org> <20001120130301.A10520@dan.emsphone.com> <14874.23121.801503.448167@hyde.lpds.sublink.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <14874.23121.801503.448167@hyde.lpds.sublink.org>; from "Walter C. Pelissero" on Tue Nov 21 11:19:45 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Followups to -emulation, please In the last episode (Nov 21), Walter C. Pelissero said: > Dan Nelson writes: > > In the last episode (Nov 20), Walter C. Pelissero said: > > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a > > > SIGSYS (invalid system call) at the very beginning. Here is the > > > kdump: > > > > > > Which call is it about? I see an "old.lstat" but I couldn't find > > > any reference in the kernel source tree. Is there any doc I > > > could read to see if I can hack this syscall in the emulator? > > > > old.lstat is syscall #40, which is the ibcs2_xenix syscall on SCO. > > May I ask you where you got this information from? I was grep-ing > around in the kernel source tree but I couldn't figure out that this > old.lstat is syscall #40, let alone that it was a Xenix syscall. Take a look at /sys/kern/syscalls.master. Any syscall with the word "old" in it has been phased out and gets a COMPAT flag. So you would look for a "COMPAT ... lstat" line, which happens to be #40. > Is there any doc that can help me hacking this syscall into the ibcs2 > emulator? > > > You can add hooks from the svr4 emulation code back to the ibcs2 > > code, but the svr4 module was really written for Solaris x86 > > instead of SCO. You'll have to make a lot of changes to get SCO > > binaries to run under it. I tried to get an SCO SVR4 binary to > > work about 6 months ago but gave up and simply got the vendor to > > send me a Linux binary instead. Runs fine under the Linuxulator :) > > Are you telling me that the IBCS emulator is not really working? > Unfortunately I can't ask for a Linux version. Have you ever had a > look at the NetBSD one? Is it usable? If you have access to NetBSD binaries, get them. FreeBSD should be able to run static NetBSD, OpenBSD, and BSD/OS binaries natively; no emulation layer required. The iBCS2 emulator works great; I've run all sorts of SCO 3.2v4.2 binaries on FreeBSD with it. Your problem is that SCO 5.* doesn't use iBCS2 anymore; it uses svr4 binaries. Even more of a problem is that SCO binaries rely heavily on old SCO syscalls. You end up having to link in the whole iBCS2 module, AND recode a bunch of syscalls that are different between Solaris and SCO (since our svr4 emulator was written for Solaris). And you have to do all of this in the dark because SCO doesn't release any information about their kernel. I couldn't even find a list of syscalls and their arguments. I had to grep through include files and try and reverse-engineer everything. If you want more background, take a look at the thread starting at http://www.freebsd.org/cgi/getmsg.cgi?fetch=28280+0+/usr/local/www/db/text/1999/freebsd-emulation/19990509.freebsd-emulation I have patches for a June 30 -current that implement enough SCO stuff to make /bin/sh work (but /bin/ls dies), if you're interested. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 7:51: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from online.dct.com (online.dct.com [204.29.185.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B5F337B479; Tue, 21 Nov 2000 07:51:00 -0800 (PST) Received: (from markm@localhost) by online.dct.com (8.9.3/8.9.3) id JAA22896; Tue, 21 Nov 2000 09:50:53 -0600 (CST) Date: Tue, 21 Nov 2000 09:50:53 -0600 From: Mark <markm@online.dct.com> To: Peter Pentchev <roam@orbitel.bg> Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Systems programming questions... Message-ID: <20001121095053.B6568@online.dct.com> Reply-To: markm@gbonline.com References: <20001121092902.A6568@online.dct.com> <20001121173651.C9661@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001121173651.C9661@ringworld.oblivion.bg>; from roam@orbitel.bg on Tue, Nov 21, 2000 at 05:36:51PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Peter Pentchev (roam@orbitel.bg): > On Tue, Nov 21, 2000 at 09:29:02AM -0600, Mark wrote: > > Hey all -- > > > > I'm trying to find a "correct" way to add virtual interfaces to my network > > card via a C program. right now, I've come up with 3 system() calls to do the > > work. I don't know if there is a better way or not, but if there is, I'd like > > to use it. Is there a better way to create and make active a virtual > > interface in a C program other than using system() to call an ifconfig, route, > > and arp command? > > Generally, the 'most correct' way to do almost anything regarding interfaces > can be found in the /sbin/ifconfig source. I do not really know why you > also need to do a route and arp though; I admin I know nothing about arp, > but I'm pretty sure that the FreeBSD kernel automagically installs a new route > for each newly-upped interface. > > Hope that helps.. Sure does... I guess I don't need the route and arp commands. Works just fine with the "ifconfig ... alias" system call. I guess the next step is to look at the source for /sbin/ifconfig, like you suggested. Thanks for the help, -- Mark Maurer markm@solinus.com Programmer, Solinus Inc. Play: markm@gbonline.com http://www.dct.com/~markm/ Other: mark@thecity.com mark@mail2go.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 8: 5:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id C0EC637B4CF for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 08:05:42 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eALG5Xk15112; Tue, 21 Nov 2000 10:05:33 -0600 (CST) (envelope-from dan) Date: Tue, 21 Nov 2000 10:05:33 -0600 From: Dan Nelson <dnelson@emsphone.com> To: andrew@ugh.net.au Cc: hackers@FreeBSD.ORG Subject: Re: Hiding the cursor on the console Message-ID: <20001121100533.B23358@dan.emsphone.com> References: <Pine.BSF.4.21.0011212356500.34727-100000@starbug.ugh.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <Pine.BSF.4.21.0011212356500.34727-100000@starbug.ugh.net.au>; from "andrew@ugh.net.au" on Tue Nov 21 23:58:41 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Nov 21), andrew@ugh.net.au said: > Hi, > > Is it possible to hide the (text) cursor when using syscons? There is > no vi attribute defined for the cons25 termcap record...is this an > oversite or is it not possible? You can cheat by setting the cursor shape to an invalid one, which will turn it off, then setting it back to normal when you want to turn it on again: off: ESC [=16;15C ESC [=3C on: ESC [=15;16C ESC [=3C -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 8:21:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool34-tch-1.Sofia.0rbitel.net [212.95.170.34]) by hub.freebsd.org (Postfix) with SMTP id 87C0137B479 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 08:21:53 -0800 (PST) Received: (qmail 32246 invoked by uid 1000); 21 Nov 2000 16:21:29 -0000 Date: Tue, 21 Nov 2000 18:21:29 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Dan Nelson <dnelson@emsphone.com> Cc: andrew@ugh.net.au, hackers@FreeBSD.ORG Subject: Re: Hiding the cursor on the console Message-ID: <20001121182128.D9661@ringworld.oblivion.bg> Mail-Followup-To: Dan Nelson <dnelson@emsphone.com>, andrew@ugh.net.au, hackers@FreeBSD.ORG References: <Pine.BSF.4.21.0011212356500.34727-100000@starbug.ugh.net.au> <20001121100533.B23358@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121100533.B23358@dan.emsphone.com>; from dnelson@emsphone.com on Tue, Nov 21, 2000 at 10:05:33AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 10:05:33AM -0600, Dan Nelson wrote: > In the last episode (Nov 21), andrew@ugh.net.au said: > > Hi, > > > > Is it possible to hide the (text) cursor when using syscons? There is > > no vi attribute defined for the cons25 termcap record...is this an > > oversite or is it not possible? > > You can cheat by setting the cursor shape to an invalid one, which will > turn it off, then setting it back to normal when you want to turn it on > again: > > off: ESC [=16;15C ESC [=3C > on: ESC [=15;16C ESC [=3C That's what I've tried doing, but I'm stumbling into a funny syscons behavior - the cursor shape is maintained across consoles, it is impossible to change it for a certain console only. Thus, when I define a 'hide cursor' termcap attribute, all my consoles lose the cursor whenever I fire up mutt :\ A cursor-shape-per-console syscons patch has been on my todo list for quite some time now; just never seem to find the time for it :( G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 12:19: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 444A937B479 for <hackers@FreeBSD.org>; Tue, 21 Nov 2000 12:18:54 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id A45103E4F; Tue, 21 Nov 2000 21:18:53 +0100 (CET) Date: Tue, 21 Nov 2000 21:18:53 +0100 From: Jesper Skriver <jesper@skriver.dk> To: hackers@FreeBSD.org Subject: Re: React to ICMP administratively prohibited ? - commit candidate ? Message-ID: <20001121211853.B84107@skriver.dk> References: <20001117211013.C9227@skriver.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001117211013.C9227@skriver.dk>; from jesper@skriver.dk on Fri, Nov 17, 2000 at 09:10:13PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 17, 2000 at 09:10:13PM +0100, Jesper Skriver wrote: As said before, I've not got this code working, when the sysctl 'net.inet.tcp.icmp_admin_prohib_like_rst' is set to 1, we'll treat a ICMP administratively prohibited (icmp type 3 code 9, 10 and 13) as if we recived a TCP RST, but only if the TCP session is in SYN_SENT state. This is actually required by rfc1122 (Requirements for Internet Hosts) section 3.2.2.1 A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. Because of this, I suggest that we by default enable this feature, but it would be a change of current behaviour, so if people prefer to leave it disabled by default, at least for now, this would be ok for me, the attached diff actually have the sysctl set to 0 by default. The only difference from the attached diff, to the one I mailed yesterday is comments. Does anyone have any objections to this being committed ? If no, who will do it ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Description: icmp_admin_prohib_like_rst.diff Content-Disposition: attachment; filename="icmp_admin_prohib_like_rst.diff" diff -ru sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c --- sys/netinet.old/ip_icmp.c Thu Nov 2 10:46:23 2000 +++ sys/netinet/ip_icmp.c Mon Nov 20 22:33:43 2000 @@ -328,6 +328,11 @@ case ICMP_UNREACH_NET_UNKNOWN: case ICMP_UNREACH_NET_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSNET: code = PRC_UNREACH_NET; break; @@ -335,11 +340,21 @@ case ICMP_UNREACH_HOST_UNKNOWN: case ICMP_UNREACH_ISOLATED: case ICMP_UNREACH_HOST_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_TOSHOST: code = PRC_UNREACH_HOST; break; case ICMP_UNREACH_FILTER_PROHIB: + if (icp->icmp_ip.ip_p == IPPROTO_TCP) { + code = PRC_UNREACH_PORT; + break; + } + case ICMP_UNREACH_HOST_PRECEDENCE: case ICMP_UNREACH_PRECEDENCE_CUTOFF: code = PRC_UNREACH_PORT; diff -ru sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c --- sys/netinet.old/tcp_subr.c Fri Oct 27 13:45:41 2000 +++ sys/netinet/tcp_subr.c Tue Nov 21 21:16:27 2000 @@ -134,6 +134,15 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, pcbcount, CTLFLAG_RD, &tcbinfo.ipi_count, 0, "Number of active PCBs"); +/* + * Treat ICMP administratively prohibited like a TCP RST + * as required by rfc1122 section 3.2.2.1 + */ + +static int icmp_admin_prohib_like_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, icmp_admin_prohib_like_rst, CTLFLAG_RW, + &icmp_admin_prohib_like_rst, 0, "Treat ICMP administratively prohibited messages like TCP RST, rfc1122 section 3.2.2.1"); + static void tcp_cleartaocache __P((void)); static void tcp_notify __P((struct inpcb *, int)); @@ -961,6 +970,8 @@ if (cmd == PRC_QUENCH) notify = tcp_quench; + else if ((icmp_admin_prohib_like_rst == 1) && (cmd == PRC_UNREACH_PORT) && (ip)) + notify = tcp_drop_syn_sent; else if (cmd == PRC_MSGSIZE) notify = tcp_mtudisc; else if (!PRC_IS_REDIRECT(cmd) && @@ -1071,6 +1082,20 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; +} + +/* + * When a ICMP unreachable is recieved, drop the + * TCP connection, but only if in SYN_SENT + */ +void +tcp_drop_syn_sent(inp, errno) + struct inpcb *inp; + int errno; +{ + struct tcpcb *tp = intotcpcb(inp); + if((tp) && (tp->t_state == TCPS_SYN_SENT)) + tcp_drop(tp, errno); } /* diff -ru sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h --- sys/netinet.old/tcp_var.h Sat Jul 22 01:26:37 2000 +++ sys/netinet/tcp_var.h Sun Nov 19 21:17:55 2000 @@ -387,6 +387,7 @@ void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); +void tcp_drop_syn_sent __P((struct inpcb *, int)); void tcp_mtudisc __P((struct inpcb *, int)); struct tcpcb * tcp_newtcpcb __P((struct inpcb *)); --QKdGvSO+nmPlgiQ/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 13:47: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mb1i0.ns.pitt.edu (mb1i0.ns.pitt.edu [136.142.186.35]) by hub.freebsd.org (Postfix) with ESMTP id EB85537B4C5 for <freebsd-hackers@FreeBSD.org>; Tue, 21 Nov 2000 13:47:02 -0800 (PST) Received: from box022.labs.pitt.edu ("port 1458"@[130.49.141.33]) by pitt.edu (PMDF V5.2-32 #41462) with ESMTP id <01JWT4K4ROSS0004NE@mb1i0.ns.pitt.edu> for freebsd-hackers@FreeBSD.org; Tue, 21 Nov 2000 16:40:49 EST Date: Tue, 21 Nov 2000 16:40:49 -0500 From: "Pedro F. Giffuni" <pfg1+@pitt.edu> Subject: sfork() ?? Originator-info: login-id=pfg1; server=imap.pitt.edu To: freebsd-hackers@FreeBSD.org Message-id: <4162240307.974824849@box022.labs.pitt.edu> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline Content-transfer-encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I was reading that interesting article that some posted on the list of an implementaion of Scheduler Activations for an old version of BSDI. The article mentions that it was based of BSDI's sfork() call. This call is referenced in our syscalls.master but it's not implemented and the BSDI manpages seem to have vanished from the net. Can someone knowledgeable comment on what it does, and maybe if it could (or should) be brought into FreeBSD ? tia, Pedro. BTW, the .ps version of that article is really better than the .pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 16:36:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id D2BEF37B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 16:36:52 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id TAA283086; Tue, 21 Nov 2000 19:36:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p04330104b640abfaf13d@[128.113.24.47]> In-Reply-To: <200011201020.MAA23349@siri.nordier.com> References: <200011201020.MAA23349@siri.nordier.com> Date: Tue, 21 Nov 2000 19:36:39 -0500 To: Robert Nordier <rnordier@nordier.com> From: Garance A Drosihn <drosih@rpi.edu> Subject: Re: fclose vs ferror (from libc/getcap) Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:19 PM +0200 11/20/00, Robert Nordier wrote: >Garance A Drosihn wrote: > > [...] The basic problem is some code which does: > > >> (void)fclose(pfp); >> if (ferror(pfp)) { >> ...do stuff... >> } >> > > I find it surprising that the above works under FreeBSD. > > [...] > >Bear in mind that ferror is one of a number of stdio functions that >are often implemented as macros. For instance: ferror and (say) >getc might look like this: > > #define ferror(f) ((f)->fl & _FERR) > #define getc(f) ((f)->p < (f)->xr ? *(f)->p++ : fgetc(f)) > >Given the intentionally minimalist way those functions are written, >to do any consistent and obligatory sanity-checking on (FILE *) would >cause a big change in the actual code generated, and the amount of >code generated. Hmm. I can see that it would add some overhead. This may seem paradoxical, but I'm not quite as concerned about getc as I am about ferror. If you're calling getc on a closed stream, then you're almost always going to get into some obvious trouble, and right in that section of code. The thing with ferror is that it will generally "work" after the fclose, although the value it returns might not be the right (pre-close) value. And before I go on with the rest of my response, let me note that I realize that my own (personal) headaches with this is due to linux's implementation of ferror. It's just that this was in code from freebsd that I was trying to run on linux, and I was surprised that this fclose/ferror combination was not a problem caught on freebsd. >I think the best way to do what you want is to create a separate >debugging library. This is great if you already know where the problem is. In my case, I started out with a problem that was nowhere-near the code which had the above bug in it. Initially the process was dying in a call to inet_aton(). I commented that out (as a debugging measure, since I knew what the result of that call would be), and then the process would die in some other library routine that I forget right now. I commented out the call to THAT routine, and finally the process started to die on a call to fopen. Not an fopen anywhere near the above fclose, but at least this indicated the problem might have something to do with io-streams. To make debugging matters worse, I am debugging this in a daemon process, and the process would sometimes work perfectly fine, while other times it would simply disappear. For those and other reasons, I had spent a few hours debugging the problem before I had any idea the problem was specific to routines for streamed IO. [note that the debugging library does not do any good unless one knows to #undef those macros, so that strategy does not work until after someone has already figured out where the problem is] >The point about > > (void)fclose(pfp); > if (ferror(pfp)) { > ...do stuff... > } > >is that it's a silly thing to do deliberately, but if I was >porting some hairy old C code I'd tend to expect it to work. >C is not a language in which you go out of your way to prevent >people making mistakes. I would not expect it to work. This has nothing to do with the C language, it has to do with fclose. Fclose gets rid of the descriptor. In my own code, I usually follow 'fclose(fp)' with 'fp = NULL', because that stream is GONE. I do realize that this code does seem to work on several operating systems, but it also causes dramatic problems with linux. Given the description of fclose, I'd say it is the code which is wrong. The "single Unix spec" says: After the call to fclose(), any use of stream causes undefined behavior. FreeBSD's own man page for fclose says: [fclose returns 0 or EOF]. In either case, no further access to the stream is possible. Neither of those indicate that anyone should "expect it to work", no matter what language they are programming in. There is nothing in the description for ferror which implies that it is some magical exception to the above rules. I might grudgingly admit that it would be a shame to increase the overhead of macro-ized 'ferror' calls, and I'm not sure of any good way to avoid that. But I see no reason that this code should be "expected" to work. And if it does not work, then I'd rather it failed right at the call to ferror, and not some indeterminate place later on. (obviously this is the big problem with the implementation of ferror on linux, in that it doesn't fail or die at the ferror call, it dies much much later due to some corrupted data structure). Perhaps it would be helpful to add some sanity checking in the subroutine-ized version of ferror, in libc/lib/stdio/ferror.c ? (although I realize that wouldn't have really helped me at all) Really I should be bugging someone in linux-land about this, as it is their implementation which causes such painfully obscure problems. It's just that I don't see myself as a linux developer... :) Still, I guess I should go bug them now. -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 16:45:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id E3F2337B4C5 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 16:45:44 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13yO2p-000Dgx-00; Wed, 22 Nov 2000 00:45:51 +0000 Date: Wed, 22 Nov 2000 00:45:51 +0000 From: Tony Finch <dot@dotat.at> To: "Pedro F. Giffuni" <pfg1+@pitt.edu> Cc: freebsd-hackers@FreeBSD.org Subject: Re: sfork() ?? Message-ID: <20001122004551.A50272@hand.dotat.at> References: <4162240307.974824849@box022.labs.pitt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4162240307.974824849@box022.labs.pitt.edu> Organization: Covalent Technologies, Inc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Pedro F. Giffuni" <pfg1+@pitt.edu> wrote: > >Can someone knowledgeable comment on what it does, and maybe if it could >(or should) be brought into FreeBSD ? Perhaps you are looking for rfork()? AFAIK Irix calls rfork() sfork(). Tony. -- f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 17:28:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mb2i0.ns.pitt.edu (mb2i0.ns.pitt.edu [136.142.186.36]) by hub.freebsd.org (Postfix) with ESMTP id EBC0F37B4C5 for <freebsd-hackers@FreeBSD.org>; Tue, 21 Nov 2000 17:28:32 -0800 (PST) Received: from unixs1.cis.pitt.edu (pfg1@[136.142.185.31]) by pitt.edu (PMDF V5.2-32 #41462) with SMTP id <01JWTCGOHC8O000B8F@mb2i0.ns.pitt.edu> for freebsd-hackers@FreeBSD.org; Tue, 21 Nov 2000 20:27:06 EST Date: Tue, 21 Nov 2000 20:27:06 -0500 (EST) From: Pedro F Giffuni <pfg1+@pitt.edu> Subject: Re: sfork() ?? In-reply-to: <20001122004551.A50272@hand.dotat.at> X-Sender: pfg1@unixs1.cis.pitt.edu To: Tony Finch <dot@dotat.at> Cc: freebsd-hackers@FreeBSD.org Message-id: <Pine.GSO.3.96L.1001121201011.27588A-100000@unixs1.cis.pitt.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It might be.. rfork comes from plan 9 and along with sfork it wasn't part of the 4.4BSDlite 2 release, OTOH if both are the same, why aren't we referencing it in our syscalls for compatibility with BSDI ? I can't find a reference to sfork elsewhere, but anyone with BSD/OS 2.x or later should know for sure. cheers, Pedro. On Wed, 22 Nov 2000, Tony Finch wrote: > "Pedro F. Giffuni" <pfg1+@pitt.edu> wrote: > > > >Can someone knowledgeable comment on what it does, and maybe if it could > >(or should) be brought into FreeBSD ? > > Perhaps you are looking for rfork()? AFAIK Irix calls rfork() sfork(). > > Tony. > -- > f.a.n.finch dot@dotat.at fanf@covalent.net Chad for President! > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 17:43:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 43BCC37B479; Tue, 21 Nov 2000 17:43:39 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-204.nnj.dialup.bellatlantic.net [151.198.117.204]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA18581; Tue, 21 Nov 2000 20:43:24 -0500 (EST) Message-ID: <3A1B24BB.37D7DF6B@bellatlantic.net> Date: Tue, 21 Nov 2000 20:43:23 -0500 From: Sergey Babkin <babkin@bellatlantic.net> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Roman Shterenzon <roman@xpert.com> Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: truss -f References: <Pine.LNX.4.30.0011201849050.13345-100000@jamus.xpert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Roman Shterenzon wrote: > > Hi, > > Once, someone told me that he had a patch for truss that allows it to > follow children, just like in Solaris (or strace -f in linux). > Does anyone have it? Why don't you use the native ktrace/kdump commands instead ? "ktrace -d" does follow the children. I think truss has only a minimalistic implementation. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 17:46:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 6EA4937B479 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 17:46:15 -0800 (PST) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id eAM1kFh09832 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 18:46:16 -0700 Message-Id: <200011220146.eAM1kFh09832@chopper.Poohsticks.ORG> To: freebsd-hackers@freebsd.org Subject: Interrupt threads MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9828.974857575.1@chopper.Poohsticks.ORG> Date: Tue, 21 Nov 2000 18:46:15 -0700 From: Drew Eckhardt <drew@PoohSticks.ORG> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For reasons beyond my control, I'm stuck using FreeBSD in a real time system and am violating my timing constraints when too many SCSI commands complete in a short time frame and starve one of my userland real time processes. If the interrupt handler wokeup a kernel thread running at a lower real-time priority than my application which disabled the interrupt on the PIC/APIC, ran the handler, and re-enabled the line on the PIC/APIC my problems should go away. -CURRENT supposedly uses threads for interrupts. Is there a more specific description of what it does archived somewhere? Assuming familiarity with the interrupt code and a cursory but improving understanding of the scheduler, how messy would it be to retrofit that code to -stable or 3.1-stable ? -- <a href="http://www.poohsticks.org/drew/">Home Page</a> For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 18:29: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from distortion.dk (distortion.dk [195.249.147.156]) by hub.freebsd.org (Postfix) with ESMTP id 5C28037B4C5 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 18:28:59 -0800 (PST) Received: from petri2000 ([194.192.131.97]) by distortion.dk (8.9.3/8.9.1) with SMTP id DAA39119 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 03:35:20 +0100 (CET) (envelope-from nicolai@petri.cc) Message-ID: <01ad01c0542c$5d4d38d0$6732a8c0@atomic.dk> From: "Nicolai Petri" <nicolai@petri.cc> To: <freebsd-hackers@freebsd.org> Subject: SIGPIPE in multithread http server. Date: Wed, 22 Nov 2000 03:31:48 +0100 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I hope someone can help me with this issue.. When the application recieves a SIGPIPE the thread hangs hard.. What is the correct thing to do when a socket is closed by the remote end ?? The fault happens each time I'll hit reload in my browser while there's still a connection open (while downloading a large page).. It blocks my http server hard... No new connections is accepted.. But other non-socket threads runs nicely in the backgrund.. My current signal-handler looks like this : --------- void ignoreSignal(int signalId _UNUSED_) { closeNwSocket(&newSock); (void)setsignal(SIGPIPE, ignoreSignal); } --------- I'll bet this is very wrong... But what is the correct code for cleaning the session up ?? Best regards, Nicolai Petri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 18:32:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.netsol.net (mail.netsol.net [216.179.148.10]) by hub.freebsd.org (Postfix) with ESMTP id 131FB37B4C5 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 18:32:45 -0800 (PST) Received: from fire ([63.194.3.101]) by mail1.netsol.net (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id net; Tue, 21 Nov 2000 18:37:07 -0800 Message-ID: <008801c0542c$82e1bc60$6503c23f@XGforce.com> Reply-To: "jl" <tech@scsr.com> From: "jl" <tech@scsr.com> To: "Nicolai Petri" <nicolai@petri.cc>, <freebsd-hackers@freebsd.org> References: <01ad01c0542c$5d4d38d0$6732a8c0@atomic.dk> Subject: Re: SIGPIPE in multithread http server. Date: Tue, 21 Nov 2000 18:32:51 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You should have the thread call signal() to ignor the sigpipe signal so the thread won't hang. ====================================== WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. ====================================== ----- Original Message ----- From: Nicolai Petri <nicolai@petri.cc> To: <freebsd-hackers@freebsd.org> Sent: Tuesday, November 21, 2000 6:31 PM Subject: SIGPIPE in multithread http server. > I hope someone can help me with this issue.. > > When the application recieves a SIGPIPE the thread hangs hard.. What is the > correct thing to do when a socket is closed by the remote end ?? > > The fault happens each time I'll hit reload in my browser while there's > still a connection open (while downloading a large page).. It blocks my http > server hard... No new connections is accepted.. But other non-socket threads > runs nicely in the backgrund.. > > My current signal-handler looks like this : > --------- > void ignoreSignal(int signalId _UNUSED_) { > closeNwSocket(&newSock); > (void)setsignal(SIGPIPE, ignoreSignal); > } > --------- > I'll bet this is very wrong... But what is the correct code for cleaning the > session up ?? > > Best regards, > Nicolai Petri > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 19:38:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.illtel.denver.co.us (clw-5-CF5A06-144.wwc.com [207.90.6.144]) by hub.freebsd.org (Postfix) with ESMTP id 906E337B4D7 for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 19:38:21 -0800 (PST) Received: from localhost (abelits@localhost) by mercury.illtel.denver.co.us (8.9.3/8.9.3) with ESMTP id TAA01093; Tue, 21 Nov 2000 19:39:27 -0800 X-Authentication-Warning: mercury.illtel.denver.co.us: abelits owned process doing -bs Date: Tue, 21 Nov 2000 19:39:24 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> X-Sender: abelits@mercury To: Nicolai Petri <nicolai@petri.cc> Cc: freebsd-hackers@freebsd.org Subject: Re: SIGPIPE in multithread http server. In-Reply-To: <01ad01c0542c$5d4d38d0$6732a8c0@atomic.dk> Message-ID: <Pine.LNX.4.10.10011211926560.1035-100000@mercury> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, Nicolai Petri wrote: > I hope someone can help me with this issue.. > > When the application recieves a SIGPIPE the thread hangs hard.. What is the > correct thing to do when a socket is closed by the remote end ?? When application receives SIGPIPE the correct thing to do is nothing unless you have only one socket or pipe in the whole process -- and even then you shouldn't manipulate data used by the rest of program from inside the signal handler -- ignore the signal ot just set some flag from inside the handler. You can use this flag if it helps you to check if there is any socket that just got closed, however real test for closed socket while you are writing in it is failed write()/writev()/send()/... -- whatever you use to send the data to the other end. Of course, you should also check for empty read() result to see if the socket was closed while you was reading the request. When connection is closed on the other end you must close() it, and consider whatever was sent there to be lost. -- Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 20:24: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from meketrex.pix.net (meketrex.pix.net [192.111.45.13]) by hub.freebsd.org (Postfix) with ESMTP id 278D637B4CF for <freebsd-hackers@freebsd.org>; Tue, 21 Nov 2000 20:24:03 -0800 (PST) Received: by meketrex.pix.net id XAA18317; Tue, 21 Nov 2000 23:23:51 -0500 (EST) Message-ID: <20001121232351.B18090@pix.net> Date: Tue, 21 Nov 2000 23:23:51 -0500 From: "Kurt J. Lidl" <lidl@pix.net> To: Tony Finch <dot@dotat.at>, David Miller <dmiller@search.sparks.net> Cc: freebsd-hackers@freebsd.org Subject: Re: UDP limits in dns server? References: <Pine.BSF.4.21.0011192131520.21277-100000@search.sparks.net> <20001121055406.H54653@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <20001121055406.H54653@hand.dotat.at>; from Tony Finch on Tue, Nov 21, 2000 at 05:54:06AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 05:54:06AM +0000, Tony Finch wrote: > >I'm looking up the IP addresses with up to 1500 or so processes each > >taking a list of addresses and running gethostbyaddr() on them. > > That's stupid. Use adns instead. > http://www.chiark.greenend.org.uk/~ian/adns/ That's stupid, use something advanced (and already debugged) built on top of ADNS: http://www.web.us.uu.net/sw/fastresolve/ -Kurt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 20:44: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from meketrex.pix.net (meketrex.pix.net [192.111.45.13]) by hub.freebsd.org (Postfix) with ESMTP id CA72037B479 for <freebsd-hackers@FreeBSD.org>; Tue, 21 Nov 2000 20:44:05 -0800 (PST) Received: by meketrex.pix.net id XAA18702; Tue, 21 Nov 2000 23:44:02 -0500 (EST) Message-ID: <20001121234402.C18090@pix.net> Date: Tue, 21 Nov 2000 23:44:02 -0500 From: "Kurt J. Lidl" <lidl@pix.net> To: Pedro F Giffuni <pfg1+@pitt.edu>, Tony Finch <dot@dotat.at> Cc: freebsd-hackers@FreeBSD.org Subject: Re: sfork() ?? References: <20001122004551.A50272@hand.dotat.at> <Pine.GSO.3.96L.1001121201011.27588A-100000@unixs1.cis.pitt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <Pine.GSO.3.96L.1001121201011.27588A-100000@unixs1.cis.pitt.edu>; from Pedro F Giffuni on Tue, Nov 21, 2000 at 08:27:06PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 08:27:06PM -0500, Pedro F Giffuni wrote: > rfork comes from plan 9 and along with sfork it wasn't part of the > 4.4BSDlite 2 release, OTOH if both are the same, why aren't we referencing > it in our syscalls for compatibility with BSDI ? > > I can't find a reference to sfork elsewhere, but anyone with BSD/OS 2.x > or later should know for sure. sfork(), in the not-quite-released BSD/OS 4.2 has gotten an overhaul, to the point where fork() and vfork() are just sfork() wrappers. I've heard the comment before that sfork() is just the BSD way of pronouncing rfork()! So in the 4.2 release, BSD/OS will finally have a fully variable weight fork() call, which would be suitable for implementing all sorts of lightweight processes, threads and so forth. For those unfamiliar with variable weight fork semantics, bastically, you get to specify which parts of the process space you want to share and which parts you want to have a new version of in the child process. So, you can trivially share data, memory, etc... (Stack, of course, cannot be shared :-) The linux clone() call is something similar to sfork()/vfork(). It has some extra grot pasted onto the side to allow for pid hiding, for the wretched hack of a way to do pthreads support there. Chris Torek has described this in amazing detail in the past, while answering a different question. Look for the message with the Subject line "why fork?" in the following digest message: http://faqchest.dynhost.com/prgm/perlu-l/perl-99/perl-9906/perl-990602/perl99061420_14433.html -Kurt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 21:14: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2D9AB37B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 21:13:59 -0800 (PST) Received: from newsguy.com (p51-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.116]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id OAA07090; Wed, 22 Nov 2000 14:13:33 +0900 (JST) Message-ID: <3A1B5592.89A7BBE2@newsguy.com> Date: Wed, 22 Nov 2000 14:11:46 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Garance A Drosihn <drosih@rpi.edu> Cc: Robert Nordier <rnordier@nordier.com>, hackers@FreeBSD.ORG Subject: Re: fclose vs ferror (from libc/getcap) References: <200011201020.MAA23349@siri.nordier.com> <p04330104b640abfaf13d@[128.113.24.47]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > The "single Unix spec" says: > After the call to fclose(), any use of stream causes > undefined behavior. > > FreeBSD's own man page for fclose says: > [fclose returns 0 or EOF]. In either case, no further > access to the stream is possible. > > Neither of those indicate that anyone should "expect it to > work", no matter what language they are programming in. There > is nothing in the description for ferror which implies that it > is some magical exception to the above rules. Undefined behavior means anything goes. On a standard, it means the behaviour is implementation-defined (which may be undefined or not). And notice that ferror() is not an access to the stream. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@united.bsdconspiracy.net "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 21:34:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id 5459C37B479 for <freebsd-hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 21:34:49 -0800 (PST) Received: (qmail 10802921 invoked from network); 22 Nov 2000 05:34:47 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender <clefevre@cybercable.fr>) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for <reichert@numachi.com>; 22 Nov 2000 05:34:47 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id eAM5Yfv09792; Wed, 22 Nov 2000 06:34:41 +0100 (CET) (envelope-from clefevre@cybercable.fr) Original-Sender: Cyrille Lefevre <root%no-spam@gits.dyndns.org.invalid> Original-Sender: Cyrille Lefevre <root%no-spam@gits.dyndns.org.invalid> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Brian Reichert <reichert@numachi.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: find, -delete, and relative paths References: <XFMail.001121120856.doconnor@gsoft.com.au> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<<r#uCVjK"~Ke!@0vxS/.,wki/c|uVnNV!BA-_gY2sfoGc3 f{#/$PT>97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: "Daniel O'Connor"'s message of "Tue, 21 Nov 2000 12:08:56 +1030 (CST)" From: Cyrille Lefevre <clefevre@cybercable.fr> Reply-To: Cyrille Lefevre <clefevre@cybercable.fr> Mail-Copies-To: never Date: 22 Nov 2000 06:34:40 +0100 Message-ID: <hf50a7tb.fsf@gits.dyndns.org> Lines: 34 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel O'Connor" <doconnor@gsoft.com.au> writes: > On 20-Nov-00 Brian Reichert wrote: > > I didn't find anything after an admittedly quick look intp PRs and the mail > > list archives: > > > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > > > How can I suppress this warning? Is it a bug in find, or did I > > misunderstand the manpage? > > I don't know why, but I think find prints those messages when you attempt to delete > a directory. > > If you do -> > 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete > > it should work.. 15 3 * * * find /usr/local/logs/lsp -depth \! -ctime 1 -delete could be better, deletes file entries before directory ones. PS : -a is not necessary, it's always implied except if -o of course. Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 22: 8:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id E521C37B4C5 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 22:08:24 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA679066; Wed, 22 Nov 2000 01:08:09 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p04330100b641090d2474@[128.113.24.47]> In-Reply-To: <3A1B5592.89A7BBE2@newsguy.com> References: <200011201020.MAA23349@siri.nordier.com> <p04330104b640abfaf13d@[128.113.24.47]> <3A1B5592.89A7BBE2@newsguy.com> Date: Wed, 22 Nov 2000 01:08:06 -0500 To: "Daniel C. Sobral" <dcs@newsguy.com> From: Garance A Drosihn <drosih@rpi.edu> Subject: Re: fclose vs ferror (from libc/getcap) Cc: Robert Nordier <rnordier@nordier.com>, hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:11 PM +0900 11/22/00, Daniel C. Sobral wrote: >Garance A Drosihn wrote: > > > > The "single Unix spec" says: >> After the call to fclose(), any use of stream causes >> undefined behavior. >> >> FreeBSD's own man page for fclose says: >> [fclose returns 0 or EOF]. In either case, no further >> access to the stream is possible. >> >> Neither of those indicate that anyone should "expect it to >> work", no matter what language they are programming in. There >> is nothing in the description for ferror which implies that it >> is some magical exception to the above rules. > >Undefined behavior means anything goes. On a standard, it means the >behaviour is implementation-defined (which may be undefined or not). But if "anything goes", then that you can not expect it to work; certainly not when porting to other platforms. I am not saying that what freebsd does is wrong. But Robert said that "[that code is a silly thing], but if I was porting some hairy old C code I'd tend to expect it to work." It seems to me that if the behavior is explicitly undefined then you can NOT expect much of anything when porting. In any case, I did bug redhat about it (once I found the right web page), as it is the implementation of fclose in glibc which really caused all my headaches. Someone has already replied, at least to change the bug report from libc to glibc. As for freebsd, I do hope to fix the specific code in getcap.c, but I am not suggesting a change to fclose/ferror unless other developers felt this was a problem (and obviously no one seems to :-). I did want to remark on it, in case other people USE the combination of fclose followed by ferror, and then run into mysterious problems when they port their code to other platforms. I certainly did not enjoy tracking this down, and by mentioning it here then maybe I'd save someone else some headaches. > And notice that ferror() is not an access to the stream. In the section I quoted from unix spec, "stream" refers to the variable passed to fclose (though that isn't obvious, because I didn't copy the formatting). ferror certainly does access that variable. -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Nov 21 22:26:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9E0B837B479 for <hackers@FreeBSD.ORG>; Tue, 21 Nov 2000 22:26:48 -0800 (PST) Received: from newsguy.com (p51-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.116]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id PAA26353; Wed, 22 Nov 2000 15:26:23 +0900 (JST) Message-ID: <3A1B66A3.D29C8565@newsguy.com> Date: Wed, 22 Nov 2000 15:24:35 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Garance A Drosihn <drosih@rpi.edu> Cc: Robert Nordier <rnordier@nordier.com>, hackers@FreeBSD.ORG Subject: Re: fclose vs ferror (from libc/getcap) References: <200011201020.MAA23349@siri.nordier.com> <p04330104b640abfaf13d@[128.113.24.47]> <3A1B5592.89A7BBE2@newsguy.com> <p04330100b641090d2474@[128.113.24.47]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > >Undefined behavior means anything goes. On a standard, it means the > >behaviour is implementation-defined (which may be undefined or not). > > But if "anything goes", then that you can not expect it to > work; certainly not when porting to other platforms. Sure enough. The behavior of any function on a closed FILE* is not defined by standards. > I am not saying that what freebsd does is wrong. But Robert > said that "[that code is a silly thing], but if I was porting > some hairy old C code I'd tend to expect it to work." > It seems to me that if the behavior is explicitly undefined > then you can NOT expect much of anything when porting. He said he would _tend_ to expect it to work. To me, that means the code is dubious, but is likely to work. > > And notice that ferror() is not an access to the stream. > > In the section I quoted from unix spec, "stream" refers to the > variable passed to fclose (though that isn't obvious, because I > didn't copy the formatting). ferror certainly does access that > variable. MMmmmm. That's a dubious interpretation. The variable is a handle to the stream, not the stream itself. Are you sure of the SUS wording? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@united.bsdconspiracy.net "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 2:11: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.trident-uk.co.uk (mail.trident-uk.co.uk [195.166.16.10]) by hub.freebsd.org (Postfix) with ESMTP id 7AA1E37B479 for <hackers@freebsd.org>; Wed, 22 Nov 2000 02:10:57 -0800 (PST) Received: from [194.207.93.139] by gate.trident-uk.co.uk for hackers@freebsd.org id KAA21341; Wed Nov 22 10:10:56 2000 Organization: Psi-Domain Ltd. Subject: make installworld Date: Wed, 22 Nov 2000 10:15:28 +0000 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00112210162804.53554@freefire.psi-domain.co.uk> Content-Transfer-Encoding: 8bit To: hackers@freebsd.org From: Jamie Heckford <heckfordj@psi-domain.co.uk> Reply-To: heckfordj@psi-domain.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Encountered the following while running make installworld: Installing /usr/libdata/perl/5.00503/mach/auto/POSIX/setgid.al Installing /usr/libdata/perl/5.00503/mach/auto/POSIX/setuid.al Usage: copy(FROM, TO [, BUFFERSIZE]) at /usr/obj/usr/src/gnu/usr.bin/perl/library/POSIX/lib/ExtUtils/Install.pm line 123 *** Error code 2 Stop in /usr/obj/usr/src/gnu/usr.bin/perl/library/POSIX/ext/POSIX. *** Error code 1 Sucessfully completed make buildworld, any suggestions ppl? Thanks, -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. =================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7779 646 529 =================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 2:14:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 17DE237B4CF; Wed, 22 Nov 2000 02:14:29 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAMAFeY04338; Wed, 22 Nov 2000 02:15:40 -0800 (PST) (envelope-from kris) Date: Wed, 22 Nov 2000 02:15:39 -0800 From: Kris Kennaway <kris@FreeBSD.ORG> To: hackers@FreeBSD.ORG Cc: "Sean O'Connell" <sean@stat.Duke.EDU>, green@FreeBSD.ORG Subject: PAM and passwords (Re: Hmm..passwords.) Message-ID: <20001122021539.C4078@citusc17.usc.edu> References: <20001121135541.A14220@nevermind.kiev.ua> <Pine.BSF.4.21.0011210704230.88234-100000@epsilon.lucida.ca> <20001121082750.A2922@citusc17.usc.edu> <20001121114933.D27266@stat.Duke.EDU> <20001121085551.A3534@citusc17.usc.edu> <20001121153112.B1910@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121153112.B1910@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Tue, Nov 21, 2000 at 03:31:12PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 21, 2000 at 03:31:12PM -0800, David O'Brien wrote: > When Kris and I discussed this functionality (before Brian went and did > it); we talked about much higher granularity than Brian implemented: >=20 > MD5 everywhere > DES everywhere > MD5 locally / DES yp > Convert to MD5 > Convert to DES Only these last two are candidates for PAM. PAM (specifically pam_unix) doesn't and shouldn't care what crypt() does and what the algorithm it chooses to use is called, it just treats the strings as opaque data which are compared to the master.passwd records. The latter two in your list could be implemented by a "recrypt" function in a pam "password" module, which a) verifies the presented password, and b) generates a new password hash with the same plaintext, which is written out. This would have the effect that the new password would be whichever format is the current passwd_format for that user's login class, so you can transparently migrate users from one algorithm to another without having to expire passwords or mess with them by hand. You likely wouldn't want this to happen every time a user logs in, so there'd have to be some other condition which triggers it for a given account. Kris --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjobnMoACgkQWry0BWjoQKVQuQCdF/GfekP7jnciyb6IbfNP3jNr QgUAniDGKk8rmNrKLNNvPTt7gzZXAI8P =2+gg -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 3:27:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 98DF137B4C5 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 03:27:10 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19]) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 13yY3M-00080t-00 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 12:27:04 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 13yY3L-0004L2-00 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 12:27:03 +0100 Date: Wed, 22 Nov 2000 12:27:03 +0100 From: Nicolas Souchu <nsouch@alcove.fr> To: freebsd-hackers@freebsd.org Subject: KGI port Message-ID: <20001122122703.D15916@wiliam.alcove-int> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi hackers, Hope you've ever heard about KGI... the kernel side of the GGI project. It consists mostly in a basic framework for accessing graphic hardware from userland and is designed to support efficiently the GGI upper library. More info is avalable at http://kgi.sourceforge.net I'm willing to port it to FreeBSD. First, any comments? advices? Then, how could I efficiently reuse the existing stuff of FreeBSD (kbd, fb)? What are resistrictions on the license? Most of the code is governed by: ** Copyright (C) 2000 xxxx ** ** This file is distributed under the terms and conditions of the ** MIT/X public license. Please see the file COPYRIGHT.MIT included ** with this software for details of these terms and conditions. ** Alternatively you may distribute this file under the terms and ** conditions of the GNU General Public License. Please see the file ** COPYRIGHT.GPL included with this software for details of these terms ** and conditions. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 5:19:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 4E9EE37B4D7 for <hackers@freebsd.org>; Wed, 22 Nov 2000 05:19:40 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13yZo3-0002UA-00 for hackers@freebsd.org; Wed, 22 Nov 2000 15:19:23 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id PAA03101 for <hackers@freebsd.org>; Wed, 22 Nov 2000 15:19:33 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 2916; Wed Nov 22 15:18:27 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13yZn9-0009h9-00 for hackers@FreeBSD.org; Wed, 22 Nov 2000 15:18:27 +0200 From: Sheldon Hearn <sheldonh@uunet.co.za> To: hackers@freebsd.org Subject: BSD's random.c dicey on the Alpha Date: Wed, 22 Nov 2000 15:18:27 +0200 Message-ID: <37270.974899107@axl.fw.uunet.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Anyone want to have a look at this? It's from the GNU awk maintainer. Ciao, Sheldon. ------- Forwarded Message From: Aharon Robbins <arnold@skeeve.com> Date: Wed, 22 Nov 2000 11:59:10 +0200 Message-ID: <974887150.75c0d57f@skeeve.com> To: sheldonh@uunet.co.za Subject: BSD random for Alpha? Cc: bostic@bostic.com, michal@phys.ualberta.ca Hi. I've switched to the new random.c you sent me for gawk. My Linux/Alpha Guru reports that the code in it assumes that sizeof(long) is always 4, and one particular test doesn't "look" very random on the Alpha. My question is, is there a better version of random that can deal with both 32 and 64 bit systems in the same source code? Would the NetBSD people maybe have such a thing? Thanks, Arnold - -- Aharon (Arnold) Robbins --- Pioneer Consulting Ltd. arnold@skeeve.com P.O. Box 354 Home Phone: +972 8 979-0381 Fax: +1 603 761-6761 Nof Ayalon Cell Phone: +972 51 297-545 (See www.efax.com) D.N. Shimshon 99785 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 6:33: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from siri.nordier.com (c3-dbn-54.dial-up.net [196.33.200.54]) by hub.freebsd.org (Postfix) with ESMTP id 9909937B4CF for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 06:32:53 -0800 (PST) Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id QAA05038; Wed, 22 Nov 2000 16:33:55 +0200 (SAST) From: Robert Nordier <rnordier@nordier.com> Message-Id: <200011221433.QAA05038@siri.nordier.com> Subject: Re: fclose vs ferror (from libc/getcap) To: drosih@rpi.edu (Garance A Drosihn) Date: Wed, 22 Nov 2000 16:33:55 +0200 (SAST) Cc: hackers@FreeBSD.ORG In-Reply-To: <p04330104b640abfaf13d@[128.113.24.47]> from "Garance A Drosihn" at Nov 21, 2000 07:36:39 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > >The point about > > > > (void)fclose(pfp); > > if (ferror(pfp)) { > > ...do stuff... > > } > > > >is that it's a silly thing to do deliberately, but if I was > >porting some hairy old C code I'd tend to expect it to work. > >C is not a language in which you go out of your way to prevent > >people making mistakes. > > I would not expect it to work. This has nothing to do with > the C language, it has to do with fclose. Fclose gets rid > of the descriptor. In my own code, I usually follow 'fclose(fp)' > with 'fp = NULL', because that stream is GONE. I do realize that > this code does seem to work on several operating systems, but it > also causes dramatic problems with linux. Given the description > of fclose, I'd say it is the code which is wrong. This has to do with the C language at least in the sense that the standard library is a part of C. About half the bulk of the original ANSI/ISO C Standard is taken up with specifying the library. I don't think I really disagree with the points you make, mostly not quoted; but I also think the fundamental issue is that you're not entirely in sympathy with the C way of doing things, and that you'd prefer to be using something else. (Someone who does the fp = NULL thing is quite likely deep-down a Modula-3 guy, or an Oberon guy, or an Ada guy, or something. :-) The _Rationale_, which was put out by the original ANSI committee somewhat in defence of the C Standard itself, talks about sticking to "the spirit of C". And the first of the tenets it mentions is "Trust the programmer". It's probably fair to say that the lack of sanity-checking in the routines of the standard library is one example of that kind of trust. Though whether it is sensible to trust the programmer not to make silly mistakes is a different matter altogether, of course. -- Robert Nordier rnordier@nordier.com rnordier@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 6:33:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from siri.nordier.com (c3-dbn-54.dial-up.net [196.33.200.54]) by hub.freebsd.org (Postfix) with ESMTP id B85D437B4CF for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 06:33:42 -0800 (PST) Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id OAA04292; Wed, 22 Nov 2000 14:25:34 +0200 (SAST) From: Robert Nordier <rnordier@nordier.com> Message-Id: <200011221225.OAA04292@siri.nordier.com> Subject: Re: fclose vs ferror (from libc/getcap) To: dcs@newsguy.com (Daniel C. Sobral) Date: Wed, 22 Nov 2000 14:25:34 +0200 (SAST) Cc: drosih@rpi.edu (Garance A Drosihn), hackers@FreeBSD.ORG In-Reply-To: <3A1B66A3.D29C8565@newsguy.com> from "Daniel C. Sobral" at Nov 22, 2000 03:24:35 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel C. Sobral wrote: > Garance A Drosihn wrote: > > > > >Undefined behavior means anything goes. On a standard, it means the > > >behaviour is implementation-defined (which may be undefined or not). While not disagreeing with what I think Daniel means: at least in the C Standard itself, "undefined behavior" and "implementation-defined behavior" are kept carefully separate. A quote from X3J11's Rationale document probably addresses the crux of the issue Garance raised, though: Undefined behavior gives the implementor license not to catch certain program errors > > I am not saying that what freebsd does is wrong. But Robert > > said that "[that code is a silly thing], but if I was porting > > some hairy old C code I'd tend to expect it to work." > > > It seems to me that if the behavior is explicitly undefined > > then you can NOT expect much of anything when porting. > > He said he would _tend_ to expect it to work. To me, that means the code > is dubious, but is likely to work. Garance himself writes, two messages back: The thing with ferror is that it will generally "work" after the fclose, although the value it returns might not be the right (pre-close) value. and I really meant something very similar. Though I'd probably go a bit further and say -- knowing how ferror is likely to be implemented -- the most probable result of invoking it after fclose would be a failure to detect that an I/O error had occurred. For "hairy old C code", that "works" about as much as I'd expect it to. > > > And notice that ferror() is not an access to the stream. > > > > In the section I quoted from unix spec, "stream" refers to the > > variable passed to fclose (though that isn't obvious, because I > > didn't copy the formatting). ferror certainly does access that > > variable. > > MMmmmm. That's a dubious interpretation. The variable is a handle to the > stream, not the stream itself. Are you sure of the SUS wording? The original ISO standard defines "FILE" as an object capable of recording all the information needed to control a stream [7.9.1] and elsewhere goes on to describe a stream as, for example an ordered sequence of characters [7.9.2] so I think it's fairly clear that a stream is not what (FILE *) points at. I doubt that the SUS would intentionally deviate on such a fundamental point. -- Robert Nordier rnordier@nordier.com rnordier@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 6:46:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 7ACF537B4D7 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 06:46:35 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19]) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 13ybA0-0001o7-00; Wed, 22 Nov 2000 15:46:08 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 13yb9z-0004YA-00; Wed, 22 Nov 2000 15:46:07 +0100 Date: Wed, 22 Nov 2000 15:46:06 +0100 From: Nicolas Souchu <nsouch@alcove.fr> To: Felipe Gustavo de Almeida <galmeida@linux.ime.usp.br> Cc: freebsd-hackers@freebsd.org Subject: Re: SMBus Message-ID: <20001122154606.A17461@wiliam.alcove-int> References: <20001118143148.A53654@linux.ime.usp.br> <20001120085916.A4055@wiliam.alcove-int> <20001120203853.B1459@linux.ime.usp.br> <20001121104417.D12884@wiliam.alcove-int> <20001121200542.C461@linux.ime.usp.br> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <20001121200542.C461@linux.ime.usp.br>; from galmeida@linux.ime.usp.br on Tue, Nov 21, 2000 at 08:05:42PM -0200 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 08:05:42PM -0200, Felipe Gustavo de Almeida wrote: > > thanks for your 'support' ! > > Nicolas Souchu writes: > > On Mon, Nov 20, 2000 at 08:38:53PM -0200, Felipe Gustavo de Almeida wrote: > > > Nicolas Souchu writes: > > > > On Sat, Nov 18, 2000 at 02:31:48PM -0200, Felipe Gustavo de Almeida wrote: > > > > > Hi, > > > > > do you know about someone working on smbus drivers for > > > > > VIA VT82C686A (the chipset from ASUS K7V MB) ? > > > > > > > > To bad. I did the driver in the past, but as a very bad programmer did not > > > > do any backup :(( > > > > Actually it was for the 586B chip :( For which the datasheets are fully > > available. > > > > > > > > > > What do you plan to do with it? I could try out another devel if needed. > > > I was digging driver sources and I think what I really want is a kind > > > of 'intpm' to K7V, ie. a driver to let me get my mobo health data. > > > As far as I could see in the NetBSD driver, the only supported feature is hardware monitoring feature not SMBUS yet. You may ask ACPI specialists on the hackers list for more info on the subject. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 8:19:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mb2i0.ns.pitt.edu (mb2i0.ns.pitt.edu [136.142.186.36]) by hub.freebsd.org (Postfix) with ESMTP id 6DE1237B479 for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 08:19:28 -0800 (PST) Received: from unixs1.cis.pitt.edu (pfg1@[136.142.185.31]) by pitt.edu (PMDF V5.2-32 #41462) with SMTP id <01JWU7LNJEF0000CYA@mb2i0.ns.pitt.edu> for freebsd-hackers@FreeBSD.ORG; Wed, 22 Nov 2000 11:19:08 EST Date: Wed, 22 Nov 2000 11:19:06 -0500 (EST) From: Pedro F Giffuni <pfg1+@pitt.edu> Subject: Re: KGI port In-reply-to: <20001122122703.D15916@wiliam.alcove-int> X-Sender: pfg1@unixs1.cis.pitt.edu To: Nicolas Souchu <nsouch@alcove.fr> Cc: freebsd-hackers@FreeBSD.ORG Message-id: <Pine.GSO.3.96L.1001122111059.11628B-100000@unixs1.cis.pitt.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good ! I recall the kernel related parts can be licensed under a plain (new) BSD license. I don't understand our fb enough but if you know your way through kld's and newbus, the result will be really neat. =09Pedro. On Wed, 22 Nov 2000, Nicolas Souchu wrote: > Hi hackers, >=20 > Hope you've ever heard about KGI... the kernel side of the GGI project. I= t consists > mostly in a basic framework for accessing graphic hardware from userland = and is designed > to support efficiently the GGI upper library. More info is avalable at > http://kgi.sourceforge.net >=20 > I'm willing to port it to FreeBSD. >=20 > First, any comments? advices? >=20 > Then, how could I efficiently reuse the existing stuff of FreeBSD (kbd, f= b)? >=20 > What are resistrictions on the license? Most of the code is governed by: >=20 > ** Copyright (C) 2000 xxxx > ** > ** This file is distributed under the terms and conditions of the=20 > ** MIT/X public license. Please see the file COPYRIGHT.MIT included > ** with this software for details of these terms and conditions. > ** Alternatively you may distribute this file under the terms and > ** conditions of the GNU General Public License. Please see the file= =20 > ** COPYRIGHT.GPL included with this software for details of these te= rms > ** and conditions. >=20 > Nicholas >=20 > --=20 > Nicolas Souchu > Alc=F4ve - Open Source Software Engineer - http://www.alcove.fr >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:31: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 3991C37B4CF for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 09:30:53 -0800 (PST) Received: from sv.Go2France.com (sv.meiway.com [212.73.210.79]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 2FCF76A909 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 18:30:48 +0100 (CET) Message-Id: <5.0.2.1.0.20001122183002.023debf0@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 22 Nov 2000 18:30:11 +0100 To: freebsd-hackers@freebsd.org From: Len Conrad <lconrad@Go2France.com> Subject: Fwd: Re: still in the woods (tuning for postfix hub) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, Hackers, .... but I got no response from the -questions list for 2 days. Somebody here must know who is Mr. Hub Admin, no? tia, Len ============================================== Can somebody tell me who admins FreeBSD/postifx mail hubs? I need some help opening up FreeBSD for postfix and 200K msgs/day. Thanks, Len ================================== >Delivered-To: postfix-users-outgoing@cloud9.net >Delivered-To: postfix-users@cloud9.net >Subject: Re: still in the woods >To: postfix-users@postfix.org (Postfix users) >Reply-To: postfix-users@postfix.org (Postfix users) >X-Time-Zone: USA EST, 6 hours behind central European time >Date: Tue, 21 Nov 2000 16:31:50 -0500 (EST) >From: wietse@porcupine.org (Wietse Venema) >Sender: owner-postfix-users@postfix.org >X-RCPT-TO: <lconrad@Go2France.com> > >The FreeBSD mailing list server runs 500+ Postfix SMTP clients and >it does not hurt the machine. > >Perhaps you need to ask the people who run that machine. > > Wietse > >Len Conrad: > > Got a faily busy postfix relay hub, about 200K msgs / day. > > > > FreeBSD IMGate1.xxx.net 4.1.1-RELEASE FreeBSD 4.1.1-RELEASE #0: Tue > > Sep 26 00:46:59 GMT 2000 > > > > # postconf mail_version > > mail_version = Snapshot-20001030 > > > > ast pid: 67847; load > > averages: 0.19, 0.37, 0.47 > > up 7+00:47:48 16:07:03 > > 320 processes: 1 running, 319 sleeping > > CPU states: 3.5% user, 0.0% nice, 3.8% system, 0.8% > interrupt, 91.9% idle > > Mem: 78M Active, 103M Inact, 29M Wired, 6524K Cache, 35M Buf, 32M Free > > Swap: 47M Total, 1464K Used, 46M Free, 3% Inuse > > > > We had these "too many files" pb's are initial install, and the > > FreeBSD-hackers gave me some things to change that seem to stop the > > but they're back even with these settings( an rebootin): > > > > /boot/rc.loader with > > > > set kern.ipc.maxsockets=4000 (from default of 1000, I think) > > > > and > > > > /etc/sysctl.conf with > > > > kern.maxfiles = 4096 > > kern.maxfilesperproc = 4096 > > > > A section of "sysctl -a" shows: > > > > ITEM SIZE LIMIT USED FREE REQUESTS > > > > PIPE: 160, 0, 2, 100, 63091 > > unpcb: 64, 0, 6, 122, 607 > > ripcb: 96, 1064, 0, 84, 68 > > tcpcb: 288, 1064, 10, 32, 2428 > > udpcb: 96, 1064, 11, 73, 2637 > > unpcb: 64, 0, 0, 0, 0 > > socket: 160, 1064, 27, 48, 5752 > > AIOLIO: 704, 0, 0, 0, 0 > > AIOL: 64, 0, 0, 0, 0 > > AIOCB: 128, 0, 0, 0, 0 > > AIOP: 32, 0, 0, 0, 0 > > AIO: 96, 0, 0, 0, 0 > > NFSNODE: 288, 0, 0, 0, 0 > > NFSMOUNT: 544, 0, 0, 0, 0 > > VNODE: 192, 0, 3801, 121, 3764 > > NAMEI: 1024, 0, 0, 24, 3391019 > > VMSPACE: 192, 0, 20, 44, 50568 > > PROC: 352, 0, 23, 35, 50571 > > DP fakepg: 64, 0, 0, 0, 0 > > PV ENTRY: 28, 139130, 3868, 12497, 7249523 > > MAP ENTRY: 40, 0, 351, 491, 802213 > > KMAP ENTRY: 40, 3996, 61, 169, 13057 > > MAP: 100, 0, 7, 3, 7 > > VM OBJECT: 124, 0, 532, 2133, 604523 > > > > > > But the client is still getting these: > > > > Fatal Errors > > ------------ > > bounce > > 1 open file defer 63A8B51811: Too many open files in system > > 1 open file defer 954FF516E4: Too many open files in system > > 1 open file defer 21333516EF: Too many open files in system > > 1 open file defer B7675516C8: Too many open files in system > > 1 open file defer B6A3E51605: Too many open files in system > > 1 open file defer 33E0B518AE: Too many open files in system > > 1 open file defer 9521D51766: Too many open files in system > > 1 open file defer 6848A5171E: Too many open files in system > > 1 open file defer B5B285178E: Too many open files in system > > 1 open file defer 300B45164D: Too many open files in system > > 1 open file defer 624495172D: Too many open files in system > > 1 open file defer B18F351765: Too many open files in system > > 1 open file defer B2688516B4: Too many open files in system > > 1 open file defer 2717951750: Too many open files in system > > cleanup > > 26 accept connection: Too many open files in system > > qmgr > > 10 socket: Too many open files in system > > 1 open active 7123851A0C: Too many open files in system > > 1 open active 2B05B517B4: Too many open files in system > > 1 open active 495C551796: Too many open files in system > > 1 open active 79A17517F8: Too many open files in system > > 1 open active 6690651964: Too many open files in system > > 1 open active 983CE516F1: Too many open files in system > > 1 open active D61D65181E: Too many open files in system > > smtp > > 8 accept connection: Too many open files in system > > 4 unknown service: smtp/tcp > > 2 open /etc/postfix/main.cf: Too many open files in system > > 1 unknown user: postfix > > 1 unknown default_privs configuration parameter value: nobody > > 1 open active 8817E51660: Too many open files in system > > 1 inet_addr_local: socket: Too many open files in system > > smtpd > > 93 accept connection: Too many open files in system > > 9 socket: Too many open files in system > > 1 watchdog timeout > > trivial-rewrite > > 1 accept connection: Too many open files in system > > > > > > Any body know how I can systcl or other re-param my way out of this, > > without a new kernal (he didn't install kernal sources, against my request) > > > > tia, > > Len http://BIND8NT.MEIway.com : ISC BIND 8.2.2 p5 & 8.2.3 T6B for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:36: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mmap.nyct.net (mmap.nyct.net [216.44.109.243]) by hub.freebsd.org (Postfix) with ESMTP id 7EC7437B479 for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 09:36:02 -0800 (PST) Received: by mmap.nyct.net (Postfix, from userid 1000) id 21AC8F86A; Wed, 22 Nov 2000 12:34:26 -0500 (EST) Date: Wed, 22 Nov 2000 12:34:26 -0500 To: "Kurt J. Lidl" <lidl@pix.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: sfork() ?? Message-ID: <20001122123425.B10356@mmap.nyct.net> References: <20001122004551.A50272@hand.dotat.at> <Pine.GSO.3.96L.1001121201011.27588A-100000@unixs1.cis.pitt.edu> <20001121234402.C18090@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001121234402.C18090@pix.net>; from lidl@pix.net on Tue, Nov 21, 2000 at 11:44:02PM -0500 From: mbac@mmap.nyct.net (Michael Bacarella) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 11:44:02PM -0500, Kurt J. Lidl wrote: > The linux clone() call is something similar to sfork()/vfork(). > It has some extra grot pasted onto the side to allow for pid hiding, > for the wretched hack of a way to do pthreads support there. In all fairness, every single pthreads implementation I've seen has been a total hack. Additionally, every substantial software package I've come across that uses "lightweight processes" does it in some unique way that is always plagued with one system's particular idiosyncracies. I'm sure that someone out there swears by threads and kicks butt with them and has no problems whatsoever, but they put me through too much trouble to ever be worth it. I've reached the point where I re-evaluate my design if I ever find myself saying "..and then I can spawn a thread to.." -- Michael Bacarella <mbac@mmap.nyct.net> ;finger address for public key GPG Key Fingerprint: B4E4 82F5 BCAC AB83 E6F7 B5AA 933E 2A75 79A4 A9C1 Technical Staff / New York Connect Net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:36:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8FD5637B479 for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 09:36:27 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAMHaBK13156; Wed, 22 Nov 2000 09:36:11 -0800 (PST) (envelope-from dillon) Date: Wed, 22 Nov 2000 09:36:11 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> Message-Id: <200011221736.eAMHaBK13156@earth.backplane.com> To: Robert Nordier <rnordier@nordier.com> Cc: dcs@newsguy.com (Daniel C. Sobral), drosih@rpi.edu (Garance A Drosihn), hackers@FreeBSD.ORG Subject: Re: fclose vs ferror (from libc/getcap) References: <200011221225.OAA04292@siri.nordier.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When you look at the fclose()/ferror() problem you have to look at it in its historical context. Historically some versions of UNIX had very odd semantics. For example, many programmers depended on free()'d data being left intact at least until the next free(). It was even documented to have that behavior at one time (though I forget where, this was a long time ago). Similarly, close() didn't always return an integer... it used to be a void function on many systems, or return garbage (i.e. be mis-implemented) and thus undependable. And fclose() also used to be a void function on many systems or have an undependable return value. Enough confusion occured from these differences that some programmers often took liberties way back then that are obivously illegal today.. for example, calling ferror() after fclose() (because fclose() didn't used to return the final flush status), rather then using the more portable fflush/ferror/fclose combination. Another example is freopen()ing an fclose()'d file, especially in regards to stdin, stdout, and stderr. This confusion is further exasperated by shortcuts taken inside libc itself... for example, libc declares stdin, stdout and stderr as static structures and the exit code just assumes those pointers point to good memory, even if the streams have been closed. Many programmers use library code as a basis for learning the APIs and mistakenly come to believe that they can make similar assumptions externally that the library makes internally. In today's world the standard is: When you free() something, that's it.. it's gone. When you fclose() something or otherwise terminate a structure, it's gone. Anything else is illegal. *internally* our libc assumes that ferror() is legal after an fclose() because, well, it's true... but only for internal library functions. Nobody outside the library can legally make that assumption and it could also be argued that even within the library those types of assumptions should not be made unless absolutely necessary. There isn't much we can do about the issue except fix the instances of mis-programming as they show up. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:39:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id B124737B479 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 09:39:41 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JWUMZTVUE800143E@research.kpn.com> for freebsd-hackers@freebsd.org; Wed, 22 Nov 2000 18:39:40 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id <XGRLLJW1>; Wed, 22 Nov 2000 18:39:39 +0100 Content-return: allowed Date: Wed, 22 Nov 2000 18:39:38 +0100 From: "Koster, K.J." <K.J.Koster@kpn.com> Subject: RE: sfork() ?? To: "'mbac@mmap.nyct.net'" <mbac@mmap.nyct.net> Cc: 'FreeBSD Hackers mailing list' <freebsd-hackers@freebsd.org> Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7A44@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've reached the point where I re-evaluate my design if I ever find > myself saying "..and then I can spawn a thread to.." > There is a Javathreads implementation I have never worked with threads in C++, but in Java it's almost trivial to use threads. Too easy, perhaps. Anyway, the people at OOC have created a C++ wrapper that should allow you to do Java-style threads in C++. Never used it myself, but perhaps it's of use to you. Have a look and http://www.ooc.com/jtc/ Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:41:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (Postfix) with SMTP id 02ECF37B4C5 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 09:41:13 -0800 (PST) Received: (qmail 23128 invoked by uid 3001); 22 Nov 2000 17:41:11 -0000 Received: from natto.numachi.com (198.175.254.216) by numachi.numachi.com with SMTP; 22 Nov 2000 17:41:11 -0000 Received: (qmail 35847 invoked by uid 1001); 22 Nov 2000 17:41:11 -0000 Date: Wed, 22 Nov 2000 12:41:11 -0500 From: Brian Reichert <reichert@numachi.com> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: Brian Reichert <reichert@numachi.com>, freebsd-hackers@freebsd.org Subject: Re: find, -delete, and relative paths Message-ID: <20001122124111.A35725@numachi.com> References: <20001120161557.R11172@numachi.com> <XFMail.001121120856.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <XFMail.001121120856.doconnor@gsoft.com.au>; from doconnor@gsoft.com.au on Tue, Nov 21, 2000 at 12:08:56PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 12:08:56PM +1030, Daniel O'Connor wrote: > > On 20-Nov-00 Brian Reichert wrote: > > I didn't find anything after an admittedly quick look intp PRs and the mail > > list archives: > > > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > > > How can I suppress this warning? Is it a bug in find, or did I > > misunderstand the manpage? > > I don't know why, but I think find prints those messages when you attempt to delete > a directory. > > If you do -> > 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete > > it should work.. To wrap up, the above suggestion does shush up 'find' WRT absolute vs. realtive pathnames, at least in my case... > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum -- Brian 'you Bastard' Reichert <reichert@numachi.com> 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:42:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 60DF837B4C5 for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 09:42:15 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id MAA585902; Wed, 22 Nov 2000 12:41:58 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p04330104b641ac979244@[128.113.24.47]> In-Reply-To: <200011221225.OAA04292@siri.nordier.com> References: <200011221225.OAA04292@siri.nordier.com> Date: Wed, 22 Nov 2000 12:41:56 -0500 To: Robert Nordier <rnordier@nordier.com>, dcs@newsguy.com (Daniel C. Sobral) From: Garance A Drosihn <drosih@rpi.edu> Subject: Re: fclose vs ferror (from libc/getcap) Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:25 PM +0200 11/22/00, Robert Nordier wrote: >Daniel C. Sobral wrote: > > > Garance A Drosihn wrote: > > > In the section I quoted from unix spec, "stream" refers to the >> > variable passed to fclose (though that isn't obvious, because I >> > didn't copy the formatting). ferror certainly does access that >> > variable. >> > > MMmmmm. That's a dubious interpretation. The variable is a handle > > to the stream, not the stream itself. Are you sure of the SUS > > wording? > >The original ISO standard defines "FILE" as > > an object capable of recording all the information needed to > control a stream [7.9.1] > > [...skipping...] > >I doubt that the SUS would intentionally deviate on such a >fundamental point. I've replied to both Robert and Daniel with (I think) the exact section of SUS that I was quoting. I didn't want to send a message with all those formatting characters to the mailing list, because I really don't know how well that would work out... For others who might be curious, I was not saying that "the concept of a stream" refers to the variable sent to fclose. I meant that in the exact section I was quoting, that word 'stream' is in italics, and thus it refers to the variable 'stream' which SUS used in the synopsis of fclose. Eg: #include <stdio.h> int fclose(FILE *stream); ------ (the underlined 'stream' was written in italics), and: After the call to fclose(), any use of stream ------ ------ causes undefined behaviour. (where both fclose and stream are in italics in the section I was quoting from). Their description for fclose does also use the phrase 'a stream' (with no italics) in the same way everyone else has been using it. - - - - - - Also for the curious, here is the "resolution" of my bug report as it was sent to redhat: + libc is allowed to start nethack, format your disks, + whatever it wants in this case. + + The fact that it magically works on some other system + means nothing, the results of such operation are undefined. + glibc in ferror has to acquire lock of the stream in + question first (thus writes into memory). Perhaps other + systems either don't care about multiple threads (and do + no locking) or slow each operation down (by checking + if the file descriptor is valid at the start of every + single routine). + + You can turn some of such checks by recompiling glibc + with IO_DEBUG, but as such checks just catch some cases + and can pass even on invalid FILE descriptors and also + slow things down, they are not enabled by default. + + So think about ferror on fclosed FILE as if you put + random garbage into that memory area yourself. It is interesting that they talk about acquiring a lock for the stream in question first. As freebsd does more with SMP and threads, will freebsd need to do similar locking? They are also trumpeting the fact that the behavior in this case is "undefined", and thus they feel there is no problem with the fact that the call to ferror trashes random locations in memory and will trigger very obscure bugs which are no where near the "real bug" (ie, the ferror). All very well. Everyone gets to use the term "undefined behavior" to justify that no changes should be made to there version fclose or ferror. All I'm saying is that this leaves the person porting "hairy old C code" in a mighty unpleasant position. This fclose/ferror combination is a fairly easy mistake to miss (particularly since it does work on freebsd), but it might be lethal on other platforms. And if it is lethal, you will get no sympathy once you do track it down. Here I lost 30 hours tracking down a bug in code I did not write in the first place, and everyone's attitude seems to be that it's my fault for wanting to port some C code to multiple platforms. So, for those hackers who do port C code, put this combination on the list of things you should lookout for. -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 9:56:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id 753E237B695 for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 09:56:26 -0800 (PST) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id UAA14466; Wed, 22 Nov 2000 20:54:48 +0300 (MSK) Message-Id: <200011221754.UAA14466@aaz.links.ru> Subject: Re: find, -delete, and relative paths In-Reply-To: <hf50a7tb.fsf@gits.dyndns.org> from "Cyrille Lefevre" at "Nov 22, 0 06:34:40 am" To: clefevre@cybercable.fr Date: Wed, 22 Nov 2000 20:54:48 +0300 (MSK) Cc: doconnor@gsoft.com.au, reichert@numachi.com, freebsd-hackers@FreeBSD.ORG From: "Aleksandr A.Babaylov" <babolo@links.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cyrille Lefevre writes: > "Daniel O'Connor" <doconnor@gsoft.com.au> writes: > > On 20-Nov-00 Brian Reichert wrote: > > > I didn't find anything after an admittedly quick look intp PRs and the mail > > > list archives: > > > > > > Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: > > > > > > 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete > > > > > > I pointedly am using an absolute path, yes I get this warning repeatedly: > > > > > > find: -delete: /usr/local/logs/lsp: relative path potentially not safe > > > > > > How can I suppress this warning? Is it a bug in find, or did I > > > misunderstand the manpage? > > > > I don't know why, but I think find prints those messages when you attempt to delete > > a directory. > > > > If you do -> > > 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete > > > > it should work.. > > 15 3 * * * find /usr/local/logs/lsp -depth \! -ctime 1 -delete > > could be better, deletes file entries before directory ones. > > PS : -a is not necessary, it's always implied except if -o of course. Look at ports/sysutils/deleted daemon that deletes old files, directories and other -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 10:39:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 9252B37B479 for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 10:39:30 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA604312; Wed, 22 Nov 2000 13:39:17 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p04330108b641c13d6c49@[128.113.24.47]> In-Reply-To: <200011221736.eAMHaBK13156@earth.backplane.com> References: <200011221225.OAA04292@siri.nordier.com> <200011221736.eAMHaBK13156@earth.backplane.com> Date: Wed, 22 Nov 2000 13:39:15 -0500 To: Matt Dillon <dillon@earth.backplane.com>, Robert Nordier <rnordier@nordier.com> From: Garance A Drosihn <drosih@rpi.edu> Subject: Re: fclose vs ferror (from libc/getcap) Cc: dcs@newsguy.com (Daniel C. Sobral), hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:36 AM -0800 11/22/00, Matt Dillon wrote: > [...] When you fclose() something or otherwise terminate a > structure, it's gone. Anything else is illegal. *internally* > our libc assumes that ferror() is legal after an fclose() > because, well, it's true... but only for internal library > functions. Nobody outside the library can legally make that > assumption and it could also be argued that even within the > library those types of assumptions should not be made unless > absolutely necessary. Hmm. That does bring up an important point. The code with the fclose/ferror combination *is* something I was taking directly out of libc. So, it would have more right than most code to make explicit assumptions about the implementation of other libc routines. I had not thought of it in that way, mainly because I pulled it out of libc at least five years ago, and it didn't cause me any trouble until this month. > There isn't much we can do about the issue except fix the > instances of mis-programming as they show up. Yep. Oh well. On to the next tempest, please pass the tea. -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 12: 6:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2BE9137B4C5 for <freebsd-hackers@FreeBSD.org>; Wed, 22 Nov 2000 12:06:43 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMK6U045303; Wed, 22 Nov 2000 12:06:30 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: <XFMail.001122120641.jhb@FreeBSD.org> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011220146.eAM1kFh09832@chopper.Poohsticks.ORG> Date: Wed, 22 Nov 2000 12:06:41 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Drew Eckhardt <drew@PoohSticks.ORG> Subject: RE: Interrupt threads Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Drew Eckhardt wrote: > For reasons beyond my control, I'm stuck using FreeBSD in a real time > system and am violating my timing constraints when too many SCSI commands > complete in a short time frame and starve one of my userland real time > processes. > > If the interrupt handler wokeup a kernel thread running at a lower > real-time priority than my application which disabled the interrupt > on the PIC/APIC, ran the handler, and re-enabled the line on the > PIC/APIC my problems should go away. > > -CURRENT supposedly uses threads for interrupts. Is there a more specific > description of what it does archived somewhere? Assuming familiarity > with the interrupt code and a cursory but improving understanding of the > scheduler, how messy would it be to retrofit that code to -stable or > 3.1-stable ? There's no good description of what it does, no. :( Basically, it does do what you ask. You could make a given thread interrupt driven by registering a kernel thread using kthread_create() kind of like inthand_add() in -CURRENT does (though you will need to use a different priority for it). Have that kthread run your interrupt handler using something similar to ithd_loop() in i386/isa/ithread.c. Then, when you register an interrupt handler, have the function it calls basically do the equivalent of sched_ithd() in ithread.c. Instead of using the sched_lock to protect the runqueue, use splhigh() instead. Doing this wouldn't involve any changes to the existing assembly code. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 12:35:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.sereb.net (ip51-16.dialup.wplus.net [195.131.51.16]) by hub.freebsd.org (Postfix) with ESMTP id EF6B237B4C5 for <freebsd-hackers@FreeBSD.org>; Wed, 22 Nov 2000 12:35:12 -0800 (PST) Received: from lev.sereb.net (lev.sereb.net [192.168.1.1]) by freebsd.sereb.net (8.9.3/8.9.3) with ESMTP id XAA36920 for <freebsd-hackers@FreeBSD.org>; Wed, 22 Nov 2000 23:32:54 +0300 (MSK) (envelope-from lev@serebryakov.spb.ru) Date: Wed, 22 Nov 2000 23:34:04 +0300 From: Lev Serebryakov <lev@serebryakov.spb.ru> X-Mailer: The Bat! (v1.47 Halloween Edition) Personal Reply-To: Lev Serebryakov <lev@serebryakov.spb.ru> X-Priority: 3 (Normal) Message-ID: <18987629344.20001122233404@serebryakov.spb.ru> To: All <freebsd-hackers@FreeBSD.org> Subject: HDD crashes, S.M.A.R.T and relocation tables. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, All! How are you? Now here is no `bad144' utility. Everybody say ``modern HDDs could do hardware remaps of bad blocks, and if here is visible bad blocks, it means HDD will die soon, so buy new HDD ASAP and throw bad one away''. Ok. I agree with it. IDE HDDs are cheap now, and information is expensive. But here is one problem: sometimes ASAP means two days or even two weeks (especially, in Russia). Sometimes we need wait salary, need bank transfer from firm to shop or something like this. But HERE IS BAD SECTORS RIGHT NOW! We understand, we need to buy new HDD when we see ``hard read error''! And we need to live with bad HDD for days! I see god solution: monitor HDD health by downloading relocation table and S.M.A.R.T. information from it daily (in cron job). When script detect, that relocation table is near to be full or here is 1000 new relocations in one day, it sends mail to root, and we have some time to buy new HDD. But I could not find any utility for FreeBSD, which could get S.M.A.R.T. information and relocation table from HDD... So, we need such utility. Does anybody know -- is such utility exists? Lev Serebryakov /-----------------------------------------------\ | FIDONet: 2:5030/661.0 | | E-Mail: lev@serebryakov.spb.ru | | Page: http://lev.serebyrakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===============================================/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 12:39:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 6C88137B4CF for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 12:39:15 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id VAA06261; Wed, 22 Nov 2000 21:39:13 +0100 (CET) (envelope-from sos) From: Soren Schmidt <sos@freebsd.dk> Message-Id: <200011222039.VAA06261@freebsd.dk> Subject: Re: HDD crashes, S.M.A.R.T and relocation tables. In-Reply-To: <18987629344.20001122233404@serebryakov.spb.ru> from Lev Serebryakov at "Nov 22, 2000 11:34:04 pm" To: lev@serebryakov.spb.ru (Lev Serebryakov) Date: Wed, 22 Nov 2000 21:39:12 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG (All) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Lev Serebryakov wrote: > I see god solution: monitor HDD health by downloading relocation > table and S.M.A.R.T. information from it daily (in cron job). > When script detect, that relocation table is near to be full or here > is 1000 new relocations in one day, it sends mail to root, and we > have some time to buy new HDD. > > But I could not find any utility for FreeBSD, which could get > S.M.A.R.T. information and relocation table from HDD... > So, we need such utility. > Does anybody know -- is such utility exists? I'm working on it, but its not available to the public yet... I'll announce it when I have it ready for general consumption... BTW not all ATA drives supports this... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 12:59:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 3BA5B37B4CF for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 12:59:37 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAML0gC13702; Wed, 22 Nov 2000 13:00:42 -0800 (PST) (envelope-from kris) Date: Wed, 22 Nov 2000 13:00:42 -0800 From: Kris Kennaway <kris@FreeBSD.ORG> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: hackers@FreeBSD.ORG Subject: Re: BSD's random.c dicey on the Alpha Message-ID: <20001122130042.B13528@citusc17.usc.edu> References: <37270.974899107@axl.fw.uunet.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <37270.974899107@axl.fw.uunet.co.za>; from sheldonh@uunet.co.za on Wed, Nov 22, 2000 at 03:18:27PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 22, 2000 at 03:18:27PM +0200, Sheldon Hearn wrote: >=20 > Hi folks, >=20 > Anyone want to have a look at this? It's from the GNU awk maintainer. Without knowing which random.c it was, it's hard to judge :-) Also not knowing what the intended use is, it's hard to recommend something. Kris --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjocM/oACgkQWry0BWjoQKVWeACgzYDDXPHcrUtPC6gDr1yE3QTc M5kAoNqAPIJ2bRTw1O1ruddpxhIIxBLp =sSC0 -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 14:58:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from coder.networkcomputerz.com (unknown [208.21.1.40]) by hub.freebsd.org (Postfix) with ESMTP id 535E137B479 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 14:58:47 -0800 (PST) Received: from networkcomputerz.com (localhost.networkcomputerz.com [127.0.0.1]) by coder.networkcomputerz.com (8.9.3/8.9.3) with ESMTP id RAA34342 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 17:57:35 -0500 (EST) (envelope-from andrew@networkcomputerz.com) Message-ID: <3A1C4F5F.81D0EF07@networkcomputerz.com> Date: Wed, 22 Nov 2000 17:57:35 -0500 From: Andrew Otwell <andrew@networkcomputerz.com> X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: porting a Linux app Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please respond to me directly (and the mailing list if you so choose).... I am attempting to port an application from Linux to FreeBSD (source code). I have been told that I need to compile the source against a different set of /include and /lib files. When compiled against the system libs it works fine but when I try to compile against our proprietary libs it doesn't seem to do what I ask. The code does compile and run. Problem is.... my gcc options do not seem to produce the results I'd like. I have attempted gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c but it always seems to compile against the /usr/include and /usr/lib files. I know this because I produced an ELF binary (sans the -static arg) and ran "ldd program-name" and it returned lgcc.2 => /usr/lib/libgcc.xxxxxxxxx and some other => /usr/lib/xxxxxxxxxx's. I have also tried renaming all "#include <stdio.h>" to "#include "/pathto/new/include/stdio.h" and so on.... How do I force this source to compile using the /pathto/new/include and /pathto/new/lib ??????? -- Andrew Otwell andrew@networkcomputerz.com www.NetworkComputerz.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 15:17: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 43DF037B479 for <freebsd-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 15:17:04 -0800 (PST) Received: from newsguy.com (p30-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.95]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id IAA27543; Thu, 23 Nov 2000 08:16:59 +0900 (JST) Message-ID: <3A1C537D.CCEB458E@newsguy.com> Date: Thu, 23 Nov 2000 08:15:09 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Andrew Otwell <andrew@networkcomputerz.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: porting a Linux app References: <3A1C4F5F.81D0EF07@networkcomputerz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Otwell wrote: > > gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c -nostdlib -nostdinc -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@united.bsdconspiracy.net "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 15:20:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id 623BB37B4C5 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 15:20:16 -0800 (PST) Received: (qmail 89833 invoked from network); 22 Nov 2000 23:20:15 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 22 Nov 2000 23:20:15 -0000 Received: (qmail 2884 invoked from network); 22 Nov 2000 23:20:42 -0000 Received: from explorer.rsa.com (10.81.217.59) by spirit.dynas.se with SMTP; 22 Nov 2000 23:20:42 -0000 Received: (from mikko@localhost) by explorer.rsa.com (8.11.1/8.11.1) id eAMNKDx45514; Wed, 22 Nov 2000 15:20:13 -0800 (PST) (envelope-from mikko) Date: Wed, 22 Nov 2000 15:20:13 -0800 (PST) From: Mikko Tyolajarvi <mikko@dynas.se> Message-Id: <200011222320.eAMNKDx45514@explorer.rsa.com> To: wollman@khavrinen.lcs.mit.edu Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch Newsgroups: local.freebsd-current References: <1470.974928159@critter> <200011222239.RAA48717@khavrinen.lcs.mit.edu> X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In local.freebsd-current you write: ><<On Wed, 22 Nov 2000 22:22:39 +0100, Poul-Henning Kamp <phk@critter.freebsd.dk> said: >> Another particular thing I remember was that some syslog-challenged >> daemons whine on /dev/console long after /etc/rc has finished. >They can try, but by the time they do the console has already been >revoke()d, so they no longer have access to the real console. >I've thought about writing daemon(8) which will put these turkeys in >their place. Just a Small Matter of Programming.... Do you mean something like this? $.02, /Mikko ---8<----------------------------------------------------- /* * Description: * Utility to start a program as a daemon. * Closes stdin/out/err and execs the program. * Program is located using PATH. * * Usage: * daemon [options] program [ args to program ] * * Options: * -c Do not close stdin/out/err * -d Do not chdir("/") * -o file Append stdout/err to file * -p file Write pid to file * -u user User to run program as */ #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <stdlib.h> #include <fcntl.h> #include <pwd.h> #include <err.h> #include <sys/stat.h> #define PROGNAME "daemon" #define USAGE "Usage: " PROGNAME \ " [-c] [-o output] [-p pidfile] [-u user] program [args ...]" int main(int argc, char **argv) { int fd, c, noclose, nochdir; char *outfile, *prog, *s, *pidfile; FILE *pf; struct passwd *pw; char *user; noclose = 0; nochdir = 0; outfile = NULL; pidfile = NULL; user = NULL; fd = -1; pf = NULL; pw = NULL; while ((c = getopt(argc, argv, "cdo:p:u:")) != -1) { switch (c) { case 'c': noclose++; break; case 'd': nochdir++; break; case 'o': outfile = optarg; noclose++; break; case 'p': pidfile = optarg; break; case 'u': user = optarg; break; default: errx(2, USAGE); } } if (optind == argc) errx(2, USAGE); if (user != NULL && (pw = getpwnam(user)) == NULL) errx(EXIT_FAILURE, "user unknown: \"%s\"", user); if (pidfile != NULL && ((pf = fopen(pidfile, "w")) == NULL)) err(EXIT_FAILURE, "cannot create \"%s\"", pidfile); if (outfile != NULL) { if ((fd = open(outfile, O_WRONLY | O_APPEND | O_CREAT, 0644)) < 0) { err(EXIT_FAILURE, "cannot create \"%s\"", outfile); } } if (pw != NULL) { initgroups(pw->pw_name, pw->pw_gid); if (setuid(pw->pw_uid) < 0) err(EXIT_FAILURE, "setuid(%d)", pw->pw_uid); } if (daemon(nochdir, noclose) < 0) err(EXIT_FAILURE, "daemon"); if (pidfile != NULL) { fprintf(pf, "%u\n", (unsigned)getpid()); fclose(pf); } if (fd != -1) { dup2(fd, STDOUT_FILENO); dup2(fd, STDERR_FILENO); close(fd); } prog = argv[optind]; if ((s = strrchr(argv[optind], '/')) != 0) { argv[optind] = s+1; } execvp(prog, argv + optind); err(EXIT_FAILURE, "cannot exec %s", prog); if (pidfile != NULL) { unlink(pidfile); } exit(EXIT_FAILURE); } -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 15:56:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4]) by hub.freebsd.org (Postfix) with ESMTP id A173737B4FE for <hackers@freebsd.org>; Wed, 22 Nov 2000 15:56:05 -0800 (PST) Received: (from uucp@localhost) by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id AAA27795; Thu, 23 Nov 2000 00:56:04 +0100 (MET) Received: by adv.devet.org (Postfix, from userid 100) id 8F50F43FA; Thu, 23 Nov 2000 00:55:52 +0100 (CET) Date: Thu, 23 Nov 2000 00:55:52 +0100 To: lconrad@Go2France.com Cc: hackers@freebsd.org Subject: Re: Fwd: Re: still in the woods (tuning for postfix hub) Message-ID: <20001123005552.A57254@adv.devet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Newsgroups: list.freebsd.hackers In-Reply-To: <5.0.2.1.0.20001122183002.023debf0@mail.Go2France.com> Organization: Eindhoven, the Netherlands From: Arjan.deVet@adv.iae.nl (Arjan de Vet) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <5.0.2.1.0.20001122183002.023debf0@mail.Go2France.com> you write: >Somebody here must know who is Mr. Hub Admin, no? postmaster@freebsd.org I guess? >Can somebody tell me who admins FreeBSD/postifx mail hubs? > >I need some help opening up FreeBSD for postfix and 200K msgs/day. Below is an old posting of Peter Wemm to the postfix mailing list about the FreeBSD mailing list server. It gives you some of the information you are asking for. Arjan -- Arjan de Vet, Eindhoven, The Netherlands <Arjan.deVet@adv.iae.nl> URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl From: peter@netplex.com.au (Peter Wemm) Subject: Re: huge mailout tuning? Date: 9 Jul 1999 07:16:38 +0200 Message-ID: <19990708214148.91C7F79@overcee.netplex.com.au> References: <D6C355D59E6DD2119AED00104BCC644C4D3F6F@ccs-exchange.ccsc.com> "Dunstan, Andrew" wrote: > > > > -----Original Message----- > > From: wietse@porcupine.org [SMTP:wietse@porcupine.org] > > > > 2M deliveries in 12 hours is almost 50 a second. Now that is going > > to hit your disk really hard. Each queue file involves synchronous > > disk accesses for creating, writing the message to file and for > > unlinking. Remember, the issue is disk seeks, not I/O bandwidth. > > > [Andrew>] Yes. Would using some sort of raid striping help? If you are prepared to loose mail on a crash, run the filesystem with the queue directory async, or something like the BSD softupdates code to safely avoid directory sync writes. (safely from the perspective of filesystem recovery, not safety from lost mail). If it's a bulk mailout then perhaps this is a acceptable. > > Given that SMTP is a somewhat chatty protocol (unlike HTTP), you > > will need to run hundreds of deliveries in parallel. Postfix uses > > select(), and by default is limited to 1024 open files. In order to > > increase the limit, recompile with a larger size for FD_SETSIZE > > in util/sys_defs.hm at the start of the #ifdef SUNOS5 section. > > > [Andrew>] How do I run "hundreds of deliveries in parallel"? (and > where does postfix multiplex io?) On the freebsd.org machines, we recompiled postfix with FD_SETSIZE set to (overkill) 4096 (freebsd's kernel implementation has variable sized fd_sets). We currently run with 250 delivery smtp processes, and have used higher limits in the past. We manage to fit the entire /var/spool/postfix queue in memory on that machine and with softupdates, a good amount of writes are entirely avoided. (ie: an incoming queue entry gets created, processed (fed to majordomo), then deleted. Under async writes, this data gets written back. Under softupdates it's entirely cancelled out (I believe. :-)) since it was deleted so quickly and never even partially existed on disk before it was unlinked. Again, those machines are not processing critical or sensitive mail so lost mail is unfortunate but tolerable. I *think* we've peaked sustained delivery at about 60/sec for short periods in some circumstances - but we have a *LOT* of slow and/or congested remote sites. I'm pretty sure I've seen transient delivery rate spikes go quite beyond that though but that's probably more luck and timing than anything. Again, *from memory*, the mailing list traffic runs about 1/2 million recipients per day and there is loads of spare capacity as a good deal of this happens in bursts at peak times when a lot of folks read and post to the lists at about the same time of day. > > > I realise that a distributed solution might be necessary, but I want to > > know > > > what we can achieve with our current platform. > > > > > > How can we best tune postfix to maximise delivery rate? Are there issues > > > with queue directories becoming huge? > > > > You can configure postfix to hash queues. By default, only the > > directory for deferred logfiles is hashed. See the hash_queue_names > > parameter. Examples in conf/* > > > [Andrew>] I set have hashing on for incoming, deferred and defer. > Is that right? What is the penalty for increasing the hashing levels? (2 > levels for 2m files would still give me around 10,000 per directory (ouch)). > So I'd prefer to go to 3 or even 4 levels if this doesn't involve a big > performance hit. Also, if you can get the machines, I'd suggest a small cluster of outgoing sender machines. Set up a round-robin DNS entry, say mail-outgoing.you.com where mail-outgoing has 5 or 10 IP addresses or MX records. Then use mail-outgoing for your outbound host. Your core box will send envelopes to the outbound boxes for relaying in a fairly distributed way. We use this technique for freebsd.org mail delivery for some geographical mail exploder relays. For example, mail-relay.de.freebsd.org points to 4 machines, and *.de is exploded via them with a transports entry. Two servers are primary and share the load evenly and the other two are fallbacks on different networks with different international links. eg: [5:06am]~/Mail-251> host mail-relay.de.freebsd.org mail-relay.de.freebsd.org mail is handled (pri=100) by mail.rz.tu-clausthal.de mail-relay.de.freebsd.org mail is handled (pri=100) by baerenklau.de.freebsd.org mail-relay.de.freebsd.org mail is handled (pri=200) by sol.terramedia.de mail-relay.de.freebsd.org mail is handled (pri=300) by ra.dkuug.dk [2:30pm]/etc/postfix-132# fgrep .de /etc/postfix/transport .de smtp:mail-relay.de.freebsd.org This approach works with sendmail too, but you need something like bulk_mailer to presort the envelopes at injection time to get any advantage of multiple recipients per envelope. Anyway, hope this is of use for some ideas. > cheers > > andrew Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 16:30:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id DE89A37B479 for <FreeBSD-hackers@freebsd.org>; Wed, 22 Nov 2000 16:30:00 -0800 (PST) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id CAA28894 for <FreeBSD-hackers@freebsd.org>; Thu, 23 Nov 2000 02:29:55 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id CAA59752 for <FreeBSD-hackers@freebsd.org>; Thu, 23 Nov 2000 02:30:54 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Thu, 23 Nov 2000 02:30:54 +0200 (EET) From: petro <petro@She.wertep.com> To: FreeBSD-hackers@freebsd.org Subject: Shell script Message-ID: <Pine.BSF.4.21.0011230228470.59745-100000@She.wertep.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have such script..... # more trafdump #!/bin/sh - # trafdump Copyright (c)1993 CAD lab # # dump all records to /var/tmp/trafd.$iface # # usage: trafdump interfaces... # PATH=/usr/local/bin WHERE_PID=/var/run/trafd.ed0 LOG_FILE=/var/log/traffic.log if [ $# = 0 ]; then echo trafdump - dump tcp/udp network data traffic echo usage: trafdump interfaces... exit 1 fi for iface in $*; do PID_FILE=$WHERE_PID$iface if [ -f $PID_FILE ]; then kill -HUP `cat $PID_FILE` if [ $? = 0 ]; then echo `date +"%b %e %H:%M:%S"` `hostname -s` trafdump: \ '('$iface')' signaling to dump >> $LOG_FILE fi else echo error: $PID_FILE not found | tee -a $LOG_FILE fi done # but when I try to start # ./trafdump -ied0 I receive three errors.... I can't understand whereis the errors..... [: not found [: not found tee: not found To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 16:37:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 0FF1837B479 for <FreeBSD-hackers@freebsd.org>; Wed, 22 Nov 2000 16:37:45 -0800 (PST) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 13ykNt-0006R1-00; Thu, 23 Nov 2000 00:37:05 +0000 Date: Thu, 23 Nov 2000 00:37:05 +0000 To: petro <petro@She.wertep.com> Cc: FreeBSD-hackers@freebsd.org Subject: Re: Shell script Message-ID: <20001123003704.A24704@firedrake.org> References: <Pine.BSF.4.21.0011230228470.59745-100000@She.wertep.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011230228470.59745-100000@She.wertep.com>; from petro@She.wertep.com on Thu, Nov 23, 2000 at 02:30:54AM +0200 From: void <float@firedrake.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 23, 2000 at 02:30:54AM +0200, petro wrote: > I have such script..... > > PATH=/usr/local/bin [...] > if [ $# = 0 ]; then [...] > if [ -f $PID_FILE ]; then [...] > if [ $? = 0 ]; then [...] > echo error: $PID_FILE not found | tee -a $LOG_FILE > I receive three errors.... > I can't understand whereis the errors..... > [: not found > [: not found > tee: not found $ which [ /bin/[ $ which tee /usr/bin/tee Fix your PATH and all will be well. And next time, post your question to questions@freebsd.org. -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 16:39:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ego.mind.net (ego.mind.net [206.99.66.9]) by hub.freebsd.org (Postfix) with ESMTP id DE1ED37B4CF for <FreeBSD-hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 16:39:16 -0800 (PST) Received: from takhus.dyn.mind.net (AFN-Dyn-63151108225.pc.ashlandfiber.net [63.151.108.225]) by ego.mind.net (8.9.3/8.9.3) with ESMTP id QAA00366; Wed, 22 Nov 2000 16:39:15 -0800 Received: from localhost (fleisher@localhost) by takhus.dyn.mind.net (8.11.1/8.11.1) with ESMTP id eAN0dAu07232; Wed, 22 Nov 2000 16:39:10 -0800 (PST) (envelope-from takhus@takhus.mind.net) X-Authentication-Warning: takhus.dyn.mind.net: fleisher owned process doing -bs Date: Wed, 22 Nov 2000 16:39:09 -0800 (PST) From: Tony Fleisher <takhus@takhus.mind.net> X-Sender: fleisher@takhus.dyn.mind.net To: petro <petro@She.wertep.com> Cc: FreeBSD-hackers@FreeBSD.ORG Subject: Re: Shell script In-Reply-To: <Pine.BSF.4.21.0011230228470.59745-100000@She.wertep.com> Message-ID: <Pine.BSF.4.21.0011221637470.7168-100000@takhus.dyn.mind.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Your PATH variable (line 8) needs to include /bin, where both tee and [ are located. Tony. On Thu, 23 Nov 2000, petro wrote: > I have such script..... > > # more trafdump > #!/bin/sh - > # trafdump Copyright (c)1993 CAD lab > # > # dump all records to /var/tmp/trafd.$iface > # > # usage: trafdump interfaces... > # > PATH=/usr/local/bin > WHERE_PID=/var/run/trafd.ed0 > LOG_FILE=/var/log/traffic.log > > if [ $# = 0 ]; then > echo trafdump - dump tcp/udp network data traffic > echo usage: trafdump interfaces... > exit 1 > fi > > for iface in $*; do > PID_FILE=$WHERE_PID$iface > if [ -f $PID_FILE ]; then > kill -HUP `cat $PID_FILE` > if [ $? = 0 ]; then > echo `date +"%b %e %H:%M:%S"` `hostname -s` > trafdump: \ > '('$iface')' signaling to dump >> $LOG_FILE > fi > else > echo error: $PID_FILE not found | tee -a $LOG_FILE > fi > done > # > > but when I try to start > # ./trafdump -ied0 > I receive three errors.... > I can't understand whereis the errors..... > [: not found > [: not found > tee: not found > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 18:58:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.unpar.ac.id (unknown [202.150.34.3]) by hub.freebsd.org (Postfix) with ESMTP id B79D737B4C5 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 18:58:13 -0800 (PST) Received: from home.unpar.ac.id (root@home [202.150.34.12]) by mx1.unpar.ac.id (8.9.3/8.9.3) with ESMTP id KAA16302 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 10:22:41 +0700 (JAVT) X-UNPAR-MX1-From: thomas@home.unpar.ac.id X-UNPAR-MX1-To: <freebsd-hackers@freebsd.org> Received: from pelangi (h-041.bapsi [10.2.4.41] (may be forged)) by home.unpar.ac.id (8.9.3/8.9.3) with SMTP id JAA91705 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 09:58:09 +0700 (JAVT) (envelope-from thomas@home.unpar.ac.id) Message-ID: <004a01c054f9$2866f5c0$2904020a@unpar.ac.id> From: "Thomas Wahyudi" <thomas@home.unpar.ac.id> To: <freebsd-hackers@freebsd.org> Subject: 2 pci , 1 isa, same type NIC makes freebsd seems to be confused Date: Thu, 23 Nov 2000 09:57:44 +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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have FreeBSd 4.1 with 2 PCI NIC and 1 ISA NIC all of them detected as ed0, ed1. ed2 at kernel, I put ISA NIC as ed0. the problem is: the box seems not stable, almost every 2 hours i must restart the box, when i try to remove all the nic and put back only one, the box going smooth. Any suggestion what i must do ? oh btw I already check the intrupt, none of them were use twince for NIC Best regards, Thomas Wahyudi ======== UIN 535778 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 19: 3:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 02F3E37B479 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 19:03:20 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id WAA50234; Wed, 22 Nov 2000 22:03:09 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Nov 2000 22:03:09 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Message-Id: <200011230303.WAA50234@khavrinen.lcs.mit.edu> To: Mikko Tyolajarvi <mikko@dynas.se> Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch Newsgroups: local.freebsd-current In-Reply-To: <200011222320.eAMNKDx45514@explorer.rsa.com> References: <1470.974928159@critter> <200011222239.RAA48717@khavrinen.lcs.mit.edu> <200011222320.eAMNKDx45514@explorer.rsa.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG <<On Wed, 22 Nov 2000 15:20:13 -0800 (PST), Mikko Tyolajarvi <mikko@dynas.se> said: > Do you mean something like this? Yes, exactly like that! -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 22:25:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tkc.att.ne.jp (tkc.att.ne.jp [165.76.16.7]) by hub.freebsd.org (Postfix) with ESMTP id 0169337B4D7 for <freebsd-hackers@freebsd.org>; Wed, 22 Nov 2000 22:25:39 -0800 (PST) Received: from work.mzaki.nom (108.pool9.ipctokyo.att.ne.jp [165.76.205.108]) by tkc.att.ne.jp (8.8.8+Spin/3.6W-CONS(10/06/00)) id PAA14122; Thu, 23 Nov 2000 15:25:29 +0900 (JST) Date: Thu, 23 Nov 2000 15:25:23 +0900 Message-ID: <86d7fnryr0.wl@tkc.att.ne.jp> From: Motomichi Matsuzaki <mzaki@e-mail.ne.jp> To: thomas@home.unpar.ac.id Cc: freebsd-hackers@freebsd.org Subject: Re: 2 pci , 1 isa, same type NIC makes freebsd seems to be confused In-Reply-To: In your message of "Thu, 23 Nov 2000 09:57:44 +0700" <004a01c054f9$2866f5c0$2904020a@unpar.ac.id> References: <004a01c054f9$2866f5c0$2904020a@unpar.ac.id> X-Mailer: Wanderlust/1.1.1 (Purple Rain) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At Thu, 23 Nov 2000 09:57:44 +0700, Thomas Wahyudi <thomas@home.unpar.ac.id> wrote: > I have FreeBSd 4.1 with 2 PCI NIC and 1 ISA NIC > all of them detected as ed0, ed1. ed2 > at kernel, I put ISA NIC as ed0. Currently, many of NIC drivers can not handle this situation. Many drivers shoud be used on single bus. These are occured from miss-using of devclass. For example, 'ed', In /sys/dev/ed/if_ed_isa.c: static devclass_t ed_isa_devclass; And in /sys/dev/ed/if_ed_pci.c: static devclass_t ed_devclass; These separated devclass leads to confusable situation. Drivers which have same name (such like 'ed') should share one devclass, or multiple 'ed0' appear on the host. Sadly, this type of mistakes are widely spreaded on the tree. The 'snc' driver (which I ported) does right things on this point. /sys/dev/snc/if_sncvar.h extern declaration /sys/dev/snc/if_snc.c real declaration /sys/dev/snc/if_snc_cbus.c use devclass in DRIVER_MODULE /sys/dev/snc/if_snc_pccard.c use devclass in DRIVER_MODULE -- Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 23:29:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [203.96.92.17]) by hub.freebsd.org (Postfix) with ESMTP id F044E37B479; Wed, 22 Nov 2000 23:27:47 -0800 (PST) Received: from themail.com ([210.54.197.59]) by mta5-rme.xtra.co.nz with SMTP id <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com>; Thu, 23 Nov 2000 20:27:44 +1300 From: "turehu" <turehu@themail.com> To: <info@avatar.com> Subject: Accept credit cards on-line THE EASY WAY! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 23 Nov 2000 08:24:45 +1300 Content-Transfer-Encoding: 8bit Message-Id: <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No set up fees No monthly interest No minimum transaction fees The only charge is a small percentage of the cost of the transaction. You can not lose money! You only pay fees if you sell your product. Get in the act and launch your online bussiness which will work for you 24hrs a day, seven days a week and it is worldwide. Want to find out more? Go to: http://www.cyberturf.com/creditcard If this Email has reached you by mistake, we apologize. To remove your Email from the mailing list please send: jennifer@nottern.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Nov 22 23:30: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [203.96.92.17]) by hub.freebsd.org (Postfix) with ESMTP id F044E37B479; Wed, 22 Nov 2000 23:27:47 -0800 (PST) Received: from themail.com ([210.54.197.59]) by mta5-rme.xtra.co.nz with SMTP id <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com>; Thu, 23 Nov 2000 20:27:44 +1300 From: "turehu" <turehu@themail.com> To: <info@avatar.com> Subject: Accept credit cards on-line THE EASY WAY! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 23 Nov 2000 08:24:45 +1300 Content-Transfer-Encoding: 8bit Message-Id: <20001123072744.OAIP60565.mta5-rme.xtra.co.nz@themail.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No set up fees No monthly interest No minimum transaction fees The only charge is a small percentage of the cost of the transaction. You can not lose money! You only pay fees if you sell your product. Get in the act and launch your online bussiness which will work for you 24hrs a day, seven days a week and it is worldwide. Want to find out more? Go to: http://www.cyberturf.com/creditcard If this Email has reached you by mistake, we apologize. To remove your Email from the mailing list please send: jennifer@nottern.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 3:17: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id B651F37B479 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 03:17:03 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19]) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 13yuNB-0006tx-00 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 12:17:01 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 13yuNA-0005J4-00 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 12:17:00 +0100 Date: Thu, 23 Nov 2000 12:17:00 +0100 From: Nicolas Souchu <nsouch@alcove.fr> To: freebsd-hackers@freebsd.org Subject: FreeBSD vs Linux framebuffer Message-ID: <20001123121700.G19987@wiliam.alcove-int> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Kazutaka, hackers, As adviced by the GGI community, I will first try to port libGGI to the FreeBSD framebuffer. Before I look deeper into the sources, what are the main differencies between Linux and FreeBSD designs? Are the interfaces similar? Regards, Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 3:58: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-03-real.cdsnet.net (mail-03-real.cdsnet.net [63.163.68.110]) by hub.freebsd.org (Postfix) with SMTP id 0A79F37B4C5 for <hackers@freebsd.org>; Thu, 23 Nov 2000 03:57:59 -0800 (PST) Received: (qmail 32990 invoked from network); 23 Nov 2000 11:59:09 -0000 Received: from apocalypse.cdsnet.net (63.163.68.5) by mail-03-real.cdsnet.net with SMTP; 23 Nov 2000 11:59:09 -0000 Date: Thu, 23 Nov 2000 03:58:29 -0800 (PST) From: Jaye Mathisen <mrcpu@internetcds.com> X-Sender: mrcpu@apocalypse.cdsnet.net To: hackers@freebsd.org Subject: Any actual shipping ATM cards supported by FreeBSD 4.x and higher? Message-ID: <Pine.BSF.4.21.0011230356360.58989-100000@apocalypse.cdsnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Fore systems web site dumps you into Marconi's site, and a search there doesn't find the word ATM. Efficient Networks page doesnt list the card on the products page any more. So barring those 2, which are the only 2 listed in the release notes, where can I get ATM cards that will work? Optimally, with SM fiber interfaces. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 5:33:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.hitbase.com (ns.hitbase.com [64.65.2.58]) by hub.freebsd.org (Postfix) with ESMTP id 0571537B4C5 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 05:33:17 -0800 (PST) Received: from dima (ts1-195-190-97-14.Spb.dial.sovam.com [195.190.97.14]) by ns.hitbase.com (8.9.3/8.9.3) with SMTP id JAA07066 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 09:29:45 -0500 Message-ID: <001001c05552$45913f80$0e61bec3@dima> From: "Dmitry Sychov" <accelware@accelware.com> To: <hackers@FreeBSD.ORG> Subject: dlopen() Date: Wed, 22 Nov 2000 22:04:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings. Is it safe to remove the *.so file after it is loaded into the process space and addresses to its functions are gotten? I've tested this and have no problems so far. I need this to implement the "hot swap" of the dynamic loading libraries. Thanks, Dmitry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 5:40:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by hub.freebsd.org (Postfix) with ESMTP id 9417937B479 for <hackers@freebsd.org>; Thu, 23 Nov 2000 05:40:50 -0800 (PST) Received: from theta.dante.org.uk ([193.63.211.7]) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 13ywcC-0004iZ-00; Thu, 23 Nov 2000 13:40:40 +0000 Received: from localhost ([127.0.0.1] helo=dante.org.uk) by theta.dante.org.uk with esmtp (Exim 3.12 #4) id 13ywc6-0004H8-00; Thu, 23 Nov 2000 13:40:35 +0000 Message-ID: <3A1D1E52.95A9E626@dante.org.uk> Date: Thu, 23 Nov 2000 13:40:34 +0000 From: Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk> Organization: Delivery of Advanced Networking Technology to Europe Ltd. X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en, ru MIME-Version: 1.0 To: Dmitry Sychov <accelware@accelware.com> Cc: hackers@FreeBSD.ORG Subject: Re: dlopen() References: <001001c05552$45913f80$0e61bec3@dima> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dmitry Sychov wrote: > Greetings. > > Is it safe to remove the *.so file after it is loaded > into the process space and addresses to its > functions are gotten? It's safe to remove it as soon as it's been opened. The file will still exist in the filesystem, only there won't be any references to it from any directories, so you won't be able to open it by its name. The file will be really removed from the file system when you close your file descriptor. > > I've tested this and have no problems so far. > > I need this to implement the "hot swap" of the > dynamic loading libraries. > > Thanks, > Dmitry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 5:48:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool56-tch-1.Sofia.0rbitel.net [212.95.170.56]) by hub.freebsd.org (Postfix) with SMTP id 2760137B4C5 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 05:48:22 -0800 (PST) Received: (qmail 8964 invoked by uid 1000); 23 Nov 2000 13:47:48 -0000 Date: Thu, 23 Nov 2000 15:47:48 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk> Cc: Dmitry Sychov <accelware@accelware.com>, hackers@FreeBSD.ORG Subject: Re: dlopen() Message-ID: <20001123154748.C7746@ringworld.oblivion.bg> Mail-Followup-To: Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk>, Dmitry Sychov <accelware@accelware.com>, hackers@FreeBSD.ORG References: <001001c05552$45913f80$0e61bec3@dima> <3A1D1E52.95A9E626@dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A1D1E52.95A9E626@dante.org.uk>; from Konstantin.Chuguev@dante.org.uk on Thu, Nov 23, 2000 at 01:40:34PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 23, 2000 at 01:40:34PM +0000, Konstantin Chuguev wrote: > Dmitry Sychov wrote: > > > Greetings. > > > > Is it safe to remove the *.so file after it is loaded > > into the process space and addresses to its > > functions are gotten? > > It's safe to remove it as soon as it's been opened. > The file will still exist in the filesystem, only there won't be any > references to it from any directories, so you won't be able to open it > by its name. The file will be really removed from the file system when > you close your file descriptor. So the original poster's question is better translated as 'does the dynamic loader ever close and reopen a file after the initial loading, so it could accidentally open the new version of the library and use the old addresses'? I'd guess the answer is 'no' - the dynamic loader most probably opens the file once, and mmap()'s the needed functions; I might very well be wrong though. G'luck, Peter -- This sentence is false. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 5:58:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id A2B2037B4CF for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 05:57:43 -0800 (PST) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id eANDr9928546; Thu, 23 Nov 2000 19:53:14 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Date: Thu, 23 Nov 2000 19:53:08 +0600 (NS) From: Max Khon <fjoe@iclub.nsu.ru> To: Dmitry Sychov <accelware@accelware.com> Cc: hackers@FreeBSD.ORG Subject: Re: dlopen() In-Reply-To: <001001c05552$45913f80$0e61bec3@dima> Message-ID: <Pine.BSF.4.21.0011231952030.28477-100000@iclub.nsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Wed, 22 Nov 2000, Dmitry Sychov wrote: > Is it safe to remove the *.so file after it is loaded > into the process space and addresses to its > functions are gotten? yes /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 6:38:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by hub.freebsd.org (Postfix) with ESMTP id A48EE37B4C5 for <hackers@freebsd.org>; Thu, 23 Nov 2000 06:38:16 -0800 (PST) Received: from theta.dante.org.uk ([193.63.211.7]) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 13yxVk-0004wh-00; Thu, 23 Nov 2000 14:38:04 +0000 Received: from localhost ([127.0.0.1] helo=dante.org.uk) by theta.dante.org.uk with esmtp (Exim 3.12 #4) id 13yxVi-0004Ji-00; Thu, 23 Nov 2000 14:38:02 +0000 Message-ID: <3A1D2BC7.65AB61AA@dante.org.uk> Date: Thu, 23 Nov 2000 14:37:59 +0000 From: Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk> Organization: Delivery of Advanced Networking Technology to Europe Ltd. X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en, ru MIME-Version: 1.0 To: Peter Pentchev <roam@orbitel.bg> Cc: Dmitry Sychov <accelware@accelware.com>, hackers@FreeBSD.ORG Subject: Re: dlopen() References: <001001c05552$45913f80$0e61bec3@dima> <3A1D1E52.95A9E626@dante.org.uk> <20001123154748.C7746@ringworld.oblivion.bg> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > > > Is it safe to remove the *.so file after it is loaded > > > into the process space and addresses to its > > > functions are gotten? > > > > It's safe to remove it as soon as it's been opened. > > The file will still exist in the filesystem, only there won't be any > > references to it from any directories, so you won't be able to open it > > by its name. The file will be really removed from the file system when > > you close your file descriptor. > > So the original poster's question is better translated as 'does the dynamic > loader ever close and reopen a file after the initial loading, so it could > accidentally open the new version of the library and use the old addresses'? > > I'd guess the answer is 'no' - the dynamic loader most probably opens > the file once, and mmap()'s the needed functions; I might very well be wrong > though. > This is how I think it works (don't have any FreeBSD box nearby): For all dynamically loaded modules: dlopen() opens the file (gets a file descriptor) and mmaps it (possibly excluding the debug and some other sections). dlclose() unmaps and closes it. For shared libraries: __init() code of the binary executable dlopen()'s all the libraries, then goes through the table of external symbols, lookups them with dlsym(RTLD_NOW) in the libraries and replaces stub function pointers with the pointers to real functions. The latter may be optimised somehow. __fini() code dlclose()'s all the libraries. But the best way is to look at the source code, of course ;-) -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 7: 4:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from spammie.svbug.com (mg134-015.ricochet.net [204.179.134.15]) by hub.freebsd.org (Postfix) with ESMTP id CCC9637B4C5 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 07:04:46 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA02182; Thu, 23 Nov 2000 07:04:28 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011231504.HAA02182@spammie.svbug.com> Date: Thu, 23 Nov 2000 07:04:26 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: "iowait" CPU state To: barry@lustig.com Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <20001115204128.12980.qmail@devious.lustig.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Nov, Barry Lustig wrote: > On Wed, 15 Nov 2000, Terry Lambert wrote: >> >> I'm always tempted to set up a company where the main >> engineers have a centralized batch compile server, so as to >> not slow down developement, but requiring that they run no >> better than a 386SX/16 on their desktop. If they are good, >> I'd give them a full 8M of real RAM, instead of 4M. >> > > That's what they did at NeXT. The engineers got machines with slower > processors and small amounts of RAM. It was designed to encourage them to > produce fast efficient code. > Thats what we do also. We hired some engineers and it seemed they spent more time on "build world", than solving the problem. When one of them went on vacation (for a few days), we told him we needed to sell his computer. We replace a 350MHz PII with a 386dx @ 33Mhz. It took him about 3 days, but he started thinking about the problem, not building new code. It's become very effective in retraining engineers. Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 7:58:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CAC437B4D7 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 07:58:34 -0800 (PST) Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA02410 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 16:58:28 +0100 Date: Thu, 23 Nov 2000 16:58:28 +0100 (CET) From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> To: freebsd-hackers@freebsd.org Subject: page coloring Message-ID: <Pine.LNX.3.96.1001123162401.737A-100000@artax.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. Isn't the page coloring algoritm in _vm_page_list_find totally bogus? It skips queue pq[index & PQ_L2_MASK]. If it doesn't find page with desired color, it allocates page with nearest color - as a result there are two pages with same color mapped at two adjacent virtual adresses - this is the exact opposite of what page coloring should do! It should be changed to something like: for (i = PQ_L2_SIZE * PQ_PRIME1; i > 0; i -= PQ_PRIME1) if ((m = TAILQ_FIRST(&pq[(index + i) & PQ_L2_MASK].pl)) != NULL) break; Mikulas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 8: 7:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-178-138.dsl.snfc21.pacbell.net [63.202.178.138]) by hub.freebsd.org (Postfix) with ESMTP id F23D737B4CF for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 08:07:19 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eANGEgF01060; Thu, 23 Nov 2000 08:14:42 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011231614.eANGEgF01060@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Cc: freebsd-hackers@freebsd.org Subject: Re: page coloring In-reply-to: Your message of "Thu, 23 Nov 2000 16:58:28 +0100." <Pine.LNX.3.96.1001123162401.737A-100000@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Nov 2000 08:14:42 -0800 From: Mike Smith <msmith@freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi. > > Isn't the page coloring algoritm in _vm_page_list_find totally bogus? Yes, it's totally bogus, and it should probably be ripped out. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 8:38:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bunyip.flash.net (bunyip.flash.net [209.30.2.15]) by hub.freebsd.org (Postfix) with ESMTP id 2564837B4C5 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 08:38:56 -0800 (PST) Received: from b41box.SAMBA (208-194-215-26.flash.net [208.194.215.26]) by bunyip.flash.net (8.9.3/Pro-8.9.3) with SMTP id KAA25429; Thu, 23 Nov 2000 10:38:34 -0600 (CST) Message-ID: <3A1CECF9.446B9B3D@flash.net> Date: Thu, 23 Nov 2000 10:10:01 +0000 From: Courtney Thomas <ccthomas@flash.net> X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 4.1-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 9:18:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 2B59537B479 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 09:18:50 -0800 (PST) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id JAA61610; Thu, 23 Nov 2000 09:18:42 -0800 (PST) (envelope-from rh@matriplex.com) Date: Thu, 23 Nov 2000 09:18:42 -0800 (PST) From: Richard Hodges <rh@matriplex.com> To: Jaye Mathisen <mrcpu@internetcds.com> Cc: hackers@FreeBSD.ORG Subject: Re: Any actual shipping ATM cards supported by FreeBSD 4.x and higher? In-Reply-To: <Pine.BSF.4.21.0011230356360.58989-100000@apocalypse.cdsnet.net> Message-ID: <Pine.BSF.4.10.10011230854510.59285-100000@mail.matriplex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 23 Nov 2000, Jaye Mathisen wrote: > Fore systems web site dumps you into Marconi's site, and a search there > doesn't find the word ATM. Yeah, it was a pretty sad day when the Fore site changed from ATM products to ... actually, I don't know *what* they are selling now. I hope otherwise, but my gut tells me they are preparing to quietly abandon ATM. > Efficient Networks page doesnt list the card on the products page any > more. I saw the Adaptec 2940 on pricewatch. It uses the Efficient Midway SAR and should probably be a simple or trivial modification to the hea code. The natm (man 4 en) driver handles both Efficient and Adaptec cards, so any differences should be noted there. > So barring those 2, which are the only 2 listed in the release notes, > where can I get ATM cards that will work? Optimally, with SM fiber > interfaces. Shopper.com is pretty slow (search for "forerunner"). It just showed that buy.com has the Fore PCA200E/OC3 for $620. They also list the SMF version for $1730. Personally, I would rather get out my soldering iron and a junk (cheap) part with an SMF module and replace the MMF with the SMF. (Come to think of it, I *DID* do this kind of exchange in the past - works great.) If you don't mind using a driver outside the FreeBSD distribution, you can use the Fore LE155 or IDT Nicstar cards. Mark Tinguely has a driver that works with HARP (http://www.cs.ndsu.nodak.edu/~tinguely) These cards are right now priced from $140 (UTP) to $450 (MMF). If you have no luck at all finding what you want, let me know and I'll get you hooked up with something :-) All the best, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. <title> | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 9:22:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id D274937B479; Thu, 23 Nov 2000 09:22:43 -0800 (PST) Received: from newsguy.com (p35-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.100]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id CAA15518; Fri, 24 Nov 2000 02:21:32 +0900 (JST) Message-ID: <3A1D51AF.87781AD1@newsguy.com> Date: Fri, 24 Nov 2000 02:19:43 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Motomichi Matsuzaki <mzaki@e-mail.ne.jp> Cc: thomas@home.unpar.ac.id, freebsd-hackers@FreeBSD.ORG, julian@freebsd.org Subject: Re: 2 pci , 1 isa, same type NIC makes freebsd seems to be confused References: <004a01c054f9$2866f5c0$2904020a@unpar.ac.id> <86d7fnryr0.wl@tkc.att.ne.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Motomichi Matsuzaki wrote: > > These separated devclass leads to confusable situation. > Drivers which have same name (such like 'ed') > should share one devclass, or multiple 'ed0' appear on the host. > > Sadly, this type of mistakes are widely spreaded on the tree. That's probably because it's widely spread on the tree. There ought to be a note on this on Julian's example driver (though I'm glad to see it already _does_ the right thing), and possibly elsewhere. As well as an effort to fix it in the three. There, I added a note on devclass(9). Someone fix the tree. :-) The fix is trivial, and not even particularly tiring. This is the proverbial junior kernel hacker task, though one doesn't even need to be a junior kernel hacker to do it. :-) The downside is that it's not particularly interesting to do either, and there is nothing to be learned from the experience. /me sighs -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@united.bsdconspiracy.net "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 9:33:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 64FB337B4D7; Thu, 23 Nov 2000 09:33:08 -0800 (PST) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eANHX4J34102; Thu, 23 Nov 2000 19:33:04 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011231733.eANHX4J34102@gratis.grondar.za> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, hackers@FreeBSD.ORG Subject: Re: BSD's random.c dicey on the Alpha References: <20001122130042.B13528@citusc17.usc.edu> In-Reply-To: <20001122130042.B13528@citusc17.usc.edu> ; from Kris Kennaway <kris@FreeBSD.ORG> "Wed, 22 Nov 2000 13:00:42 PST." Date: Thu, 23 Nov 2000 19:33:05 +0200 From: Mark Murray <mark@grondar.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Anyone want to have a look at this? It's from the GNU awk maintainer. > > Without knowing which random.c it was, it's hard to judge :-) Also not > knowing what the intended use is, it's hard to recommend something. I'd guess src/lib/libc/stdlib/random.c I'll bury it in my TODO. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 11: 5: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id E11C537B4FE for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 11:04:58 -0800 (PST) Received: from pretoria-31.budapest.interware.hu ([195.70.53.95] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13z1fk-0004IG-00; Thu, 23 Nov 2000 20:04:41 +0100 Message-ID: <3A1D1C90.F5C508FD@elischer.org> Date: Thu, 23 Nov 2000 05:33:04 -0800 From: Julian Elischer <julian@elischer.org> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Andrew Otwell <andrew@networkcomputerz.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: porting a Linux app References: <3A1C4F5F.81D0EF07@networkcomputerz.com> <3A1C537D.CCEB458E@newsguy.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Andrew Otwell wrote: > > > > gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c > > -nostdlib -nostdinc and don't forget to compile the libries on freeBSD..you can't just use the Linux ones > > -- > Daniel C. Sobral (8-DCS) > > dcs@newsguy.com > dcs@freebsd.org > capo@united.bsdconspiracy.net > > "All right, Lieutenant, let's see what you do know. Whatever it is, > it's not enough, but at least you haven't done anything stupid yet." > "I've hardly had time, sir." > "There's a naive statement." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 11:20:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by hub.freebsd.org (Postfix) with ESMTP id 08AD237B4C5 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 11:20:54 -0800 (PST) Received: from manor.msen.com (wayne@localhost [127.0.0.1]) by manor.msen.com (8.9.3/8.9.3) with ESMTP id OAA70638 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 14:20:52 -0500 (EST) (envelope-from wayne@manor.msen.com) Message-Id: <200011231920.OAA70638@manor.msen.com> To: hackers@FreeBSD.ORG Subject: Ethernet de driver problem on 3.5 stable Date: Thu, 23 Nov 2000 14:20:52 -0500 From: "Michael R. Wayne" <wayne@staff.msen.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have run into an issue with the de driver and Dlink quad cards under 3.5 stable. Despite the messages from the driver, claiming to be in full duplex, (see trimmed dmesg output below) it's not. I removed a working Intel fxp card from a system and installed the Dlink quad card. Same cable, same switch port (HP 4000M locked at 100 Full Duplex). After booting the machine, slogin session felt like duplex was mismatched (after enough times, one recognizes the symptoms). The switch was seeing CRC errors about once a minute and netstat -in showed lots of collisions (which can not occur in FD Mode) and 1-2 Oerrs per minute. Locking the HP port to 100 Half-Duplex has reduced the Oerrs to four in 24 hours, along with about 1500 collisions (which are expected in HD). slogin sessions no longer feel like the duplex is mismatched. ifconfig claims the card is still in full duplex mode. As we did not see this problem with the Intel, I am not suspecting the cable or the switch port. Is there a known problem with the Dlinks or is this a possible issue in the driver? /\/\ \/\/ FreeBSD 3.5-STABLE #6: Wed Nov 8 18:28:20 EST 2000 Probing for devices on PCI bus 2: de0: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 11 on pci2.4.0 de0: 21143 [10-100Mb/s] pass 4.1 de0: address 00:80:c8:c9:8c:60 de1: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 9 on pci2.5.0 de1: 21143 [10-100Mb/s] pass 4.1 de1: address 00:80:c8:c9:8c:61 de2: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 5 on pci2.6.0 de2: 21143 [10-100Mb/s] pass 4.1 de2: address 00:80:c8:c9:8c:62 de3: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 10 on pci2.7.0 de3: 21143 [10-100Mb/s] pass 4.1 de3: address 00:80:c8:c9:8c:63 de1: enabling 100baseTX port de0: enabling 100baseTX port de0: enabling Full Duplex 100baseTX port de1: enabling 100baseTX port de1: enabling Full Duplex 100baseTX port To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 12:36:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.waikato.ac.nz (taupo.cs.waikato.ac.nz [130.217.241.30]) by hub.freebsd.org (Postfix) with ESMTP id 66C3A37B4C5 for <hackers@freebsd.org>; Thu, 23 Nov 2000 12:36:31 -0800 (PST) Received: (from joerg@localhost) by cs.waikato.ac.nz (8.9.3/8.9.3) id JAA44357; Fri, 24 Nov 2000 09:35:28 +1300 (NZDT) (envelope-from joerg) Date: Fri, 24 Nov 2000 09:35:28 +1300 From: Joerg Micheel <joerg@cs.waikato.ac.nz> To: Jaye Mathisen <mrcpu@internetcds.com> Cc: hackers@freebsd.org, joerg@cs.waikato.ac.nz Subject: Re: Any actual shipping ATM cards supported by FreeBSD 4.x and higher? Message-ID: <20001124093528.R24761@cs.waikato.ac.nz> References: <Pine.BSF.4.21.0011230356360.58989-100000@apocalypse.cdsnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.BSF.4.21.0011230356360.58989-100000@apocalypse.cdsnet.net>; from mrcpu@internetcds.com on Thu, Nov 23, 2000 at 03:58:29AM -0800 Organization: Dept of Computer Science, University of Waikato, Hamilton, New Zealand Project: WAND - Waikato Applied Network Dynamics, DAG Operating-System: ... powered by FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 23, 2000 at 03:58:29AM -0800, Jaye Mathisen wrote: > Fore systems web site dumps you into Marconi's site, and a search there > doesn't find the word ATM. It's there, under broadband, edge, adaptors, look for PCA-200E. http://www.marconi.com/html/solutions/forerunner200e.htm http://www.marconi.com/html/solutions/forerunner200eorderinginformation.htm Joerg -- Joerg B. Micheel Email: <joerg@cs.waikato.ac.nz> WAND and NLANR MOAT Email: <joerg@nlanr.net> The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105 Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 13:26:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 85A1A37B4CF; Thu, 23 Nov 2000 13:26:11 -0800 (PST) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id PAA00745; Thu, 23 Nov 2000 15:26:10 -0600 (CST) Date: Thu, 23 Nov 2000 15:26:10 -0600 From: Alan Cox <alc@cs.rice.edu> To: Mike Smith <msmith@freebsd.org> Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>, hackers@freebsd.org Subject: Re: page coloring Message-ID: <20001123152610.F21300@cs.rice.edu> References: <20001123143530.E21300@cs.rice.edu> <200011232048.eANKm9F01796@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <200011232048.eANKm9F01796@mass.osd.bsdi.com>; from Mike Smith on Thu, Nov 23, 2000 at 12:48:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 23, 2000 at 12:48:09PM -0800, Mike Smith wrote: > > > Isn't the page coloring algoritm in _vm_page_list_find totally bogus? > > > > > > > No, it's not. The comment is, however, misplaced. It describes > > the behavior of an inline function in vm_page.h, and not the function > > it precedes. > > Hrm. My comment was based on John Dyson's own observations on its > behaviour, and other discussions which concluded that the code wasn't > flexible enough (hardcoded assumptions on cache organisation, size etc.) > Yes, it would be nice if it was "auto-configuring", because many people who use it misconfigure it. They configure the number of colors based upon the size of their cache rather than cache size/degree of associativity. (Having too many colors makes it less likely that you'll get a page of the right color when you ask for one because that queue will be empty.) Overall, it's my experience that people have absurb expectations of page coloring. They think of it as an optimization. It's not. It's better thought of as a necessary evil: Suppose you're writing a numerical application and either you or your compiler goes to a lot of trouble to "block" the algorithm for the L2 cache size. If the underlying OS doesn't do page coloring, it's likely that your program will still experience conflict misses despite your efforts to avoid them. Furthermore, you'll see a different number of conflict misses each time you run the program (assuming the typical random page allocation strategies). So, the execution time will vary. In short, page coloring simply provides a machine whose performance is more deterministic/predictable. Alan P.S. I noticed that I mistakenly cc'ed my previous message to -current rather than -hackers. I've changed it back to -hackers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14: 0:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 5332E37B4C5; Thu, 23 Nov 2000 14:00:36 -0800 (PST) Subject: Re: Ethernet de driver problem on 3.5 stable In-Reply-To: <200011231920.OAA70638@manor.msen.com> from "Michael R. Wayne" at "Nov 23, 2000 02:20:52 pm" To: wayne@staff.msen.com (Michael R. Wayne) Date: Thu, 23 Nov 2000 14:00:36 -0800 (PST) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20001123220036.5332E37B4C5@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I have run into an issue with the de driver and Dlink quad cards under > 3.5 stable. > > Despite the messages from the driver, claiming to be in full duplex, [...] > Is there a known problem with the Dlinks or is this a possible > issue in the driver? [...] > Probing for devices on PCI bus 2: > de0: <Digital 21143 Fast Ethernet> rev 0x41 int a irq 11 on pci2.4.0 [...] It's a driver bug, although it's partly Intel's fault for screwing up the 21143 design. To enable full duplex mode, you're supposed to set the full duplex bit in in CSR6. In the 21140A, that's all this bit does; it's not affected by anything else. But in the 21143 design, this bit performs two functions, depending on the setting of the autoneg enable bit in CSR14. If the autoneg enable bit is off, then the full duplex bit works as expected. But if the autoneg enable bit is turned on, the full duplex bit controls whether or not the 21143 will advertise 10Mbps/full-duplex during an NWAY exchange. Unfortunately, after a software reset, the autoneg enable bit in CSR14 is turned on by default, and the de driver never bothers to clear it. The stupid thing is that there are plenty of unused bits in other registers that Intel could have used rather than overloading the full duplex bit in CSR6 to perform two functions. Anyway. The dc driver in FreeBSD 4.0 and later should get this right. If you want to try and fix it in the de driver, you need to add a line somewhere that says: TULIP_CSR_WRITE(sc, csr_14, 0); It should probably at the end of tulip_init(), or possibly near the end of tulip_reset(), the point being to do it immediately after invoking a software reset in order to clear the autoneg enable flag. Either that, or upgrade to FreeBSD 4.2. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14: 2:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 4878637B479; Thu, 23 Nov 2000 14:02:37 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-158.nnj.dialup.bellatlantic.net [151.198.117.158]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id RAA03148; Thu, 23 Nov 2000 17:01:39 -0500 (EST) Message-ID: <3A1D93C2.9DEC01F1@bellatlantic.net> Date: Thu, 23 Nov 2000 17:01:38 -0500 From: Sergey Babkin <babkin@bellatlantic.net> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: walter@pelissero.org Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SVR4 missing syscall References: <14873.23011.159826.718978@hyde.lpds.sublink.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Walter C. Pelissero" wrote: > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > (invalid system call) at the very beginning. Here is the kdump: > > 39525 ktrace RET ktrace 0 > 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) > 39525 ktrace RET sigprocmask 0 > 39525 ktrace CALL execve(0xbfbff9a3,0xbfbff880,0xbfbff88c) > 39525 ktrace NAMI "./scobin" > 39525 ktrace NAMI "/compat/svr4/usr/lib/libc.so.1" > 39525 scobin RET execve 0 > 39525 scobin CALL getuid > 39525 scobin RET getuid 1001/0x3e9 > 39525 scobin CALL getuid > 39525 scobin RET getuid 1001/0x3e9 > 39525 scobin CALL getgid > 39525 scobin RET getgid 0 > 39525 scobin CALL getgid > 39525 scobin RET getgid 0 > 39525 scobin CALL setlogin(0x72,0x805056c) > 39525 scobin RET setlogin 0 > 39525 scobin CALL setlogin(0x28,0x280a9764) > 39525 scobin RET setlogin 0 > 39525 scobin CALL break(0x8051580) > 39525 scobin RET break 0 > 39525 scobin CALL setlogin(0x68,0x8049830) > 39525 scobin RET setlogin 0 > 39525 scobin CALL getpid > 39525 scobin RET getpid 39525/0x9a65 > 39525 scobin CALL old.lstat > 39525 scobin PSIG SIGSYS SIG_DFL > 39525 scobin NAMI "scobin.core" > > Which call is it about? I see an "old.lstat" but I couldn't find any I believe old.ldstat is the name of BSD syscall with the same number. The other syscall names are also not SVR4 but BSD, kdump has the same problem with Linux binaries too. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14:38:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id C0C7437B4CF for <hackers@freebsd.org>; Thu, 23 Nov 2000 14:38:34 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id OAA09619; Thu, 23 Nov 2000 14:38:25 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id eANMcOf81020; Thu, 23 Nov 2000 14:38:24 -0800 (PST) (envelope-from jdp) Date: Thu, 23 Nov 2000 14:38:24 -0800 (PST) Message-Id: <200011232238.eANMcOf81020@vashon.polstra.com> To: hackers@freebsd.org From: John Polstra <jdp@polstra.com> Reply-To: hackers@freebsd.org Cc: Konstantin.Chuguev@dante.org.uk Subject: Re: dlopen() In-Reply-To: <3A1D2BC7.65AB61AA@dante.org.uk> References: <001001c05552$45913f80$0e61bec3@dima> <3A1D1E52.95A9E626@dante.org.uk> <20001123154748.C7746@ringworld.oblivion.bg> <3A1D2BC7.65AB61AA@dante.org.uk> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <3A1D2BC7.65AB61AA@dante.org.uk>, Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk> wrote: > Peter Pentchev wrote: > > > So the original poster's question is better translated as 'does the dynamic > > loader ever close and reopen a file after the initial loading, so it could > > accidentally open the new version of the library and use the old addresses'? > > > > I'd guess the answer is 'no' - the dynamic loader most probably opens > > the file once, and mmap()'s the needed functions; I might very well be wrong > > though. > > > > This is how I think it works (don't have any FreeBSD box nearby): > For all dynamically loaded modules: > dlopen() opens the file (gets a file descriptor) and mmaps it (possibly > excluding the debug and some other sections). dlclose() unmaps and closes it. Not quite. The dynamic linker opens the file, mmaps it, and closes it immediately. A mapping created by mmap endures even after you close the underlying file. I assume (but have not tested) that it is OK to remove the file after the dlopen call. The file is still mmapped, so I don't think the underlying storage will go away. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14:44: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.unixbox.com (shell.unixbox.com [207.211.45.65]) by hub.freebsd.org (Postfix) with ESMTP id E121B37B479 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 14:43:59 -0800 (PST) Received: from localhost (fengyue@localhost) by shell.unixbox.com (8.11.1/8.11.0) with ESMTP id eANMk3113101 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 14:46:03 -0800 (PST) Date: Thu, 23 Nov 2000 14:46:03 -0800 (PST) From: FengYue <fengyue@bluerose.windmoon.nu> X-Sender: fengyue@shell.unixbox.com To: hackers@FreeBSD.ORG Subject: crash on 4.2-stable (sendto() system call) In-Reply-To: <3A1D93C2.9DEC01F1@bellatlantic.net> Message-ID: <Pine.BSF.4.21.0011231439220.12930-100000@shell.unixbox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, got a crash on 4.2-stable. the machine was running 4.1.1-stable and had no problem at all. 10 hours after upgrade to 4.2-stable I got a vmcore. Here it's the trace and could someone take a look, it looks like it was the sendto() call triggered the crash but I don't know how to reproduce it. Thanks ----------- initial pcb at 24c320 panicstr: page fault panic messages: --- dmesg: kvm_read: --- #0 0xc013336e in dumpsys () (kgdb) bt #0 0xc013336e in dumpsys () #1 0xc013318f in boot () #2 0xc013350c in poweroff_wait () #3 0xc0200461 in trap_fatal () #4 0xc0200139 in trap_pfault () #5 0xc01ffd1f in trap () #6 0xc01882dd in fr_makefrip () #7 0xc018e20c in fr_checkicmpmatchingstate () #8 0xc018e44d in fr_checkstate () #9 0xc0188ecc in fr_check () #10 0xc017d124 in ip_output () #11 0xc017b416 in icmp_send () #12 0xc017b397 in icmp_reflect () #13 0xc017acbd in icmp_error () #14 0xc0185be4 in udp_input () #15 0xc017bdcb in ip_input () #16 0xc017be2b in ipintr () #17 0xc01f69d5 in swi_net_next () #18 0xc0153881 in sendit () #19 0xc0153975 in sendto () #20 0xc020070d in syscall2 () #21 0xc01f5575 in Xint0x80_syscall () Cannot access memory at address 0xbfbffc8c. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14:50:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 944B737B4CF for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 14:50:35 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4I00DOD244HV@field.videotron.net> for hackers@FreeBSD.ORG; Thu, 23 Nov 2000 17:50:28 -0500 (EST) Date: Thu, 23 Nov 2000 17:50:53 -0500 (EST) From: Bosko Milekic <bmilekic@technokratis.com> Subject: Re: crash on 4.2-stable (sendto() system call) In-reply-to: <Pine.BSF.4.21.0011231439220.12930-100000@shell.unixbox.com> To: FengYue <fengyue@bluerose.windmoon.nu> Cc: hackers@FreeBSD.ORG Message-id: <Pine.BSF.4.21.0011231748310.32741-100000@jehovah.technokratis.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Can you please also get the instruction at which the page fault occured? You can try "where" from gdb or you can get the instruction pointer from the original page fault message and then you can probably "disassemble fr_makefrip" and get us the contents around the instruction generating the fault. On Thu, 23 Nov 2000, FengYue wrote: > > Hi, got a crash on 4.2-stable. the machine was running 4.1.1-stable > and had no problem at all. 10 hours after upgrade to 4.2-stable I got > a vmcore. Here it's the trace and could someone take a look, it looks > like it was the sendto() call triggered the crash but I don't know > how to reproduce it. > > Thanks > > ----------- > initial pcb at 24c320 > panicstr: page fault > panic messages: > --- > dmesg: kvm_read: > --- > #0 0xc013336e in dumpsys () > (kgdb) bt > #0 0xc013336e in dumpsys () > #1 0xc013318f in boot () > #2 0xc013350c in poweroff_wait () > #3 0xc0200461 in trap_fatal () > #4 0xc0200139 in trap_pfault () > #5 0xc01ffd1f in trap () > #6 0xc01882dd in fr_makefrip () > #7 0xc018e20c in fr_checkicmpmatchingstate () > #8 0xc018e44d in fr_checkstate () > #9 0xc0188ecc in fr_check () > #10 0xc017d124 in ip_output () > #11 0xc017b416 in icmp_send () > #12 0xc017b397 in icmp_reflect () > #13 0xc017acbd in icmp_error () > #14 0xc0185be4 in udp_input () > #15 0xc017bdcb in ip_input () > #16 0xc017be2b in ipintr () > #17 0xc01f69d5 in swi_net_next () > #18 0xc0153881 in sendit () > #19 0xc0153975 in sendto () > #20 0xc020070d in syscall2 () > #21 0xc01f5575 in Xint0x80_syscall () > Cannot access memory at address 0xbfbffc8c. > Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 14:53:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C983537B4CF for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 14:53:47 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eANMrkq28068; Thu, 23 Nov 2000 14:53:46 -0800 (PST) Date: Thu, 23 Nov 2000 14:53:45 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Bosko Milekic <bmilekic@technokratis.com> Cc: FengYue <fengyue@bluerose.windmoon.nu>, hackers@FreeBSD.ORG Subject: Re: crash on 4.2-stable (sendto() system call) Message-ID: <20001123145345.F18037@fw.wintelcom.net> References: <Pine.BSF.4.21.0011231439220.12930-100000@shell.unixbox.com> <Pine.BSF.4.21.0011231748310.32741-100000@jehovah.technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.BSF.4.21.0011231748310.32741-100000@jehovah.technokratis.com>; from bmilekic@technokratis.com on Thu, Nov 23, 2000 at 05:50:53PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bosko Milekic <bmilekic@technokratis.com> [001123 14:51] wrote: > > Hello, > > Can you please also get the instruction at which the page fault > occured? You can try "where" from gdb or you can get the instruction > pointer from the original page fault message and then you can probably > "disassemble fr_makefrip" and get us the contents around the instruction > generating the fault. It would be better if he could add '-g' to his makeoptions and get a crashdump with debug symbols. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 15:22:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.unixbox.com (shell.unixbox.com [207.211.45.65]) by hub.freebsd.org (Postfix) with ESMTP id 4123B37B4C5 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 15:22:00 -0800 (PST) Received: from localhost (fengyue@localhost) by shell.unixbox.com (8.11.1/8.11.0) with ESMTP id eANNNtu13843; Thu, 23 Nov 2000 15:23:55 -0800 (PST) Date: Thu, 23 Nov 2000 15:23:55 -0800 (PST) From: FengYue <fengyue@bluerose.windmoon.nu> X-Sender: fengyue@shell.unixbox.com To: Alfred Perlstein <bright@wintelcom.net> Cc: Bosko Milekic <bmilekic@technokratis.com>, hackers@FreeBSD.ORG Subject: Re: crash on 4.2-stable (sendto() system call) In-Reply-To: <20001123145345.F18037@fw.wintelcom.net> Message-ID: <Pine.BSF.4.21.0011231515050.12930-100000@shell.unixbox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 23 Nov 2000, Alfred Perlstein wrote: ->* Bosko Milekic <bmilekic@technokratis.com> [001123 14:51] wrote: ->> ->> Hello, ->> ->> Can you please also get the instruction at which the page fault ->> occured? You can try "where" from gdb or you can get the instruction ->> pointer from the original page fault message and then you can probably ->> "disassemble fr_makefrip" and get us the contents around the instruction ->> generating the fault. -> ->It would be better if he could add '-g' to his makeoptions and ->get a crashdump with debug symbols. -> ->-Alfred -> Ah, yes, I actually have -g option turned on. Forgot to do a gdb -k on the kernel.debug instead. Ok, here comes the new trace: ---------------------------------------------------------- shell# gdb -k kernel.debug /var/crash/vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 2883584 initial pcb at 24c320 panicstr: page fault panic messages: --- dmesg: kvm_read: --- #0 dumpsys () at ../../kern/kern_shutdown.c:469 469 if (dumping++) { (kgdb) where #0 dumpsys () at ../../kern/kern_shutdown.c:469 #1 0xc013318f in boot (howto=256) at ../../kern/kern_shutdown.c:309 #2 0xc013350c in poweroff_wait (junk=0xc022952f, howto=-662374720) at ../../kern/kern_shutdown.c:556 #3 0xc0200461 in trap_fatal (frame=0xd892fa68, eva=3232010240) at ../../i386/i386/trap.c:951 #4 0xc0200139 in trap_pfault (frame=0xd892fa68, usermode=0, eva=3232010240) at ../../i386/i386/trap.c:844 #5 0xc01ffd1f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = -1062957084, tf_esi = 0, tf_ebp = -661456160, tf_isp = -661456236, tf_ebx = 0, tf_edx = -661456112, tf_ecx = -661456116, tf_eax = 11008, tf_trapno = 12, tf_err = 0, tf_eip = -1072135459, tf_cs = 8, tf_eflags = 66118, tf_esp = 16128, tf_ss = 638}) at ../../i386/i386/trap.c:443 #6 0xc01882dd in fr_makefrip (hlen=20, ip=0xc0a48fe4, fin=0xd892fb0c) at ../../netinet/fil.c:258 #7 0xc018e20c in fr_checkicmpmatchingstate (ip=0xc0a48fc8, fin=0xd892fc1c) at ../../netinet/ip_state.c:1081 #8 0xc018e44d in fr_checkstate (ip=0xc0a48fc8, fin=0xd892fc1c) at ../../netinet/ip_state.c:1194 #9 0xc0188ecc in fr_check (ip=0xc0a48fc8, hlen=20, ifp=0xc02634e0, out=1, mp=0xd892fcd4) at ../../netinet/fil.c:887 #10 0xc017d124 in ip_output (m0=0xc0a48f00, opt=0x0, ro=0xd892fd14, flags=0, ---Type <return> to continue, or q <return> to quit--- imo=0x0) at ../../netinet/ip_output.c:437 #11 0xc017b416 in icmp_send (m=0xc0a48f00, opts=0x0) at ../../netinet/ip_icmp.c:753 #12 0xc017b397 in icmp_reflect (m=0xc0a48f00) at ../../netinet/ip_icmp.c:715 #13 0xc017acbd in icmp_error (n=0xc099e900, type=3, code=3, dest=0, destifp=0x0) at ../../netinet/ip_icmp.c:225 #14 0xc0185be4 in udp_input (m=0xc099e900, off=20, proto=17) at ../../netinet/udp_usrreq.c:364 #15 0xc017bdcb in ip_input (m=0xc099e900) at ../../netinet/ip_input.c:731 #16 0xc017be2b in ipintr () at ../../netinet/ip_input.c:759 #17 0xc01f69d5 in swi_net_next () #18 0xc0153881 in sendit (p=0xd884f6c0, s=4, mp=0xd892ff10, flags=0) at ../../kern/uipc_syscalls.c:520 #19 0xc0153975 in sendto (p=0xd884f6c0, uap=0xd892ff80) at ../../kern/uipc_syscalls.c:572 #20 0xc020070d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134594596, tf_esi = 4, tf_ebp = -1077937012, tf_isp = -661454892, tf_ebx = 134569988, tf_edx = 134594560, tf_ecx = -37, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671903036, tf_cs = 31, tf_eflags = 514, tf_esp = -1077937104, tf_ss = 47}) at ../../i386/i386/trap.c:1150 #21 0xc01f5575 in Xint0x80_syscall () Cannot access memory at address 0xbfbffc8c. (kgdb) disassemble fr_makefrip Dump of assembler code for function fr_makefrip: 0xc0188174 <fr_makefrip>: push %ebp 0xc0188175 <fr_makefrip+1>: mov %esp,%ebp 0xc0188177 <fr_makefrip+3>: sub $0x2c,%esp 0xc018817a <fr_makefrip+6>: push %edi 0xc018817b <fr_makefrip+7>: push %esi 0xc018817c <fr_makefrip+8>: push %ebx 0xc018817d <fr_makefrip+9>: mov 0xc(%ebp),%edi 0xc0188180 <fr_makefrip+12>: mov 0x10(%ebp),%ecx 0xc0188183 <fr_makefrip+15>: movw $0x0,0xfffffffe(%ebp) 0xc0188189 <fr_makefrip+21>: movw $0x0,0xfffffffc(%ebp) 0xc018818f <fr_makefrip+27>: movw $0x0,0xfffffff8(%ebp) 0xc0188195 <fr_makefrip+33>: lea 0x4(%ecx),%eax 0xc0188198 <fr_makefrip+36>: mov %eax,0xffffffec(%ebp) 0xc018819b <fr_makefrip+39>: movb $0x0,0x35(%ecx) 0xc018819f <fr_makefrip+43>: movl $0x0,0x40(%ecx) 0xc01881a6 <fr_makefrip+50>: movb $0x0,0x38(%ecx) 0xc01881aa <fr_makefrip+54>: movw $0x0,0x30(%ecx) 0xc01881b0 <fr_makefrip+60>: movw $0x0,0x32(%ecx) 0xc01881b6 <fr_makefrip+66>: movw $0xffff,0x3a(%ecx) 0xc01881bc <fr_makefrip+72>: movl $0xffffffff,0x3c(%ecx) 0xc01881c3 <fr_makefrip+79>: mov 0xc023c7f0,%al 0xc01881c8 <fr_makefrip+84>: mov %al,0x39(%ecx) 0xc01881cb <fr_makefrip+87>: movzbl 0x4(%ecx),%eax 0xc01881cf <fr_makefrip+91>: and $0xf,%eax 0xc01881d2 <fr_makefrip+94>: mov %eax,0xfffffff0(%ebp) 0xc01881d5 <fr_makefrip+97>: andb $0xf0,0x4(%ecx) 0xc01881d9 <fr_makefrip+101>: or %al,0x4(%ecx) 0xc01881dc <fr_makefrip+104>: mov 0x8(%ebp),%edx 0xc01881df <fr_makefrip+107>: mov %dx,0x36(%ecx) 0xc01881e3 <fr_makefrip+111>: cmpl $0x4,0xfffffff0(%ebp) 0xc01881e7 <fr_makefrip+115>: jne 0xc0188298 <fr_makefrip+292> 0xc01881ed <fr_makefrip+121>: movzwl 0x4(%edi),%eax 0xc01881f1 <fr_makefrip+125>: mov %ax,0x4a(%ecx) 0xc01881f5 <fr_makefrip+129>: mov 0x1(%edi),%al 0xc01881f8 <fr_makefrip+132>: mov 0xffffffec(%ebp),%esi 0xc01881fb <fr_makefrip+135>: mov %al,0x1(%esi) 0xc01881fe <fr_makefrip+138>: movzwl 0x6(%edi),%eax 0xc0188202 <fr_makefrip+142>: and $0x1f,%ah 0xc0188205 <fr_makefrip+145>: movzwl %ax,%ebx 0xc0188208 <fr_makefrip+148>: shl $0x3,%ebx 0xc018820b <fr_makefrip+151>: mov 0x8(%ebp),%eax 0xc018820e <fr_makefrip+154>: add %edi,%eax 0xc0188210 <fr_makefrip+156>: mov %eax,0xffffffe4(%ebp) 0xc0188213 <fr_makefrip+159>: movzwl 0x8(%edi),%eax 0xc0188217 <fr_makefrip+163>: mov %ax,0x2(%esi) 0xc018821b <fr_makefrip+167>: movl $0x0,0x8(%esi) 0xc0188222 <fr_makefrip+174>: movl $0x0,0xc(%esi) 0xc0188229 <fr_makefrip+181>: movl $0x0,0x10(%esi) 0xc0188230 <fr_makefrip+188>: movl $0x0,0x18(%esi) 0xc0188237 <fr_makefrip+195>: movl $0x0,0x1c(%esi) 0xc018823e <fr_makefrip+202>: movl $0x0,0x20(%esi) 0xc0188245 <fr_makefrip+209>: mov 0xc(%edi),%eax 0xc0188248 <fr_makefrip+212>: mov %eax,0x4(%esi) 0xc018824b <fr_makefrip+215>: mov 0x10(%edi),%eax 0xc018824e <fr_makefrip+218>: mov %eax,0x14(%esi) 0xc0188251 <fr_makefrip+221>: movzbl 0x9(%edi),%esi 0xc0188255 <fr_makefrip+225>: cmpl $0x14,0x8(%ebp) 0xc0188259 <fr_makefrip+229>: seta %al 0xc018825c <fr_makefrip+232>: shl $0x4,%al 0xc018825f <fr_makefrip+235>: andb $0xf,0x4(%ecx) 0xc0188263 <fr_makefrip+239>: or %al,0x4(%ecx) 0xc0188266 <fr_makefrip+242>: testl $0x3fff,0x6(%edi) 0xc018826d <fr_makefrip+249>: je 0xc0188286 <fr_makefrip+274> 0xc018826f <fr_makefrip+251>: mov 0x4(%ecx),%al 0xc0188272 <fr_makefrip+254>: shr $0x4,%al 0xc0188275 <fr_makefrip+257>: and $0xff,%eax 0xc018827a <fr_makefrip+262>: or $0x4,%al 0xc018827c <fr_makefrip+264>: shl $0x4,%al 0xc018827f <fr_makefrip+267>: andb $0xf,0x4(%ecx) 0xc0188283 <fr_makefrip+271>: or %al,0x4(%ecx) 0xc0188286 <fr_makefrip+274>: movzwl 0x2(%edi),%edx 0xc018828a <fr_makefrip+278>: mov %edx,%eax 0xc018828c <fr_makefrip+280>: sub 0x8(%ebp),%eax 0xc018828f <fr_makefrip+283>: mov %ax,0x48(%ecx) 0xc0188293 <fr_makefrip+287>: jmp 0xc018830a <fr_makefrip+406> 0xc0188295 <fr_makefrip+289>: lea 0x0(%esi),%esi 0xc0188298 <fr_makefrip+292>: cmpl $0x6,0xfffffff0(%ebp) 0xc018829c <fr_makefrip+296>: jne 0xc018867c <fr_makefrip+1288> 0xc01882a2 <fr_makefrip+302>: xor %ebx,%ebx 0xc01882a4 <fr_makefrip+304>: movzbl 0x6(%edi),%esi 0xc01882a8 <fr_makefrip+308>: mov %esi,%edx 0xc01882aa <fr_makefrip+310>: mov 0xffffffec(%ebp),%eax 0xc01882ad <fr_makefrip+313>: mov %dl,0x3(%eax) 0xc01882b0 <fr_makefrip+316>: mov 0x7(%edi),%al 0xc01882b3 <fr_makefrip+319>: mov 0xffffffec(%ebp),%edx 0xc01882b6 <fr_makefrip+322>: mov %al,0x2(%edx) 0xc01882b9 <fr_makefrip+325>: lea 0x28(%edi),%eax 0xc01882bc <fr_makefrip+328>: mov %eax,0xffffffe4(%ebp) 0xc01882bf <fr_makefrip+331>: mov 0x8(%edi),%eax 0xc01882c2 <fr_makefrip+334>: mov %eax,0x4(%edx) 0xc01882c5 <fr_makefrip+337>: mov 0xc(%edi),%eax 0xc01882c8 <fr_makefrip+340>: mov %eax,0x8(%edx) 0xc01882cb <fr_makefrip+343>: mov 0x10(%edi),%eax 0xc01882ce <fr_makefrip+346>: mov %eax,0xc(%edx) 0xc01882d1 <fr_makefrip+349>: mov 0x14(%edi),%eax 0xc01882d4 <fr_makefrip+352>: mov %eax,0x10(%edx) 0xc01882d7 <fr_makefrip+355>: mov 0x18(%edi),%eax 0xc01882da <fr_makefrip+358>: mov %eax,0x14(%edx) 0xc01882dd <fr_makefrip+361>: mov 0x1c(%edi),%eax 0xc01882e0 <fr_makefrip+364>: mov %eax,0x18(%edx) 0xc01882e3 <fr_makefrip+367>: mov 0x20(%edi),%eax 0xc01882e6 <fr_makefrip+370>: mov %eax,0x1c(%edx) 0xc01882e9 <fr_makefrip+373>: mov 0x24(%edi),%eax 0xc01882ec <fr_makefrip+376>: mov %eax,0x20(%edx) 0xc01882ef <fr_makefrip+379>: movzwl (%edi),%eax 0xc01882f2 <fr_makefrip+382>: mov %ax,0x4a(%ecx) 0xc01882f6 <fr_makefrip+386>: movb $0x0,0x1(%edx) 0xc01882fa <fr_makefrip+390>: andb $0xf,(%edx) 0xc01882fd <fr_makefrip+393>: movzwl 0x4(%edi),%eax 0xc0188301 <fr_makefrip+397>: xchg %ah,%al 0xc0188303 <fr_makefrip+399>: movzwl %ax,%edx 0xc0188306 <fr_makefrip+402>: mov %dx,0x48(%ecx) 0xc018830a <fr_makefrip+406>: mov %bx,0x52(%ecx) 0xc018830e <fr_makefrip+410>: mov %dx,0x50(%ecx) 0xc0188312 <fr_makefrip+414>: mov 0xffffffe4(%ebp),%eax 0xc0188315 <fr_makefrip+417>: mov %eax,0x44(%ecx) 0xc0188318 <fr_makefrip+420>: cmp $0x6,%esi 0xc018831b <fr_makefrip+423>: je 0xc01883dc <fr_makefrip+616> 0xc0188321 <fr_makefrip+429>: jg 0xc0188330 <fr_makefrip+444> 0xc0188323 <fr_makefrip+431>: cmp $0x1,%esi 0xc0188326 <fr_makefrip+434>: je 0xc0188340 <fr_makefrip+460> 0xc0188328 <fr_makefrip+436>: jmp 0xc018850f <fr_makefrip+923> 0xc018832d <fr_makefrip+441>: lea 0x0(%esi),%esi 0xc0188330 <fr_makefrip+444>: cmp $0x11,%esi 0xc0188333 <fr_makefrip+447>: je 0xc0188478 <fr_makefrip+772> 0xc0188339 <fr_makefrip+453>: jmp 0xc018850f <fr_makefrip+923> 0xc018833e <fr_makefrip+458>: mov %esi,%esi 0xc0188340 <fr_makefrip+460>: movl $0x1c,0xffffffd4(%ebp) 0xc0188347 <fr_makefrip+467>: mov 0xffffffe4(%ebp),%esi 0xc018834a <fr_makefrip+470>: mov %esi,0xffffffe0(%ebp) 0xc018834d <fr_makefrip+473>: test %ebx,%ebx 0xc018834f <fr_makefrip+475>: jne 0xc0188392 <fr_makefrip+542> 0xc0188351 <fr_makefrip+477>: cmpb $0x0,(%esi) 0xc0188354 <fr_makefrip+480>: je 0xc018835b <fr_makefrip+487> 0xc0188356 <fr_makefrip+482>: cmpb $0x8,(%esi) 0xc0188359 <fr_makefrip+485>: jne 0xc0188364 <fr_makefrip+496> 0xc018835b <fr_makefrip+487>: movl $0x8,0xffffffd4(%ebp) 0xc0188362 <fr_makefrip+494>: jmp 0xc0188392 <fr_makefrip+542> 0xc0188364 <fr_makefrip+496>: test %ebx,%ebx 0xc0188366 <fr_makefrip+498>: jne 0xc0188392 <fr_makefrip+542> 0xc0188368 <fr_makefrip+500>: mov 0xffffffe0(%ebp),%esi 0xc018836b <fr_makefrip+503>: mov (%esi),%al 0xc018836d <fr_makefrip+505>: add $0xf3,%al 0xc018836f <fr_makefrip+507>: cmp $0x1,%al 0xc0188371 <fr_makefrip+509>: ja 0xc018837c <fr_makefrip+520> 0xc0188373 <fr_makefrip+511>: movl $0x14,0xffffffd4(%ebp) 0xc018837a <fr_makefrip+518>: jmp 0xc0188392 <fr_makefrip+542> 0xc018837c <fr_makefrip+520>: test %ebx,%ebx 0xc018837e <fr_makefrip+522>: jne 0xc0188392 <fr_makefrip+542> 0xc0188380 <fr_makefrip+524>: mov 0xffffffe0(%ebp),%esi 0xc0188383 <fr_makefrip+527>: mov (%esi),%al 0xc0188385 <fr_makefrip+529>: add $0xef,%al 0xc0188387 <fr_makefrip+531>: cmp $0x1,%al 0xc0188389 <fr_makefrip+533>: ja 0xc0188392 <fr_makefrip+542> 0xc018838b <fr_makefrip+535>: movl $0xc,0xffffffd4(%ebp) 0xc0188392 <fr_makefrip+542>: mov 0x8(%ebp),%eax 0xc0188395 <fr_makefrip+545>: add 0xffffffd4(%ebp),%eax 0xc0188398 <fr_makefrip+548>: cmp %eax,%edx 0xc018839a <fr_makefrip+550>: jge 0xc01883a0 <fr_makefrip+556> 0xc018839c <fr_makefrip+552>: test %ebx,%ebx 0xc018839e <fr_makefrip+554>: je 0xc01883a8 <fr_makefrip+564> 0xc01883a0 <fr_makefrip+556>: lea 0xffffffff(%ebx),%eax 0xc01883a3 <fr_makefrip+559>: cmp $0x1a,%eax 0xc01883a6 <fr_makefrip+562>: ja 0xc01883bf <fr_makefrip+587> 0xc01883a8 <fr_makefrip+564>: mov 0xffffffec(%ebp),%edx 0xc01883ab <fr_makefrip+567>: mov (%edx),%al 0xc01883ad <fr_makefrip+569>: shr $0x4,%al 0xc01883b0 <fr_makefrip+572>: and $0xff,%eax 0xc01883b5 <fr_makefrip+577>: or $0x8,%al 0xc01883b7 <fr_makefrip+579>: shl $0x4,%al 0xc01883ba <fr_makefrip+582>: andb $0xf,(%edx) 0xc01883bd <fr_makefrip+585>: or %al,(%edx) 0xc01883bf <fr_makefrip+587>: cmpw $0x1,0x48(%ecx) 0xc01883c4 <fr_makefrip+592>: jbe 0xc018850f <fr_makefrip+923> 0xc01883ca <fr_makefrip+598>: mov 0xffffffe4(%ebp),%esi 0xc01883cd <fr_makefrip+601>: movzwl (%esi),%eax 0xc01883d0 <fr_makefrip+604>: mov %ax,0x30(%ecx) 0xc01883d4 <fr_makefrip+608>: jmp 0xc018850f <fr_makefrip+923> 0xc01883d9 <fr_makefrip+613>: lea 0x0(%esi),%esi 0xc01883dc <fr_makefrip+616>: mov 0xffffffec(%ebp),%esi 0xc01883df <fr_makefrip+619>: mov (%esi),%al 0xc01883e1 <fr_makefrip+621>: shr $0x4,%al 0xc01883e4 <fr_makefrip+624>: and $0xff,%eax 0xc01883e9 <fr_makefrip+629>: or $0x2,%al 0xc01883eb <fr_makefrip+631>: shl $0x4,%al 0xc01883ee <fr_makefrip+634>: andb $0xf,(%esi) 0xc01883f1 <fr_makefrip+637>: or %al,(%esi) 0xc01883f3 <fr_makefrip+639>: cmpl $0x6,0xfffffff0(%ebp) 0xc01883f7 <fr_makefrip+643>: jne 0xc0188414 <fr_makefrip+672> 0xc01883f9 <fr_makefrip+645>: cmp $0x13,%edx 0xc01883fc <fr_makefrip+648>: ja 0xc0188452 <fr_makefrip+734> 0xc01883fe <fr_makefrip+650>: mov (%esi),%al 0xc0188400 <fr_makefrip+652>: shr $0x4,%al 0xc0188403 <fr_makefrip+655>: and $0xff,%eax 0xc0188408 <fr_makefrip+660>: or $0x8,%al 0xc018840a <fr_makefrip+662>: shl $0x4,%al 0xc018840d <fr_makefrip+665>: andb $0xf,(%esi) 0xc0188410 <fr_makefrip+668>: or %al,(%esi) 0xc0188412 <fr_makefrip+670>: jmp 0xc0188452 <fr_makefrip+734> 0xc0188414 <fr_makefrip+672>: cmpl $0x4,0xfffffff0(%ebp) 0xc0188418 <fr_makefrip+676>: jne 0xc0188452 <fr_makefrip+734> 0xc018841a <fr_makefrip+678>: movzwl 0x2(%edi),%edx 0xc018841e <fr_makefrip+682>: movzbl (%edi),%eax 0xc0188421 <fr_makefrip+685>: and $0xf,%eax 0xc0188424 <fr_makefrip+688>: lea 0x14(,%eax,4),%eax 0xc018842b <fr_makefrip+695>: cmp %eax,%edx 0xc018842d <fr_makefrip+697>: jae 0xc0188433 <fr_makefrip+703> 0xc018842f <fr_makefrip+699>: test %ebx,%ebx 0xc0188431 <fr_makefrip+701>: je 0xc018843b <fr_makefrip+711> 0xc0188433 <fr_makefrip+703>: lea 0xffffffff(%ebx),%eax 0xc0188436 <fr_makefrip+706>: cmp $0x12,%eax 0xc0188439 <fr_makefrip+709>: ja 0xc0188452 <fr_makefrip+734> 0xc018843b <fr_makefrip+711>: mov 0xffffffec(%ebp),%edx 0xc018843e <fr_makefrip+714>: mov (%edx),%al 0xc0188440 <fr_makefrip+716>: shr $0x4,%al 0xc0188443 <fr_makefrip+719>: and $0xff,%eax 0xc0188448 <fr_makefrip+724>: or $0x8,%al 0xc018844a <fr_makefrip+726>: shl $0x4,%al 0xc018844d <fr_makefrip+729>: andb $0xf,(%edx) 0xc0188450 <fr_makefrip+732>: or %al,(%edx) 0xc0188452 <fr_makefrip+734>: mov 0xffffffec(%ebp),%esi 0xc0188455 <fr_makefrip+737>: mov (%esi),%al 0xc0188457 <fr_makefrip+739>: shr $0x4,%al 0xc018845a <fr_makefrip+742>: test $0x8,%al 0xc018845c <fr_makefrip+744>: jne 0xc01884ee <fr_makefrip+890> 0xc0188462 <fr_makefrip+750>: test %ebx,%ebx 0xc0188464 <fr_makefrip+752>: jne 0xc018850f <fr_makefrip+923> 0xc018846a <fr_makefrip+758>: mov 0xffffffe4(%ebp),%edx 0xc018846d <fr_makefrip+761>: mov 0xd(%edx),%al 0xc0188470 <fr_makefrip+764>: mov %al,0x38(%ecx) 0xc0188473 <fr_makefrip+767>: jmp 0xc01884ee <fr_makefrip+890> 0xc0188475 <fr_makefrip+769>: lea 0x0(%esi),%esi 0xc0188478 <fr_makefrip+772>: mov 0xffffffec(%ebp),%esi 0xc018847b <fr_makefrip+775>: mov (%esi),%al 0xc018847d <fr_makefrip+777>: shr $0x4,%al 0xc0188480 <fr_makefrip+780>: and $0xff,%eax 0xc0188485 <fr_makefrip+785>: or $0x2,%al 0xc0188487 <fr_makefrip+787>: shl $0x4,%al 0xc018848a <fr_makefrip+790>: andb $0xf,(%esi) 0xc018848d <fr_makefrip+793>: or %al,(%esi) 0xc018848f <fr_makefrip+795>: cmpl $0x6,0xfffffff0(%ebp) 0xc0188493 <fr_makefrip+799>: jne 0xc01884b0 <fr_makefrip+828> 0xc0188495 <fr_makefrip+801>: cmp $0x7,%edx 0xc0188498 <fr_makefrip+804>: ja 0xc01884ee <fr_makefrip+890> 0xc018849a <fr_makefrip+806>: mov (%esi),%al 0xc018849c <fr_makefrip+808>: shr $0x4,%al 0xc018849f <fr_makefrip+811>: and $0xff,%eax 0xc01884a4 <fr_makefrip+816>: or $0x8,%al 0xc01884a6 <fr_makefrip+818>: shl $0x4,%al 0xc01884a9 <fr_makefrip+821>: andb $0xf,(%esi) 0xc01884ac <fr_makefrip+824>: or %al,(%esi) 0xc01884ae <fr_makefrip+826>: jmp 0xc01884ee <fr_makefrip+890> 0xc01884b0 <fr_makefrip+828>: cmpl $0x4,0xfffffff0(%ebp) 0xc01884b4 <fr_makefrip+832>: jne 0xc01884ee <fr_makefrip+890> 0xc01884b6 <fr_makefrip+834>: movzwl 0x2(%edi),%edx 0xc01884ba <fr_makefrip+838>: movzbl (%edi),%eax 0xc01884bd <fr_makefrip+841>: and $0xf,%eax 0xc01884c0 <fr_makefrip+844>: lea 0x8(,%eax,4),%eax 0xc01884c7 <fr_makefrip+851>: cmp %eax,%edx 0xc01884c9 <fr_makefrip+853>: jae 0xc01884cf <fr_makefrip+859> 0xc01884cb <fr_makefrip+855>: test %ebx,%ebx 0xc01884cd <fr_makefrip+857>: je 0xc01884d7 <fr_makefrip+867> 0xc01884cf <fr_makefrip+859>: lea 0xffffffff(%ebx),%eax 0xc01884d2 <fr_makefrip+862>: cmp $0x6,%eax 0xc01884d5 <fr_makefrip+865>: ja 0xc01884ee <fr_makefrip+890> 0xc01884d7 <fr_makefrip+867>: mov 0xffffffec(%ebp),%edx 0xc01884da <fr_makefrip+870>: mov (%edx),%al 0xc01884dc <fr_makefrip+872>: shr $0x4,%al 0xc01884df <fr_makefrip+875>: and $0xff,%eax 0xc01884e4 <fr_makefrip+880>: or $0x8,%al 0xc01884e6 <fr_makefrip+882>: shl $0x4,%al 0xc01884e9 <fr_makefrip+885>: andb $0xf,(%edx) 0xc01884ec <fr_makefrip+888>: or %al,(%edx) 0xc01884ee <fr_makefrip+890>: test %ebx,%ebx 0xc01884f0 <fr_makefrip+892>: jne 0xc018850f <fr_makefrip+923> 0xc01884f2 <fr_makefrip+894>: cmpw $0x3,0x48(%ecx) 0xc01884f7 <fr_makefrip+899>: jbe 0xc018850f <fr_makefrip+923> 0xc01884f9 <fr_makefrip+901>: mov 0xffffffe4(%ebp),%esi 0xc01884fc <fr_makefrip+904>: movzwl (%esi),%eax 0xc01884ff <fr_makefrip+907>: xchg %ah,%al 0xc0188501 <fr_makefrip+909>: mov %ax,0x30(%ecx) 0xc0188505 <fr_makefrip+913>: movzwl 0x2(%esi),%eax 0xc0188509 <fr_makefrip+917>: xchg %ah,%al 0xc018850b <fr_makefrip+919>: mov %ax,0x32(%ecx) 0xc018850f <fr_makefrip+923>: cmpl $0x6,0xfffffff0(%ebp) 0xc0188513 <fr_makefrip+927>: jne 0xc0188530 <fr_makefrip+956> 0xc0188515 <fr_makefrip+929>: mov 0xffffffec(%ebp),%eax 0xc0188518 <fr_makefrip+932>: movl $0x0,0x24(%eax) 0xc018851f <fr_makefrip+939>: movw $0x0,0x28(%eax) 0xc0188525 <fr_makefrip+945>: movw $0x0,0x2a(%eax) 0xc018852b <fr_makefrip+951>: jmp 0xc018867c <fr_makefrip+1288> 0xc0188530 <fr_makefrip+956>: add $0x14,%edi 0xc0188533 <fr_makefrip+959>: addl $0xffffffec,0x8(%ebp) 0xc0188537 <fr_makefrip+963>: jmp 0xc0188615 <fr_makefrip+1185> 0xc018853c <fr_makefrip+968>: mov $0x9,%ebx 0xc0188541 <fr_makefrip+973>: mov $0x4,%ecx 0xc0188546 <fr_makefrip+978>: movzwl 0xc023c9d8,%edx 0xc018854d <fr_makefrip+985>: mov %dx,0xffffffdc(%ebp) 0xc0188551 <fr_makefrip+989>: lea 0x0(%esi),%esi 0xc0188554 <fr_makefrip+992>: lea 0x0(,%ebx,8),%eax 0xc018855b <fr_makefrip+999>: lea 0xc023c920(%eax),%esi 0xc0188561 <fr_makefrip+1005>: mov 0xffffffeb(%ebp),%dl 0xc0188564 <fr_makefrip+1008>: cmp 0xc023c920(%eax),%dl 0xc018856a <fr_makefrip+1014>: jne 0xc01885f4 <fr_makefrip+1152> 0xc0188570 <fr_makefrip+1020>: movzwl 0x4(%esi),%esi 0xc0188574 <fr_makefrip+1024>: or %si,0xfffffffe(%ebp) 0xc0188578 <fr_makefrip+1028>: cmp $0x82,%dl 0xc018857b <fr_makefrip+1031>: jne 0xc018860d <fr_makefrip+1177> 0xc0188581 <fr_makefrip+1037>: mov 0x2(%edi),%al 0xc0188584 <fr_makefrip+1040>: mov %al,0xffffffdf(%ebp) 0xc0188587 <fr_makefrip+1043>: mov $0x3,%esi 0xc018858c <fr_makefrip+1048>: mov $0x2,%ebx 0xc0188591 <fr_makefrip+1053>: mov $0xc023c9d8,%ecx 0xc0188596 <fr_makefrip+1058>: movzbw 0xffffffdf(%ebp),%ax 0xc018859b <fr_makefrip+1063>: cmp 0xffffffdc(%ebp),%ax 0xc018859f <fr_makefrip+1067>: je 0xc01885d4 <fr_makefrip+1120> 0xc01885a1 <fr_makefrip+1069>: lea 0x0(%esi),%esi 0xc01885a4 <fr_makefrip+1072>: movzbw 0xffffffdf(%ebp),%ax 0xc01885a9 <fr_makefrip+1077>: cmp (%ecx),%ax 0xc01885ac <fr_makefrip+1080>: jae 0xc01885b4 <fr_makefrip+1088> 0xc01885ae <fr_makefrip+1082>: sub %ebx,%esi 0xc01885b0 <fr_makefrip+1084>: jmp 0xc01885b6 <fr_makefrip+1090> 0xc01885b2 <fr_makefrip+1086>: mov %esi,%esi 0xc01885b4 <fr_makefrip+1088>: add %ebx,%esi 0xc01885b6 <fr_makefrip+1090>: dec %ebx 0xc01885b7 <fr_makefrip+1091>: js 0xc018860d <fr_makefrip+1177> 0xc01885b9 <fr_makefrip+1093>: lea 0x0(,%esi,8),%edx 0xc01885c0 <fr_makefrip+1100>: lea 0xc023c9c0(%edx),%ecx 0xc01885c6 <fr_makefrip+1106>: movzbw 0xffffffdf(%ebp),%ax 0xc01885cb <fr_makefrip+1111>: cmp 0xc023c9c0(%edx),%ax 0xc01885d2 <fr_makefrip+1118>: jne 0xc01885a4 <fr_makefrip+1072> 0xc01885d4 <fr_makefrip+1120>: movzwl 0x4(%ecx),%ecx 0xc01885d8 <fr_makefrip+1124>: or %cx,0xfffffffc(%ebp) 0xc01885dc <fr_makefrip+1128>: movzbl 0x3(%edi),%eax 0xc01885e0 <fr_makefrip+1132>: shl $0x8,%eax 0xc01885e3 <fr_makefrip+1135>: mov %ax,0xfffffff8(%ebp) 0xc01885e7 <fr_makefrip+1139>: movzbw 0x4(%edi),%ax 0xc01885ec <fr_makefrip+1144>: add %ax,0xfffffff8(%ebp) 0xc01885f0 <fr_makefrip+1148>: jmp 0xc018860d <fr_makefrip+1177> 0xc01885f2 <fr_makefrip+1150>: mov %esi,%esi 0xc01885f4 <fr_makefrip+1152>: movzbw 0xffffffeb(%ebp),%ax 0xc01885f9 <fr_makefrip+1157>: cmp (%esi),%ax 0xc01885fc <fr_makefrip+1160>: jae 0xc0188604 <fr_makefrip+1168> 0xc01885fe <fr_makefrip+1162>: sub %ecx,%ebx 0xc0188600 <fr_makefrip+1164>: jmp 0xc0188606 <fr_makefrip+1170> 0xc0188602 <fr_makefrip+1166>: mov %esi,%esi 0xc0188604 <fr_makefrip+1168>: add %ecx,%ebx 0xc0188606 <fr_makefrip+1170>: dec %ecx 0xc0188607 <fr_makefrip+1171>: jns 0xc0188554 <fr_makefrip+992> 0xc018860d <fr_makefrip+1177>: mov 0xfffffff4(%ebp),%edx 0xc0188610 <fr_makefrip+1180>: sub %edx,0x8(%ebp) 0xc0188613 <fr_makefrip+1183>: add %edx,%edi 0xc0188615 <fr_makefrip+1185>: cmpl $0x0,0x8(%ebp) 0xc0188619 <fr_makefrip+1189>: jle 0xc0188651 <fr_makefrip+1245> 0xc018861b <fr_makefrip+1191>: mov (%edi),%al 0xc018861d <fr_makefrip+1193>: mov %al,0xffffffeb(%ebp) 0xc0188620 <fr_makefrip+1196>: test %al,%al 0xc0188622 <fr_makefrip+1198>: je 0xc0188651 <fr_makefrip+1245> 0xc0188624 <fr_makefrip+1200>: cmp $0x1,%al 0xc0188626 <fr_makefrip+1202>: jne 0xc0188634 <fr_makefrip+1216> 0xc0188628 <fr_makefrip+1204>: movl $0x1,0xfffffff4(%ebp) 0xc018862f <fr_makefrip+1211>: jmp 0xc018853c <fr_makefrip+968> 0xc0188634 <fr_makefrip+1216>: cmpl $0x1,0x8(%ebp) 0xc0188638 <fr_makefrip+1220>: jle 0xc0188651 <fr_makefrip+1245> 0xc018863a <fr_makefrip+1222>: movzbl 0x1(%edi),%edx 0xc018863e <fr_makefrip+1226>: mov %edx,0xfffffff4(%ebp) 0xc0188641 <fr_makefrip+1229>: cmp $0x1,%edx 0xc0188644 <fr_makefrip+1232>: jle 0xc0188651 <fr_makefrip+1245> 0xc0188646 <fr_makefrip+1234>: mov 0x8(%ebp),%esi 0xc0188649 <fr_makefrip+1237>: cmp %esi,%edx 0xc018864b <fr_makefrip+1239>: jle 0xc018853c <fr_makefrip+968> 0xc0188651 <fr_makefrip+1245>: cmpw $0x0,0xfffffff8(%ebp) 0xc0188656 <fr_makefrip+1250>: je 0xc0188664 <fr_makefrip+1264> 0xc0188658 <fr_makefrip+1252>: mov 0xfffffff8(%ebp),%eax 0xc018865b <fr_makefrip+1255>: test $0x1,%ah 0xc018865e <fr_makefrip+1258>: jne 0xc0188664 <fr_makefrip+1264> 0xc0188660 <fr_makefrip+1260>: movb $0x0,0xfffffff8(%ebp) 0xc0188664 <fr_makefrip+1264>: movzwl 0xfffffffe(%ebp),%eax 0xc0188668 <fr_makefrip+1268>: mov 0xffffffec(%ebp),%edx 0xc018866b <fr_makefrip+1271>: mov %eax,0x24(%edx) 0xc018866e <fr_makefrip+1274>: mov 0xfffffffc(%ebp),%esi 0xc0188671 <fr_makefrip+1277>: mov %si,0x28(%edx) 0xc0188675 <fr_makefrip+1281>: mov 0xfffffff8(%ebp),%eax 0xc0188678 <fr_makefrip+1284>: mov %ax,0x2a(%edx) 0xc018867c <fr_makefrip+1288>: pop %ebx 0xc018867d <fr_makefrip+1289>: pop %esi 0xc018867e <fr_makefrip+1290>: pop %edi 0xc018867f <fr_makefrip+1291>: leave 0xc0188680 <fr_makefrip+1292>: ret End of assembler dump. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 21:28: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (frankenrouter.softweyr.com [204.68.178.1]) by hub.freebsd.org (Postfix) with ESMTP id 3F77C37B4C5 for <freebsd-hackers@freebsd.org>; Thu, 23 Nov 2000 21:27:59 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13yprl-00034b-00; Wed, 22 Nov 2000 23:28:17 -0700 Message-ID: <3A1CB901.9503129@softweyr.com> Date: Wed, 22 Nov 2000 23:28:17 -0700 From: Wes Peters <wes@softweyr.com> Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mikko Tyolajarvi <mikko@dynas.se> Cc: wollman@khavrinen.lcs.mit.edu, freebsd-hackers@freebsd.org Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch References: <1470.974928159@critter> <200011222239.RAA48717@khavrinen.lcs.mit.edu> <200011222320.eAMNKDx45514@explorer.rsa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikko Tyolajarvi wrote: > > In local.freebsd-current you write: > > ><<On Wed, 22 Nov 2000 22:22:39 +0100, Poul-Henning Kamp <phk@critter.freebsd.dk> said: > > >> Another particular thing I remember was that some syslog-challenged > >> daemons whine on /dev/console long after /etc/rc has finished. > > >They can try, but by the time they do the console has already been > >revoke()d, so they no longer have access to the real console. > > >I've thought about writing daemon(8) which will put these turkeys in > >their place. Just a Small Matter of Programming.... > > Do you mean something like this? Yeah, something like that, except it should restart the named daemon if it exits for any reason. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 21:29:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (frankenrouter.softweyr.com [204.68.178.1]) by hub.freebsd.org (Postfix) with ESMTP id E01EF37B479 for <hackers@freebsd.org>; Thu, 23 Nov 2000 21:29:23 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13ypcM-0002I9-00; Wed, 22 Nov 2000 23:12:22 -0700 Message-ID: <3A1CB545.647AC073@softweyr.com> Date: Wed, 22 Nov 2000 23:12:21 -0700 From: Wes Peters <wes@softweyr.com> Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon <dillon@earth.backplane.com> Cc: Robert Nordier <rnordier@nordier.com>, "Daniel C. Sobral" <dcs@newsguy.com>, Garance A Drosihn <drosih@rpi.edu>, hackers@FreeBSD.ORG Subject: Re: fclose vs ferror (from libc/getcap) References: <200011221225.OAA04292@siri.nordier.com> <200011221736.eAMHaBK13156@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > [...] > > In today's world the standard is: When you free() something, that's it.. > it's gone. When you fclose() something or otherwise terminate a > structure, it's gone. Anything else is illegal. *internally* our libc > assumes that ferror() is legal after an fclose() because, well, it's > true... but only for internal library functions. Nobody outside the > library can legally make that assumption and it could also be argued > that even within the library those types of assumptions should not be > made unless absolutely necessary. > > There isn't much we can do about the issue except fix the instances > of mis-programming as they show up. An excellent summary of what is and what should be. If we wanted to be anally retentive, we could bzero the FILE after completing the close() operation, just to "help" poorly written programs core... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Nov 23 22:22:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from web111.yahoomail.com (web111.mail.yahoo.com [205.180.60.81]) by hub.freebsd.org (Postfix) with SMTP id 87B2D37B479 for <hackers@FreeBSD.ORG>; Thu, 23 Nov 2000 22:22:29 -0800 (PST) Received: (qmail 1646 invoked by uid 60001); 24 Nov 2000 06:22:29 -0000 Message-ID: <20001124062229.1645.qmail@web111.yahoomail.com> Received: from [164.164.56.2] by web111.yahoomail.com; Thu, 23 Nov 2000 22:22:29 PST Date: Thu, 23 Nov 2000 22:22:29 -0800 (PST) From: Mohan Krishna P <penumetcha@yahoo.com> Subject: DMA to user process address space!!! To: hackers@FreeBSD.ORG Cc: pmk@sasi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG AFAMUG, all user processes are allocated from the virtual memory. so DMA to that doesn't make sense. but is there some way, i can let the kernel know i am DMAing to an address location and hence keep it in main memory until some x seconds?? here is why we need this. we are writing software for a multi-port switch. it can be used in both managed and unmanaged modes. in managed mode, switch is connected to host through PCI interface. all packets that can't be switched are sent to host. with cach such packet, switch passes information like the source port of the packet, it's priority level, whether the packet is tagged or not etc. in normal operation, driver discards this information and sends the packet to ether_input(). for testing purpose, we would like to have user-level process, which receives packets bypassing the ip stack(it isn't freeBSD way of doing things, but this is only for testing) and verifies the information. if the above thing can't be done, then we will have to move the user-process functionality to driver. Thanks, mohan __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 1:32: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id 82F3A37B479 for <freebsd-hackers@freebsd.org>; Fri, 24 Nov 2000 01:31:57 -0800 (PST) Received: (qmail 2362 invoked from network); 24 Nov 2000 09:31:52 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 24 Nov 2000 09:31:52 -0000 Received: (qmail 18522 invoked from network); 24 Nov 2000 09:32:19 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Nov 2000 09:32:19 -0000 Date: Fri, 24 Nov 2000 10:32:19 +0100 (MET) From: Mikael Hybsch <mhybsch@rsasecurity.com> X-Sender: <micke@spirit.dynas.se> To: <freebsd-hackers@freebsd.org> Subject: 4.2-STABLE takes 35 seconds to probe ata1-master. Message-ID: <Pine.GSO.4.30.0011241006130.15577-100000@spirit.dynas.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I cvsuped RELENG_4 last night on my home machine an now I have a 35 second delay while probing my DVD on ata1-master. Before the upgrade I was running RELENG_4 from around June and it didn't show this behaviour. This is a SMP machine, but the dmesg output below is from a GENERIC kernel I compiled to make sure that I didn't add anything strange. There is a comment in the dmesg output to show where I get the delay. Regards, Mikael. Copyright (c) 1992-2000 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 4.2-STABLE #0: Thu Nov 23 23:07:53 CET 2000 micke@kaka.home.dynas.se:/d/src/sys/compile/GENERIC Calibrating clock(s) ... TSC clock: 400886114 Hz, i8254 clock: 1193114 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR> real memory = 134205440 (131060K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x0044f000 - 0x07ff4fff, 129654784 bytes (31654 pages) avail memory = 126377984 (123416K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f9d80 bios32: Entry = 0xf0530 (c00f0530) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x730 pnpbios: Found PnP BIOS data at 0xc00fd240 pnpbios: Entry = f0000:d270 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ACPI: 000f8070 Preloaded elf kernel "kernel.GENERIC" at 0xc0436000. Pentium Pro MTRR support enabled md0: Malloc disk Creating DISK md0 Math emulator present pci_open(1): mode 1 addr port (0x0cf8) is 0x80010048 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) npx0: <math processor> on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard found-> vendor=0x8086, dev=0x7190, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[10]: type 1, range 32, base e4000000, size 26 found-> vendor=0x8086, dev=0x7191, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[20]: type 1, range 32, base 0000d800, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base 0000d400, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[90]: type 1, range 32, base 0000e800, size 4 found-> vendor=0x8086, dev=0x1229, revid=0x05 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base e2000000, size 12 map[14]: type 1, range 32, base 0000d000, size 5 map[18]: type 1, range 32, base e0000000, size 20 found-> vendor=0x1000, dev=0x000f, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=5 map[10]: type 1, range 32, base 0000b800, size 8 map[14]: type 1, range 32, base df800000, size 8 map[18]: type 1, range 32, base df000000, size 12 found-> vendor=0x1105, dev=0x8300, revid=0x01 class=04-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base de800000, size 20 pci0: <PCI bus> on pcib0 pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0 found-> vendor=0x102b, dev=0x0521, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base e3000000, size 24 map[14]: type 1, range 32, base e1000000, size 14 map[18]: type 1, range 32, base e0800000, size 23 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> (vendor=0x102b, dev=0x0521) at 0.0 irq 11 isab0: <Intel 82371AB PCI to ISA bridge> at device 4.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel PIIX4 ATA33 controller> port 0xd800-0xd80f at device 4.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xd800 ata0: mask=03 status0=50 status1=00 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI probe a=00 b=00 ata0-slave: ATAPI probe a=00 b=00 ata0: mask=03 status0=50 status1=00 ata0-master: ATA probe a=01 b=a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xd808 ata1: mask=03 status0=50 status1=7f ata1: mask=03 ostat0=50 ostat2=7f ata1-master: ATAPI probe a=14 b=eb ----------> Waits here for about 35 seconds. <--------- ata1: mask=01 status0=00 status1=ff ata1: devices=04 ata1: at 0x170 irq 15 on atapci0 uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xd400-0xd41f irq 9 at device 4.2 on pci0 usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: <Intel 82371AB Power management controller> port 0xe800-0xe80f at device 4.3 on pci0 fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xd000-0xd01f mem 0xe0000000-0xe00fffff,0xe2000000-0xe2000fff irq 9 at device 10.0 on pci0 using shared irq9. fxp0: Ethernet address 00:a0:c9:c9:f7:87 bpf: fxp0 attached sym0: <875> port 0xb800-0xb8ff mem 0xdf000000-0xdf000fff,0xdf800000-0xdf8000ff irq 5 at device 11.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. pci0: <unknown card> (vendor=0x1105, dev=0x8300) at 12.0 irq 11 ata-: ata0 exists, using next available unit number ata-: ata1 exists, using next available unit number Trying Read_Port at 203 CTL0043: start dependant CTL0043: adding irq mask 0x20 CTL0043: adding dma mask 0x2 CTL0043: adding dma mask 0x8 CTL0043: adding io range 0x220-0x22f, size=0x10, align=0x1 CTL0043: adding io range 0x330-0x331, size=0x2, align=0x1 CTL0043: adding io range 0x388-0x38b, size=0x4, align=0x1 CTL0043: start dependant CTL0043: adding irq mask 0x6a0 CTL0043: adding dma mask 0xb CTL0043: adding dma mask 0xb CTL0043: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0043: adding io range 0x300-0x331, size=0x2, align=0x30 CTL0043: adding io range 0x388-0x38b, size=0x4, align=0x1 CTL0043: start dependant CTL0043: adding irq mask 0x6a0 CTL0043: adding dma mask 0xb CTL0043: adding dma mask 0xb CTL0043: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0043: adding io range 0x300-0x331, size=0x2, align=0x30 CTL0043: start dependant CTL0043: adding irq mask 0x6a0 CTL0043: adding dma mask 0xb CTL0043: adding dma mask 0xb CTL0043: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0043: start dependant CTL0043: adding irq mask 0x6a0 CTL0043: adding dma mask 0xb CTL0043: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0043: adding io range 0x300-0x331, size=0x2, align=0x10 CTL0043: adding io range 0x388-0x397, size=0x4, align=0x4 CTL0043: start dependant CTL0043: adding irq mask 0x6a0 CTL0043: adding dma mask 0xb CTL0043: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0043: end dependant CTL7005: start dependant CTL7005: adding io range 0x201-0x201, size=0x1, align=0x1 CTL7005: start dependant CTL7005: adding io range 0x200-0x20f, size=0x1, align=0x1 CTL7005: end dependant isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ata2 failed to probe at port 0x1f0 irq 14 on isa0 ata3 failed to probe at port 0x170 irq 15 on isa0 adv0 failed to probe at port 0x330 on isa0 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x330 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x334 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x230 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x234 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x130 bt0: Failed Status Reg Test - ff bt_isa_probe: Probe failed at 0x134 bt0 failed to probe at port 0x134-0x137 on isa0 aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed ff aha0: status reg test failed ff aha0 failed to probe at port 0x134-0x137 on isa0 aic0 failed to probe at port 0x140-0x15f on isa0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 90 03 3c psm: status 90 03 3c psm: status 90 03 3c psm: data 08 00 00 psm: status 00 00 3c psm: status 00 02 64 psm: data 08 00 00 psm: status 00 02 64 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sio0: irq maps: 0x441 0x451 0x441 0x441 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x441 0x449 0x441 0x441 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: <PLIP network interface> on ppbus0 bpf: lp0 attached lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port ppi0: <Parallel I/O> on ppbus0 ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0 fe0 failed to probe at port 0x300-0x31f on isa0 ie0 failed to probe at port 0x300 iomem 0xd0000 irq 10 on isa0 lnc0 failed to probe at port 0x280 irq 10 drq 0 on isa0 cs0 failed to probe at port 0x300 on isa0 sn0 failed to probe at port 0x300 irq 10 on isa0 isa_probe_children: probing PnP devices adv1: Invalid baseport of 0x220 specified. Nearest valid baseport is 0x230. Failing probe. unknown: <Audio> failed to probe at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 10 drq 0,1 on isa0 adv1: Invalid baseport of 0x201 specified. Nearest valid baseport is 0x210. Failing probe. unknown: <Game> failed to probe at port 0x201-0x210 on isa0 BIOS Geometries: 0:03fffe3f 0..1023=1024 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. bpf: faith0 attached bpf: gif0 attached bpf: gif1 attached bpf: gif2 attached bpf: gif3 attached bpf: lo0 attached bpf: ppp0 attached new masks: bio 68c240, tty 63109a, net 67129a bpf: sl0 attached ata0-master: success setting UDMA2 on PIIX4 chip Creating DISK ad0 Creating DISK wd0 ad0: <IBM-DTTA-351010/T56OA73A> ATA-4 disk at ata0-master ad0: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad0: piomode=4 dmamode=2 udmamode=2 cblid=0 ad0: 9671MB <IBM-DTTA-351010> [19650/16/63] at ata0-master UDMA33 ata1-master: piomode=4 dmamode=2 udmamode=-1 dmaflag=1 ata1-master: success setting PIO4 on generic chip acd0: <PHILIPS PCA424D DVD-ROM/A011> DVD-ROM drive at ata1 as master acd0: read 1722KB/s (4134KB/s), 512KB buffer, PIO4 acd0: Reads: CD-R, CD-RW, CD-DA stream, DVD-ROM, DVD-R, packet acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data/audio disc loaded, unlocked Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. Creating DISK da0 pass0 at sym0 bus 0 target 6 lun 0 pass0: <IBM DNES-309170W SA30> Fixed Direct Access SCSI-3 device pass0: Serial Number AJL5E590 pass0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled Mounting root from ufs:/dev/ad0s3a ad0s1: type 0x6, start 63, end = 1028159, size 1028097 : OK ad0s2: type 0x5, start 1028160, end = 5237189, size 4209030 : OK ad0s3: type 0xa5, start 5237190, end = 13623119, size 8385930 : OK ad0s4: type 0xa5, start 13623120, end = 19792079, size 6168960 : OK ad0s5: type 0xb, start 1028223, end = 5237189, size 4208967 : OK da0 at sym0 bus 0 target 6 lun 0 da0: <IBM DNES-309170W SA30> Fixed Direct Access SCSI-3 device da0: Serial Number AJL5E590 da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) start_init: trying /sbin/init da0s1: type 0xa5, start 63, end = 8385929, size 8385867 : OK da0s2: type 0xf, start 8385930, end = 12594959, size 4209030 : OK da0<extended>: type 0x5, start 8386560, end = 12593151, size 4206592 : OK da0s5: type 0x7, start 8386592, end = 12593151, size 4206560 da0s5: C/H/S start 1023/1/1 (16434558) != start 8386592: invalid da0s5: C/H/S end 1023/63/32 (16438495) != end 12593151: invalid -- Mikael Hybsch Email: mhybsch@rsasecurity.com RSA Security AB Phone: +46-8-7250900 Box 10704 Fax: +46-8-6494970 S-121 29 STOCKHOLM, SWEDEN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 2: 6:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E5E937B479; Fri, 24 Nov 2000 02:06:29 -0800 (PST) Received: from localhost (mikulas@localhost) by artax.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA03675; Fri, 24 Nov 2000 11:06:26 +0100 Date: Fri, 24 Nov 2000 11:06:26 +0100 (CET) From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Reply-To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> To: Alan Cox <alc@cs.rice.edu> Cc: Mike Smith <msmith@freebsd.org>, hackers@freebsd.org Subject: Re: page coloring In-Reply-To: <20001123143530.E21300@cs.rice.edu> Message-ID: <Pine.LNX.3.96.1001124110143.3355A-100000@artax.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It skips queue pq[index & PQ_L2_MASK]. > > > > That's correct. The inline function vm_page_list_find() in vm_page.h > has already failed to allocate a page of the desired color, index, > and so _vm_page_list_find() is called to allocate a page of ANY other > color it can find. Oh, yes. I didn't look at that macro. Mikulas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 2:58:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.mobilix.dk (unknown [194.234.53.85]) by hub.freebsd.org (Postfix) with ESMTP id AB06F37B4CF for <freebsd-hackers@freebsd.org>; Fri, 24 Nov 2000 02:58:11 -0800 (PST) Received: from lflat.vas.mobilix.dk (gw-vas.mobilix.net [212.97.206.4]) by mail.mobilix.dk (8.8.7/8.8.7) with ESMTP id MAA07596 for <freebsd-hackers@freebsd.org>; Fri, 24 Nov 2000 12:44:36 +0100 Received: by lflat.vas.mobilix.dk (Postfix, from userid 72044) id 9E510A8B0; Fri, 24 Nov 2000 11:57:37 +0100 (CET) Date: Fri, 24 Nov 2000 11:57:37 +0100 From: Vadim Belman <voland@lflat.org> To: freebsd-hackers@freebsd.org Subject: Another NFS deadlock. Message-ID: <20001124115737.A463@lflat.vas.mobilix.dk> Mail-Followup-To: Vadim Belman <voland@lflat.org>, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems I have an ideal proving ground for testing NFS on deadlocks. As I was reporting before, we have a bunch of web servers for serving customers home pages. And there is a customer which has a webcam page where he has an image updated via ftp. Same time the image is handled by HTTP servers creating collisions. Recently it caused another kind of deadlock in the nfs_vinvalbuf() function where it clashes with another process flushing buffers. Any ideas of where do I dig? Or any solutions? I would appretiate everything. === IdlePTD 2953216 initial pcb at c847000 panic messages: --- --- #0 mi_switch () at ../../kern/kern_synch.c:858 #1 0xc0151861 in tsleep (ident=0xe123ed4a, priority=18, wmesg=0xc022b35b "nfsvinval", timo=0) at ../../kern/kern_synch.c:467 #2 0xc019cb5b in nfs_vinvalbuf (vp=0xe12348c0, flags=1, cred=0xc4f6f880, p=0xdf6753c0, intrflg=1) at ../../nfs/nfs_bio.c:1170 #3 0xc01a4af1 in nfs_open (ap=0xdf6e3e00) at ../../nfs/nfs_vnops.c:489 #4 0xc017ecd7 in vn_open (ndp=0xdf6e3ecc, fmode=1, cmode=420) at vnode_if.h:189 #5 0xc017acc9 in open (p=0xdf6753c0, uap=0xdf6e3f80) at ../../kern/vfs_syscalls.c:994 #6 0xc0209925 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 672342188, tf_ebp = -1077937384, tf_isp = -546422828, tf_ebx = 672285376, tf_edx = 13, tf_ecx = 0, tf_eax = 5, tf_trapno = 7, tf_err = 2, tf_eip = 672034688, tf_cs = 31, tf_eflags = 518, tf_esp = -1077937416, tf_ss = 47}) at ../../i386/i386/trap.c:1126 #7 0xc01fe556 in Xint0x80_syscall () #8 0x805f3b3 in ?? () #9 0x806572e in ?? () #10 0x806108f in ?? () #11 0x806e38d in ?? () #12 0x806e3db in ?? () #13 0x806861c in ?? () #14 0x80687d6 in ?? () #15 0x8068a49 in ?? () #16 0x8068e35 in ?? () #17 0x80693af in ?? () #18 0x804eb51 in ?? () -- /Voland Vadim Belman E-mail: voland@lflat.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 3:24:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from X-server.e-smith.sonnius.yi.org (c18792021.telekabel.chello.nl [212.187.92.21]) by hub.freebsd.org (Postfix) with ESMTP id 1A15B37B4C5 for <freebsd-hackers@FreeBSD.org>; Fri, 24 Nov 2000 03:24:14 -0800 (PST) Received: from sonnius.yi.org (localhost.e-smith.sonnius.yi.org [127.0.0.1]) by X-server.e-smith.sonnius.yi.org (8.11.1/8.11.0) with ESMTP id eAOBOCO08702 for <freebsd-hackers@FreeBSD.org>; Fri, 24 Nov 2000 11:24:13 GMT (envelope-from rob@sonnius.yi.org) Message-ID: <3A1E4FDC.7EA7DE39@sonnius.yi.org> Date: Fri, 24 Nov 2000 11:24:12 +0000 From: robbie <rob@sonnius.yi.org> X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 6:46:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ozz.freebsd.org.ru (ozz.etrust.ru [194.84.67.11]) by hub.freebsd.org (Postfix) with ESMTP id 1FC8037B4CF for <freebsd-hackers@FreeBSD.org>; Fri, 24 Nov 2000 06:46:03 -0800 (PST) Received: (from osa@localhost) by ozz.freebsd.org.ru (8.11.1/8.11.1) id eAOEjsg00520 for freebsd-hackers@FreeBSD.org; Fri, 24 Nov 2000 17:45:54 +0300 (MSK) (envelope-from osa) Date: Fri, 24 Nov 2000 17:45:54 +0300 From: Sergey Osokin <osa@freebsd.org.ru> To: freebsd-hackers@FreeBSD.org Subject: stranges in threads implementation... possible bug? Message-ID: <20001124174554.A473@freebsd.org.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! My friend find some stranges in FreeBSD threads implementation... Here is a "special" code: ===================================== #include <stdio.h> #include <assert.h> #include <string> #include <pthread.h> #include <unistd.h> #include <errno.h> #define Debug(x) printf x extern "C" { typedef void *(*_THR_C_FUNC)(void *args); } typedef void *(*_THR_FUNC)(void *args); /*-----------------------------------------------------------------*/ class Mutex { public: Mutex() { assert(::pthread_mutex_init(&this->lock_, 0) == 0); } ~Mutex (void) { assert(::pthread_mutex_destroy(&this->lock_)==0); } int acquire (void) { return ::pthread_mutex_lock(&this->lock_); } int release (void) { return ::pthread_mutex_unlock (&this->lock_); } pthread_mutex_t lock_; }; /*-----------------------------------------------------------------*/ class Condition { public: Condition (Mutex &m); ~Condition (void); int wait (void); void signal (void); protected: pthread_cond_t cond_; Mutex &mutex_; }; Condition::Condition (Mutex &m) : mutex_ (m) { assert (pthread_cond_init(&this->cond_, 0) == 0); } Condition::~Condition (void) { while(::pthread_cond_destroy(&this->cond_) == -1 && errno == EBUSY) { assert(::pthread_cond_broadcast(&this->cond_) == 0); #ifdef __linux__ ::sched_yield (); #else ::pthread_yield(); #endif } } int Condition::wait (void) { return ::pthread_cond_wait(&this->cond_, &this->mutex_.lock_); } void Condition::signal (void) { assert(::pthread_cond_signal(&this->cond_) == 0); } /*-----------------------------------------------------------------*/ class Guard { public: Guard (Mutex &l); ~Guard (void); private: Mutex *lock_; }; Guard::Guard (Mutex &l) : lock_ (&l) { this->lock_->acquire (); } Guard::~Guard (void) { this->lock_->release (); } /*-----------------------------------------------------------------*/ class _Base_Thread_Adapter { public: _Base_Thread_Adapter (_THR_FUNC user_func, void *arg); void *invoke (void); _THR_C_FUNC entry_point (void) { return entry_point_; } private: _THR_FUNC user_func_; void *arg_; _THR_C_FUNC entry_point_; }; extern "C" void * _thread_adapter (void *args) { _Base_Thread_Adapter *thread_args = (_Base_Thread_Adapter*)args; void *status = thread_args->invoke (); return status; } _Base_Thread_Adapter::_Base_Thread_Adapter (_THR_FUNC user_func, void *arg) : user_func_ (user_func), arg_ (arg), entry_point_ (_thread_adapter) { } void * _Base_Thread_Adapter::invoke (void) { void *(*func)(void *) = this->user_func_; void *arg = this->arg_; delete this; return func(arg); } /*-----------------------------------------------------------------*/ class SS { public: void spawn(); static void run(); static void *WThread( void *data ); }; /*---------------------------------------------------------------------*/ static Mutex CMutex; static Condition Cond(CMutex); static Mutex m1; /*---------------------------------------------------------------------*/ #define REL(m,n) assert(m.release() != -1) #define ACQ(m,n) assert(m.acquire() != -1) /*---------------------------------------------------------------------*/ void * SS::WThread( void *data ) { Cond.signal(); Debug(("run thread...\n")); SS::run(); Debug(("thread ended\n")); return NULL; } /*---------------------------------------------------------------------*/ int thr_create (_THR_FUNC func, void *args) { _Base_Thread_Adapter *thread_args; thread_args = new _Base_Thread_Adapter(func, args); pthread_attr_t attr; if (::pthread_attr_init (&attr) != 0) return -1; ::pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); pthread_t thr_id; assert( ::pthread_create (&thr_id, &attr, thread_args->entry_point(), thread_args) == 0 ); ::pthread_attr_destroy (&attr); } /*---------------------------------------------------------------------*/ void SS::spawn() { #ifdef BAD int rc; Guard guard(m1); // !!! #else Guard guard(m1); // !!! int rc; #endif pthread_attr_t attr; if (::pthread_attr_init (&attr) != 0) return; ::pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); thr_create(SS::WThread, (void *)0); ::pthread_attr_destroy (&attr); ACQ(CMutex, "CMutex"); rc = Cond.wait(); if( rc == -1 ) Debug(("Cond wait failed: %s\n", strerror(errno))); REL(CMutex, "CMutex"); } /*---------------------------------------------------------------------*/ void SS::run() { string s; // !!! string s1; // !!! sleep(1); } /*=====================================================================*/ static void sp_call(SS *ss) { string s; // !!! ss->spawn(); } /*------------------------------------------------------------------*/ int main(int argc, char **argv) { SS ss; sp_call(&ss); sleep(2); Debug(("Exitting...\n")); sleep(3); return 0; } ===================================== and here is is a makefile (use gmake for build): ===================================== Goal: bad good bad: tt.cpp $(CXX) -DBAD tt.cpp -pthread -g -o bad good: tt.cpp $(CXX) tt.cpp -pthread -g -o good ===================================== After build code, try run ./good and ./bad: ===================================== $ ./good run thread... thread ended Exitting... $ ./bad run thread... zsh: segmentation fault (core dumped) ./bad $ ===================================== Thats stranges work in FreeBSD 4.2-STABLE #0: Wed Nov 22 19:25:46 MSK 2000 and FreeBSD 5.0-CURRENT #0: Wed Nov 22 01:23:44 MSK 2000 Any idea? Sergey Osokin, osa@freebsd.org.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 15:31:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 554C037B4C5 for <hackers@freebsd.org>; Fri, 24 Nov 2000 15:31:15 -0800 (PST) Received: from pretoria-33.budapest.interware.hu ([195.70.53.97] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13zSJE-0001RA-00 for <hackers@freebsd.org>; Sat, 25 Nov 2000 00:31:13 +0100 Message-ID: <3A1EFA3F.5EEEE620@elischer.org> Date: Fri, 24 Nov 2000 15:31:11 -0800 From: Julian Elischer <julian@elischer.org> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: hackers@freebsd.org Subject: any ways to look at powerpoint slides? Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have looked in the ports xlhtml seems to extract out the text but it's not exactly easy to see what is in the ppt slides. I've seen ppt presentations moved to some free S/W at usenix and BSDcon.. how was that done? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 15:35:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id C002237B4C5 for <hackers@freebsd.org>; Fri, 24 Nov 2000 15:35:03 -0800 (PST) Received: from pretoria-33.budapest.interware.hu ([195.70.53.97] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13zSMw-0001ed-00 for <hackers@freebsd.org>; Sat, 25 Nov 2000 00:35:03 +0100 Message-ID: <3A1EFB25.46965228@elischer.org> Date: Fri, 24 Nov 2000 15:35:01 -0800 From: Julian Elischer <julian@elischer.org> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: hackers@freebsd.org Subject: oh, and any way to see visio files? Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I forgot, I need to see visio files as well.. no mention of reading them anywhere I have found. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 16: 0:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from valis.worldgate.ca (valis.worldgate.ca [198.161.84.2]) by hub.freebsd.org (Postfix) with ESMTP id 6395237B479 for <hackers@FreeBSD.ORG>; Fri, 24 Nov 2000 16:00:09 -0800 (PST) Received: from worldgate.ca (diskless1.worldgate.ca [198.161.84.128]) by valis.worldgate.ca (8.9.3/8.9.3) with ESMTP id QAA69065; Fri, 24 Nov 2000 16:59:56 -0700 (MST) (envelope-from skafte@worldgate.ca) Message-ID: <3A1F00FA.2728DB52@worldgate.ca> Date: Fri, 24 Nov 2000 16:59:54 -0700 From: Greg Skafte <skafte@worldgate.ca> Organization: WorldGate Inc X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer <julian@elischer.org> Cc: hackers@FreeBSD.ORG Subject: Re: any ways to look at powerpoint slides? References: <3A1EFA3F.5EEEE620@elischer.org> Content-Type: multipart/mixed; boundary="------------9897E113F8E1C848D29240AB" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9897E113F8E1C848D29240AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote: > > I have looked in the ports xlhtml seems to extract out the text > but it's not exactly easy to see what is in the ppt slides. > > I've seen ppt presentations moved to some free S/W at usenix and BSDcon.. > how was that done? > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message Both Star Office & Applix can read ppt depending on the version of Power Point ..... -- Email: skafte@worldgate.ca Voice: +780 413 1910 Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) --------------9897E113F8E1C848D29240AB Content-Type: text/x-vcard; charset=us-ascii; name="skafte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Greg Skafte Content-Disposition: attachment; filename="skafte.vcf" begin:vcard n:Skafte;Greg tel;pager:+1 (780) 491 4791 tel;cell:+1 (780) 718 1570 tel;fax:+1 (780) 421 4929 tel;work:+1 (780) 413 1910 x-mozilla-html:FALSE org:<A HREF="http://www.worldgate.ca"><IMG BORDER=0 SRC="http://dev.worldgate.ca/images/worldgate_black_200_bolder.gif"></A>;Network Operations adr:;;#575 10123 99 Street;Edmonton;Alberta;T5J 3H1;Canada version:2.1 email;internet:Skafte@worldgate.ca title:Operations Manager x-mozilla-cpt:;29088 fn:Greg Skafte end:vcard --------------9897E113F8E1C848D29240AB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 16:17:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 7FC3E37B4C5 for <hackers@freebsd.org>; Fri, 24 Nov 2000 16:17:18 -0800 (PST) Received: from pretoria-33.budapest.interware.hu ([195.70.53.97] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13zT1d-0003tO-00; Sat, 25 Nov 2000 01:17:12 +0100 Message-ID: <3A1F04F2.AB0CDCE@elischer.org> Date: Fri, 24 Nov 2000 16:16:50 -0800 From: Julian Elischer <julian@elischer.org> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Greg Skafte <skafte@worldgate.ca> Cc: hackers@FreeBSD.ORG Subject: Re: any ways to look at powerpoint slides? References: <3A1EFA3F.5EEEE620@elischer.org> <3A1F00FA.2728DB52@worldgate.ca> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Skafte wrote: > > > Both Star Office & Applix can read ppt depending on the version of > Power Point ..... > OK I'm an idiot for not thining of staroffice I forgot it did that.. I already even have it loaded.. people can stop bombarding me now... -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 16:23:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from newmail.netbistro.com (newmail.netbistro.com [204.239.167.35]) by hub.freebsd.org (Postfix) with SMTP id BDE8C37B4CF for <hackers@freebsd.org>; Fri, 24 Nov 2000 16:23:31 -0800 (PST) Received: (qmail 26342 invoked by uid 1020); 25 Nov 2000 00:23:25 -0000 Date: Fri, 24 Nov 2000 16:23:25 -0800 (PST) From: Jon Simola <jon@abccom.bc.ca> X-Sender: jon@newmail.netbistro.com To: hackers@freebsd.org Subject: Broken-by-design USB device? Message-ID: <Pine.BSF.3.96.1001124160514.9801G-100000@newmail.netbistro.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a little USB device that allows Playstation controllers to be used on a PC. If it's plugged in while booting FreeBSD 4.2-RELEASE (the shipped GENERIC kernel), I get: uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xd400-0xd41f irq 3 at device 4.2 on pci0 usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhid0: vendor 0x6666 product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 uhid0: no report descriptor device_probe_and_attach: uhid0 attach returned 6 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc012663a stack pointer = 0x10:0xc044a938 frame pointer = 0x10:0xc044a938 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort After poking around in the uhid and usb code, I'm beginning to think that this adapter is just broken by design. Can someone a bit more familiar with the USB stuff comment on that? Thanks. For identifying what this is, there's not a lot of info available. It shows up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and just has a single 20 pin DIPP chip inside with these markings (looks like a PLA to me): CY7C63000A-PC 9946 G 02 518003 --- Jon Simola <jon@abccom.bc.ca> | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 17: 0:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from doorstop.frotz.net (www.frotz.net [63.203.215.42]) by hub.freebsd.org (Postfix) with ESMTP id 0D8BF37B479 for <hackers@freebsd.org>; Fri, 24 Nov 2000 17:00:30 -0800 (PST) Received: by doorstop.frotz.net (Postfix, from userid 1000) id A21142504A; Fri, 24 Nov 2000 16:58:11 -0800 (PST) Date: Fri, 24 Nov 2000 16:58:11 -0800 From: Brian Swetland <swetland@frotz.net> To: Jon Simola <jon@abccom.bc.ca> Cc: hackers@freebsd.org Subject: Re: Broken-by-design USB device? Message-ID: <20001124165811.A17915@doorstop.frotz.net> References: <Pine.BSF.3.96.1001124160514.9801G-100000@newmail.netbistro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: <Pine.BSF.3.96.1001124160514.9801G-100000@newmail.netbistro.com>; from jon@abccom.bc.ca on Fri, Nov 24, 2000 at 04:23:25PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 24, 2000 at 04:23:25PM -0800, Jon Simola wrote: > After poking around in the uhid and usb code, I'm beginning to think that > this adapter is just broken by design. Can someone a bit more familiar > with the USB stuff comment on that? Thanks. > > For identifying what this is, there's not a lot of info available. It shows > up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and > just has a single 20 pin DIPP chip inside with these markings (looks like a > PLA to me): > CY7C63000A-PC > 9946 G 02 518003 That's a Cypress USB Controller / Microcontroller combo. It's a little 8bit, 128bytes-of-ram cpu with integrated USB support (supports the 8byte-deep control endpoint 0 and an interrupt endpoint (also 8 bytes deep). 90+% of all USB mice use this critter, last I looked. Mayhap the particular device is returning some bogus descriptors that the uhid code is not dealing with well. I haven't mucked about with the *BSD usb support much, but I can say that there are a lot of questionable devices out there and trusting descriptors is a dangerous thing to do... Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 20:39:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 96F6337B4C5 for <hackers@FreeBSD.ORG>; Fri, 24 Nov 2000 20:39:23 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA60876; Fri, 24 Nov 2000 21:37:45 -0700 (MST) (envelope-from ken) Date: Fri, 24 Nov 2000 21:37:45 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Mohan Krishna P <penumetcha@yahoo.com> Cc: hackers@FreeBSD.ORG, pmk@sasi.com Subject: Re: DMA to user process address space!!! Message-ID: <20001124213745.A60779@panzer.kdm.org> References: <20001124062229.1645.qmail@web111.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001124062229.1645.qmail@web111.yahoomail.com>; from penumetcha@yahoo.com on Thu, Nov 23, 2000 at 10:22:29PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 23, 2000 at 22:22:29 -0800, Mohan Krishna P wrote: > > AFAMUG, all user processes are allocated from the > virtual memory. so DMA to that doesn't make sense. but > is there some way, i can let the kernel know i am > DMAing to an address location and hence keep it in > main memory until some x seconds?? > > > here is why we need this. we are writing software for > a multi-port switch. it can be used in both managed > and unmanaged modes. in managed mode, switch is > connected to host through PCI interface. all packets > that can't > be switched are sent to host. with cach such packet, > switch passes information like the source port of the > packet, it's priority level, whether the packet is > tagged or not etc. > > in normal operation, driver discards this information > and sends the packet to ether_input(). for testing > purpose, we would like to have user-level process, > which receives packets bypassing the ip stack(it isn't > freeBSD way of doing things, but this is only for > testing) and verifies the information. > > if the above thing can't be done, then we will have to > move the user-process functionality to driver. You can do what you're proposing, although it isn't clear that that would necessarily be the best thing to do. There are ways to map memory from the kernel's address space into a userland process address space and vice versa. Just for reference, the pass(4) driver maps things from userland into the kernel with the cam_periph_mapmem() function call in sys/cam/cam_periph.c. There are limits on the amount of data that can be mapped into the kernel with that approach. (128K, which is MAXPHYS) Another way to do get userland memory into the kernel is to map it copy on write. You can get kernel memory into userland via page flipping, if the pages are allocated in the kernel in a manner that allows them to be thrown away. Examples of COW (copy on write) mapping and page flipping are available in the code described here: http://people.FreeBSD.org/~ken/zero_copy Page flipping could also be used to get memory from userland into the kernel, although in that case it might need to be a page trade, unless the userland process was designed to never touch that chunk of memory again. One thing about mapping things COW or page flipping is that you can only do that with page-sized chunks of data. Since you are only passing packets into userland for testing purposes, it may not be necessary to have the high performance (or the page size and alignment issues) that you would gain from one of the methods I described. You can probably get by just as well designing a simple character device interface with a poll() routine that would allow you to select(2) on the file descriptor from a userland process, and wake up whenever a packet arrives. Then your driver can just use copyin(9) and copyout(9) to move things back and forth from the userland process into the driver. As you mentioned, another alternative is to implement the test functionality in the driver. Then you wouldn't have to worry about the performance or alignment considerations of moving things between the kernel and userland. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 21:25:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 4305E37B4C5 for <hackers@freebsd.org>; Fri, 24 Nov 2000 21:25:15 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13zXrx-0000YB-00; Fri, 24 Nov 2000 22:27:25 -0700 Message-ID: <3A1F4DBD.1161E7D9@softweyr.com> Date: Fri, 24 Nov 2000 22:27:25 -0700 From: Wes Peters <wes@softweyr.com> Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: any ways to look at powerpoint slides? References: <3A1EFA3F.5EEEE620@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > I have looked in the ports xlhtml seems to extract out the text > but it's not exactly easy to see what is in the ppt slides. > > I've seen ppt presentations moved to some free S/W at usenix and BSDcon.. > how was that done? StarOffice seems to read most PowerPoint presentations. The worst I've seen so far is some ugly fonts, and a lot of slowness. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Nov 24 21:47:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id CD1F237B4CF for <hackers@FreeBSD.org>; Fri, 24 Nov 2000 21:47:15 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id eAP5m5R78381; Fri, 24 Nov 2000 21:48:05 -0800 (PST) (envelope-from kris) Date: Fri, 24 Nov 2000 21:48:04 -0800 From: Kris Kennaway <kris@FreeBSD.org> To: Wes Peters <wes@softweyr.com> Cc: Julian Elischer <julian@elischer.org>, hackers@FreeBSD.org Subject: Re: any ways to look at powerpoint slides? Message-ID: <20001124214804.A78335@citusc17.usc.edu> References: <3A1EFA3F.5EEEE620@elischer.org> <3A1F4DBD.1161E7D9@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A1F4DBD.1161E7D9@softweyr.com>; from wes@softweyr.com on Fri, Nov 24, 2000 at 10:27:25PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 24, 2000 at 10:27:25PM -0700, Wes Peters wrote: > Julian Elischer wrote: > >=20 > > I have looked in the ports xlhtml seems to extract out the text > > but it's not exactly easy to see what is in the ppt slides. > >=20 > > I've seen ppt presentations moved to some free S/W at usenix and BSDcon= .. > > how was that done? >=20 > StarOffice seems to read most PowerPoint presentations. The worst I've > seen so far is some ugly fonts, and a lot of slowness. If you install a truetype-capable font server (XFree86 4.0.1, or xfstt) and use the Microsoft windows fonts, does it get any better? It certainly makes netscape much nicer to use. Kris --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjofUpQACgkQWry0BWjoQKVreACeLhoN0GSwpfN0P6Xb50dajsYH iA0AoOfUlVqKrdR3IxVZ52ilU+aayO5c =/yah -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Nov 25 20:52:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.mail.yahoo.com (smtp2.mail.yahoo.com [128.11.68.32]) by hub.freebsd.org (Postfix) with SMTP id 6E18337B4F9 for <hackers@freebsd.org>; Sat, 25 Nov 2000 20:52:36 -0800 (PST) Received: from host-216-226-229-81.interpacket.net (HELO yahoo.com) (216.226.229.81) by smtp.mail.vip.suc.yahoo.com with SMTP; 26 Nov 2000 04:52:29 -0000 X-Apparently-From: <ycardena@yahoo.com> Message-ID: <3A208949.8F7AA342@yahoo.com> Date: Sat, 25 Nov 2000 22:53:45 -0500 From: "Yonny Cardenas B." <ycardena@yahoo.com> Organization: Universidad de los Andes X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Link error in the system call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I have the following link error adding new system calls to FreeBSD kernel when it uses send() or recv() with sockets. > linking kernel > rtp_unix.o: In function `_sys_send': > rtp_unix.o(.text+0x1c8): undefined reference to `send' Perhaps the problem is the system call's type in syscalls.master file (show it below), because the rtp_unix.c has calls to socket(), connect() and bind() and it doesn't have the same problem. Is the type COMPAT for compatibility with BSD4.3 system calls (COMPAT_43)? Why? You can look below in the files generated from syscalls.master file: init_sysent.c has the "compat" conditional statement for send() and recv(). And syscalls.c has entries "old.send" and "old.recv", for the other sockets system calls are different. What should I do to solve this link error ? Can I change COMPAT type for STD type in syscalls.master without problems? Thanks for your help. /* ---------------- syscalls.master ------------ */ ; Processed to created init_sysent.c, syscalls.c and syscall.h. ; Columns: number type nargs namespc name alt{name,tag,rtyp}/comments ; types: ; STD always included ; COMPAT included on COMPAT #ifdef 97 STD BSD { int socket(int domain, int type, int protocol); } 98 STD BSD { int connect(int s, caddr_t name, int namelen); } 99 CPT_NOA BSD { int accept(int s, caddr_t name, int *anamelen); } \ accept accept_args int 101 COMPAT BSD { int send(int s, caddr_t buf, int len, int flags); } 102 COMPAT BSD { int recv(int s, caddr_t buf, int len, int flags); } 104 STD BSD { int bind(int s, caddr_t name, int namelen); } /* ----------------- init_sysent.c ------------------ */ #ifdef COMPAT_43 #define compat(n, name) n, (sy_call_t *)__CONCAT(o,name) #else #define compat(n, name) 0, (sy_call_t *)nosys #endif { 3, (sy_call_t *)socket }, /* 97 = socket */ { 3, (sy_call_t *)connect }, /* 98 = connect */ { compat(3,accept) }, /* 99 = old accept */ { compat(4,send) }, /* 101 = old send */ { compat(4,recv) }, /* 102 = old recv */ { 3, (sy_call_t *)bind }, /* 104 = bind */ /* ---------------- syscalls.c ---------------- */ "socket", /* 97 = socket */ "connect", /* 98 = connect */ "old.accept", /* 99 = old accept */ "old.send", /* 101 = old send */ "old.recv", /* 102 = old recv */ "bind", /* 104 = bind */ +------------------------------------------------------------------+ | YONNY CARDENAS B. Apartado Aereo 22828 | | Systems Engineer Santafe de Bogota D.C. | | Colombia - South America | | Student M.Sc. Tel: +571 6095477 | | UNIVERSIDAD DE LOS ANDES mailto: y-carden@uniandes.edu.co | | ycardena@computer.org | | ICQ #: 46933750 | +------------------------------------------------------------------+ UNIX is BSD, and FreeBSD is an advanced 4.4BSD __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message