From owner-freebsd-hackers Sun Feb 7 00:04:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA21109 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 00:04:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA21100 for ; Sun, 7 Feb 1999 00:04:54 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id BAA18112; Sun, 7 Feb 1999 01:03:27 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36BD48CE.D055BBD2@softweyr.com> Date: Sun, 07 Feb 1999 01:03:26 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: witr@rwwa.com, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG Subject: Re: more modular rc/init/uninit system... References: <199902062229.PAA21963@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > > :- Yep. I'm not against run states, just against run levels. > > > > > > > > I'm against both! See my earlier remarks about configuration mamagement. > > > > > > How do you propose to solve the Solaris binary compatability > > > problem for commercial Solaris applications that install > > > components into the rc.d directories in order to get them run > > > at the correct time and in the correct order for dependent > > > services requirements? > > > > By writing a port that will install the startup script in the > > right place and modify it as necessary. We really don't have > > to implement the entire brain-dead mess of the SysV init system > > just to start a simple (or even not so simple) application. > > You're in Utah. > > I bet Bob would let you borrow his IBCS2 Sybase for the AT&T > StartServer so you could install it on FreeBSD and make a "port". You're tangetizing again. You asked what we would do to bash the init.d script for a Solaris app to fitting within the new scheme proposed, and I said "write a port that install the startup script in the right place and modify it as necessary." The original question had nothing to do with supporting the actual app, but rather the differences in the system startup scripts. And besides, if I want to run a Sybase server on FreeBSD, I'll use the Linux version, which is much more likely to run on FreeBSD. I don't know about Sybase, but I will be testing both Informix servers, Oracle 8i, and DB2 in the next few months. And I'm certain I'll be able to get the system to start the database at system boot. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 01:47:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA01170 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 01:47:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA01164 for ; Sun, 7 Feb 1999 01:47:32 -0800 (PST) (envelope-from bodkins@prologic.com) Received: from tech-10 (bodkins.slip.rtd.com [198.102.68.27]) by seagull.rtd.com (8.9.2/8.9.2) with SMTP id CAA23683 for ; Sun, 7 Feb 1999 02:47:29 -0700 (MST) Message-ID: <031301be527e$b1a6ad00$0101010a@tech-10> From: "Jim Bodkins" To: Subject: elf ld problem Date: Sun, 7 Feb 1999 02:46:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0310_01BE5244.04A92400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0310_01BE5244.04A92400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry to bother you on this list. I got no response on -questions. I'm = trying to build a unify application, experimentally, using unify solaris = elf libs. I get the following using 3.0-current. .. /usr/libexec/elf/ld: uld.12459: Not enough room for program headers = (allocated 5 , need 6) uld is a unify front end to the linker. Has anyone seen this, or know what it is? (3.0) =20 Jim bodkins@prologic.com =20 ------=_NextPart_000_0310_01BE5244.04A92400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry to bother you on this list. I = got no=20 response on -questions.  I'm=20 trying to build a unify application, experimentally, using unify solaris = elf=20 libs. I get the following using 3.0-current.
..
/usr/libexec/elf/ld: uld.12459: Not = enough room=20 for program headers (allocated 5
, need 6)
 
   uld is a unify front = end to the=20 linker.
   Has anyone seen this, = or know what=20 it is? (3.0)
 
Jim
bodkins@prologic.com
 
 ------=_NextPart_000_0310_01BE5244.04A92400-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 02:44:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06855 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 02:44:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mtu.ru (ns.mtu.ru [195.34.32.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06847; Sun, 7 Feb 1999 02:44:17 -0800 (PST) (envelope-from daktaklakpak@mtu-net.ru) Received: from dial52078.mtu-net.ru (dial52078.mtu-net.ru [195.34.52.78]) by ns.mtu.ru (8.9.1/8.8.8) with ESMTP id NAA19540; Sun, 7 Feb 1999 13:44:13 +0300 (MSK) Date: Sun, 7 Feb 1999 13:43:25 +0300 (MSK) From: Danil Shebunin X-Sender: danil@free-bsd.space To: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: user ppp packet filtering & ipfw 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 Hi! Excuse me about my poor English. I have a question about ppp & ipfw. I connect to my ISP with user ppp. The -alias option is turned on bescause my internal network have an address 192.168.1.x, and ISP assigns a dynamic IPaddr to me. The gateway computer, which also used as dialout server, have address 192.168.1.1 I need to disable any connections to Telnet and port 3000 of gateway from Internet (but enable to connect to these ports from internal network). Also I need to allow/disallow computers of my internal network to connect to Internet via gate. How can I achieve all this? P.S. I have read man 8 ppp and change ppp.conf file. Below I provide a cut from this file. It seems to work. Do I go a right way? ---8<--- #I want to disallow comp 192.168.1.2 to use Internet connection set filter in 0 deny 0/0 192.168.1.2/32 set filter out 0 deny 192.168.1.2/32 0/0 set filter in 1 deny tcp src eq telnet estab set filter out 1 permit tcp dst eq telnet set filter in 2 deny tcp dst eq 3000 set filter in 3 permit tcp src eq 21 estab set filter out 3 permit tcp dst eq 21 set filter in 4 permit tcp src eq 20 dst gt 1023 set filter out 4 permit tcp dst eq 20 set filter in 5 permit tcp src eq 80 estab set filter out 5 permit tcp dst eq 80 set filter in 6 permit udp src eq 53 set filter out 6 permit udp dst eq 53 set filter in 7 permit icmp set filter out 7 permit icmp set filter in 8 permit udp dst gt 33433 set filter out 8 permit udp dst gt 33433 set server +3000 internet --->8--- When the rules calculated, if packet is come from outside (Internet): before IP packet de-aliasing is performed, or after the packet appears in internal network? And what about packet going from inside to outside? Maybe the point is to use ppp packet filtering for external network and ipfw - for internal? Or maybe I can use ipfw for both networks. In this case, how can I specify dynamic IPaddr in ipfw rules. P.P.S. PLEASE, PLEASE, PLEASE Reply to my e-mail also - I do not subscribed on this mailing lists. Thanks, as long as you answer. -- ===---===---===---===---===---=== Have a nice CONNECT! Dan (daktaklakpak@public.mtu.ru) ===---===---===---===---===---=== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 02:44:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07071 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 02:44:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mtu.ru (ns.mtu.ru [195.34.32.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06910; Sun, 7 Feb 1999 02:44:36 -0800 (PST) (envelope-from daktaklakpak@mtu-net.ru) Received: from dial52078.mtu-net.ru (dial52078.mtu-net.ru [195.34.52.78]) by ns.mtu.ru (8.9.1/8.8.8) with ESMTP id NAA19660; Sun, 7 Feb 1999 13:44:33 +0300 (MSK) Date: Sun, 7 Feb 1999 13:43:45 +0300 (MSK) From: Danil Shebunin X-Sender: danil@free-bsd.space To: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: pppctl & windows telnet 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 Hi! Excuse me about my poor English. How can I customize pppctl (or user ppp) for use it with M$ Windows Telnet application. I use port 3000 for controlling user ppp via network. When I use Telnet from Windows: "telnet free-bsd 3000", Telnet shows garbaged screen. And worse, after each character typed the (NL or CR) character added automatically. I can not type any command. Is it a MicroSh%t stuff, or I have to customize something in Free-BSD. Thanks, as long as you answer. P.S. PLEASE, PLEASE, PLEASE Reply to my e-mail also - I'm not subscribed on these mail lists. -- ===---===---===---===---===---=== Have a nice CONNECT! Dan (daktaklakpak@public.mtu.ru) ===---===---===---===---===---=== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 11:12:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29564 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 11:12:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29554 for ; Sun, 7 Feb 1999 11:12:28 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id UAA03423 for freebsd-hackers@freebsd.org; Sun, 7 Feb 1999 20:12:22 +0100 (MET) Message-ID: <19990207201222.A3390@gvr.org> Date: Sun, 7 Feb 1999 20:12:22 +0100 From: Guido van Rooij To: freebsd-hackers@FreeBSD.ORG Subject: struct ipc_perm Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just noticed that our struct ipc_perm looks as follows: struct ipc_perm { ushort cuid; /* creator user id */ ushort cgid; /* creator group id */ ushort uid; /* user id */ ushort gid; /* group id */ ushort mode; /* r/w permission */ ushort seq; /* sequence # (to generate unique msg/sem/shm id) */ key_t key; /* user specified msg/sem/shm key */ }; On SYSV systems, this struct looks as follows: struct ipc_perm { ushort uid; /* user id */ ushort gid; /* group id */ ushort cuid; /* creator user id */ ushort cgid; /* creator group id */ ushort mode; /* r/w permission */ ushort seq; /* sequence # (to generate unique msg/sem/shm id) */ key_t key; /* user specified msg/sem/shm key */ }; Is there any reason why we have that different? Especially since in our ipc.h, we see: /* * SVID compatible ipc.h file */ -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 12:15:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07871 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 12:15:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07860 for ; Sun, 7 Feb 1999 12:15:49 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id PAA07725; Sun, 7 Feb 1999 15:15:37 -0500 (EST) Date: Sun, 7 Feb 1999 15:15:37 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 Reply-To: zhihuizhang To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how process 0 becomes the swapper In-Reply-To: <199902060251.TAA28845@usr02.primenet.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 Sat, 6 Feb 1999, Terry Lambert wrote: > > I am wondering how the swapper code (I think it should be in swap_pager.c > > and vm_swap.c) is associated with the proc0. Proc0 is created by hand in > > init_main.c and machdep.c. Everything is setup there, including VM, > > signal, stack used for stack switch, etc. But the TSS is not fully setup. > > I mean the registers like %eip to indicate the code for process 0. > > > > I maybe dumb to ask this. But a little hint may help me out. Thanks. > > In effect, a "kernel process" is like an NFS nfsiod. It's the > equivalent of a system call that never returns, instead looping > in code in the kernel and only going away when it has to go to > sleep for some reason. > > Because this is the case, it runs on the kernel stack and instruction > pointer, and therefore never needs to run on a user stack and > instruction pointer. > > In practice, you should be able to call the exec code (not the system > call implementation, since a failure would attempt to return to a > non-existant user space) and create a user space process out of > nothing. > > This is basically how the /sbin/init gets started from the kernel. > > > Kernel processes are used for doing things in the kernel that > require a process context, such as calling tsleep() in order to > wait until a page has been read off of disk. > You email gives me another insight into the kernel process which I never think of. Thanks! It does not answer the question in my mind. I look at the source code again and consult the book by Maurice J. Bach (page 280). After some thought, I have come to the following conclusions: (1) Process 0 does not really exist in FreeBSD. It was the swapper somehow. But now proc0 acts only as a proc structure prototype used by fork(). The structure proc0 is never put onto the run queue (although it is put on the allproc queue). (2) The swapin is now done by scheduler() in vm_glue.c which never returns. It may sleep on the proc0 structure. This seems to be the only relation between process 0 and the swapper left from earlier Unix. (3) The swapout is driven by vm daemon. The main routine of it is vm_daemon(). Please comment on my conclusions. Thanks a lot. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 13:18:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15713 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 13:18:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15676; Sun, 7 Feb 1999 13:18:14 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id UAA01693; Sun, 7 Feb 1999 20:59:38 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.2/8.9.2) with ESMTP id UAA38475; Sun, 7 Feb 1999 20:59:26 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902072059.UAA38475@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Danil Shebunin cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: user ppp packet filtering & ipfw In-reply-to: Your message of "Sun, 07 Feb 1999 13:43:25 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Feb 1999 20:59:26 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > When the rules calculated, if packet is come from outside (Internet): > before IP packet de-aliasing is performed, or after the packet appears in > internal network? And what about packet going from inside to outside? filter rules are applied before outgoing stuff is aliased and after incoming stuff is de-aliased. > Maybe the point is to use ppp packet filtering for external network and > ipfw - for internal? Or maybe I can use ipfw for both networks. In this > case, how can I specify dynamic IPaddr in ipfw rules. Use the interface rather than the IP address (via tun0). > P.P.S. PLEASE, PLEASE, PLEASE Reply to my e-mail also - I do not > subscribed on this mailing lists. > > > Thanks, as long as you answer. > > -- > ===---===---===---===---===---=== > Have a nice CONNECT! > Dan (daktaklakpak@public.mtu.ru) > ===---===---===---===---===---=== -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 13:24:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16671 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 13:24:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16403 for ; Sun, 7 Feb 1999 13:22:14 -0800 (PST) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id WAA15102 for hackers@freebsd.org; Sun, 7 Feb 1999 22:22:24 +0100 (MET) (envelope-from kuku) Date: Sun, 7 Feb 1999 22:22:24 +0100 (MET) From: Christoph Kukulies Message-Id: <199902072122.WAA15102@gilberto.physik.RWTH-Aachen.DE> To: hackers@FreeBSD.ORG Subject: portability of shm, mmap, pipes and socket IPC Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone have experience with portability of common IPC mechanisms between Linux 2.x and FreeBSD? I'm trying to estimate the risk of a porting project from Linux to FreeBSD. What peculiarities are there? Incompatibilities between the two OSs WRT to 'clean' implementation of these disciplines? sockets - feature set compatible? pipes - ? named pipes? mmap - stable? limitations? shmxxx - SYSV compatibility? Comments greatly appreciated. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:15:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02379 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:15:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from niobe.ewox.org (ppp035.uio.no [129.240.240.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02303; Sun, 7 Feb 1999 15:15:37 -0800 (PST) (envelope-from des@niobe.ewox.org) Received: (from des@localhost) by niobe.ewox.org (8.9.2/8.9.1) id AAA68765; Mon, 8 Feb 1999 00:16:14 +0100 (CET) (envelope-from des) To: wpaul@FreeBSD.ORG Cc: nsouch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Regarding tcpdump and plip In-Reply-To: From: Dag-Erling Smorgrav Date: 08 Feb 1999 00:16:13 +0100 Message-ID: <86n22pg5z6.fsf@niobe.ewox.org> Lines: 68 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moving over to -hackers...] As I mentioned in earlier correspondance on -current, tcpdump is broken wrt plip connections. The reason for this is that, as I read the code in src/contrib/libpcap/gencode.c, libpcap expect DLT_NULL- type interfaces to produce a four-byte header with the link type in the first two bytes, whereas the PLIP driver produces a two-byte header consisting solely of the link type. The obvious fix is to patch src/sys/dev/ppbus/if_plip.c to announce and use a four-byte header as libpcap expects it to do; I have attached an untested patch which does this. I'm not sure it's the *correct* fix, however, and I have a hunch that it's only a partial fix since it seems that the plip code does not construct a header for incoming packets - if I am correct, then even with the attached patch tcpdump will only show outgoing packets correctly. I'll toy around with it a little to see if I can confirm or deny my hunch, and/or fix it to work in all cases. On a related note, I was rather surprised, when browsing through the ppbus code, to discover that it is based on an older version of the parallell port code than what was then (and is still) in -CURRENT. What caught my attention was that src/sys/dev/ppbus/nlpt.c still uses the old probe code, instead of the new one I wrote about a year ago, which was integrated in revision 1.66 of src/sys/i386/isa/lpt.c on 1998/02/20. There may be other differences as well, but I did not look too closely. Also, the plip code still causes regular panics. I haven't caught a dump yet because my dump device was misconfigured, but I've had at least two plip-related panics on an otherwise perfectly stable system in the last two weeks. I'll send a backtrace as soon as I have one. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: if_plip.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v retrieving revision 1.9 diff -u -r1.9 if_plip.c --- if_plip.c 1999/01/30 15:35:39 1.9 +++ if_plip.c 1999/02/07 22:31:42 @@ -123,7 +123,7 @@ #define CLPIP_SHAKE 0x80 /* This bit toggles between nibble reception */ #define MLPIPHDRLEN CLPIPHDRLEN -#define LPIPHDRLEN 2 /* We send 0x08, 0x00 in front of packet */ +#define LPIPHDRLEN 4 /* We send 0x08, 0x00, 0x00, 0x00 in front of packet */ #define LPIP_SHAKE 0x40 /* This bit toggles between nibble reception */ #if !defined(MLPIPHDRLEN) || LPIPHDRLEN > MLPIPHDRLEN #define MLPIPHDRLEN LPIPHDRLEN @@ -743,11 +743,11 @@ * try to free it or keep a pointer to it). */ struct mbuf m0; - u_short hdr = 0x800; + u_char hdr[4] = { 0x08, 0x00, 0x00, 0x00 }; m0.m_next = m; - m0.m_len = 2; - m0.m_data = (char *)&hdr; + m0.m_len = 4; + m0.m_data = (char *)hdr; bpf_mtap(ifp, &m0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:19:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02761 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:19:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02741; Sun, 7 Feb 1999 15:18:59 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id AAA89043; Mon, 8 Feb 1999 00:18:52 +0100 (CET) (envelope-from des) To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: NIS woes References: <99Feb8.093744est.40330@border.alcanet.com.au> From: Dag-Erling Smorgrav Date: 08 Feb 1999 00:18:50 +0100 In-Reply-To: Peter Jeremy's message of "Mon, 8 Feb 1999 09:47:53 +1100" Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moved to -hackers] Peter Jeremy writes: > Dag-Erling Smorgrav wrote: > > Tcpdump does not work on PLIP links, > Check out http://www.freebsd.org/cgi/query-pr.cgi?pr=7241 > This includes fixes for PLIP in lpt.c, but the code in ppbus/if_plip.c > looks virtually the same. Note that lpt.c with Bill Fenner's patch > did not compile and needed the following additional patch: The first patch in that PR is IMHO incorrect. It introduces a new link type which is identical to DLT_NULL except that it has a two-byte header instead of a four-byte header. In short, it's a big patch that does nothing except break compatibility with other systems that use LBL's bpfilter and libpcap code. The second patch looks quite close to what I had worked out (see my previous post to -hackers), so I'll try it out and commit it if it works. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:32:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04423 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:32:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04398 for ; Sun, 7 Feb 1999 15:32:15 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id QAA19452; Sun, 7 Feb 1999 16:32:01 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36BE2270.364A090F@softweyr.com> Date: Sun, 07 Feb 1999 16:32:00 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bodkins CC: freebsd-hackers@FreeBSD.ORG Subject: Re: elf ld problem References: <031301be527e$b1a6ad00$0101010a@tech-10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Jim Bodkins wrote: > > Sorry to bother you on this list. I got no response on -questions. You're much more likely to get responses if you send actual email, instead of HTML. > I'm trying to build a unify application, experimentally, using unify > solaris elf libs. I get the following using 3.0-current. > .. > /usr/libexec/elf/ld: uld.12459: Not enough room for program headers (allocated 5 > , need 6) > > uld is a unify front end to the linker. > Has anyone seen this, or know what it is? (3.0) Nope. Maybe someone else can answer, now that they can read your message. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:44:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05589 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:44:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA05581; Sun, 7 Feb 1999 15:44:11 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <52197(1)>; Sun, 7 Feb 1999 15:44:06 PST Received: from mango.parc.xerox.com (localhost.parc.xerox.com [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id PAA06579; Sun, 7 Feb 1999 15:44:01 -0800 (PST) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199902072344.PAA06579@mango.parc.xerox.com> To: Dag-Erling Smorgrav cc: wpaul@FreeBSD.ORG, nsouch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-reply-to: Your message of "Sun, 07 Feb 1999 15:16:13 PST." <86n22pg5z6.fsf@niobe.ewox.org> Date: Sun, 7 Feb 1999 15:44:01 PST From: Bill Fenner Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here are some diffs that I wrote ages ago for lpt.c, but never committed because nobody volunteered to test them. They at least demonstrate what tcpdump wants (an int, in host byte order, with AF_INET in it). You could also look at if_sl.c, if_loop.c, etc. Bill Index: lpt.c =================================================================== RCS file: /home/ncvs/src/sys/i386/isa/lpt.c,v retrieving revision 1.72 diff -u -r1.72 lpt.c --- lpt.c 1998/12/10 01:42:32 1.72 +++ lpt.c 1999/02/07 23:39:10 @@ -876,7 +876,7 @@ printf("lp%d: TCP/IP capable interface\n", unit); #if NBPFILTER > 0 - bpfattach(ifp, DLT_NULL, LPIPHDRLEN); + bpfattach(ifp, DLT_NULL, sizeof(u_int)); #endif } /* @@ -1098,6 +1098,25 @@ sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + CLPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) { + /* + * We need to prepend the address family as + * a four byte field. Cons up a dummy header + * to pacify bpf. This is safe because bpf + * will only read from the mbuf (i.e., it won't + * try to free it or keep a pointer to it). + */ + struct mbuf m0; + u_int af = AF_INET; + + m0.m_next = top; + m0.m_len = 4; + m0.m_data = (char *)⁡ + + bpf_mtap(ifp, &m0); + } +#endif IF_ENQUEUE(&ipintrq, top); schednetisr(NETISR_IP); } @@ -1142,16 +1161,30 @@ IF_DROP(&ipintrq); goto done; } -#if NBPFILTER > 0 - if (sc->sc_if.if_bpf) { - bpf_tap(&sc->sc_if, sc->sc_ifbuf, len); - } -#endif len -= LPIPHDRLEN; sc->sc_if.if_ipackets++; sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + LPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) { + /* + * We need to prepend the address family as + * a four byte field. Cons up a dummy header + * to pacify bpf. This is safe because bpf + * will only read from the mbuf (i.e., it won't + * try to free it or keep a pointer to it). + */ + struct mbuf m0; + u_int af = AF_INET; + + m0.m_next = top; + m0.m_len = 4; + m0.m_data = (char *)⁡ + + bpf_mtap(ifp, &m0); + } +#endif IF_ENQUEUE(&ipintrq, top); schednetisr(NETISR_IP); } @@ -1221,6 +1254,26 @@ /* Suspend (on laptops) or receive-errors might have taken us offline */ outb(lpt_ctrl_port, LPC_ENA); +#if NBPFILTER > 0 + if (ifp->if_bpf) { + /* + * We need to prepend the address family as + * a four byte field. Cons up a dummy header + * to pacify bpf. This is safe because bpf + * will only read from the mbuf (i.e., it won't + * try to free it or keep a pointer to it). + */ + struct mbuf m0; + u_int af = AF_INET; + + m0.m_next = m; + m0.m_len = 4; + m0.m_data = (char *)⁡ + + bpf_mtap(ifp, &m0); + } +#endif + if (ifp->if_flags & IFF_LINK0) { if (!(inb(lpt_stat_port) & CLPIP_SHAKE)) { @@ -1330,25 +1383,6 @@ } else { ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; -#if NBPFILTER > 0 - if (ifp->if_bpf) { - /* - * We need to prepend the packet type as - * a two byte field. Cons up a dummy header - * to pacify bpf. This is safe because bpf - * will only read from the mbuf (i.e., it won't - * try to free it or keep a pointer to it). - */ - struct mbuf m0; - u_short hdr = 0x800; - - m0.m_next = m; - m0.m_len = 2; - m0.m_data = (char *)&hdr; - - bpf_mtap(ifp, &m0); - } -#endif } m_freem(m); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:45:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05647 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:45:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05618 for ; Sun, 7 Feb 1999 15:44:59 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40336>; Mon, 8 Feb 1999 10:34:41 +1100 Date: Mon, 8 Feb 1999 10:44:52 +1100 From: Peter Jeremy Subject: Re: Regarding tcpdump and plip To: des@flood.ping.uio.no Cc: hackers@FreeBSD.ORG Message-Id: <99Feb8.103441est.40336@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: >On a related note, I was rather surprised, when browsing through the >ppbus code, to discover that it is based on an older version of the >parallell port code than what was then (and is still) in -CURRENT. This is a problem when we have duplicated code. If you do commit a fix to if_plip.c, could you please commit the equivalent fix to lpt.c. >Also, the plip code still causes regular panics. Probably still PR's i386/5698 and kern/6099 - neither of which seem to be fixed (or fixable :-(). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:55:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06626 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:55:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06600; Sun, 7 Feb 1999 15:54:44 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id AAA89170; Mon, 8 Feb 1999 00:54:39 +0100 (CET) (envelope-from des) To: Bill Fenner Cc: Dag-Erling Smorgrav , wpaul@FreeBSD.ORG, nsouch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902072344.PAA06579@mango.parc.xerox.com> From: Dag-Erling Smorgrav Date: 08 Feb 1999 00:54:39 +0100 In-Reply-To: Bill Fenner's message of "Sun, 7 Feb 1999 15:44:01 PST" Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fenner writes: > Here are some diffs that I wrote ages ago for lpt.c, but never > committed because nobody volunteered to test them. They at least > demonstrate what tcpdump wants (an int, in host byte order, with > AF_INET in it). You could also look at if_sl.c, if_loop.c, etc. I strongly suspect they work for FreeBSD-mode PLIP, and will install and test a similar patch (I can't apply your patch directly since the plip driver has been detached from the parallell port code, so the offsets are all wrong) I also strongly suspect that it is utterly bogus for Crynwr-mode PLIP, but that was already broken. The reason it won't work for Crynwr-mode PLIP is that in Crynwr mode, the plip driver already prepends a fake Ethernet header to every packet, so you end up with a bpf header that says the packet is an IP packet when in fact it's an Ethernet frame which may or may not contain an IP packet. Then again, I may be wrong :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 15:57:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06876 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 15:57:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06871 for ; Sun, 7 Feb 1999 15:57:05 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id AAA89174; Mon, 8 Feb 1999 00:56:59 +0100 (CET) (envelope-from des) To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <99Feb8.103441est.40336@border.alcanet.com.au> From: Dag-Erling Smorgrav Date: 08 Feb 1999 00:56:59 +0100 In-Reply-To: Peter Jeremy's message of "Mon, 8 Feb 1999 10:44:52 +1100" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: > Dag-Erling Smorgrav wrote: > > On a related note, I was rather surprised, when browsing through the > > ppbus code, to discover that it is based on an older version of the > > parallell port code than what was then (and is still) in -CURRENT. > This is a problem when we have duplicated code. If you do commit > a fix to if_plip.c, could you please commit the equivalent fix to > lpt.c. I'm more likely to move lpt.c to the Attic, assuming TPTB will alow it. There's no use for it now that the ppbus code is in. > > Also, the plip code still causes regular panics. > Probably still PR's i386/5698 and kern/6099 - neither of which seem to > be fixed (or fixable :-(). I'm not so sure about that; it used to freeze the system, now it panics instead. I'll try to catch a dump. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 16:02:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07760 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 16:02:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA07737; Sun, 7 Feb 1999 16:02:39 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52229(4)>; Sun, 7 Feb 1999 16:02:31 PST Received: by crevenia.parc.xerox.com id <177534>; Sun, 7 Feb 1999 16:02:20 -0800 From: Bill Fenner To: des@flood.ping.uio.no, fenner@parc.xerox.com Subject: Re: Regarding tcpdump and plip Cc: hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG Message-Id: <99Feb7.160220pst.177534@crevenia.parc.xerox.com> Date: Sun, 7 Feb 1999 16:02:10 PST Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ugh. Can you tell what mode the device is going to be in when you bpf_attach()? (Presumably not). I guess bpf might end up needing a mechanism to change what you told it in bpf_attach(). I wonder what happens if someone's got a bpf open on the device when that happens; probably nothing good... Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 17:40:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22125 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 17:40:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22113; Sun, 7 Feb 1999 17:40:44 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id CAA89706; Mon, 8 Feb 1999 02:40:39 +0100 (CET) (envelope-from des) To: Bill Fenner Cc: hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <99Feb7.160220pst.177534@crevenia.parc.xerox.com> From: Dag-Erling Smorgrav Date: 08 Feb 1999 02:40:39 +0100 In-Reply-To: Bill Fenner's message of "Sun, 7 Feb 1999 16:02:10 PST" Message-ID: Lines: 218 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc:ed to jkh because of the last two paragraphs] Bill Fenner writes: > Ugh. Can you tell what mode the device is going to be in when you > bpf_attach()? (Presumably not). I guess bpf might end up needing > a mechanism to change what you told it in bpf_attach(). I wonder what > happens if someone's got a bpf open on the device when that happens; > probably nothing good... No, I just throw away the fake Ethernet header and put a DLT_NULL header on instead. It's much simpler, and no useful information is lost since the fake Ethernet header in the incoming packet is blank except for the type field, which we reproduce (or rather, translate to AF_INET) in the DLT_NULL header. Whoever originally added bpf support to the lpt driver must have been smoking some really strong stuff. Not only does the current code produce invalid (and therefore useless) bpf packets, but in Crynwr mode it doesn't pass incoming packets to bpf at all! The first of the two attached patches (hopefully) fixes the bpf problem. It compiles and links, but I haven't tested it yet (waiting for make world to complete). The second patch is equivalent to the one committed to lpt.c last February (simplified port probe). It's been in lpt.c long enough to be considered stable, and I'd like to MFC it (and the first patch as well if it turns out OK - it can't possibly make matters worse than they already are) I'd really, *really* like to rip out the lpt driver, since its functionality is completely duplicated by the nlpt and lpip drivers, which seem pretty stable now. Keeping the lpt driver will only result in slowing down ppbus development. I don't think ppbus + nlpt + plip is significantly larger than lpt, so size is not an argument. And if we ever want to rip out lpt, we have to rip it out *now* before 3.1 is released, or we'll have a hard time doing it before 4.0 goes -STABLE in a year or two. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: if_plip.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v retrieving revision 1.9 diff -u -r1.9 if_plip.c --- if_plip.c 1999/01/30 15:35:39 1.9 +++ if_plip.c 1999/02/08 00:25:46 @@ -123,7 +123,7 @@ #define CLPIP_SHAKE 0x80 /* This bit toggles between nibble reception */ #define MLPIPHDRLEN CLPIPHDRLEN -#define LPIPHDRLEN 2 /* We send 0x08, 0x00 in front of packet */ +#define LPIPHDRLEN 4 /* We send AF_INET in front of packet */ #define LPIP_SHAKE 0x40 /* This bit toggles between nibble reception */ #if !defined(MLPIPHDRLEN) || LPIPHDRLEN > MLPIPHDRLEN #define MLPIPHDRLEN LPIPHDRLEN @@ -445,6 +445,26 @@ return (ctrecvl[cl] | ctrecvh[c]); } +#if NBPFILTER > 0 +static void +lptap(struct ifnet *ifp, struct mbuf *m) +{ + /* + * Send a packet through bpf. We need to prepend the address family + * as a four byte field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf (i.e., it won't + * try to free it or keep a pointer to it). + */ + u_int32_t af = AF_INET; + struct mbuf m0; + + m0.m_next = m; + m0.m_len = LPIPHDRLEN; + m0.m_data = (char *)⁡ + bpf_mtap(ifp, &m0); +} +#endif + static void lpintr (int unit) { @@ -504,6 +524,10 @@ sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + CLPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) + lptap(&sc->sc_if, top); +#endif IF_ENQUEUE(&ipintrq, top); schednetisr(NETISR_IP); } @@ -548,18 +572,17 @@ IF_DROP(&ipintrq); goto done; } -#if NBPFILTER > 0 - if (sc->sc_if.if_bpf) { - bpf_tap(&sc->sc_if, sc->sc_ifbuf, len); - } -#endif len -= LPIPHDRLEN; sc->sc_if.if_ipackets++; sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + LPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { - IF_ENQUEUE(&ipintrq, top); - schednetisr(NETISR_IP); +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) + lptap(&sc->sc_if, top); +#endif + IF_ENQUEUE(&ipintrq, top); + schednetisr(NETISR_IP); } } goto done; @@ -734,23 +757,8 @@ ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; #if NBPFILTER > 0 - if (ifp->if_bpf) { - /* - * We need to prepend the packet type as - * a two byte field. Cons up a dummy header - * to pacify bpf. This is safe because bpf - * will only read from the mbuf (i.e., it won't - * try to free it or keep a pointer to it). - */ - struct mbuf m0; - u_short hdr = 0x800; - - m0.m_next = m; - m0.m_len = 2; - m0.m_data = (char *)&hdr; - - bpf_mtap(ifp, &m0); - } + if (ifp->if_bpf) + lptap(ifp, m); #endif } Index: nlpt.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/nlpt.c,v retrieving revision 1.13 diff -u -r1.13 nlpt.c --- nlpt.c 1999/01/27 20:09:19 1.13 +++ nlpt.c 1999/02/08 00:52:13 @@ -221,6 +221,9 @@ } /* + * Probe simplified by replacing multiple loops with a hardcoded + * test pattern - 1999/02/08 des@freebsd.org + * * New lpt port probe Geoff Rehmet - Rhodes University - 14/2/94 * Based partially on Rod Grimes' printer probe * @@ -267,38 +270,29 @@ static int nlpt_detect(struct lpt_data *sc) { - int status; - u_char data; - u_char mask; - int i, error; + static u_char testbyte[18] = { + 0x55, /* alternating zeros */ + 0xaa, /* alternating ones */ + 0xfe, 0xfd, 0xfb, 0xf7, + 0xef, 0xdf, 0xbf, 0x7f, /* walking zero */ + 0x01, 0x02, 0x04, 0x08, + 0x10, 0x20, 0x40, 0x80 /* walking one */ + }; + int i, error, status; status = 1; /* assume success */ if ((error = lpt_request_ppbus(sc, PPB_DONTWAIT))) { printf(LPT_NAME ": cannot alloc ppbus (%d)!\n", error); - status = 0 ; goto end_probe ; - } - - mask = 0xff; - data = 0x55; /* Alternating zeros */ - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - - data = 0xaa; /* Alternating ones */ - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - - for (i = 0; i < 8; i++) { /* Walking zero */ - data = ~(1 << i); - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } + status = 0; + goto end_probe; } - for (i = 0; i < 8; i++) { /* Walking one */ - data = (1 << i); - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - } + for (i = 0; i < 18 && status; i++) + if (!nlpt_port_test(sc, testbyte[i], 0xff)) { + status = 0; + goto end_probe; + } end_probe: /* write 0's to control and data ports */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 17:51:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23254 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 17:51:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23230 for ; Sun, 7 Feb 1999 17:51:36 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id CAA89755; Mon, 8 Feb 1999 02:51:28 +0100 (CET) (envelope-from des) To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <99Feb8.103441est.40336@border.alcanet.com.au> From: Dag-Erling Smorgrav Date: 08 Feb 1999 02:51:28 +0100 In-Reply-To: Peter Jeremy's message of "Mon, 8 Feb 1999 10:44:52 +1100" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy writes: > Dag-Erling Smorgrav wrote: > > Also, the plip code still causes regular panics. > Probably still PR's i386/5698 and kern/6099 - neither of which seem to > be fixed (or fixable :-(). OBTW, guess who originated i386/5698 :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 17:53:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23589 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 17:53:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles91.castles.com [208.214.165.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23520; Sun, 7 Feb 1999 17:52:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA09054; Sun, 7 Feb 1999 17:48:23 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902080148.RAA09054@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav cc: Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-reply-to: Your message of "08 Feb 1999 02:40:39 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Feb 1999 17:48:22 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd really, *really* like to rip out the lpt driver, since its > functionality is completely duplicated by the nlpt and lpip drivers, > which seem pretty stable now. Keeping the lpt driver will only result > in slowing down ppbus development. I don't think ppbus + nlpt + plip > is significantly larger than lpt, so size is not an argument. And if > we ever want to rip out lpt, we have to rip it out *now* before 3.1 is > released, or we'll have a hard time doing it before 4.0 goes -STABLE > in a year or two. This was actually meant to happen a while back, and I should be wearing the pointy hat for it. The last stumbling block was lack of linux-mode compatibility in lpip, which was fixed ages ago. I'm not sure we want to do this so late for 3.1, but it should certainly happen in -current and probably shortly following the 3.1 release. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 18:02:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24779 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 18:02:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24765; Sun, 7 Feb 1999 18:02:17 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id DAA89798; Mon, 8 Feb 1999 03:01:50 +0100 (CET) (envelope-from des) To: Mike Smith Cc: Dag-Erling Smorgrav , Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> From: Dag-Erling Smorgrav Date: 08 Feb 1999 03:01:50 +0100 In-Reply-To: Mike Smith's message of "Sun, 07 Feb 1999 17:48:22 -0800" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: > > I'd really, *really* like to rip out the lpt driver, since its > > functionality is completely duplicated by the nlpt and lpip drivers, > > which seem pretty stable now. > This was actually meant to happen a while back, and I should be wearing > the pointy hat for it. The last stumbling block was lack of linux-mode > compatibility in lpip, which was fixed ages ago. Plip has always had Linux compatibility mode, since the code for plip was taken from lpt, which has had it for at least a year - way longer than ppbus has existed anyway. One interesting anectode is that a friend of mine (Per Kristian Gjermshus, one of the authors of LXR) tried to use PLIP between his home box and his laptop (both RedHat Linux boxen). No workee. His Linux laptop would talk to my FreeBSD laptop just fine, but refused to talk to other Linux boxen, so apparently it's Linux that lacks a Linux compatibility mode, not FreeBSD :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 18:49:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29986 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 18:49:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles91.castles.com [208.214.165.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29954; Sun, 7 Feb 1999 18:49:23 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA09339; Sun, 7 Feb 1999 18:45:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902080245.SAA09339@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav cc: Mike Smith , Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-reply-to: Your message of "08 Feb 1999 03:01:50 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Feb 1999 18:45:02 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith writes: > > > I'd really, *really* like to rip out the lpt driver, since its > > > functionality is completely duplicated by the nlpt and lpip drivers, > > > which seem pretty stable now. > > This was actually meant to happen a while back, and I should be wearing > > the pointy hat for it. The last stumbling block was lack of linux-mode > > compatibility in lpip, which was fixed ages ago. > > Plip has always had Linux compatibility mode, since the code for plip > was taken from lpt, which has had it for at least a year - way longer > than ppbus has existed anyway. lpip didn't correctly interoperate with Linux PLIP - we proved this at Comdex this year. Nicolas subsequently found and fixed the bug (see rev 1.7 of if_lpip.c). > One interesting anectode is that a friend of mine (Per Kristian > Gjermshus, one of the authors of LXR) tried to use PLIP between his > home box and his laptop (both RedHat Linux boxen). No workee. His > Linux laptop would talk to my FreeBSD laptop just fine, but refused to > talk to other Linux boxen, so apparently it's Linux that lacks a Linux > compatibility mode, not FreeBSD :) *laugh* -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 19:22:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA02900 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 19:22:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zippy.dyn.ml.org (pm3-39.ppp.wenet.net [206.15.85.39]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA02865; Sun, 7 Feb 1999 19:21:54 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (localhost [127.0.0.1]) by zippy.dyn.ml.org (8.9.2/8.9.1) with ESMTP id TAA46696; Sun, 7 Feb 1999 19:18:47 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Sun, 7 Feb 1999 19:18:47 -0800 (PST) From: Alex Zepeda To: Dag-Erling Smorgrav cc: Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-Reply-To: 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 8 Feb 1999, Dag-Erling Smorgrav wrote: > I'd really, *really* like to rip out the lpt driver, since its > functionality is completely duplicated by the nlpt and lpip drivers, > which seem pretty stable now. Keeping the lpt driver will only result > in slowing down ppbus development. I don't think ppbus + nlpt + plip > is significantly larger than lpt, so size is not an argument. But doesn't ppbus depend on the SCSI code? I can imagine something like PicoBSD might not want tha that extra bloat.. I know the GENERIC kernel already has the SCSI support compiled in... - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 19:32:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04134 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 19:32:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles91.castles.com [208.214.165.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04075; Sun, 7 Feb 1999 19:31:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id TAA09567; Sun, 7 Feb 1999 19:27:28 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902080327.TAA09567@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Alex Zepeda cc: Dag-Erling Smorgrav , Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-reply-to: Your message of "Sun, 07 Feb 1999 19:18:47 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Feb 1999 19:27:27 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 8 Feb 1999, Dag-Erling Smorgrav wrote: > > > I'd really, *really* like to rip out the lpt driver, since its > > functionality is completely duplicated by the nlpt and lpip drivers, > > which seem pretty stable now. Keeping the lpt driver will only result > > in slowing down ppbus development. I don't think ppbus + nlpt + plip > > is significantly larger than lpt, so size is not an argument. > > But doesn't ppbus depend on the SCSI code? I can imagine something like > PicoBSD might not want tha that extra bloat.. I know the GENERIC kernel > already has the SCSI support compiled in... No. You only need the SCSI code for vpo (parallel-port Zip drives). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 19:53:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA06240 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 19:53:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA06218; Sun, 7 Feb 1999 19:53:28 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id EAA90101; Mon, 8 Feb 1999 04:53:19 +0100 (CET) (envelope-from des) To: Dag-Erling Smorgrav Cc: Bill Fenner , hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: Regarding tcpdump and plip References: <99Feb7.160220pst.177534@crevenia.parc.xerox.com> From: Dag-Erling Smorgrav Date: 08 Feb 1999 04:53:19 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "08 Feb 1999 02:40:39 +0100" Message-ID: Lines: 236 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > The first of the two attached patches (hopefully) fixes the bpf > problem. It compiles and links, but I haven't tested it yet (waiting > for make world to complete). Well, it's 5 am over here and I finally got it licked :) It was a little hairier than I thought because a) I can't just barge in and set LPIPHDRLEN to 4, because it's used by non-bpf-related stuff, and b) the transmit loop in lpoutput() modified the m_len field in each mbuf along the chain *before* passing it on to bpf; the result was a lot of empty packets (all outgoing packets would show up blank in bpf output) Patches are attached. I'll commit them after I get some sleep :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: if_plip.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v retrieving revision 1.9 diff -u -r1.9 if_plip.c --- if_plip.c 1999/01/30 15:35:39 1.9 +++ if_plip.c 1999/02/08 03:32:23 @@ -256,7 +256,7 @@ if_attach(ifp); #if NBPFILTER > 0 - bpfattach(ifp, DLT_NULL, LPIPHDRLEN); + bpfattach(ifp, DLT_NULL, sizeof(u_int32_t)); #endif return (1); @@ -445,6 +445,26 @@ return (ctrecvl[cl] | ctrecvh[c]); } +#if NBPFILTER > 0 +static void +lptap(struct ifnet *ifp, struct mbuf *m) +{ + /* + * Send a packet through bpf. We need to prepend the address family + * as a four byte field. Cons up a dummy header to pacify bpf. This + * is safe because bpf will only read from the mbuf (i.e., it won't + * try to free it or keep a pointer to it). + */ + u_int32_t af = AF_INET; + struct mbuf m0; + + m0.m_next = m; + m0.m_len = sizeof(u_int32_t); + m0.m_data = (char *)⁡ + bpf_mtap(ifp, &m0); +} +#endif + static void lpintr (int unit) { @@ -504,6 +524,10 @@ sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + CLPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) + lptap(&sc->sc_if, top); +#endif IF_ENQUEUE(&ipintrq, top); schednetisr(NETISR_IP); } @@ -548,18 +572,17 @@ IF_DROP(&ipintrq); goto done; } -#if NBPFILTER > 0 - if (sc->sc_if.if_bpf) { - bpf_tap(&sc->sc_if, sc->sc_ifbuf, len); - } -#endif len -= LPIPHDRLEN; sc->sc_if.if_ipackets++; sc->sc_if.if_ibytes += len; top = m_devget(sc->sc_ifbuf + LPIPHDRLEN, len, 0, &sc->sc_if, 0); if (top) { - IF_ENQUEUE(&ipintrq, top); - schednetisr(NETISR_IP); +#if NBPFILTER > 0 + if (sc->sc_if.if_bpf) + lptap(&sc->sc_if, top); +#endif + IF_ENQUEUE(&ipintrq, top); + schednetisr(NETISR_IP); } } goto done; @@ -610,8 +633,7 @@ u_char *cp = "\0\0"; u_char chksum = 0; int count = 0; - int i; - int spin; + int i, len, spin; /* We need a sensible value if we abort */ cp++; @@ -668,7 +690,8 @@ mm = m; do { cp = mtod(mm, u_char *); - while (mm->m_len--) { + len = mm->m_len; + while (len--) { chksum += *cp; if (clpoutbyte(*cp++, LPMAXSPIN2, &sc->lp_dev)) goto nend; @@ -691,6 +714,10 @@ } else { ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; +#if NBPFILTER > 0 + if (ifp->if_bpf) + lptap(ifp, m); +#endif } m_freem(m); @@ -716,7 +743,8 @@ mm = m; do { cp = mtod(mm,u_char *); - while (mm->m_len--) + len = mm->m_len; + while (len--) if (lpoutbyte(*cp++, LPMAXSPIN2, &sc->lp_dev)) goto end; } while ((mm = mm->m_next)); @@ -734,23 +762,8 @@ ifp->if_opackets++; ifp->if_obytes += m->m_pkthdr.len; #if NBPFILTER > 0 - if (ifp->if_bpf) { - /* - * We need to prepend the packet type as - * a two byte field. Cons up a dummy header - * to pacify bpf. This is safe because bpf - * will only read from the mbuf (i.e., it won't - * try to free it or keep a pointer to it). - */ - struct mbuf m0; - u_short hdr = 0x800; - - m0.m_next = m; - m0.m_len = 2; - m0.m_data = (char *)&hdr; - - bpf_mtap(ifp, &m0); - } + if (ifp->if_bpf) + lptap(ifp, m); #endif } Index: nlpt.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/nlpt.c,v retrieving revision 1.13 diff -u -r1.13 nlpt.c --- nlpt.c 1999/01/27 20:09:19 1.13 +++ nlpt.c 1999/02/08 00:52:13 @@ -221,6 +221,9 @@ } /* + * Probe simplified by replacing multiple loops with a hardcoded + * test pattern - 1999/02/08 des@freebsd.org + * * New lpt port probe Geoff Rehmet - Rhodes University - 14/2/94 * Based partially on Rod Grimes' printer probe * @@ -267,38 +270,29 @@ static int nlpt_detect(struct lpt_data *sc) { - int status; - u_char data; - u_char mask; - int i, error; + static u_char testbyte[18] = { + 0x55, /* alternating zeros */ + 0xaa, /* alternating ones */ + 0xfe, 0xfd, 0xfb, 0xf7, + 0xef, 0xdf, 0xbf, 0x7f, /* walking zero */ + 0x01, 0x02, 0x04, 0x08, + 0x10, 0x20, 0x40, 0x80 /* walking one */ + }; + int i, error, status; status = 1; /* assume success */ if ((error = lpt_request_ppbus(sc, PPB_DONTWAIT))) { printf(LPT_NAME ": cannot alloc ppbus (%d)!\n", error); - status = 0 ; goto end_probe ; - } - - mask = 0xff; - data = 0x55; /* Alternating zeros */ - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - - data = 0xaa; /* Alternating ones */ - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - - for (i = 0; i < 8; i++) { /* Walking zero */ - data = ~(1 << i); - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } + status = 0; + goto end_probe; } - for (i = 0; i < 8; i++) { /* Walking one */ - data = (1 << i); - if (!nlpt_port_test(sc, data, mask)) - { status = 0 ; goto end_probe ; } - } + for (i = 0; i < 18 && status; i++) + if (!nlpt_port_test(sc, testbyte[i], 0xff)) { + status = 0; + goto end_probe; + } end_probe: /* write 0's to control and data ports */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 20:57:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11662 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 20:57:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd-daemon.net (bsd-daemon.net [209.90.150.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11657 for ; Sun, 7 Feb 1999 20:57:52 -0800 (PST) (envelope-from pjp@bsd-daemon.net) Received: from localhost (pjp@localhost) by bsd-daemon.net (8.9.1/8.9.1) with SMTP id XAA17781; Sun, 7 Feb 1999 23:56:39 -0500 (EST) Date: Sun, 7 Feb 1999 23:56:39 -0500 (EST) From: Peter Philipp To: Ruslan Ermilov cc: hackers@FreeBSD.ORG Subject: Re: Problems with fstat/netstat in 3.0-STABLE In-Reply-To: <19990204182141.B46126@ucb.crimea.ua> 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 I've seen exactly the same problem but with a 3.0-980804-SNAP, comparing this with a 3.0-980428-SNAP it works. So somewhere between those two snapshots it was broken and probably never noticed. I have found that the difference between the address is higher by 60 hex in an fstat as compared to a netstat -A. It seems it's still off by 60 hex in 3.0-RELEASE. Peter Philipp (PP2441) Daemonic Networks "In theory, theory is the same as practice, but not in practice" - ??? On Thu, 4 Feb 1999, Ruslan Ermilov wrote: > Hi! > > On 2.2.X I was able to do the following: > > # fstat -p 13612 > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W > root telnetd 13612 wd / 2 drwxr-xr-x 512 r > root telnetd 13612 text /usr 61498 -r-xr-xr-x 49152 r > root telnetd 13612 0* internet stream tcp f0b79e00 > root telnetd 13612 1* internet stream tcp f0b79e00 > root telnetd 13612 2* internet stream tcp f0b79e00 > root telnetd 13612 3 / 524 crw-rw-rw- ptyp1 rw > > # netstat -Aan | grep f0b79e00 > f0b79e00 tcp 0 0 212.110.138.4.23 192.168.1.250.1030 ESTABLISHED > > > On 3.0-STABLE it doesn't work for TCP sockets (for udp it works). > Anyone's comments? > > -- > Ruslan Ermilov Sysadmin and DBA of the > ru@ucb.crimea.ua United Commercial Bank > +380.652.247.647 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > 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 Sun Feb 7 22:24:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20228 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 22:24:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd-daemon.net (bsd-daemon.net [209.90.150.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20223 for ; Sun, 7 Feb 1999 22:24:57 -0800 (PST) (envelope-from pjp@bsd-daemon.net) Received: from localhost (pjp@localhost) by bsd-daemon.net (8.9.1/8.9.1) with SMTP id BAA17927; Mon, 8 Feb 1999 01:23:47 -0500 (EST) Date: Mon, 8 Feb 1999 01:23:47 -0500 (EST) From: Peter Philipp To: Ruslan Ermilov cc: hackers@FreeBSD.ORG Subject: Re: Problems with fstat/netstat in 3.0-STABLE In-Reply-To: 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 Ruslan and FreeBSD hackers, I have made a small patch that seems to work. I'm not sure if this is semantically correct but for the functionality that Ruslan was mentioning it seems to do the job. Feel free to stick this in the CVS tree if useful and correct. If not *shrug* no loss. The patch is for inet.c in netstat. *** inet.c.orig Mon Feb 8 01:13:44 1999 --- inet.c Mon Feb 8 01:15:04 1999 *************** *** 171,177 **** first = 0; } if (Aflag) ! printf("%8lx ", (u_long)so->so_pcb); printf("%-5.5s %6ld %6ld ", name, so->so_rcv.sb_cc, so->so_snd.sb_cc); if (nflag) { --- 171,180 ---- first = 0; } if (Aflag) ! if(istcp) ! printf("%8x ", (int)inp->inp_ppcb); ! else ! printf("%8lx ", (u_long)so->so_pcb); printf("%-5.5s %6ld %6ld ", name, so->so_rcv.sb_cc, so->so_snd.sb_cc); if (nflag) { Peter Philipp (PP2441) Daemonic Networks "In theory, theory is the same as practice, but not in practice" - ??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 23:14:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25889 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 23:14:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd-daemon.net (bsd-daemon.net [209.90.150.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25882 for ; Sun, 7 Feb 1999 23:14:28 -0800 (PST) (envelope-from pjp@bsd-daemon.net) Received: from localhost (pjp@localhost) by bsd-daemon.net (8.9.1/8.9.1) with SMTP id CAA18119; Mon, 8 Feb 1999 02:13:26 -0500 (EST) Date: Mon, 8 Feb 1999 02:13:26 -0500 (EST) From: Peter Philipp To: Ruslan Ermilov cc: hackers@FreeBSD.ORG Subject: Re: Problems with fstat/netstat in 3.0-STABLE In-Reply-To: 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 I wrote: > Ruslan and FreeBSD hackers, > > I have made a small patch that seems to work. I'm not sure if this is > semantically correct but for the functionality that Ruslan was mentioning > it seems to do the job. Feel free to stick this in the CVS tree if > useful and correct. If not *shrug* no loss. > > The patch is for inet.c in netstat. > This was the patch for inet.c in version: "$Id: inet.c,v 1.30 1998/07/06 21:01:23 bde Exp $"; The patch I made is almost identical to the an earlier version: "$Id: inet.c,v 1.26 1997/08/25 16:57:05 wollman Exp $"; I only noticed this later. But anyhow I'm correcting myself it seems we already had something similar which was stripped when it got to CVS 1.30. Apologies. My (broken?) patch below. Dunno if I'd use this anymore. :-) > *** inet.c.orig Mon Feb 8 01:13:44 1999 > --- inet.c Mon Feb 8 01:15:04 1999 > *************** > *** 171,177 **** > first = 0; > } > if (Aflag) > ! printf("%8lx ", (u_long)so->so_pcb); > printf("%-5.5s %6ld %6ld ", name, so->so_rcv.sb_cc, > so->so_snd.sb_cc); > if (nflag) { > --- 171,180 ---- > first = 0; > } > if (Aflag) > ! if(istcp) > ! printf("%8x ", (int)inp->inp_ppcb); > ! else > ! printf("%8lx ", (u_long)so->so_pcb); > printf("%-5.5s %6ld %6ld ", name, so->so_rcv.sb_cc, > so->so_snd.sb_cc); > if (nflag) { Peter Philipp (PP2441) Daemonic Networks "In theory, theory is the same as practice, but not in practice" - ??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 7 23:24:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26819 for freebsd-hackers-outgoing; Sun, 7 Feb 1999 23:24:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA26804 for ; Sun, 7 Feb 1999 23:24:31 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 7956 invoked by uid 1001); 8 Feb 1999 07:24:29 +0000 (GMT) To: des@flood.ping.uio.no Cc: fenner@parc.xerox.com, hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: Regarding tcpdump and plip In-Reply-To: Your message of "08 Feb 1999 04:53:19 +0100" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 08 Feb 1999 08:24:29 +0100 Message-ID: <7954.918458669@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dag-Erling Smorgrav writes: > > The first of the two attached patches (hopefully) fixes the bpf > > problem. It compiles and links, but I haven't tested it yet (waiting > > for make world to complete). > > Well, it's 5 am over here and I finally got it licked :) It was a > little hairier than I thought because a) I can't just barge in and set > LPIPHDRLEN to 4, because it's used by non-bpf-related stuff, and b) > the transmit loop in lpoutput() modified the m_len field in each mbuf > along the chain *before* passing it on to bpf; Yup. Already noted by several people, I sent patches for this (among other things) to -current 14. April last year. Search for "Fixes for tcpdump with LPIP encapsulation". Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 01:08:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA07219 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 01:08:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA07191 for ; Mon, 8 Feb 1999 01:08:24 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id LAA40745; Mon, 8 Feb 1999 11:08:07 +0200 (EET) (envelope-from ru) Date: Mon, 8 Feb 1999 11:08:07 +0200 From: Ruslan Ermilov To: FreeBSD Hackers Subject: conf/9555: anyone bother to fix this? Message-ID: <19990208110807.J17722@ucb.crimea.ua> Mail-Followup-To: FreeBSD Hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i X-Operating-System: FreeBSD 3.0-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! Can anyone please commit this before 3.1 is out? Thanks, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 01:36:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA10484 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 01:36:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA10479 for ; Mon, 8 Feb 1999 01:36:28 -0800 (PST) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.1a/8.9.1) id DAA19348 for hackers@freebsd.org; Mon, 8 Feb 1999 03:36:26 -0600 (CST) Message-ID: <19990208033626.A14553@futuresouth.com> Date: Mon, 8 Feb 1999 03:36:26 -0600 From: "Matthew D. Fuller" To: FreeBSD Hackers Subject: Re: conf/9555: anyone bother to fix this? References: <19990208110807.J17722@ucb.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990208110807.J17722@ucb.crimea.ua>; from Ruslan Ermilov on Mon, Feb 08, 1999 at 11:08:07AM +0200 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 08, 1999 at 11:08:07AM +0200, a little birdie told me that Ruslan Ermilov remarked > Hi! > > Can anyone please commit this before 3.1 is out? Speaking of PR's... Could somebody take a look at these two PR's (with patches) before comes the 3.1? They're both fairly unintrusive and fix annoying nit-ish bugs. - bin/9471: msgs: /var/msgs/bounds: No such file or directory - Re: bin/9484: False error while adding a user, whose uid begins with a number, via sysinstall --- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew Fuller http://www.over-yonder.net/~fullermd | * fullermd@futuresouth.com fullermd@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | * is because I haven't figured out how to light the * | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 05:46:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA06012 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 05:46:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.WorldMediaCo.com ([207.252.121.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA06005 for ; Mon, 8 Feb 1999 05:46:06 -0800 (PST) (envelope-from opsys@open-systems.net) Received: from freebsd.omaha.com ([207.252.122.220]) by mail1.WorldMediaCo.com (Post.Office MTA v3.5.3 release 223 ID# 0-55573U2500L250S0V35) with SMTP id com; Mon, 8 Feb 1999 07:39:25 -0600 Date: Mon, 8 Feb 1999 07:45:54 +0000 (GMT) From: "Open Systems Inc." X-Sender: opsys@freebsd.omaha.com To: Bill Fenner cc: "Dirk-Willem van Gulik (vaio)" , Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: Irratic Curve In-Reply-To: <99Feb5.160306pst.177534@crevenia.parc.xerox.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 Fri, 5 Feb 1999, Bill Fenner wrote: > Using the "database of results" from > http://www.scl.ameslab.gov/Projects/Gigabit/ shows that after they > turned off delayed ACKs, the curves were much smoother. This indicates > that the problem is probably the interaction of Nagle, mbuf sizes, and > delayed ACK's, which is fixed in -current and 3.1 . For those interested there was, as of friday. A discussion of re-writing nagle i believe on the tcp-impl list for those interested. Chris -- "Join Team-FreeBSD on cracking RC5-64! grab you client now and HELP OUT! http://www.distributed.net/cgi/select.cgi" ===================================| Open Systems FreeBSD Consulting. FreeBSD 2.2.8 is available now! | Phone: 402-573-9124 -----------------------------------| 3335 N. 103 Plaza #14, Omaha, NE 68134 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting, Network Engineering, Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 06:25:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11055 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 06:25:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA11047 for ; Mon, 8 Feb 1999 06:25:40 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA91422; Mon, 8 Feb 1999 15:25:33 +0100 (CET) (envelope-from des) To: "Matthew D. Fuller" Cc: FreeBSD Hackers Subject: Re: conf/9555: anyone bother to fix this? References: <19990208110807.J17722@ucb.crimea.ua> <19990208033626.A14553@futuresouth.com> From: Dag-Erling Smorgrav Date: 08 Feb 1999 15:25:32 +0100 In-Reply-To: "Matthew D. Fuller"'s message of "Mon, 8 Feb 1999 03:36:26 -0600" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew D. Fuller" writes: > On Mon, Feb 08, 1999 at 11:08:07AM +0200, a little birdie told me > that Ruslan Ermilov remarked > > Can anyone please commit this before 3.1 is out? > Could somebody take a look at these two PR's (with patches) before comes > the 3.1? They're both fairly unintrusive and fix annoying nit-ish bugs. OK, I'll look at 9555, 9471 and 9484 later tonight (Oslo time). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 07:08:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA17620 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 07:08:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA17615 for ; Mon, 8 Feb 1999 07:08:32 -0800 (PST) (envelope-from dennis@etinc.com) Received: from workstation.etinc.com (port53.netsvr1.cst.vastnet.net [207.252.73.53]) by etinc.com (8.8.8/8.6.9) with SMTP id KAA21938 for ; Mon, 8 Feb 1999 10:06:30 -0500 (EST) Message-Id: <199902081506.KAA21938@etinc.com> X-Sender: dennis@mail.etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 08 Feb 1999 10:15:48 -0500 To: hackers@FreeBSD.ORG From: Dennis Subject: fchdir libary problem in 2.2.7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm getting the following error message? /usr/libexec/ld.so: Undefined symbol "_fchdir" called from mysqld:/usr/lib/libc_ r.so.3.0 at 0x201a56a8 Ive loaded the 2.2.7 upgrade to stable package, and still no luck. fchdir seems to be being compiled when I rebuild the library..any ideas of what this might me? Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 08:35:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26353 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 08:35:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26347 for ; Mon, 8 Feb 1999 08:35:40 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id JAA15100; Mon, 8 Feb 1999 09:35:36 -0700 (MST) Date: Mon, 8 Feb 1999 09:35:36 -0700 From: Greg Skafte To: Dennis Cc: hackers@FreeBSD.ORG Subject: Re: fchdir libary problem in 2.2.7 Message-ID: <19990208093535.F10802@gras-varg.worldgate.com> References: <199902081506.KAA21938@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902081506.KAA21938@etinc.com>; from Dennis on Mon, Feb 08, 1999 at 10:15:48AM -0500 Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG for mysql the freebsd kernel threads are pretty much broken use the the included mit threads..... I've just compile mysql-3.22.15gamma on 2.2.8 stable machine cleanly using the mit threads.... Quoting Dennis (dennis@etinc.com) On Subject: fchdir libary problem in 2.2.7 Date: Mon, Feb 08, 1999 at 10:15:48AM -0500 > I'm getting the following error message? > > /usr/libexec/ld.so: Undefined symbol "_fchdir" called from > mysqld:/usr/lib/libc_ > r.so.3.0 at 0x201a56a8 > > > Ive loaded the 2.2.7 upgrade to stable package, and still no luck. > > fchdir seems to be being compiled when I rebuild the library..any ideas of > what > this might me? > > Dennis > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 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) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 09:32:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA02069 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 09:32:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA02064 for ; Mon, 8 Feb 1999 09:32:11 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 08 Feb 1999 17:32:18 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1LNB74BN; Mon, 8 Feb 1999 17:27:02 -0000 Received: from localhost ([127.0.0.1] helo=palmerharvey.co.uk) by voodoo.pandhm.co.uk with esmtp (Exim 2.10 #1) id 109uZl-000075-00 for hackers@FreeBSD.org; Mon, 8 Feb 1999 17:34:25 +0000 To: hackers@FreeBSD.ORG Subject: size of environment X-Mailer: nmh v0.26 Organization: Palmer & Harvey McLane Date: Mon, 08 Feb 1999 17:34:25 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How can I tell what the maximum size of a processes environment is? I've had a cursory grep through /usr/include and haven't been able to spot anything. Reason I ask is that I appear to have such a large collection of environment variables inside my zsh, that the new ones aren't appearing. And the large ones that get modified (like PATH) appear to be disappearing. If I comment out a few of my lesser used ones, then all is well, I get a PATH variable back in my subshells. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator ``Those who do not understand Unix are condemned to reinvent it, poorly.'' -- Henry Spencer -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 10:35:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09355 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 10:35:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09350 for ; Mon, 8 Feb 1999 10:35:04 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id KAA18262; Mon, 8 Feb 1999 10:34:45 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id KAA43746; Mon, 8 Feb 1999 10:34:42 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199902060217.TAA26924@usr02.primenet.com> Date: Mon, 08 Feb 1999 10:34:42 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Terry Lambert Subject: Re: ldconfig and libraries Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >> > Sounds like it's in the wrong order in the file... >> >> No it's not. It's a read-only section (section, not segment), so at >> load time it needs to end up in a read-only segment (segment, not >> section). On most OSs the only read-only segment is the text segment. >> So it has to be in the same segment as text. Given that, it doesn't >> matter whether it comes before or after the actual program code, >> because in either case it will precede the data segment. Therefore, >> changing its size will move the data segment. > > I think we are talking at cross purposes here. > > You are saying that the section is read-only to the program. Yes. > I am saying that it shouldn't be read-only to a tool to manipulate > the section contents. Of course it needn't be read-only to any tool. > In that regard, the location of the section should be after the > executable code. It can be after the executable code, but it can't be after the program's data. FreeBSD's kernel currently supports only 3 segments for programs: text, data, and bss. They are laid out contiguously in the address space, in that order. The only one that's read-only is text, the first segment. So all read-only items have to be somewhere in the text segment. They can be before or after the program code, but that doesn't help. Because in either case, they'll still precede the data segment. Thus changing the size of anything that's read-only will force the data segment to move. That would require relocation, which cannot be done for an executable. The relocation information isn't present in the file any more. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 10:36:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09448 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 10:36:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09442 for ; Mon, 8 Feb 1999 10:36:35 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id KAA18277; Mon, 8 Feb 1999 10:36:33 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id KAA43758; Mon, 8 Feb 1999 10:36:33 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199902060712.AAA88283@harmony.village.org> Date: Mon, 08 Feb 1999 10:36:32 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Warner Losh Subject: Re: ldconfig and libraries Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <199902041927.LAA19876@vashon.polstra.com> John Polstra writes: >: executables. The RPATH string is in the .dynstr section, which >: precedes text, data, and bss in the address space. If you made the > > Is it required to come before text, data and bss? Or is that just > convention that needn't be true. Since it's read-only, it has to be in the only read-only segment at execution time. That's the text segment. No matter where it is in the text segment, it still precedes the data segment. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 11:09:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13625 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 11:09:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA13609; Mon, 8 Feb 1999 11:08:56 -0800 (PST) (envelope-from son@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.1a/8.9.1a) with ESMTP id UAA00566; Mon, 8 Feb 1999 20:08:26 +0100 (MET) Received: (from son@localhost) by teaser.fr (8.9.2/8.9.1) id TAA00873; Mon, 8 Feb 1999 19:58:55 +0100 (CET) (envelope-from son) Message-ID: <19990208195855.56187@breizh.prism.uvsq.fr> Date: Mon, 8 Feb 1999 19:58:55 +0100 From: Nicolas Souchu To: Mike Smith Cc: Dag-Erling Smorgrav , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199902080148.RAA09054@dingo.cdrom.com>; from Mike Smith on Sun, Feb 07, 1999 at 05:48:22PM -0800 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 07, 1999 at 05:48:22PM -0800, Mike Smith wrote: > >> I'd really, *really* like to rip out the lpt driver, since its >> functionality is completely duplicated by the nlpt and lpip drivers, >> which seem pretty stable now. Keeping the lpt driver will only result >> in slowing down ppbus development. I don't think ppbus + nlpt + plip >> is significantly larger than lpt, so size is not an argument. And if >> we ever want to rip out lpt, we have to rip it out *now* before 3.1 is >> released, or we'll have a hard time doing it before 4.0 goes -STABLE >> in a year or two. > >This was actually meant to happen a while back, and I should be wearing >the pointy hat for it. The last stumbling block was lack of linux-mode >compatibility in lpip, which was fixed ages ago. > >I'm not sure we want to do this so late for 3.1, but it should >certainly happen in -current and probably shortly following the 3.1 >release. Yes, I missed this step :( And I should certainly have done this before the last ppbus/nlpt enhancements (http://www.freebsd.org/~nsouch/ppbus.html). So, let's do it for -current and wait some feedback before a 3.1 update. > >-- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ mike@smith.net.au >\\ The race is long, and in the \\ msmith@freebsd.org >\\ end it's only with yourself. \\ msmith@cdrom.com > > > -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - 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 Mon Feb 8 11:54:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21471 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 11:54:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21466 for ; Mon, 8 Feb 1999 11:54:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id LAA18263; Mon, 8 Feb 1999 11:53:44 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA16959; Mon, 8 Feb 1999 11:53:43 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id MAA06169; Mon, 8 Feb 1999 12:53:42 -0700 Message-ID: <36BF40C6.A2CA621D@softweyr.com> Date: Mon, 08 Feb 1999 12:53:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra CC: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: ldconfig and libraries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > Terry Lambert wrote: > > > I am saying that it shouldn't be read-only to a tool to manipulate > > the section contents. > > Of course it needn't be read-only to any tool. > > > In that regard, the location of the section should be after the > > executable code. > > It can be after the executable code, but it can't be after the > program's data. FreeBSD's kernel currently supports only 3 segments > for programs: text, data, and bss. They are laid out contiguously in > the address space, in that order. The only one that's read-only is > text, the first segment. So all read-only items have to be somewhere > in the text segment. They can be before or after the program code, > but that doesn't help. Because in either case, they'll still precede > the data segment. Thus changing the size of anything that's read-only > will force the data segment to move. That would require relocation, > which cannot be done for an executable. The relocation information > isn't present in the file any more. So make the field ALWAYS PATH_MAX (+1 ??) characters in length, and stick a zero-terminated string within that buffer. Changing the length of the string won't change the length of the field, and therefore won't require fixing up addresses in the data (or any other) segment. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 12:00:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22270 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 12:00:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22262 for ; Mon, 8 Feb 1999 12:00:08 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id MAA18723; Mon, 8 Feb 1999 12:00:07 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id MAA44703; Mon, 8 Feb 1999 12:00:06 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <36BF40C6.A2CA621D@softweyr.com> Date: Mon, 08 Feb 1999 12:00:06 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Wes Peters Subject: Re: ldconfig and libraries Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > So make the field ALWAYS PATH_MAX (+1 ??) characters in length, and > stick a zero-terminated string within that buffer. Changing the length > of the string won't change the length of the field, and therefore won't > require fixing up addresses in the data (or any other) segment. And add 1K to the size of every executable and shared library file in the system? Both on disk and in memory at execution time? That's too much of a hack for my tastes. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 12:53:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29568 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 12:53:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29513; Mon, 8 Feb 1999 12:52:47 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id VAA97951; Mon, 8 Feb 1999 21:25:27 +0100 (CET) (envelope-from des) To: Nicolas Souchu Cc: Mike Smith , Dag-Erling Smorgrav , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> From: Dag-Erling Smorgrav Date: 08 Feb 1999 21:25:26 +0100 In-Reply-To: Nicolas Souchu's message of "Mon, 8 Feb 1999 19:58:55 +0100" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Souchu writes: > On Sun, Feb 07, 1999 at 05:48:22PM -0800, Mike Smith wrote: > > > I'd really, *really* like to rip out the lpt driver [...] > > I'm not sure we want to do this so late for 3.1, but it should > > certainly happen in -current and probably shortly following the 3.1 > > release. > So, let's do it for -current and wait some feedback before a 3.1 update. Better yet, let's rip it out of -current (I have an lpt-less src/sys tree just waiting to be committed), and stick an #error in -stable's lpt.c saying "This driver is deprecated, use ppbus instead". That way, we give everybody advance warning without risking a botched commit and/or people complaining that their kernel has inexplicably failed to build. In any case, does anybody mind if I go ahead and remove the lpt driver from -current, say, tomorrow? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 13:47:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08902 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 13:47:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08851 for ; Mon, 8 Feb 1999 13:47:10 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA24111; Mon, 8 Feb 1999 14:46:53 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd024022; Mon Feb 8 14:46:51 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA01313; Mon, 8 Feb 1999 14:46:39 -0700 (MST) From: Terry Lambert Message-Id: <199902082146.OAA01313@usr08.primenet.com> Subject: Re: more modular rc/init/uninit system... To: wes@softweyr.com (Wes Peters) Date: Mon, 8 Feb 1999 21:46:38 +0000 (GMT) Cc: tlambert@primenet.com, witr@rwwa.com, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <36BD48CE.D055BBD2@softweyr.com> from "Wes Peters" at Feb 7, 99 01:03:26 am X-Mailer: ELM [version 2.4 PL25] 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 > > > > How do you propose to solve the Solaris binary compatability > > > > problem for commercial Solaris applications that install > > > > components into the rc.d directories in order to get them run > > > > at the correct time and in the correct order for dependent > > > > services requirements? > > > > > > By writing a port that will install the startup script in the > > > right place and modify it as necessary. We really don't have > > > to implement the entire brain-dead mess of the SysV init system > > > just to start a simple (or even not so simple) application. > > > > You're in Utah. > > > > I bet Bob would let you borrow his IBCS2 Sybase for the AT&T > > StartServer so you could install it on FreeBSD and make a "port". > > You're tangetizing again. You asked what we would do to bash the > init.d script for a Solaris app to fitting within the new scheme > proposed, and I said "write a port that install the startup > script in the right place and modify it as necessary." The original > question had nothing to do with supporting the actual app, but > rather the differences in the system startup scripts. No, I was asking what we would do to bash the new scheme proposed so that it would fit around the init.d scripts for already existing Solaris apps. I think that bashing the scripts with a port is exactly the wrong way to solve the problem; there are a hell of a lot more Solaris binaries than there are FreeBSD init programs. It's pretty clear where the cleanest, lowest overhead implementation should be located. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 13:49:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09193 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 13:49:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09182; Mon, 8 Feb 1999 13:49:07 -0800 (PST) (envelope-from son@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.1a/8.9.1a) with ESMTP id WAA08950; Mon, 8 Feb 1999 22:48:34 +0100 (MET) Received: (from son@localhost) by teaser.fr (8.9.2/8.9.1) id WAA01197; Mon, 8 Feb 1999 22:28:29 +0100 (CET) (envelope-from son) Message-ID: <19990208222829.53422@breizh.prism.uvsq.fr> Date: Mon, 8 Feb 1999 22:28:29 +0100 From: Nicolas Souchu To: Dag-Erling Smorgrav Cc: Mike Smith , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Dag-Erling Smorgrav on Mon, Feb 08, 1999 at 09:25:26PM +0100 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 08, 1999 at 09:25:26PM +0100, Dag-Erling Smorgrav wrote: > >Nicolas Souchu writes: >> On Sun, Feb 07, 1999 at 05:48:22PM -0800, Mike Smith wrote: >> > > I'd really, *really* like to rip out the lpt driver [...] >> > I'm not sure we want to do this so late for 3.1, but it should >> > certainly happen in -current and probably shortly following the 3.1 >> > release. >> So, let's do it for -current and wait some feedback before a 3.1 update. > >Better yet, let's rip it out of -current (I have an lpt-less src/sys >tree just waiting to be committed), and stick an #error in -stable's >lpt.c saying "This driver is deprecated, use ppbus instead". That way, >we give everybody advance warning without risking a botched commit >and/or people complaining that their kernel has inexplicably failed to >build. Ok. Is UPDATING only a -current resource or may it be updated in 3.1? > >In any case, does anybody mind if I go ahead and remove the lpt driver >from -current, say, tomorrow? Don't forget GENERIC.. this patch or whatelse. Index: GENERIC =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v retrieving revision 1.146 diff -u -r1.146 GENERIC --- GENERIC 1999/02/04 22:34:23 1.146 +++ GENERIC 1999/02/08 21:17:52 @@ -145,7 +145,13 @@ device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 -device lpt0 at isa? port? tty irq 7 +# Parallel port bus framework with nlpt (printer), plip (network). +# Uncomment vpo if you need ZIP/ZIP+ support. +controller ppbus0 +#controller vpo0 at ppbus? +device nlpt0 at ppbus? +device plip0 at ppbus? +controller ppc0 at isa? port? tty irq 7 "This supposes slip/ppp is statically configured for plip", would add Bruce. > >DES >-- >Dag-Erling Smorgrav - des@flood.ping.uio.no > -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - 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 Mon Feb 8 14:00:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10447 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 14:00:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10410; Mon, 8 Feb 1999 14:00:25 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id WAA98322; Mon, 8 Feb 1999 22:59:59 +0100 (CET) (envelope-from des) To: Nicolas Souchu Cc: Dag-Erling Smorgrav , Mike Smith , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> From: Dag-Erling Smorgrav Date: 08 Feb 1999 22:59:57 +0100 In-Reply-To: Nicolas Souchu's message of "Mon, 8 Feb 1999 22:28:29 +0100" Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Souchu writes: > On Mon, Feb 08, 1999 at 09:25:26PM +0100, Dag-Erling Smorgrav wrote: > > Better yet, let's rip it out of -current (I have an lpt-less src/sys > > tree just waiting to be committed), and stick an #error in -stable's > > lpt.c saying "This driver is deprecated, use ppbus instead". That way, > > we give everybody advance warning without risking a botched commit > > and/or people complaining that their kernel has inexplicably failed to > > build. > Ok. Is UPDATING only a -current resource or may it be updated in 3.1? I don't know, I was planning to just notify Warner Losh and let him fix src/UPDATING. > > In any case, does anybody mind if I go ahead and remove the lpt driver > > from -current, say, tomorrow? > Don't forget GENERIC.. this patch or whatelse. Don't worry, I've patched GENERIC, LINT, files.i386 and the PicoBSD kernels, and removed lpt.c and lpt.4. I'll still have to track down references to the driver in the documentation though. > "This supposes slip/ppp is statically configured for plip", would add Bruce. What are the consequences of just setting the interrupt mask to net in all cases? Does one still need slip? Is it wrong to do so when plip is not compiled in? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 14:09:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11559 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 14:09:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from estel.uindy.edu (ESTEL.UINDY.EDU [192.146.191.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11550 for ; Mon, 8 Feb 1999 14:09:31 -0800 (PST) (envelope-from steve@estel.uindy.edu) Received: by estel.uindy.edu (8.8.8/NX3.0M) id RAA12448; Mon, 8 Feb 1999 17:09:30 -0500 (EST) Date: Mon, 8 Feb 1999 17:09:30 -0500 (EST) From: Steve Spicklemire Message-Id: <199902082209.RAA12448@estel.uindy.edu> To: freebsd-hackers@FreeBSD.ORG CC: steve@spvi.com Subject: Where do I go from here..... libc_r, threads and system/popen/cron Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmmm.... I'd really like to get this sorted out. Can someone point me in some direction that I might attempt to track this down and figure it out? I've submitted a bug report (misc/9903), and a very detailed description of the problem a few days earlier. Should I rebuild "system", or "popen" with '-g' and attempt to step through the call to figure out what's hanging there? Is there some other/better trick that might lead to a resolution? I just need a hint... really! thanks, -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 15:07:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21049 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 15:07:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21044 for ; Mon, 8 Feb 1999 15:07:19 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.1/8.9.1) id PAA10226; Mon, 8 Feb 1999 15:06:35 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Feb 1999 15:06:34 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip Message-ID: <19990208150634.A10137@relay.nuxi.com> Reply-To: obrien@NUXI.com References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990208222829.53422@breizh.prism.uvsq.fr>; from Nicolas Souchu on Mon, Feb 08, 1999 at 10:28:29PM +0100 X-Operating-System: FreeBSD 3.0-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > +# Parallel port bus framework with nlpt (printer), plip (network). What does ``nlpt'' stand for? If "New LPT" or something similarly useless, then can't we keep the "lpt" name that is standard across PCs and just change the usage to: device lpt0 at ppbus? The number of name changes for devices in FreeBSD is reaching an alarming rate, messes with POLA, and many are simply gratuitous. -- -- David (obrien@NUXI.com -or- obrien@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 Feb 8 15:50:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25240 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 15:50:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25232 for ; Mon, 8 Feb 1999 15:50:39 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA01350; Mon, 8 Feb 1999 15:41:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902082341.PAA01350@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: obrien@NUXI.com cc: Dag-Erling Smorgrav , Mike Smith , hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-reply-to: Your message of "Mon, 08 Feb 1999 15:06:34 PST." <19990208150634.A10137@relay.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Feb 1999 15:41:32 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > +# Parallel port bus framework with nlpt (printer), plip (network). > > What does ``nlpt'' stand for? If "New LPT" or something similarly > useless, then can't we keep the "lpt" name that is standard across PCs > and just change the usage to: > > device lpt0 at ppbus? > > The number of name changes for devices in FreeBSD is reaching an alarming > rate, messes with POLA, and many are simply gratuitous. As soon as 'lpt' is gone from config's data, yes. You can't have more than one instance of a given name, hence the new name. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 16:26:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01471 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 16:24:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01464 for ; Mon, 8 Feb 1999 16:24:42 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA22029; Mon, 8 Feb 1999 16:20:31 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA26752; Mon, 8 Feb 1999 16:20:31 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA09335; Mon, 8 Feb 1999 17:20:27 -0700 Message-ID: <36BF7F4B.438B602@softweyr.com> Date: Mon, 08 Feb 1999 17:20:27 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: witr@rwwa.com, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG Subject: Re: more modular rc/init/uninit system... References: <199902082146.OAA01313@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > I think that bashing the scripts with a port is exactly the wrong > way to solve the problem; there are a hell of a lot more Solaris > binaries than there are FreeBSD init programs. It's pretty clear > where the cleanest, lowest overhead implementation should be > located. Only if it is indeed the cleanest, lowest overhead implementation. This discussion moved far beyond that point, agreeing it was not, well before you joined it. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 16:27:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01691 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 16:27:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01674 for ; Mon, 8 Feb 1999 16:27:45 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.1/8.9.1) id QAA11588; Mon, 8 Feb 1999 16:27:28 -0800 (PST) (envelope-from obrien) Date: Mon, 8 Feb 1999 16:27:28 -0800 From: "David O'Brien" To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip Message-ID: <19990208162728.C10315@relay.nuxi.com> Reply-To: obrien@NUXI.com References: <19990208150634.A10137@relay.nuxi.com> <199902082341.PAA01350@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199902082341.PAA01350@dingo.cdrom.com>; from Mike Smith on Mon, Feb 08, 1999 at 03:41:32PM -0800 X-Operating-System: FreeBSD 3.0-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > useless, then can't we keep the "lpt" name that is standard across PCs > > and just change the usage to: > > device lpt0 at ppbus? ... > > As soon as 'lpt' is gone from config's data, yes. You can't have more > than one instance of a given name, hence the new name. Certainly. Since it hadn't been mentioned as the plan, I spoke up. -- -- David (obrien@NUXI.com -or- obrien@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 Feb 8 16:41:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03382 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 16:41:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03374; Mon, 8 Feb 1999 16:41:39 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id BAA99056; Tue, 9 Feb 1999 01:41:37 +0100 (CET) (envelope-from des) To: hackers@FreeBSD.ORG Cc: Nicolas Souchu , Mike Smith , Bill Fenner , wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> From: Dag-Erling Smorgrav Date: 09 Feb 1999 01:41:37 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "08 Feb 1999 22:59:57 +0100" Message-ID: Lines: 314 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Don't worry, I've patched GENERIC, LINT, files.i386 and the PicoBSD > kernels, and removed lpt.c and lpt.4. I'll still have to track down > references to the driver in the documentation though. Hmm, there were quite a few. I'd forgotten a handful of man pages, the userconfig device list, and the man4.i386 Makefile. I have a LINT build running to check that I didn't break anything. I didn't touch any of the PC98 stuff; I'll leave that up to Kato. Patches are attached. If noone objects loudly, I'll commit them and cvs rm src/sys/i386/isa/lpt.c and src/share/man4/man4.i386/lpt.4 tomorrow. I'd also like to remove src/sys/i386/isa/lptreg.h, but it's referenced by the rdp driver (which should be ported to ppbus by Joerg or someone else who has an RTL8002 or RTL8012 handy for testing) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: src/release/picobsd/isp/conf/PICOBSD =================================================================== RCS file: /home/ncvs/src/release/picobsd/isp/conf/PICOBSD,v retrieving revision 1.8 diff -u -r1.8 PICOBSD --- PICOBSD 1999/01/18 10:17:31 1.8 +++ PICOBSD 1999/02/08 04:21:10 @@ -104,7 +104,11 @@ device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 device cy1 at isa? tty irq 11 iomem 0xd6000 iosiz 0x2000 -device lpt0 at isa? port? tty irq 7 +device ppc0 at isa? port? net irq 7 +controller ppbus0 +device nlpt0 at ppbus? +device plip0 at ppbus? +device ppi0 at ppbus? # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. Index: src/release/picobsd/net/conf/PICOBSD =================================================================== RCS file: /home/ncvs/src/release/picobsd/net/conf/PICOBSD,v retrieving revision 1.8 diff -u -r1.8 PICOBSD --- PICOBSD 1999/01/19 23:12:27 1.8 +++ PICOBSD 1999/02/08 04:23:49 @@ -68,7 +68,11 @@ device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 -device lpt0 at isa? port? tty irq 7 +device ppc0 at isa? port? net irq 7 +controller ppbus0 +device nlpt0 at ppbus? +device plip0 at ppbus? +device ppi0 at ppbus? # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. Index: src/release/picobsd/router/conf/PICOBSD =================================================================== RCS file: /home/ncvs/src/release/picobsd/router/conf/PICOBSD,v retrieving revision 1.11 diff -u -r1.11 PICOBSD --- PICOBSD 1999/01/18 10:17:35 1.11 +++ PICOBSD 1999/02/08 23:55:28 @@ -70,7 +70,11 @@ device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 -#device lpt0 at isa? port? tty irq 7 +#device ppc0 at isa? port? net irq 7 +#controller ppbus0 +#device nlpt0 at ppbus? +#device plip0 at ppbus? +#device ppi0 at ppbus? # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. Index: src/share/man/man4/man4.i386/Makefile =================================================================== RCS file: /home/ncvs/src/share/man/man4/man4.i386/Makefile,v retrieving revision 1.96 diff -u -r1.96 Makefile --- Makefile 1999/02/07 05:40:13 1.96 +++ Makefile 1999/02/08 23:44:01 @@ -3,7 +3,7 @@ MAN4= adv.4 adw.4 aha.4 ahb.4 ahc.4 aic.4 apm.4 ar.4 asc.4 atkbd.4 \ atkbdc.4 ax.4 bktr.4 bt.4 cs.4 cx.4 cy.4 de.4 \ dgb.4 dpt.4 ed.4 el.4 en.4 ep.4 ex.4 fdc.4 fe.4 fxp.4 gsc.4 ie.4 \ - io.4 joy.4 keyboard.4 labpc.4 le.4 lnc.4 lp.4 lpt.4 matcd.4 mcd.4 \ + io.4 joy.4 keyboard.4 labpc.4 le.4 lnc.4 lp.4 matcd.4 mcd.4 \ mem.4 meteor.4 mouse.4 mse.4 mtio.4 mx.4 ncr.4 npx.4 \ pcf.4 pcm.4 pcvt.4 perfmon.4 pn.4 pnp.4 ppc.4 psm.4 \ rdp.4 rl.4 sb.4 scd.4 screen.4 si.4 sio.4 \ @@ -46,8 +46,7 @@ MLINKS+= labpc.4 ../labpc.4 MLINKS+= le.4 ../le.4 MLINKS+= lnc.4 ../lnc.4 -MLINKS+= lp.4 ../lp.4 -MLINKS+= lpt.4 ../lpt.4 +MLINKS+= lp.4 ../lp.4 lp.4 plip.4 lp.4 ../plip.4 MLINKS+= matcd.4 ../matcd.4 MLINKS+= mcd.4 ../mcd.4 MLINKS+= mem.4 kmem.4 mem.4 ../mem.4 mem.4 ../kmem.4 Index: src/share/man/man4/man4.i386/lp.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/man4.i386/lp.4,v retrieving revision 1.7 diff -u -r1.7 lp.4 --- lp.4 1998/10/22 14:12:55 1.7 +++ lp.4 1999/02/08 23:58:35 @@ -43,7 +43,7 @@ .Nm ifconfig lp0 .Ar myaddress hisaddress .Op Fl link0 -.Cd "device lpt0 at isa? port? tty irq 7" +.Cd "device plip0 at ppbus?" .Sh DESCRIPTION The .Nm @@ -53,29 +53,21 @@ input: hence there is no requirement for special bidirectional hardware and any standard AT-compatible printer port with working interrupts may be used. .Pp -The -.Nm -driver is implemented as an integral part of the -.Nm lpt -driver, and will automatically be present in a kernel configured with -Internet support and at least one -.Nm lpt -device. During the boot process, for each -.Nm lpt -printer device which is probed and has an interrupt assigned, a corresponding +During the boot process, for each +.Nm ppc +device which is probed and has an interrupt assigned, a corresponding .Nm network device is created. Available devices are announced with a message such as: .Dl lp0: TCP/IP capable interface .Pp -Initially, the -.Nm lpt -device is active for printing and the network interface is inactive; however, -once the corresponding +Configuring an .Nm -device has been configured 'up' with +device with .Xr ifconfig 8 -printing is disabled until the network interface is configured 'down'. +causes the corresponding +.Nm ppc +device to be reserved for PLIP until the network interface is configured 'down'. .Pp The communication protocol is selected by the .Cm link0 @@ -219,7 +211,8 @@ specially (although the data lines are restored to the zero, idle state to avoid spuriously indicating the start of the next packet). .Sh SEE ALSO -.Xr lpt 4 , +.Xr ppbus 4 , +.Xr ppc 4 , .Xr ifconfig 8 . .Sh BUGS Busy-waiting loops are used while handshaking bytes, (and worse still when Index: src/share/man/man4/man4.i386/rdp.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/man4.i386/rdp.4,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 rdp.4 --- rdp.4 1998/12/21 18:01:15 1.1.1.1 +++ rdp.4 1999/02/08 23:39:12 @@ -77,7 +77,7 @@ might help in diagnosing the reason. Since the RTL 8002 requires the availability of a working interrupt for the printer adapter (unlike the -.Xr lpt 4 +.Xr ppc 4 driver), the .Nm driver fails to attach if the ethernet adapter cannot assert an @@ -90,8 +90,8 @@ driver internally sets a flag so it gets probed very early. This way, it is possible to configure both, an .Nm -driver as well as an -.Xr lpt 4 +driver as well as a +.Xr ppc 4 driver into the same kernel. If no RTL 8002 hardware is present, probing will eventually detect the printer driver. .Sh DIAGNOSTICS @@ -121,15 +121,15 @@ hardware is likely to be wedged, and is being reset. .Pp .Sh SEE ALSO -.Xr lpt 4 , +.Xr ppc 4 , .Xr ifconfig 8 .Sh AUTHORS This driver was written by .ie t J\(:org Wunsch, .el Joerg Wunsch, based on RealTek's packet driver for the RTL 8002, as well as on some -description of the successor chip, RTL 8012, RealTek was gratefully -providing. +description of the successor chip, RTL 8012, gracefully provided by +RealTek. .Sh BUGS There are certainly many of them. .Pp Index: src/sys/i386/conf/GENERIC =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v retrieving revision 1.146 diff -u -r1.146 GENERIC --- GENERIC 1999/02/04 22:34:23 1.146 +++ GENERIC 1999/02/09 00:00:15 @@ -145,7 +145,13 @@ device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 -device lpt0 at isa? port? tty irq 7 +# Parallell port +device ppc0 at isa? port? net irq 7 +constroller ppbus0 +device nlpt0 at ppbus? +device plip0 at ppbus? +device ppi0 at ppbus? +#controller vpo0 at ppbus? # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. Index: src/sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.550 diff -u -r1.550 LINT --- LINT 1999/02/07 20:33:05 1.550 +++ LINT 1999/02/08 23:45:12 @@ -1113,19 +1113,11 @@ disk fd1 at fdc0 drive 1 # -# Other standard PC hardware: `lpt', `mse', `sio', etc. +# Other standard PC hardware: `mse', `sio', etc. # -# lpt: printer port -# lpt specials: -# The port may be specified as ?. This will cause the -# driver to scan the BIOS port list. -# The irq clause may be omitted. This will force the port -# into polling mode. # mse: Logitech and ATI InPort bus mouse ports # sio: serial ports (see sio(4)) -device lpt0 at isa? port? tty irq 7 -device lpt1 at isa? port "IO_LPT3" tty irq 5 device mse0 at isa? port 0x23c tty irq 5 device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 @@ -1813,7 +1805,7 @@ # vpo Iomega Zip Drive # Requires SCSI disk support ('scbus' and 'da'), best # performance is achieved with ports in EPP 1.9 mode. -# nlpt Parallel Printer, use _instead_ of lpt0 +# nlpt Parallel Printer # plip Parallel network interface # ppi General-purpose I/O ("Geek Port") # pps Pulse per second Timing Interface Index: src/sys/i386/conf/files.i386 =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/files.i386,v retrieving revision 1.220 diff -u -r1.220 files.i386 --- files.i386 1999/01/20 03:29:52 1.220 +++ files.i386 1999/02/08 04:10:12 @@ -146,7 +146,6 @@ i386/isa/istallion.c optional stli device-driver i386/isa/joy.c optional joy device-driver i386/isa/loran.c optional loran device-driver -i386/isa/lpt.c optional lpt device-driver i386/isa/labpc.c optional labpc device-driver i386/isa/mcd.c optional mcd device-driver i386/isa/mse.c optional mse device-driver Index: src/sys/i386/i386/userconfig.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/userconfig.c,v retrieving revision 1.129 diff -u -r1.129 userconfig.c --- userconfig.c 1999/02/04 10:36:57 1.129 +++ userconfig.c 1999/02/08 23:36:52 @@ -391,6 +391,7 @@ {"vr", "VIA Rhine/Rhine II ethernet adapter", FLG_FIXED, CLS_NETWORK}, {"wb", "Winbond W89C840F ethernet adapter", FLG_FIXED, CLS_NETWORK}, {"xl", "3COM 3C90x PCI ethernet adapter", FLG_FIXED, CLS_NETWORK}, +{"rdp", "RealTek RTL8002 Pocket Ethernet", 0, CLS_NETWORK}, {"sio", "8250/16450/16550 Serial port", 0, CLS_COMMS}, {"cx", "Cronyx/Sigma multiport sync/async adapter",0, CLS_COMMS}, @@ -401,7 +402,6 @@ {"si", "Specialix SI/XIO async adapter", 0, CLS_COMMS}, {"stl", "Stallion EasyIO/Easy Connection 8/32 async adapter",0, CLS_COMMS}, {"stli", "Stallion intelligent async adapter" ,0, CLS_COMMS}, -{"lpt", "Parallel printer port", 0, CLS_COMMS}, {"ppc", "Parallel Port chipset", 0, CLS_COMMS}, {"gp", "National Instruments AT-GPIB/TNT driver", 0, CLS_COMMS}, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 18:18:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15872 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 18:18:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15867 for ; Mon, 8 Feb 1999 18:18:07 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4007.ime.net [209.90.195.17]) by Loki.orland.u91.k12.me.us (8.9.2/8.8.8-Loki) with SMTP id VAA22983 for ; Mon, 8 Feb 1999 21:18:01 -0500 (EST) (envelope-from netmonger@genesis.ispace.com) X-Server-ID: Loki.orland.u91.k12.me.us, OCSNet - Orland Maine USA X-Coord-Name: Drew "Droobie" Baxter, OneNetwork Exchange X-Coord-Addr: Droobie@Openlink.orland.me.us X-Coord-Pager: USA: 207-471-2719, http://pagedroo.orland.me.us Message-Id: <4.1.19990208211641.039d3f10@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 08 Feb 1999 21:17:46 -0500 To: Freebsd-hackers@FreeBSD.ORG From: Drew Baxter Subject: Re: Pentium III support? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Checking as Pentium III processors are starting to surface in my vendors. Does FreeBSD already support these "KATMAI" processors? My Slot 1 Board has a BIOS upgrade to it, wasn't sure if FreeBSD may shoot out "Invalid Processor Type" or something. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP ID: 409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 20:38:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA02193 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 20:38:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from keep.scn.ru (keep.scnet.ru [195.239.174.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA02187 for ; Mon, 8 Feb 1999 20:38:36 -0800 (PST) (envelope-from smith@scn.ru) Received: from scn.ru (quick.scnet.ru [195.239.174.3]) by keep.scn.ru (8.9.1/8.9.1) with ESMTP id LAA06499 for ; Tue, 9 Feb 1999 11:37:56 +0700 (KRS) Message-ID: <36BFBA8B.37A3EFF3@scn.ru> Date: Tue, 09 Feb 1999 11:33:16 +0700 From: "Vladimir N. Kovalev" Reply-To: smith@scn.ru Organization: Sibchallenge Telecom Inc. X-Mailer: Mozilla 4.07 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Dummynet pipes truble Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello ! I'm use dummynet on FreeBSD 2.2.7-19981103-SNAP with the such configuration of pipes: # Set pipes for icmp ipfw pipe 1 config delay 7000ms queue 10 plr 0.001 # Set pipes for admin ipfw pipe 2 config bw 4000B queue 70 # Set pipes for LAN channel ipfw pipe 3 config bw 10KB queue 75 # Set pipes for server ( mail, ftp, squid etc ) channel ipfw pipe 4 config bw 6KB queue 75 # Set pipes for class rooms channel ipfw pipe 5 config bw 100B queue 75 # Set pipes for test purposes only ipfw pipe 6 config bw 1B queue 50 And rc.firewall have appropiate rules: 01710 1044 533229 pipe 6 tcp from any to 192.168.0.1 ... 02210 12525 15043642 pipe 2 tcp from any to 192.168.2.2 in recv 192.168.1.1 established 02310 0 0 pipe 5 tcp from any to 192.168.3.1 in recv 192.168.1.1 established 02410 38345 16987766 pipe 4 tcp from any to 192.168.1.1 in recv 192.168.1.1 established 02510 18798 5420744 pipe 4 tcp from any to 192.168.2.1 in recv 192.168.1.1 established 02610 883364 658924977 pipe 3 tcp from any to any in recv 192.168.1.1 established ... 04410 18384 1348136 pipe 1 icmp from any to any in recv cx0 Pipes number 1, 3 and 4 works fine, but pipes number 2, 5 and 6 does not limit a bandwidth. However, then I add delay to this pipes I can feel it. Why ? Thanks in advance. Best regards Vladimir N. Kovalev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 8 21:19:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05735 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 21:19:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pc2etp.mephi.ru (pc2etp.mephi.ru [194.67.66.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA05723 for ; Mon, 8 Feb 1999 21:19:11 -0800 (PST) (envelope-from igusarov@chat.ru) Received: from piglet ([194.67.67.195]) by pc2etp.mephi.ru (8.8.8/8.8.8) with ESMTP id IAA12593 for ; Tue, 9 Feb 1999 08:23:09 GMT (envelope-from igusarov@chat.ru) Message-Id: <199902090823.IAA12593@pc2etp.mephi.ru> From: "Igor Gousarov" To: Subject: Unsafe code in libc in 3.0-RELEASE FreeBSD i386 Date: Tue, 9 Feb 1999 08:19:08 +0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The source file for setlocale function (/usr/src/lib/libc/locale/setlocale.c) contains the line which might put libc into infinite loop: Line 172: while ( i < _LC_LAST ) Should be replaced with Line 172: for ( ; i < _LC_LAST ; i++ ) And there's one more line to correct in the same source file: Line 178: if (category) This line rely on the fact that LC_ALL is defined to be equal 0. Correct statement should look like Line 178: if ( category != LC_ALL ) --------------------------------------------------- Igor A. Goussarov, igusarov@chat.ru, ICQ UIN 11267740 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 02:55:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA00419 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 02:55:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA00405 for ; Tue, 9 Feb 1999 02:55:44 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id JAA04327 for hackers@FreeBSD.ORG; Tue, 9 Feb 1999 09:32:26 GMT From: Emmanuel DELOGET Message-Id: <199902090932.JAA04327@excalibur.oceanis.net> Subject: Adding sysctl entries To: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Date: Tue, 9 Feb 1999 10:32:26 +0100 (MET) 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 [Sorry to disturb you :)] I wanna add some sysctl entries to a loadable kernel module. As I'm sure I'm not the first doing that, if anybody knows... -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 03:01:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA00969 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 03:01:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA00962 for ; Tue, 9 Feb 1999 03:01:48 -0800 (PST) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.2/8.8.5) with SMTP id QAA48135 for ; Tue, 9 Feb 1999 16:37:00 +0600 (NS) Date: Tue, 9 Feb 1999 16:36:59 +0600 (NS) From: Max Khon To: freebsd-hackers@FreeBSD.ORG Subject: softupdates 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 hi, there! what is the current status of softupdates? is it safe to turn on softupdates (no ccd)? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 03:03:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01232 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 03:03:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01213 for ; Tue, 9 Feb 1999 03:03:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id MAA26770; Tue, 9 Feb 1999 12:03:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA68741; Tue, 9 Feb 1999 12:03:23 +0100 (MET) Date: Tue, 9 Feb 1999 12:03:23 +0100 From: Eivind Eklund To: Emmanuel DELOGET Cc: FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries Message-ID: <19990209120322.L46616@bitbox.follo.net> References: <199902090932.JAA04327@excalibur.oceanis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199902090932.JAA04327@excalibur.oceanis.net>; from Emmanuel DELOGET on Tue, Feb 09, 1999 at 10:32:26AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: > [Sorry to disturb you :)] > > I wanna add some sysctl entries to a loadable kernel > module. As I'm sure I'm not the first doing that, > if anybody knows... It is not possible at the moment. :-( Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 06:03:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17558 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 06:03:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from netserv1.chg.ru (netserv1.chg.ru [193.233.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17547 for ; Tue, 9 Feb 1999 06:03:53 -0800 (PST) (envelope-from dima@netserv1.chg.ru) Received: (from dima@localhost) by netserv1.chg.ru (8.9.1/8.9.1) id RAA02695 for freebsd-hackers@freebsd.org; Tue, 9 Feb 1999 17:03:40 +0300 (MSK) Date: Tue, 9 Feb 1999 17:03:40 +0300 (MSK) From: Dima Sivachenko Message-Id: <199902091403.RAA02695@netserv1.chg.ru> To: freebsd-hackers@FreeBSD.ORG Subject: Configuring cvsupd Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I want to configure cvsupd to make local mirror of CVS repository. Where can I read more than man-page about how to configure cvsupd? Thank you in advance, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 06:41:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA22567 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 06:41:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA22560 for ; Tue, 9 Feb 1999 06:41:46 -0800 (PST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18185 for ; Tue, 9 Feb 1999 09:41:44 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.1/8.9.1) with ESMTP id JAA02508 for ; Tue, 9 Feb 1999 09:41:44 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199902091441.JAA02508@bmcgover-pc.cisco.com> To: hackers@FreeBSD.ORG Subject: Docs on line disciplines? Date: Tue, 09 Feb 1999 09:41:44 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm looking to see if anyone can point me at documents for implementing a new line discipline... I'm looking at creating something that will take a set of data (Voice RTP packets, to be precise), and handle packetizing it while passing it up. The idea is to take a character at a time from the tty driver (a la l_rint), and watch for special escaping of the character using the upper 8 bits (ie - Start of Frame and End of Frame), then buffer the characters until we have a complete packet of data. Then, I want to throw some header info on the front end, and a trailer on the back, and stuff it in to the right part of the clist for the tty (t_rawq or t_canq). On the write side, I want to be able to strip off the header and trailer, then present the data to t_outq with the Start of Frame and End of Frame characters properly escaped. So, any docs that give a primer for starting these types of things would be most appreciated. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 07:05:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25556 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 07:05:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25512; Tue, 9 Feb 1999 07:05:00 -0800 (PST) (envelope-from roger@cs.strath.ac.uk) Received: from cs.strath.ac.uk (posh.dmem.strath.ac.uk [130.159.202.3]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id PAA01967 Tue, 9 Feb 1999 15:04:33 GMT Message-ID: <36C04E7F.2824D2BD@cs.strath.ac.uk> Date: Tue, 09 Feb 1999 15:04:31 +0000 From: Roger Hardiman Organization: Strathclyde Uni X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.1-BETA i386) MIME-Version: 1.0 To: multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: bt848 reverse mute - do you use it? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Does anyone use the reverse mute option on the bt848 driver, in conjunction with selecting the Hauppauge card type. eg options CARD_TYPE=2 options BKTR_REVERSE_MUTE or sysctl -w hw.bt848.card=2 sysctl -w hw.bt848.reverse_mute=1 I want to fix a bug in the bt848 driver, where the Hauppauge mute is incorrect. (The bug causes users of the Hauppauge with Radio card to get hiss instead of mute). But people using Reverse Mute and card type Happauge (2) will find the fix breaks their card. Will this cause problems for you? Please email me, roger@cs.strath.ac.uk Thanks Roger Roger Hardiman roger@cs.strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 07:07:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26094 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 07:07:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26086; Tue, 9 Feb 1999 07:07:38 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id PAA10987; Tue, 9 Feb 1999 15:07:27 GMT From: Emmanuel DELOGET Message-Id: <199902091507.PAA10987@excalibur.oceanis.net> Subject: Re: Adding sysctl entries In-Reply-To: <19990209120322.L46616@bitbox.follo.net> from Eivind Eklund at "Feb 9, 1999 12: 3:23 pm" To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Tue, 9 Feb 1999 16:07:26 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As Eivind Eklund (thanks) said... ** On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: ** > [Sorry to disturb you :)] ** > ** > I wanna add some sysctl entries to a loadable kernel ** > module. As I'm sure I'm not the first doing that, ** > if anybody knows... ** ** It is not possible at the moment. :-( The result seems bad... I had to compile the kernel, then to reboot... Each time I wonder wether I added a bug or not... And if there is a bug, I'm out... Any idea would be welcome... ** ** Eivind. ** -- pixel@dotcom.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 07:39:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29690 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 07:39:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29683 for ; Tue, 9 Feb 1999 07:39:30 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id KAA18320 for ; Tue, 9 Feb 1999 10:30:42 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 10:30:41 -0500 (EST) From: Larry Lile To: hackers@FreeBSD.ORG Subject: Why did this panic? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id HAA29685 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am working on improving the mtu sizes (above 1500) for the Olicom token ring driver but I just ran across this panic that I really don't understand. Any ideas? Larry Lile lile@stdio.com Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf07eddc2 fault code = supervisor write, page not present instruction pointer = 0x8:0xf02096ff stack pointer = 0x10:0xf6829cdc frame pointer = 0x10:0xf6829d14 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 = 352 (ftpd) interrupt mask = net trap number = 12 panic: page fault syncing disks... 7 7 done dumping to dev 20419, offset 761856 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 285 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") at ../../kern/kern_shutdown.c:446 #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) at ../../i386/i386/trap.c:942 #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) at ../../i386/i386/trap.c:835 #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) at ../../i386/i386/trap.c:437 #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) at ../../i386/isa/if_oltr.c:1236 #6 0xf0210acc in ReturnCompletedBuffers () #7 0x631000 in ?? () #8 0xecc5b15a in ?? () Cannot access memory at address 0x104018. (kgdb) up 5 #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) at ../../i386/isa/if_oltr.c:1236 1236 MCLGET(m0, M_DONTWAIT); (kgdb) print m0 $1 = (struct mbuf *) 0xf0756a00 (kgdb) list 1231 if (m0 == NULL) { 1232 ifp->if_ierrors++; 1233 goto out; 1234 } 1235 if (ByteCount + 2 > MHLEN) { 1236 MCLGET(m0, M_DONTWAIT); 1237 mbuf_size = MCLBYTES; 1238 if ((m0->m_flags & M_EXT) == 0) { 1239 m_freem(m0); 1240 ifp->if_ierrors++; (kgdb) print mbstat $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} (kgdb) print *m0 $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { ext_buf = 0x3d637228
, ext_free = 0, ext_size = 2048, ext_ref = 0}, MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} (kgdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 08:10:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03258 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 08:10:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03250 for ; Tue, 9 Feb 1999 08:10:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id HAA04229; Tue, 9 Feb 1999 07:56:38 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpduY4225; Tue Feb 9 15:56:34 1999 Date: Tue, 9 Feb 1999 07:56:12 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Brian McGovern cc: hackers@FreeBSD.ORG Subject: Re: Docs on line disciplines? In-Reply-To: <199902091441.JAA02508@bmcgover-pc.cisco.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 check out the netgraph "tty" node.. does a lot of wht you want.. and is dynamically loadable. ftp://ftp.whistle.com/pub/archie/netgraph/index.html (look at this in netscape) julian On Tue, 9 Feb 1999, Brian McGovern wrote: > I'm looking to see if anyone can point me at documents for implementing a new > line discipline... I'm looking at creating something that will take a > set of data (Voice RTP packets, to be precise), and handle packetizing it > while passing it up. > > The idea is to take a character at a time from the tty driver (a la l_rint), > and watch for special escaping of the character using the upper 8 bits > (ie - Start of Frame and End of Frame), then buffer the characters until > we have a complete packet of data. Then, I want to throw some header info > on the front end, and a trailer on the back, and stuff it in to the right > part of the clist for the tty (t_rawq or t_canq). > > On the write side, I want to be able to strip off the header and trailer, > then present the data to t_outq with the Start of Frame and End of Frame > characters properly escaped. > > So, any docs that give a primer for starting these types of things would > be most appreciated. > > -Brian > > 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 Feb 9 08:11:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03343 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 08:11:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03330 for ; Tue, 9 Feb 1999 08:11:29 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id IAA04404; Tue, 9 Feb 1999 08:03:30 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdeG4399; Tue Feb 9 16:03:23 1999 Date: Tue, 9 Feb 1999 08:03:00 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id IAA03338 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think We saw this last week.. it crashed on MCLGET.. what is the pointer to the next free mbuf cluster? (not the next mbuf) (check the MCLGET macro to see what I mean) On Tue, 9 Feb 1999, Larry Lile wrote: > > I am working on improving the mtu sizes (above 1500) for the Olicom > token ring driver but I just ran across this panic that I really > don't understand. Any ideas? > > Larry Lile > lile@stdio.com > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xf07eddc2 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xf02096ff > stack pointer = 0x10:0xf6829cdc > frame pointer = 0x10:0xf6829d14 > 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 = 352 (ftpd) > interrupt mask = net > trap number = 12 > panic: page fault > > syncing disks... 7 7 done > > dumping to dev 20419, offset 761856 > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > 285 dumppcb.pcb_cr3 = rcr3(); > (kgdb) bt > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") > at ../../kern/kern_shutdown.c:446 > #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) > at ../../i386/i386/trap.c:942 > #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) > at ../../i386/i386/trap.c:835 > #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, > tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, > tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, > tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, > tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) > at ../../i386/i386/trap.c:437 > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > at ../../i386/isa/if_oltr.c:1236 > #6 0xf0210acc in ReturnCompletedBuffers () > #7 0x631000 in ?? () > #8 0xecc5b15a in ?? () > Cannot access memory at address 0x104018. > (kgdb) up 5 > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > at ../../i386/isa/if_oltr.c:1236 > 1236 MCLGET(m0, M_DONTWAIT); > (kgdb) print m0 > $1 = (struct mbuf *) 0xf0756a00 > (kgdb) list > 1231 if (m0 == NULL) { > 1232 ifp->if_ierrors++; > 1233 goto out; > 1234 } > 1235 if (ByteCount + 2 > MHLEN) { > 1236 MCLGET(m0, M_DONTWAIT); > 1237 mbuf_size = MCLBYTES; > 1238 if ((m0->m_flags & M_EXT) == 0) { > 1239 m_freem(m0); > 1240 ifp->if_ierrors++; > (kgdb) print mbstat > $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, > m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, > 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, > m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} > (kgdb) print *m0 > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > ext_buf = 0x3d637228
, > ext_free = 0, ext_size = 2048, ext_ref = 0}, > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > (kgdb) > > > 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 Feb 9 08:17:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04137 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 08:17:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04131 for ; Tue, 9 Feb 1999 08:17:08 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id IAA32509; Tue, 9 Feb 1999 08:13:08 -0800 (PST) From: Archie Cobbs Message-Id: <199902091613.IAA32509@bubba.whistle.com> Subject: Re: Docs on line disciplines? In-Reply-To: <199902091441.JAA02508@bmcgover-pc.cisco.com> from Brian McGovern at "Feb 9, 99 09:41:44 am" To: bmcgover@cisco.com (Brian McGovern) Date: Tue, 9 Feb 1999 08:13:08 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Brian McGovern writes: > I'm looking to see if anyone can point me at documents for implementing a new > line discipline... I'm looking at creating something that will take a > set of data (Voice RTP packets, to be precise), and handle packetizing it > while passing it up. > > The idea is to take a character at a time from the tty driver (a la l_rint), > and watch for special escaping of the character using the upper 8 bits > (ie - Start of Frame and End of Frame), then buffer the characters until > we have a complete packet of data. Then, I want to throw some header info > on the front end, and a trailer on the back, and stuff it in to the right > part of the clist for the tty (t_rawq or t_canq). You might take a look at the netgraph sync<->async converter node/line discipline, just to get started.. it doesn't use rawq or canq though.. ftp://ftp.whistle.com/pub/archie/netgraph/index.html -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 08:21:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04876 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 08:21:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04870 for ; Tue, 9 Feb 1999 08:21:45 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id IAA32532; Tue, 9 Feb 1999 08:20:27 -0800 (PST) From: Archie Cobbs Message-Id: <199902091620.IAA32532@bubba.whistle.com> Subject: Re: Unsafe code in libc in 3.0-RELEASE FreeBSD i386 In-Reply-To: <199902090823.IAA12593@pc2etp.mephi.ru> from Igor Gousarov at "Feb 9, 99 08:19:08 am" To: igusarov@chat.ru (Igor Gousarov) Date: Tue, 9 Feb 1999 08:20:27 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (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 Igor Gousarov writes: > The source file for setlocale function (/usr/src/lib/libc/locale/setlocale.c) > contains the line which might put libc into infinite loop: > Line 172: while ( i < _LC_LAST ) > Should be replaced with > Line 172: for ( ; i < _LC_LAST ; i++ ) > > And there's one more line to correct in the same source file: > Line 178: if (category) > This line rely on the fact that LC_ALL is defined to be equal 0. Correct > statement should look like > Line 178: if ( category != LC_ALL ) Please file a PR to make sure that this doesn't "slip through the cracks"... Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 08:31:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05875 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 08:31:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA05867 for ; Tue, 9 Feb 1999 08:31:26 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id LAA20491; Tue, 9 Feb 1999 11:22:31 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 11:22:31 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id IAA05869 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Arrgh, a little help with the derefernce. I can't seem to get it out of gdb. What is the correct command? I seem to bee finding all of the wrong ones :( Larry Lile lile@stdio.com On Tue, 9 Feb 1999, Julian Elischer wrote: > I think We saw this last week.. > it crashed on MCLGET.. > what is the pointer to the next free mbuf cluster? > (not the next mbuf) (check the MCLGET macro to see what I mean) > > > On Tue, 9 Feb 1999, Larry Lile wrote: > > > > > I am working on improving the mtu sizes (above 1500) for the Olicom > > token ring driver but I just ran across this panic that I really > > don't understand. Any ideas? > > > > Larry Lile > > lile@stdio.com > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xf07eddc2 > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xf02096ff > > stack pointer = 0x10:0xf6829cdc > > frame pointer = 0x10:0xf6829d14 > > 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 = 352 (ftpd) > > interrupt mask = net > > trap number = 12 > > panic: page fault > > > > syncing disks... 7 7 done > > > > dumping to dev 20419, offset 761856 > > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > > --- > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > 285 dumppcb.pcb_cr3 = rcr3(); > > (kgdb) bt > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") > > at ../../kern/kern_shutdown.c:446 > > #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) > > at ../../i386/i386/trap.c:942 > > #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) > > at ../../i386/i386/trap.c:835 > > #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, > > tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, > > tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, > > tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, > > tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) > > at ../../i386/i386/trap.c:437 > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > at ../../i386/isa/if_oltr.c:1236 > > #6 0xf0210acc in ReturnCompletedBuffers () > > #7 0x631000 in ?? () > > #8 0xecc5b15a in ?? () > > Cannot access memory at address 0x104018. > > (kgdb) up 5 > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > at ../../i386/isa/if_oltr.c:1236 > > 1236 MCLGET(m0, M_DONTWAIT); > > (kgdb) print m0 > > $1 = (struct mbuf *) 0xf0756a00 > > (kgdb) list > > 1231 if (m0 == NULL) { > > 1232 ifp->if_ierrors++; > > 1233 goto out; > > 1234 } > > 1235 if (ByteCount + 2 > MHLEN) { > > 1236 MCLGET(m0, M_DONTWAIT); > > 1237 mbuf_size = MCLBYTES; > > 1238 if ((m0->m_flags & M_EXT) == 0) { > > 1239 m_freem(m0); > > 1240 ifp->if_ierrors++; > > (kgdb) print mbstat > > $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, > > m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, > > 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, > > m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} > > (kgdb) print *m0 > > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > > ext_buf = 0x3d637228
, > > ext_free = 0, ext_size = 2048, ext_ref = 0}, > > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > > (kgdb) > > > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 09:38:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13530 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 09:38:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13519 for ; Tue, 9 Feb 1999 09:38:14 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id SAA01935; Tue, 9 Feb 1999 18:37:58 +0100 (CET) (envelope-from des) To: Dima Sivachenko Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Configuring cvsupd References: <199902091403.RAA02695@netserv1.chg.ru> From: Dag-Erling Smorgrav Date: 09 Feb 1999 18:37:58 +0100 In-Reply-To: Dima Sivachenko's message of "Tue, 9 Feb 1999 17:03:40 +0300 (MSK)" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dima Sivachenko writes: > I want to configure cvsupd to make local mirror of CVS repository. > Where can I read more than man-page about how to configure cvsupd? cd /usr/ports/net/cvsup-mirror ; make install clean DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 09:40:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13729 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 09:40:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13649; Tue, 9 Feb 1999 09:39:57 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id SAA01957; Tue, 9 Feb 1999 18:39:49 +0100 (CET) (envelope-from des) To: Eivind Eklund Cc: Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries References: <199902090932.JAA04327@excalibur.oceanis.net> <19990209120322.L46616@bitbox.follo.net> From: Dag-Erling Smorgrav Date: 09 Feb 1999 18:39:49 +0100 In-Reply-To: Eivind Eklund's message of "Tue, 9 Feb 1999 12:03:23 +0100" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund writes: > On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: > > I wanna add some sysctl entries to a loadable kernel > > module. As I'm sure I'm not the first doing that, > > if anybody knows... > It is not possible at the moment. :-( Gag. I intended to look into this, but got sidetracked. I'll put it on my TODO list. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 10:05:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16487 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:05:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16459 for ; Tue, 9 Feb 1999 10:05:01 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id MAA24043; Tue, 9 Feb 1999 12:56:09 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 12:56:08 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id KAA16478 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this what you were looking for? (kgdb) print *m0 $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { ext_buf = 0x3d637228
, ext_free = 0, ext_size = 2048, ext_ref = 0}, MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} (kgdb) print m0.M_dat.MH.MH_dat.MH_ext $6 = {ext_buf = 0x3d637228
, ext_free = 0, ext_size = 2048, ext_ref = 0} (kgdb) print ((union mcluster *)(m0.M_dat.MH.MH_dat.MH_ext.ext_buf))->mcl_next Cannot access memory at address 0x3d637228. or more to the point: (kgdb) print mclfree $8 = (union mcluster *) 0x3d637228 (kgdb) print *mclfree Cannot access memory at address 0x3d637228. (kgdb) Or am I misenterpreting MCLGET/MCLALLOC? I must have missed the messages about this, was it fixed? Larry Lile lile@stdio.com On Tue, 9 Feb 1999, Julian Elischer wrote: > I think We saw this last week.. > it crashed on MCLGET.. > what is the pointer to the next free mbuf cluster? > (not the next mbuf) (check the MCLGET macro to see what I mean) > > > On Tue, 9 Feb 1999, Larry Lile wrote: > > > > > I am working on improving the mtu sizes (above 1500) for the Olicom > > token ring driver but I just ran across this panic that I really > > don't understand. Any ideas? > > > > Larry Lile > > lile@stdio.com > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xf07eddc2 > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xf02096ff > > stack pointer = 0x10:0xf6829cdc > > frame pointer = 0x10:0xf6829d14 > > 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 = 352 (ftpd) > > interrupt mask = net > > trap number = 12 > > panic: page fault > > > > syncing disks... 7 7 done > > > > dumping to dev 20419, offset 761856 > > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > > --- > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > 285 dumppcb.pcb_cr3 = rcr3(); > > (kgdb) bt > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") > > at ../../kern/kern_shutdown.c:446 > > #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) > > at ../../i386/i386/trap.c:942 > > #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) > > at ../../i386/i386/trap.c:835 > > #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, > > tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, > > tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, > > tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, > > tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) > > at ../../i386/i386/trap.c:437 > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > at ../../i386/isa/if_oltr.c:1236 > > #6 0xf0210acc in ReturnCompletedBuffers () > > #7 0x631000 in ?? () > > #8 0xecc5b15a in ?? () > > Cannot access memory at address 0x104018. > > (kgdb) up 5 > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > at ../../i386/isa/if_oltr.c:1236 > > 1236 MCLGET(m0, M_DONTWAIT); > > (kgdb) print m0 > > $1 = (struct mbuf *) 0xf0756a00 > > (kgdb) list > > 1231 if (m0 == NULL) { > > 1232 ifp->if_ierrors++; > > 1233 goto out; > > 1234 } > > 1235 if (ByteCount + 2 > MHLEN) { > > 1236 MCLGET(m0, M_DONTWAIT); > > 1237 mbuf_size = MCLBYTES; > > 1238 if ((m0->m_flags & M_EXT) == 0) { > > 1239 m_freem(m0); > > 1240 ifp->if_ierrors++; > > (kgdb) print mbstat > > $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, > > m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, > > 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, > > m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} > > (kgdb) print *m0 > > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > > ext_buf = 0x3d637228
, > > ext_free = 0, ext_size = 2048, ext_ref = 0}, > > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > > (kgdb) > > > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 10:23:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18213 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:23:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18208; Tue, 9 Feb 1999 10:23:04 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA01839; Tue, 9 Feb 1999 10:18:50 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdrD1831; Tue Feb 9 18:18:46 1999 Date: Tue, 9 Feb 1999 10:18:41 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav cc: Eivind Eklund , Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-Reply-To: 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 someone said thay had code already.. was it warner? or maybe one of the Johns. julian On 9 Feb 1999, Dag-Erling Smorgrav wrote: > Eivind Eklund writes: > > On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: > > > I wanna add some sysctl entries to a loadable kernel > > > module. As I'm sure I'm not the first doing that, > > > if anybody knows... > > It is not possible at the moment. :-( > > Gag. I intended to look into this, but got sidetracked. I'll put it on > my TODO list. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > > 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 Feb 9 10:33:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19465 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:33:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19459 for ; Tue, 9 Feb 1999 10:33:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA02497; Tue, 9 Feb 1999 10:31:18 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpddx2492; Tue Feb 9 18:31:14 1999 Date: Tue, 9 Feb 1999 10:31:11 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id KAA19461 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG print the value of mclfree On Tue, 9 Feb 1999, Larry Lile wrote: > > > Arrgh, a little help with the derefernce. I can't seem to get it > out of gdb. What is the correct command? I seem to bee finding > all of the wrong ones :( > > Larry Lile > lile@stdio.com > > > > On Tue, 9 Feb 1999, Julian Elischer wrote: > > > I think We saw this last week.. > > it crashed on MCLGET.. > > what is the pointer to the next free mbuf cluster? > > (not the next mbuf) (check the MCLGET macro to see what I mean) > > > > > > On Tue, 9 Feb 1999, Larry Lile wrote: > > > > > > > > I am working on improving the mtu sizes (above 1500) for the Olicom > > > token ring driver but I just ran across this panic that I really > > > don't understand. Any ideas? > > > > > > Larry Lile > > > lile@stdio.com > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0xf07eddc2 > > > fault code = supervisor write, page not present > > > instruction pointer = 0x8:0xf02096ff > > > stack pointer = 0x10:0xf6829cdc > > > frame pointer = 0x10:0xf6829d14 > > > 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 = 352 (ftpd) > > > interrupt mask = net > > > trap number = 12 > > > panic: page fault > > > > > > syncing disks... 7 7 done > > > > > > dumping to dev 20419, offset 761856 > > > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > > > --- > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > > 285 dumppcb.pcb_cr3 = rcr3(); > > > (kgdb) bt > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > > #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") > > > at ../../kern/kern_shutdown.c:446 > > > #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) > > > at ../../i386/i386/trap.c:942 > > > #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) > > > at ../../i386/i386/trap.c:835 > > > #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, > > > tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, > > > tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, > > > tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, > > > tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) > > > at ../../i386/i386/trap.c:437 > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > > at ../../i386/isa/if_oltr.c:1236 > > > #6 0xf0210acc in ReturnCompletedBuffers () > > > #7 0x631000 in ?? () > > > #8 0xecc5b15a in ?? () > > > Cannot access memory at address 0x104018. > > > (kgdb) up 5 > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > > at ../../i386/isa/if_oltr.c:1236 > > > 1236 MCLGET(m0, M_DONTWAIT); > > > (kgdb) print m0 > > > $1 = (struct mbuf *) 0xf0756a00 > > > (kgdb) list > > > 1231 if (m0 == NULL) { > > > 1232 ifp->if_ierrors++; > > > 1233 goto out; > > > 1234 } > > > 1235 if (ByteCount + 2 > MHLEN) { > > > 1236 MCLGET(m0, M_DONTWAIT); > > > 1237 mbuf_size = MCLBYTES; > > > 1238 if ((m0->m_flags & M_EXT) == 0) { > > > 1239 m_freem(m0); > > > 1240 ifp->if_ierrors++; > > > (kgdb) print mbstat > > > $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, > > > m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, > > > 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, > > > m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} > > > (kgdb) print *m0 > > > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > > > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > > > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > > > ext_buf = 0x3d637228
, > > > ext_free = 0, ext_size = 2048, ext_ref = 0}, > > > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > > > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > > > (kgdb) > > > > > > > > > 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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 10:42:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20666 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:42:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20660 for ; Tue, 9 Feb 1999 10:42:39 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA02814; Tue, 9 Feb 1999 10:38:02 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdqN2805; Tue Feb 9 18:37:54 1999 Date: Tue, 9 Feb 1999 10:37:46 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id KAA20661 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ah yes that's what I want.. mclfree is garbage.... exactly liek we saw on our mystery crash This indicates that an mbuf cluster was used after it was freed, or it was allocated to two differnt users. that's exactly what we saw. What version EXACTLY (date etc) of FreeBSD? tell me.. what protocols are compiled in? and what netowrking drivers and what machines are on your nets (specifically, do you have MACS and the netatalk code compiled in? On Tue, 9 Feb 1999, Larry Lile wrote: > > Is this what you were looking for? > > (kgdb) print *m0 > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > ext_buf = 0x3d637228
, > ext_free = 0, ext_size = 2048, ext_ref = 0}, > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > > (kgdb) print m0.M_dat.MH.MH_dat.MH_ext > $6 = {ext_buf = 0x3d637228
, ext_free = 0, > ext_size = 2048, ext_ref = 0} > > (kgdb) print ((union mcluster *)(m0.M_dat.MH.MH_dat.MH_ext.ext_buf))->mcl_next > Cannot access memory at address 0x3d637228. > > or more to the point: > > (kgdb) print mclfree > $8 = (union mcluster *) 0x3d637228 *blam* Somethings not freeing mbuf clusters correctly. > (kgdb) print *mclfree > Cannot access memory at address 0x3d637228. > (kgdb) > > Or am I misenterpreting MCLGET/MCLALLOC? > > I must have missed the messages about this, was it fixed? > > Larry Lile > lile@stdio.com > > On Tue, 9 Feb 1999, Julian Elischer wrote: > > > I think We saw this last week.. > > it crashed on MCLGET.. > > what is the pointer to the next free mbuf cluster? > > (not the next mbuf) (check the MCLGET macro to see what I mean) > > > > > > On Tue, 9 Feb 1999, Larry Lile wrote: > > > > > > > > I am working on improving the mtu sizes (above 1500) for the Olicom > > > token ring driver but I just ran across this panic that I really > > > don't understand. Any ideas? > > > > > > Larry Lile > > > lile@stdio.com > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0xf07eddc2 > > > fault code = supervisor write, page not present > > > instruction pointer = 0x8:0xf02096ff > > > stack pointer = 0x10:0xf6829cdc > > > frame pointer = 0x10:0xf6829d14 > > > 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 = 352 (ftpd) > > > interrupt mask = net > > > trap number = 12 > > > panic: page fault > > > > > > syncing disks... 7 7 done > > > > > > dumping to dev 20419, offset 761856 > > > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > > > --- > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > > 285 dumppcb.pcb_cr3 = rcr3(); > > > (kgdb) bt > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 > > > #1 0xf013f55d in panic (fmt=0xf023f25b "page fault") > > > at ../../kern/kern_shutdown.c:446 > > > #2 0xf02024da in trap_fatal (frame=0xf6829ca0, eva=4034846146) > > > at ../../i386/i386/trap.c:942 > > > #3 0xf0202193 in trap_pfault (frame=0xf6829ca0, usermode=0, eva=4034846146) > > > at ../../i386/i386/trap.c:835 > > > #4 0xf0201daa in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -260740608, > > > tf_esi = -260740576, tf_ebp = -159212268, tf_isp = -159212344, > > > tf_ebx = -1073314688, tf_edx = 630210, tf_ecx = -265747636, > > > tf_eax = -260751360, tf_trapno = 12, tf_err = 2, tf_eip = -266299649, > > > tf_cs = 8, tf_eflags = 66066, tf_esp = -250238026, tf_ss = -250238028}) > > > at ../../i386/i386/trap.c:437 > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > > at ../../i386/isa/if_oltr.c:1236 > > > #6 0xf0210acc in ReturnCompletedBuffers () > > > #7 0x631000 in ?? () > > > #8 0xecc5b15a in ?? () > > > Cannot access memory at address 0x104018. > > > (kgdb) up 5 > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=0x1, > > > ByteCount=1514, FragmentCount=1, FragmentHandle=0x9, ReceiveStatus=0) > > > at ../../i386/isa/if_oltr.c:1236 > > > 1236 MCLGET(m0, M_DONTWAIT); > > > (kgdb) print m0 > > > $1 = (struct mbuf *) 0xf0756a00 > > > (kgdb) list > > > 1231 if (m0 == NULL) { > > > 1232 ifp->if_ierrors++; > > > 1233 goto out; > > > 1234 } > > > 1235 if (ByteCount + 2 > MHLEN) { > > > 1236 MCLGET(m0, M_DONTWAIT); > > > 1237 mbuf_size = MCLBYTES; > > > 1238 if ((m0->m_flags & M_EXT) == 0) { > > > 1239 m_freem(m0); > > > 1240 ifp->if_ierrors++; > > > (kgdb) print mbstat > > > $3 = {m_mbufs = 128, m_clusters = 100, m_spare = 0, m_clfree = 27, > > > m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {65453, 79, 4, > > > 0 }, m_mcfail = 0, m_mpfail = 0, m_msize = 128, > > > m_mclbytes = 2048, m_minclsize = 204, m_mlen = 108, m_mhlen = 96} > > > (kgdb) print *m0 > > > $4 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xf0756a20 "(rc=", > > > mh_len = 40, mh_type = 1, mh_flags = 2}, M_dat = {MH = {MH_pkthdr = { > > > rcvif = 0x0, len = 1492, header = 0x4000000}, MH_dat = {MH_ext = { > > > ext_buf = 0x3d637228
, > > > ext_free = 0, ext_size = 2048, ext_ref = 0}, > > > MH_databuf = "(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}}, > > > M_databuf = "\000\000\000\000Ô\005\000\000\000\000\000\004(rc=\000\000\000\000\000\b\000\000\000\000\000\000E\b\005Ô1º@\000@\006ï_\n\000\000\001\n\000\000\002\000\024\004\r\t\211ô¾\013ø¶\002P\020D\020Z²\000\000sap f4 ui/C len=\020@\020\000Z±Åì\000\000\203/íªª\003\000\000\000\b\000le"}} > > > (kgdb) > > > > > > > > > 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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 10:51:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21382 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:51:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles313.castles.com [208.214.167.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21367; Tue, 9 Feb 1999 10:50:53 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id KAA03973; Tue, 9 Feb 1999 10:46:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902091846.KAA03973@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Emmanuel DELOGET cc: eivind@FreeBSD.ORG (Eivind Eklund), hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Subject: Re: Adding sysctl entries In-reply-to: Your message of "Tue, 09 Feb 1999 16:07:26 +0100." <199902091507.PAA10987@excalibur.oceanis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Feb 1999 10:46:32 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As Eivind Eklund (thanks) said... > ** On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: > ** > [Sorry to disturb you :)] > ** > > ** > I wanna add some sysctl entries to a loadable kernel > ** > module. As I'm sure I'm not the first doing that, > ** > if anybody knows... > ** > ** It is not possible at the moment. :-( > > The result seems bad... I had to compile the kernel, then to > reboot... Each time I wonder wether I added a bug or not... > And if there is a bug, I'm out... Any idea would be welcome... This is why you have more than one kernel image in /, and why you can select which kernel to boot when you come up. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 10:55:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21964 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 10:55:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21957 for ; Tue, 9 Feb 1999 10:55:51 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id NAA26602; Tue, 9 Feb 1999 13:46:59 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 13:46:58 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1628243425-918586018=:14147" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1628243425-918586018=:14147 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE It looks like Jan 20 21:15 (EST) judging from the CVS directory and=20 sounds about right as I recall. drwxr-xr-x 2 root wheel 512 Jan 20 21:15 CVS I included the kernel config for you, the problem is that I am working on token-ring drivers and my code could easily be wrong. The funny thing is, I only see the problem with high mtu's like 4K. No problems at 1500. Also, I have an fxp interface in the machine (in reference to the last thread). I have also included the source to the oltr driver in-case you want to look at the code where I allocate the mubfs... Things appeared to start to go wrong in ReceiveFrameCompleted. The tok (IBM) driver is compiled in but the interface was down. Larry Lile lile@stdio.com On Tue, 9 Feb 1999, Julian Elischer wrote: > ah yes that's what I want.. > mclfree is garbage.... > exactly liek we saw on our mystery crash >=20 > This indicates that an mbuf cluster was used after it was freed, > or it was allocated to two differnt users. >=20 >=20 > that's exactly what we saw. >=20 > What version EXACTLY (date etc) of FreeBSD? >=20 >=20 > tell me.. > what protocols are compiled in?=20 > and what netowrking drivers and=20 > what machines are on your nets (specifically, do you have MACS > and the netatalk code compiled in? >=20 >=20 > On Tue, 9 Feb 1999, Larry Lile wrote: >=20 > >=20 > > Is this what you were looking for? > >=20 > > (kgdb) print *m0 > > $4 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D 0xf= 0756a20 "(rc=3D",=20 > > mh_len =3D 40, mh_type =3D 1, mh_flags =3D 2}, M_dat =3D {MH =3D {M= H_pkthdr =3D { > > rcvif =3D 0x0, len =3D 1492, header =3D 0x4000000}, MH_dat =3D = {MH_ext =3D { > > ext_buf =3D 0x3d637228
,=20 > > ext_free =3D 0, ext_size =3D 2048, ext_ref =3D 0},=20 > > MH_databuf =3D "(rc=3D\000\000\000\000\000\b\000\000\000\000\00= 0\000E\b\005=D41=BA@\000@\006=EF_\n\000\000\001\n\000\000\002\000\024\004\r= \t\211=F4=BE\013=F8=B6\002P\020D\020Z=B2\000\000sap f4 ui/C len=3D\020@\020= \000Z=B1=C5=EC\000\000\203/=C3=AD=AA=AA\003\000\000\000\b\000le"}},=20 > > M_databuf =3D "\000\000\000\000=D4\005\000\000\000\000\000\004(rc= =3D\000\000\000\000\000\b\000\000\000\000\000\000E\b\005=D41=BA@\000@\006= =EF_\n\000\000\001\n\000\000\002\000\024\004\r\t\211=F4=BE\013=F8=B6\002P\0= 20D\020Z=B2\000\000sap f4 ui/C len=3D\020@\020\000Z=B1=C5=EC\000\000\203/= =C3=AD=AA=AA\003\000\000\000\b\000le"}} > >=20 > > (kgdb) print m0.M_dat.MH.MH_dat.MH_ext > > $6 =3D {ext_buf =3D 0x3d637228
, ext_= free =3D 0,=20 > > ext_size =3D 2048, ext_ref =3D 0} > >=20 > > (kgdb) print ((union mcluster *)(m0.M_dat.MH.MH_dat.MH_ext.ext_buf))->m= cl_next > > Cannot access memory at address 0x3d637228. > >=20 > > or more to the point: > >=20 > > (kgdb) print mclfree > > $8 =3D (union mcluster *) 0x3d637228 >=20 > *blam* > Somethings not freeing mbuf clusters correctly. >=20 > > (kgdb) print *mclfree > > Cannot access memory at address 0x3d637228. > > (kgdb)=20 > >=20 > > Or am I misenterpreting MCLGET/MCLALLOC? > >=20 > > I must have missed the messages about this, was it fixed? > >=20 > > Larry Lile > > lile@stdio.com > >=20 > > On Tue, 9 Feb 1999, Julian Elischer wrote: > >=20 > > > I think We saw this last week.. > > > it crashed on MCLGET.. > > > what is the pointer to the next free mbuf cluster? > > > (not the next mbuf) (check the MCLGET macro to see what I mean) > > >=20 > > >=20 > > > On Tue, 9 Feb 1999, Larry Lile wrote: > > >=20 > > > >=20 > > > > I am working on improving the mtu sizes (above 1500) for the Olicom= =20 > > > > token ring driver but I just ran across this panic that I really > > > > don't understand. Any ideas?=20 > > > >=20 > > > > Larry Lile > > > > lile@stdio.com > > > >=20 > > > >=20 > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address=09=3D 0xf07eddc2 > > > > fault code=09=09=3D supervisor write, page not present > > > > instruction pointer=09=3D 0x8:0xf02096ff > > > > stack pointer=09 =3D 0x10:0xf6829cdc > > > > frame pointer=09 =3D 0x10:0xf6829d14 > > > > code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b > > > > =09=09=09=3D DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 > > > > current process=09=09=3D 352 (ftpd) > > > > interrupt mask=09=09=3D net=20 > > > > trap number=09=09=3D 12 > > > > panic: page fault > > > >=20 > > > > syncing disks... 7 7 done > > > >=20 > > > > dumping to dev 20419, offset 761856 > > > > dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 11= 3 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 = 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 = 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 = 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 = 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1=20 > > > > --- > > > > #0 boot (howto=3D256) at ../../kern/kern_shutdown.c:285 > > > > 285=09=09=09dumppcb.pcb_cr3 =3D rcr3(); > > > > (kgdb) bt > > > > #0 boot (howto=3D256) at ../../kern/kern_shutdown.c:285 > > > > #1 0xf013f55d in panic (fmt=3D0xf023f25b "page fault") > > > > at ../../kern/kern_shutdown.c:446 > > > > #2 0xf02024da in trap_fatal (frame=3D0xf6829ca0, eva=3D4034846146) > > > > at ../../i386/i386/trap.c:942 > > > > #3 0xf0202193 in trap_pfault (frame=3D0xf6829ca0, usermode=3D0, ev= a=3D4034846146) > > > > at ../../i386/i386/trap.c:835 > > > > #4 0xf0201daa in trap (frame=3D{tf_es =3D 16, tf_ds =3D 16, tf_edi= =3D -260740608,=20 > > > > tf_esi =3D -260740576, tf_ebp =3D -159212268, tf_isp =3D -159= 212344,=20 > > > > tf_ebx =3D -1073314688, tf_edx =3D 630210, tf_ecx =3D -265747= 636,=20 > > > > tf_eax =3D -260751360, tf_trapno =3D 12, tf_err =3D 2, tf_eip= =3D -266299649,=20 > > > > tf_cs =3D 8, tf_eflags =3D 66066, tf_esp =3D -250238026, tf_s= s =3D -250238028}) > > > > at ../../i386/i386/trap.c:437 > > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=3D0x1,= =20 > > > > ByteCount=3D1514, FragmentCount=3D1, FragmentHandle=3D0x9, Rece= iveStatus=3D0) > > > > at ../../i386/isa/if_oltr.c:1236 > > > > #6 0xf0210acc in ReturnCompletedBuffers () > > > > #7 0x631000 in ?? () > > > > #8 0xecc5b15a in ?? () > > > > Cannot access memory at address 0x104018. > > > > (kgdb) up 5 > > > > #5 0xf02096ff in DriverReceiveFrameCompleted (DriverHandle=3D0x1,= =20 > > > > ByteCount=3D1514, FragmentCount=3D1, FragmentHandle=3D0x9, Rece= iveStatus=3D0) > > > > at ../../i386/isa/if_oltr.c:1236 > > > > 1236=09 MCLGET(m0, M_DONTWAIT); > > > > (kgdb) print m0 > > > > $1 =3D (struct mbuf *) 0xf0756a00 > > > > (kgdb) list > > > > 1231=09 if (m0 =3D=3D NULL) { > > > > 1232=09 ifp->if_ierrors++; > > > > 1233=09 goto out; > > > > 1234=09 } > > > > 1235=09 if (ByteCount + 2 > MHLEN) { > > > > 1236=09 MCLGET(m0, M_DONTWAIT); > > > > 1237=09 mbuf_size =3D MCLBYTES; > > > > 1238=09 if ((m0->m_flags & M_EXT) =3D=3D 0) { > > > > 1239=09 m_freem(m0); > > > > 1240=09 ifp->if_ierrors++; > > > > (kgdb) print mbstat > > > > $3 =3D {m_mbufs =3D 128, m_clusters =3D 100, m_spare =3D 0, m_clfre= e =3D 27,=20 > > > > m_drops =3D 0, m_wait =3D 0, m_drain =3D 0, m_mtypes =3D {65453, = 79, 4,=20 > > > > 0 }, m_mcfail =3D 0, m_mpfail =3D 0, m_msize= =3D 128,=20 > > > > m_mclbytes =3D 2048, m_minclsize =3D 204, m_mlen =3D 108, m_mhlen= =3D 96} > > > > (kgdb) print *m0 > > > > $4 =3D {m_hdr =3D {mh_next =3D 0x0, mh_nextpkt =3D 0x0, mh_data =3D= 0xf0756a20 "(rc=3D",=20 > > > > mh_len =3D 40, mh_type =3D 1, mh_flags =3D 2}, M_dat =3D {MH = =3D {MH_pkthdr =3D { > > > > rcvif =3D 0x0, len =3D 1492, header =3D 0x4000000}, MH_dat = =3D {MH_ext =3D { > > > > ext_buf =3D 0x3d637228
= ,=20 > > > > ext_free =3D 0, ext_size =3D 2048, ext_ref =3D 0},=20 > > > > MH_databuf =3D "(rc=3D\000\000\000\000\000\b\000\000\000\00= 0\000\000E\b\005=D41=BA@\000@\006=EF_\n\000\000\001\n\000\000\002\000\024\0= 04\r\t\211=F4=BE\013=F8=B6\002P\020D\020Z=B2\000\000sap f4 ui/C len=3D\020@= \020\000Z=B1=C5=EC\000\000\203/=C3=AD=AA=AA\003\000\000\000\b\000le"}},=20 > > > > M_databuf =3D "\000\000\000\000=D4\005\000\000\000\000\000\004(= rc=3D\000\000\000\000\000\b\000\000\000\000\000\000E\b\005=D41=BA@\000@\006= =EF_\n\000\000\001\n\000\000\002\000\024\004\r\t\211=F4=BE\013=F8=B6\002P\0= 20D\020Z=B2\000\000sap f4 ui/C len=3D\020@\020\000Z=B1=C5=EC\000\000\203/= =C3=AD=AA=AA\003\000\000\000\b\000le"}} > > > > (kgdb) > > > >=20 > > > >=20 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > >=20 > > >=20 > > >=20 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > >=20 > >=20 > >=20 >=20 --0-1628243425-918586018=:14147 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_oltr.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="if_oltr.c" LyogDQogKiBDb3B5cmlnaHQgKGMpIDE5OTgsIExhcnJ5IExpbGUNCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogRm9yIGxhdGVzdCBzb3VyY2Vz IGFuZCBpbmZvcm1hdGlvbiBvbiB0aGlzIGRyaXZlciwgcGxlYXNlDQogKiBn byB0byBodHRwOi8vYW5hcmNoeS5zdGRpby5jb20uDQogKg0KICogUXVlc3Rp b25zLCBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBzaG91bGQgYmUgZGlyZWN0 ZWQgdG8NCiAqIExhcnJ5IExpbGUgPGxpbGVAc3RkaW8uY29tPi4NCiAqDQog KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5 IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0 aW9ucw0KICogYXJlIG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQog KiAgICBub3RpY2UgdW5tb2RpZmllZCwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMsIGFuZCB0aGUgZm9sbG93aW5nDQogKiAgICBkaXNjbGFpbWVyLg0KICog Mi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9k dWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1h dGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uDQogKg0K ICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFO RCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVYUFJFU1Mg T1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZPUiBBTlkg RElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBM QVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVU RSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBP UiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQogKiBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdI RVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZLCBPUiBU T1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZU V0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRg0K ICogU1VDSCBEQU1BR0UuDQogKg0KICogJElkOiBpZl9vbHRyLmMsdiAxLjE1 IDE5OTkvMDIvMDggMjM6Mzc6NDUgbGlsZSBFeHAgbGlsZSAkDQogKi8NCg0K DQojaW5jbHVkZSAicGNpLmgiDQojaW5jbHVkZSAib2x0ci5oIg0KI2luY2x1 ZGUgIm9wdF9pbmV0LmgiDQojaW5jbHVkZSAiYnBmaWx0ZXIuaCINCg0KI2lm IChOT0xUUiArIE5QQ0kpID4gMA0KDQovKiNkZWZpbmUgVFJsbGRJbmxpbmVJ TyovDQoNCiNkZWZpbmUgSVNBX0FEQVBURVJTICAoT0NfMzExNSB8IE9DXzMx MTcgfCBPQ18zMTE4KQ0KI2RlZmluZSBQQ0lfQURBUFRFUlMgIChPQ18zMTMz IHwgT0NfMzEzNiB8IE9DXzMxMzcgfCBcDQogICAgICAgICAgICAgICAgICAg ICAgIE9DXzMxMzkgfCBPQ18zMTQwIHwgT0NfMzE0MSB8IFwNCiAgICAgICAg ICAgICAgICAgICAgICAgT0NfMzI1MCB8IE9DXzM1NDAgKQ0KDQojZGVmaW5l IFBDSV9WRU5ET1JfT0xJQ09NIDB4MTA4RA0KDQpjaGFyICpBZGFwdGVyTmFt ZVtdID0gew0KICAgLyogIDAgKi8gIk9saWNvbSBYVCBBZGFwdGVyIFt1bnN1 cHBvcnRlZF0iLA0KICAgLyogIDEgKi8gIk9saWNvbSBPQy0zMTE1IiwNCiAg IC8qICAyICovICJPbGljb20gSVNBIDE2LzQgQWRhcHRlciAoT0MtMzExNyki LA0KICAgLyogIDMgKi8gIk9saWNvbSBJU0EgMTYvNCBBZGFwdGVyIChPQy0z MTE4KSIsDQogICAvKiAgNCAqLyAiT2xpY29tIE1DQSAxNi80IEFkYXB0ZXIg KE9DLTMxMjkpIFt1bnN1cHBvcnRlZF0iLA0KICAgLyogIDUgKi8gIk9saWNv bSBNQ0EgMTYvNCBBZGFwdGVyIChPQy0zMTI5KSBbdW5zdXBwb3J0ZWRdIiwN CiAgIC8qICA2ICovICJPbGljb20gTUNBIDE2LzQgQWRhcHRlciAoT0MtMzEy OSkgW3Vuc3VwcG9ydGVkXSIsDQogICAvKiAgNyAqLyAiT2xpY29tIEVJU0Eg MTYvNCBBZGFwdGVyIChPQy0zMTMzKSIsDQogICAvKiAgOCAqLyAiT2xpY29t IEVJU0EgMTYvNCBBZGFwdGVyIChPQy0zMTMzKSIsDQogICAvKiAgOSAqLyAi T2xpY29tIEVJU0EgMTYvNCBTZXJ2ZXIgQWRhcHRlciAoT0MtMzEzNSkiLA0K ICAgLyogMTAgKi8gIk9saWNvbSBQQ0kgMTYvNCBBZGFwdGVyIChPQy0zMTM2 KSIsDQogICAvKiAxMSAqLyAiT2xpY29tIFBDSSAxNi80IEFkYXB0ZXIgKE9D LTMxMzYpIiwNCiAgIC8qIDEyICovICJPbGljb20gUENJL0lJIDE2LzQgQWRh cHRlciAoT0MtMzEzNykiLA0KICAgLyogMTMgKi8gIk9saWNvbSBQQ0kgMTYv NCBBZGFwdGVyIChPQy0zMTM5KSIsDQogICAvKiAxNCAqLyAiT2xpY29tIFJh cGlkRmlyZSAzMTQwIDE2LzQgUENJIEFkYXB0ZXIgKE9DLTMxNDApIiwNCiAg IC8qIDE1ICovICJPbGljb20gUmFwaWRGaXJlIDMxNDEgRmliZXIgQWRhcHRl ciAoT0MtMzE0MSkiLA0KICAgLyogMTYgKi8gIk9saWNvbSBQQ01DSUEgMTYv NCBBZGFwdGVyIChPQy0zMjIwKSBbdW5zdXBwb3J0ZWRdIiwNCiAgIC8qIDE3 ICovICJPbGljb20gUENNQ0lBIDE2LzQgQWRhcHRlciAoT0MtMzEyMSwgT0Mt MzIzMCwgT0MtMzIzMikgW3Vuc3VwcG9ydGVkXSIsDQogICAvKiAxOCAqLyAi T2xpY29tIFBDTUNJQSAxNi80IEFkYXB0ZXIgKE9DLTMyNTApIiwNCiAgIC8q IDE5ICovICJPbGljb20gUmFwaWRGaXJlIDM1NDAgNC8xNi8xMDAgQWRhcHRl ciAoT0MtMzU0MCkiDQp9Ow0KDQojaW5jbHVkZSA8c3lzL3BhcmFtLmg+DQoj aW5jbHVkZSA8c3lzL3N5c3RtLmg+DQojaW5jbHVkZSA8c3lzL3Byb2MuaD4N CiNpbmNsdWRlIDxzeXMvc29ja2lvLmg+DQojaW5jbHVkZSA8c3lzL21hbGxv Yy5oPg0KI2luY2x1ZGUgPHN5cy9tYnVmLmg+DQojaW5jbHVkZSA8c3lzL3Nv Y2tldC5oPg0KI2luY2x1ZGUgPHN5cy9zeXNsb2cuaD4NCiNpbmNsdWRlIDxz eXMva2VybmVsLmg+DQojaW5jbHVkZSA8c3lzL2ludGVycnVwdC5oPg0KDQoj aW5jbHVkZSA8bmV0L2V0aGVybmV0Lmg+DQojaW5jbHVkZSA8bmV0L2lmLmg+ DQojaW5jbHVkZSA8bmV0L2lmX2FycC5oPg0KI2luY2x1ZGUgPG5ldC9pc284 ODAyNS5oPg0KI2luY2x1ZGUgPG5ldC9pZl9tZWRpYS5oPg0KDQojaWYgTkJQ RklMVEVSID4gMA0KI2luY2x1ZGUgPG5ldC9icGYuaD4NCiNlbmRpZg0KIA0K I2lmIE5QTlAgPiAwDQojaW5jbHVkZSA8aTM4Ni9pc2EvcG5wLmg+DQojZW5k aWYNCg0KI2luY2x1ZGUgPG1hY2hpbmUvY2xvY2suaD4NCiNpbmNsdWRlIDxt YWNoaW5lL21kX3Zhci5oPg0KI2luY2x1ZGUgPGkzODYvaXNhL2lzYV9kZXZp Y2UuaD4NCg0KI2lmIE5QQ0kgPiAwDQojaW5jbHVkZSA8cGNpL3BjaXZhci5o Pg0KI2luY2x1ZGUgPHBjaS9wY2lyZWcuaD4NCiNlbmRpZg0KDQojaWZuZGVm IFRSTExEX1NQRUVEX0FVVE8NCiNkZWZpbmUgVFJMTERfU1BFRURfQVVUTyAw DQojZW5kaWYNCg0Kdm9pZCAqb2x0cl9tYWxsb2Moc3NpemVfdCwgVFJsbGRB ZGFwdGVyQ29uZmlnX3QgKik7DQoNCi8qDQogKiBHbHVlIGZ1bmN0aW9ucyBw cm90b3R5cGVzIGZvciBQTVcga2l0IElPDQogKi8NCg0KI2lmbmRlZiBUUmxs ZElubGluZUlPDQpzdGF0aWMgdm9pZCBEcml2ZXJPdXRCeXRlICAgICAgICAg ICBfX1AoKHVuc2lnbmVkIHNob3J0LCB1bnNpZ25lZCBjaGFyKSk7DQpzdGF0 aWMgdm9pZCBEcml2ZXJPdXRXb3JkICAgICAgICAgICBfX1AoKHVuc2lnbmVk IHNob3J0LCB1bnNpZ25lZCBzaG9ydCkpOw0Kc3RhdGljIHZvaWQgRHJpdmVy T3V0RHdvcmQgICAgICAgICAgX19QKCh1bnNpZ25lZCBzaG9ydCwgdW5zaWdu ZWQgbG9uZykpOw0Kc3RhdGljIHZvaWQgRHJpdmVyUmVwT3V0Qnl0ZSAgICAg ICAgX19QKCh1bnNpZ25lZCBzaG9ydCwgdW5zaWduZWQgY2hhciAgKiwgaW50 KSk7DQpzdGF0aWMgdm9pZCBEcml2ZXJSZXBPdXRXb3JkICAgICAgICBfX1Ao KHVuc2lnbmVkIHNob3J0LCB1bnNpZ25lZCBzaG9ydCAqLCBpbnQpKTsNCnN0 YXRpYyB2b2lkIERyaXZlclJlcE91dER3b3JkICAgICAgIF9fUCgodW5zaWdu ZWQgc2hvcnQsIHVuc2lnbmVkIGxvbmcgICosIGludCkpOw0Kc3RhdGljIHVu c2lnbmVkIGNoYXIgIERyaXZlckluQnl0ZSAgX19QKCh1bnNpZ25lZCBzaG9y dCkpOw0Kc3RhdGljIHVuc2lnbmVkIHNob3J0IERyaXZlckluV29yZCAgX19Q KCh1bnNpZ25lZCBzaG9ydCkpOw0Kc3RhdGljIHVuc2lnbmVkIGxvbmcgIERy aXZlckluRHdvcmQgX19QKCh1bnNpZ25lZCBzaG9ydCkpOw0Kc3RhdGljIHZv aWQgRHJpdmVyUmVwSW5CeXRlICAgICAgICAgX19QKCh1bnNpZ25lZCBzaG9y dCwgdW5zaWduZWQgY2hhciAgKiwgaW50KSk7DQpzdGF0aWMgdm9pZCBEcml2 ZXJSZXBJbldvcmQgICAgICAgICBfX1AoKHVuc2lnbmVkIHNob3J0LCB1bnNp Z25lZCBzaG9ydCAqLCBpbnQpKTsNCnN0YXRpYyB2b2lkIERyaXZlclJlcElu RHdvcmQgICAgICAgIF9fUCgodW5zaWduZWQgc2hvcnQsIHVuc2lnbmVkIGxv bmcgICosIGludCkpOw0KI2VuZGlmIC8qVFJsbGRJbmxpbmVJTyovDQpzdGF0 aWMgdm9pZCBEcml2ZXJTdXNwZW5kICAgICAgICAgICAgICAgIF9fUCgodW5z aWduZWQgc2hvcnQpKTsNCnN0YXRpYyB2b2lkIERyaXZlclN0YXR1cyAgICAg ICAgICAgICAgICAgX19QKCh2b2lkICosIFRSbGxkU3RhdHVzX3QgKikpOw0K c3RhdGljIHZvaWQgRHJpdmVyQ2xvc2VDb21wbGV0ZWQgICAgICAgICBfX1Ao KHZvaWQgKikpOw0Kc3RhdGljIHZvaWQgRHJpdmVyU3RhdGlzdGljcyAgICAg ICAgICAgICBfX1AoKHZvaWQgKiwgVFJsbGRTdGF0aXN0aWNzX3QgKikpOw0K c3RhdGljIHZvaWQgRHJpdmVyVHJhbnNtaXRGcmFtZUNvbXBsZXRlZCBfX1Ao KHZvaWQgKiwgdm9pZCAqLCBpbnQpKTsNCnN0YXRpYyB2b2lkIERyaXZlclJl Y2VpdmVGcmFtZUNvbXBsZXRlZCAgX19QKCh2b2lkICosIGludCwgaW50LCB2 b2lkICosIGludCkpOw0KDQp0eXBlZGVmIHN0cnVjdCB0eF9idWYgew0KICAg IGludCBpbmRleDsNCiAgICBjaGFyICpidWY7DQp9IHR4X2J1Zl90Ow0KDQp0 eXBlZGVmIHN0cnVjdCByeF9idWYgew0KICAgIGludCAgICAgIGluZGV4Ow0K ICAgIGNoYXIgICAgICpidWY7DQp9IHJ4X2J1Zl90Ow0KDQojaWZuZGVmIEVY VFJBX09MVFINCiNpZiBOUENJID4gMA0KI2RlZmluZSBFWFRSQV9PTFRSCTgN CiNlbHNlIA0KI2RlZmluZSBFWFRSQV9PTFRSCTANCiNlbmRpZiAvKiBOUENJ ICovDQojZW5kaWYgLyogRVhUUkFfT0xUUiAqLw0KDQojaWZuZGVmIE9MVFJf UFJPTUlTQ19NT0RFDQojZGVmaW5lIE9MVFJfUFJPTUlTQ19NT0RFIChUUkxM RF9QUk9NX0xMQykNCiNlbmRpZg0KDQojZGVmaW5lIEFMTF9PUFRJT05TIChJ Rk1fVE9LX0VUUiB8IElGTV9UT0tfU1JDUlQgfCBJRk1fVE9LX0FMTFIgfCBJ Rk1fVE9LX0RUUiB8IElGTV9UT0tfQ0xBU1NJQyB8IElGTV9UT0tfQVVUTykN Cg0KLyogTGlzdCBzaXplcyBNVVNUIGJlIGEgcG93ZXIgb2YgMiAqLw0KI2Rl ZmluZSBUWF9MSVNUX1NJWkUgICAgMTYNCiNkZWZpbmUgUlhfTElTVF9TSVpF ICAgIDE2IA0KI2RlZmluZSBUWF9MSVNUX01BU0sgICAgKFRYX0xJU1RfU0la RSAtIDEpDQojZGVmaW5lIFJYX0xJU1RfTUFTSyAgICAoUlhfTElTVF9TSVpF IC0gMSkNCiNkZWZpbmUgUlhfQlVGRkVSX0xFTiAgICg4KjEwMjQpDQojZGVm aW5lIFRYX0JVRkZFUl9MRU4gICAoOCoxMDI0KQ0KDQpzdHJ1Y3Qgb2x0cl9z b2Z0YyB7DQogICAgc3RydWN0IGFycGNvbSBhcnBjb207DQogICAgc3RydWN0 IGlmbWVkaWEgaWZtZWRpYTsNCiAgICBUUmxsZEFkYXB0ZXJDb25maWdfdCAq Y29uZmlnOw0KICAgIFRSbGxkQWRhcHRlcl90ICpUUmxsZEFkYXB0ZXI7DQog ICAgaW50IHVuaXQ7DQogICAgdV9zaG9ydCBQcm9taXNjTW9kZTsNCiAgICB1 X3Nob3J0IEFkYXB0ZXJNb2RlOw0KICAgIGludCBod19zdGF0ZTsNCiNkZWZp bmUgSFdfVU5LTk9XTiAgICAgIDAgIC8qIGluaXRpYWwvYWJzZW50IHN0YXRl ICovDQojZGVmaW5lIEhXX0ZPVU5EICAgICAgICAxICAvKiBmb3VuZCwgbm90 IGluaXRpYWxpemVkICovDQojZGVmaW5lIEhXX0JBRCAgICAgICAgICAyICAv KiBmYXRhbCBlcnJvciAqLw0KI2RlZmluZSBIV19GQUlMRUQgICAgICAgMyAg LyogY2xvc2VkIGVnLiBieSByZW1vdmUsIGFsbG93IG1hbnVhbCByZW9wZW4g Ki8NCiNkZWZpbmUgSFdfTE9BRElORyAgICAgIDQNCiNkZWZpbmUgSFdfQ0xP U0lORyAgICAgIDUNCiNkZWZpbmUgSFdfQ0xPU0lORzIgICAgIDYNCiNkZWZp bmUgSFdfQ0xPU0VEICAgICAgIDcNCiNkZWZpbmUgSFdfT1BFTklORyAgICAg IDgNCiNkZWZpbmUgSFdfT1BFTiAgICAgICAgIDkNCiNkZWZpbmUgSFdfRVJS T1IgICAgICAgIDEwIC8qIHRlbXBvcmFyeSBlcnJvciAqLw0KDQogICAgdV9s b25nIEdyb3VwQWRkcmVzczsNCiAgICB1X2xvbmcgRnVuY3Rpb25hbEFkZHJl c3M7DQogICAgaW50IHBvbGxfYWRhcHRlcjsgDQoNCiAgICBpbnQgdHhfbmV4 dDsNCiAgICBpbnQgdHhfYXZhaWw7DQogICAgdHhfYnVmX3QgdHhfYnVmZmVy W1RYX0xJU1RfU0laRV07DQoNCiAgICBpbnQgcnhfbmV4dDsNCiAgICBpbnQg cnhfYXZhaWw7DQogICAgcnhfYnVmX3QgcnhfYnVmZmVyW1JYX0xJU1RfU0la RV07DQoNCiAgICBzdHJ1Y3QgY2FsbG91dF9oYW5kbGUgb2x0cl9jaDsNCiAg ICBzdHJ1Y3QgY2FsbG91dF9oYW5kbGUgcG9sbF9jaDsNCg0KfTsNCg0Kc3Rh dGljIHN0cnVjdCBvbHRyX3NvZnRjIG9sdHJfc29mdGNbTk9MVFIgKyBFWFRS QV9PTFRSXTsNCg0KLyoNCiAqIERyaXZlciBmdW5jdGlvbiBwcm90b3R5cGVz DQogKi8NCg0Kc3RhdGljIGludCAgb2x0cl9wcm9iZSAgIF9fUCgoc3RydWN0 IGlzYV9kZXZpY2UgKikpOw0Kc3RhdGljIGludCAgb2x0cl9hdHRhY2ggIF9f UCgoc3RydWN0IGlzYV9kZXZpY2UgKikpOyAgDQpzdGF0aWMgdm9pZCBvbHRy X2luaXQgICAgX19QKChzdHJ1Y3Qgb2x0cl9zb2Z0YyAqKSk7DQpzdGF0aWMg dm9pZCBvbHRyX2ludHIgICAgX19QKChpbnQpKTsNCnN0YXRpYyB2b2lkIG9s dHJfc3RhcnQgICBfX1AoKHN0cnVjdCBpZm5ldCAqKSk7DQpzdGF0aWMgdm9p ZCBvbHRyX3N0b3AgICAgX19QKChzdHJ1Y3Qgb2x0cl9zb2Z0YyAqKSk7DQpz dGF0aWMgaW50ICBvbHRyX2lvY3RsICAgX19QKChzdHJ1Y3QgaWZuZXQgKiwg dV9sb25nLCBjYWRkcl90KSk7DQoNCnN0YXRpYyBpbnQgb2x0cl9hdHRhY2hf Y29tbW9uICAgX19QKChzdHJ1Y3Qgb2x0cl9zb2Z0YyAqKSk7DQoNCnZvaWQg b2x0cl90aW1lb3V0IF9fUCgodm9pZCAqKSk7DQp2b2lkIGFkYXB0ZXJfcG9s bCBfX1AoKHZvaWQgKikpOw0KDQpzdHJ1Y3QgaXNhX2RyaXZlciBvbHRyZHJp dmVyID0gew0KICAgIG9sdHJfcHJvYmUsDQogICAgb2x0cl9hdHRhY2gsDQog ICAgIm9sdHIiLA0KICAgIDANCn07DQoNCmludCBpc2FfY2FyZHMgPSAwOw0K DQojaWYgTlBDSSA+IDANCnN0YXRpYyB1X2xvbmcgb2x0cl9jb3VudCA9IE5P TFRSOw0Kc3RhdGljIGNvbnN0IGNoYXIgKm9sdHJfcGNpX3Byb2JlCV9fUCgo cGNpY2lfdCwgcGNpZGlfdCkpOw0Kc3RhdGljIHZvaWQgb2x0cl9wY2lfYXR0 YWNoCQlfX1AoKHBjaWNpX3QsIGludCkpOw0Kc3RhdGljIHZvaWQgb2x0cl9w Y2lfaW50ciAgICAJCV9fUCgodm9pZCAqKSk7DQpzdGF0aWMgdm9pZCBvbHRy X3BjaV9zaHV0ZG93bgkJX19QKChpbnQsIHZvaWQgKikpOw0KDQpzdGF0aWMg c3RydWN0IHBjaV9kZXZpY2Ugb2x0cl9kZXZpY2UgPSB7DQogICAgIm9sdHIi LA0KICAgIG9sdHJfcGNpX3Byb2JlLA0KICAgIG9sdHJfcGNpX2F0dGFjaCwN CiAgICAmb2x0cl9jb3VudCwNCiAgICBOVUxMDQp9Ow0KDQpEQVRBX1NFVChw Y2lkZXZpY2Vfc2V0LCBvbHRyX2RldmljZSk7DQppbnQgcGNpX2NhcmRzID0g MDsNCiNlbmRpZiAvKiBOUENJICovDQoNCnN0YXRpYyBpbnQgIG9sdHJfaWZt ZWRpYV91cGQJX19QKChzdHJ1Y3QgaWZuZXQgKikpOw0Kc3RhdGljIHZvaWQg b2x0cl9pZm1lZGlhX3N0cyAgICBfX1AoKHN0cnVjdCBpZm5ldCAqLCBzdHJ1 Y3QgaWZtZWRpYXJlcSAqKSk7DQoNCnN0YXRpYyBUUmxsZERyaXZlcl90IG9s dHJMbGREcml2ZXIgPSB7DQogICAgVFJMTERfVkVSU0lPTiwNCiNpZm5kZWYg VFJsbGRJbmxpbmVJTw0KICAgIERyaXZlck91dEJ5dGUsDQogICAgRHJpdmVy T3V0V29yZCwNCiAgICBEcml2ZXJPdXREd29yZCwNCiAgICBEcml2ZXJSZXBP dXRCeXRlLA0KICAgIERyaXZlclJlcE91dFdvcmQsDQogICAgRHJpdmVyUmVw T3V0RHdvcmQsDQogICAgRHJpdmVySW5CeXRlLA0KICAgIERyaXZlckluV29y ZCwNCiAgICBEcml2ZXJJbkR3b3JkLA0KICAgIERyaXZlclJlcEluQnl0ZSwN CiAgICBEcml2ZXJSZXBJbldvcmQsDQogICAgRHJpdmVyUmVwSW5Ed29yZCwN CiNlbmRpZiAvKlRSbGxkSW5saW5lSU8qLw0KICAgIERyaXZlclN1c3BlbmQs DQogICAgRHJpdmVyU3RhdHVzLA0KICAgIERyaXZlckNsb3NlQ29tcGxldGVk LA0KICAgIERyaXZlclN0YXRpc3RpY3MsDQogICAgRHJpdmVyVHJhbnNtaXRG cmFtZUNvbXBsZXRlZCwNCiAgICBEcml2ZXJSZWNlaXZlRnJhbWVDb21wbGV0 ZWQsDQp9Ow0KDQpUUmxsZEFkYXB0ZXJDb25maWdfdCBvbHRyX2NvbmZpZ1tO T0xUUiArIEVYVFJBX09MVFJdOw0KDQp2b2lkICoNCm9sdHJfbWFsbG9jKFNp emUsIEFkYXB0ZXIpDQogICAgc3NpemVfdCBTaXplOw0KICAgIFRSbGxkQWRh cHRlckNvbmZpZ190ICpBZGFwdGVyOw0Kew0KDQogICAgLyogSWYgdGhlIGFk YXB0ZXIgbmVlZHMgbWVtb3J5IGJlbG93IDE2TSBmb3IgRE1BIHRoZW4gdXNl IGNvbnRpZ21hbGxvYyAqLw0KICAgIGlmIChBZGFwdGVyLT5tb2RlICYgVFJM TERfTU9ERV8xNk0pICAvKiBBZGFwdGVyIHVzaW5nIElTQSBETUEgYnVmZmVy IGJlbG93IDE2TSAqLw0KICAgICAgICByZXR1cm4oY29udGlnbWFsbG9jKFNp emUsIE1fREVWQlVGLCBNX05PV0FJVCwgMHVsLCAweGZmZmZmZnVsLCAxdWws IDB4MTAwMDB1bCkpOw0KICAgIGVsc2UNCiAgICAgICAgcmV0dXJuKG1hbGxv YyhTaXplLCBNX0RFVkJVRiwgTV9OT1dBSVQpKTsNCn0NCiAgICANCi8qDQog KiBEcml2ZXIgRnVuY3Rpb25zIA0KICovDQoNCnN0YXRpYyBpbnQNCm9sdHJf cHJvYmUoaXMpDQogICAgc3RydWN0IGlzYV9kZXZpY2UgKmlzOw0Kew0KICAg IHN0YXRpYyBpbnQgZmluZF9jb21wbGV0ZWQgPSAwLCBhc3NpZ25lZFtOT0xU Ul07DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gJm9sdHJfc29mdGNb aXMtPmlkX3VuaXRdOw0KICAgIGludCBpOw0KDQogICAgcHJpbnRmKCJvbHRy JWQ6IG9sdHJfcHJvYmVcbiIsIGlzLT5pZF91bml0KTsNCg0KICAgIC8qIE1h a2UgbGlmZSBlYXN5LCB1c2UgdGhlIE9saWNvbSBzdXBwbGllZCBmaW5kIGZ1 bmN0aW9uIG9uIHRoZSBmaXJzdCBwcm9iZQ0KICAgICAqIHRvIHByb2JlIGFs bCBvZiB0aGUgSVNBIGFkYXB0ZXJzLiAgVGhlbiBnaXZlIHRoZW0gdG8gZWFj aCB1bml0IGFzIHJlcXVlc3RlZC4NCiAgICAgKiBUcnkgdG8gbWF0Y2ggdGhl IGFkYXB0ZXJzIHRvIHVuaXRzIGJhc2VkIG9uIHRoZSBpb2Jhc2UsIGJ1dCBp ZiBpb2Jhc2U/IHRoZW4NCiAgICAgKiBqdXN0IGdpdmUgb3V0IHRoZSBuZXh0 IGF2YWlsYWJsZSBhZGFwdGVyLg0KICAgICAqLw0KICAgIGlmICghZmluZF9j b21wbGV0ZWQpIHsNCiAgICAgICAgaXNhX2NhcmRzID0gVFJsbGRGaW5kKCZv bHRyTGxkRHJpdmVyLCAmb2x0cl9jb25maWdbMF0sIElTQV9BREFQVEVSUywg Tk9MVFIpOw0KICAgICAgICAvKmZvciAoaSA9IDA7IGkgPCBpc2FfY2FyZHM7 IGkrKykgew0KICAgICAgICAgICAgcHJpbnRmKCJUUmxsZEZpbmQ6IGNhcmQg JWQgLSAlcyBNQUMgJTZEXG4iLCBpICsgMSwgQWRhcHRlck5hbWVbb2x0cl9j b25maWdbaV0udHlwZV0sIG9sdHJfY29uZmlnW2ldLm1hY2FkZHJlc3MsICI6 Iik7DQogICAgICAgIH0qLw0KICAgICAgICBmb3IgKGkgPSAwOyBpIDwgTk9M VFI7IGkrKykNCiAgICAgICAgICAgIGFzc2lnbmVkW2ldID0gMDsNCiAgICAg ICAgZmluZF9jb21wbGV0ZWQgPSAxOw0KICAgIH0NCg0KICAgIHNjLT51bml0 ID0gaXMtPmlkX3VuaXQ7DQogICAgc2MtPmh3X3N0YXRlID0gSFdfVU5LTk9X TjsNCg0KICAgIGlmIChmaW5kX2NvbXBsZXRlZCAmJiAoKGlzYV9jYXJkcyA9 PSAwKSB8fCAoaXMtPmlkX3VuaXQgPiBpc2FfY2FyZHMpKSkgDQogICAgICAg IHJldHVybigwKTsNCg0KICAgIGlmICgoKGlzLT5pZF9pb2Jhc2UgPCAweGEw MCkgfHwgKGlzLT5pZF9pb2Jhc2UgPiAweGJlMCkpICYmIChpcy0+aWRfaW9i YXNlICE9IDB4ZmZmZmZmZmYpKSB7DQogICAgICAgIHByaW50Zigib2x0ciVk OiBwb3J0IGFkZHJlc3MgaW1wb3NzaWJsZSAoMHglWClcbiIsIGlzLT5pZF91 bml0LCBpcy0+aWRfaW9iYXNlKTsNCiAgICAgICAgcmV0dXJuKDApOw0KICAg IH0NCg0KICAgIC8qIEF1dG8gYXNzaWduIGxvd2VzdCBhdmFpbGFibGUgY2Fy ZCBub3QgYWxyZWFkeSBpbiB1c2UgKi8NCiAgICBpZiAoaXMtPmlkX2lvYmFz ZSA9PSAweGZmZmZmZmZmKSB7DQogICAgICAgIHByaW50Zigib2x0ciVkOiBh dXRvIGFzc2lnbmluZyBjYXJkLlxuIiwgaXMtPmlkX3VuaXQpOw0KICAgICAg ICBmb3IgKGkgPSAwOyBhc3NpZ25lZFtpXTsgaSsrKTsNCiAgICAgICAgYXNz aWduZWRbaV0gPSAxOw0KICAgICAgICBzYy0+Y29uZmlnID0gJm9sdHJfY29u ZmlnW2ldOw0KICAgICAgICBpcy0+aWRfaW9iYXNlID0gc2MtPmNvbmZpZy0+ aW9iYXNlMDsgICAgICAgICAgICAgICAgICAgICAgICAvKiBDbGFpbSBvdXIg cG9ydCBzcGFjZSAqLw0KICAgICAgICBpZiAoIWlzLT5pZF9pcnEpIA0KICAg ICAgICAgICAgaXMtPmlkX2lycSA9ICgxIDw8IHNjLT5jb25maWctPmludGVy cnVwdGxldmVsKTsgICAgICAgICAvKiBDbGFpbSBvdXIgaW50ZXJydXB0ICov DQogICAgICAgIGlzLT5pZF9pbnRyID0gKGludGhhbmQyX3QgKilvbHRyX2lu dHI7DQogICAgICAgIHJlZ2lzdGVyX2ludHIoZmZzKGlzLT5pZF9pcnEpIC0g MSwgaXMtPmlkX2lkLCBpcy0+aWRfcmlfZmxhZ3MsIGlzLT5pZF9pbnRyLCAm bmV0X2ltYXNrLCBpcy0+aWRfdW5pdCk7DQogICAgICAgIGlmICgoaXMtPmlk X2RycSA9PSAweGZmZmZmZmZmKSAmJiAoc2MtPmNvbmZpZy0+ZG1hbGV2ZWwg IT0gVFJMTERfRE1BX1BJTykpDQogICAgICAgICAgICBpcy0+aWRfZHJxID0g c2MtPmNvbmZpZy0+ZG1hbGV2ZWw7ICAgICAgICAgICAgICAgICAgICAgIC8q IENsYWltIG91ciBkbWEgY2hhbm5lbCAqLw0KICAgICAgICBwcmludGYoIm9s dHIlZDogPCVzPiBbJTZEXVxuIiwgaXMtPmlkX3VuaXQsIEFkYXB0ZXJOYW1l W3NjLT5jb25maWctPnR5cGVdLCBzYy0+Y29uZmlnLT5tYWNhZGRyZXNzLCAi OiIpOw0KICAgICAgICBzYy0+aHdfc3RhdGUgPSBIV19GT1VORDsNCiAgICAg ICAgcmV0dXJuKDEpOw0KICAgIH0gZWxzZSB7DQogICAgLyogQXNzaWduIGJh c2VkIG9uIGlvYmFzZSBhZGRyZXNzIHByb3ZpZGVkIGluIGtlcm5lbCBjb25m aWcgKi8NCiAgICAgICAgZm9yIChpID0gMDsgaSA8IE5PTFRSOyBpKyspIHsN CiAgICAgICAgICAgIGlmIChpcy0+aWRfaW9iYXNlID09IG9sdHJfY29uZmln W2ldLmlvYmFzZTApIHsNCiAgICAgICAgICAgICAgICBpZiAoYXNzaWduZWRb aV0pIHsNCiAgICAgICAgICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IGFk YXB0ZXIgKDB4JVgpIGFscmVhZHkgYXNzaWduZWQuXG4iLCBpcy0+aWRfdW5p dCwgaXMtPmlkX2lvYmFzZSk7DQogICAgICAgICAgICAgICAgICAgIHJldHVy bigwKTsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgYXNz aWduZWRbaV0gPSAxOw0KICAgICAgICAgICAgICAgIHNjLT5jb25maWcgPSAm b2x0cl9jb25maWdbaV07DQogICAgICAgICAgICAgICAgaWYgKGlzLT5pZF9p cnEgPT0gMCkNCiAgICAgICAgICAgICAgICAgICAgaXMtPmlkX2lycSA9ICgx IDw8IHNjLT5jb25maWctPmludGVycnVwdGxldmVsKTsgICAgICAgICAvKiBD bGFpbSBvdXIgaW50ZXJydXB0ICovDQogICAgICAgICAgICAgICAgaXMtPmlk X2ludHIgPSAoaW50aGFuZDJfdCAqKW9sdHJfaW50cjsNCiAgICAgICAgICAg ICAgICByZWdpc3Rlcl9pbnRyKGZmcyhpcy0+aWRfaXJxKSAtIDEsIGlzLT5p ZF9pZCwgaXMtPmlkX3JpX2ZsYWdzLCBpcy0+aWRfaW50ciwgJm5ldF9pbWFz aywgaXMtPmlkX3VuaXQpOw0KICAgICAgICAgICAgICAgIGlmICgoaXMtPmlk X2RycSA9PSAweGZmZmZmZmZmKSAmJiAoc2MtPmNvbmZpZy0+ZG1hbGV2ZWwg IT0gVFJMTERfRE1BX1BJTykpDQogICAgICAgICAgICAgICAgICAgIGlzLT5p ZF9kcnEgPSBzYy0+Y29uZmlnLT5kbWFsZXZlbDsgICAgICAgICAgICAgICAg ICAgICAgLyogQ2xhaW0gb3VyIGRtYSBjaGFubmVsICovDQogICAgICAgICAg ICAgICAgcHJpbnRmKCJvbHRyJWQ6IDwlcz4gWyU2RF1cbiIsIGlzLT5pZF91 bml0LCBBZGFwdGVyTmFtZVtzYy0+Y29uZmlnLT50eXBlXSwgc2MtPmNvbmZp Zy0+bWFjYWRkcmVzcywgIjoiKTsNCiAgICAgICAgICAgICAgICBzYy0+aHdf c3RhdGUgPSBIV19GT1VORDsNCiAgICAgICAgICAgICAgICByZXR1cm4oMSk7 DQogICAgICAgICAgICB9DQogICAgICAgIH0NCiAgICB9DQogICAgcmV0dXJu KDApOyAvKiBDYXJkIHdhcyBub3QgZm91bmQgKi8NCn0NCg0KI2lmIE5QQ0kg PiAwDQpzdGF0aWMgY29uc3QgY2hhciAqDQpvbHRyX3BjaV9wcm9iZShjb25m aWdfaWQsIGRldmljZV9pZCkNCiAgICBwY2ljaV90IGNvbmZpZ19pZDsNCiAg ICBwY2lkaV90IGRldmljZV9pZDsNCnsNCiAgICB1X2NoYXIgUENJQ29uZmln dXJhdGlvblNwYWNlWzY0XTsNCiAgICB1X2xvbmcgY29tbWFuZDsNCiAgICBp bnQgaSwgaiwgcmM7DQoNCiAgICBwcmludGYoIm9sdHI6IG9sdHJfcGNpX3By b2JlXG4iKTsNCg0KICAgIGogPSBOT0xUUiArIHBjaV9jYXJkczsNCg0KICAg IGlmIChwY2lfY2FyZHMgPT0gRVhUUkFfT0xUUikNCiAgICAgICAgcmV0dXJu KE5VTEwpOw0KDQogICAgaWYgKCgoZGV2aWNlX2lkICYgMHhmZmZmKSA9PSBQ Q0lfVkVORE9SX09MSUNPTSkgJiYgDQogICAgICAgICAgKCgoKGRldmljZV9p ZCA+PiAxNikgJiAweGZmZmYpID09IDB4MDAwMSkgfHwgDQogICAgICAgICAg ICgoKGRldmljZV9pZCA+PiAxNikgJiAweGZmZmYpID09IDB4MDAwNCkgfHwg DQogICAgICAgICAgICgoKGRldmljZV9pZCA+PiAxNikgJiAweGZmZmYpID09 IDB4MDAwNSkgfHwgDQogICAgICAgICAgICgoKGRldmljZV9pZCA+PiAxNikg JiAweGZmZmYpID09IDB4MDAwNykgfHwgDQogICAgICAgICAgICgoKGRldmlj ZV9pZCA+PiAxNikgJiAweGZmZmYpID09IDB4MDAwOCkpKSB7DQoNCiAgICAg ICAgZm9yIChpID0gMDsgaSA8IDY0OyBpKyspDQogICAgICAgICAgICBQQ0lD b25maWd1cmF0aW9uU3BhY2VbaV0gPSBwY2lfY2ZncmVhZChjb25maWdfaWQs IGksIC8qYnl0ZXMqLzEpOw0KDQogICAgICAgIHJjID0gVFJsbGRQQ0lDb25m aWcoJm9sdHJMbGREcml2ZXIsICZvbHRyX2NvbmZpZ1tqXSwgUENJQ29uZmln dXJhdGlvblNwYWNlKTsNCg0KICAgICAgICBpZiAoKHJjID09IFRSTExEX1BD SUNPTkZJR19PSykgfHwgKHJjID09IFRSTExEX1BDSUNPTkZJR19TRVRfQ09N TUFORCkpIHsNCiAgICAgICAgICAgIGlmIChyYyA9PSBUUkxMRF9QQ0lDT05G SUdfU0VUX0NPTU1BTkQpIHsNCiAgICAgICAgICAgICAgICBwcmludGYoIm9s dHI6IHNldHRpbmcgYnVzLW1hc3RlciBtb2RlXG4iKTsNCiAgICAgICAgICAg ICAgICBjb21tYW5kID0gcGNpX2NvbmZfcmVhZChjb25maWdfaWQsIFBDSVJf Q09NTUFORCk7DQogICAgICAgICAgICAgICAgcGNpX2NvbmZfd3JpdGUoY29u ZmlnX2lkLCBQQ0lSX0NPTU1BTkQsIChjb21tYW5kIHwgUENJTV9DTURfQlVT TUFTVEVSRU4pKTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIHBjaV9j YXJkcysrOw0KICAgICAgICAgICAgcmV0dXJuIChBZGFwdGVyTmFtZVtvbHRy X2NvbmZpZ1tqXS50eXBlXSk7DQogICAgICAgIH0gZWxzZSB7DQogICAgICAg ICAgICBpZiAocmMgPT0gVFJMTERfUENJQ09ORklHX0ZBSUwpDQogICAgICAg ICAgICAgICAgcHJpbnRmKCJvbHRyOiBUUmxsZFBDSUNvbmZpZyBmYWlsZWQh XG4iKTsNCiAgICAgICAgICAgIGlmIChyYyA9PSBUUkxMRF9QQ0lDT05GSUdf VkVSU0lPTikNCiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHI6IHdyb25n IExMRCB2ZXJzaW9uXG4iKTsNCiAgICAgICAgfQ0KICAgIH0NCiAgICByZXR1 cm4oTlVMTCk7DQp9DQojZW5kaWYgLyogTlBDSSAqLw0KDQpzdGF0aWMgaW50 DQpvbHRyX2F0dGFjaChpcykNCiAgICBzdHJ1Y3QgaXNhX2RldmljZSAqaXM7 DQp7DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gJm9sdHJfc29mdGNb aXMtPmlkX3VuaXRdOw0KICAgIGludCByYzsNCg0KICAgIHNjLT51bml0ID0g aXMtPmlkX3VuaXQ7DQoNCiAgICBpZiAoIW9sdHJfYXR0YWNoX2NvbW1vbihz YykpDQogICAgICAgIHJldHVybigwKTsNCg0KICAgIC8qIElmIHRoZSBrZXJu ZWwgY29uZmlnIGRvZXMgbm90IG1hdGNoIHRoZSBjdXJyZW50IGNhcmQgY29u ZmlndXJhdGlvbiB0aGVuDQogICAgICogYWRqdXN0IHRoZSBjYXJkIHNldHRp bmdzIHRvIG1hdGNoIHRoZSBrZXJuZWwuDQogICAgICovDQogICAgaWYgKChm ZnMoaXMtPmlkX2lycSkgLSAxKSAhPSBzYy0+Y29uZmlnLT5pbnRlcnJ1cHRs ZXZlbCkgew0KICAgICAgICByYyA9IFRSbGxkU2V0SW50ZXJydXB0KHNjLT5U UmxsZEFkYXB0ZXIsIGlzLT5pZF9pcnEpOyANCiAgICAgICAgaWYgKHJjICE9 IFRSTExEX0NPTkZJR19PSykgeyAgDQogICAgICAgICAgICBwcmludGYoIm9s dHIlZDogVW5hYmxlIHRvIGNoYW5nZSBhZGFwdGVyIGludGVycnVwdCBsZXZl bCAoJXgpXG4iLCBzYy0+dW5pdCwgcmMpOw0KICAgICAgICAgICAgcmV0dXJu KDApOw0KICAgICAgICB9DQogICAgfSAgIA0KICAgICAgICANCiAgICAvKiBT ZXQgZG1hIGxldmVsLCBmYWxsIGJhY2sgdG8gcGlvIGlmIHBvc3NpYmxlLiAo Zm9sbG93aW5nIFNDTyBkcml2ZXIgZXhhbXBsZSkgKi8NCiAgICBpZiAoaXMt PmlkX2RycSAhPSBzYy0+Y29uZmlnLT5kbWFsZXZlbCkgew0KICAgICAgICBy YyA9IFRSbGxkU2V0RE1BKHNjLT5UUmxsZEFkYXB0ZXIsIGlzLT5pZF9kcnEs ICZzYy0+Y29uZmlnLT5tb2RlKTsNCiAgICAgICAgaWYgKHJjICE9IFRSTExE X0NPTkZJR19PSykgew0KICAgICAgICAgICAgaWYgKChzYy0+Y29uZmlnLT5k bWFsZXZlbCAhPSBUUkxMRF9ETUFfUElPKSAmJg0KICAgICAgICAgICAgICAg IChUUmxsZFNldERNQShzYy0+VFJsbGRBZGFwdGVyLCBUUkxMRF9ETUFfUElP LCAmc2MtPmNvbmZpZy0+bW9kZSkgIT0gVFJMTERfQ09ORklHX09LKSkgew0K ICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiB1bmFibGUgdG8gY2hh bmdlIGRtYSBsZXZlbCBmcm9tICVkIHRvICVkICgleClcbiIsIHNjLT51bml0 LA0KICAgICAgICAgICAgICAgICAgICAgICAgc2MtPmNvbmZpZy0+ZG1hbGV2 ZWwsIGlzLT5pZF9kcnEsIHJjKTsNCiAgICAgICAgICAgIH0NCiAgICAgICAg ICAgIHByaW50Zigib2x0ciVkOiBVbmFibGUgdG8gY2hhbmdlIGFkYXB0ZXIg ZG1hIGxldmVsLCB1c2luZyBQSU8gbW9kZSAoJXgpXG4iLCBzYy0+dW5pdCwg cmMpOw0KICAgICAgICAgICAgc2MtPmNvbmZpZy0+ZG1hbGV2ZWwgPSBUUkxM RF9ETUFfUElPOw0KICAgICAgICAgICAgcmMgPSBUUmxsZFNldERNQShzYy0+ VFJsbGRBZGFwdGVyLCBpcy0+aWRfZHJxLCAmc2MtPmNvbmZpZy0+bW9kZSk7 DQogICAgICAgIH0NCiAgICAgICAgaXMtPmlkX2lycSA9IHNjLT5jb25maWct PmRtYWxldmVsOw0KICAgIH0NCiAgICByZXR1cm4oMSk7DQp9DQoNCiNpZiBO UENJID4gMA0Kc3RhdGljIHZvaWQNCm9sdHJfcGNpX2F0dGFjaChjb25maWdf aWQsIHVuaXQpDQogICAgcGNpY2lfdCBjb25maWdfaWQ7DQogICAgaW50IHVu aXQ7DQp7DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gJm9sdHJfc29m dGNbdW5pdF07DQoNCiAgICBzYy0+dW5pdCA9IHVuaXQ7DQogICAgc2MtPmNv bmZpZyA9ICZvbHRyX2NvbmZpZ1t1bml0XTsNCiAgICBzYy0+aHdfc3RhdGUg PSBIV19GT1VORDsNCg0KICAgIHByaW50Zigib2x0ciVkOiBtYWMgYWRkcmVz cyBbJTZEXVxuIiwgc2MtPnVuaXQsIHNjLT5jb25maWctPm1hY2FkZHJlc3Ms ICI6Iik7DQoNCiAgICBpZiAoIW9sdHJfYXR0YWNoX2NvbW1vbihzYykpDQog ICAgICAgIHJldHVybjsNCg0KICAgIC8qIE1hcCBvdXIgaW50ZXJydXB0ICov DQogICAgaWYgKCFwY2lfbWFwX2ludChjb25maWdfaWQsIG9sdHJfcGNpX2lu dHIsIHNjLCAmbmV0X2ltYXNrKSkgew0KICAgICAgICBwcmludGYoIm9sdHIl ZDogY291bGRuJ3QgbWFwIGludGVycnVwdFxuIiwgdW5pdCk7DQogICAgICAg IHJldHVybjsNCiAgICB9DQp9DQojZW5kaWYgLyogTlBDSSAqLw0KDQpzdGF0 aWMgaW50DQpvbHRyX2F0dGFjaF9jb21tb24oc2MpDQogICAgc3RydWN0IG9s dHJfc29mdGMgKnNjOw0Kew0KICAgIHN0cnVjdCBpZm5ldCAqaWZwID0gJnNj LT5hcnBjb20uYWNfaWY7DQogICAgdV9pbnQgIGJ1ZnNpemU7DQogICAgaW50 ICAgIHJjLCBpLCBqOw0KICANCiAgICAvKnByaW50Zigib2x0ciVkOiBhdHRh Y2hfY29tbW9uIGNhbGxlZFxuIiwgc2MtPnVuaXQpOyovDQoNCiAgICAvKiBB bGxvY2F0ZSBhZGFwdGVyIG1lbW9yeSBidWZmZXIgKi8NCiAgICBidWZzaXpl ID0gVFJsbGRBZGFwdGVyU2l6ZSgpOw0KICAgIHNjLT5UUmxsZEFkYXB0ZXIg PSAoVFJsbGRBZGFwdGVyX3QgKilvbHRyX21hbGxvYyhidWZzaXplLCBzYy0+ Y29uZmlnKTsNCiAgICBpZiAoc2MtPlRSbGxkQWRhcHRlciA9PSBOVUxMKSB7 DQogICAgICAgIHByaW50Zigib2x0ciVkOiBVbmFibGUgdG8gYWxsb2NhdGUg YWRhcHRlciBtZW1vcnkgYmxvY2sgKCVkIGJ5dGVzKVxuIiwgc2MtPnVuaXQs IGJ1ZnNpemUpOw0KICAgIH0gDQogICAgLypwcmludGYoIm9sdHIlZDogQWRh cHRlciBtZW1vcnkgYmxvY2sgKCVwICVkIGJ5dGVzKVxuIiwgc2MtPnVuaXQs IHNjLT5UUmxsZEFkYXB0ZXIsIGJ1ZnNpemUpOyovDQoNCiAgICAvKiBTZXR1 cCB0cmFuc21pdCBwb29sICovDQogICAgZm9yIChpID0gMDsgaSA8IFRYX0xJ U1RfU0laRTsgaSsrKSB7DQogICAgICAgIHNjLT50eF9idWZmZXJbaV0uaW5k ZXggPSBpOw0KICAgICAgICBzYy0+dHhfYnVmZmVyW2ldLmJ1ZiA9IChjaGFy ICopb2x0cl9tYWxsb2MoVFhfQlVGRkVSX0xFTiwgc2MtPmNvbmZpZyk7DQog ICAgICAgIC8qIElmIHdlIGhhdmUgYSBmYWlsdXJlIHRoZW4gZnJlZSBldmVy eXRoaW5nIGFuZCBnZXQgb3V0ICovDQogICAgICAgIGlmICghc2MtPnR4X2J1 ZmZlcltpXS5idWYpIHsNCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBV bmFibGUgdG8gYWxsb2NhdGUgdHJhbnNtaXQgYnVmZmVycy5cbiIsIHNjLT51 bml0KTsNCiAgICAgICAgICAgIGZvciAoaiA9IDA7IGogPCBpOyBqKyspDQog ICAgICAgICAgICAgICAgZnJlZShzYy0+dHhfYnVmZmVyW2pdLmJ1ZiwgTV9E RVZCVUYpOw0KICAgICAgICAgICAgcmV0dXJuKDApOw0KICAgICAgICB9DQog ICAgfQ0KICAgIHNjLT50eF9uZXh0ID0gMDsNCiAgICBzYy0+dHhfYXZhaWwg PSBUWF9MSVNUX1NJWkU7DQoNCiAgICAvKiBTZXR1cCByZWNlaXZlIHBvb2wg Ki8NCiAgICBmb3IgKGkgPSAwOyBpIDwgUlhfTElTVF9TSVpFOyBpKyspIHsN CiAgICAgICAgc2MtPnJ4X2J1ZmZlcltpXS5pbmRleCA9IGk7DQogICAgICAg IHNjLT5yeF9idWZmZXJbaV0uYnVmID0gKGNoYXIgKilvbHRyX21hbGxvYyhS WF9CVUZGRVJfTEVOLCBzYy0+Y29uZmlnKTsNCiAgICAgICAgLyogSWYgd2Ug aGF2ZSBhIGZhaWx1cmUgdGhlbiBmcmVlIGV2ZXJ5dGhpbmcgYW5kIGdldCBv dXQgKi8NCiAgICAgICAgaWYgKCFzYy0+cnhfYnVmZmVyW2ldLmJ1ZikgeyAg ICAgICAgICANCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBVbmFibGUg dG8gYWxsb2NhdGUgcmVjZWl2ZSBidWZmZXJzLlxuIiwgc2MtPnVuaXQpOw0K ICAgICAgICAgICAgZm9yIChqID0gMDsgaiA8IGk7IGorKykNCiAgICAgICAg ICAgICAgICBmcmVlKHNjLT5yeF9idWZmZXJbal0uYnVmLCBNX0RFVkJVRik7 DQogICAgICAgICAgICByZXR1cm4oMCk7DQogICAgICAgIH0NCiAgICB9ICAg DQogICAgc2MtPnJ4X25leHQgPSAwOw0KICAgIHNjLT5yeF9hdmFpbCA9IFJY X0xJU1RfU0laRTsgDQogICAgLypwcmludGYoIm9sdHIlZDogQWxsb2NhdGVk IHJlY2VpdmUgYnVmZmVyc1xuIiwgc2MtPnVuaXQpOyAqLw0KICAgIA0KICAg IC8qIFNldCB1cCBhZGFwdGVyIHBvbGxpbmcgbWVjaGFuaXNtICovDQogICAg c2MtPnBvbGxfYWRhcHRlciA9IDE7DQogICAgY2FsbG91dF9oYW5kbGVfaW5p dCgmc2MtPnBvbGxfY2gpOw0KICAgIHNjLT5wb2xsX2NoID0gdGltZW91dChh ZGFwdGVyX3BvbGwsICh2b2lkICopc2MtPnVuaXQsICgxKmh6KS8xMDAwKTsN CiAgICBjYWxsb3V0X2hhbmRsZV9pbml0KCZzYy0+b2x0cl9jaCk7DQoNCiAg ICAvKiBJbml0aWFsaXplIGFkYXB0ZXIgKi8NCiAgICByYyA9IFRSbGxkQWRh cHRlckluaXQoJm9sdHJMbGREcml2ZXIsIHNjLT5UUmxsZEFkYXB0ZXIsIGt2 dG9wKHNjLT5UUmxsZEFkYXB0ZXIpLCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgKHZvaWQgKilzYy0+dW5pdCwgc2MtPmNvbmZpZyk7DQogICAgaWYg KHJjICE9IFRSTExEX0lOSVRfT0spIHsNCiAgICAgICAgc3dpdGNoIChyYykg ew0KICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX05PVF9GT1VORDoNCiAg ICAgICAgICAgICAgICBwcmludGYoIm9sdHIlZDogQWRhcHRlciBub3QgZm91 bmQgb3IgbWFsZnVuY3Rpb25pbmcuXG4iLCBzYy0+dW5pdCk7DQogICAgICAg ICAgICAgICAgc2MtPmh3X3N0YXRlID0gSFdfQkFEOw0KICAgICAgICAgICAg ICAgIHJldHVybigwKTsNCiAgICAgICAgICAgIGNhc2UgVFJMTERfSU5JVF9V TlNVUFBPUlRFRDoNCiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIlZDog QWRhcHRlciBub3Qgc3VwcG9ydGVkIGJ5IGxvdyBsZXZlbCBkcml2ZXIuXG4i LCBzYy0+dW5pdCk7DQogICAgICAgICAgICAgICAgc2MtPmh3X3N0YXRlID0g SFdfVU5LTk9XTjsNCiAgICAgICAgICAgICAgICByZXR1cm4oMCk7DQogICAg ICAgICAgICBjYXNlIFRSTExEX0lOSVRfUEhZUzE2Og0KICAgICAgICAgICAg ICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVyIG1lbW9yeSBibG9jayBhYm92 ZSAxNk0sIG11c3QgYmUgYmVsb3cgMTZNLlxuIiwgc2MtPnVuaXQpOw0KICAg ICAgICAgICAgICAgIHJldHVybigwKTsNCiAgICAgICAgICAgIGNhc2UgVFJM TERfSU5JVF9WRVJTSU9OOg0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0 ciVkOiBMb3cgbGV2ZWwgZHJpdmVyIHZlcnNpb24gbWlzbWF0Y2guXG4iLCBz Yy0+dW5pdCk7DQogICAgICAgICAgICAgICAgcmV0dXJuKDApOw0KICAgICAg ICAgICAgZGVmYXVsdDoNCiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIl ZDogVW5rbm93biBpbml0aWxpemF0aW9uIGVycm9yIG9jY291cmVkICgleCku XG4iLCBzYy0+dW5pdCwgcmMpOw0KICAgICAgICAgICAgICAgIHJldHVybigw KTsNCiAgICAgICAgfQ0KICAgIH0NCg0KICAgIC8qIERvd25sb2FkIEFkYXB0 ZXIgTWljcm9jb2RlICovDQogICAgLypwcmludGYoIm9sdHIlZDogRG93bmxv YWRpbmcgYWRhcHRlciBtaWNyb2NvZGUuLi4iLCBzYy0+dW5pdCk7Ki8NCiAg ICBzYy0+aHdfc3RhdGUgPSBIV19MT0FESU5HOw0KICAgIHN3aXRjaChzYy0+ Y29uZmlnLT5tYWN0eXBlKSB7DQogICAgICAgIGNhc2UgVFJMTERfTUFDX1RN UzogICAgICAgICAgIC8qIFRNUyBtaWNyb2NvZGUgKi8NCiAgICAgICAgICAg IHJjID0gVFJsbGREb3dubG9hZChzYy0+VFJsbGRBZGFwdGVyLCBUUmxsZE1h Y0NvZGUpOw0KICAgICAgICAgICAgYnJlYWs7DQogICAgICAgIGNhc2UgVFJM TERfTUFDX0hBV0tFWUU6ICAgICAgICAvKiBIYXdrZXllIG1pY3JvY29kZSAq Lw0KICAgICAgICAgICAgcmMgPSBUUmxsZERvd25sb2FkKHNjLT5UUmxsZEFk YXB0ZXIsIFRSbGxkSGF3a2V5ZU1hYyk7DQogICAgICAgICAgICBicmVhazsN CiAgICAgICAgY2FzZSBUUkxMRF9NQUNfQlVMTFNFWUU6ICAgICAgLyogQnVs bHNleWUgbWljcm9jb2RlICovDQogICAgICAgICAgICByYyA9IFRSbGxkRG93 bmxvYWQoc2MtPlRSbGxkQWRhcHRlciwgVFJsbGRCdWxsc2V5ZU1hYyk7DQog ICAgICAgICAgICBicmVhazsNCiAgICAgICAgZGVmYXVsdDoNCiAgICAgICAg ICAgIHByaW50Zigib2x0ciVkOiB1bmtub3duIG1hY3R5cGUgJWRcbiIsIHNj LT51bml0LCBzYy0+Y29uZmlnLT5tYWN0eXBlKTsNCiAgICAgICAgICAgIHJl dHVybigwKTsNCiAgICB9DQogICAgLyppZiAocmMgPT0gVFJMTERfRE9XTkxP QURfT0spIA0KICAgICAgICBwcmludGYoImRvbmVcbiIpOyovDQogICAgaWYg KChyYyA9PSBUUkxMRF9ET1dOTE9BRF9FUlJPUikgfHwgKHJjID09IFRSTExE X1NUQVRFKSkgew0KICAgICAgICBwcmludGYoIm9sdHIlZDogQWRhcHRlciBt aWNyb2NvZGUgZG93bmxvYWQgZmFpbGVkISAocmMgPSAleClcbiIsIHNjLT51 bml0LCByYyk7DQogICAgICAgIHNjLT5od19zdGF0ZSA9IEhXX0JBRDsNCiAg ICAgICAgcmV0dXJuKDApOyAgICAgDQogICAgfQ0KDQogICAgVFJsbGRTZXRT cGVlZChzYy0+VFJsbGRBZGFwdGVyLCBUUkxMRF9TUEVFRF9BVVRPKTsNCg0K ICAgIHNjLT5Qcm9taXNjTW9kZSA9IDA7DQogICAgc2MtPkFkYXB0ZXJNb2Rl ID0gMDsNCg0KICAgIC8qIERvIHRoZSBpZm5ldCBpbml0aWFsaXphdGlvbiAq Lw0KICAgIGlmcC0+aWZfc29mdGMgICA9IHNjOw0KICAgIGlmcC0+aWZfdW5p dCAgICA9IHNjLT51bml0Ow0KICAgIGlmcC0+aWZfbmFtZSAgICA9ICJvbHRy IjsNCiAgICBpZnAtPmlmX291dHB1dCAgPSBpc284ODAyNV9vdXRwdXQ7DQog ICAgaWZwLT5pZl9pbml0ICAgID0gKGlmX2luaXRfZl90ICopb2x0cl9pbml0 Ow0KICAgIGlmcC0+aWZfc3RhcnQgICA9IG9sdHJfc3RhcnQ7DQogICAgaWZw LT5pZl9pb2N0bCAgID0gb2x0cl9pb2N0bDsNCiAgICBpZnAtPmlmX2ZsYWdz ICAgPSBJRkZfQlJPQURDQVNUIHwgSUZGX01VTFRJQ0FTVCB8IElGRl9TSU1Q TEVYOw0KICAgIGJjb3B5KHNjLT5jb25maWctPm1hY2FkZHJlc3MsIHNjLT5h cnBjb20uYWNfZW5hZGRyLCBzaXplb2Yoc2MtPmNvbmZpZy0+bWFjYWRkcmVz cykpOw0KDQogICAgLyogU2V0IHVwIGNvbW1vbiBpZm1lZGlhIG9wdGlvbnMg Ki8NCiAgICBpZm1lZGlhX2luaXQoJnNjLT5pZm1lZGlhLCAwLCBvbHRyX2lm bWVkaWFfdXBkLCBvbHRyX2lmbWVkaWFfc3RzKTsNCg0KICAgIGlmbWVkaWFf YWRkKCZzYy0+aWZtZWRpYSwgSUZNX1RPS0VOIHwgSUZNX0FVVE8sIDAgLCBO VUxMKTsNCiAgICBpZm1lZGlhX2FkZCgmc2MtPmlmbWVkaWEsIElGTV9UT0tF TiB8IElGTV9UT0tfVVRQNCwgMCAsIE5VTEwpOw0KICAgIGlmbWVkaWFfYWRk KCZzYy0+aWZtZWRpYSwgSUZNX1RPS0VOIHwgSUZNX1RPS19VVFAxNiwgMCAs IE5VTEwpOw0KICAgIA0KICAgIGlmbWVkaWFfc2V0KCZzYy0+aWZtZWRpYSwg SUZNX1RPS0VOIHwgSUZNX0FVVE8pOw0KDQogICAgaWZfYXR0YWNoKGlmcCk7 DQogICAgaXNvODgwMjVfaWZhdHRhY2goaWZwKTsNCg0KI2lmIE5CUEZJTFRF UiA+IDANCiAgICBicGZhdHRhY2goaWZwLCBETFRfSUVFRTgwMiwgc2l6ZW9m KHN0cnVjdCBpc284ODAyNV9oZWFkZXIpKTsNCiNlbmRpZg0KDQogICAgcmV0 dXJuKDEpOw0KfQ0KDQojaWYgTlBDSSA+IDANCnN0YXRpYyB2b2lkDQpvbHRy X3BjaV9zaHV0ZG93bihob3d0bywgc2MpDQogICAgaW50IGhvd3RvOw0KICAg IHZvaWQgKnNjOw0Kew0KICAgIHByaW50Zigib2x0cjogb2x0cl9wY2lfc2h1 dGRvd24gY2FsbGVkXG4iKTsNCn0NCiNlbmRpZiAvKiBOUENJICovDQoNCnN0 YXRpYyBpbnQNCm9sdHJfaWZtZWRpYV91cGQoaWZwKQ0KICAgIHN0cnVjdCBp Zm5ldCAqaWZwOw0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9IGlm cC0+aWZfc29mdGM7DQogICAgc3RydWN0IGlmbWVkaWEgKmlmbSAgID0gJnNj LT5pZm1lZGlhOw0KDQogICAgaWYgKElGTV9UWVBFKGlmbS0+aWZtX21lZGlh KSAhPSBJRk1fVE9LRU4pDQogICAgICAgIHJldHVybihFSU5WQUwpOw0KICAg IA0KICAgIHN3aXRjaChJRk1fU1VCVFlQRShpZm0tPmlmbV9tZWRpYSkpIHsN CiAgICAgICAgY2FzZSBJRk1fQVVUTzoNCiAgICAgICAgICAgIFRSbGxkU2V0 U3BlZWQoc2MtPlRSbGxkQWRhcHRlciwgVFJMTERfU1BFRURfQVVUTyk7DQog ICAgICAgICAgICBicmVhazsNCiAgICAgICAgY2FzZSBJRk1fVE9LX1VUUDQ6 DQogICAgICAgICAgICBUUmxsZFNldFNwZWVkKHNjLT5UUmxsZEFkYXB0ZXIs IFRSTExEX1NQRUVEXzRNQlBTKTsNCiAgICAgICAgICAgIGJyZWFrOw0KICAg ICAgICBjYXNlIElGTV9UT0tfVVRQMTY6DQogICAgICAgICAgICBUUmxsZFNl dFNwZWVkKHNjLT5UUmxsZEFkYXB0ZXIsIFRSTExEX1NQRUVEXzE2TUJQUyk7 DQogICAgICAgICAgICBicmVhazsNCiAgICAgICAgZGVmYXVsdDoNCiAgICAg ICAgICAgIHJldHVybihFSU5WQUwpOw0KICAgIH0NCg0KICAgIGlmIChJRk1f VFlQRV9PUFRJT05TKGlmbS0+aWZtX21lZGlhKSAmIElGTV9UT0tfRVRSKQ0K ICAgICAgICBwcmludGYoIm9sdHIlZDogRVRSIG5vdCBpbXBsZW1lbnRlZFxu Iiwgc2MtPnVuaXQpOw0KICAgIGlmIChJRk1fVFlQRV9PUFRJT05TKGlmbS0+ aWZtX21lZGlhKSAmIElGTV9UT0tfU1JDUlQpDQogICAgICAgIHByaW50Zigi b2x0ciVkOiBzb3VyY2Utcm91dGluZyBub3QgaW1wbGVtZW50ZWRcbiIsIHNj LT51bml0KTsNCiAgICBpZiAoSUZNX1RZUEVfT1BUSU9OUyhpZm0tPmlmbV9t ZWRpYSkgJiBJRk1fVE9LX0FMTFIpDQogICAgICAgIHByaW50Zigib2x0ciVk OiBhbGwgc291cmNlIHJvdXRlcyBub3QgaW1wbGVtZW50ZWRcbiIsIHNjLT51 bml0KTsNCiAgICBpZiAoSUZNX1RZUEVfT1BUSU9OUyhpZm0tPmlmbV9tZWRp YSkgJiBJRk1fVE9LX0RUUikgew0KICAgICAgICBzYy0+QWRhcHRlck1vZGUg fD0gVFJMTERfTU9ERV9GT1JDRV9UWEk7DQogICAgICAgIHNjLT5BZGFwdGVy TW9kZSAmPSB+VFJMTERfTU9ERV9GT1JDRV9US1A7DQogICAgfQ0KICAgIGlm IChJRk1fVFlQRV9PUFRJT05TKGlmbS0+aWZtX21lZGlhKSAmIElGTV9UT0tf Q0xBU1NJQykgew0KICAgICAgICBzYy0+QWRhcHRlck1vZGUgfD0gVFJMTERf TU9ERV9GT1JDRV9US1A7DQogICAgICAgIHNjLT5BZGFwdGVyTW9kZSAmPSB+ VFJMTERfTU9ERV9GT1JDRV9UWEk7DQogICAgfQ0KICAgIGlmIChJRk1fVFlQ RV9PUFRJT05TKGlmbS0+aWZtX21lZGlhKSAmIElGTV9UT0tfQVVUTykNCiAg ICAgICAgc2MtPkFkYXB0ZXJNb2RlICY9IH4oVFJMTERfTU9ERV9GT1JDRV9U WEkgfCBUUkxMRF9NT0RFX0ZPUkNFX1RLUCk7DQoNCiAgICBpZiAoSUZNX1RZ UEVfT1BUSU9OUyhpZm0tPmlmbV9tZWRpYSkgJiB+QUxMX09QVElPTlMpDQog ICAgICAgIHJldHVybihFSU5WQUwpOw0KDQogICAgcmV0dXJuKDApOw0KfQ0K DQpzdGF0aWMgdm9pZA0Kb2x0cl9pZm1lZGlhX3N0cyhpZnAsIGlmbXIpDQog ICAgc3RydWN0IGlmbmV0ICppZnA7DQogICAgc3RydWN0IGlmbWVkaWFyZXEg KmlmbXI7DQp7DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gaWZwLT5p Zl9zb2Z0YzsNCiAgICBzdHJ1Y3QgaWZtZWRpYSAqaWZtID0gJnNjLT5pZm1l ZGlhOw0KDQogICAgaWZtci0+aWZtX2FjdGl2ZSA9IElGTV9UWVBFKGlmbS0+ aWZtX21lZGlhKXxJRk1fU1VCVFlQRShpZm0tPmlmbV9tZWRpYSl8SUZNX1RZ UEVfT1BUSU9OUyhpZm0tPmlmbV9tZWRpYSk7DQoNCiAgICByZXR1cm47DQp9 DQoNCnZvaWQNCm9sdHJfdGltZW91dCh0b2tlbikNCiAgICB2b2lkICp0b2tl bjsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0 Y1soaW50KXRva2VuXTsNCiAgICBpbnQgdW5pdCA9IChpbnQpdG9rZW4sIHM7 DQoNCiAgICBzID0gc3BsaW1wKCk7DQoNCiAgICBwcmludGYoIm9sdHIlZDog YWRhcHRlciB0aW1lZCBvdXQgKCV4KVxuIiwgdW5pdCwgc2MtPmh3X3N0YXRl KTsNCg0KICAgIHNwbHgocyk7DQp9DQoNCg0Kdm9pZA0KYWRhcHRlcl9wb2xs KHRva2VuKQ0KICAgIHZvaWQgKnRva2VuOw0Kew0KICAgIGludCB1bml0ID0g KGludCl0b2tlbiwgcG9sbF90aW1lb3V0ID0gMCwgczsNCiAgICBzdHJ1Y3Qg b2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1t1bml0XTsNCiNpZiAwDQog ICAgc3RhdGljIGludCByeF9idWZmZXJzID0gMCwgdHhfYnVmZmVycyA9IDAs IHJjOyANCiNlbmRpZg0KICAgIA0KICAgIHMgPSBzcGxpbXAoKTsNCg0KICAg IC8qIENoZWNrIHRvIG1ha2Ugc3VyZSB3ZSBhcmUgbm90IHBvbGxpbmcgYSBk ZWFkIGNhcmQgKi8NCiAgICBpZiAoKHNjLT5od19zdGF0ZSA9PSBIV19CQUQp IHx8IChzYy0+aHdfc3RhdGUgPT0gSFdfVU5LTk9XTikpIHsNCiAgICAgICAg c2MtPnBvbGxfYWRhcHRlciA9IC0xOw0KICAgICAgICBzcGx4KHMpOw0KICAg ICAgICByZXR1cm47DQogICAgfQ0KDQogICAgLypwcmludGYoIm9sdHIlZDog YWRhcHRlciBwb2xsLlxuIiwgdW5pdCk7Ki8NCiAgICANCiAgICAvKiBJZiB0 aGUgYWRhcHRlciBpcyB0byBiZSBwb2xsZWQgYWdhaW4sIHRoZW4gc2V0IHVw DQogICAgICogbmV4dCB0aW1lb3V0IHBvbGwgDQogICAgICovDQogICAgaWYg KHNjLT5wb2xsX2FkYXB0ZXIpIHsNCiAgICAgICAgcG9sbF90aW1lb3V0ID0g VFJsbGRQb2xsKHNjLT5UUmxsZEFkYXB0ZXIpOw0KICAgICAgICBzYy0+cG9s bF9jaCA9IHRpbWVvdXQoYWRhcHRlcl9wb2xsLCAodm9pZCAqKXVuaXQsIChw b2xsX3RpbWVvdXQgKiBoeikvMTAwMCk7DQogICAgfQ0KI2lmIDANCiAgICBy YyA9IFRSbGxkUmVjZWl2ZUZyZWUoc2MtPlRSbGxkQWRhcHRlcik7DQogICAg aWYgKHJ4X2J1ZmZlcnMgIT0gcmMpIHsNCiAgICAgICAgcHJpbnRmKCJvbHRy JWQ6ICVkIHJlY2VpdmUgYnVmZmVycyBhdmFpbGFibGVcbiIsIHNjLT51bml0 LCByYyk7DQogICAgICAgIHJ4X2J1ZmZlcnMgPSByYzsNCiAgICB9IA0KICAg IHJjID0gVFJsbGRUcmFuc21pdEZyZWUoc2MtPlRSbGxkQWRhcHRlcik7DQog ICAgaWYgKHR4X2J1ZmZlcnMgIT0gcmMpIHsNCiAgICAgICAgcHJpbnRmKCJv bHRyJWQ6ICVkIHRyYW5zbWl0IGJ1ZmZlcnMgYXZhaWxhYmxlXG4iLCBzYy0+ dW5pdCwgcmMpOw0KICAgICAgICB0eF9idWZmZXJzID0gcmM7DQogICAgfSAN CiNlbmRpZg0KDQogICAgc3BseChzKTsgICAgICAgICAgICANCn0NCg0Kc3Rh dGljIHZvaWQgDQpvbHRyX2luaXQoc2MpDQogICAgc3RydWN0IG9sdHJfc29m dGMgKnNjOw0Kew0KICAgIHN0cnVjdCBpZm5ldCAqaWZwID0gJnNjLT5hcnBj b20uYWNfaWY7DQogICAgaW50IGksIHJjOw0KDQogICAgLypwcmludGYoIm9s dHIlZDogb2x0cl9pbml0XG4iLCBzYy0+dW5pdCk7Ki8NCiAgICANCiAgICAv KiANCiAgICAgKiBBZGFwdGVyIHNob3VsZCBiZSBmcmVzaGx5IGRvd25sb2Fk ZWQgb3IgcHJldmlvdXNseSBjbG9zZWQgYmVmb3JlDQogICAgICogYnJpbmdp bmcgaXQgYmFjayBvbiBsaW5lLg0KICAgICAqLw0KICAgIGlmICgoc2MtPmh3 X3N0YXRlICE9IEhXX0NMT1NFRCkgJiYgKHNjLT5od19zdGF0ZSAhPSBIV19M T0FESU5HKSAmJiAoc2MtPmh3X3N0YXRlICE9IEhXX0NMT1NJTkcyKSkgew0K ICAgICAgICBwcmludGYoIm9sdHIlZDogYWRhcHRlciBub3QgcmVhZHkgdG8g YmUgb3BlbmVkICglZCkuXG4iLCBzYy0+dW5pdCwgc2MtPmh3X3N0YXRlKTsN CiAgICAgICAgcmV0dXJuOw0KICAgIH0NCg0KICAgIC8qIEFsbG9jYXRlIGFu ZCBzZXQgdXAgdGhlIERNQSBjaGFubmVsICovDQogICAgaWYgKHNjLT5jb25m aWctPmRtYWxldmVsICE9IFRSTExEX0RNQV9QSU8pIHsNCiAgICAgICAgcmMg PSBpc2FfZG1hX2FjcXVpcmUoc2MtPmNvbmZpZy0+ZG1hbGV2ZWwpOw0KICAg ICAgICBpc2FfZG1hY2FzY2FkZShzYy0+Y29uZmlnLT5kbWFsZXZlbCk7DQog ICAgfQ0KDQogICAgLyogT3BlbiB0aGUgYWRhcHRlciAqLw0KICAgIHNjLT5o d19zdGF0ZSA9IEhXX09QRU5JTkc7DQogICAgcmMgPSBUUmxsZE9wZW4oc2Mt PlRSbGxkQWRhcHRlciwgc2MtPmFycGNvbS5hY19lbmFkZHIsIHNjLT5Hcm91 cEFkZHJlc3MsIA0KICAgICAgICAgICAgICAgICAgIHNjLT5GdW5jdGlvbmFs QWRkcmVzcywgaWZwLT5pZl9tdHUgKyA1Miwgc2MtPkFkYXB0ZXJNb2RlKTsN CiAgICBpZiAocmMgIT0gVFJMTERfT1BFTl9PSykgew0KICAgICAgICBwcmlu dGYoIm9sdHIlZDogQWRhcHRlciBmYWlsZWQgdG8gb3BlbiAocmMgPSAleClc biIsIHNjLT51bml0LCByYyk7DQogICAgICAgIHNjLT5od19zdGF0ZSA9IEhX X0ZBSUxFRDsNCiAgICB9IGVsc2Ugew0KICAgICAgICAvKnByaW50Zigib2x0 ciVkOiBhZGFwdGVyIG9wZW5pbmcuLi5cbiIsIHNjLT51bml0KTsqLw0KICAg ICAgICAvKmlmcC0+aWZfZmxhZ3MgfD0gKElGRl9VUCB8IElGRl9SVU5OSU5H KTsqLw0KICAgICAgICBpZnAtPmlmX2ZsYWdzICY9IH5JRkZfT0FDVElWRTsN CiAgICB9DQogICAgc2MtPm9sdHJfY2ggPSB0aW1lb3V0KG9sdHJfdGltZW91 dCwgKHZvaWQgKilzYy0+dW5pdCwgMzAqaHopOw0KICAgIHRzbGVlcCgodm9p ZCAqKXNjLT51bml0LCAxLCAib2x0cm9wIiwgMzAqaHopOw0KDQogICAgLyog R2l2ZSB0aGUgdHJhbnNtaXQgYnVmZmVycyB0byB0aGUgYWRhcHRlciAqLw0K ICAgIGZvciAoaSA9IDA7IGkgPCBSWF9MSVNUX1NJWkU7IGkrKykgeyANCiAg ICAgICAgcmMgPSBUUmxsZFJlY2VpdmVGcmFnbWVudChzYy0+VFJsbGRBZGFw dGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2b2lk ICopc2MtPnJ4X2J1ZmZlcltzYy0+cnhfbmV4dCAmIFJYX0xJU1RfTUFTS10u YnVmLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGt2dG9w KHNjLT5yeF9idWZmZXJbc2MtPnJ4X25leHQgJiBSWF9MSVNUX01BU0tdLmJ1 ZiksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUlhfQlVG RkVSX0xFTiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo dm9pZCAqKXNjLT5yeF9idWZmZXJbc2MtPnJ4X25leHQgJiBSWF9MSVNUX01B U0tdLmluZGV4KTsNCiAgICAgICAgaWYgKHJjICE9IFRSTExEX1JFQ0VJVkVf T0spIHsNCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVyIHJl ZnVzZWQgZnJhZ21lbnQgJWQgKHJjID0gJWQpLlxuIiwgc2MtPnVuaXQsIGks IHJjKTsNCiAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICB9ICBlbHNlIHsN CiAgICAgICAgICAgIHNjLT5yeF9hdmFpbC0tOw0KICAgICAgICB9DQogICAg ICAgIHNjLT5yeF9uZXh0Kys7DQogICAgfQ0KICAgIA0KICAgIHJldHVybjsN Cn0NCiAgICANCnN0YXRpYyB2b2lkDQpvbHRyX2ludHIodW5pdCkNCiAgICBp bnQgdW5pdDsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0 cl9zb2Z0Y1t1bml0XTsNCiAgICBpbnQgcmM7DQoNCiAgICAvKnByaW50Zigi b2x0ciVkOiBvbHRyX2ludHJcbiIsIHVuaXQpOyovIC8qIFRvbyBub2lzeSAq Lw0KICAgIHJjPSBUUmxsZEludGVycnVwdFNlcnZpY2Uoc2MtPlRSbGxkQWRh cHRlcik7DQogICAgaWYgKHJjID09IFRSTExEX05PX0lOVEVSUlVQVCkgDQog ICAgICAgIHByaW50Zigib2x0ciVkOiBpbnRlcnJ1cHQgbm90IHNlcnZpY2Vk LlxuIiwgdW5pdCk7DQp9DQoNCiNpZiBOUENJID4gMA0Kc3RhdGljIHZvaWQN Cm9sdHJfcGNpX2ludHIocHNjKQ0KICAgIHZvaWQgKnBzYzsNCnsNCiAgICBz dHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAoc3RydWN0IG9sdHJfc29mdGMgKilw c2M7DQogICAgaW50IHJjID0gMDsNCg0KICAgIC8qcHJpbnRmKCJvbHRyJWQ6 IG9sdHJfcGNpX2ludHJcbiIsIHNjLT51bml0KTsqLyAvKiBUb28gbm9pc3kg Ki8NCiAgICByYyA9IFRSbGxkSW50ZXJydXB0U2VydmljZShzYy0+VFJsbGRB ZGFwdGVyKTsNCiAgICBpZiAocmMgPT0gVFJMTERfTk9fSU5URVJSVVBUKQ0K ICAgICAgICBwcmludGYoIm9sdHIlZDogcGNpIGludGVycnVwdCBub3Qgc2Vy dmljZWQuXG4iLCBzYy0+dW5pdCk7DQp9DQojZW5kaWYgLyogTlBDSSAqLw0K DQpzdGF0aWMgdm9pZCANCm9sdHJfc3RhcnQoaWZwKQ0KICAgIHN0cnVjdCBp Zm5ldCAqaWZwOw0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9ICZv bHRyX3NvZnRjW2lmcC0+aWZfdW5pdF07DQogICAgc3RydWN0IG1idWYgKm0w LCAqbTsNCiAgICBzdHJ1Y3QgaXNvODgwMjVfaGVhZGVyICp0aDsNCiAgICBU UmxsZFRyYW5zbWl0X3QgZnJhbWU7DQogICAgaW50ICBsZW4sIGksIHJjOw0K DQogICAgLypwcmludGYoIm9sdHIlZDogb2x0cl9zdGFydFxuIiwgc2MtPnVu aXQpOyovDQoNCm91dGxvb3A6DQoNCiAgICAvKiBDaGVjayB0byBzZWUgaWYg d2UgaGF2ZSBlbm91Z2ggcm9vbSB0byB0cmFuc21pdCAqLw0KICAgIGlmIChz Yy0+dHhfYXZhaWwgPD0gMCkgew0KICAgICAgICAvKiBObyBmcmVlIGJ1ZmZl cnMsIGhvbGQgb2ZmIHRoZSB1cHBlciBsYXllcnMgKi8NCiAgICAgICAgLypw cmludGYoIm9sdHIlZDogdHJhbnNtaXQgcXVldWUgZnVsbC5cbiIsIHNjLT51 bml0KTsqLw0KICAgICAgICBpZnAtPmlmX2ZsYWdzIHw9IElGRl9PQUNUSVZF Ow0KICAgICAgICByZXR1cm47DQogICAgfQ0KICAgIElGX0RFUVVFVUUoJmlm cC0+aWZfc25kLCBtKTsNCiAgICBpZiAobSA9PSAwKSB7DQogICAgICAgIC8q cHJpbnRmKCJvbHRyJWQ6IG9sdHJfc3RhcnQgTlVMTCBwYWNrZXQgZGVxdWV1 ZWQuXG4iLCBzYy0+dW5pdCk7Ki8NCiAgICAgICAgaWZwLT5pZl9mbGFncyAm PSB+SUZGX09BQ1RJVkU7DQogICAgICAgIHJldHVybjsNCiAgICB9DQoNCiAg ICB0aCA9IG10b2QobSwgc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqKTsNCiAg ICB0aC0+YWMgPSAweDEwOw0KICAgIHRoLT5mYyA9IDB4NDA7DQogICAgDQog ICAgLyogS2VlcCBhIHBvaW50ZXIgdG8gdGhlIGhlYWQgb2YgdGhlIHBhY2tl dCAqLw0KICAgIG0wID0gbTsNCg0KICAgIGkgPSAoc2MtPnR4X25leHQgJiBU WF9MSVNUX01BU0spOyAvKiBKdXN0IHRvIHNob3J0ZW4gdGhpbmcgdXAgKi8N Cg0KICAgIGZvciAobGVuID0gMDsgbSAhPSAwOyBtID0gbS0+bV9uZXh0KSB7 DQogICAgICAgIGZyYW1lLlRyYW5zbWl0RnJhZ21lbnRbMF0uVmlydHVhbEFk ZHJlc3MgPSBzYy0+dHhfYnVmZmVyW2ldLmJ1ZjsNCiAgICAgICAgZnJhbWUu VHJhbnNtaXRGcmFnbWVudFswXS5QaHlzaWNhbEFkZHJlc3MgPSBrdnRvcChz Yy0+dHhfYnVmZmVyW2ldLmJ1Zik7DQogICAgICAgIGJjb3B5KG10b2QobSwg Y2FkZHJfdCksIHNjLT50eF9idWZmZXJbaV0uYnVmICsgbGVuLCBtLT5tX2xl bik7DQogICAgICAgIGxlbiArPSBtLT5tX2xlbjsNCiAgICB9DQogICAgZnJh bWUuRnJhZ21lbnRDb3VudCA9IDE7DQogICAgZnJhbWUuVHJhbnNtaXRGcmFn bWVudFswXS5jb3VudCA9IGxlbjsNCg0KICAgIHJjID0gVFJsbGRUcmFuc21p dEZyYW1lKHNjLT5UUmxsZEFkYXB0ZXIsICZmcmFtZSwgKHZvaWQgKilzYy0+ dHhfYnVmZmVyW2ldLmluZGV4KTsNCiAgICBpZiAocmMgIT0gVFJMTERfVFJB TlNNSVRfT0spIHsNCiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IFRSbGxkVHJh bnNtaXRGcmFtZSByZXR1cm5lZCAoJXgpXG4iLCBzYy0+dW5pdCwgcmMpOw0K ICAgICAgICBpZnAtPmlmX29lcnJvcnMrKzsNCiAgICAgICAgZ290byBiYWQ7 DQogICAgfQ0KDQogICAgc2MtPnR4X25leHQrKzsNCiAgICBzYy0+dHhfYXZh aWwtLTsNCg0KI2lmIE5CUEZJTFRFUiA+IDANCiAgICBpZiAoaWZwLT5pZl9i cGYpDQogICAgICAgIGJwZl9tdGFwKGlmcCwgbTApOw0KI2VuZGlmDQoNCmJh ZDoNCiAgICBtX2ZyZWVtKG0wKTsNCiAgICBnb3RvIG91dGxvb3A7DQogICAg cmV0dXJuOw0KfQ0KDQpzdGF0aWMgdm9pZA0Kb2x0cl9zdG9wKHNjKQ0KICAg IHN0cnVjdCBvbHRyX3NvZnRjICpzYzsNCnsNCiAgICBzdHJ1Y3QgaWZuZXQg KmlmcCA9ICZzYy0+YXJwY29tLmFjX2lmOw0KICAgIHByaW50Zigib2x0ciVk OiBvdGxyX3N0b3BcbiIsIHNjLT51bml0KTsNCiAgICBpZnAtPmlmX2ZsYWdz ICY9IH4oSUZGX1VQIHwgSUZGX1JVTk5JTkcgfCBJRkZfT0FDVElWRSk7DQog ICAgc2MtPmh3X3N0YXRlID0gSFdfQ0xPU0lORzsNCiAgICBUUmxsZENsb3Nl KHNjLT5UUmxsZEFkYXB0ZXIsIDApOw0KICAgIHNjLT5vbHRyX2NoID0gdGlt ZW91dChvbHRyX3RpbWVvdXQsICh2b2lkICopc2MtPnVuaXQsIDMwKmh6KTsN CiAgICB0c2xlZXAoKHZvaWQgKilzYy0+dW5pdCwgMSwgIm9sdHJjbCIsIDMw Kmh6KTsNCn0NCg0Kc3RhdGljIGludA0Kb2x0cl9pb2N0bChpZnAsIGNtZCwg ZGF0YSkNCiAgICBzdHJ1Y3QgaWZuZXQgKmlmcDsNCiAgICB1X2xvbmcgY21k Ow0KICAgIGNhZGRyX3QgZGF0YTsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0 YyAqc2MgPSAmb2x0cl9zb2Z0Y1tpZnAtPmlmX3VuaXRdOw0KICAgIHN0cnVj dCBpZnJlcSAqaWZyID0gKHN0cnVjdCBpZnJlcSAqKWRhdGE7DQogICAgaW50 IGVycm9yID0gMCwgczsNCg0KICAgIC8qcHJpbnRmKCJvbHRyJWQ6IG9sdHJf aW9jdGxcbiIsIGlmcC0+aWZfdW5pdCk7Ki8NCg0KICAgIHMgPSBzcGxpbXAo KTsNCg0KICAgIHN3aXRjaCAoY21kKSB7DQogICANCiAgICAgICAgY2FzZSBT SU9DU0lGQUREUjoNCiAgICAgICAgY2FzZSBTSU9DR0lGQUREUjoNCiAgICAg ICAgY2FzZSBTSU9DU0lGTVRVOg0KICAgICAgICAgICAgZXJyb3IgPSBpc284 ODAyNV9pb2N0bChpZnAsIGNtZCwgZGF0YSk7DQogICAgICAgICAgICBicmVh azsNCg0KICAgICAgICBjYXNlIFNJT0NTSUZGTEFHUzoNCiAgICAgICAgICAg IC8qDQogICAgICAgICAgICAgKiBJZiB0aGUgaW50ZXJmYWNlIGlzIG1hcmtl ZCB1cCBhbmQgc3RvcHBlZCwgdGhlbiBzdGFydCBpdC4NCiAgICAgICAgICAg ICAqIElmIGl0IGlzIG1hcmtlZCBkb3duIGFuZCBydW5uaW5nLCB0aGVuIHN0 b3AgaXQuDQogICAgICAgICAgICAgKi8NCiAgICAgICAgICAgIGlmIChpZnAt PmlmX2ZsYWdzICYgSUZGX1VQKSB7DQogICAgICAgICAgICAgICAgICAgIGlm ICgoaWZwLT5pZl9mbGFncyAmIElGRl9SVU5OSU5HKSA9PSAwKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG9sdHJfaW5pdChzYyk7DQogICAgICAg ICAgICB9IGVsc2Ugew0KICAgICAgICAgICAgICAgICAgICBpZiAoaWZwLT5p Zl9mbGFncyAmIElGRl9SVU5OSU5HKSB7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgb2x0cl9zdG9wKHNjKTsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpZnAtPmlmX2ZsYWdzICY9IH5JRkZfUlVOTklORzsNCiAgICAg ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICBpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfUFJPTUlTQykgIT0gc2MtPlBy b21pc2NNb2RlKSB7DQogICAgICAgICAgICAgICAgaWYgKGlmcC0+aWZfZmxh Z3MgJiBJRkZfUFJPTUlTQykNCiAgICAgICAgICAgICAgICAgICAgVFJsbGRT ZXRQcm9taXNjdW91c01vZGUoc2MtPlRSbGxkQWRhcHRlciwgT0xUUl9QUk9N SVNDX01PREUpOw0KICAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAg ICAgICAgICAgVFJsbGRTZXRQcm9taXNjdW91c01vZGUoc2MtPlRSbGxkQWRh cHRlciwgMCk7DQogICAgICAgICAgICAgICAgc2MtPlByb21pc2NNb2RlID0g KGlmcC0+aWZfZmxhZ3MgJiBJRkZfUFJPTUlTQyk7DQogICAgICAgICAgICB9 DQogICAgICAgICAgICANCiAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICBj YXNlIFNJT0NHSUZNRURJQToNCiAgICAgICAgY2FzZSBTSU9DU0lGTUVESUE6 DQogICAgICAgICAgICBlcnJvciA9IGlmbWVkaWFfaW9jdGwoaWZwLCBpZnIs ICZzYy0+aWZtZWRpYSwgY21kKTsNCiAgICAgICAgICAgIGJyZWFrOw0KICAg ICAgICBkZWZhdWx0Og0KICAgICAgICAgICAgZXJyb3IgPSBFSU5WQUw7DQog ICAgfQ0KICAgIHNwbHgocyk7DQogICAgcmV0dXJuKGVycm9yKTsNCn0NCg0K LyoNCiAqIFBNVyBDYWxsYmFjayBmdW5jdGlvbnMgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICovDQoN CnN0YXRpYyB2b2lkDQpEcml2ZXJTdXNwZW5kKE1pY3JvU2Vjb25kcykNCiAg ICB1bnNpZ25lZCBzaG9ydCBNaWNyb1NlY29uZHM7DQp7DQogICAgREVMQVko TWljcm9TZWNvbmRzKTsNCn0NCg0KDQpzdGF0aWMgdm9pZA0KRHJpdmVyU3Rh dHVzKERyaXZlckhhbmRsZSwgU3RhdHVzKQ0KICAgIHZvaWQgKkRyaXZlckhh bmRsZTsNCiAgICBUUmxsZFN0YXR1c190ICpTdGF0dXM7DQp7DQogICAgc3Ry dWN0IG9sdHJfc29mdGMgKnNjID0gJm9sdHJfc29mdGNbKGludClEcml2ZXJI YW5kbGVdOw0KICAgIHN0cnVjdCBpZm5ldCAqaWZwID0gJnNjLT5hcnBjb20u YWNfaWY7DQoNCiAgICBzd2l0Y2ggKFN0YXR1cy0+VHlwZSkgew0KICAgICAg ICBjYXNlIFRSTExEX1NUU19PTl9XSVJFOg0KICAgICAgICAgICAgaWYgKHNj LT5od19zdGF0ZSA9PSBIV19PUEVOSU5HKSB7DQogICAgICAgICAgICAgICAg c2MtPmh3X3N0YXRlID0gSFdfT1BFTjsNCiAgICAgICAgICAgICAgICBpZnAt PmlmX2ZsYWdzIHw9IChJRkZfVVAgfCBJRkZfUlVOTklORyk7DQogICAgICAg ICAgICAgICAgLypwcmludGYoIm9sdHIlZDogQWRhcHRlciBpbnNlcnRlZC5c biIsIHNjLT51bml0KTsqLw0KICAgICAgICAgICAgICAgIHVudGltZW91dChv bHRyX3RpbWVvdXQsICh2b2lkICopc2MtPnVuaXQsIHNjLT5vbHRyX2NoKTsN CiAgICAgICAgICAgICAgICB3YWtldXBfb25lKCh2b2lkICopc2MtPnVuaXQp Ow0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgYnJlYWs7DQogICAgICAg IGNhc2UgVFJMTERfU1RTX1NFTEZURVNUX1NUQVRVUzoNCiAgICAgICAgICAg IGlmIChTdGF0dXMtPlNwZWNpZmljYXRpb24uU2VsZnRlc3RTdGF0dXMgPT0g VFJMTERfU1RfT0spIHsNCiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIl ZDogYWRhcHRlciBzdGF0dXMgZ29vZC4gKGNsb3NlIGNvbXBsZXRlZC9zZWxm LXRlc3QpXG4iLCBzYy0+dW5pdCk7DQogICAgICAgICAgICAgICAgaWYgKChz Yy0+aHdfc3RhdGUgPT0gSFdfTE9BRElORykgfHwgKHNjLT5od19zdGF0ZSA9 PSBIV19DTE9TSU5HKSB8fCAoc2MtPmh3X3N0YXRlID09IEhXX0NMT1NJTkcy KSkgew0KICAgICAgICAgICAgICAgICAgICBzYy0+aHdfc3RhdGUgPSBIV19D TE9TRUQ7DQogICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICAg ICAgICAgIH0NCiAgICAgICAgICAgIH0gZWxzZSB7DQogICAgICAgICAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IFNlbGYgdGVzdCBmYWlsZWQ6ICIsIHNjLT51 bml0KTsNCiAgICAgICAgICAgICAgICBzd2l0Y2ggKFN0YXR1cy0+U3BlY2lm aWNhdGlvbi5TZWxmdGVzdFN0YXR1cykgew0KICAgICAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX1NUX0VSUk9SICsgMDogcHJpbnRmKCJJbml0aWFsIFRl c3QgRXJyb3JcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAgY2Fz ZSBUUkxMRF9TVF9FUlJPUiArIDE6IHByaW50ZigiQWRhcHRlciBTb2Z0d2Fy ZSBDaGVja3N1bSBFcnJvclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAg ICAgICBjYXNlIFRSTExEX1NUX0VSUk9SICsgMjogcHJpbnRmKCJBZGFwdGVy IFJBTSBFcnJvclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICBj YXNlIFRSTExEX1NUX0VSUk9SICsgNDogcHJpbnRmKCJJbnN0cnVjdGlvbiBU ZXN0IEVycm9yXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgICAgIGNh c2UgVFJMTERfU1RfRVJST1IgKyA1OiBwcmludGYoIlByb3RvY29sIEhhbmRs ZXIvUkkgSHcgRXJyb3JcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAg ICAgY2FzZSBUUkxMRF9TVF9FUlJPUiArIDY6IHByaW50ZigiU3lzdGVtIElu dGVyZmFjZSBSZWdpc3RlciBFcnJvclxuIik7IGJyZWFrOw0KICAgICAgICAg ICAgICAgICAgICBjYXNlIFRSTExEX1NUX1RJTUVPVVQ6ICAgcHJpbnRmKCJT ZWxmdGVzdCBkaWQgbm90IGNvbXBsZXRlXG4iKTsgYnJlYWs7DQogICAgICAg ICAgICAgICAgICAgIGRlZmF1bHQ6IHByaW50ZigiVW5rbm93biBlcnJvciAo JXgpXG4iLCBTdGF0dXMtPlNwZWNpZmljYXRpb24uU2VsZnRlc3RTdGF0dXMp Ow0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAg ICAgIGJyZWFrOw0KICAgICAgICBjYXNlIFRSTExEX1NUU19JTklUX1NUQVRV UzoNCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVyIGluaXRp YWxpemF0aW9uIGZhaWxlZDogIiwgc2MtPnVuaXQpOw0KICAgICAgICAgICAg c3dpdGNoKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5Jbml0U3RhdHVzKSB7DQog ICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX0VSUk9SICsgMHgwMTog cHJpbnRmKCJJbnZhbGlkIGluaXQgYmxvY2sgKExMRCBlcnJvcilcbiIpOyBi cmVhazsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExEX0lOSVRfRVJST1Ig KyAweDAyOiBwcmludGYoIkludmFsaWQgb3B0aW9ucyAoTExEIGVycm9yKVxu Iik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfSU5JVF9F UlJPUiArIDB4MDM6IHByaW50ZigiSW52YWxpZCByY3YgYnVyc3QgKExMRCBl cnJvcilcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExE X0lOSVRfRVJST1IgKyAweDA0OiBwcmludGYoIkludmFsaWQgeG10IGJ1cnN0 IChMTEQgZXJyb3IpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2Fz ZSBUUkxMRF9JTklUX0VSUk9SICsgMHgwNTogcHJpbnRmKCJJbnZhbGlkIERN QSB0aHJlc2hvbGQgKExMRCBlcnJvcilcbiIpOyBicmVhazsNCiAgICAgICAg ICAgICAgICBjYXNlIFRSTExEX0lOSVRfRVJST1IgKyAweDA2OiBwcmludGYo IkludmFsaWQgc2NiIGFkZHJcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX0lOSVRfRVJST1IgKyAweDA3OiBwcmludGYoIkludmFs aWQgc3NiIGFkZHJcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNl IFRSTExEX0lOSVRfRVJST1IgKyAweDA4OiBwcmludGYoIkRJTyBwYXJpdHkg ZXJyb3IgKEhXIGVycm9yKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAg IGNhc2UgVFJMTERfSU5JVF9FUlJPUiArIDB4MDk6IHByaW50ZigiRE1BIHRp bWVvdXQgKE1heSBiZSBpbnRlcnJ1cHQgZmFpbGluZyBpZiBQSU8gbW9kZSBv ciBQQ0kyKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNhc2UgVFJM TERfSU5JVF9FUlJPUiArIDB4MEE6IHByaW50ZigiRE1BIHBhcml0eSBlcnJv ciAoSFcgZXJyb3IpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2Fz ZSBUUkxMRF9JTklUX0VSUk9SICsgMHgwQjogcHJpbnRmKCJETUEgYnVzIGVy cm9yIChIVyBlcnJvcilcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBj YXNlIFRSTExEX0lOSVRfRVJST1IgKyAweDBDOiBwcmludGYoIkRNQSBkYXRh IGVycm9yXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxM RF9JTklUX0VSUk9SICsgMHgwRDogcHJpbnRmKCJBZGFwdGVyIENoZWNrXG4i KTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX1RJ TUVPVVQ6ICAgICAgcHJpbnRmKCJBZGFwdGVyIGluaXRpYWxpemF0aW9uIGRp ZCBub3QgY29tcGxldGVcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBj YXNlIFRSTExEX0lOSVRfRE1BX0VSUk9SOiAgICBwcmludGYoIkFkYXB0ZXIg Y2Fubm90IGFjY2VzcyBzeXN0ZW0gbWVtb3J5XG4iKTsgYnJlYWs7DQogICAg ICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX0lOVFJfRVJST1I6ICAgcHJp bnRmKCJBZGFwdGVyIGNhbm5vdCBpbnRlcnJ1cHRcbiIpOyBicmVhazsNCiAg ICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fVElNRU9VVDogICAgICBw cmludGYoIkFkYXB0ZXIgZGlkIG5vdCBjb21wbGV0ZSBvcGVuIHdpdGhpbiAz MCBzZWNvbmRzXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2FzZSBU UkxMRF9PUEVOX0VSUk9SICsgMHgwMTogcHJpbnRmKCJJbnZhbGlkIG9wZW4g b3B0aW9ucyAoTExEIGVycm9yKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAg ICAgIGNhc2UgVFJMTERfT1BFTl9FUlJPUiArIDB4MDQ6IHByaW50ZigiVHhC dWZmZXIgY291bnQgZXJyb3IgKExMRCBlcnJvcilcbiIpOyBicmVhazsNCiAg ICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fRVJST1IgKyAweDEwOiBw cmludGYoIkJ1ZmZlciBzaXplIGVycm9yIChMTEQgZXJyb3IpXG4iKTsgYnJl YWs7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX0VSUk9SICsg MHgyMDogcHJpbnRmKCJMaXN0IHNpemUgZXJyb3IgKExMRCBlcnJvcilcbiIp OyBicmVhazsNCiAgICAgICAgICAgICAgICBkZWZhdWx0OiANCiAgICAgICAg ICAgICAgICAgICAgaWYgKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5Jbml0U3Rh dHVzICYgMHg3MDApIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHN3aXRj aCAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRTdGF0dXMgJiAweDcwRikg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BF Tl9SRVBFQVQgKyAweDAxOiBwcmludGYoIkxvYmUgbWVkaWEgdGVzdCAtICIp OyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXNlIFRS TExEX09QRU5fUkVQRUFUICsgMHgwMjogcHJpbnRmKCJQaHlzaWNhbCBpbnNl cnRpb24gLSAiKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCArIDB4MDM6IHByaW50ZigiQWRk cmVzcyB2ZXJpZmljYXRpb24gLSAiKTsgYnJlYWs7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCArIDB4MDQ6 IHByaW50ZigiUGFydGljaXBhdGlvbiBpbiByaW5nIHBvbGwgLSAiKTsgYnJl YWs7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9P UEVOX1JFUEVBVCArIDB4MDU6IHByaW50ZigiUmVxdWVzdCBpbml0aWFsaXph dGlvbiAtICIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHgwOTogcHJpbnRmKCJSZXF1 ZXN0IHJlZ2lzdHJhdGlvbiAoVFhJKSAtICIpOyBicmVhazsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsg MHgwQTogcHJpbnRmKCJMb2JlIG1lZGlhIHRlc3QgKFRYSSkgLSAiKTsgYnJl YWs7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdDogICAg ICAgICAgICAgICAgICAgICAgIHByaW50ZigiVW5rbm93biBwaGFzZSAoJXgp IC0gIiwgU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRTdGF0dXMgJiAweDAw Rik7DQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgICAgICAgICBzd2l0Y2ggKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5Jbml0 U3RhdHVzICYgMHg3RjApIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHgxMDogcHJpbnRmKCJGdW5j dGlvbiBmYWlsdXJlIChObyBjYWJsZT8pXG4iKTsgYnJlYWs7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCAr IDB4MjA6IHByaW50ZigiU2lnbmFsIGxvc3NcbiIpOyBicmVhazsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFU ICsgMHg1MDogcHJpbnRmKCJUaW1lb3V0XG4iKTsgYnJlYWs7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCAr IDB4NjA6IHByaW50ZigiUmluZyBmYWlsdXJlIChUS1ApIC8gUHJvdG9jb2wg ZXJyb3IgKFRYSSlcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHg3MDogcHJpbnRm KCJSaW5nIGJlYWNvbmluZ1xuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9SRVBFQVQgKyAweDgwOiBw cmludGYoIkR1cGxpY2F0ZSBub2RlIGFkZHJlc3MgKFRLUCkgLyBJbnNlcnQg ZGVuaWVkIChUWEkpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCArIDB4OTA6IHByaW50 ZigiUmVxdWVzdCBpbml0aWFsaXphdGlvbiAoVEtQKVxuIik7IGJyZWFrOw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9S RVBFQVQgKyAweGEwOiBwcmludGYoIlJlbW92ZSByZWNlaXZlZFxuIik7IGJy ZWFrOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2UgVFJMTERf T1BFTl9SRVBFQVQgKyAweGIwOiBwcmludGYoIkMtcG9ydCBhZGRyZXNzIGNo YW5nZWQgKFRYSSlcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBkZWZhdWx0OiAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRm KCJVbmtub3duIHR5cGUgKCV4KVxuIiwgU3RhdHVzLT5TcGVjaWZpY2F0aW9u LkluaXRTdGF0dXMgJiAweDBGMCk7DQogICAgICAgICAgICAgICAgICAgICAg ICB9DQogICAgICAgICAgICAgICAgICAgIH0gZWxzZSB7DQogICAgICAgICAg ICAgICAgICAgICAgICBwcmludGYoIlVua25vd24gZXJyb3IgKCV4KVxuIiwg U3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRTdGF0dXMpOyANCiAgICAgICAg ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgYnJl YWs7DQogICAgICAgIGNhc2UgVFJMTERfU1RTX1JJTkdfU1RBVFVTOg0KICAg ICAgICAgICAgaWYgKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5SaW5nU3RhdHVz ICE9IDApIHsNCiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIlZDogUmlu ZyBzdGF0dXMgY2hhbmdlOiAiLCBzYy0+dW5pdCk7DQogICAgICAgICAgICAg ICAgaWYgKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5SaW5nU3RhdHVzICYgVFJM TERfUlNfSEFSRF9FUlJPUikgICAgICAgICBwcmludGYoIltIYXJkIGVycm9y XSAiKTsNCiAgICAgICAgICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0 aW9uLlJpbmdTdGF0dXMgJiBUUkxMRF9SU19TT0ZUX0VSUk9SKSAgICAgICAg IHByaW50ZigiW1NvZnQgZXJyb3JdICIpOw0KICAgICAgICAgICAgICAgIGlm IChTdGF0dXMtPlNwZWNpZmljYXRpb24uUmluZ1N0YXR1cyAmIFRSTExEX1JT X1RSQU5TTUlUX0JFQUNPTikgICAgcHJpbnRmKCJbVHJhbnNtaXQgYmVhY29u XSAiKTsNCiAgICAgICAgICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0 aW9uLlJpbmdTdGF0dXMgJiBUUkxMRF9SU19MT0JFX1dJUkVfRkFVTFQpICAg IHByaW50ZigiW1dpcmUgZmF1bHRdICIpOw0KICAgICAgICAgICAgICAgIGlm IChTdGF0dXMtPlNwZWNpZmljYXRpb24uUmluZ1N0YXR1cyAmIFRSTExEX1JT X0FVVE9fUkVNT1ZBTF9FUlJPUikgcHJpbnRmKCJbQXV0byByZW1vdmFsXSAi KTsNCiAgICAgICAgICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9u LlJpbmdTdGF0dXMgJiBUUkxMRF9SU19SRU1PVkVfUkVDRUlWRUQpICAgIHBy aW50ZigiW1JlbW92ZSByZWNlaXZlZF0gIik7DQogICAgICAgICAgICAgICAg aWYgKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5SaW5nU3RhdHVzICYgVFJMTERf UlNfQ09VTlRFUl9PVkVSRkxPVykgICBwcmludGYoIltDb3VudGVyIG92ZXJm bG93XSAiKTsNCiAgICAgICAgICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZp Y2F0aW9uLlJpbmdTdGF0dXMgJiBUUkxMRF9SU19TSU5HTEVfU1RBVElPTikg ICAgIHByaW50ZigiW1NpbmdsZSBzdGF0aW9uXSAiKTsNCiAgICAgICAgICAg ICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlJpbmdTdGF0dXMgJiBU UkxMRF9SU19SSU5HX1JFQ09WRVJZKSAgICAgIHByaW50ZigiW1JpbmcgcmVj b3ZlcnldICIpOw0KICAgICAgICAgICAgICAgIHByaW50ZigiXG4iKTsNCiAg ICAgICAgICAgIH0NCiAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICBjYXNl IFRSTExEX1NUU19BREFQVEVSX0NIRUNLOg0KICAgICAgICAgICAgcHJpbnRm KCJvbHRyJWQ6IEFkYXB0ZXIgY2hlY2sgKCV4ICV4ICV4ICV4KVxuIiwgc2Mt PnVuaXQsIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5BZGFwdGVyQ2hlY2tbMF0s IA0KICAgICAgICAgICAgICAgICAgICBTdGF0dXMtPlNwZWNpZmljYXRpb24u QWRhcHRlckNoZWNrWzFdLCBTdGF0dXMtPlNwZWNpZmljYXRpb24uQWRhcHRl ckNoZWNrWzJdLCANCiAgICAgICAgICAgICAgICAgICAgU3RhdHVzLT5TcGVj aWZpY2F0aW9uLkFkYXB0ZXJDaGVja1szXSk7IA0KICAgICAgICAgICAgYnJl YWs7DQogICAgICAgIGNhc2UgVFJMTERfU1RTX1BST01JU0NVT1VTX1NUT1BQ RUQ6DQogICAgICAgICAgICBwcmludGYoIm9sdHIlZDogUHJvbWlzY3VvdXMg bW9kZSBzdG9wcGVkOiAiLCBzYy0+dW5pdCk7DQogICAgICAgICAgICBzd2l0 Y2goU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlByb21SZW1vdmVkQ2F1c2UpIHsN CiAgICAgICAgICAgICAgICBjYXNlIFRSTExEX1BST01fUkVNT1ZFX1JFQ0VJ VkVEOiBwcmludGYoIlJlbW92ZSByZWNlaXZlZFxuIik7IGJyZWFrOw0KICAg ICAgICAgICAgICAgIGNhc2UgVFJMTERfUFJPTV9QT0xMX0ZBSUxVUkU6ICAg IHByaW50ZigiUG9sbCBmYWlsdXJlXG4iKTsgYnJlYWs7DQogICAgICAgICAg ICAgICAgZGVmYXVsdDogICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRm KCJVbmtub3duICgleClcbiIsIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5Qcm9t UmVtb3ZlZENhdXNlKTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGJy ZWFrOw0KICAgICAgICBjYXNlIFRSTExEX1NUU19MTERfRVJST1I6DQogICAg ICAgICAgICBwcmludGYoIm9sdHIlZDogTExEIGVycm9yICgleCAleCAleCAl eCkgIiwgc2MtPnVuaXQsIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5JbnRlcm5h bEVycm9yWzBdLCANCiAgICAgICAgICAgICAgICAgICAgU3RhdHVzLT5TcGVj aWZpY2F0aW9uLkludGVybmFsRXJyb3JbMV0sIFN0YXR1cy0+U3BlY2lmaWNh dGlvbi5JbnRlcm5hbEVycm9yWzJdLCANCiAgICAgICAgICAgICAgICAgICAg U3RhdHVzLT5TcGVjaWZpY2F0aW9uLkludGVybmFsRXJyb3JbM10pOw0KICAg ICAgICAgICAgYnJlYWs7DQogICAgICAgIGNhc2UgVFJMTERfU1RTX0FEQVBU RVJfVElNRU9VVDoNCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFw dGVyIG9wZXJhdGlvbiB0aW1lZCBvdXQ6ICIsIHNjLT51bml0KTsNCiAgICAg ICAgICAgIHN3aXRjaChTdGF0dXMtPlNwZWNpZmljYXRpb24uQWRhcHRlclRp bWVvdXQpIHsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExEX0NPTU1BTkRf VElNRU9VVDogICBwcmludGYoIkNvbW1hbmRcbiIpOw0KICAgICAgICAgICAg ICAgIGNhc2UgVFJMTERfVFJBTlNNSVRfVElNRU9VVDogIHByaW50ZigiVHJh bnNtaXRcbiIpOw0KICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfSU5URVJS VVBUX1RJTUVPVVQ6IHByaW50ZigiSW50ZXJydXB0XG4iKTsNCiAgICAgICAg ICAgICAgICBkZWZhdWx0OiAgICAgICAgICAgICAgICAgICAgICBwcmludGYo IlVua25vd24gKCV4KVxuIiwgU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkFkYXB0 ZXJUaW1lb3V0KTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGJyZWFr Ow0KICAgICAgICBkZWZhdWx0Og0KICAgICAgICAgICAgcHJpbnRmKCJvbHRy JWQ6IFVua25vd24gc3RhdHVzIHR5cGUgKCV4KVxuIiwgc2MtPnVuaXQsIFN0 YXR1cy0+VHlwZSk7DQoNCiAgICB9DQogICAgaWYgKFN0YXR1cy0+Q2xvc2Vk KSB7DQogICAgICAgIGlmIChzYy0+aHdfc3RhdGUgPiBIV19CQUQpIHsNCiAg ICAgICAgICAgIHNjLT5od19zdGF0ZSA9IEhXX0ZBSUxFRDsNCiAgICAgICAg ICAgIHByaW50Zigib2x0ciVkOiBjbG9zaW5nIGFkYXB0ZXIgZHVlIHRvIGZh aWx1cmUuXG4iLCBzYy0+dW5pdCk7DQogICAgICAgICAgICBvbHRyX3N0b3Ao c2MpOw0KICAgICAgICB9DQogICAgfQ0KfQ0KDQpzdGF0aWMgdm9pZA0KRHJp dmVyQ2xvc2VDb21wbGV0ZWQoRHJpdmVySGFuZGxlKQ0KICAgIHZvaWQgKkRy aXZlckhhbmRsZTsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAm b2x0cl9zb2Z0Y1soaW50KURyaXZlckhhbmRsZV07DQoNCiAgICBwcmludGYo Im9sdHIlZDogRHJpdmVyQ2xvc2VDb21wbGV0ZWRcbiIsIHNjLT51bml0KTsN Cg0KICAgIHVudGltZW91dChvbHRyX3RpbWVvdXQsICh2b2lkICopc2MtPnVu aXQsIHNjLT5vbHRyX2NoKTsNCiAgICB3YWtldXBfb25lKCh2b2lkICopc2Mt PnVuaXQpOw0KDQogICAgaWYgKChzYy0+aHdfc3RhdGUgIT0gSFdfQ0xPU0lO RykgJiYgKHNjLT5od19zdGF0ZSAhPSBIV19DTE9TSU5HMikgJiYgKHNjLT5o d19zdGF0ZSAhPSBIV19DTE9TRUQpKSB7DQogICAgICAgIHByaW50Zigib2x0 ciVkOiBhZGFwdGVyIGNsb3NlIGNvbXBsZXRlIGNhbGxlZCBpbiB3cm9uZyBz dGF0ZSAoJWQpXG4iLCBzYy0+dW5pdCwgc2MtPmh3X3N0YXRlKTsNCiAgICAg ICAgcmV0dXJuOw0KICAgIH0NCiAgICBzYy0+aHdfc3RhdGUgPSBIV19DTE9T SU5HMjsNCiAgICBpZiAoc2MtPmNvbmZpZy0+ZG1hbGV2ZWwgIT0gVFJMTERf RE1BX1BJTykNCiAgICAgICAgaXNhX2RtYV9yZWxlYXNlKHNjLT5jb25maWct PmRtYWxldmVsKTsNCiAgICANCn0NCg0Kc3RhdGljIHZvaWQNCkRyaXZlclN0 YXRpc3RpY3MoRHJpdmVySGFuZGxlLCBTdGF0aXN0aWNzKQ0KICAgIHZvaWQg KkRyaXZlckhhbmRsZTsNCiAgICBUUmxsZFN0YXRpc3RpY3NfdCAqU3RhdGlz dGljczsNCnsNCiAgICBwcmludGYoIm9sdHI6IERyaXZlclN0YXRpc3RpY3Nc biIpOw0KfQ0KDQpzdGF0aWMgdm9pZA0KRHJpdmVyVHJhbnNtaXRGcmFtZUNv bXBsZXRlZChEcml2ZXJIYW5kbGUsIEZyYW1lSGFuZGxlLCBUcmFuc21pdFN0 YXR1cykNCiAgICB2b2lkICpEcml2ZXJIYW5kbGU7DQogICAgdm9pZCAqRnJh bWVIYW5kbGU7DQogICAgaW50IFRyYW5zbWl0U3RhdHVzOw0Kew0KICAgIGlu dCBmcmFtZSA9IChpbnQpRnJhbWVIYW5kbGU7DQogICAgc3RydWN0IG9sdHJf c29mdGMgKnNjID0gJm9sdHJfc29mdGNbKGludClEcml2ZXJIYW5kbGVdOw0K ICAgIHN0cnVjdCBpZm5ldCAqaWZwID0gJnNjLT5hcnBjb20uYWNfaWY7DQoN CiAgICBpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9PQUNUSVZFKQ0KICAgICAg ICBpZnAtPmlmX2ZsYWdzICY9IH4oSUZGX09BQ1RJVkUpOw0KDQogICAgLypw cmludGYoIm9sdHIlZDogdHJhbnNtaXQgY29tcGxldGUgZnJhbWUgJWRcbiIs IHNjLT51bml0LCBmcmFtZSk7Ki8NCiAgICBpZiAoVHJhbnNtaXRTdGF0dXMg PT0gVFJMTERfVFJBTlNNSVRfT0spIHsNCiAgICAgICAgaWZwLT5pZl9vcGFj a2V0cysrOw0KICAgIH0gZWxzZSB7DQogICAgICAgIHByaW50Zigib2x0ciVk OiBEcml2ZXJUcmFuc21pdEZyYW1lQ29tcGxldGVkIChGcmFtZSAlZCBzdGF0 dXMgJXgpXG4iLCBzYy0+dW5pdCwgZnJhbWUsIFRyYW5zbWl0U3RhdHVzKTsN CiAgICAgICAgaWZwLT5pZl9vZXJyb3JzKys7DQogICAgfQ0KICAgIGlmICgo ZnJhbWUgPCAwKSB8fCAoZnJhbWUgPiBUWF9MSVNUX1NJWkUpKSB7DQogICAg ICAgIHByaW50Zigib2x0ciVkOiBib2d1cyB0cmFuc21pdCBidWZmZXIuICgl ZClcbiIsIHNjLT51bml0LCBmcmFtZSk7DQogICAgICAgIHJldHVybjsNCiAg ICB9DQoNCiAgICBzYy0+dHhfYXZhaWwrKzsNCg0KfQ0KDQpzdGF0aWMgdm9p ZA0KRHJpdmVyUmVjZWl2ZUZyYW1lQ29tcGxldGVkKERyaXZlckhhbmRsZSwg Qnl0ZUNvdW50LCBGcmFnbWVudENvdW50LCBGcmFnbWVudEhhbmRsZSwgUmVj ZWl2ZVN0YXR1cykNCiAgICB2b2lkICpEcml2ZXJIYW5kbGU7DQogICAgaW50 IEJ5dGVDb3VudDsNCiAgICBpbnQgRnJhZ21lbnRDb3VudDsNCiAgICB2b2lk ICpGcmFnbWVudEhhbmRsZTsNCiAgICBpbnQgUmVjZWl2ZVN0YXR1czsNCnsN CiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1soaW50 KURyaXZlckhhbmRsZV07DQogICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2Mt PmFycGNvbS5hY19pZjsNCiAgICBzdHJ1Y3QgaXNvODgwMjVfaGVhZGVyICp0 aDsNCiAgICBzdHJ1Y3QgbWJ1ZiAqbTAsICptMSwgKm07DQogICAgaW50IGog PSAoaW50KUZyYWdtZW50SGFuZGxlLCByYywgZnJhbWVfbGVuID0gQnl0ZUNv dW50LCBtYWNfaGRyX2xlbjsNCiAgICBpbnQgbWJ1Zl9vZmZzZXQsIG1idWZf c2l6ZSwgZnJhZ19vZmZzZXQsIGxlbmd0aDsNCiAgICBjaGFyICpmcmFnID0g c2MtPnJ4X2J1ZmZlcltqXS5idWY7DQoNCiAgICAvKnByaW50Zigib2x0ciVk OiBSZWNlaXZlRnJhbWVDb21wbGV0ZWQgKFNpemUgJWQgQ291bnQgJWQgU3Rh cnQgJWQpXG4iLCBzYy0+dW5pdCwgQnl0ZUNvdW50LCBGcmFnbWVudENvdW50 LCBqKTsqLw0KDQogICAgaWYgKHNjLT5od19zdGF0ZSA+PSAgSFdfT1BFTikg eyAgICAgICAgICAgICAvKiBIYXJkd2FyZSBvcGVyYXRpbmcgbm9ybWFsbHkg Ki8NCiAgICAgICAgaWYgKGZyYWcgIT0gc2MtPnJ4X2J1ZmZlcltzYy0+cnhf bmV4dCAmIFJYX0xJU1RfTUFTS10uYnVmKSB7DQogICAgICAgICAgICBwcmlu dGYoIm9sdHIlZDogcmluZyBidWZmZXIgcG9pbnRlciBibG93blxuIiwgc2Mt PnVuaXQpOw0KICAgICAgICAgICAgb2x0cl9zdG9wKHNjKTsNCiAgICAgICAg ICAgIHJldHVybjsNCiAgICAgICAgfQ0KICAgICAgICBpZiAoUmVjZWl2ZVN0 YXR1cyA9PSBUUkxMRF9SQ1ZfT0spIHsgICAgLyogUmVjZWl2ZSBnb29kIGZy YW1lICovDQogICAgICAgICAgICBNR0VUSERSKG0wLCBNX0RPTlRXQUlULCBN VF9EQVRBKTsNCiAgICAgICAgICAgIG1idWZfc2l6ZSA9IE1ITEVOOw0KICAg ICAgICAgICAgaWYgKG0wID09IE5VTEwpIHsNCiAgICAgICAgICAgICAgICBp ZnAtPmlmX2llcnJvcnMrKzsNCiAgICAgICAgICAgICAgICBnb3RvIG91dDsN CiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGlmIChCeXRlQ291bnQgKyAy ID4gTUhMRU4pIHsNCiAgICAgICAgICAgICAgICBNQ0xHRVQobTAsIE1fRE9O VFdBSVQpOw0KICAgICAgICAgICAgICAgIG1idWZfc2l6ZSA9IE1DTEJZVEVT Ow0KICAgICAgICAgICAgICAgIGlmICgobTAtPm1fZmxhZ3MgJiBNX0VYVCkg PT0gMCkgew0KICAgICAgICAgICAgICAgICAgICBtX2ZyZWVtKG0wKTsNCiAg ICAgICAgICAgICAgICAgICAgaWZwLT5pZl9pZXJyb3JzKys7DQogICAgICAg ICAgICAgICAgICAgIGdvdG8gb3V0Ow0KICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgbTAtPm1fcGt0aGRyLnJjdmlm ID0gJnNjLT5hcnBjb20uYWNfaWY7DQogICAgICAgICAgICBtMC0+bV9wa3Ro ZHIubGVuID0gQnl0ZUNvdW50Ow0KICAgICAgICAgICAgbTAtPm1fbGVuID0g MDsNCiAgICAgICAgICAgIG0wLT5tX2RhdGEgKz0gMjsNCiAgICAgICAgICAg IHRoID0gbXRvZChtMCwgc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqKTsNCg0K ICAgICAgICAgICAgbSA9IG0wOyBtYnVmX29mZnNldCA9IDA7IGZyYWdfb2Zm c2V0ID0gMDsNCiAgICAgICAgICAgIHdoaWxlIChmcmFtZV9sZW4gPiAwKSB7 DQogICAgICAgICAgICAgICAgbGVuZ3RoID0gKFJYX0JVRkZFUl9MRU4gLSBm cmFnX29mZnNldCkgPiAobWJ1Zl9zaXplIC0gbWJ1Zl9vZmZzZXQpID8gKG1i dWZfc2l6ZSAtIG1idWZfb2Zmc2V0KSA6DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKFJYX0JVRkZFUl9MRU4gLSBmcmFnX29m ZnNldCk7DQogICAgICAgICAgICAgICAgbGVuZ3RoID0gbGVuZ3RoID4gZnJh bWVfbGVuID8gZnJhbWVfbGVuIDogbGVuZ3RoOw0KICAgICAgICAgICAgICAg IGJjb3B5KGZyYWcgKyBmcmFnX29mZnNldCwgbXRvZChtLCBjaGFyICopICsg bWJ1Zl9vZmZzZXQsIGxlbmd0aCk7DQogICAgICAgICAgICAgICAgbS0+bV9s ZW4gKz0gbGVuZ3RoOw0KICAgICAgICAgICAgICAgIG1idWZfb2Zmc2V0ICs9 IGxlbmd0aDsNCiAgICAgICAgICAgICAgICBmcmFnX29mZnNldCArPSBsZW5n dGg7DQogICAgICAgICAgICAgICAgZnJhbWVfbGVuIC09IGxlbmd0aDsNCiAg ICAgICAgICAgICAgICBpZiAoZnJhZ19vZmZzZXQgPT0gUlhfQlVGRkVSX0xF Tikgew0KICAgICAgICAgICAgICAgICAgICBmcmFnID0gc2MtPnJ4X2J1ZmZl clsrK2pdLmJ1ZjsNCiAgICAgICAgICAgICAgICAgICAgZnJhZ19vZmZzZXQg PSAwOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICBpZiAo KG1idWZfb2Zmc2V0ID09IG1idWZfc2l6ZSkgJiYgKGZyYW1lX2xlbiA+IDAp KSB7DQogICAgICAgICAgICAgICAgICAgIE1HRVQobTEsIE1fRE9OVFdBSVQs IE1UX0RBVEEpOw0KICAgICAgICAgICAgICAgICAgICBtYnVmX3NpemUgPSBN SExFTjsNCiAgICAgICAgICAgICAgICAgICAgaWYgKG0xID09IE5VTEwpIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIGlmcC0+aWZfaWVycm9ycysrOw0K ICAgICAgICAgICAgICAgICAgICAgICAgbV9mcmVlbShtMCk7DQogICAgICAg ICAgICAgICAgICAgICAgICBnb3RvIG91dDsNCiAgICAgICAgICAgICAgICAg ICAgfSAgDQogICAgICAgICAgICAgICAgICAgIGlmIChmcmFtZV9sZW4gPiBN SExFTikgew0KICAgICAgICAgICAgICAgICAgICAgICAgTUNMR0VUKG0xLCBN X0RPTlRXQUlUKTsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1idWZfc2l6 ZSA9IE1DTEJZVEVTOw0KICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCht MS0+bV9mbGFncyAmIE1fRVhUKSA9PSAwKSB7DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgbV9mcmVlbShtMCk7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgbV9mcmVlbShtMSk7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgaWZwLT5pZl9pZXJyb3JzKys7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAg bS0+bV9uZXh0ID0gbTE7DQogICAgICAgICAgICAgICAgICAgIG0gPSBtMTsN CiAgICAgICAgICAgICAgICAgICAgbWJ1Zl9vZmZzZXQgPSAwOw0KICAgICAg ICAgICAgICAgICAgICBtLT5tX2xlbiA9IDA7DQogICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgaWZwLT5pZl9pcGFja2V0 cysrOw0KICAgICAgICANCiNpZiBOQlBGSUxURVIgPiAwDQogICAgICAgICAg ICBpZiAoaWZwLT5pZl9icGYpDQogICAgICAgICAgICAgICAgYnBmX210YXAo aWZwLCBtMCk7DQojZW5kaWYNCg0KICAgICAgICAgICAgaWYgKGlmcC0+aWZf ZmxhZ3MgJiBJRkZfUFJPTUlTQykNCiAgICAgICAgICAgICAgICBpZiAoYmNt cCh0aC0+aXNvODgwMjVfZGhvc3QsIGV0aGVyYnJvYWRjYXN0YWRkciwgc2l6 ZW9mKHRoLT5pc284ODAyNV9kaG9zdCkpICE9IDApIHsNCiAgICAgICAgICAg ICAgICAgICAgaWYgKCgodGgtPmlzbzg4MDI1X2Rob3N0WzBdICYgMHg3Zikg IT0gc2MtPmFycGNvbS5hY19lbmFkZHJbMF0pIHx8DQogICAgICAgICAgICAg ICAgICAgICAgICAoYmNtcCh0aC0+aXNvODgwMjVfZGhvc3QgKyAxLCBzYy0+ YXJwY29tLmFjX2VuYWRkciArIDEsIElTTzg4MDI1X0FERFJfTEVOIC0gMSkp KSB7DQoJICAgICAgICAgICAgICAgIG1fZnJlZW0obTApOw0KICAgICAgICAg ICAgICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgbWFjX2hkcl9sZW4g PSBJU084ODAyNV9IRFJfTEVOOw0KICAgICAgICAgICAgaWYgKHRoLT5pc284 ODAyNV9zaG9zdFswXSAmIDB4ODApIC8qIENoZWNrIGZvciBzb3VyY2Ugcm91 dGluZyBpbmZvICovDQogICAgICAgICAgICAgICAgbWFjX2hkcl9sZW4gKz0g IChudG9ocyh0aC0+cmNmKSAmIDB4MWYwMCkgPj4gODsNCiAgICAgICAgICAg IA0KICAgICAgICAgICAgbTAtPm1fcGt0aGRyLmxlbiAtPSBtYWNfaGRyX2xl bjsNCiAgICAgICAgICAgIG0wLT5tX2xlbiAtPSBtYWNfaGRyX2xlbjsNCiAg ICAgICAgICAgIG0wLT5tX2RhdGEgKz0gbWFjX2hkcl9sZW47DQoNCiAgICAg ICAgICAgIGlzbzg4MDI1X2lucHV0KCZzYy0+YXJwY29tLmFjX2lmLCB0aCwg bTApOw0KDQogICAgICAgIH0gZWxzZSB7DQogICAgICAgICAgICBpZiAoUmVj ZWl2ZVN0YXR1cyAhPSBUUkxMRF9SQ1ZfTk9fREFUQSkgew0KICAgICAgICAg ICAgICAgIHByaW50Zigib2x0ciVkOiByZWNlaXZlIGVycm9yLiAoUmVjZWl2 ZVN0YXR1cz0lZClcbiIsIHNjLT51bml0LCBSZWNlaXZlU3RhdHVzKTsNCiAg ICAgICAgICAgICAgICBpZnAtPmlmX2llcnJvcnMrKzsNCiAgICAgICAgICAg IH0NCiAgICAgICAgfQ0Kb3V0Og0KICAgICAgICB3aGlsZSAoRnJhZ21lbnRD b3VudCA+IDApIHsNCiAgICAgICAgICAgIHJjID0gVFJsbGRSZWNlaXZlRnJh Z21lbnQoc2MtPlRSbGxkQWRhcHRlciwgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHZvaWQgKilzYy0+cnhfYnVmZmVyW3NjLT5y eF9uZXh0ICYgUlhfTElTVF9NQVNLXS5idWYsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAga3Z0b3Aoc2MtPnJ4X2J1ZmZlcltzYy0+ cnhfbmV4dCAmIFJYX0xJU1RfTUFTS10uYnVmKSwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSWF9CVUZGRVJfTEVOLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2b2lkICopc2MtPnJ4 X2J1ZmZlcltzYy0+cnhfbmV4dCAmIFJYX0xJU1RfTUFTS10uaW5kZXgpOw0K ICAgICAgICAgICAgaWYgKHJjID09IFRSTExEX1JFQ0VJVkVfT0spIHsNCiAg ICAgICAgICAgICAgICBzYy0+cnhfbmV4dCsrOw0KICAgICAgICAgICAgICAg IEZyYWdtZW50Q291bnQtLTsNCiAgICAgICAgICAgIH0gZWxzZSB7DQogICAg ICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IEFkYXB0ZXIgcmVmdXNlZCBm cmFnbWVudCAoJWQpLlxuIiwgc2MtPnVuaXQsIHNjLT5yeF9uZXh0IC0gMSk7 DQogICAgICAgICAgICAgICAgc2MtPnJ4X2F2YWlsICs9IEZyYWdtZW50Q291 bnQ7DQogICAgICAgICAgICAgICAgYnJlYWs7DQogICAgICAgICAgICB9DQog ICAgICAgIH0NCiAgICB9IGVsc2UgeyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC8qIEhhcmR3YXJlIGJlaW5nIGNsb3NlZCAqLw0KICAg ICAgICBpZiAoZnJhZyAhPSBzYy0+cnhfYnVmZmVyW3NjLT5yeF9uZXh0Kysg JiBSWF9MSVNUX01BU0tdLmJ1Zikgew0KICAgICAgICAgICAgcHJpbnRmKCJv bHRyJWQ6IHJpbmcgYnVmZmVyIHBvaW50ZXIgYmxvd25cbiIsIHNjLT51bml0 KTsgIA0KICAgICAgICB9ICAgICAgICAgICANCiAgICAgICAgc2MtPnJ4X2F2 YWlsICs9IEZyYWdtZW50Q291bnQ7DQogICAgfQ0KICAgIA0KfQ0KDQoNCi8q DQogKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFBNVyBHbHVlIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAqLw0KDQojaWZuZGVm IFRSbGxkSW5saW5lSU8NCg0Kc3RhdGljIHZvaWQgDQpEcml2ZXJPdXRCeXRl KElPQWRkcmVzcywgdmFsdWUpDQogICAgdW5zaWduZWQgc2hvcnQgSU9BZGRy ZXNzOw0KICAgIHVuc2lnbmVkIGNoYXIgdmFsdWU7DQp7DQogICAgb3V0YihJ T0FkZHJlc3MsIHZhbHVlKTsNCn0NCg0Kc3RhdGljIHZvaWQNCkRyaXZlck91 dFdvcmQoSU9BZGRyZXNzLCB2YWx1ZSkNCiAgICB1bnNpZ25lZCBzaG9ydCBJ T0FkZHJlc3M7DQogICAgdW5zaWduZWQgc2hvcnQgdmFsdWU7DQp7DQogICAg b3V0dyhJT0FkZHJlc3MsIHZhbHVlKTsNCn0NCg0Kc3RhdGljIHZvaWQNCkRy aXZlck91dER3b3JkKElPQWRkcmVzcywgdmFsdWUpDQogICAgdW5zaWduZWQg c2hvcnQgSU9BZGRyZXNzOw0KICAgIHVuc2lnbmVkIGxvbmcgdmFsdWU7DQp7 DQogICAgb3V0bChJT0FkZHJlc3MsIHZhbHVlKTsNCn0NCg0Kc3RhdGljIHZv aWQNCkRyaXZlclJlcE91dEJ5dGUoSU9BZGRyZXNzLCBEYXRhUG9pbnRlciwg Qnl0ZUNvdW50KQ0KICAgIHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCiAg ICB1bnNpZ25lZCBjaGFyICAqRGF0YVBvaW50ZXI7DQogICAgaW50IEJ5dGVD b3VudDsNCnsNCiAgICBvdXRzYihJT0FkZHJlc3MsICh2b2lkICopRGF0YVBv aW50ZXIsIEJ5dGVDb3VudCk7DQp9DQoNCnN0YXRpYyB2b2lkDQpEcml2ZXJS ZXBPdXRXb3JkKElPQWRkcmVzcywgRGF0YVBvaW50ZXIsIFdvcmRDb3VudCkN CiAgICB1bnNpZ25lZCBzaG9ydCBJT0FkZHJlc3M7DQogICAgdW5zaWduZWQg c2hvcnQgKkRhdGFQb2ludGVyOw0KICAgIGludCBXb3JkQ291bnQ7DQp7DQog ICAgb3V0c3coSU9BZGRyZXNzLCAodm9pZCAqKURhdGFQb2ludGVyLCBXb3Jk Q291bnQpOw0KfQ0KDQpzdGF0aWMgdm9pZA0KRHJpdmVyUmVwT3V0RHdvcmQo SU9BZGRyZXNzLCBEYXRhUG9pbnRlciwgRFdvcmRDb3VudCkNCiAgICB1bnNp Z25lZCBzaG9ydCBJT0FkZHJlc3M7DQogICAgdW5zaWduZWQgbG9uZyAgKkRh dGFQb2ludGVyOw0KICAgIGludCBEV29yZENvdW50Ow0Kew0KICAgIG91dHNs KElPQWRkcmVzcywgKHZvaWQgKilEYXRhUG9pbnRlciwgRFdvcmRDb3VudCk7 DQp9DQoNCnN0YXRpYyB1bnNpZ25lZCBjaGFyDQpEcml2ZXJJbkJ5dGUoSU9B ZGRyZXNzKQ0KICAgIHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCnsNCiAg ICByZXR1cm4oaW5iKElPQWRkcmVzcykpOw0KfQ0KDQpzdGF0aWMgdW5zaWdu ZWQgc2hvcnQNCkRyaXZlckluV29yZChJT0FkZHJlc3MpDQogICAgdW5zaWdu ZWQgc2hvcnQgSU9BZGRyZXNzOw0Kew0KICAgcmV0dXJuKGludyhJT0FkZHJl c3MpKTsNCn0NCg0Kc3RhdGljIHVuc2lnbmVkIGxvbmcNCkRyaXZlckluRHdv cmQoSU9BZGRyZXNzKQ0KICAgIHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsN CnsNCiAgICByZXR1cm4oaW5sKElPQWRkcmVzcykpOw0KfQ0KDQpzdGF0aWMg dm9pZA0KRHJpdmVyUmVwSW5CeXRlKElPQWRkcmVzcywgRGF0YVBvaW50ZXIs IEJ5dGVDb3VudCkNCiAgICB1bnNpZ25lZCBzaG9ydCBJT0FkZHJlc3M7DQog ICAgdW5zaWduZWQgY2hhciAgKkRhdGFQb2ludGVyOw0KICAgIGludCBCeXRl Q291bnQ7DQp7DQogICAgaW5zYihJT0FkZHJlc3MsICh2b2lkICopRGF0YVBv aW50ZXIsIEJ5dGVDb3VudCk7DQp9DQoNCnN0YXRpYyB2b2lkDQpEcml2ZXJS ZXBJbldvcmQoSU9BZGRyZXNzLCBEYXRhUG9pbnRlciwgV29yZENvdW50KQ0K ICAgIHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCiAgICB1bnNpZ25lZCBz aG9ydCAqRGF0YVBvaW50ZXI7DQogICAgaW50IFdvcmRDb3VudDsNCnsNCiAg ICBpbnN3KElPQWRkcmVzcywgKHZvaWQgKilEYXRhUG9pbnRlciwgV29yZENv dW50KTsNCn0NCnN0YXRpYyB2b2lkDQpEcml2ZXJSZXBJbkR3b3JkKElPQWRk cmVzcywgRGF0YVBvaW50ZXIsIERXb3JkQ291bnQpDQogICAgdW5zaWduZWQg c2hvcnQgSU9BZGRyZXNzOw0KICAgIHVuc2lnbmVkIGxvbmcgICpEYXRhUG9p bnRlcjsNCiAgICBpbnQgRFdvcmRDb3VudDsNCnsNCiAgICBpbnNsKElPQWRk cmVzcywgKHZvaWQgKilEYXRhUG9pbnRlciwgRFdvcmRDb3VudCk7DQp9DQoj ZW5kaWYgLyogVFJsbGRJbmxpbmVJTyAqLw0KDQojZW5kaWYgLyogTk9MVFIg Ki8NCg== --0-1628243425-918586018=:14147 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=anarchy Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=anarchy Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMgbWFjaGluZSB3aXRoIFdEL0FIeC9O Q1IvQlR4IGZhbWlseSBkaXNrcw0KIw0KIyBGb3IgbW9yZSBpbmZvcm1hdGlv biByZWFkIHRoZSBoYW5kYm9vayBwYXJ0IFN5c3RlbSBBZG1pbmlzdHJhdGlv biAtPiANCiMgQ29uZmlndXJpbmcgdGhlIEZyZWVCU0QgS2VybmVsIC0+IFRo ZSBDb25maWd1cmF0aW9uIEZpbGUuIA0KIyBUaGUgaGFuZGJvb2sgaXMgYXZh aWxhYmxlIGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rIG9yIG9ubGluZSBh cw0KIyBsYXRlc3QgdmVyc2lvbiBmcm9tIHRoZSBGcmVlQlNEIFdvcmxkIFdp ZGUgV2ViIHNlcnZlciANCiMgPFVSTDpodHRwOi8vd3d3LkZyZWVCU0QuT1JH Lz4NCiMNCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9mIG9wdGlvbnMgYW5kIG1v cmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZSANCiMgZGV2aWNlIGxp bmVzIGlzIHByZXNlbnQgaW4gdGhlIC4vTElOVCBjb25maWd1cmF0aW9uIGZp bGUuIElmIHlvdSBhcmUgDQojIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3Nl IG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0IGluIExJTlQu DQojDQojCSRJZDogR0VORVJJQyx2IDEuMTE4IDE5OTgvMDkvMTggMDA6NDY6 NDAgbWphY29iIEV4cCAkDQoNCm1hY2hpbmUJCSJpMzg2Ig0KI2NwdQkJIkkz ODZfQ1BVIg0KY3B1CQkiSTQ4Nl9DUFUiDQpjcHUJCSJJNTg2X0NQVSINCiNj cHUJCSJJNjg2X0NQVSINCmlkZW50CQlhbmFyY2h5DQptYXh1c2VycwkzMg0K DQpvcHRpb25zCQkiTUFYTUVNPSgxMjgqMTAyNCkiDQpvcHRpb25zICAgICAg ICAgTk1CQ0xVU1RFUlM9NDA5Ng0KDQpvcHRpb25zCQlNQVRIX0VNVUxBVEUJ CSNTdXBwb3J0IGZvciB4ODcgZW11bGF0aW9uDQpvcHRpb25zCQlJTkVUCQkJ I0ludGVyTkVUd29ya2luZw0Kb3B0aW9ucwkJRkZTCQkJI0JlcmtlbGV5IEZh c3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucwkJTkZTCQkJI05ldHdvcmsgRmlsZXN5 c3RlbQ0Kb3B0aW9ucwkJTVNET1NGUwkJCSNNU0RPUyBGaWxlc3lzdGVtDQpv cHRpb25zCQkiQ0Q5NjYwIgkJI0lTTyA5NjYwIEZpbGVzeXN0ZW0NCm9wdGlv bnMJCSJDRDk2NjBfUk9PVCIJCSNDRC1ST00gdXNhYmxlIGFzIHJvb3QgZGV2 aWNlDQpvcHRpb25zCQlGRlNfUk9PVAkJI0ZGUyB1c2FibGUgYXMgcm9vdCBk ZXZpY2UgW2tlZXAgdGhpcyFdDQpvcHRpb25zCQlORlNfUk9PVAkJI05GUyB1 c2FibGUgYXMgcm9vdCBkZXZpY2UNCm9wdGlvbnMJCVBST0NGUwkJCSNQcm9j ZXNzIGZpbGVzeXN0ZW0NCm9wdGlvbnMJCSJDT01QQVRfNDMiCQkjQ29tcGF0 aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAgVEhJUyFdDQpvcHRpb25zCQlTQ1NJ X0RFTEFZPTgwMDAgCSNCZSBwZXNzaW1pc3RpYyBhYm91dCBKb2UgU0NTSSBk ZXZpY2UNCm9wdGlvbnMJCVVDT05TT0xFCQkjQWxsb3cgdXNlcnMgdG8gZ3Jh YiB0aGUgY29uc29sZQ0Kb3B0aW9ucwkJRkFJTFNBRkUJCSNCZSBjb25zZXJ2 YXRpdmUNCm9wdGlvbnMJCVVTRVJDT05GSUcJCSNib290IC1jIGVkaXRvcg0K b3B0aW9ucwkJVklTVUFMX1VTRVJDT05GSUcJI3Zpc3VhbCBib290IC1jIGVk aXRvcg0KDQpvcHRpb25zICAgICAgICAgU09GVFVQREFURVMNCg0Kb3B0aW9u cwkJRERCDQpvcHRpb25zCQlEREJfVU5BVFRFTkRFRA0KDQpjb25maWcJCWtl cm5lbAlyb290IG9uIGRhMA0KDQpjb250cm9sbGVyCWlzYTANCiNjb250cm9s bGVyCWVpc2EwDQpjb250cm9sbGVyCXBjaTANCg0KY29udHJvbGxlciAgICAg IHBucDANCg0KI2NvbnRyb2xsZXIgICAgICBzbmQwDQojZGV2aWNlIHNiMCAg ICAgIGF0IGlzYT8gcG9ydCAweDIyMCBpcnEgNSBkcnEgMSB2ZWN0b3Igc2Jp bnRyDQojZGV2aWNlIHNieHZpMCAgIGF0IGlzYT8gZHJxIDUNCiNkZXZpY2Ug c2JtaWRpMCAgYXQgaXNhPyBwb3J0IDB4MzMwDQoNCmNvbnRyb2xsZXIJZmRj MAlhdCBpc2E/IHBvcnQgIklPX0ZEMSIgYmlvIGlycSA2IGRycSAyIHZlY3Rv ciBmZGludHINCmRpc2sJCWZkMAlhdCBmZGMwIGRyaXZlIDANCiNkaXNrCQlm ZDEJYXQgZmRjMCBkcml2ZSAxDQojIFVubGVzcyB5b3Uga25vdyB2ZXJ5IHdl bGwgd2hhdCB5b3UncmUgZG9pbmcsIGxlYXZlIGZ0MCBhdCBkcml2ZSAyLCBv cg0KIyByZW1vdmUgdGhlIGxpbmUgZW50aXJlbHkgaWYgeW91IGRvbid0IG5l ZWQgaXQuICBUcnlpbmcgdG8gY29uZmlndXJlDQojIGl0IG9uIGFub3RoZXIg dW5pdCBtaWdodCBjYXVzZSBzdXJwcmlzZXMsIHNlZSBQUiBrZXJuLzcxNzYu DQojdGFwZQkJZnQwCWF0IGZkYzAgZHJpdmUgMg0KDQojb3B0aW9ucwkJIkNN RDY0MCIJIyB3b3JrIGFyb3VuZCBDTUQ2NDAgY2hpcCBkZWZpY2llbmN5DQoj Y29udHJvbGxlcgl3ZGMwCWF0IGlzYT8gcG9ydCAiSU9fV0QxIiBiaW8gaXJx IDE0IHZlY3RvciB3ZGludHINCiNkaXNrCQl3ZDAJYXQgd2RjMCBkcml2ZSAw DQojZGlzawkJd2QxCWF0IHdkYzAgZHJpdmUgMQ0KDQojY29udHJvbGxlcgl3 ZGMxCWF0IGlzYT8gcG9ydCAiSU9fV0QyIiBiaW8gaXJxIDE1IHZlY3RvciB3 ZGludHINCiNkaXNrCQl3ZDIJYXQgd2RjMSBkcml2ZSAwDQojZGlzawkJd2Qz CWF0IHdkYzEgZHJpdmUgMQ0KDQojb3B0aW9ucwkJQVRBUEkJCSNFbmFibGUg QVRBUEkgc3VwcG9ydCBmb3IgSURFIGJ1cw0KI29wdGlvbnMJCUFUQVBJX1NU QVRJQwkjRG9uJ3QgZG8gaXQgYXMgYW4gTEtNDQojZGV2aWNlCQl3Y2QwCQkj SURFIENELVJPTQ0KI2RldmljZQkJd2ZkMAkJI0lERSBGbG9wcHkgKGUuZy4g TFMtMTIwKQ0KDQojIEEgc2luZ2xlIGVudHJ5IGZvciBhbnkgb2YgdGhlc2Ug Y29udHJvbGxlcnMgKG5jciwgYWhiLCBhaGMsIGFtZCkgaXMNCiMgc3VmZmlj aWVudCBmb3IgYW55IG51bWJlciBvZiBpbnN0YWxsZWQgZGV2aWNlcy4NCmNv bnRyb2xsZXIJbmNyMA0KI2NvbnRyb2xsZXIJYW1kMA0KI2NvbnRyb2xsZXIJ YWhiMA0KI2NvbnRyb2xsZXIJYWhjMA0KI2NvbnRyb2xsZXIJaXNwMA0KDQoj IFRoaXMgY29udHJvbGxlciBvZmZlcnMgYSBudW1iZXIgb2YgY29uZmlndXJh dGlvbiBvcHRpb25zLCB0b28gbWFueSB0bw0KIyBkb2N1bWVudCBoZXJlICAt IHNlZSB0aGUgTElOVCBmaWxlIGluIHRoaXMgZGlyZWN0b3J5IGFuZCBsb29r IHVwIHRoZQ0KIyBkcHQwIGVudHJ5IHRoZXJlIGZvciBtdWNoIGZ1bGxlciBk b2N1bWVudGF0aW9uIG9uIHRoaXMuICBUaGUgb3B0aW9ucw0KIyBsaW5lIGZv bGxvd2luZyBkcHQwIGhlcmUgaXMgYWxzbyBjdXJyZW50bHkgYSAqcmVxdWly ZWQqIG9wdGlvbiBmb3IgaXQuDQojIGNvbnRyb2xsZXIgICAgICBkcHQwDQoj IG9wdGlvbnMgRFBUX01FQVNVUkVfUEVSRk9STUFOQ0UNCg0KI2NvbnRyb2xs ZXIJYWR2MAlhdCBpc2E/IHBvcnQgPyBjYW0gaXJxID8NCiNjb250cm9sbGVy CWJ0MAlhdCBpc2E/IHBvcnQgPyBjYW0gaXJxID8NCiNjb250cm9sbGVyCWFo YTAJYXQgaXNhPyBwb3J0ID8gY2FtIGlycSA/DQojY29udHJvbGxlcgl1aGEw CWF0IGlzYT8gcG9ydCAiSU9fVUhBMCIgYmlvIGlycSA/IGRycSA1IHZlY3Rv ciB1aGFpbnRyDQojY29udHJvbGxlcglhaWMwCWF0IGlzYT8gcG9ydCAweDM0 MCBiaW8gaXJxIDExIHZlY3RvciBhaWNpbnRyDQojY29udHJvbGxlcgluY2Ew CWF0IGlzYT8gcG9ydCAweDFmODggYmlvIGlycSAxMCB2ZWN0b3IgbmNhaW50 cg0KI2NvbnRyb2xsZXIJbmNhMQlhdCBpc2E/IHBvcnQgMHgzNTAgYmlvIGly cSA1IHZlY3RvciBuY2FpbnRyDQojY29udHJvbGxlcglzZWEwCWF0IGlzYT8g YmlvIGlycSA1IGlvbWVtIDB4YzgwMDAgaW9zaXogMHgyMDAwIHZlY3RvciBz ZWFpbnRyDQoNCmNvbnRyb2xsZXIJc2NidXMwDQoNCmRldmljZQkJZGEwDQoN CmRldmljZSAgICAgICAgICBvZDAgICAgICNTZWUgTElOVCBmb3IgcG9zc2li bGUgYG9kJyBvcHRpb25zLg0KI29wdGlvbnMgICAgICAgICBPRF9CT0dVU19O T1RfUkVBRFkgICAgICANCg0KZGV2aWNlCQlzYTANCg0KZGV2aWNlCQlwYXNz MA0KDQpkZXZpY2UJCWNkMAkjT25seSBuZWVkIG9uZSBvZiB0aGVzZSwgdGhl IGNvZGUgZHluYW1pY2FsbHkgZ3Jvd3MNCg0KI2RldmljZQkJd3QwCWF0IGlz YT8gcG9ydCAweDMwMCBiaW8gaXJxIDUgZHJxIDEgdmVjdG9yIHd0aW50cg0K I2RldmljZQkJbWNkMAlhdCBpc2E/IHBvcnQgMHgzMDAgYmlvIGlycSAxMCB2 ZWN0b3IgbWNkaW50cg0KDQojY29udHJvbGxlcgltYXRjZDAJYXQgaXNhPyBw b3J0IDB4MjMwIGJpbw0KDQojZGV2aWNlCQlzY2QwCWF0IGlzYT8gcG9ydCAw eDIzMCBiaW8NCg0KIyBhdGtiZGMwIGNvbnRyb2xscyBib3RoIHRoZSBrZXli b2FyZCBhbmQgdGhlIFBTLzIgbW91c2UNCmNvbnRyb2xsZXIJYXRrYmRjMAlh dCBpc2E/IHBvcnQgSU9fS0JEIHR0eQ0KZGV2aWNlCQlhdGtiZDAJYXQgaXNh PyB0dHkgaXJxIDENCmRldmljZQkJcHNtMAlhdCBpc2E/IHR0eSBpcnEgMTIN Cg0KZGV2aWNlCQl2Z2EwCWF0IGlzYT8gcG9ydCA/IGNvbmZsaWN0cw0KDQoj IHNwbGFzaCBzY3JlZW4vc2NyZWVuIHNhdmVyDQpwc2V1ZG8tZGV2aWNlCXNw bGFzaA0KDQojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2 ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZQkJc2MwCWF0 IGlzYT8gdHR5DQojIEVuYWJsZSB0aGlzIGFuZCBQQ1ZUX0ZSRUVCU0QgZm9y IHBjdnQgdnQyMjAgY29tcGF0aWJsZSBjb25zb2xlIGRyaXZlcg0KI2Rldmlj ZQkJdnQwCWF0IGlzYT8gdHR5DQpvcHRpb25zCQlYU0VSVkVSCQkJIyBzdXBw b3J0IGZvciBYIHNlcnZlcg0KI29wdGlvbnMJCUZBVF9DVVJTT1IJCSMgc3Rh cnQgd2l0aCBibG9jayBjdXJzb3INCiMgSWYgeW91IGhhdmUgYSBUaGlua1BB RCwgdW5jb21tZW50IHRoaXMgYWxvbmcgd2l0aCB0aGUgcmVzdCBvZiB0aGUg UENWVCBsaW5lcw0KI29wdGlvbnMJCVBDVlRfU0NBTlNFVD0yCQkjIElCTSBr ZXlib2FyZHMgYXJlIG5vbi1zdGQNCg0KZGV2aWNlCQlucHgwCWF0IGlzYT8g cG9ydCAiSU9fTlBYIiBpcnEgMTMgdmVjdG9yIG5weGludHINCg0KIw0KIyBM YXB0b3Agc3VwcG9ydCAoc2VlIExJTlQgZm9yIG1vcmUgb3B0aW9ucykNCiMN CiNkZXZpY2UJCWFwbTAgICAgYXQgaXNhPwlkaXNhYmxlCWZsYWdzIDB4MzEg IyBBZHZhbmNlZCBQb3dlciBNYW5hZ2VtZW50DQoNCiMgUENDQVJEIChQQ01D SUEpIHN1cHBvcnQNCiNjb250cm9sbGVyCWNhcmQwDQojZGV2aWNlCQlwY2lj MAlhdCBjYXJkPw0KI2RldmljZQkJcGNpYzEJYXQgY2FyZD8NCg0KZGV2aWNl CQlzaW8wCWF0IGlzYT8gcG9ydCAiSU9fQ09NMSIgZmxhZ3MgMHgxMCB0dHkg aXJxIDQgdmVjdG9yIHNpb2ludHINCmRldmljZQkJc2lvMQlhdCBpc2E/IHBv cnQgIklPX0NPTTIiIHR0eSBpcnEgMyB2ZWN0b3Igc2lvaW50cg0KZGV2aWNl CQlzaW8yCWF0IGlzYT8gZGlzYWJsZSBwb3J0ICJJT19DT00zIiB0dHkgaXJx IDUgdmVjdG9yIHNpb2ludHINCmRldmljZQkJc2lvMwlhdCBpc2E/IGRpc2Fi bGUgcG9ydCAiSU9fQ09NNCIgdHR5IGlycSA5IHZlY3RvciBzaW9pbnRyDQoN CiNkZXZpY2UJCWxwdDAJYXQgaXNhPyBwb3J0PyB0dHkgaXJxIDcgdmVjdG9y IGxwdGludHINCiNkZXZpY2UJCWxwdDEJYXQgaXNhPyBwb3J0PyB0dHkNCiNk ZXZpY2UJCW1zZTAJYXQgaXNhPyBwb3J0IDB4MjNjIHR0eSBpcnEgNSB2ZWN0 b3IgbXNlaW50cg0KDQojZGV2aWNlCQlwc20wCWF0IGlzYT8gcG9ydCAiSU9f S0JEIiBjb25mbGljdHMgdHR5IGlycSAxMiB2ZWN0b3IgcHNtaW50cg0KDQoj IE9yZGVyIGlzIGltcG9ydGFudCBoZXJlIGR1ZSB0byBpbnRydXNpdmUgcHJv YmVzLCBkbyAqbm90KiBhbHBoYWJldGl6ZQ0KIyB0aGlzIGxpc3Qgb2YgbmV0 d29yayBpbnRlcmZhY2VzIHVudGlsIHRoZSBwcm9iZXMgaGF2ZSBiZWVuIGZp eGVkLg0KIyBSaWdodCBub3cgaXQgYXBwZWFycyB0aGF0IHRoZSBpZTAgbXVz dCBiZSBwcm9iZWQgYmVmb3JlIGVwMC4gU2VlDQojIHJldmlzaW9uIDEuMjAg b2YgdGhpcyBmaWxlLg0KI2RldmljZSBkZTANCmRldmljZSBmeHAwDQojZGV2 aWNlIHRsMA0KI2RldmljZSB0eDANCiNkZXZpY2UgdngwDQojZGV2aWNlIHhs MA0KDQpkZXZpY2Ugb2x0cjAgYXQgaXNhPyANCmRldmljZSB0b2swIGF0IGlz YT8gcG9ydCAweGEyMCBuZXQgaXJxIDcgaW9tZW0gMHhkODAwMA0KI2Rldmlj ZSBlZDAgYXQgaXNhPyBwb3J0IDB4MjgwIG5ldCBpcnEgMTAgaW9tZW0gMHhk ODAwMCB2ZWN0b3IgZWRpbnRyDQojZGV2aWNlIGllMCBhdCBpc2E/IHBvcnQg MHgzMDAgbmV0IGlycSAxMCBpb21lbSAweGQwMDAwIHZlY3RvciBpZWludHIN CiNkZXZpY2UgZXAwIGF0IGlzYT8gcG9ydCAweDMwMCBuZXQgaXJxIDEwIHZl Y3RvciBlcGludHINCiNkZXZpY2UgZXgwIGF0IGlzYT8gcG9ydD8gbmV0IGly cT8gdmVjdG9yIGV4aW50cg0KI2RldmljZSBmZTAgYXQgaXNhPyBwb3J0IDB4 MzAwIG5ldCBpcnEgPyB2ZWN0b3IgZmVpbnRyDQojZGV2aWNlIGxlMCBhdCBp c2E/IHBvcnQgMHgzMDAgbmV0IGlycSA1IGlvbWVtIDB4ZDAwMDAgdmVjdG9y IGxlX2ludHINCiNkZXZpY2UgbG5jMCBhdCBpc2E/IHBvcnQgMHgyODAgbmV0 IGlycSAxMCBkcnEgMCB2ZWN0b3IgbG5jaW50cg0KI2RldmljZSB6ZTAgYXQg aXNhPyBwb3J0IDB4MzAwIG5ldCBpcnEgMTAgaW9tZW0gMHhkODAwMCB2ZWN0 b3IgemVpbnRyDQojZGV2aWNlIHpwMCBhdCBpc2E/IHBvcnQgMHgzMDAgbmV0 IGlycSAxMCBpb21lbSAweGQ4MDAwIHZlY3RvciB6cGludHINCiNkZXZpY2Ug Y3MwIGF0IGlzYT8gcG9ydCAweDMwMCBuZXQgaXJxID8gdmVjdG9yIGNzaW50 cg0KDQpwc2V1ZG8tZGV2aWNlCWxvb3ANCnBzZXVkby1kZXZpY2UJZXRoZXIN CnBzZXVkby1kZXZpY2UJdG9rZW4NCiNwc2V1ZG8tZGV2aWNlCXNsCTENCiNw c2V1ZG8tZGV2aWNlCXBwcAkxDQojcHNldWRvLWRldmljZQl0dW4JMQ0KcHNl dWRvLWRldmljZSAgIGJwZmlsdGVyIDQNCnBzZXVkby1kZXZpY2UJcHR5CTY0 DQpwc2V1ZG8tZGV2aWNlICAgc25wICAgICA0DQpwc2V1ZG8tZGV2aWNlCWd6 aXAJCSMgRXhlYyBnemlwcGVkIGEub3V0J3MNCg0KIyBLVFJBQ0UgZW5hYmxl cyB0aGUgc3lzdGVtLWNhbGwgdHJhY2luZyBmYWNpbGl0eSBrdHJhY2UoMiku DQojIFRoaXMgYWRkcyA0IEtCIGJsb2F0IHRvIHlvdXIga2VybmVsLCBhbmQg c2xpZ2h0bHkgaW5jcmVhc2VzDQojIHRoZSBjb3N0cyBvZiBlYWNoIHN5c2Nh bGwuDQpvcHRpb25zCQlLVFJBQ0UJCSNrZXJuZWwgdHJhY2luZw0KDQojIFRo aXMgcHJvdmlkZXMgc3VwcG9ydCBmb3IgU3lzdGVtIFYgc2hhcmVkIG1lbW9y eS4NCiMNCm9wdGlvbnMJCVNZU1ZTSE0NCm9wdGlvbnMgICAgICAgICBTWVNW U0VNDQpvcHRpb25zICAgICAgICAgU1lTVk1TRw0K --0-1628243425-918586018=:14147-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:16:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24115 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:16:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.monmouth.com (shell.monmouth.com [205.231.236.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24108 for ; Tue, 9 Feb 1999 11:16:01 -0800 (PST) (envelope-from pechter@pechter.nws.net) Received: from pechter.nws.net (bg-tc-ppp336.monmouth.com [209.191.61.83]) by shell.monmouth.com (8.9.0/8.9.0) with ESMTP id OAA19248 for ; Tue, 9 Feb 1999 14:15:43 -0500 (EST) Received: (from pechter@localhost) by pechter.nws.net (8.9.2/8.9.1) id OAA07509 for freebsd-hackers@freebsd.org; Tue, 9 Feb 1999 14:13:19 -0500 (EST) (envelope-from pechter) From: Bill Pechter Message-Id: <199902091913.OAA07509@pechter.nws.net> Subject: Samba 2.0.x To: freebsd-hackers@FreeBSD.ORG Date: Tue, 9 Feb 1999 14:13:18 -0500 (EST) Reply-to: pechter@shell.monmouth.com X-Phone-Number: 908-389-3592 X-OS-Type: FreeBSD 3.0-Stable X-Mailer: ELM [version 2.4ME+ PL43 (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 Has anyone resolved the Samba 2.0 not handling passwords with a FreeBSD 3.x system. Bill --- Bill Gates is a Persian cat and a monocle away from being a villain in a James Bond movie -- Dennis Miller bpechter@shell.monmouth.com|pechter@pechter.nws.net|pechter@pechter.ddns.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:20:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24654 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:20:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles313.castles.com [208.214.167.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24618; Tue, 9 Feb 1999 11:20:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA04227; Tue, 9 Feb 1999 11:15:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902091915.LAA04227@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer cc: Dag-Erling Smorgrav , Eivind Eklund , Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-reply-to: Your message of "Tue, 09 Feb 1999 10:18:41 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Feb 1999 11:15:55 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > someone said thay had code already.. > was it warner? or maybe one of the Johns. Doug Rabson, IIRC. > julian > > On 9 Feb 1999, Dag-Erling Smorgrav wrote: > > > Eivind Eklund writes: > > > On Tue, Feb 09, 1999 at 10:32:26AM +0100, Emmanuel DELOGET wrote: > > > > I wanna add some sysctl entries to a loadable kernel > > > > module. As I'm sure I'm not the first doing that, > > > > if anybody knows... > > > It is not possible at the moment. :-( > > > > Gag. I intended to look into this, but got sidetracked. I'll put it on > > my TODO list. > > > > DES > > -- > > Dag-Erling Smorgrav - des@flood.ping.uio.no > > > > 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 > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:43:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27090 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:43:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from helen.CS.Berkeley.EDU (helen.CS.Berkeley.EDU [128.32.131.251]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27085 for ; Tue, 9 Feb 1999 11:43:19 -0800 (PST) (envelope-from jmacd@helen.CS.Berkeley.EDU) Received: (from jmacd@localhost) by helen.CS.Berkeley.EDU (8.9.1a/8.9.1) id LAA05978; Tue, 9 Feb 1999 11:43:19 -0800 (PST) Message-ID: <19990209114319.30878@helen.CS.Berkeley.EDU> Date: Tue, 9 Feb 1999 11:43:19 -0800 From: Josh MacDonald To: freebsd-hackers@FreeBSD.ORG Subject: natd and rc.firewall Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently followed the directions in the natd man page, I'm trying to set up IP masquerading. I noticed that natd is started in the 3rd network startup phase, yet rc.firewall runs from the first. This means that everything inbetween the firewall startup and natd has no network access, yet this is when many utilities try to run. I had to move natd to start before running rc.firewall, and it seems to work now. Someone who understands this stuff might want to take a look. -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:43:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27123 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:43:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27105 for ; Tue, 9 Feb 1999 11:43:21 -0800 (PST) (envelope-from dfr@nlsystems.com.demon.co.uk) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id TAA12053; Tue, 9 Feb 1999 19:42:19 GMT (envelope-from dfr@nlsystems.com.demon.co.uk) X-Authentication-Warning: herring.nlsystems.com: dfr owned process doing -bs Date: Tue, 9 Feb 1999 19:42:15 +0000 (GMT) From: Doug Rabson X-Sender: dfr@localhost To: Christoph Kukulies cc: hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902072122.WAA15102@gilberto.physik.RWTH-Aachen.DE> 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 Sun, 7 Feb 1999, Christoph Kukulies wrote: > > Does anyone have experience with portability of common > IPC mechanisms between Linux 2.x and FreeBSD? > > I'm trying to estimate the risk of a porting project from > Linux to FreeBSD. > What peculiarities are there? Incompatibilities between the > two OSs WRT to 'clean' implementation of these disciplines? > > sockets - feature set compatible? Both systems use the Berkeley sockets api and should be source compatible. > pipes - ? named pipes? Yes. > mmap - stable? limitations? No problems for local filesystems. Possibly one or two NFS bugs might remain but I doubt that you would come across them. I think I had one or two problems with Linux using strange names MAP_XXX flags but I can't remember that clearly. > shmxxx - SYSV compatibility? Yes. You will have to make sure that they are built into your kernel. GENERIC only includes SYSVSHM for some reason. > > Comments greatly appreciated. I don't think you will have much trouble :-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:46:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27459 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:46:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27450; Tue, 9 Feb 1999 11:46:45 -0800 (PST) (envelope-from dfr@nlsystems.com.demon.co.uk) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id TAA12209; Tue, 9 Feb 1999 19:45:04 GMT (envelope-from dfr@nlsystems.com.demon.co.uk) X-Authentication-Warning: herring.nlsystems.com: dfr owned process doing -bs Date: Tue, 9 Feb 1999 19:45:04 +0000 (GMT) From: Doug Rabson X-Sender: dfr@localhost To: Mike Smith cc: Julian Elischer , Dag-Erling Smorgrav , Eivind Eklund , Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-Reply-To: <199902091915.LAA04227@dingo.cdrom.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 Tue, 9 Feb 1999, Mike Smith wrote: > > someone said thay had code already.. > > was it warner? or maybe one of the Johns. > > Doug Rabson, IIRC. I have some code. I would like to commit it but I haven't managed to find a reviewer yet (not that I have pushed that hard). Considering what happened to the last guy that tried to change sysctl, I'm not going to commit it without a review. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 11:54:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28382 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 11:54:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28375 for ; Tue, 9 Feb 1999 11:54:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA05500; Tue, 9 Feb 1999 11:45:38 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdPE5497; Tue Feb 9 19:45:29 1999 Date: Tue, 9 Feb 1999 11:45:23 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: 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 in line 1248, subtract 2 from buf_size as well 1245 m0->m_pkthdr.rcvif = &sc->arpcom.ac_if; 1246 m0->m_pkthdr.len = ByteCount; 1247 m0->m_len = 0; 1248 m0->m_data += 2; 1249 th = mtod(m0, struct iso88025_header *); in 1255 you overwrite what you just calculated the line before.. have you already set up the variables used? (looks like you have..) ah it's a 3 way min() use a MIN macro please.. #define MIN(A,B) (((A) < (B)) ? (A) : (B)) length = MIN( frame_len, MIN( (RX_BUFFER_LEN - frag_offset), (mbuf_size - mbuf_offset)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 12:06:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29921 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 12:06:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29913 for ; Tue, 9 Feb 1999 12:06:36 -0800 (PST) (envelope-from dfr@nlsystems.com.demon.co.uk) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id UAA12261 for ; Tue, 9 Feb 1999 20:06:31 GMT (envelope-from dfr@nlsystems.com.demon.co.uk) X-Authentication-Warning: herring.nlsystems.com: dfr owned process doing -bs Date: Tue, 9 Feb 1999 20:06:31 +0000 (GMT) From: Doug Rabson X-Sender: dfr@localhost To: hackers@FreeBSD.ORG Subject: Lost mail 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 My main machine lost a drive at the weekend and I managed to lose my INBOX :-(. If anyone has sent me mail at all since Sunday or is waiting for me to reply to mail sent before then, could you please re-send it, thanks. Bah. To think I was looking at tape drives just a couple of weeks ago... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 12:28:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02423 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 12:28:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02414 for ; Tue, 9 Feb 1999 12:28:26 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id PAA00824; Tue, 9 Feb 1999 15:18:26 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 15:18:26 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-519715650-918591506=:14147" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-519715650-918591506=:14147 Content-Type: TEXT/PLAIN; charset=US-ASCII Oops, too much buffer size math, I should add the following between 1248 & 1249: mbuf_size -= 2; I guess that could explain the panic. I wonder why I don't see it with smaller mtu's? I guess I probably wrote off the end of one mbuf into the beggining of a mbuf cluster and ate the free list pointer. Yes, consider me suitably embarrased, I was in a hurry when I globbed that 3-way min together. Thanks for pointing out my math error! I am not very happy with all of that code to begin with, do you have any suggestions on how to make it more elegant? I do intend at some point to try just linking the raw receive buffers to m_ext and setting the free routine to a routine in the driver to avoid the unnecesary copies. Heres a new cut. Larry Lile lile@stdio.com On Tue, 9 Feb 1999, Julian Elischer wrote: > > > > > in line 1248, > subtract 2 from buf_size as well > > 1245 m0->m_pkthdr.rcvif = &sc->arpcom.ac_if; > 1246 m0->m_pkthdr.len = ByteCount; > 1247 m0->m_len = 0; > 1248 m0->m_data += 2; > 1249 th = mtod(m0, struct iso88025_header *); > > > in 1255 you overwrite what you just calculated the line before.. > have you already set up the variables used? > (looks like you have..) > ah it's a 3 way min() > > use a MIN macro please.. > #define MIN(A,B) (((A) < (B)) ? (A) : (B)) > length = MIN( frame_len, > MIN( (RX_BUFFER_LEN - frag_offset), > (mbuf_size - mbuf_offset)) > --0-519715650-918591506=:14147 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_oltr.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="if_oltr.c" LyogDQogKiBDb3B5cmlnaHQgKGMpIDE5OTgsIExhcnJ5IExpbGUNCiAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQogKg0KICogRm9yIGxhdGVzdCBzb3VyY2Vz IGFuZCBpbmZvcm1hdGlvbiBvbiB0aGlzIGRyaXZlciwgcGxlYXNlDQogKiBn byB0byBodHRwOi8vYW5hcmNoeS5zdGRpby5jb20uDQogKg0KICogUXVlc3Rp b25zLCBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBzaG91bGQgYmUgZGlyZWN0 ZWQgdG8NCiAqIExhcnJ5IExpbGUgPGxpbGVAc3RkaW8uY29tPi4NCiAqDQog KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5 IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0 aW9ucw0KICogYXJlIG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQog KiAgICBub3RpY2UgdW5tb2RpZmllZCwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMsIGFuZCB0aGUgZm9sbG93aW5nDQogKiAgICBkaXNjbGFpbWVyLg0KICog Mi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9k dWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbiB0aGUNCiAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1h dGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uDQogKg0K ICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFO RCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORA0KICogQU5ZIEVYUFJFU1Mg T1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFDQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RQ0KICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUNCiAqIEZPUiBBTlkg RElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBM QVJZLCBPUiBDT05TRVFVRU5USUFMDQogKiBEQU1BR0VTIChJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVU RSBHT09EUw0KICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBP UiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pDQogKiBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdI RVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVA0KICogTElBQklMSVRZLCBPUiBU T1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWQ0KICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZU V0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRg0K ICogU1VDSCBEQU1BR0UuDQogKg0KICogJElkOiBpZl9vbHRyLmMsdiAxLjE1 IDE5OTkvMDIvMDggMjM6Mzc6NDUgbGlsZSBFeHAgbGlsZSAkDQogKi8NCg0K DQojaW5jbHVkZSAicGNpLmgiDQojaW5jbHVkZSAib2x0ci5oIg0KI2luY2x1 ZGUgIm9wdF9pbmV0LmgiDQojaW5jbHVkZSAiYnBmaWx0ZXIuaCINCg0KI2lm IChOT0xUUiArIE5QQ0kpID4gMA0KDQovKiNkZWZpbmUgVFJsbGRJbmxpbmVJ TyovDQoNCiNkZWZpbmUgSVNBX0FEQVBURVJTICAoT0NfMzExNSB8IE9DXzMx MTcgfCBPQ18zMTE4KQ0KI2RlZmluZSBQQ0lfQURBUFRFUlMgIChPQ18zMTMz IHwgT0NfMzEzNiB8IE9DXzMxMzcgfCBcDQogICAgICAgICAgICAgICAgICAg ICAgIE9DXzMxMzkgfCBPQ18zMTQwIHwgT0NfMzE0MSB8IFwNCiAgICAgICAg ICAgICAgICAgICAgICAgT0NfMzI1MCB8IE9DXzM1NDAgKQ0KDQojZGVmaW5l IFBDSV9WRU5ET1JfT0xJQ09NIDB4MTA4RA0KDQpjaGFyICpBZGFwdGVyTmFt ZVtdID0gew0KICAgLyogIDAgKi8gIk9saWNvbSBYVCBBZGFwdGVyIFt1bnN1 cHBvcnRlZF0iLA0KICAgLyogIDEgKi8gIk9saWNvbSBPQy0zMTE1IiwNCiAg IC8qICAyICovICJPbGljb20gSVNBIDE2LzQgQWRhcHRlciAoT0MtMzExNyki LA0KICAgLyogIDMgKi8gIk9saWNvbSBJU0EgMTYvNCBBZGFwdGVyIChPQy0z MTE4KSIsDQogICAvKiAgNCAqLyAiT2xpY29tIE1DQSAxNi80IEFkYXB0ZXIg KE9DLTMxMjkpIFt1bnN1cHBvcnRlZF0iLA0KICAgLyogIDUgKi8gIk9saWNv bSBNQ0EgMTYvNCBBZGFwdGVyIChPQy0zMTI5KSBbdW5zdXBwb3J0ZWRdIiwN CiAgIC8qICA2ICovICJPbGljb20gTUNBIDE2LzQgQWRhcHRlciAoT0MtMzEy OSkgW3Vuc3VwcG9ydGVkXSIsDQogICAvKiAgNyAqLyAiT2xpY29tIEVJU0Eg MTYvNCBBZGFwdGVyIChPQy0zMTMzKSIsDQogICAvKiAgOCAqLyAiT2xpY29t IEVJU0EgMTYvNCBBZGFwdGVyIChPQy0zMTMzKSIsDQogICAvKiAgOSAqLyAi T2xpY29tIEVJU0EgMTYvNCBTZXJ2ZXIgQWRhcHRlciAoT0MtMzEzNSkiLA0K ICAgLyogMTAgKi8gIk9saWNvbSBQQ0kgMTYvNCBBZGFwdGVyIChPQy0zMTM2 KSIsDQogICAvKiAxMSAqLyAiT2xpY29tIFBDSSAxNi80IEFkYXB0ZXIgKE9D LTMxMzYpIiwNCiAgIC8qIDEyICovICJPbGljb20gUENJL0lJIDE2LzQgQWRh cHRlciAoT0MtMzEzNykiLA0KICAgLyogMTMgKi8gIk9saWNvbSBQQ0kgMTYv NCBBZGFwdGVyIChPQy0zMTM5KSIsDQogICAvKiAxNCAqLyAiT2xpY29tIFJh cGlkRmlyZSAzMTQwIDE2LzQgUENJIEFkYXB0ZXIgKE9DLTMxNDApIiwNCiAg IC8qIDE1ICovICJPbGljb20gUmFwaWRGaXJlIDMxNDEgRmliZXIgQWRhcHRl ciAoT0MtMzE0MSkiLA0KICAgLyogMTYgKi8gIk9saWNvbSBQQ01DSUEgMTYv NCBBZGFwdGVyIChPQy0zMjIwKSBbdW5zdXBwb3J0ZWRdIiwNCiAgIC8qIDE3 ICovICJPbGljb20gUENNQ0lBIDE2LzQgQWRhcHRlciAoT0MtMzEyMSwgT0Mt MzIzMCwgT0MtMzIzMikgW3Vuc3VwcG9ydGVkXSIsDQogICAvKiAxOCAqLyAi T2xpY29tIFBDTUNJQSAxNi80IEFkYXB0ZXIgKE9DLTMyNTApIiwNCiAgIC8q IDE5ICovICJPbGljb20gUmFwaWRGaXJlIDM1NDAgNC8xNi8xMDAgQWRhcHRl ciAoT0MtMzU0MCkiDQp9Ow0KDQojaW5jbHVkZSA8c3lzL3BhcmFtLmg+DQoj aW5jbHVkZSA8c3lzL3N5c3RtLmg+DQojaW5jbHVkZSA8c3lzL3Byb2MuaD4N CiNpbmNsdWRlIDxzeXMvc29ja2lvLmg+DQojaW5jbHVkZSA8c3lzL21hbGxv Yy5oPg0KI2luY2x1ZGUgPHN5cy9tYnVmLmg+DQojaW5jbHVkZSA8c3lzL3Nv Y2tldC5oPg0KI2luY2x1ZGUgPHN5cy9zeXNsb2cuaD4NCiNpbmNsdWRlIDxz eXMva2VybmVsLmg+DQojaW5jbHVkZSA8c3lzL2ludGVycnVwdC5oPg0KDQoj aW5jbHVkZSA8bmV0L2V0aGVybmV0Lmg+DQojaW5jbHVkZSA8bmV0L2lmLmg+ DQojaW5jbHVkZSA8bmV0L2lmX2FycC5oPg0KI2luY2x1ZGUgPG5ldC9pc284 ODAyNS5oPg0KI2luY2x1ZGUgPG5ldC9pZl9tZWRpYS5oPg0KDQojaWYgTkJQ RklMVEVSID4gMA0KI2luY2x1ZGUgPG5ldC9icGYuaD4NCiNlbmRpZg0KIA0K I2lmIE5QTlAgPiAwDQojaW5jbHVkZSA8aTM4Ni9pc2EvcG5wLmg+DQojZW5k aWYNCg0KI2luY2x1ZGUgPG1hY2hpbmUvY2xvY2suaD4NCiNpbmNsdWRlIDxt YWNoaW5lL21kX3Zhci5oPg0KI2luY2x1ZGUgPGkzODYvaXNhL2lzYV9kZXZp Y2UuaD4NCg0KI2lmIE5QQ0kgPiAwDQojaW5jbHVkZSA8cGNpL3BjaXZhci5o Pg0KI2luY2x1ZGUgPHBjaS9wY2lyZWcuaD4NCiNlbmRpZg0KDQojaWZuZGVm IFRSTExEX1NQRUVEX0FVVE8NCiNkZWZpbmUgVFJMTERfU1BFRURfQVVUTyAw DQojZW5kaWYNCg0KI2RlZmluZSBNSU4oQSxCKSAoKChBKSA8IChCKSkgPyAo QSkgOiAoQikpDQojZGVmaW5lIE1JTjMoQSxCLEMpIChNSU4oQSwgKE1JTihC LCBDKSkpKQ0KDQp2b2lkICpvbHRyX21hbGxvYyhzc2l6ZV90LCBUUmxsZEFk YXB0ZXJDb25maWdfdCAqKTsNCg0KLyoNCiAqIEdsdWUgZnVuY3Rpb25zIHBy b3RvdHlwZXMgZm9yIFBNVyBraXQgSU8NCiAqLw0KDQojaWZuZGVmIFRSbGxk SW5saW5lSU8NCnN0YXRpYyB2b2lkIERyaXZlck91dEJ5dGUgICAgICAgICAg IF9fUCgodW5zaWduZWQgc2hvcnQsIHVuc2lnbmVkIGNoYXIpKTsNCnN0YXRp YyB2b2lkIERyaXZlck91dFdvcmQgICAgICAgICAgIF9fUCgodW5zaWduZWQg c2hvcnQsIHVuc2lnbmVkIHNob3J0KSk7DQpzdGF0aWMgdm9pZCBEcml2ZXJP dXREd29yZCAgICAgICAgICBfX1AoKHVuc2lnbmVkIHNob3J0LCB1bnNpZ25l ZCBsb25nKSk7DQpzdGF0aWMgdm9pZCBEcml2ZXJSZXBPdXRCeXRlICAgICAg ICBfX1AoKHVuc2lnbmVkIHNob3J0LCB1bnNpZ25lZCBjaGFyICAqLCBpbnQp KTsNCnN0YXRpYyB2b2lkIERyaXZlclJlcE91dFdvcmQgICAgICAgIF9fUCgo dW5zaWduZWQgc2hvcnQsIHVuc2lnbmVkIHNob3J0ICosIGludCkpOw0Kc3Rh dGljIHZvaWQgRHJpdmVyUmVwT3V0RHdvcmQgICAgICAgX19QKCh1bnNpZ25l ZCBzaG9ydCwgdW5zaWduZWQgbG9uZyAgKiwgaW50KSk7DQpzdGF0aWMgdW5z aWduZWQgY2hhciAgRHJpdmVySW5CeXRlICBfX1AoKHVuc2lnbmVkIHNob3J0 KSk7DQpzdGF0aWMgdW5zaWduZWQgc2hvcnQgRHJpdmVySW5Xb3JkICBfX1Ao KHVuc2lnbmVkIHNob3J0KSk7DQpzdGF0aWMgdW5zaWduZWQgbG9uZyAgRHJp dmVySW5Ed29yZCBfX1AoKHVuc2lnbmVkIHNob3J0KSk7DQpzdGF0aWMgdm9p ZCBEcml2ZXJSZXBJbkJ5dGUgICAgICAgICBfX1AoKHVuc2lnbmVkIHNob3J0 LCB1bnNpZ25lZCBjaGFyICAqLCBpbnQpKTsNCnN0YXRpYyB2b2lkIERyaXZl clJlcEluV29yZCAgICAgICAgIF9fUCgodW5zaWduZWQgc2hvcnQsIHVuc2ln bmVkIHNob3J0ICosIGludCkpOw0Kc3RhdGljIHZvaWQgRHJpdmVyUmVwSW5E d29yZCAgICAgICAgX19QKCh1bnNpZ25lZCBzaG9ydCwgdW5zaWduZWQgbG9u ZyAgKiwgaW50KSk7DQojZW5kaWYgLypUUmxsZElubGluZUlPKi8NCnN0YXRp YyB2b2lkIERyaXZlclN1c3BlbmQgICAgICAgICAgICAgICAgX19QKCh1bnNp Z25lZCBzaG9ydCkpOw0Kc3RhdGljIHZvaWQgRHJpdmVyU3RhdHVzICAgICAg ICAgICAgICAgICBfX1AoKHZvaWQgKiwgVFJsbGRTdGF0dXNfdCAqKSk7DQpz dGF0aWMgdm9pZCBEcml2ZXJDbG9zZUNvbXBsZXRlZCAgICAgICAgIF9fUCgo dm9pZCAqKSk7DQpzdGF0aWMgdm9pZCBEcml2ZXJTdGF0aXN0aWNzICAgICAg ICAgICAgIF9fUCgodm9pZCAqLCBUUmxsZFN0YXRpc3RpY3NfdCAqKSk7DQpz dGF0aWMgdm9pZCBEcml2ZXJUcmFuc21pdEZyYW1lQ29tcGxldGVkIF9fUCgo dm9pZCAqLCB2b2lkICosIGludCkpOw0Kc3RhdGljIHZvaWQgRHJpdmVyUmVj ZWl2ZUZyYW1lQ29tcGxldGVkICBfX1AoKHZvaWQgKiwgaW50LCBpbnQsIHZv aWQgKiwgaW50KSk7DQoNCnR5cGVkZWYgc3RydWN0IHR4X2J1ZiB7DQogICAg aW50IGluZGV4Ow0KICAgIGNoYXIgKmJ1ZjsNCn0gdHhfYnVmX3Q7DQoNCnR5 cGVkZWYgc3RydWN0IHJ4X2J1ZiB7DQogICAgaW50ICAgICAgaW5kZXg7DQog ICAgY2hhciAgICAgKmJ1ZjsNCn0gcnhfYnVmX3Q7DQoNCiNpZm5kZWYgRVhU UkFfT0xUUg0KI2lmIE5QQ0kgPiAwDQojZGVmaW5lIEVYVFJBX09MVFIJOA0K I2Vsc2UgDQojZGVmaW5lIEVYVFJBX09MVFIJMA0KI2VuZGlmIC8qIE5QQ0kg Ki8NCiNlbmRpZiAvKiBFWFRSQV9PTFRSICovDQoNCiNpZm5kZWYgT0xUUl9Q Uk9NSVNDX01PREUNCiNkZWZpbmUgT0xUUl9QUk9NSVNDX01PREUgKFRSTExE X1BST01fTExDKQ0KI2VuZGlmDQoNCiNkZWZpbmUgQUxMX09QVElPTlMgKElG TV9UT0tfRVRSIHwgSUZNX1RPS19TUkNSVCB8IElGTV9UT0tfQUxMUiB8IElG TV9UT0tfRFRSIHwgSUZNX1RPS19DTEFTU0lDIHwgSUZNX1RPS19BVVRPKQ0K DQovKiBMaXN0IHNpemVzIE1VU1QgYmUgYSBwb3dlciBvZiAyICovDQojZGVm aW5lIFRYX0xJU1RfU0laRSAgICAxNg0KI2RlZmluZSBSWF9MSVNUX1NJWkUg ICAgMTYgDQojZGVmaW5lIFRYX0xJU1RfTUFTSyAgICAoVFhfTElTVF9TSVpF IC0gMSkNCiNkZWZpbmUgUlhfTElTVF9NQVNLICAgIChSWF9MSVNUX1NJWkUg LSAxKQ0KI2RlZmluZSBSWF9CVUZGRVJfTEVOICAgKDgqMTAyNCkNCiNkZWZp bmUgVFhfQlVGRkVSX0xFTiAgICg4KjEwMjQpDQoNCnN0cnVjdCBvbHRyX3Nv ZnRjIHsNCiAgICBzdHJ1Y3QgYXJwY29tIGFycGNvbTsNCiAgICBzdHJ1Y3Qg aWZtZWRpYSBpZm1lZGlhOw0KICAgIFRSbGxkQWRhcHRlckNvbmZpZ190ICpj b25maWc7DQogICAgVFJsbGRBZGFwdGVyX3QgKlRSbGxkQWRhcHRlcjsNCiAg ICBpbnQgdW5pdDsNCiAgICB1X3Nob3J0IFByb21pc2NNb2RlOw0KICAgIHVf c2hvcnQgQWRhcHRlck1vZGU7DQogICAgaW50IGh3X3N0YXRlOw0KI2RlZmlu ZSBIV19VTktOT1dOICAgICAgMCAgLyogaW5pdGlhbC9hYnNlbnQgc3RhdGUg Ki8NCiNkZWZpbmUgSFdfRk9VTkQgICAgICAgIDEgIC8qIGZvdW5kLCBub3Qg aW5pdGlhbGl6ZWQgKi8NCiNkZWZpbmUgSFdfQkFEICAgICAgICAgIDIgIC8q IGZhdGFsIGVycm9yICovDQojZGVmaW5lIEhXX0ZBSUxFRCAgICAgICAzICAv KiBjbG9zZWQgZWcuIGJ5IHJlbW92ZSwgYWxsb3cgbWFudWFsIHJlb3BlbiAq Lw0KI2RlZmluZSBIV19MT0FESU5HICAgICAgNA0KI2RlZmluZSBIV19DTE9T SU5HICAgICAgNQ0KI2RlZmluZSBIV19DTE9TSU5HMiAgICAgNg0KI2RlZmlu ZSBIV19DTE9TRUQgICAgICAgNw0KI2RlZmluZSBIV19PUEVOSU5HICAgICAg OA0KI2RlZmluZSBIV19PUEVOICAgICAgICAgOQ0KI2RlZmluZSBIV19FUlJP UiAgICAgICAgMTAgLyogdGVtcG9yYXJ5IGVycm9yICovDQoNCiAgICB1X2xv bmcgR3JvdXBBZGRyZXNzOw0KICAgIHVfbG9uZyBGdW5jdGlvbmFsQWRkcmVz czsNCiAgICBpbnQgcG9sbF9hZGFwdGVyOyANCg0KICAgIGludCB0eF9uZXh0 Ow0KICAgIGludCB0eF9hdmFpbDsNCiAgICB0eF9idWZfdCB0eF9idWZmZXJb VFhfTElTVF9TSVpFXTsNCg0KICAgIGludCByeF9uZXh0Ow0KICAgIGludCBy eF9hdmFpbDsNCiAgICByeF9idWZfdCByeF9idWZmZXJbUlhfTElTVF9TSVpF XTsNCg0KICAgIHN0cnVjdCBjYWxsb3V0X2hhbmRsZSBvbHRyX2NoOw0KICAg IHN0cnVjdCBjYWxsb3V0X2hhbmRsZSBwb2xsX2NoOw0KDQp9Ow0KDQpzdGF0 aWMgc3RydWN0IG9sdHJfc29mdGMgb2x0cl9zb2Z0Y1tOT0xUUiArIEVYVFJB X09MVFJdOw0KDQovKg0KICogRHJpdmVyIGZ1bmN0aW9uIHByb3RvdHlwZXMN CiAqLw0KDQpzdGF0aWMgaW50ICBvbHRyX3Byb2JlICAgX19QKChzdHJ1Y3Qg aXNhX2RldmljZSAqKSk7DQpzdGF0aWMgaW50ICBvbHRyX2F0dGFjaCAgX19Q KChzdHJ1Y3QgaXNhX2RldmljZSAqKSk7ICANCnN0YXRpYyB2b2lkIG9sdHJf aW5pdCAgICBfX1AoKHN0cnVjdCBvbHRyX3NvZnRjICopKTsNCnN0YXRpYyB2 b2lkIG9sdHJfaW50ciAgICBfX1AoKGludCkpOw0Kc3RhdGljIHZvaWQgb2x0 cl9zdGFydCAgIF9fUCgoc3RydWN0IGlmbmV0ICopKTsNCnN0YXRpYyB2b2lk IG9sdHJfc3RvcCAgICBfX1AoKHN0cnVjdCBvbHRyX3NvZnRjICopKTsNCnN0 YXRpYyBpbnQgIG9sdHJfaW9jdGwgICBfX1AoKHN0cnVjdCBpZm5ldCAqLCB1 X2xvbmcsIGNhZGRyX3QpKTsNCg0Kc3RhdGljIGludCBvbHRyX2F0dGFjaF9j b21tb24gICBfX1AoKHN0cnVjdCBvbHRyX3NvZnRjICopKTsNCg0Kdm9pZCBv bHRyX3RpbWVvdXQgX19QKCh2b2lkICopKTsNCnZvaWQgYWRhcHRlcl9wb2xs IF9fUCgodm9pZCAqKSk7DQoNCnN0cnVjdCBpc2FfZHJpdmVyIG9sdHJkcml2 ZXIgPSB7DQogICAgb2x0cl9wcm9iZSwNCiAgICBvbHRyX2F0dGFjaCwNCiAg ICAib2x0ciIsDQogICAgMA0KfTsNCg0KaW50IGlzYV9jYXJkcyA9IDA7DQoN CiNpZiBOUENJID4gMA0Kc3RhdGljIHVfbG9uZyBvbHRyX2NvdW50ID0gTk9M VFI7DQpzdGF0aWMgY29uc3QgY2hhciAqb2x0cl9wY2lfcHJvYmUJX19QKChw Y2ljaV90LCBwY2lkaV90KSk7DQpzdGF0aWMgdm9pZCBvbHRyX3BjaV9hdHRh Y2gJCV9fUCgocGNpY2lfdCwgaW50KSk7DQpzdGF0aWMgdm9pZCBvbHRyX3Bj aV9pbnRyICAgIAkJX19QKCh2b2lkICopKTsNCnN0YXRpYyB2b2lkIG9sdHJf cGNpX3NodXRkb3duCQlfX1AoKGludCwgdm9pZCAqKSk7DQoNCnN0YXRpYyBz dHJ1Y3QgcGNpX2RldmljZSBvbHRyX2RldmljZSA9IHsNCiAgICAib2x0ciIs DQogICAgb2x0cl9wY2lfcHJvYmUsDQogICAgb2x0cl9wY2lfYXR0YWNoLA0K ICAgICZvbHRyX2NvdW50LA0KICAgIE5VTEwNCn07DQoNCkRBVEFfU0VUKHBj aWRldmljZV9zZXQsIG9sdHJfZGV2aWNlKTsNCmludCBwY2lfY2FyZHMgPSAw Ow0KI2VuZGlmIC8qIE5QQ0kgKi8NCg0Kc3RhdGljIGludCAgb2x0cl9pZm1l ZGlhX3VwZAlfX1AoKHN0cnVjdCBpZm5ldCAqKSk7DQpzdGF0aWMgdm9pZCBv bHRyX2lmbWVkaWFfc3RzICAgIF9fUCgoc3RydWN0IGlmbmV0ICosIHN0cnVj dCBpZm1lZGlhcmVxICopKTsNCg0Kc3RhdGljIFRSbGxkRHJpdmVyX3Qgb2x0 ckxsZERyaXZlciA9IHsNCiAgICBUUkxMRF9WRVJTSU9OLA0KI2lmbmRlZiBU UmxsZElubGluZUlPDQogICAgRHJpdmVyT3V0Qnl0ZSwNCiAgICBEcml2ZXJP dXRXb3JkLA0KICAgIERyaXZlck91dER3b3JkLA0KICAgIERyaXZlclJlcE91 dEJ5dGUsDQogICAgRHJpdmVyUmVwT3V0V29yZCwNCiAgICBEcml2ZXJSZXBP dXREd29yZCwNCiAgICBEcml2ZXJJbkJ5dGUsDQogICAgRHJpdmVySW5Xb3Jk LA0KICAgIERyaXZlckluRHdvcmQsDQogICAgRHJpdmVyUmVwSW5CeXRlLA0K ICAgIERyaXZlclJlcEluV29yZCwNCiAgICBEcml2ZXJSZXBJbkR3b3JkLA0K I2VuZGlmIC8qVFJsbGRJbmxpbmVJTyovDQogICAgRHJpdmVyU3VzcGVuZCwN CiAgICBEcml2ZXJTdGF0dXMsDQogICAgRHJpdmVyQ2xvc2VDb21wbGV0ZWQs DQogICAgRHJpdmVyU3RhdGlzdGljcywNCiAgICBEcml2ZXJUcmFuc21pdEZy YW1lQ29tcGxldGVkLA0KICAgIERyaXZlclJlY2VpdmVGcmFtZUNvbXBsZXRl ZCwNCn07DQoNClRSbGxkQWRhcHRlckNvbmZpZ190IG9sdHJfY29uZmlnW05P TFRSICsgRVhUUkFfT0xUUl07DQoNCnZvaWQgKg0Kb2x0cl9tYWxsb2MoU2l6 ZSwgQWRhcHRlcikNCiAgICBzc2l6ZV90IFNpemU7DQogICAgVFJsbGRBZGFw dGVyQ29uZmlnX3QgKkFkYXB0ZXI7DQp7DQoNCiAgICAvKiBJZiB0aGUgYWRh cHRlciBuZWVkcyBtZW1vcnkgYmVsb3cgMTZNIGZvciBETUEgdGhlbiB1c2Ug Y29udGlnbWFsbG9jICovDQogICAgaWYgKEFkYXB0ZXItPm1vZGUgJiBUUkxM RF9NT0RFXzE2TSkgIC8qIEFkYXB0ZXIgdXNpbmcgSVNBIERNQSBidWZmZXIg YmVsb3cgMTZNICovDQogICAgICAgIHJldHVybihjb250aWdtYWxsb2MoU2l6 ZSwgTV9ERVZCVUYsIE1fTk9XQUlULCAwdWwsIDB4ZmZmZmZmdWwsIDF1bCwg MHgxMDAwMHVsKSk7DQogICAgZWxzZQ0KICAgICAgICByZXR1cm4obWFsbG9j KFNpemUsIE1fREVWQlVGLCBNX05PV0FJVCkpOw0KfQ0KICAgIA0KLyoNCiAq IERyaXZlciBGdW5jdGlvbnMgDQogKi8NCg0Kc3RhdGljIGludA0Kb2x0cl9w cm9iZShpcykNCiAgICBzdHJ1Y3QgaXNhX2RldmljZSAqaXM7DQp7DQogICAg c3RhdGljIGludCBmaW5kX2NvbXBsZXRlZCA9IDAsIGFzc2lnbmVkW05PTFRS XTsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1tp cy0+aWRfdW5pdF07DQogICAgaW50IGk7DQoNCiAgICBwcmludGYoIm9sdHIl ZDogb2x0cl9wcm9iZVxuIiwgaXMtPmlkX3VuaXQpOw0KDQogICAgLyogTWFr ZSBsaWZlIGVhc3ksIHVzZSB0aGUgT2xpY29tIHN1cHBsaWVkIGZpbmQgZnVu Y3Rpb24gb24gdGhlIGZpcnN0IHByb2JlDQogICAgICogdG8gcHJvYmUgYWxs IG9mIHRoZSBJU0EgYWRhcHRlcnMuICBUaGVuIGdpdmUgdGhlbSB0byBlYWNo IHVuaXQgYXMgcmVxdWVzdGVkLg0KICAgICAqIFRyeSB0byBtYXRjaCB0aGUg YWRhcHRlcnMgdG8gdW5pdHMgYmFzZWQgb24gdGhlIGlvYmFzZSwgYnV0IGlm IGlvYmFzZT8gdGhlbg0KICAgICAqIGp1c3QgZ2l2ZSBvdXQgdGhlIG5leHQg YXZhaWxhYmxlIGFkYXB0ZXIuDQogICAgICovDQogICAgaWYgKCFmaW5kX2Nv bXBsZXRlZCkgew0KICAgICAgICBpc2FfY2FyZHMgPSBUUmxsZEZpbmQoJm9s dHJMbGREcml2ZXIsICZvbHRyX2NvbmZpZ1swXSwgSVNBX0FEQVBURVJTLCBO T0xUUik7DQogICAgICAgIC8qZm9yIChpID0gMDsgaSA8IGlzYV9jYXJkczsg aSsrKSB7DQogICAgICAgICAgICBwcmludGYoIlRSbGxkRmluZDogY2FyZCAl ZCAtICVzIE1BQyAlNkRcbiIsIGkgKyAxLCBBZGFwdGVyTmFtZVtvbHRyX2Nv bmZpZ1tpXS50eXBlXSwgb2x0cl9jb25maWdbaV0ubWFjYWRkcmVzcywgIjoi KTsNCiAgICAgICAgfSovDQogICAgICAgIGZvciAoaSA9IDA7IGkgPCBOT0xU UjsgaSsrKQ0KICAgICAgICAgICAgYXNzaWduZWRbaV0gPSAwOw0KICAgICAg ICBmaW5kX2NvbXBsZXRlZCA9IDE7DQogICAgfQ0KDQogICAgc2MtPnVuaXQg PSBpcy0+aWRfdW5pdDsNCiAgICBzYy0+aHdfc3RhdGUgPSBIV19VTktOT1dO Ow0KDQogICAgaWYgKGZpbmRfY29tcGxldGVkICYmICgoaXNhX2NhcmRzID09 IDApIHx8IChpcy0+aWRfdW5pdCA+IGlzYV9jYXJkcykpKSANCiAgICAgICAg cmV0dXJuKDApOw0KDQogICAgaWYgKCgoaXMtPmlkX2lvYmFzZSA8IDB4YTAw KSB8fCAoaXMtPmlkX2lvYmFzZSA+IDB4YmUwKSkgJiYgKGlzLT5pZF9pb2Jh c2UgIT0gMHhmZmZmZmZmZikpIHsNCiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6 IHBvcnQgYWRkcmVzcyBpbXBvc3NpYmxlICgweCVYKVxuIiwgaXMtPmlkX3Vu aXQsIGlzLT5pZF9pb2Jhc2UpOw0KICAgICAgICByZXR1cm4oMCk7DQogICAg fQ0KDQogICAgLyogQXV0byBhc3NpZ24gbG93ZXN0IGF2YWlsYWJsZSBjYXJk IG5vdCBhbHJlYWR5IGluIHVzZSAqLw0KICAgIGlmIChpcy0+aWRfaW9iYXNl ID09IDB4ZmZmZmZmZmYpIHsNCiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IGF1 dG8gYXNzaWduaW5nIGNhcmQuXG4iLCBpcy0+aWRfdW5pdCk7DQogICAgICAg IGZvciAoaSA9IDA7IGFzc2lnbmVkW2ldOyBpKyspOw0KICAgICAgICBhc3Np Z25lZFtpXSA9IDE7DQogICAgICAgIHNjLT5jb25maWcgPSAmb2x0cl9jb25m aWdbaV07DQogICAgICAgIGlzLT5pZF9pb2Jhc2UgPSBzYy0+Y29uZmlnLT5p b2Jhc2UwOyAgICAgICAgICAgICAgICAgICAgICAgIC8qIENsYWltIG91ciBw b3J0IHNwYWNlICovDQogICAgICAgIGlmICghaXMtPmlkX2lycSkgDQogICAg ICAgICAgICBpcy0+aWRfaXJxID0gKDEgPDwgc2MtPmNvbmZpZy0+aW50ZXJy dXB0bGV2ZWwpOyAgICAgICAgIC8qIENsYWltIG91ciBpbnRlcnJ1cHQgKi8N CiAgICAgICAgaXMtPmlkX2ludHIgPSAoaW50aGFuZDJfdCAqKW9sdHJfaW50 cjsNCiAgICAgICAgcmVnaXN0ZXJfaW50cihmZnMoaXMtPmlkX2lycSkgLSAx LCBpcy0+aWRfaWQsIGlzLT5pZF9yaV9mbGFncywgaXMtPmlkX2ludHIsICZu ZXRfaW1hc2ssIGlzLT5pZF91bml0KTsNCiAgICAgICAgaWYgKChpcy0+aWRf ZHJxID09IDB4ZmZmZmZmZmYpICYmIChzYy0+Y29uZmlnLT5kbWFsZXZlbCAh PSBUUkxMRF9ETUFfUElPKSkNCiAgICAgICAgICAgIGlzLT5pZF9kcnEgPSBz Yy0+Y29uZmlnLT5kbWFsZXZlbDsgICAgICAgICAgICAgICAgICAgICAgLyog Q2xhaW0gb3VyIGRtYSBjaGFubmVsICovDQogICAgICAgIHByaW50Zigib2x0 ciVkOiA8JXM+IFslNkRdXG4iLCBpcy0+aWRfdW5pdCwgQWRhcHRlck5hbWVb c2MtPmNvbmZpZy0+dHlwZV0sIHNjLT5jb25maWctPm1hY2FkZHJlc3MsICI6 Iik7DQogICAgICAgIHNjLT5od19zdGF0ZSA9IEhXX0ZPVU5EOw0KICAgICAg ICByZXR1cm4oMSk7DQogICAgfSBlbHNlIHsNCiAgICAvKiBBc3NpZ24gYmFz ZWQgb24gaW9iYXNlIGFkZHJlc3MgcHJvdmlkZWQgaW4ga2VybmVsIGNvbmZp ZyAqLw0KICAgICAgICBmb3IgKGkgPSAwOyBpIDwgTk9MVFI7IGkrKykgew0K ICAgICAgICAgICAgaWYgKGlzLT5pZF9pb2Jhc2UgPT0gb2x0cl9jb25maWdb aV0uaW9iYXNlMCkgew0KICAgICAgICAgICAgICAgIGlmIChhc3NpZ25lZFtp XSkgew0KICAgICAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIlZDogYWRh cHRlciAoMHglWCkgYWxyZWFkeSBhc3NpZ25lZC5cbiIsIGlzLT5pZF91bml0 LCBpcy0+aWRfaW9iYXNlKTsNCiAgICAgICAgICAgICAgICAgICAgcmV0dXJu KDApOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICBhc3Np Z25lZFtpXSA9IDE7DQogICAgICAgICAgICAgICAgc2MtPmNvbmZpZyA9ICZv bHRyX2NvbmZpZ1tpXTsNCiAgICAgICAgICAgICAgICBpZiAoaXMtPmlkX2ly cSA9PSAwKQ0KICAgICAgICAgICAgICAgICAgICBpcy0+aWRfaXJxID0gKDEg PDwgc2MtPmNvbmZpZy0+aW50ZXJydXB0bGV2ZWwpOyAgICAgICAgIC8qIENs YWltIG91ciBpbnRlcnJ1cHQgKi8NCiAgICAgICAgICAgICAgICBpcy0+aWRf aW50ciA9IChpbnRoYW5kMl90ICopb2x0cl9pbnRyOw0KICAgICAgICAgICAg ICAgIHJlZ2lzdGVyX2ludHIoZmZzKGlzLT5pZF9pcnEpIC0gMSwgaXMtPmlk X2lkLCBpcy0+aWRfcmlfZmxhZ3MsIGlzLT5pZF9pbnRyLCAmbmV0X2ltYXNr LCBpcy0+aWRfdW5pdCk7DQogICAgICAgICAgICAgICAgaWYgKChpcy0+aWRf ZHJxID09IDB4ZmZmZmZmZmYpICYmIChzYy0+Y29uZmlnLT5kbWFsZXZlbCAh PSBUUkxMRF9ETUFfUElPKSkNCiAgICAgICAgICAgICAgICAgICAgaXMtPmlk X2RycSA9IHNjLT5jb25maWctPmRtYWxldmVsOyAgICAgICAgICAgICAgICAg ICAgICAvKiBDbGFpbSBvdXIgZG1hIGNoYW5uZWwgKi8NCiAgICAgICAgICAg ICAgICBwcmludGYoIm9sdHIlZDogPCVzPiBbJTZEXVxuIiwgaXMtPmlkX3Vu aXQsIEFkYXB0ZXJOYW1lW3NjLT5jb25maWctPnR5cGVdLCBzYy0+Y29uZmln LT5tYWNhZGRyZXNzLCAiOiIpOw0KICAgICAgICAgICAgICAgIHNjLT5od19z dGF0ZSA9IEhXX0ZPVU5EOw0KICAgICAgICAgICAgICAgIHJldHVybigxKTsN CiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgIH0NCiAgICByZXR1cm4o MCk7IC8qIENhcmQgd2FzIG5vdCBmb3VuZCAqLw0KfQ0KDQojaWYgTlBDSSA+ IDANCnN0YXRpYyBjb25zdCBjaGFyICoNCm9sdHJfcGNpX3Byb2JlKGNvbmZp Z19pZCwgZGV2aWNlX2lkKQ0KICAgIHBjaWNpX3QgY29uZmlnX2lkOw0KICAg IHBjaWRpX3QgZGV2aWNlX2lkOw0Kew0KICAgIHVfY2hhciBQQ0lDb25maWd1 cmF0aW9uU3BhY2VbNjRdOw0KICAgIHVfbG9uZyBjb21tYW5kOw0KICAgIGlu dCBpLCBqLCByYzsNCg0KICAgIHByaW50Zigib2x0cjogb2x0cl9wY2lfcHJv YmVcbiIpOw0KDQogICAgaiA9IE5PTFRSICsgcGNpX2NhcmRzOw0KDQogICAg aWYgKHBjaV9jYXJkcyA9PSBFWFRSQV9PTFRSKQ0KICAgICAgICByZXR1cm4o TlVMTCk7DQoNCiAgICBpZiAoKChkZXZpY2VfaWQgJiAweGZmZmYpID09IFBD SV9WRU5ET1JfT0xJQ09NKSAmJiANCiAgICAgICAgICAoKCgoZGV2aWNlX2lk ID4+IDE2KSAmIDB4ZmZmZikgPT0gMHgwMDAxKSB8fCANCiAgICAgICAgICAg KCgoZGV2aWNlX2lkID4+IDE2KSAmIDB4ZmZmZikgPT0gMHgwMDA0KSB8fCAN CiAgICAgICAgICAgKCgoZGV2aWNlX2lkID4+IDE2KSAmIDB4ZmZmZikgPT0g MHgwMDA1KSB8fCANCiAgICAgICAgICAgKCgoZGV2aWNlX2lkID4+IDE2KSAm IDB4ZmZmZikgPT0gMHgwMDA3KSB8fCANCiAgICAgICAgICAgKCgoZGV2aWNl X2lkID4+IDE2KSAmIDB4ZmZmZikgPT0gMHgwMDA4KSkpIHsNCg0KICAgICAg ICBmb3IgKGkgPSAwOyBpIDwgNjQ7IGkrKykNCiAgICAgICAgICAgIFBDSUNv bmZpZ3VyYXRpb25TcGFjZVtpXSA9IHBjaV9jZmdyZWFkKGNvbmZpZ19pZCwg aSwgLypieXRlcyovMSk7DQoNCiAgICAgICAgcmMgPSBUUmxsZFBDSUNvbmZp Zygmb2x0ckxsZERyaXZlciwgJm9sdHJfY29uZmlnW2pdLCBQQ0lDb25maWd1 cmF0aW9uU3BhY2UpOw0KDQogICAgICAgIGlmICgocmMgPT0gVFJMTERfUENJ Q09ORklHX09LKSB8fCAocmMgPT0gVFJMTERfUENJQ09ORklHX1NFVF9DT01N QU5EKSkgew0KICAgICAgICAgICAgaWYgKHJjID09IFRSTExEX1BDSUNPTkZJ R19TRVRfQ09NTUFORCkgew0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0 cjogc2V0dGluZyBidXMtbWFzdGVyIG1vZGVcbiIpOw0KICAgICAgICAgICAg ICAgIGNvbW1hbmQgPSBwY2lfY29uZl9yZWFkKGNvbmZpZ19pZCwgUENJUl9D T01NQU5EKTsNCiAgICAgICAgICAgICAgICBwY2lfY29uZl93cml0ZShjb25m aWdfaWQsIFBDSVJfQ09NTUFORCwgKGNvbW1hbmQgfCBQQ0lNX0NNRF9CVVNN QVNURVJFTikpOw0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgcGNpX2Nh cmRzKys7DQogICAgICAgICAgICByZXR1cm4gKEFkYXB0ZXJOYW1lW29sdHJf Y29uZmlnW2pdLnR5cGVdKTsNCiAgICAgICAgfSBlbHNlIHsNCiAgICAgICAg ICAgIGlmIChyYyA9PSBUUkxMRF9QQ0lDT05GSUdfRkFJTCkNCiAgICAgICAg ICAgICAgICBwcmludGYoIm9sdHI6IFRSbGxkUENJQ29uZmlnIGZhaWxlZCFc biIpOw0KICAgICAgICAgICAgaWYgKHJjID09IFRSTExEX1BDSUNPTkZJR19W RVJTSU9OKQ0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0cjogd3Jvbmcg TExEIHZlcnNpb25cbiIpOw0KICAgICAgICB9DQogICAgfQ0KICAgIHJldHVy bihOVUxMKTsNCn0NCiNlbmRpZiAvKiBOUENJICovDQoNCnN0YXRpYyBpbnQN Cm9sdHJfYXR0YWNoKGlzKQ0KICAgIHN0cnVjdCBpc2FfZGV2aWNlICppczsN CnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1tp cy0+aWRfdW5pdF07DQogICAgaW50IHJjOw0KDQogICAgc2MtPnVuaXQgPSBp cy0+aWRfdW5pdDsNCg0KICAgIGlmICghb2x0cl9hdHRhY2hfY29tbW9uKHNj KSkNCiAgICAgICAgcmV0dXJuKDApOw0KDQogICAgLyogSWYgdGhlIGtlcm5l bCBjb25maWcgZG9lcyBub3QgbWF0Y2ggdGhlIGN1cnJlbnQgY2FyZCBjb25m aWd1cmF0aW9uIHRoZW4NCiAgICAgKiBhZGp1c3QgdGhlIGNhcmQgc2V0dGlu Z3MgdG8gbWF0Y2ggdGhlIGtlcm5lbC4NCiAgICAgKi8NCiAgICBpZiAoKGZm cyhpcy0+aWRfaXJxKSAtIDEpICE9IHNjLT5jb25maWctPmludGVycnVwdGxl dmVsKSB7DQogICAgICAgIHJjID0gVFJsbGRTZXRJbnRlcnJ1cHQoc2MtPlRS bGxkQWRhcHRlciwgaXMtPmlkX2lycSk7IA0KICAgICAgICBpZiAocmMgIT0g VFJMTERfQ09ORklHX09LKSB7ICANCiAgICAgICAgICAgIHByaW50Zigib2x0 ciVkOiBVbmFibGUgdG8gY2hhbmdlIGFkYXB0ZXIgaW50ZXJydXB0IGxldmVs ICgleClcbiIsIHNjLT51bml0LCByYyk7DQogICAgICAgICAgICByZXR1cm4o MCk7DQogICAgICAgIH0NCiAgICB9ICAgDQogICAgICAgIA0KICAgIC8qIFNl dCBkbWEgbGV2ZWwsIGZhbGwgYmFjayB0byBwaW8gaWYgcG9zc2libGUuIChm b2xsb3dpbmcgU0NPIGRyaXZlciBleGFtcGxlKSAqLw0KICAgIGlmIChpcy0+ aWRfZHJxICE9IHNjLT5jb25maWctPmRtYWxldmVsKSB7DQogICAgICAgIHJj ID0gVFJsbGRTZXRETUEoc2MtPlRSbGxkQWRhcHRlciwgaXMtPmlkX2RycSwg JnNjLT5jb25maWctPm1vZGUpOw0KICAgICAgICBpZiAocmMgIT0gVFJMTERf Q09ORklHX09LKSB7DQogICAgICAgICAgICBpZiAoKHNjLT5jb25maWctPmRt YWxldmVsICE9IFRSTExEX0RNQV9QSU8pICYmDQogICAgICAgICAgICAgICAg KFRSbGxkU2V0RE1BKHNjLT5UUmxsZEFkYXB0ZXIsIFRSTExEX0RNQV9QSU8s ICZzYy0+Y29uZmlnLT5tb2RlKSAhPSBUUkxMRF9DT05GSUdfT0spKSB7DQog ICAgICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IHVuYWJsZSB0byBjaGFu Z2UgZG1hIGxldmVsIGZyb20gJWQgdG8gJWQgKCV4KVxuIiwgc2MtPnVuaXQs DQogICAgICAgICAgICAgICAgICAgICAgICBzYy0+Y29uZmlnLT5kbWFsZXZl bCwgaXMtPmlkX2RycSwgcmMpOw0KICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IFVuYWJsZSB0byBjaGFuZ2UgYWRhcHRlciBk bWEgbGV2ZWwsIHVzaW5nIFBJTyBtb2RlICgleClcbiIsIHNjLT51bml0LCBy Yyk7DQogICAgICAgICAgICBzYy0+Y29uZmlnLT5kbWFsZXZlbCA9IFRSTExE X0RNQV9QSU87DQogICAgICAgICAgICByYyA9IFRSbGxkU2V0RE1BKHNjLT5U UmxsZEFkYXB0ZXIsIGlzLT5pZF9kcnEsICZzYy0+Y29uZmlnLT5tb2RlKTsN CiAgICAgICAgfQ0KICAgICAgICBpcy0+aWRfaXJxID0gc2MtPmNvbmZpZy0+ ZG1hbGV2ZWw7DQogICAgfQ0KICAgIHJldHVybigxKTsNCn0NCg0KI2lmIE5Q Q0kgPiAwDQpzdGF0aWMgdm9pZA0Kb2x0cl9wY2lfYXR0YWNoKGNvbmZpZ19p ZCwgdW5pdCkNCiAgICBwY2ljaV90IGNvbmZpZ19pZDsNCiAgICBpbnQgdW5p dDsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0 Y1t1bml0XTsNCg0KICAgIHNjLT51bml0ID0gdW5pdDsNCiAgICBzYy0+Y29u ZmlnID0gJm9sdHJfY29uZmlnW3VuaXRdOw0KICAgIHNjLT5od19zdGF0ZSA9 IEhXX0ZPVU5EOw0KDQogICAgcHJpbnRmKCJvbHRyJWQ6IG1hYyBhZGRyZXNz IFslNkRdXG4iLCBzYy0+dW5pdCwgc2MtPmNvbmZpZy0+bWFjYWRkcmVzcywg IjoiKTsNCg0KICAgIGlmICghb2x0cl9hdHRhY2hfY29tbW9uKHNjKSkNCiAg ICAgICAgcmV0dXJuOw0KDQogICAgLyogTWFwIG91ciBpbnRlcnJ1cHQgKi8N CiAgICBpZiAoIXBjaV9tYXBfaW50KGNvbmZpZ19pZCwgb2x0cl9wY2lfaW50 ciwgc2MsICZuZXRfaW1hc2spKSB7DQogICAgICAgIHByaW50Zigib2x0ciVk OiBjb3VsZG4ndCBtYXAgaW50ZXJydXB0XG4iLCB1bml0KTsNCiAgICAgICAg cmV0dXJuOw0KICAgIH0NCn0NCiNlbmRpZiAvKiBOUENJICovDQoNCnN0YXRp YyBpbnQNCm9sdHJfYXR0YWNoX2NvbW1vbihzYykNCiAgICBzdHJ1Y3Qgb2x0 cl9zb2Z0YyAqc2M7DQp7DQogICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2Mt PmFycGNvbS5hY19pZjsNCiAgICB1X2ludCAgYnVmc2l6ZTsNCiAgICBpbnQg ICAgcmMsIGksIGo7DQogIA0KICAgIC8qcHJpbnRmKCJvbHRyJWQ6IGF0dGFj aF9jb21tb24gY2FsbGVkXG4iLCBzYy0+dW5pdCk7Ki8NCg0KICAgIC8qIEFs bG9jYXRlIGFkYXB0ZXIgbWVtb3J5IGJ1ZmZlciAqLw0KICAgIGJ1ZnNpemUg PSBUUmxsZEFkYXB0ZXJTaXplKCk7DQogICAgc2MtPlRSbGxkQWRhcHRlciA9 IChUUmxsZEFkYXB0ZXJfdCAqKW9sdHJfbWFsbG9jKGJ1ZnNpemUsIHNjLT5j b25maWcpOw0KICAgIGlmIChzYy0+VFJsbGRBZGFwdGVyID09IE5VTEwpIHsN CiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IFVuYWJsZSB0byBhbGxvY2F0ZSBh ZGFwdGVyIG1lbW9yeSBibG9jayAoJWQgYnl0ZXMpXG4iLCBzYy0+dW5pdCwg YnVmc2l6ZSk7DQogICAgfSANCiAgICAvKnByaW50Zigib2x0ciVkOiBBZGFw dGVyIG1lbW9yeSBibG9jayAoJXAgJWQgYnl0ZXMpXG4iLCBzYy0+dW5pdCwg c2MtPlRSbGxkQWRhcHRlciwgYnVmc2l6ZSk7Ki8NCg0KICAgIC8qIFNldHVw IHRyYW5zbWl0IHBvb2wgKi8NCiAgICBmb3IgKGkgPSAwOyBpIDwgVFhfTElT VF9TSVpFOyBpKyspIHsNCiAgICAgICAgc2MtPnR4X2J1ZmZlcltpXS5pbmRl eCA9IGk7DQogICAgICAgIHNjLT50eF9idWZmZXJbaV0uYnVmID0gKGNoYXIg KilvbHRyX21hbGxvYyhUWF9CVUZGRVJfTEVOLCBzYy0+Y29uZmlnKTsNCiAg ICAgICAgLyogSWYgd2UgaGF2ZSBhIGZhaWx1cmUgdGhlbiBmcmVlIGV2ZXJ5 dGhpbmcgYW5kIGdldCBvdXQgKi8NCiAgICAgICAgaWYgKCFzYy0+dHhfYnVm ZmVyW2ldLmJ1Zikgew0KICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IFVu YWJsZSB0byBhbGxvY2F0ZSB0cmFuc21pdCBidWZmZXJzLlxuIiwgc2MtPnVu aXQpOw0KICAgICAgICAgICAgZm9yIChqID0gMDsgaiA8IGk7IGorKykNCiAg ICAgICAgICAgICAgICBmcmVlKHNjLT50eF9idWZmZXJbal0uYnVmLCBNX0RF VkJVRik7DQogICAgICAgICAgICByZXR1cm4oMCk7DQogICAgICAgIH0NCiAg ICB9DQogICAgc2MtPnR4X25leHQgPSAwOw0KICAgIHNjLT50eF9hdmFpbCA9 IFRYX0xJU1RfU0laRTsNCg0KICAgIC8qIFNldHVwIHJlY2VpdmUgcG9vbCAq Lw0KICAgIGZvciAoaSA9IDA7IGkgPCBSWF9MSVNUX1NJWkU7IGkrKykgew0K ICAgICAgICBzYy0+cnhfYnVmZmVyW2ldLmluZGV4ID0gaTsNCiAgICAgICAg c2MtPnJ4X2J1ZmZlcltpXS5idWYgPSAoY2hhciAqKW9sdHJfbWFsbG9jKFJY X0JVRkZFUl9MRU4sIHNjLT5jb25maWcpOw0KICAgICAgICAvKiBJZiB3ZSBo YXZlIGEgZmFpbHVyZSB0aGVuIGZyZWUgZXZlcnl0aGluZyBhbmQgZ2V0IG91 dCAqLw0KICAgICAgICBpZiAoIXNjLT5yeF9idWZmZXJbaV0uYnVmKSB7ICAg ICAgICAgIA0KICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IFVuYWJsZSB0 byBhbGxvY2F0ZSByZWNlaXZlIGJ1ZmZlcnMuXG4iLCBzYy0+dW5pdCk7DQog ICAgICAgICAgICBmb3IgKGogPSAwOyBqIDwgaTsgaisrKQ0KICAgICAgICAg ICAgICAgIGZyZWUoc2MtPnJ4X2J1ZmZlcltqXS5idWYsIE1fREVWQlVGKTsN CiAgICAgICAgICAgIHJldHVybigwKTsNCiAgICAgICAgfQ0KICAgIH0gICAN CiAgICBzYy0+cnhfbmV4dCA9IDA7DQogICAgc2MtPnJ4X2F2YWlsID0gUlhf TElTVF9TSVpFOyANCiAgICAvKnByaW50Zigib2x0ciVkOiBBbGxvY2F0ZWQg cmVjZWl2ZSBidWZmZXJzXG4iLCBzYy0+dW5pdCk7ICovDQogICAgDQogICAg LyogU2V0IHVwIGFkYXB0ZXIgcG9sbGluZyBtZWNoYW5pc20gKi8NCiAgICBz Yy0+cG9sbF9hZGFwdGVyID0gMTsNCiAgICBjYWxsb3V0X2hhbmRsZV9pbml0 KCZzYy0+cG9sbF9jaCk7DQogICAgc2MtPnBvbGxfY2ggPSB0aW1lb3V0KGFk YXB0ZXJfcG9sbCwgKHZvaWQgKilzYy0+dW5pdCwgKDEqaHopLzEwMDApOw0K ICAgIGNhbGxvdXRfaGFuZGxlX2luaXQoJnNjLT5vbHRyX2NoKTsNCg0KICAg IC8qIEluaXRpYWxpemUgYWRhcHRlciAqLw0KICAgIHJjID0gVFJsbGRBZGFw dGVySW5pdCgmb2x0ckxsZERyaXZlciwgc2MtPlRSbGxkQWRhcHRlciwga3Z0 b3Aoc2MtPlRSbGxkQWRhcHRlciksIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAodm9pZCAqKXNjLT51bml0LCBzYy0+Y29uZmlnKTsNCiAgICBpZiAo cmMgIT0gVFJMTERfSU5JVF9PSykgew0KICAgICAgICBzd2l0Y2ggKHJjKSB7 DQogICAgICAgICAgICBjYXNlIFRSTExEX0lOSVRfTk9UX0ZPVU5EOg0KICAg ICAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVyIG5vdCBmb3Vu ZCBvciBtYWxmdW5jdGlvbmluZy5cbiIsIHNjLT51bml0KTsNCiAgICAgICAg ICAgICAgICBzYy0+aHdfc3RhdGUgPSBIV19CQUQ7DQogICAgICAgICAgICAg ICAgcmV0dXJuKDApOw0KICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX1VO U1VQUE9SVEVEOg0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBB ZGFwdGVyIG5vdCBzdXBwb3J0ZWQgYnkgbG93IGxldmVsIGRyaXZlci5cbiIs IHNjLT51bml0KTsNCiAgICAgICAgICAgICAgICBzYy0+aHdfc3RhdGUgPSBI V19VTktOT1dOOw0KICAgICAgICAgICAgICAgIHJldHVybigwKTsNCiAgICAg ICAgICAgIGNhc2UgVFJMTERfSU5JVF9QSFlTMTY6DQogICAgICAgICAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IEFkYXB0ZXIgbWVtb3J5IGJsb2NrIGFib3Zl IDE2TSwgbXVzdCBiZSBiZWxvdyAxNk0uXG4iLCBzYy0+dW5pdCk7DQogICAg ICAgICAgICAgICAgcmV0dXJuKDApOw0KICAgICAgICAgICAgY2FzZSBUUkxM RF9JTklUX1ZFUlNJT046DQogICAgICAgICAgICAgICAgcHJpbnRmKCJvbHRy JWQ6IExvdyBsZXZlbCBkcml2ZXIgdmVyc2lvbiBtaXNtYXRjaC5cbiIsIHNj LT51bml0KTsNCiAgICAgICAgICAgICAgICByZXR1cm4oMCk7DQogICAgICAg ICAgICBkZWZhdWx0Og0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVk OiBVbmtub3duIGluaXRpbGl6YXRpb24gZXJyb3Igb2Njb3VyZWQgKCV4KS5c biIsIHNjLT51bml0LCByYyk7DQogICAgICAgICAgICAgICAgcmV0dXJuKDAp Ow0KICAgICAgICB9DQogICAgfQ0KDQogICAgLyogRG93bmxvYWQgQWRhcHRl ciBNaWNyb2NvZGUgKi8NCiAgICAvKnByaW50Zigib2x0ciVkOiBEb3dubG9h ZGluZyBhZGFwdGVyIG1pY3JvY29kZS4uLiIsIHNjLT51bml0KTsqLw0KICAg IHNjLT5od19zdGF0ZSA9IEhXX0xPQURJTkc7DQogICAgc3dpdGNoKHNjLT5j b25maWctPm1hY3R5cGUpIHsNCiAgICAgICAgY2FzZSBUUkxMRF9NQUNfVE1T OiAgICAgICAgICAgLyogVE1TIG1pY3JvY29kZSAqLw0KICAgICAgICAgICAg cmMgPSBUUmxsZERvd25sb2FkKHNjLT5UUmxsZEFkYXB0ZXIsIFRSbGxkTWFj Q29kZSk7DQogICAgICAgICAgICBicmVhazsNCiAgICAgICAgY2FzZSBUUkxM RF9NQUNfSEFXS0VZRTogICAgICAgIC8qIEhhd2tleWUgbWljcm9jb2RlICov DQogICAgICAgICAgICByYyA9IFRSbGxkRG93bmxvYWQoc2MtPlRSbGxkQWRh cHRlciwgVFJsbGRIYXdrZXllTWFjKTsNCiAgICAgICAgICAgIGJyZWFrOw0K ICAgICAgICBjYXNlIFRSTExEX01BQ19CVUxMU0VZRTogICAgICAvKiBCdWxs c2V5ZSBtaWNyb2NvZGUgKi8NCiAgICAgICAgICAgIHJjID0gVFJsbGREb3du bG9hZChzYy0+VFJsbGRBZGFwdGVyLCBUUmxsZEJ1bGxzZXllTWFjKTsNCiAg ICAgICAgICAgIGJyZWFrOw0KICAgICAgICBkZWZhdWx0Og0KICAgICAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IHVua25vd24gbWFjdHlwZSAlZFxuIiwgc2Mt PnVuaXQsIHNjLT5jb25maWctPm1hY3R5cGUpOw0KICAgICAgICAgICAgcmV0 dXJuKDApOw0KICAgIH0NCiAgICAvKmlmIChyYyA9PSBUUkxMRF9ET1dOTE9B RF9PSykgDQogICAgICAgIHByaW50ZigiZG9uZVxuIik7Ki8NCiAgICBpZiAo KHJjID09IFRSTExEX0RPV05MT0FEX0VSUk9SKSB8fCAocmMgPT0gVFJMTERf U1RBVEUpKSB7DQogICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVyIG1p Y3JvY29kZSBkb3dubG9hZCBmYWlsZWQhIChyYyA9ICV4KVxuIiwgc2MtPnVu aXQsIHJjKTsNCiAgICAgICAgc2MtPmh3X3N0YXRlID0gSFdfQkFEOw0KICAg ICAgICByZXR1cm4oMCk7ICAgICANCiAgICB9DQoNCiAgICBUUmxsZFNldFNw ZWVkKHNjLT5UUmxsZEFkYXB0ZXIsIFRSTExEX1NQRUVEX0FVVE8pOw0KDQog ICAgc2MtPlByb21pc2NNb2RlID0gMDsNCiAgICBzYy0+QWRhcHRlck1vZGUg PSAwOw0KDQogICAgLyogRG8gdGhlIGlmbmV0IGluaXRpYWxpemF0aW9uICov DQogICAgaWZwLT5pZl9zb2Z0YyAgID0gc2M7DQogICAgaWZwLT5pZl91bml0 ICAgID0gc2MtPnVuaXQ7DQogICAgaWZwLT5pZl9uYW1lICAgID0gIm9sdHIi Ow0KICAgIGlmcC0+aWZfb3V0cHV0ICA9IGlzbzg4MDI1X291dHB1dDsNCiAg ICBpZnAtPmlmX2luaXQgICAgPSAoaWZfaW5pdF9mX3QgKilvbHRyX2luaXQ7 DQogICAgaWZwLT5pZl9zdGFydCAgID0gb2x0cl9zdGFydDsNCiAgICBpZnAt PmlmX2lvY3RsICAgPSBvbHRyX2lvY3RsOw0KICAgIGlmcC0+aWZfZmxhZ3Mg ICA9IElGRl9CUk9BRENBU1QgfCBJRkZfTVVMVElDQVNUIHwgSUZGX1NJTVBM RVg7DQogICAgYmNvcHkoc2MtPmNvbmZpZy0+bWFjYWRkcmVzcywgc2MtPmFy cGNvbS5hY19lbmFkZHIsIHNpemVvZihzYy0+Y29uZmlnLT5tYWNhZGRyZXNz KSk7DQoNCiAgICAvKiBTZXQgdXAgY29tbW9uIGlmbWVkaWEgb3B0aW9ucyAq Lw0KICAgIGlmbWVkaWFfaW5pdCgmc2MtPmlmbWVkaWEsIDAsIG9sdHJfaWZt ZWRpYV91cGQsIG9sdHJfaWZtZWRpYV9zdHMpOw0KDQogICAgaWZtZWRpYV9h ZGQoJnNjLT5pZm1lZGlhLCBJRk1fVE9LRU4gfCBJRk1fQVVUTywgMCAsIE5V TEwpOw0KICAgIGlmbWVkaWFfYWRkKCZzYy0+aWZtZWRpYSwgSUZNX1RPS0VO IHwgSUZNX1RPS19VVFA0LCAwICwgTlVMTCk7DQogICAgaWZtZWRpYV9hZGQo JnNjLT5pZm1lZGlhLCBJRk1fVE9LRU4gfCBJRk1fVE9LX1VUUDE2LCAwICwg TlVMTCk7DQogICAgDQogICAgaWZtZWRpYV9zZXQoJnNjLT5pZm1lZGlhLCBJ Rk1fVE9LRU4gfCBJRk1fQVVUTyk7DQoNCiAgICBpZl9hdHRhY2goaWZwKTsN CiAgICBpc284ODAyNV9pZmF0dGFjaChpZnApOw0KDQojaWYgTkJQRklMVEVS ID4gMA0KICAgIGJwZmF0dGFjaChpZnAsIERMVF9JRUVFODAyLCBzaXplb2Yo c3RydWN0IGlzbzg4MDI1X2hlYWRlcikpOw0KI2VuZGlmDQoNCiAgICByZXR1 cm4oMSk7DQp9DQoNCiNpZiBOUENJID4gMA0Kc3RhdGljIHZvaWQNCm9sdHJf cGNpX3NodXRkb3duKGhvd3RvLCBzYykNCiAgICBpbnQgaG93dG87DQogICAg dm9pZCAqc2M7DQp7DQogICAgcHJpbnRmKCJvbHRyOiBvbHRyX3BjaV9zaHV0 ZG93biBjYWxsZWRcbiIpOw0KfQ0KI2VuZGlmIC8qIE5QQ0kgKi8NCg0Kc3Rh dGljIGludA0Kb2x0cl9pZm1lZGlhX3VwZChpZnApDQogICAgc3RydWN0IGlm bmV0ICppZnA7DQp7DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gaWZw LT5pZl9zb2Z0YzsNCiAgICBzdHJ1Y3QgaWZtZWRpYSAqaWZtICAgPSAmc2Mt PmlmbWVkaWE7DQoNCiAgICBpZiAoSUZNX1RZUEUoaWZtLT5pZm1fbWVkaWEp ICE9IElGTV9UT0tFTikNCiAgICAgICAgcmV0dXJuKEVJTlZBTCk7DQogICAg DQogICAgc3dpdGNoKElGTV9TVUJUWVBFKGlmbS0+aWZtX21lZGlhKSkgew0K ICAgICAgICBjYXNlIElGTV9BVVRPOg0KICAgICAgICAgICAgVFJsbGRTZXRT cGVlZChzYy0+VFJsbGRBZGFwdGVyLCBUUkxMRF9TUEVFRF9BVVRPKTsNCiAg ICAgICAgICAgIGJyZWFrOw0KICAgICAgICBjYXNlIElGTV9UT0tfVVRQNDoN CiAgICAgICAgICAgIFRSbGxkU2V0U3BlZWQoc2MtPlRSbGxkQWRhcHRlciwg VFJMTERfU1BFRURfNE1CUFMpOw0KICAgICAgICAgICAgYnJlYWs7DQogICAg ICAgIGNhc2UgSUZNX1RPS19VVFAxNjoNCiAgICAgICAgICAgIFRSbGxkU2V0 U3BlZWQoc2MtPlRSbGxkQWRhcHRlciwgVFJMTERfU1BFRURfMTZNQlBTKTsN CiAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICBkZWZhdWx0Og0KICAgICAg ICAgICAgcmV0dXJuKEVJTlZBTCk7DQogICAgfQ0KDQogICAgaWYgKElGTV9U WVBFX09QVElPTlMoaWZtLT5pZm1fbWVkaWEpICYgSUZNX1RPS19FVFIpDQog ICAgICAgIHByaW50Zigib2x0ciVkOiBFVFIgbm90IGltcGxlbWVudGVkXG4i LCBzYy0+dW5pdCk7DQogICAgaWYgKElGTV9UWVBFX09QVElPTlMoaWZtLT5p Zm1fbWVkaWEpICYgSUZNX1RPS19TUkNSVCkNCiAgICAgICAgcHJpbnRmKCJv bHRyJWQ6IHNvdXJjZS1yb3V0aW5nIG5vdCBpbXBsZW1lbnRlZFxuIiwgc2Mt PnVuaXQpOw0KICAgIGlmIChJRk1fVFlQRV9PUFRJT05TKGlmbS0+aWZtX21l ZGlhKSAmIElGTV9UT0tfQUxMUikNCiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6 IGFsbCBzb3VyY2Ugcm91dGVzIG5vdCBpbXBsZW1lbnRlZFxuIiwgc2MtPnVu aXQpOw0KICAgIGlmIChJRk1fVFlQRV9PUFRJT05TKGlmbS0+aWZtX21lZGlh KSAmIElGTV9UT0tfRFRSKSB7DQogICAgICAgIHNjLT5BZGFwdGVyTW9kZSB8 PSBUUkxMRF9NT0RFX0ZPUkNFX1RYSTsNCiAgICAgICAgc2MtPkFkYXB0ZXJN b2RlICY9IH5UUkxMRF9NT0RFX0ZPUkNFX1RLUDsNCiAgICB9DQogICAgaWYg KElGTV9UWVBFX09QVElPTlMoaWZtLT5pZm1fbWVkaWEpICYgSUZNX1RPS19D TEFTU0lDKSB7DQogICAgICAgIHNjLT5BZGFwdGVyTW9kZSB8PSBUUkxMRF9N T0RFX0ZPUkNFX1RLUDsNCiAgICAgICAgc2MtPkFkYXB0ZXJNb2RlICY9IH5U UkxMRF9NT0RFX0ZPUkNFX1RYSTsNCiAgICB9DQogICAgaWYgKElGTV9UWVBF X09QVElPTlMoaWZtLT5pZm1fbWVkaWEpICYgSUZNX1RPS19BVVRPKQ0KICAg ICAgICBzYy0+QWRhcHRlck1vZGUgJj0gfihUUkxMRF9NT0RFX0ZPUkNFX1RY SSB8IFRSTExEX01PREVfRk9SQ0VfVEtQKTsNCg0KICAgIGlmIChJRk1fVFlQ RV9PUFRJT05TKGlmbS0+aWZtX21lZGlhKSAmIH5BTExfT1BUSU9OUykNCiAg ICAgICAgcmV0dXJuKEVJTlZBTCk7DQoNCiAgICByZXR1cm4oMCk7DQp9DQoN CnN0YXRpYyB2b2lkDQpvbHRyX2lmbWVkaWFfc3RzKGlmcCwgaWZtcikNCiAg ICBzdHJ1Y3QgaWZuZXQgKmlmcDsNCiAgICBzdHJ1Y3QgaWZtZWRpYXJlcSAq aWZtcjsNCnsNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0YyAqc2MgPSBpZnAtPmlm X3NvZnRjOw0KICAgIHN0cnVjdCBpZm1lZGlhICppZm0gPSAmc2MtPmlmbWVk aWE7DQoNCiAgICBpZm1yLT5pZm1fYWN0aXZlID0gSUZNX1RZUEUoaWZtLT5p Zm1fbWVkaWEpfElGTV9TVUJUWVBFKGlmbS0+aWZtX21lZGlhKXxJRk1fVFlQ RV9PUFRJT05TKGlmbS0+aWZtX21lZGlhKTsNCg0KICAgIHJldHVybjsNCn0N Cg0Kdm9pZA0Kb2x0cl90aW1lb3V0KHRva2VuKQ0KICAgIHZvaWQgKnRva2Vu Ow0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9ICZvbHRyX3NvZnRj WyhpbnQpdG9rZW5dOw0KICAgIGludCB1bml0ID0gKGludCl0b2tlbiwgczsN Cg0KICAgIHMgPSBzcGxpbXAoKTsNCg0KICAgIHByaW50Zigib2x0ciVkOiBh ZGFwdGVyIHRpbWVkIG91dCAoJXgpXG4iLCB1bml0LCBzYy0+aHdfc3RhdGUp Ow0KDQogICAgc3BseChzKTsNCn0NCg0KDQp2b2lkDQphZGFwdGVyX3BvbGwo dG9rZW4pDQogICAgdm9pZCAqdG9rZW47DQp7DQogICAgaW50IHVuaXQgPSAo aW50KXRva2VuLCBwb2xsX3RpbWVvdXQgPSAwLCBzOw0KICAgIHN0cnVjdCBv bHRyX3NvZnRjICpzYyA9ICZvbHRyX3NvZnRjW3VuaXRdOw0KI2lmIDANCiAg ICBzdGF0aWMgaW50IHJ4X2J1ZmZlcnMgPSAwLCB0eF9idWZmZXJzID0gMCwg cmM7IA0KI2VuZGlmDQogICAgDQogICAgcyA9IHNwbGltcCgpOw0KDQogICAg LyogQ2hlY2sgdG8gbWFrZSBzdXJlIHdlIGFyZSBub3QgcG9sbGluZyBhIGRl YWQgY2FyZCAqLw0KICAgIGlmICgoc2MtPmh3X3N0YXRlID09IEhXX0JBRCkg fHwgKHNjLT5od19zdGF0ZSA9PSBIV19VTktOT1dOKSkgew0KICAgICAgICBz Yy0+cG9sbF9hZGFwdGVyID0gLTE7DQogICAgICAgIHNwbHgocyk7DQogICAg ICAgIHJldHVybjsNCiAgICB9DQoNCiAgICAvKnByaW50Zigib2x0ciVkOiBh ZGFwdGVyIHBvbGwuXG4iLCB1bml0KTsqLw0KICAgIA0KICAgIC8qIElmIHRo ZSBhZGFwdGVyIGlzIHRvIGJlIHBvbGxlZCBhZ2FpbiwgdGhlbiBzZXQgdXAN CiAgICAgKiBuZXh0IHRpbWVvdXQgcG9sbCANCiAgICAgKi8NCiAgICBpZiAo c2MtPnBvbGxfYWRhcHRlcikgew0KICAgICAgICBwb2xsX3RpbWVvdXQgPSBU UmxsZFBvbGwoc2MtPlRSbGxkQWRhcHRlcik7DQogICAgICAgIHNjLT5wb2xs X2NoID0gdGltZW91dChhZGFwdGVyX3BvbGwsICh2b2lkICopdW5pdCwgKHBv bGxfdGltZW91dCAqIGh6KS8xMDAwKTsNCiAgICB9DQojaWYgMA0KICAgIHJj ID0gVFJsbGRSZWNlaXZlRnJlZShzYy0+VFJsbGRBZGFwdGVyKTsNCiAgICBp ZiAocnhfYnVmZmVycyAhPSByYykgew0KICAgICAgICBwcmludGYoIm9sdHIl ZDogJWQgcmVjZWl2ZSBidWZmZXJzIGF2YWlsYWJsZVxuIiwgc2MtPnVuaXQs IHJjKTsNCiAgICAgICAgcnhfYnVmZmVycyA9IHJjOw0KICAgIH0gDQogICAg cmMgPSBUUmxsZFRyYW5zbWl0RnJlZShzYy0+VFJsbGRBZGFwdGVyKTsNCiAg ICBpZiAodHhfYnVmZmVycyAhPSByYykgew0KICAgICAgICBwcmludGYoIm9s dHIlZDogJWQgdHJhbnNtaXQgYnVmZmVycyBhdmFpbGFibGVcbiIsIHNjLT51 bml0LCByYyk7DQogICAgICAgIHR4X2J1ZmZlcnMgPSByYzsNCiAgICB9IA0K I2VuZGlmDQoNCiAgICBzcGx4KHMpOyAgICAgICAgICAgIA0KfQ0KDQpzdGF0 aWMgdm9pZCANCm9sdHJfaW5pdChzYykNCiAgICBzdHJ1Y3Qgb2x0cl9zb2Z0 YyAqc2M7DQp7DQogICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2MtPmFycGNv bS5hY19pZjsNCiAgICBpbnQgaSwgcmM7DQoNCiAgICAvKnByaW50Zigib2x0 ciVkOiBvbHRyX2luaXRcbiIsIHNjLT51bml0KTsqLw0KICAgIA0KICAgIC8q IA0KICAgICAqIEFkYXB0ZXIgc2hvdWxkIGJlIGZyZXNobHkgZG93bmxvYWRl ZCBvciBwcmV2aW91c2x5IGNsb3NlZCBiZWZvcmUNCiAgICAgKiBicmluZ2lu ZyBpdCBiYWNrIG9uIGxpbmUuDQogICAgICovDQogICAgaWYgKChzYy0+aHdf c3RhdGUgIT0gSFdfQ0xPU0VEKSAmJiAoc2MtPmh3X3N0YXRlICE9IEhXX0xP QURJTkcpICYmIChzYy0+aHdfc3RhdGUgIT0gSFdfQ0xPU0lORzIpKSB7DQog ICAgICAgIHByaW50Zigib2x0ciVkOiBhZGFwdGVyIG5vdCByZWFkeSB0byBi ZSBvcGVuZWQgKCVkKS5cbiIsIHNjLT51bml0LCBzYy0+aHdfc3RhdGUpOw0K ICAgICAgICByZXR1cm47DQogICAgfQ0KDQogICAgLyogQWxsb2NhdGUgYW5k IHNldCB1cCB0aGUgRE1BIGNoYW5uZWwgKi8NCiAgICBpZiAoc2MtPmNvbmZp Zy0+ZG1hbGV2ZWwgIT0gVFJMTERfRE1BX1BJTykgew0KICAgICAgICByYyA9 IGlzYV9kbWFfYWNxdWlyZShzYy0+Y29uZmlnLT5kbWFsZXZlbCk7DQogICAg ICAgIGlzYV9kbWFjYXNjYWRlKHNjLT5jb25maWctPmRtYWxldmVsKTsNCiAg ICB9DQoNCiAgICAvKiBPcGVuIHRoZSBhZGFwdGVyICovDQogICAgc2MtPmh3 X3N0YXRlID0gSFdfT1BFTklORzsNCiAgICByYyA9IFRSbGxkT3BlbihzYy0+ VFJsbGRBZGFwdGVyLCBzYy0+YXJwY29tLmFjX2VuYWRkciwgc2MtPkdyb3Vw QWRkcmVzcywgDQogICAgICAgICAgICAgICAgICAgc2MtPkZ1bmN0aW9uYWxB ZGRyZXNzLCBpZnAtPmlmX210dSArIDUyLCBzYy0+QWRhcHRlck1vZGUpOw0K ICAgIGlmIChyYyAhPSBUUkxMRF9PUEVOX09LKSB7DQogICAgICAgIHByaW50 Zigib2x0ciVkOiBBZGFwdGVyIGZhaWxlZCB0byBvcGVuIChyYyA9ICV4KVxu Iiwgc2MtPnVuaXQsIHJjKTsNCiAgICAgICAgc2MtPmh3X3N0YXRlID0gSFdf RkFJTEVEOw0KICAgIH0gZWxzZSB7DQogICAgICAgIC8qcHJpbnRmKCJvbHRy JWQ6IGFkYXB0ZXIgb3BlbmluZy4uLlxuIiwgc2MtPnVuaXQpOyovDQogICAg ICAgIC8qaWZwLT5pZl9mbGFncyB8PSAoSUZGX1VQIHwgSUZGX1JVTk5JTkcp OyovDQogICAgICAgIGlmcC0+aWZfZmxhZ3MgJj0gfklGRl9PQUNUSVZFOw0K ICAgIH0NCiAgICBzYy0+b2x0cl9jaCA9IHRpbWVvdXQob2x0cl90aW1lb3V0 LCAodm9pZCAqKXNjLT51bml0LCAzMCpoeik7DQogICAgdHNsZWVwKCh2b2lk ICopc2MtPnVuaXQsIDEsICJvbHRyb3AiLCAzMCpoeik7DQoNCiAgICAvKiBH aXZlIHRoZSB0cmFuc21pdCBidWZmZXJzIHRvIHRoZSBhZGFwdGVyICovDQog ICAgZm9yIChpID0gMDsgaSA8IFJYX0xJU1RfU0laRTsgaSsrKSB7IA0KICAg ICAgICByYyA9IFRSbGxkUmVjZWl2ZUZyYWdtZW50KHNjLT5UUmxsZEFkYXB0 ZXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHZvaWQg KilzYy0+cnhfYnVmZmVyW3NjLT5yeF9uZXh0ICYgUlhfTElTVF9NQVNLXS5i dWYsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAga3Z0b3Ao c2MtPnJ4X2J1ZmZlcltzYy0+cnhfbmV4dCAmIFJYX0xJU1RfTUFTS10uYnVm KSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSWF9CVUZG RVJfTEVOLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2 b2lkICopc2MtPnJ4X2J1ZmZlcltzYy0+cnhfbmV4dCAmIFJYX0xJU1RfTUFT S10uaW5kZXgpOw0KICAgICAgICBpZiAocmMgIT0gVFJMTERfUkVDRUlWRV9P Sykgew0KICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IEFkYXB0ZXIgcmVm dXNlZCBmcmFnbWVudCAlZCAocmMgPSAlZCkuXG4iLCBzYy0+dW5pdCwgaSwg cmMpOw0KICAgICAgICAgICAgYnJlYWs7DQogICAgICAgIH0gIGVsc2Ugew0K ICAgICAgICAgICAgc2MtPnJ4X2F2YWlsLS07DQogICAgICAgIH0NCiAgICAg ICAgc2MtPnJ4X25leHQrKzsNCiAgICB9DQogICAgDQogICAgcmV0dXJuOw0K fQ0KICAgIA0Kc3RhdGljIHZvaWQNCm9sdHJfaW50cih1bml0KQ0KICAgIGlu dCB1bml0Ow0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9ICZvbHRy X3NvZnRjW3VuaXRdOw0KICAgIGludCByYzsNCg0KICAgIC8qcHJpbnRmKCJv bHRyJWQ6IG9sdHJfaW50clxuIiwgdW5pdCk7Ki8gLyogVG9vIG5vaXN5ICov DQogICAgcmM9IFRSbGxkSW50ZXJydXB0U2VydmljZShzYy0+VFJsbGRBZGFw dGVyKTsNCiAgICBpZiAocmMgPT0gVFJMTERfTk9fSU5URVJSVVBUKSANCiAg ICAgICAgcHJpbnRmKCJvbHRyJWQ6IGludGVycnVwdCBub3Qgc2VydmljZWQu XG4iLCB1bml0KTsNCn0NCg0KI2lmIE5QQ0kgPiAwDQpzdGF0aWMgdm9pZA0K b2x0cl9wY2lfaW50cihwc2MpDQogICAgdm9pZCAqcHNjOw0Kew0KICAgIHN0 cnVjdCBvbHRyX3NvZnRjICpzYyA9IChzdHJ1Y3Qgb2x0cl9zb2Z0YyAqKXBz YzsNCiAgICBpbnQgcmMgPSAwOw0KDQogICAgLypwcmludGYoIm9sdHIlZDog b2x0cl9wY2lfaW50clxuIiwgc2MtPnVuaXQpOyovIC8qIFRvbyBub2lzeSAq Lw0KICAgIHJjID0gVFJsbGRJbnRlcnJ1cHRTZXJ2aWNlKHNjLT5UUmxsZEFk YXB0ZXIpOw0KICAgIGlmIChyYyA9PSBUUkxMRF9OT19JTlRFUlJVUFQpDQog ICAgICAgIHByaW50Zigib2x0ciVkOiBwY2kgaW50ZXJydXB0IG5vdCBzZXJ2 aWNlZC5cbiIsIHNjLT51bml0KTsNCn0NCiNlbmRpZiAvKiBOUENJICovDQoN CnN0YXRpYyB2b2lkIA0Kb2x0cl9zdGFydChpZnApDQogICAgc3RydWN0IGlm bmV0ICppZnA7DQp7DQogICAgc3RydWN0IG9sdHJfc29mdGMgKnNjID0gJm9s dHJfc29mdGNbaWZwLT5pZl91bml0XTsNCiAgICBzdHJ1Y3QgbWJ1ZiAqbTAs ICptOw0KICAgIHN0cnVjdCBpc284ODAyNV9oZWFkZXIgKnRoOw0KICAgIFRS bGxkVHJhbnNtaXRfdCBmcmFtZTsNCiAgICBpbnQgIGxlbiwgaSwgcmM7DQoN CiAgICAvKnByaW50Zigib2x0ciVkOiBvbHRyX3N0YXJ0XG4iLCBzYy0+dW5p dCk7Ki8NCg0Kb3V0bG9vcDoNCg0KICAgIC8qIENoZWNrIHRvIHNlZSBpZiB3 ZSBoYXZlIGVub3VnaCByb29tIHRvIHRyYW5zbWl0ICovDQogICAgaWYgKHNj LT50eF9hdmFpbCA8PSAwKSB7DQogICAgICAgIC8qIE5vIGZyZWUgYnVmZmVy cywgaG9sZCBvZmYgdGhlIHVwcGVyIGxheWVycyAqLw0KICAgICAgICAvKnBy aW50Zigib2x0ciVkOiB0cmFuc21pdCBxdWV1ZSBmdWxsLlxuIiwgc2MtPnVu aXQpOyovDQogICAgICAgIGlmcC0+aWZfZmxhZ3MgfD0gSUZGX09BQ1RJVkU7 DQogICAgICAgIHJldHVybjsNCiAgICB9DQogICAgSUZfREVRVUVVRSgmaWZw LT5pZl9zbmQsIG0pOw0KICAgIGlmIChtID09IDApIHsNCiAgICAgICAgLypw cmludGYoIm9sdHIlZDogb2x0cl9zdGFydCBOVUxMIHBhY2tldCBkZXF1ZXVl ZC5cbiIsIHNjLT51bml0KTsqLw0KICAgICAgICBpZnAtPmlmX2ZsYWdzICY9 IH5JRkZfT0FDVElWRTsNCiAgICAgICAgcmV0dXJuOw0KICAgIH0NCg0KICAg IHRoID0gbXRvZChtLCBzdHJ1Y3QgaXNvODgwMjVfaGVhZGVyICopOw0KICAg IHRoLT5hYyA9IDB4MTA7DQogICAgdGgtPmZjID0gMHg0MDsNCiAgICANCiAg ICAvKiBLZWVwIGEgcG9pbnRlciB0byB0aGUgaGVhZCBvZiB0aGUgcGFja2V0 ICovDQogICAgbTAgPSBtOw0KDQogICAgaSA9IChzYy0+dHhfbmV4dCAmIFRY X0xJU1RfTUFTSyk7IC8qIEp1c3QgdG8gc2hvcnRlbiB0aGluZyB1cCAqLw0K DQogICAgZm9yIChsZW4gPSAwOyBtICE9IDA7IG0gPSBtLT5tX25leHQpIHsN CiAgICAgICAgZnJhbWUuVHJhbnNtaXRGcmFnbWVudFswXS5WaXJ0dWFsQWRk cmVzcyA9IHNjLT50eF9idWZmZXJbaV0uYnVmOw0KICAgICAgICBmcmFtZS5U cmFuc21pdEZyYWdtZW50WzBdLlBoeXNpY2FsQWRkcmVzcyA9IGt2dG9wKHNj LT50eF9idWZmZXJbaV0uYnVmKTsNCiAgICAgICAgYmNvcHkobXRvZChtLCBj YWRkcl90KSwgc2MtPnR4X2J1ZmZlcltpXS5idWYgKyBsZW4sIG0tPm1fbGVu KTsNCiAgICAgICAgbGVuICs9IG0tPm1fbGVuOw0KICAgIH0NCiAgICBmcmFt ZS5GcmFnbWVudENvdW50ID0gMTsNCiAgICBmcmFtZS5UcmFuc21pdEZyYWdt ZW50WzBdLmNvdW50ID0gbGVuOw0KDQogICAgcmMgPSBUUmxsZFRyYW5zbWl0 RnJhbWUoc2MtPlRSbGxkQWRhcHRlciwgJmZyYW1lLCAodm9pZCAqKXNjLT50 eF9idWZmZXJbaV0uaW5kZXgpOw0KICAgIGlmIChyYyAhPSBUUkxMRF9UUkFO U01JVF9PSykgew0KICAgICAgICBwcmludGYoIm9sdHIlZDogVFJsbGRUcmFu c21pdEZyYW1lIHJldHVybmVkICgleClcbiIsIHNjLT51bml0LCByYyk7DQog ICAgICAgIGlmcC0+aWZfb2Vycm9ycysrOw0KICAgICAgICBnb3RvIGJhZDsN CiAgICB9DQoNCiAgICBzYy0+dHhfbmV4dCsrOw0KICAgIHNjLT50eF9hdmFp bC0tOw0KDQojaWYgTkJQRklMVEVSID4gMA0KICAgIGlmIChpZnAtPmlmX2Jw ZikNCiAgICAgICAgYnBmX210YXAoaWZwLCBtMCk7DQojZW5kaWYNCg0KYmFk Og0KICAgIG1fZnJlZW0obTApOw0KICAgIGdvdG8gb3V0bG9vcDsNCiAgICBy ZXR1cm47DQp9DQoNCnN0YXRpYyB2b2lkDQpvbHRyX3N0b3Aoc2MpDQogICAg c3RydWN0IG9sdHJfc29mdGMgKnNjOw0Kew0KICAgIHN0cnVjdCBpZm5ldCAq aWZwID0gJnNjLT5hcnBjb20uYWNfaWY7DQogICAgcHJpbnRmKCJvbHRyJWQ6 IG90bHJfc3RvcFxuIiwgc2MtPnVuaXQpOw0KICAgIGlmcC0+aWZfZmxhZ3Mg Jj0gfihJRkZfVVAgfCBJRkZfUlVOTklORyB8IElGRl9PQUNUSVZFKTsNCiAg ICBzYy0+aHdfc3RhdGUgPSBIV19DTE9TSU5HOw0KICAgIFRSbGxkQ2xvc2Uo c2MtPlRSbGxkQWRhcHRlciwgMCk7DQogICAgc2MtPm9sdHJfY2ggPSB0aW1l b3V0KG9sdHJfdGltZW91dCwgKHZvaWQgKilzYy0+dW5pdCwgMzAqaHopOw0K ICAgIHRzbGVlcCgodm9pZCAqKXNjLT51bml0LCAxLCAib2x0cmNsIiwgMzAq aHopOw0KfQ0KDQpzdGF0aWMgaW50DQpvbHRyX2lvY3RsKGlmcCwgY21kLCBk YXRhKQ0KICAgIHN0cnVjdCBpZm5ldCAqaWZwOw0KICAgIHVfbG9uZyBjbWQ7 DQogICAgY2FkZHJfdCBkYXRhOw0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRj ICpzYyA9ICZvbHRyX3NvZnRjW2lmcC0+aWZfdW5pdF07DQogICAgc3RydWN0 IGlmcmVxICppZnIgPSAoc3RydWN0IGlmcmVxICopZGF0YTsNCiAgICBpbnQg ZXJyb3IgPSAwLCBzOw0KDQogICAgLypwcmludGYoIm9sdHIlZDogb2x0cl9p b2N0bFxuIiwgaWZwLT5pZl91bml0KTsqLw0KDQogICAgcyA9IHNwbGltcCgp Ow0KDQogICAgc3dpdGNoIChjbWQpIHsNCiAgIA0KICAgICAgICBjYXNlIFNJ T0NTSUZBRERSOg0KICAgICAgICBjYXNlIFNJT0NHSUZBRERSOg0KICAgICAg ICBjYXNlIFNJT0NTSUZNVFU6DQogICAgICAgICAgICBlcnJvciA9IGlzbzg4 MDI1X2lvY3RsKGlmcCwgY21kLCBkYXRhKTsNCiAgICAgICAgICAgIGJyZWFr Ow0KDQogICAgICAgIGNhc2UgU0lPQ1NJRkZMQUdTOg0KICAgICAgICAgICAg LyoNCiAgICAgICAgICAgICAqIElmIHRoZSBpbnRlcmZhY2UgaXMgbWFya2Vk IHVwIGFuZCBzdG9wcGVkLCB0aGVuIHN0YXJ0IGl0Lg0KICAgICAgICAgICAg ICogSWYgaXQgaXMgbWFya2VkIGRvd24gYW5kIHJ1bm5pbmcsIHRoZW4gc3Rv cCBpdC4NCiAgICAgICAgICAgICAqLw0KICAgICAgICAgICAgaWYgKGlmcC0+ aWZfZmxhZ3MgJiBJRkZfVVApIHsNCiAgICAgICAgICAgICAgICAgICAgaWYg KChpZnAtPmlmX2ZsYWdzICYgSUZGX1JVTk5JTkcpID09IDApDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgb2x0cl9pbml0KHNjKTsNCiAgICAgICAg ICAgIH0gZWxzZSB7DQogICAgICAgICAgICAgICAgICAgIGlmIChpZnAtPmlm X2ZsYWdzICYgSUZGX1JVTk5JTkcpIHsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvbHRyX3N0b3Aoc2MpOw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGlmcC0+aWZfZmxhZ3MgJj0gfklGRl9SVU5OSU5HOw0KICAgICAg ICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAg IGlmICgoaWZwLT5pZl9mbGFncyAmIElGRl9QUk9NSVNDKSAhPSBzYy0+UHJv bWlzY01vZGUpIHsNCiAgICAgICAgICAgICAgICBpZiAoaWZwLT5pZl9mbGFn cyAmIElGRl9QUk9NSVNDKQ0KICAgICAgICAgICAgICAgICAgICBUUmxsZFNl dFByb21pc2N1b3VzTW9kZShzYy0+VFJsbGRBZGFwdGVyLCBPTFRSX1BST01J U0NfTU9ERSk7DQogICAgICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAg ICAgICAgICBUUmxsZFNldFByb21pc2N1b3VzTW9kZShzYy0+VFJsbGRBZGFw dGVyLCAwKTsNCiAgICAgICAgICAgICAgICBzYy0+UHJvbWlzY01vZGUgPSAo aWZwLT5pZl9mbGFncyAmIElGRl9QUk9NSVNDKTsNCiAgICAgICAgICAgIH0N CiAgICAgICAgICAgIA0KICAgICAgICAgICAgYnJlYWs7DQogICAgICAgIGNh c2UgU0lPQ0dJRk1FRElBOg0KICAgICAgICBjYXNlIFNJT0NTSUZNRURJQToN CiAgICAgICAgICAgIGVycm9yID0gaWZtZWRpYV9pb2N0bChpZnAsIGlmciwg JnNjLT5pZm1lZGlhLCBjbWQpOw0KICAgICAgICAgICAgYnJlYWs7DQogICAg ICAgIGRlZmF1bHQ6DQogICAgICAgICAgICBlcnJvciA9IEVJTlZBTDsNCiAg ICB9DQogICAgc3BseChzKTsNCiAgICByZXR1cm4oZXJyb3IpOw0KfQ0KDQov Kg0KICogUE1XIENhbGxiYWNrIGZ1bmN0aW9ucyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogKi8NCg0K c3RhdGljIHZvaWQNCkRyaXZlclN1c3BlbmQoTWljcm9TZWNvbmRzKQ0KICAg IHVuc2lnbmVkIHNob3J0IE1pY3JvU2Vjb25kczsNCnsNCiAgICBERUxBWShN aWNyb1NlY29uZHMpOw0KfQ0KDQoNCnN0YXRpYyB2b2lkDQpEcml2ZXJTdGF0 dXMoRHJpdmVySGFuZGxlLCBTdGF0dXMpDQogICAgdm9pZCAqRHJpdmVySGFu ZGxlOw0KICAgIFRSbGxkU3RhdHVzX3QgKlN0YXR1czsNCnsNCiAgICBzdHJ1 Y3Qgb2x0cl9zb2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1soaW50KURyaXZlckhh bmRsZV07DQogICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2MtPmFycGNvbS5h Y19pZjsNCg0KICAgIHN3aXRjaCAoU3RhdHVzLT5UeXBlKSB7DQogICAgICAg IGNhc2UgVFJMTERfU1RTX09OX1dJUkU6DQogICAgICAgICAgICBpZiAoc2Mt Pmh3X3N0YXRlID09IEhXX09QRU5JTkcpIHsNCiAgICAgICAgICAgICAgICBz Yy0+aHdfc3RhdGUgPSBIV19PUEVOOw0KICAgICAgICAgICAgICAgIGlmcC0+ aWZfZmxhZ3MgfD0gKElGRl9VUCB8IElGRl9SVU5OSU5HKTsNCiAgICAgICAg ICAgICAgICAvKnByaW50Zigib2x0ciVkOiBBZGFwdGVyIGluc2VydGVkLlxu Iiwgc2MtPnVuaXQpOyovDQogICAgICAgICAgICAgICAgdW50aW1lb3V0KG9s dHJfdGltZW91dCwgKHZvaWQgKilzYy0+dW5pdCwgc2MtPm9sdHJfY2gpOw0K ICAgICAgICAgICAgICAgIHdha2V1cF9vbmUoKHZvaWQgKilzYy0+dW5pdCk7 DQogICAgICAgICAgICB9DQogICAgICAgICAgICBicmVhazsNCiAgICAgICAg Y2FzZSBUUkxMRF9TVFNfU0VMRlRFU1RfU1RBVFVTOg0KICAgICAgICAgICAg aWYgKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5TZWxmdGVzdFN0YXR1cyA9PSBU UkxMRF9TVF9PSykgew0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVk OiBhZGFwdGVyIHN0YXR1cyBnb29kLiAoY2xvc2UgY29tcGxldGVkL3NlbGYt dGVzdClcbiIsIHNjLT51bml0KTsNCiAgICAgICAgICAgICAgICBpZiAoKHNj LT5od19zdGF0ZSA9PSBIV19MT0FESU5HKSB8fCAoc2MtPmh3X3N0YXRlID09 IEhXX0NMT1NJTkcpIHx8IChzYy0+aHdfc3RhdGUgPT0gSFdfQ0xPU0lORzIp KSB7DQogICAgICAgICAgICAgICAgICAgIHNjLT5od19zdGF0ZSA9IEhXX0NM T1NFRDsNCiAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQogICAgICAgICAg ICAgICAgfQ0KICAgICAgICAgICAgfSBlbHNlIHsNCiAgICAgICAgICAgICAg ICBwcmludGYoIm9sdHIlZDogU2VsZiB0ZXN0IGZhaWxlZDogIiwgc2MtPnVu aXQpOw0KICAgICAgICAgICAgICAgIHN3aXRjaCAoU3RhdHVzLT5TcGVjaWZp Y2F0aW9uLlNlbGZ0ZXN0U3RhdHVzKSB7DQogICAgICAgICAgICAgICAgICAg IGNhc2UgVFJMTERfU1RfRVJST1IgKyAwOiBwcmludGYoIkluaXRpYWwgVGVz dCBFcnJvclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICBjYXNl IFRSTExEX1NUX0VSUk9SICsgMTogcHJpbnRmKCJBZGFwdGVyIFNvZnR3YXJl IENoZWNrc3VtIEVycm9yXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAg ICAgIGNhc2UgVFJMTERfU1RfRVJST1IgKyAyOiBwcmludGYoIkFkYXB0ZXIg UkFNIEVycm9yXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgICAgIGNh c2UgVFJMTERfU1RfRVJST1IgKyA0OiBwcmludGYoIkluc3RydWN0aW9uIFRl c3QgRXJyb3JcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAgY2Fz ZSBUUkxMRF9TVF9FUlJPUiArIDU6IHByaW50ZigiUHJvdG9jb2wgSGFuZGxl ci9SSSBIdyBFcnJvclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX1NUX0VSUk9SICsgNjogcHJpbnRmKCJTeXN0ZW0gSW50 ZXJmYWNlIFJlZ2lzdGVyIEVycm9yXG4iKTsgYnJlYWs7DQogICAgICAgICAg ICAgICAgICAgIGNhc2UgVFJMTERfU1RfVElNRU9VVDogICBwcmludGYoIlNl bGZ0ZXN0IGRpZCBub3QgY29tcGxldGVcbiIpOyBicmVhazsNCiAgICAgICAg ICAgICAgICAgICAgZGVmYXVsdDogcHJpbnRmKCJVbmtub3duIGVycm9yICgl eClcbiIsIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5TZWxmdGVzdFN0YXR1cyk7 DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgYnJlYWs7DQogICAgICAgIGNhc2UgVFJMTERfU1RTX0lOSVRfU1RBVFVT Og0KICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IEFkYXB0ZXIgaW5pdGlh bGl6YXRpb24gZmFpbGVkOiAiLCBzYy0+dW5pdCk7DQogICAgICAgICAgICBz d2l0Y2goU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRTdGF0dXMpIHsNCiAg ICAgICAgICAgICAgICBjYXNlIFRSTExEX0lOSVRfRVJST1IgKyAweDAxOiBw cmludGYoIkludmFsaWQgaW5pdCBibG9jayAoTExEIGVycm9yKVxuIik7IGJy ZWFrOw0KICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfSU5JVF9FUlJPUiAr IDB4MDI6IHByaW50ZigiSW52YWxpZCBvcHRpb25zIChMTEQgZXJyb3IpXG4i KTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9JTklUX0VS Uk9SICsgMHgwMzogcHJpbnRmKCJJbnZhbGlkIHJjdiBidXJzdCAoTExEIGVy cm9yKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNhc2UgVFJMTERf SU5JVF9FUlJPUiArIDB4MDQ6IHByaW50ZigiSW52YWxpZCB4bXQgYnVyc3Qg KExMRCBlcnJvcilcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNl IFRSTExEX0lOSVRfRVJST1IgKyAweDA1OiBwcmludGYoIkludmFsaWQgRE1B IHRocmVzaG9sZCAoTExEIGVycm9yKVxuIik7IGJyZWFrOw0KICAgICAgICAg ICAgICAgIGNhc2UgVFJMTERfSU5JVF9FUlJPUiArIDB4MDY6IHByaW50Zigi SW52YWxpZCBzY2IgYWRkclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAg IGNhc2UgVFJMTERfSU5JVF9FUlJPUiArIDB4MDc6IHByaW50ZigiSW52YWxp ZCBzc2IgYWRkclxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNhc2Ug VFJMTERfSU5JVF9FUlJPUiArIDB4MDg6IHByaW50ZigiRElPIHBhcml0eSBl cnJvciAoSFcgZXJyb3IpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAg Y2FzZSBUUkxMRF9JTklUX0VSUk9SICsgMHgwOTogcHJpbnRmKCJETUEgdGlt ZW91dCAoTWF5IGJlIGludGVycnVwdCBmYWlsaW5nIGlmIFBJTyBtb2RlIG9y IFBDSTIpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxM RF9JTklUX0VSUk9SICsgMHgwQTogcHJpbnRmKCJETUEgcGFyaXR5IGVycm9y IChIVyBlcnJvcilcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNl IFRSTExEX0lOSVRfRVJST1IgKyAweDBCOiBwcmludGYoIkRNQSBidXMgZXJy b3IgKEhXIGVycm9yKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNh c2UgVFJMTERfSU5JVF9FUlJPUiArIDB4MEM6IHByaW50ZigiRE1BIGRhdGEg ZXJyb3JcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExE X0lOSVRfRVJST1IgKyAweDBEOiBwcmludGYoIkFkYXB0ZXIgQ2hlY2tcbiIp OyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExEX0lOSVRfVElN RU9VVDogICAgICBwcmludGYoIkFkYXB0ZXIgaW5pdGlhbGl6YXRpb24gZGlk IG5vdCBjb21wbGV0ZVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgIGNh c2UgVFJMTERfSU5JVF9ETUFfRVJST1I6ICAgIHByaW50ZigiQWRhcHRlciBj YW5ub3QgYWNjZXNzIHN5c3RlbSBtZW1vcnlcbiIpOyBicmVhazsNCiAgICAg ICAgICAgICAgICBjYXNlIFRSTExEX0lOSVRfSU5UUl9FUlJPUjogICBwcmlu dGYoIkFkYXB0ZXIgY2Fubm90IGludGVycnVwdFxuIik7IGJyZWFrOw0KICAg ICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9USU1FT1VUOiAgICAgIHBy aW50ZigiQWRhcHRlciBkaWQgbm90IGNvbXBsZXRlIG9wZW4gd2l0aGluIDMw IHNlY29uZHNcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICBjYXNlIFRS TExEX09QRU5fRVJST1IgKyAweDAxOiBwcmludGYoIkludmFsaWQgb3BlbiBv cHRpb25zIChMTEQgZXJyb3IpXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAg ICAgY2FzZSBUUkxMRF9PUEVOX0VSUk9SICsgMHgwNDogcHJpbnRmKCJUeEJ1 ZmZlciBjb3VudCBlcnJvciAoTExEIGVycm9yKVxuIik7IGJyZWFrOw0KICAg ICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9FUlJPUiArIDB4MTA6IHBy aW50ZigiQnVmZmVyIHNpemUgZXJyb3IgKExMRCBlcnJvcilcbiIpOyBicmVh azsNCiAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fRVJST1IgKyAw eDIwOiBwcmludGYoIkxpc3Qgc2l6ZSBlcnJvciAoTExEIGVycm9yKVxuIik7 IGJyZWFrOw0KICAgICAgICAgICAgICAgIGRlZmF1bHQ6IA0KICAgICAgICAg ICAgICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRTdGF0 dXMgJiAweDcwMCkgew0KICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo IChTdGF0dXMtPlNwZWNpZmljYXRpb24uSW5pdFN0YXR1cyAmIDB4NzBGKSB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVO X1JFUEVBVCArIDB4MDE6IHByaW50ZigiTG9iZSBtZWRpYSB0ZXN0IC0gIik7 IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2UgVFJM TERfT1BFTl9SRVBFQVQgKyAweDAyOiBwcmludGYoIlBoeXNpY2FsIGluc2Vy dGlvbiAtICIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHgwMzogcHJpbnRmKCJBZGRy ZXNzIHZlcmlmaWNhdGlvbiAtICIpOyBicmVhazsNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHgwNDog cHJpbnRmKCJQYXJ0aWNpcGF0aW9uIGluIHJpbmcgcG9sbCAtICIpOyBicmVh azsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09Q RU5fUkVQRUFUICsgMHgwNTogcHJpbnRmKCJSZXF1ZXN0IGluaXRpYWxpemF0 aW9uIC0gIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNhc2UgVFJMTERfT1BFTl9SRVBFQVQgKyAweDA5OiBwcmludGYoIlJlcXVl c3QgcmVnaXN0cmF0aW9uIChUWEkpIC0gIik7IGJyZWFrOw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9SRVBFQVQgKyAw eDBBOiBwcmludGYoIkxvYmUgbWVkaWEgdGVzdCAoVFhJKSAtICIpOyBicmVh azsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0OiAgICAg ICAgICAgICAgICAgICAgICAgcHJpbnRmKCJVbmtub3duIHBoYXNlICgleCkg LSAiLCBTdGF0dXMtPlNwZWNpZmljYXRpb24uSW5pdFN0YXR1cyAmIDB4MDBG KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg ICAgICAgICAgIHN3aXRjaCAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkluaXRT dGF0dXMgJiAweDdGMCkgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNhc2UgVFJMTERfT1BFTl9SRVBFQVQgKyAweDEwOiBwcmludGYoIkZ1bmN0 aW9uIGZhaWx1cmUgKE5vIGNhYmxlPylcbiIpOyBicmVhazsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsg MHgyMDogcHJpbnRmKCJTaWduYWwgbG9zc1xuIik7IGJyZWFrOw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfT1BFTl9SRVBFQVQg KyAweDUwOiBwcmludGYoIlRpbWVvdXRcbiIpOyBicmVhazsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsg MHg2MDogcHJpbnRmKCJSaW5nIGZhaWx1cmUgKFRLUCkgLyBQcm90b2NvbCBl cnJvciAoVFhJKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNhc2UgVFJMTERfT1BFTl9SRVBFQVQgKyAweDcwOiBwcmludGYo IlJpbmcgYmVhY29uaW5nXG4iKTsgYnJlYWs7DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JFUEVBVCArIDB4ODA6IHBy aW50ZigiRHVwbGljYXRlIG5vZGUgYWRkcmVzcyAoVEtQKSAvIEluc2VydCBk ZW5pZWQgKFRYSSlcbiIpOyBicmVhazsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjYXNlIFRSTExEX09QRU5fUkVQRUFUICsgMHg5MDogcHJpbnRm KCJSZXF1ZXN0IGluaXRpYWxpemF0aW9uIChUS1ApXG4iKTsgYnJlYWs7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9PUEVOX1JF UEVBVCArIDB4YTA6IHByaW50ZigiUmVtb3ZlIHJlY2VpdmVkXG4iKTsgYnJl YWs7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9P UEVOX1JFUEVBVCArIDB4YjA6IHByaW50ZigiQy1wb3J0IGFkZHJlc3MgY2hh bmdlZCAoVFhJKVxuIik7IGJyZWFrOw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGRlZmF1bHQ6ICAgICAgICAgICAgICAgICAgICAgICBwcmludGYo IlVua25vd24gdHlwZSAoJXgpXG4iLCBTdGF0dXMtPlNwZWNpZmljYXRpb24u SW5pdFN0YXR1cyAmIDB4MEYwKTsNCiAgICAgICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgfSBlbHNlIHsNCiAgICAgICAgICAg ICAgICAgICAgICAgIHByaW50ZigiVW5rbm93biBlcnJvciAoJXgpXG4iLCBT dGF0dXMtPlNwZWNpZmljYXRpb24uSW5pdFN0YXR1cyk7IA0KICAgICAgICAg ICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAgICAgICBicmVh azsNCiAgICAgICAgY2FzZSBUUkxMRF9TVFNfUklOR19TVEFUVVM6DQogICAg ICAgICAgICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlJpbmdTdGF0dXMg IT0gMCkgew0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBSaW5n IHN0YXR1cyBjaGFuZ2U6ICIsIHNjLT51bml0KTsNCiAgICAgICAgICAgICAg ICBpZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlJpbmdTdGF0dXMgJiBUUkxM RF9SU19IQVJEX0VSUk9SKSAgICAgICAgIHByaW50ZigiW0hhcmQgZXJyb3Jd ICIpOw0KICAgICAgICAgICAgICAgIGlmIChTdGF0dXMtPlNwZWNpZmljYXRp b24uUmluZ1N0YXR1cyAmIFRSTExEX1JTX1NPRlRfRVJST1IpICAgICAgICAg cHJpbnRmKCJbU29mdCBlcnJvcl0gIik7DQogICAgICAgICAgICAgICAgaWYg KFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5SaW5nU3RhdHVzICYgVFJMTERfUlNf VFJBTlNNSVRfQkVBQ09OKSAgICBwcmludGYoIltUcmFuc21pdCBiZWFjb25d ICIpOw0KICAgICAgICAgICAgICAgIGlmIChTdGF0dXMtPlNwZWNpZmljYXRp b24uUmluZ1N0YXR1cyAmIFRSTExEX1JTX0xPQkVfV0lSRV9GQVVMVCkgICAg cHJpbnRmKCJbV2lyZSBmYXVsdF0gIik7DQogICAgICAgICAgICAgICAgaWYg KFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5SaW5nU3RhdHVzICYgVFJMTERfUlNf QVVUT19SRU1PVkFMX0VSUk9SKSBwcmludGYoIltBdXRvIHJlbW92YWxdICIp Ow0KICAgICAgICAgICAgICAgIGlmIChTdGF0dXMtPlNwZWNpZmljYXRpb24u UmluZ1N0YXR1cyAmIFRSTExEX1JTX1JFTU9WRV9SRUNFSVZFRCkgICAgcHJp bnRmKCJbUmVtb3ZlIHJlY2VpdmVkXSAiKTsNCiAgICAgICAgICAgICAgICBp ZiAoU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlJpbmdTdGF0dXMgJiBUUkxMRF9S U19DT1VOVEVSX09WRVJGTE9XKSAgIHByaW50ZigiW0NvdW50ZXIgb3ZlcmZs b3ddICIpOw0KICAgICAgICAgICAgICAgIGlmIChTdGF0dXMtPlNwZWNpZmlj YXRpb24uUmluZ1N0YXR1cyAmIFRSTExEX1JTX1NJTkdMRV9TVEFUSU9OKSAg ICAgcHJpbnRmKCJbU2luZ2xlIHN0YXRpb25dICIpOw0KICAgICAgICAgICAg ICAgIGlmIChTdGF0dXMtPlNwZWNpZmljYXRpb24uUmluZ1N0YXR1cyAmIFRS TExEX1JTX1JJTkdfUkVDT1ZFUlkpICAgICAgcHJpbnRmKCJbUmluZyByZWNv dmVyeV0gIik7DQogICAgICAgICAgICAgICAgcHJpbnRmKCJcbiIpOw0KICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgYnJlYWs7DQogICAgICAgIGNhc2Ug VFJMTERfU1RTX0FEQVBURVJfQ0hFQ0s6DQogICAgICAgICAgICBwcmludGYo Im9sdHIlZDogQWRhcHRlciBjaGVjayAoJXggJXggJXggJXgpXG4iLCBzYy0+ dW5pdCwgU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkFkYXB0ZXJDaGVja1swXSwg DQogICAgICAgICAgICAgICAgICAgIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5B ZGFwdGVyQ2hlY2tbMV0sIFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5BZGFwdGVy Q2hlY2tbMl0sIA0KICAgICAgICAgICAgICAgICAgICBTdGF0dXMtPlNwZWNp ZmljYXRpb24uQWRhcHRlckNoZWNrWzNdKTsgDQogICAgICAgICAgICBicmVh azsNCiAgICAgICAgY2FzZSBUUkxMRF9TVFNfUFJPTUlTQ1VPVVNfU1RPUFBF RDoNCiAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBQcm9taXNjdW91cyBt b2RlIHN0b3BwZWQ6ICIsIHNjLT51bml0KTsNCiAgICAgICAgICAgIHN3aXRj aChTdGF0dXMtPlNwZWNpZmljYXRpb24uUHJvbVJlbW92ZWRDYXVzZSkgew0K ICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfUFJPTV9SRU1PVkVfUkVDRUlW RUQ6IHByaW50ZigiUmVtb3ZlIHJlY2VpdmVkXG4iKTsgYnJlYWs7DQogICAg ICAgICAgICAgICAgY2FzZSBUUkxMRF9QUk9NX1BPTExfRkFJTFVSRTogICAg cHJpbnRmKCJQb2xsIGZhaWx1cmVcbiIpOyBicmVhazsNCiAgICAgICAgICAg ICAgICBkZWZhdWx0OiAgICAgICAgICAgICAgICAgICAgICAgICBwcmludGYo IlVua25vd24gKCV4KVxuIiwgU3RhdHVzLT5TcGVjaWZpY2F0aW9uLlByb21S ZW1vdmVkQ2F1c2UpOw0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgYnJl YWs7DQogICAgICAgIGNhc2UgVFJMTERfU1RTX0xMRF9FUlJPUjoNCiAgICAg ICAgICAgIHByaW50Zigib2x0ciVkOiBMTEQgZXJyb3IgKCV4ICV4ICV4ICV4 KSAiLCBzYy0+dW5pdCwgU3RhdHVzLT5TcGVjaWZpY2F0aW9uLkludGVybmFs RXJyb3JbMF0sIA0KICAgICAgICAgICAgICAgICAgICBTdGF0dXMtPlNwZWNp ZmljYXRpb24uSW50ZXJuYWxFcnJvclsxXSwgU3RhdHVzLT5TcGVjaWZpY2F0 aW9uLkludGVybmFsRXJyb3JbMl0sIA0KICAgICAgICAgICAgICAgICAgICBT dGF0dXMtPlNwZWNpZmljYXRpb24uSW50ZXJuYWxFcnJvclszXSk7DQogICAg ICAgICAgICBicmVhazsNCiAgICAgICAgY2FzZSBUUkxMRF9TVFNfQURBUFRF Ul9USU1FT1VUOg0KICAgICAgICAgICAgcHJpbnRmKCJvbHRyJWQ6IEFkYXB0 ZXIgb3BlcmF0aW9uIHRpbWVkIG91dDogIiwgc2MtPnVuaXQpOw0KICAgICAg ICAgICAgc3dpdGNoKFN0YXR1cy0+U3BlY2lmaWNhdGlvbi5BZGFwdGVyVGlt ZW91dCkgew0KICAgICAgICAgICAgICAgIGNhc2UgVFJMTERfQ09NTUFORF9U SU1FT1VUOiAgIHByaW50ZigiQ29tbWFuZFxuIik7DQogICAgICAgICAgICAg ICAgY2FzZSBUUkxMRF9UUkFOU01JVF9USU1FT1VUOiAgcHJpbnRmKCJUcmFu c21pdFxuIik7DQogICAgICAgICAgICAgICAgY2FzZSBUUkxMRF9JTlRFUlJV UFRfVElNRU9VVDogcHJpbnRmKCJJbnRlcnJ1cHRcbiIpOw0KICAgICAgICAg ICAgICAgIGRlZmF1bHQ6ICAgICAgICAgICAgICAgICAgICAgIHByaW50Zigi VW5rbm93biAoJXgpXG4iLCBTdGF0dXMtPlNwZWNpZmljYXRpb24uQWRhcHRl clRpbWVvdXQpOw0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgYnJlYWs7 DQogICAgICAgIGRlZmF1bHQ6DQogICAgICAgICAgICBwcmludGYoIm9sdHIl ZDogVW5rbm93biBzdGF0dXMgdHlwZSAoJXgpXG4iLCBzYy0+dW5pdCwgU3Rh dHVzLT5UeXBlKTsNCg0KICAgIH0NCiAgICBpZiAoU3RhdHVzLT5DbG9zZWQp IHsNCiAgICAgICAgaWYgKHNjLT5od19zdGF0ZSA+IEhXX0JBRCkgew0KICAg ICAgICAgICAgc2MtPmh3X3N0YXRlID0gSFdfRkFJTEVEOw0KICAgICAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IGNsb3NpbmcgYWRhcHRlciBkdWUgdG8gZmFp bHVyZS5cbiIsIHNjLT51bml0KTsNCiAgICAgICAgICAgIG9sdHJfc3RvcChz Yyk7DQogICAgICAgIH0NCiAgICB9DQp9DQoNCnN0YXRpYyB2b2lkDQpEcml2 ZXJDbG9zZUNvbXBsZXRlZChEcml2ZXJIYW5kbGUpDQogICAgdm9pZCAqRHJp dmVySGFuZGxlOw0Kew0KICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9ICZv bHRyX3NvZnRjWyhpbnQpRHJpdmVySGFuZGxlXTsNCg0KICAgIHByaW50Zigi b2x0ciVkOiBEcml2ZXJDbG9zZUNvbXBsZXRlZFxuIiwgc2MtPnVuaXQpOw0K DQogICAgdW50aW1lb3V0KG9sdHJfdGltZW91dCwgKHZvaWQgKilzYy0+dW5p dCwgc2MtPm9sdHJfY2gpOw0KICAgIHdha2V1cF9vbmUoKHZvaWQgKilzYy0+ dW5pdCk7DQoNCiAgICBpZiAoKHNjLT5od19zdGF0ZSAhPSBIV19DTE9TSU5H KSAmJiAoc2MtPmh3X3N0YXRlICE9IEhXX0NMT1NJTkcyKSAmJiAoc2MtPmh3 X3N0YXRlICE9IEhXX0NMT1NFRCkpIHsNCiAgICAgICAgcHJpbnRmKCJvbHRy JWQ6IGFkYXB0ZXIgY2xvc2UgY29tcGxldGUgY2FsbGVkIGluIHdyb25nIHN0 YXRlICglZClcbiIsIHNjLT51bml0LCBzYy0+aHdfc3RhdGUpOw0KICAgICAg ICByZXR1cm47DQogICAgfQ0KICAgIHNjLT5od19zdGF0ZSA9IEhXX0NMT1NJ TkcyOw0KICAgIGlmIChzYy0+Y29uZmlnLT5kbWFsZXZlbCAhPSBUUkxMRF9E TUFfUElPKQ0KICAgICAgICBpc2FfZG1hX3JlbGVhc2Uoc2MtPmNvbmZpZy0+ ZG1hbGV2ZWwpOw0KICAgIA0KfQ0KDQpzdGF0aWMgdm9pZA0KRHJpdmVyU3Rh dGlzdGljcyhEcml2ZXJIYW5kbGUsIFN0YXRpc3RpY3MpDQogICAgdm9pZCAq RHJpdmVySGFuZGxlOw0KICAgIFRSbGxkU3RhdGlzdGljc190ICpTdGF0aXN0 aWNzOw0Kew0KICAgIHByaW50Zigib2x0cjogRHJpdmVyU3RhdGlzdGljc1xu Iik7DQp9DQoNCnN0YXRpYyB2b2lkDQpEcml2ZXJUcmFuc21pdEZyYW1lQ29t cGxldGVkKERyaXZlckhhbmRsZSwgRnJhbWVIYW5kbGUsIFRyYW5zbWl0U3Rh dHVzKQ0KICAgIHZvaWQgKkRyaXZlckhhbmRsZTsNCiAgICB2b2lkICpGcmFt ZUhhbmRsZTsNCiAgICBpbnQgVHJhbnNtaXRTdGF0dXM7DQp7DQogICAgaW50 IGZyYW1lID0gKGludClGcmFtZUhhbmRsZTsNCiAgICBzdHJ1Y3Qgb2x0cl9z b2Z0YyAqc2MgPSAmb2x0cl9zb2Z0Y1soaW50KURyaXZlckhhbmRsZV07DQog ICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2MtPmFycGNvbS5hY19pZjsNCg0K ICAgIGlmIChpZnAtPmlmX2ZsYWdzICYgSUZGX09BQ1RJVkUpDQogICAgICAg IGlmcC0+aWZfZmxhZ3MgJj0gfihJRkZfT0FDVElWRSk7DQoNCiAgICAvKnBy aW50Zigib2x0ciVkOiB0cmFuc21pdCBjb21wbGV0ZSBmcmFtZSAlZFxuIiwg c2MtPnVuaXQsIGZyYW1lKTsqLw0KICAgIGlmIChUcmFuc21pdFN0YXR1cyA9 PSBUUkxMRF9UUkFOU01JVF9PSykgew0KICAgICAgICBpZnAtPmlmX29wYWNr ZXRzKys7DQogICAgfSBlbHNlIHsNCiAgICAgICAgcHJpbnRmKCJvbHRyJWQ6 IERyaXZlclRyYW5zbWl0RnJhbWVDb21wbGV0ZWQgKEZyYW1lICVkIHN0YXR1 cyAleClcbiIsIHNjLT51bml0LCBmcmFtZSwgVHJhbnNtaXRTdGF0dXMpOw0K ICAgICAgICBpZnAtPmlmX29lcnJvcnMrKzsNCiAgICB9DQogICAgaWYgKChm cmFtZSA8IDApIHx8IChmcmFtZSA+IFRYX0xJU1RfU0laRSkpIHsNCiAgICAg ICAgcHJpbnRmKCJvbHRyJWQ6IGJvZ3VzIHRyYW5zbWl0IGJ1ZmZlci4gKCVk KVxuIiwgc2MtPnVuaXQsIGZyYW1lKTsNCiAgICAgICAgcmV0dXJuOw0KICAg IH0NCg0KICAgIHNjLT50eF9hdmFpbCsrOw0KDQp9DQoNCnN0YXRpYyB2b2lk DQpEcml2ZXJSZWNlaXZlRnJhbWVDb21wbGV0ZWQoRHJpdmVySGFuZGxlLCBC eXRlQ291bnQsIEZyYWdtZW50Q291bnQsIEZyYWdtZW50SGFuZGxlLCBSZWNl aXZlU3RhdHVzKQ0KICAgIHZvaWQgKkRyaXZlckhhbmRsZTsNCiAgICBpbnQg Qnl0ZUNvdW50Ow0KICAgIGludCBGcmFnbWVudENvdW50Ow0KICAgIHZvaWQg KkZyYWdtZW50SGFuZGxlOw0KICAgIGludCBSZWNlaXZlU3RhdHVzOw0Kew0K ICAgIHN0cnVjdCBvbHRyX3NvZnRjICpzYyA9ICZvbHRyX3NvZnRjWyhpbnQp RHJpdmVySGFuZGxlXTsNCiAgICBzdHJ1Y3QgaWZuZXQgKmlmcCA9ICZzYy0+ YXJwY29tLmFjX2lmOw0KICAgIHN0cnVjdCBpc284ODAyNV9oZWFkZXIgKnRo Ow0KICAgIHN0cnVjdCBtYnVmICptMCwgKm0xLCAqbTsNCiAgICBpbnQgaiA9 IChpbnQpRnJhZ21lbnRIYW5kbGUsIHJjLCBmcmFtZV9sZW4gPSBCeXRlQ291 bnQsIG1hY19oZHJfbGVuOw0KICAgIGludCBtYnVmX29mZnNldCwgbWJ1Zl9z aXplLCBmcmFnX29mZnNldCwgbGVuZ3RoOw0KICAgIGNoYXIgKmZyYWcgPSBz Yy0+cnhfYnVmZmVyW2pdLmJ1ZjsNCg0KICAgIC8qcHJpbnRmKCJvbHRyJWQ6 IFJlY2VpdmVGcmFtZUNvbXBsZXRlZCAoU2l6ZSAlZCBDb3VudCAlZCBTdGFy dCAlZClcbiIsIHNjLT51bml0LCBCeXRlQ291bnQsIEZyYWdtZW50Q291bnQs IGopOyovDQoNCiAgICBpZiAoc2MtPmh3X3N0YXRlID49ICBIV19PUEVOKSB7 ICAgICAgICAgICAgIC8qIEhhcmR3YXJlIG9wZXJhdGluZyBub3JtYWxseSAq Lw0KICAgICAgICBpZiAoZnJhZyAhPSBzYy0+cnhfYnVmZmVyW3NjLT5yeF9u ZXh0ICYgUlhfTElTVF9NQVNLXS5idWYpIHsNCiAgICAgICAgICAgIHByaW50 Zigib2x0ciVkOiByaW5nIGJ1ZmZlciBwb2ludGVyIGJsb3duXG4iLCBzYy0+ dW5pdCk7DQogICAgICAgICAgICBvbHRyX3N0b3Aoc2MpOw0KICAgICAgICAg ICAgcmV0dXJuOw0KICAgICAgICB9DQogICAgICAgIGlmIChSZWNlaXZlU3Rh dHVzID09IFRSTExEX1JDVl9PSykgeyAgICAvKiBSZWNlaXZlIGdvb2QgZnJh bWUgKi8NCiAgICAgICAgICAgIE1HRVRIRFIobTAsIE1fRE9OVFdBSVQsIE1U X0RBVEEpOw0KICAgICAgICAgICAgbWJ1Zl9zaXplID0gTUhMRU47DQogICAg ICAgICAgICBpZiAobTAgPT0gTlVMTCkgew0KICAgICAgICAgICAgICAgIGlm cC0+aWZfaWVycm9ycysrOw0KICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0K ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgaWYgKEJ5dGVDb3VudCArIDIg PiBNSExFTikgew0KICAgICAgICAgICAgICAgIE1DTEdFVChtMCwgTV9ET05U V0FJVCk7DQogICAgICAgICAgICAgICAgbWJ1Zl9zaXplID0gTUNMQllURVM7 DQogICAgICAgICAgICAgICAgaWYgKChtMC0+bV9mbGFncyAmIE1fRVhUKSA9 PSAwKSB7DQogICAgICAgICAgICAgICAgICAgIG1fZnJlZW0obTApOw0KICAg ICAgICAgICAgICAgICAgICBpZnAtPmlmX2llcnJvcnMrKzsNCiAgICAgICAg ICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgfQ0KDQogICAgICAgICAgICBtMC0+bV9wa3RoZHIucmN2aWYg PSAmc2MtPmFycGNvbS5hY19pZjsNCiAgICAgICAgICAgIG0wLT5tX3BrdGhk ci5sZW4gPSBCeXRlQ291bnQ7DQogICAgICAgICAgICBtMC0+bV9sZW4gPSAw Ow0KICAgICAgICAgICAgbTAtPm1fZGF0YSArPSAyOw0KICAgICAgICAgICAg bWJ1Zl9zaXplIC09MjsNCiAgICAgICAgICAgIHRoID0gbXRvZChtMCwgc3Ry dWN0IGlzbzg4MDI1X2hlYWRlciAqKTsNCg0KICAgICAgICAgICAgbSA9IG0w OyBtYnVmX29mZnNldCA9IDA7IGZyYWdfb2Zmc2V0ID0gMDsNCiAgICAgICAg ICAgIHdoaWxlIChmcmFtZV9sZW4gPiAwKSB7DQogICAgICAgICAgICAgICAg bGVuZ3RoID0gTUlOMyhmcmFtZV9sZW4sIChSWF9CVUZGRVJfTEVOIC0gZnJh Z19vZmZzZXQpLCAobWJ1Zl9zaXplIC0gbWJ1Zl9vZmZzZXQpKTsNCiAgICAg ICAgICAgICAgICBiY29weShmcmFnICsgZnJhZ19vZmZzZXQsIG10b2QobSwg Y2hhciAqKSArIG1idWZfb2Zmc2V0LCBsZW5ndGgpOw0KICAgICAgICAgICAg ICAgIG0tPm1fbGVuICs9IGxlbmd0aDsNCiAgICAgICAgICAgICAgICBtYnVm X29mZnNldCArPSBsZW5ndGg7DQogICAgICAgICAgICAgICAgZnJhZ19vZmZz ZXQgKz0gbGVuZ3RoOw0KICAgICAgICAgICAgICAgIGZyYW1lX2xlbiAtPSBs ZW5ndGg7DQogICAgICAgICAgICAgICAgaWYgKGZyYWdfb2Zmc2V0ID09IFJY X0JVRkZFUl9MRU4pIHsNCiAgICAgICAgICAgICAgICAgICAgZnJhZyA9IHNj LT5yeF9idWZmZXJbKytqXS5idWY7DQogICAgICAgICAgICAgICAgICAgIGZy YWdfb2Zmc2V0ID0gMDsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgICAgaWYgKChtYnVmX29mZnNldCA9PSBtYnVmX3NpemUpICYmIChmcmFt ZV9sZW4gPiAwKSkgew0KICAgICAgICAgICAgICAgICAgICBNR0VUKG0xLCBN X0RPTlRXQUlULCBNVF9EQVRBKTsNCiAgICAgICAgICAgICAgICAgICAgbWJ1 Zl9zaXplID0gTUhMRU47DQogICAgICAgICAgICAgICAgICAgIGlmIChtMSA9 PSBOVUxMKSB7DQogICAgICAgICAgICAgICAgICAgICAgICBpZnAtPmlmX2ll cnJvcnMrKzsNCiAgICAgICAgICAgICAgICAgICAgICAgIG1fZnJlZW0obTAp Ow0KICAgICAgICAgICAgICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAg ICAgICAgICAgICAgIH0gIA0KICAgICAgICAgICAgICAgICAgICBpZiAoZnJh bWVfbGVuID4gTUhMRU4pIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE1D TEdFVChtMSwgTV9ET05UV0FJVCk7DQogICAgICAgICAgICAgICAgICAgICAg ICBtYnVmX3NpemUgPSBNQ0xCWVRFUzsNCiAgICAgICAgICAgICAgICAgICAg ICAgIGlmICgobTEtPm1fZmxhZ3MgJiBNX0VYVCkgPT0gMCkgew0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG1fZnJlZW0obTApOw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG1fZnJlZW0obTEpOw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmcC0+aWZfaWVycm9ycysrOw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KICAgICAgICAgICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgICAgICAgIG0tPm1fbmV4dCA9IG0xOw0KICAgICAgICAgICAgICAgICAg ICBtID0gbTE7DQogICAgICAgICAgICAgICAgICAgIG1idWZfb2Zmc2V0ID0g MDsNCiAgICAgICAgICAgICAgICAgICAgbS0+bV9sZW4gPSAwOw0KICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGlmcC0+ aWZfaXBhY2tldHMrKzsNCiAgICAgICAgDQojaWYgTkJQRklMVEVSID4gMA0K ICAgICAgICAgICAgaWYgKGlmcC0+aWZfYnBmKQ0KICAgICAgICAgICAgICAg IGJwZl9tdGFwKGlmcCwgbTApOw0KI2VuZGlmDQoNCiAgICAgICAgICAgIGlm IChpZnAtPmlmX2ZsYWdzICYgSUZGX1BST01JU0MpDQogICAgICAgICAgICAg ICAgaWYgKGJjbXAodGgtPmlzbzg4MDI1X2Rob3N0LCBldGhlcmJyb2FkY2Fz dGFkZHIsIHNpemVvZih0aC0+aXNvODgwMjVfZGhvc3QpKSAhPSAwKSB7DQog ICAgICAgICAgICAgICAgICAgIGlmICgoKHRoLT5pc284ODAyNV9kaG9zdFsw XSAmIDB4N2YpICE9IHNjLT5hcnBjb20uYWNfZW5hZGRyWzBdKSB8fA0KICAg ICAgICAgICAgICAgICAgICAgICAgKGJjbXAodGgtPmlzbzg4MDI1X2Rob3N0 ICsgMSwgc2MtPmFycGNvbS5hY19lbmFkZHIgKyAxLCBJU084ODAyNV9BRERS X0xFTiAtIDEpKSkgew0KCSAgICAgICAgICAgICAgICBtX2ZyZWVtKG0wKTsN CiAgICAgICAgICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KICAgICAgICAg ICAgICAgICAgICB9DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIG1h Y19oZHJfbGVuID0gSVNPODgwMjVfSERSX0xFTjsNCiAgICAgICAgICAgIGlm ICh0aC0+aXNvODgwMjVfc2hvc3RbMF0gJiAweDgwKSAvKiBDaGVjayBmb3Ig c291cmNlIHJvdXRpbmcgaW5mbyAqLw0KICAgICAgICAgICAgICAgIG1hY19o ZHJfbGVuICs9ICAobnRvaHModGgtPnJjZikgJiAweDFmMDApID4+IDg7DQog ICAgICAgICAgICANCiAgICAgICAgICAgIG0wLT5tX3BrdGhkci5sZW4gLT0g bWFjX2hkcl9sZW47DQogICAgICAgICAgICBtMC0+bV9sZW4gLT0gbWFjX2hk cl9sZW47DQogICAgICAgICAgICBtMC0+bV9kYXRhICs9IG1hY19oZHJfbGVu Ow0KDQogICAgICAgICAgICBpc284ODAyNV9pbnB1dCgmc2MtPmFycGNvbS5h Y19pZiwgdGgsIG0wKTsNCg0KICAgICAgICB9IGVsc2Ugew0KICAgICAgICAg ICAgaWYgKFJlY2VpdmVTdGF0dXMgIT0gVFJMTERfUkNWX05PX0RBVEEpIHsN CiAgICAgICAgICAgICAgICBwcmludGYoIm9sdHIlZDogcmVjZWl2ZSBlcnJv ci4gKFJlY2VpdmVTdGF0dXM9JWQpXG4iLCBzYy0+dW5pdCwgUmVjZWl2ZVN0 YXR1cyk7DQogICAgICAgICAgICAgICAgaWZwLT5pZl9pZXJyb3JzKys7DQog ICAgICAgICAgICB9DQogICAgICAgIH0NCm91dDoNCiAgICAgICAgd2hpbGUg KEZyYWdtZW50Q291bnQgPiAwKSB7DQogICAgICAgICAgICByYyA9IFRSbGxk UmVjZWl2ZUZyYWdtZW50KHNjLT5UUmxsZEFkYXB0ZXIsIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2b2lkICopc2MtPnJ4X2J1 ZmZlcltzYy0+cnhfbmV4dCAmIFJYX0xJU1RfTUFTS10uYnVmLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGt2dG9wKHNjLT5yeF9i dWZmZXJbc2MtPnJ4X25leHQgJiBSWF9MSVNUX01BU0tdLmJ1ZiksDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUlhfQlVGRkVSX0xF TiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodm9p ZCAqKXNjLT5yeF9idWZmZXJbc2MtPnJ4X25leHQgJiBSWF9MSVNUX01BU0td LmluZGV4KTsNCiAgICAgICAgICAgIGlmIChyYyA9PSBUUkxMRF9SRUNFSVZF X09LKSB7DQogICAgICAgICAgICAgICAgc2MtPnJ4X25leHQrKzsNCiAgICAg ICAgICAgICAgICBGcmFnbWVudENvdW50LS07DQogICAgICAgICAgICB9IGVs c2Ugew0KICAgICAgICAgICAgICAgIHByaW50Zigib2x0ciVkOiBBZGFwdGVy IHJlZnVzZWQgZnJhZ21lbnQgKCVkKS5cbiIsIHNjLT51bml0LCBzYy0+cnhf bmV4dCAtIDEpOw0KICAgICAgICAgICAgICAgIHNjLT5yeF9hdmFpbCArPSBG cmFnbWVudENvdW50Ow0KICAgICAgICAgICAgICAgIGJyZWFrOw0KICAgICAg ICAgICAgfQ0KICAgICAgICB9DQogICAgfSBlbHNlIHsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvKiBIYXJkd2FyZSBiZWluZyBjbG9z ZWQgKi8NCiAgICAgICAgaWYgKGZyYWcgIT0gc2MtPnJ4X2J1ZmZlcltzYy0+ cnhfbmV4dCsrICYgUlhfTElTVF9NQVNLXS5idWYpIHsNCiAgICAgICAgICAg IHByaW50Zigib2x0ciVkOiByaW5nIGJ1ZmZlciBwb2ludGVyIGJsb3duXG4i LCBzYy0+dW5pdCk7ICANCiAgICAgICAgfSAgICAgICAgICAgDQogICAgICAg IHNjLT5yeF9hdmFpbCArPSBGcmFnbWVudENvdW50Ow0KICAgIH0NCiAgICAN Cn0NCg0KDQovKg0KICogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBQ TVcgR2x1ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogKi8N Cg0KI2lmbmRlZiBUUmxsZElubGluZUlPDQoNCnN0YXRpYyB2b2lkIA0KRHJp dmVyT3V0Qnl0ZShJT0FkZHJlc3MsIHZhbHVlKQ0KICAgIHVuc2lnbmVkIHNo b3J0IElPQWRkcmVzczsNCiAgICB1bnNpZ25lZCBjaGFyIHZhbHVlOw0Kew0K ICAgIG91dGIoSU9BZGRyZXNzLCB2YWx1ZSk7DQp9DQoNCnN0YXRpYyB2b2lk DQpEcml2ZXJPdXRXb3JkKElPQWRkcmVzcywgdmFsdWUpDQogICAgdW5zaWdu ZWQgc2hvcnQgSU9BZGRyZXNzOw0KICAgIHVuc2lnbmVkIHNob3J0IHZhbHVl Ow0Kew0KICAgIG91dHcoSU9BZGRyZXNzLCB2YWx1ZSk7DQp9DQoNCnN0YXRp YyB2b2lkDQpEcml2ZXJPdXREd29yZChJT0FkZHJlc3MsIHZhbHVlKQ0KICAg IHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCiAgICB1bnNpZ25lZCBsb25n IHZhbHVlOw0Kew0KICAgIG91dGwoSU9BZGRyZXNzLCB2YWx1ZSk7DQp9DQoN CnN0YXRpYyB2b2lkDQpEcml2ZXJSZXBPdXRCeXRlKElPQWRkcmVzcywgRGF0 YVBvaW50ZXIsIEJ5dGVDb3VudCkNCiAgICB1bnNpZ25lZCBzaG9ydCBJT0Fk ZHJlc3M7DQogICAgdW5zaWduZWQgY2hhciAgKkRhdGFQb2ludGVyOw0KICAg IGludCBCeXRlQ291bnQ7DQp7DQogICAgb3V0c2IoSU9BZGRyZXNzLCAodm9p ZCAqKURhdGFQb2ludGVyLCBCeXRlQ291bnQpOw0KfQ0KDQpzdGF0aWMgdm9p ZA0KRHJpdmVyUmVwT3V0V29yZChJT0FkZHJlc3MsIERhdGFQb2ludGVyLCBX b3JkQ291bnQpDQogICAgdW5zaWduZWQgc2hvcnQgSU9BZGRyZXNzOw0KICAg IHVuc2lnbmVkIHNob3J0ICpEYXRhUG9pbnRlcjsNCiAgICBpbnQgV29yZENv dW50Ow0Kew0KICAgIG91dHN3KElPQWRkcmVzcywgKHZvaWQgKilEYXRhUG9p bnRlciwgV29yZENvdW50KTsNCn0NCg0Kc3RhdGljIHZvaWQNCkRyaXZlclJl cE91dER3b3JkKElPQWRkcmVzcywgRGF0YVBvaW50ZXIsIERXb3JkQ291bnQp DQogICAgdW5zaWduZWQgc2hvcnQgSU9BZGRyZXNzOw0KICAgIHVuc2lnbmVk IGxvbmcgICpEYXRhUG9pbnRlcjsNCiAgICBpbnQgRFdvcmRDb3VudDsNCnsN CiAgICBvdXRzbChJT0FkZHJlc3MsICh2b2lkICopRGF0YVBvaW50ZXIsIERX b3JkQ291bnQpOw0KfQ0KDQpzdGF0aWMgdW5zaWduZWQgY2hhcg0KRHJpdmVy SW5CeXRlKElPQWRkcmVzcykNCiAgICB1bnNpZ25lZCBzaG9ydCBJT0FkZHJl c3M7DQp7DQogICAgcmV0dXJuKGluYihJT0FkZHJlc3MpKTsNCn0NCg0Kc3Rh dGljIHVuc2lnbmVkIHNob3J0DQpEcml2ZXJJbldvcmQoSU9BZGRyZXNzKQ0K ICAgIHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCnsNCiAgIHJldHVybihp bncoSU9BZGRyZXNzKSk7DQp9DQoNCnN0YXRpYyB1bnNpZ25lZCBsb25nDQpE cml2ZXJJbkR3b3JkKElPQWRkcmVzcykNCiAgICB1bnNpZ25lZCBzaG9ydCBJ T0FkZHJlc3M7DQp7DQogICAgcmV0dXJuKGlubChJT0FkZHJlc3MpKTsNCn0N Cg0Kc3RhdGljIHZvaWQNCkRyaXZlclJlcEluQnl0ZShJT0FkZHJlc3MsIERh dGFQb2ludGVyLCBCeXRlQ291bnQpDQogICAgdW5zaWduZWQgc2hvcnQgSU9B ZGRyZXNzOw0KICAgIHVuc2lnbmVkIGNoYXIgICpEYXRhUG9pbnRlcjsNCiAg ICBpbnQgQnl0ZUNvdW50Ow0Kew0KICAgIGluc2IoSU9BZGRyZXNzLCAodm9p ZCAqKURhdGFQb2ludGVyLCBCeXRlQ291bnQpOw0KfQ0KDQpzdGF0aWMgdm9p ZA0KRHJpdmVyUmVwSW5Xb3JkKElPQWRkcmVzcywgRGF0YVBvaW50ZXIsIFdv cmRDb3VudCkNCiAgICB1bnNpZ25lZCBzaG9ydCBJT0FkZHJlc3M7DQogICAg dW5zaWduZWQgc2hvcnQgKkRhdGFQb2ludGVyOw0KICAgIGludCBXb3JkQ291 bnQ7DQp7DQogICAgaW5zdyhJT0FkZHJlc3MsICh2b2lkICopRGF0YVBvaW50 ZXIsIFdvcmRDb3VudCk7DQp9DQpzdGF0aWMgdm9pZA0KRHJpdmVyUmVwSW5E d29yZChJT0FkZHJlc3MsIERhdGFQb2ludGVyLCBEV29yZENvdW50KQ0KICAg IHVuc2lnbmVkIHNob3J0IElPQWRkcmVzczsNCiAgICB1bnNpZ25lZCBsb25n ICAqRGF0YVBvaW50ZXI7DQogICAgaW50IERXb3JkQ291bnQ7DQp7DQogICAg aW5zbChJT0FkZHJlc3MsICh2b2lkICopRGF0YVBvaW50ZXIsIERXb3JkQ291 bnQpOw0KfQ0KI2VuZGlmIC8qIFRSbGxkSW5saW5lSU8gKi8NCg0KI2VuZGlm IC8qIE5PTFRSICovDQo= --0-519715650-918591506=:14147-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 12:32:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02859 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 12:32:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02842 for ; Tue, 9 Feb 1999 12:32:35 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id PAA01035; Tue, 9 Feb 1999 15:23:27 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 15:23:26 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: NFS Alignment? was (Re: Why did this panic?) In-Reply-To: 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 By the way, is the "m->m_data += 2;" still a neccesary evil to apease NFS? I have always seen it in drivers but I never understood why it was there or if I really needed to follow it. from if_ed.c: 2727-2732 /* * The +2 is to longword align the start of the real packet. * This is important for NFS. */ m->m_data += 2; eh = mtod(m, struct ether_header *); Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 13:04:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06861 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 13:04:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06855 for ; Tue, 9 Feb 1999 13:04:09 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id PAA02199; Tue, 9 Feb 1999 15:55:13 -0500 (EST) (envelope-from lile@stdio.com) Date: Tue, 9 Feb 1999 15:55:12 -0500 (EST) From: Larry Lile To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: 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 That appears to have fixed it! 15:56:18.034874 snap ip cyntok.1053 > anatok.ftp-data: P 405097:406881(1784) ack 1 win 15840 (ttl 60, id 43522) 15:56:18.037594 snap ip cyntok.1053 > anatok.ftp-data: . 406881:410841(3960) ack 1 win 15840 (ttl 60, id 43523) 15:56:18.038038 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) 15:56:18.039735 snap ip cyntok.1053 > anatok.ftp-data: . 410841:414801(3960) ack 1 win 15840 (ttl 60, id 43524) 15:56:18.039780 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) 15:56:18.040342 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) 15:56:18.041825 snap ip cyntok.1053 > anatok.ftp-data: . 414801:418761(3960) ack 1 win 15840 (ttl 60, id 43525) 15:56:18.041867 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) 15:56:18.045938 snap ip cyntok.1053 > anatok.ftp-data: . 418761:422721(3960) ack 1 win 15840 (ttl 60, id 43526) 15:56:18.046106 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) 15:56:18.046263 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) 15:56:18.048370 snap ip cyntok.1053 > anatok.ftp-data: P 422721:426681(3960) ack 1 win 15840 (ttl 60, id 43527) 15:56:18.048685 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) 15:56:18.048828 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) 15:56:18.052509 snap ip cyntok.1053 > anatok.ftp-data: . 426681:430641(3960) ack 1 win 15840 (ttl 60, id 43528) 15:56:18.052995 snap ip anatok.ftp-data > cyntok.1053: . ack 430641 win 15496 (DF) [tos 0x8] (ttl 64, id 42862) Nice big 3k packets! It does seem that FreeBSD will not generate a packet bigger than 2048 though. 16:00:41.593756 snap ip anatok.ftp-data > cyntok.1056: . 223233:225281(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44259) 16:00:41.595001 snap ip anatok.ftp-data > cyntok.1056: . 225281:227329(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44260) 16:00:41.595930 snap ip anatok.ftp-data > cyntok.1056: . 227329:229377(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44261) 16:00:41.596980 snap ip anatok.ftp-data > cyntok.1056: . 229377:231425(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44262) 16:00:41.597952 snap ip cyntok.1056 > anatok.ftp-data: . ack 227329 win 15840 (ttl 60, id 44715) 16:00:41.598110 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) 16:00:41.598244 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) 16:00:41.598374 snap ip anatok.ftp-data > cyntok.1056: . 235521:237569(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44265) 16:00:41.598509 snap ip anatok.ftp-data > cyntok.1056: . 237569:239617(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44266) 16:00:41.598632 snap ip anatok.ftp-data > cyntok.1056: . 239617:241665(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44267) 16:00:41.599962 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) 16:00:41.600782 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) But that's another problem. Any idea where in the stack that is happening? Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 13:29:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10086 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 13:29:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10069 for ; Tue, 9 Feb 1999 13:29:29 -0800 (PST) (envelope-from mark.hannon@stockholm.mail.telia.com) Received: from d1o1.telia.com (root@d1o1.telia.com [195.67.240.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id WAA24704 for ; Tue, 9 Feb 1999 22:29:27 +0100 (CET) Received: from doorway.home.lan (t8o1p15.telia.com [195.67.241.195]) by d1o1.telia.com (8.8.8/8.8.5) with ESMTP id WAA10311 for ; Tue, 9 Feb 1999 22:29:25 +0100 (CET) Received: from stockholm.mail.telia.com (putte.home.lan [192.168.255.2]) by doorway.home.lan (8.8.8/8.8.7) with ESMTP id WAA04645; Tue, 9 Feb 1999 22:11:07 +0100 (CET) (envelope-from mark.hannon@stockholm.mail.telia.com) Message-ID: <36C0A3C4.E9CDA301@stockholm.mail.telia.com> Date: Tue, 09 Feb 1999 22:08:20 +0100 From: Mark Hannon X-Mailer: Mozilla 4.06 [en] (Win98; I) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Change to inherit nodump flag? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I dump some of my filesystems to my (small) floppy tape drive as backup. This works quite well as long as I only dump my own data files. To avoid dumping easily recoverable files I run a script which runs: chflags -R nodump /home/ncvs chflags -R nodump /home/freebsd-src chflags -R nodump /home/freebsd-obj prior to starting the dump. As you can imagine this traversal of the tree is a time consuming affair. As a way around this I thought maybe the nodump flags could be made inheritable, ie I would only need to set nodump on the parent directory and then all subdirs and files would also get nodump marked. Is this a good idea? I had a quick look in the code and I am guessing that I should implement such a change in: /sys/ufs/ufs/ufs_vnops.c in functions ufs_makeinode & ufs_mkdir Is this where the functionality should be implemented? Regards/Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 13:52:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12976 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 13:52:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12968 for ; Tue, 9 Feb 1999 13:52:32 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA09844; Tue, 9 Feb 1999 13:47:36 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdRy9842; Tue Feb 9 21:47:35 1999 Date: Tue, 9 Feb 1999 13:47:32 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: NFS Alignment? was (Re: Why did this panic?) In-Reply-To: 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 ethernet headers are 14 bytes they are trying to allign the IP header on a word boundary.. julian On Tue, 9 Feb 1999, Larry Lile wrote: > > By the way, is the "m->m_data += 2;" still a neccesary evil to > apease NFS? I have always seen it in drivers but I never understood > why it was there or if I really needed to follow it. > > from if_ed.c: 2727-2732 > > /* > * The +2 is to longword align the start of the real packet. > * This is important for NFS. > */ > m->m_data += 2; > eh = mtod(m, struct ether_header *); > > Larry Lile > lile@stdio.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 13:52:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12998 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 13:52:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12991 for ; Tue, 9 Feb 1999 13:52:41 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA09734; Tue, 9 Feb 1999 13:43:56 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdul9721; Tue Feb 9 21:43:51 1999 Date: Tue, 9 Feb 1999 13:43:42 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: 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 try UDP On Tue, 9 Feb 1999, Larry Lile wrote: > > That appears to have fixed it! > > 15:56:18.034874 snap ip cyntok.1053 > anatok.ftp-data: P 405097:406881(1784) ack 1 win 15840 (ttl 60, id 43522) > 15:56:18.037594 snap ip cyntok.1053 > anatok.ftp-data: . 406881:410841(3960) ack 1 win 15840 (ttl 60, id 43523) > 15:56:18.038038 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) > 15:56:18.039735 snap ip cyntok.1053 > anatok.ftp-data: . 410841:414801(3960) ack 1 win 15840 (ttl 60, id 43524) > 15:56:18.039780 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) > 15:56:18.040342 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) > 15:56:18.041825 snap ip cyntok.1053 > anatok.ftp-data: . 414801:418761(3960) ack 1 win 15840 (ttl 60, id 43525) > 15:56:18.041867 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) > 15:56:18.045938 snap ip cyntok.1053 > anatok.ftp-data: . 418761:422721(3960) ack 1 win 15840 (ttl 60, id 43526) > 15:56:18.046106 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) > 15:56:18.046263 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) > 15:56:18.048370 snap ip cyntok.1053 > anatok.ftp-data: P 422721:426681(3960) ack 1 win 15840 (ttl 60, id 43527) > 15:56:18.048685 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) > 15:56:18.048828 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) > 15:56:18.052509 snap ip cyntok.1053 > anatok.ftp-data: . 426681:430641(3960) ack 1 win 15840 (ttl 60, id 43528) > 15:56:18.052995 snap ip anatok.ftp-data > cyntok.1053: . ack 430641 win 15496 (DF) [tos 0x8] (ttl 64, id 42862) > > Nice big 3k packets! It does seem that FreeBSD will not generate a packet > bigger than 2048 though. > > 16:00:41.593756 snap ip anatok.ftp-data > cyntok.1056: . 223233:225281(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44259) > 16:00:41.595001 snap ip anatok.ftp-data > cyntok.1056: . 225281:227329(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44260) > 16:00:41.595930 snap ip anatok.ftp-data > cyntok.1056: . 227329:229377(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44261) > 16:00:41.596980 snap ip anatok.ftp-data > cyntok.1056: . 229377:231425(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44262) > 16:00:41.597952 snap ip cyntok.1056 > anatok.ftp-data: . ack 227329 win 15840 (ttl 60, id 44715) > 16:00:41.598110 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) > 16:00:41.598244 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) > 16:00:41.598374 snap ip anatok.ftp-data > cyntok.1056: . 235521:237569(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44265) > 16:00:41..598509 snap ip anatok.ftp-data > cyntok.1056: . 237569:239617(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44266) > 16:00:41.598632 snap ip anatok.ftp-data > cyntok.1056: . 239617:241665(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44267) > 16:00:41.599962 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) > 16:00:41.600782 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) > > But that's another problem. Any idea where in the stack that is > happening? > > Larry Lile > lile@stdio.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 13:52:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13012 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 13:52:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13004 for ; Tue, 9 Feb 1999 13:52:43 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA09711; Tue, 9 Feb 1999 13:43:16 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdmC9706; Tue Feb 9 21:43:11 1999 Date: Tue, 9 Feb 1999 13:43:07 -0800 (PST) From: Julian Elischer To: Larry Lile cc: hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: 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 probably the fact that as soon as a cluster is filled, it's sent.. On Tue, 9 Feb 1999, Larry Lile wrote: > > That appears to have fixed it! > > 15:56:18.034874 snap ip cyntok.1053 > anatok.ftp-data: P 405097:406881(1784) ack 1 win 15840 (ttl 60, id 43522) > 15:56:18.037594 snap ip cyntok.1053 > anatok.ftp-data: . 406881:410841(3960) ack 1 win 15840 (ttl 60, id 43523) > 15:56:18.038038 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) > 15:56:18.039735 snap ip cyntok.1053 > anatok.ftp-data: . 410841:414801(3960) ack 1 win 15840 (ttl 60, id 43524) > 15:56:18.039780 snap ip anatok.ftp-data > cyntok.1053: . ack 410841 win 15496 (DF) [tos 0x8] (ttl 64, id 42858) > 15:56:18.040342 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) > 15:56:18.041825 snap ip cyntok.1053 > anatok.ftp-data: . 414801:418761(3960) ack 1 win 15840 (ttl 60, id 43525) > 15:56:18.041867 snap ip anatok.ftp-data > cyntok.1053: . ack 414801 win 16384 (DF) [tos 0x8] (ttl 64, id 42859) > 15:56:18.045938 snap ip cyntok.1053 > anatok.ftp-data: . 418761:422721(3960) ack 1 win 15840 (ttl 60, id 43526) > 15:56:18.046106 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) > 15:56:18.046263 snap ip anatok.ftp-data > cyntok.1053: . ack 422721 win 13448 (DF) [tos 0x8] (ttl 64, id 42860) > 15:56:18.048370 snap ip cyntok.1053 > anatok.ftp-data: P 422721:426681(3960) ack 1 win 15840 (ttl 60, id 43527) > 15:56:18.048685 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) > 15:56:18.048828 snap ip anatok.ftp-data > cyntok.1053: . ack 426681 win 14472 (DF) [tos 0x8] (ttl 64, id 42861) > 15:56:18.052509 snap ip cyntok.1053 > anatok.ftp-data: . 426681:430641(3960) ack 1 win 15840 (ttl 60, id 43528) > 15:56:18.052995 snap ip anatok.ftp-data > cyntok.1053: . ack 430641 win 15496 (DF) [tos 0x8] (ttl 64, id 42862) > > Nice big 3k packets! It does seem that FreeBSD will not generate a packet > bigger than 2048 though. > > 16:00:41.593756 snap ip anatok.ftp-data > cyntok.1056: . 223233:225281(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44259) > 16:00:41.595001 snap ip anatok.ftp-data > cyntok.1056: . 225281:227329(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44260) > 16:00:41.595930 snap ip anatok.ftp-data > cyntok.1056: . 227329:229377(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44261) > 16:00:41.596980 snap ip anatok.ftp-data > cyntok.1056: . 229377:231425(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44262) > 16:00:41.597952 snap ip cyntok.1056 > anatok.ftp-data: . ack 227329 win 15840 (ttl 60, id 44715) > 16:00:41.598110 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) > 16:00:41.598244 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) > 16:00:41.598374 snap ip anatok.ftp-data > cyntok.1056: . 235521:237569(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44265) > 16:00:41.598509 snap ip anatok.ftp-data > cyntok.1056: . 237569:239617(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44266) > 16:00:41.598632 snap ip anatok.ftp-data > cyntok.1056: . 239617:241665(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44267) > 16:00:41.599962 snap ip anatok.ftp-data > cyntok.1056: . 231425:233473(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44263) > 16:00:41.600782 snap ip anatok.ftp-data > cyntok.1056: . 233473:235521(2048) ack 1 win 16384 (DF) [tos 0x8] (ttl 64, id 44264) > > But that's another problem. Any idea where in the stack that is > happening? > > Larry Lile > lile@stdio.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:03:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13805 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:03:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13774; Tue, 9 Feb 1999 14:02:58 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA10280; Tue, 9 Feb 1999 14:00:07 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpde10274; Tue Feb 9 22:00:06 1999 Date: Tue, 9 Feb 1999 14:00:02 -0800 (PST) From: Julian Elischer To: Doug Rabson cc: Mike Smith , Dag-Erling Smorgrav , Eivind Eklund , Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-Reply-To: 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 I'd like to look at it.. On Tue, 9 Feb 1999, Doug Rabson wrote: > On Tue, 9 Feb 1999, Mike Smith wrote: > > > > someone said thay had code already.. > > > was it warner? or maybe one of the Johns. > > > > Doug Rabson, IIRC. > > I have some code. I would like to commit it but I haven't managed to find > a reviewer yet (not that I have pushed that hard). Considering what > happened to the last guy that tried to change sysctl, I'm not going to > commit it without a review. > > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:16:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15403 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:16:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15398 for ; Tue, 9 Feb 1999 14:16:36 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA00950; Tue, 9 Feb 1999 15:16:29 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd000799; Tue Feb 9 15:16:15 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA07798; Tue, 9 Feb 1999 15:16:13 -0700 (MST) From: Terry Lambert Message-Id: <199902092216.PAA07798@usr02.primenet.com> Subject: Re: ldconfig and libraries To: jdp@polstra.com (John Polstra) Date: Tue, 9 Feb 1999 22:16:13 +0000 (GMT) Cc: wes@softweyr.com, hackers@FreeBSD.ORG In-Reply-To: from "John Polstra" at Feb 8, 99 12:00:06 pm X-Mailer: ELM [version 2.4 PL25] 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 > > So make the field ALWAYS PATH_MAX (+1 ??) characters in length, and > > stick a zero-terminated string within that buffer. Changing the length > > of the string won't change the length of the field, and therefore won't > > require fixing up addresses in the data (or any other) segment. > > And add 1K to the size of every executable and shared library file in > the system? Both on disk and in memory at execution time? That's too > much of a hack for my tastes. OK, next question: Why can't it be at the end of the data? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:23:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16060 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:23:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16049 for ; Tue, 9 Feb 1999 14:23:27 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id OAA26057; Tue, 9 Feb 1999 14:23:18 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id OAA49368; Tue, 9 Feb 1999 14:23:18 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199902092216.PAA07798@usr02.primenet.com> Date: Tue, 09 Feb 1999 14:23:17 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Terry Lambert Subject: Re: ldconfig and libraries Cc: hackers@FreeBSD.ORG, wes@softweyr.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > OK, next question: Why can't it be at the end of the data? Because then it wouldn't be in a read-only segment at execution time. And it wouldn't help anyway, because it would still come before BSS, causing BSS to move if the RPATHs size were changed. :-) Anticipating another likely question: Q. Why not make it read-write, then? What could it hurt? A. It would violate the ELF spec. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:24:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16208 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:24:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16181; Tue, 9 Feb 1999 14:24:16 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA29019; Tue, 9 Feb 1999 15:24:15 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd028866; Tue Feb 9 15:24:07 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA08624; Tue, 9 Feb 1999 15:24:01 -0700 (MST) From: Terry Lambert Message-Id: <199902092224.PAA08624@usr02.primenet.com> Subject: Re: Regarding tcpdump and plip To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Tue, 9 Feb 1999 22:24:01 +0000 (GMT) Cc: fenner@parc.xerox.com, hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 8, 99 02:40:39 am X-Mailer: ELM [version 2.4 PL25] 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 > No, I just throw away the fake Ethernet header and put a DLT_NULL > header on instead. It's much simpler, and no useful information is > lost since the fake Ethernet header in the incoming packet is blank > except for the type field, which we reproduce (or rather, translate to > AF_INET) in the DLT_NULL header. I guess the code is not usable for other address families, e.g. IPV6? Otherwise, the AF_INET should probably be copied instead of set unilaterally. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:33:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17559 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:33:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA17532 for ; Tue, 9 Feb 1999 14:32:56 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id VAA16071; Tue, 9 Feb 1999 21:17:34 +0100 From: Luigi Rizzo Message-Id: <199902092017.VAA16071@labinfo.iet.unipi.it> Subject: Re: Dummynet pipes truble To: smith@scn.ru Date: Tue, 9 Feb 1999 21:17:33 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <36BFBA8B.37A3EFF3@scn.ru> from "Vladimir N. Kovalev" at Feb 9, 99 11:32:57 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, try "ipfw pipe show" to be sure that your entries are parsed correctly. The bw values are rounded (or truncated ?) to some near integer depending on the value of HZ and it could be that setting too low a bandwidth results in 0 which means unlimited. Furthermore your pipe #1 is rather meaningless -- there is no queueing in a pipe without bw limitation. If you want to limit traffic you better add a bw limitation as well. cheers luigi > Hello ! > I'm use dummynet on FreeBSD 2.2.7-19981103-SNAP with the such configuration of pipes: > # Set pipes for icmp > ipfw pipe 1 config delay 7000ms queue 10 plr 0.001 > # Set pipes for admin > ipfw pipe 2 config bw 4000B queue 70 > # Set pipes for LAN channel > ipfw pipe 3 config bw 10KB queue 75 > # Set pipes for server ( mail, ftp, squid etc ) channel > ipfw pipe 4 config bw 6KB queue 75 > # Set pipes for class rooms channel > ipfw pipe 5 config bw 100B queue 75 > # Set pipes for test purposes only > ipfw pipe 6 config bw 1B queue 50 > > And rc.firewall have appropiate rules: > 01710 1044 533229 pipe 6 tcp from any to 192.168.0.1 > ... > 02210 12525 15043642 pipe 2 tcp from any to 192.168.2.2 in recv 192.168.1.1 established > 02310 0 0 pipe 5 tcp from any to 192.168.3.1 in recv 192.168.1.1 established > 02410 38345 16987766 pipe 4 tcp from any to 192.168.1.1 in recv 192.168.1.1 established > 02510 18798 5420744 pipe 4 tcp from any to 192.168.2.1 in recv 192.168.1.1 established > 02610 883364 658924977 pipe 3 tcp from any to any in recv 192.168.1.1 established > ... > 04410 18384 1348136 pipe 1 icmp from any to any in recv cx0 > > Pipes number 1, 3 and 4 works fine, but pipes number 2, 5 and 6 does not limit a bandwidth. > However, then I add delay to this pipes I can feel it. > > Why ? > > Thanks in advance. > > Best regards > Vladimir N. Kovalev > > > 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 Feb 9 14:41:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18320 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:41:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18315 for ; Tue, 9 Feb 1999 14:41:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id OAA61365; Tue, 9 Feb 1999 14:41:06 -0800 (PST) (envelope-from dillon) Date: Tue, 9 Feb 1999 14:41:06 -0800 (PST) From: Matthew Dillon Message-Id: <199902092241.OAA61365@apollo.backplane.com> To: Mark Hannon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Change to inherit nodump flag? References: <36C0A3C4.E9CDA301@stockholm.mail.telia.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, :I dump some of my filesystems to my (small) floppy tape drive as backup. : :This works quite well as long as I only dump my own data files. To :avoid :dumping easily recoverable files I run a script which runs: : : chflags -R nodump /home/ncvs :... :is a time consuming affair. As a way around this I thought maybe the :... :I had a quick look in the code and I am guessing that I should implement : :such a change in: : : /sys/ufs/ufs/ufs_vnops.c in functions ufs_makeinode & ufs_mkdir : :Is this where the functionality should be implemented? :... :Regards/Mark Yes, somewhere around line 2091 of ufs_vnops.c ( ufs_create() ). Also around line 1296 of ufs_vnops.c ( ufs_mkdir() ). Just after the gid inheritance. ... ip = VTOI(tvp); ip->i_gid = pdir->i_gid; <-------------------- here ... The 'i_flags' field ( not to be confused with 'i_flag' ) would have to inherit the directory's nodump flag. Personally, I think this is the correct way of doing it - nodump would be inherited just as directory gid is inherited. Another solution would be to hack the 'dump' program to be able to remember 'nodump' recursively. I don't think that is as good a solution as adjusting i_flags on create. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:47:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19357 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:47:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19350 for ; Tue, 9 Feb 1999 14:47:16 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA15542; Tue, 9 Feb 1999 15:47:11 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd015450; Tue Feb 9 15:47:09 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA10658; Tue, 9 Feb 1999 15:46:57 -0700 (MST) From: Terry Lambert Message-Id: <199902092246.PAA10658@usr02.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Tue, 9 Feb 1999 22:46:57 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902072122.WAA15102@gilberto.physik.RWTH-Aachen.DE> from "Christoph Kukulies" at Feb 7, 99 10:22:24 pm X-Mailer: ELM [version 2.4 PL25] 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 > Does anyone have experience with portability of common > IPC mechanisms between Linux 2.x and FreeBSD? > > I'm trying to estimate the risk of a porting project from > Linux to FreeBSD. > What peculiarities are there? Incompatibilities between the > two OSs WRT to 'clean' implementation of these disciplines? > > sockets - feature set compatible? A common error in Linux programming is to not bzero sockaddr_in contents, and to just set two fields and use them, trusting the kernel to ignore the supposedly "insignificant" uninitialized data. These programs will not function when compiled on FreeBSD (or when using IPv6 on other patforms). FreeBSD does not select writeable on sockets. Sockets can be written if there are mbuf's available, and mbuf's can become unavailable asynchronously between the select coming true and the subsequent write. Select for write is generally an artifact of porting a winsock program to a UNIX system. FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, F_SETLK, F_SETLKW. This is due to the use of struct fileops, since sockets are not backed by true vnode objects. > pipes - ? named pipes? FreeBSD pipes are bidirectional, since they are implemented with the AF_UNIX socket code. FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, F_SETLK, F_SETLKW. This is due to the use of struct fileops, since pipes are not backed by true vnode objects. > mmap - stable? limitations? FreeBSD has a unified vm and buffer cache. In theory, you do not need to call msync(2), ever, on such a system. However, there are a number of coherency bugs that make it necessary to call it (mostly in INN-type situations, where the file is being extended while it is mapped). Linux is supposedly a unified VM and buffer cache as well; but Linux also requires msync(2) for correct coherency. INN appears to run without this, but data is not written back to the backing file as it should be. > shmxxx - SYSV compatibility? FreeBSD shared memory segments are limited in size at kernel compilation time; this can be overriden with kernel configuration options. The overall size of the shared memory segment is limited to that which can fit in the kernels virtual address space; this artificially restricts the maximum size. FreeBSD semaphores are inadequately resource tracked in _exit(). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 14:53:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20684 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 14:53:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20651 for ; Tue, 9 Feb 1999 14:53:34 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA18527; Tue, 9 Feb 1999 15:53:27 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd018310; Tue Feb 9 15:53:19 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA11134; Tue, 9 Feb 1999 15:52:56 -0700 (MST) From: Terry Lambert Message-Id: <199902092252.PAA11134@usr02.primenet.com> Subject: Re: ldconfig and libraries To: jdp@polstra.com (John Polstra) Date: Tue, 9 Feb 1999 22:52:56 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG, wes@softweyr.com In-Reply-To: from "John Polstra" at Feb 9, 99 02:23:17 pm X-Mailer: ELM [version 2.4 PL25] 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 > > OK, next question: Why can't it be at the end of the data? > > Because then it wouldn't be in a read-only segment at execution > time. OK, next next question: who cares that it's not in a read-only segment? > And it wouldn't help anyway, because it would still come before BSS, > causing BSS to move if the RPATHs size were changed. :-) Next next next question: What's wrong with putting it at the end of the data, and putting Wes's 1K offset into the BSS start offset, instead of into the image file on disk? E.g., it takes what it takes up to MAX_PATH, but only the space used is accounted against the image size. > Anticipating another likely question: > Q. Why not make it read-write, then? What could it hurt? > A. It would violate the ELF spec. Hmmm. I thought Doug Rabson just did this on a mapping location change on the Alpha? Well... how about supporting more sections in a process image? Doesn't WINE require this, so it's already somewhat supported? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 15:11:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22936 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 15:11:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22928 for ; Tue, 9 Feb 1999 15:11:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id PAA61722; Tue, 9 Feb 1999 15:10:52 -0800 (PST) (envelope-from dillon) Date: Tue, 9 Feb 1999 15:10:52 -0800 (PST) From: Matthew Dillon Message-Id: <199902092310.PAA61722@apollo.backplane.com> To: Terry Lambert Cc: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies), hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :FreeBSD does not select writeable on sockets. Sockets can be : written if there are mbuf's available, and mbuf's can : become unavailable asynchronously between the select : coming true and the subsequent write. Select for : write is generally an artifact of porting a winsock : program to a UNIX system. Huh? Sure it does. The availability of mbufs in the memory pool has little to do with select()ing a socket for write. mbuf exhaustion is a rather serious error. :> mmap - stable? limitations? : :FreeBSD has a unified vm and buffer cache. In theory, you do not : need to call msync(2), ever, on such a system. However, : there are a number of coherency bugs that make it necessary : to call it (mostly in INN-type situations, where the file is : being extended while it is mapped). What coherency bugs? As far as I know, extending a mmap()'d file works just fine. You cannot *write* into the mmap()'d area beyond the end of a file until you ftruncate() the file larger, but that is true on all implementations that I know of. It is also appropriate - the validity of the mmap()'d data only extends to the logical end of file. :The overall size of the shared memory segment is limited to that : which can fit in the kernels virtual address space; this : artificially restricts the maximum size. :FreeBSD semaphores are inadequately resource tracked in _exit(). All semaphores are inadequately resource tracked in _exit(), it's a problem inherited from the SYSV implementation. : Terry Lambert : terry@lambert.org -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 15:23:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24696 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 15:23:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24691 for ; Tue, 9 Feb 1999 15:23:35 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA13799; Tue, 9 Feb 1999 15:16:09 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdN13774; Tue Feb 9 23:16:04 1999 Date: Tue, 9 Feb 1999 15:15:50 -0800 (PST) From: Julian Elischer To: Matthew Dillon cc: Mark Hannon , freebsd-hackers@FreeBSD.ORG Subject: Re: Change to inherit nodump flag? In-Reply-To: <199902092241.OAA61365@apollo.backplane.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 I don't think this is a good idea a better idea is to make th eapplication not descend into trees that have the nodump bit set on the directory. you can't "inherrit" all the way up a directory tree when it's moved into a directory with the nodump flag set. (I have the same problem with the SUIDDIR option in around the same piece of code..) julian > Yes, somewhere around line 2091 of ufs_vnops.c ( ufs_create() ). > Also around line 1296 of ufs_vnops.c ( ufs_mkdir() ). Just after > the gid inheritance. > > ... > ip = VTOI(tvp); > ip->i_gid = pdir->i_gid; > <-------------------- here > ... > > The 'i_flags' field ( not to be confused with 'i_flag' ) would have > to inherit the directory's nodump flag. > > Personally, I think this is the correct way of doing it - nodump > would be inherited just as directory gid is inherited. > > Another solution would be to hack the 'dump' program to be able to > remember 'nodump' recursively. I don't think that is as good a > solution as adjusting i_flags on create. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 15:34:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26446 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 15:34:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26441 for ; Tue, 9 Feb 1999 15:34:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id PAA61881; Tue, 9 Feb 1999 15:34:28 -0800 (PST) (envelope-from dillon) Date: Tue, 9 Feb 1999 15:34:28 -0800 (PST) From: Matthew Dillon Message-Id: <199902092334.PAA61881@apollo.backplane.com> To: Julian Elischer Cc: Mark Hannon , freebsd-hackers@FreeBSD.ORG Subject: Re: Change to inherit nodump flag? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I don't think this is a good idea : :a better idea is to make th eapplication not descend into trees that have :the nodump bit set on the directory. : :you can't "inherrit" all the way up a directory tree when it's moved :into a directory with the nodump flag set. : :(I have the same problem with the SUIDDIR option in around the same :piece of code..) : :julian True, but on the otherhand the FS implementation of 'nodump' inheritance would save your butt if you accidently renamed a directory/file into a 'nodump' subdirectory that you really wanted to dump - it would still back it up. After all, what happens when you rename a file with group A into a directory with group B ? The group doesn't change. And it shouldn't. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 15:40:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27338 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 15:40:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27325; Tue, 9 Feb 1999 15:40:46 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id AAA05032; Wed, 10 Feb 1999 00:40:40 +0100 (CET) (envelope-from des) To: Terry Lambert Cc: fenner@parc.xerox.com, hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902092224.PAA08624@usr02.primenet.com> From: Dag-Erling Smorgrav Date: 10 Feb 1999 00:40:40 +0100 In-Reply-To: Terry Lambert's message of "Tue, 9 Feb 1999 22:24:01 +0000 (GMT)" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > No, I just throw away the fake Ethernet header and put a DLT_NULL > > header on instead. It's much simpler, and no useful information is > > lost since the fake Ethernet header in the incoming packet is blank > > except for the type field, which we reproduce (or rather, translate to > > AF_INET) in the DLT_NULL header. > I guess the code is not usable for other address families, e.g. IPV6? Not that I am aware of. I'll be happy to assist in making the plip driver IPv6-aware once we get the WIDE/INRIA stack in. > Otherwise, the AF_INET should probably be copied instead of set > unilaterally. Yep. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 15:45:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27816 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 15:45:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27811 for ; Tue, 9 Feb 1999 15:45:39 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA09407; Tue, 9 Feb 1999 15:41:22 -0800 (PST) Message-Id: <199902092341.PAA09407@implode.root.com> To: Matthew Dillon cc: Terry Lambert , kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies), hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Tue, 09 Feb 1999 15:10:52 PST." <199902092310.PAA61722@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 09 Feb 1999 15:41:22 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >:The overall size of the shared memory segment is limited to that >: which can fit in the kernels virtual address space; this >: artificially restricts the maximum size. That isn't true and hasn't been true for several years in FreeBSD. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 16:14:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04327 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 16:14:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04007; Tue, 9 Feb 1999 16:12:41 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA16342; Tue, 9 Feb 1999 16:09:27 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdF16337; Wed Feb 10 00:09:24 1999 Date: Tue, 9 Feb 1999 16:09:17 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav cc: Terry Lambert , fenner@parc.xerox.com, hackers@FreeBSD.ORG, nsouch@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip In-Reply-To: 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 10 Feb 1999, Dag-Erling Smorgrav wrote: > > Not that I am aware of. I'll be happy to assist in making the plip > driver IPv6-aware once we get the WIDE/INRIA stack in. Apparently NRL are also in this co-operating group. (Apparently they are unhappy that they are being left out of the announcements (which I can understand)). julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 17:31:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14082 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 17:31:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14077 for ; Tue, 9 Feb 1999 17:31:15 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id RAA27004; Tue, 9 Feb 1999 17:31:13 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id RAA51904; Tue, 9 Feb 1999 17:31:13 -0800 (PST) (envelope-from jdp@polstra.com) Date: Tue, 9 Feb 1999 17:31:13 -0800 (PST) Message-Id: <199902100131.RAA51904@vashon.polstra.com> To: dima@Chg.RU Subject: Re: Configuring cvsupd In-Reply-To: <199902091403.RAA02695@netserv1.chg.ru> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199902091403.RAA02695@netserv1.chg.ru>, Dima Sivachenko wrote: > > I want to configure cvsupd to make local mirror of CVS repository. > Where can I read more than man-page about how to configure cvsupd? DES gave you a good answer. Here's another one. See questions 31 and 32 of the CVSup FAQ: http://www.polstra.com/projects/freeware/CVSup/ John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 17:34:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14470 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 17:34:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14462; Tue, 9 Feb 1999 17:34:20 -0800 (PST) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.054 #1) id 10AOX7-00019M-00; Wed, 10 Feb 1999 07:33:41 +0600 Date: Wed, 10 Feb 1999 07:33:41 +0600 (ALMT) From: Boris Popov To: Emmanuel DELOGET cc: Eivind Eklund , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-Reply-To: <199902091507.PAA10987@excalibur.oceanis.net> 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 Tue, 9 Feb 1999, Emmanuel DELOGET wrote: > ** > I wanna add some sysctl entries to a loadable kernel > ** > module. As I'm sure I'm not the first doing that, > ** > if anybody knows... > ** > ** It is not possible at the moment. :-( > > The result seems bad... I had to compile the kernel, then to > reboot... Each time I wonder wether I added a bug or not... > And if there is a bug, I'm out... Any idea would be welcome... You can try this: take code from any file system (null fs for simplicity) and look at nfs_vfsops variable in /sys/nfs/nfs_vfsops.c file. The last structure element do the trick. Of course, your kld become a VFS type, but I hope this will not be necessary soon. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 17:55:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17290 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 17:55:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from janus.utilicom.com (janus.utilicom.com [204.188.4.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17283 for ; Tue, 9 Feb 1999 17:55:08 -0800 (PST) (envelope-from lpoulsen@utilicom.com) Received: from Lars (lars-pc.utilicom.com [204.188.4.134]) by janus.utilicom.com (8.8.7/8.8.7) with SMTP id RAA12926 for ; Tue, 9 Feb 1999 17:55:41 -0800 Message-Id: <199902100155.RAA12926@janus.utilicom.com> X-Sender: lpoulsen@janus.utilicom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 09 Feb 1999 17:52:11 -0800 To: freebsd-hackers@FreeBSD.ORG From: Lars Poulsen Subject: Re: Strange NFS Problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I sent this to freebsd-questions a few minutes ago, meaning to cc freebsd-hackers, but my fat fingers instead typed freebAd-hackers, which sounds like a political poster...] Yesterday, I wrote on freebsd-questions: >I am running a mostly Linux shop, but have a single FreeBSD workstation to >support an application which is only available for FreeBSD. I am NFS exporting >a 4GB /home file system from DIANA, my main Linux file server, and importing >it to ATHENA, which runs FreeBSD 2.2.7. > >Users on ATHENA (the FreeBSD system) can read files on DIANA:/home, >and they can create very small files, but if they try to write a file of more than >about 70 bytes, they get "FILE TRUNCATED" errors, and nothing gets written. It was suggested to me that this problem had been discussed in the past on freebsd-hackers, and that a fix was expected to be in FreeBSD 3.1 (due out any day now). I failed to find any prior FreeBSD bug reports or freebsd-hackers discussion, but I think I have found a description and a partial fix in the Debian Linux bug database, http://www.debian.org/Bugs/db/28/28642.html. If I understand the writeup correctly, FreeBSD 2.2.6 and 2.2.7 will under some circumstances generate a malformed write command packet, which is being rejected by Linux NFSD versions from a October 1998, which happens to be about when RedHat 5.2 was packaged. It would seem that upgrading either of the two systems would resolve the problem. Most likely, I will try to retrieve the latest binary package of Linux's nfs-server package and hope that fixes the problem. I am sending this message to - inform freebsd-questions readers (and archive searchers) about the solution - ask freebsd-hackers to confirm that the problem is indeed resolved and which of the following releases contain the fix: 2.2.8, 3.0, 3.1 ?? / Lars Poulsen E-mail: Senior Software Engineer Telephone: +1-805-964-5848 ext 279 UtiliCom Inc, 323 David Love Place, Santa Barbara, CA 93117, USA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 19:40:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00947 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 19:40:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from keep.scn.ru (keep.scnet.ru [195.239.174.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00941 for ; Tue, 9 Feb 1999 19:40:13 -0800 (PST) (envelope-from smith@scn.ru) Received: from scn.ru (quick.scnet.ru [195.239.174.3]) by keep.scn.ru (8.9.1/8.9.1) with ESMTP id KAA22664; Wed, 10 Feb 1999 10:38:53 +0700 (KRS) Message-ID: <36C0FE36.9A2116D8@scn.ru> Date: Wed, 10 Feb 1999 10:34:14 +0700 From: "Vladimir N. Kovalev" Reply-To: smith@scn.ru Organization: Sibchallenge Telecom Inc. X-Mailer: Mozilla 4.07 [en] (Win95; I) MIME-Version: 1.0 To: Luigi Rizzo CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Dummynet pipes truble References: <199902092017.VAA16071@labinfo.iet.unipi.it> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > Hi, Hi ! > > > try "ipfw pipe show" to be sure that your entries are parsed correctly. /root/fire > ipfw pipe show 00001: unlimited 7000 ms 100 sl. plr 0.001000 -- 0 pkts (0 B) 126 drops 00002: 32.000 Kbit/s 0 ms 70 sl. -- 0 pkts (0 B) 0 drops 00003: 96.000 Kbit/s 0 ms 75 sl. -- 33 pkts (32429 B) 240695 drops 00004: 48.000 Kbit/s 0 ms 75 sl. -- 0 pkts (0 B) 0 drops 00005: 80.000 Kbit/s 0 ms 75 sl. -- 0 pkts (0 B) 0 drops 00006: 80.000 Kbit/s 0 ms 100 sl. -- 1 pkts (106 B) 46 drops > > The bw values are rounded (or truncated ?) to some near integer > depending on the value of HZ and it could be that setting too low a > bandwidth results in 0 which means unlimited. The value of HZ in my kernel equal to 1000. And then I set bw to 1KB, I get bandwidth value equal to 8 Kbit/s, like this : /root/fire > ipfw pipe 6 config bw 1KB /root/fire > ipfw pipe show 00001: unlimited 7000 ms 100 sl. plr 0.001000 -- 0 pkts (0 B) 126 drops 00002: 32.000 Kbit/s 0 ms 70 sl. -- 0 pkts (0 B) 0 drops 00003: 96.000 Kbit/s 0 ms 75 sl. -- 36 pkts (19756 B) 240827 drops 00004: 48.000 Kbit/s 0 ms 75 sl. -- 0 pkts (0 B) 0 drops 00005: 80.000 Kbit/s 0 ms 75 sl. -- 0 pkts (0 B) 0 drops 00006: 8.000 Kbit/s 0 ms 100 sl. -- 1 pkts (44 B) 46 drops How can I get the bandwidth value less then 8 Kbit/s ? The command "ipfw pipe 6 config bw 250B" have no effect. > > > Furthermore your pipe #1 is rather meaningless -- there is no > queueing in a pipe without bw limitation. If you want to limit > traffic you better add a bw limitation as well. Many thanks ! Best regards Vladimir Kovalev > Hello ! > I'm use dummynet on FreeBSD 2.2.7-19981103-SNAP with the such configuration of pipes: > # Set pipes for icmp > ipfw pipe 1 config delay 7000ms queue 10 plr 0.001 > # Set pipes for admin > ipfw pipe 2 config bw 4000B queue 70 > # Set pipes for LAN channel > ipfw pipe 3 config bw 10KB queue 75 > # Set pipes for server ( mail, ftp, squid etc ) channel > ipfw pipe 4 config bw 6KB queue 75 > # Set pipes for class rooms channel > ipfw pipe 5 config bw 100B queue 75 > # Set pipes for test purposes only > ipfw pipe 6 config bw 1B queue 50 > > And rc.firewall have appropiate rules: > 01710 1044 533229 pipe 6 tcp from any to 192.168.0.1 > ... > 02210 12525 15043642 pipe 2 tcp from any to 192.168.2.2 in recv 92.168.1.1 established > 02310 0 0 pipe 5 tcp from any to 192.168.3.1 in recv 192.168.1.1 established > 02410 38345 16987766 pipe 4 tcp from any to 192.168.1.1 in recv 192.168.1.1 established > 02510 18798 5420744 pipe 4 tcp from any to 192.168.2.1 in recv 192.168.1.1 established > 02610 883364 658924977 pipe 3 tcp from any to any in recv 192.168.1.1 established > ... > 04410 18384 1348136 pipe 1 icmp from any to any in recv cx0 > > Pipes number 1, 3 and 4 works fine, but pipes number 2, 5 and 6 does not limit a bandwidth. > However, then I add delay to this pipes I can feel it. > > Why ? > > Thanks in advance. > > Best regards > Vladimir N. Kovalev > > > 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 Feb 9 20:03:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA03426 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 20:03:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA03421 for ; Tue, 9 Feb 1999 20:03:00 -0800 (PST) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.2/8.9.1) id UAA98421; Tue, 9 Feb 1999 20:02:59 -0800 (PST) (envelope-from mph) Date: Tue, 9 Feb 1999 20:02:59 -0800 From: Matthew Hunt To: hackers@FreeBSD.ORG Cc: GReg Sutter Subject: Proposal: Ignore .nofinger for root Message-ID: <19990209200259.A98301@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I propose the following change to src/usr.bin/finger to ignore ~/.nofinger when finger(1) is run by root. We ship inetd.conf with fingerd running as nobody, so all remote requests still honor ~/.nofinger. Comments? Index: finger.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/finger/finger.1,v retrieving revision 1.7 diff -u -r1.7 finger.1 --- finger.1 1997/08/01 20:26:47 1.7 +++ finger.1 1999/02/10 04:00:16 @@ -184,7 +184,9 @@ .Dq Pa .nofinger exists in the user's home directory, .Nm finger -behaves as if the user in question does not exist. +behaves as if the user in question does not exist, unless +.Nm finger +is run by the superuser. .Sh ENVIRONMENT .Nm Finger utilizes the following environment variable, if it exists: Index: util.c =================================================================== RCS file: /home/ncvs/src/usr.bin/finger/util.c,v retrieving revision 1.5 diff -u -r1.5 util.c --- util.c 1997/07/02 06:34:51 1.5 +++ util.c 1999/02/10 03:40:17 @@ -393,6 +393,9 @@ { char buf[MAXPATHLEN+1]; + if (!geteuid()) + return 0; + if (!pw->pw_dir) return 0; -- Matthew Hunt * Inertia is a property of matter. http://www.pobox.com/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 20:04:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA03768 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 20:04:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA03762 for ; Tue, 9 Feb 1999 20:04:28 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id MAA55849; Wed, 10 Feb 1999 12:03:43 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199902100403.MAA55849@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies), hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Tue, 09 Feb 1999 22:46:57 GMT." <199902092246.PAA10658@usr02.primenet.com> Date: Wed, 10 Feb 1999 12:03:43 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: [...] > FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > since sockets are not backed by true vnode objects. Terry, read the bloody source before spreading unverified FUD like this.. The fcntl(2) ops F_SETOWN/F_GETOWN are translated into FIOSETOWN/FIOGETOWN ioctl's and are fully implemented. However, as you point out, the fcntl() (and flock()) *locking* operations are not implemented. IMHO file locking on a socket is of pretty marginal value since there is no seek space (with the possible exception of using it for a mutex instead of using sendmsg() or something sensible). > > pipes - ? named pipes? > > FreeBSD pipes are bidirectional, since they are implemented with the > AF_UNIX socket code. Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been for a *long* time (since 1996 when 2.2 was branched). As in kern/sys_pipe.c: /* * This file contains a high-performance replacement for the socket-based * pipes scheme originally used in FreeBSD/4.4Lite. It does not support * all features of sockets, but does do everything that pipes normally * do. */ > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > since pipes are not backed by true vnode objects. F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. *Only* the file locking parts are not implemented since it's of such little value with no seek space. > Terry Lambert > terry@lambert.org Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 20:13:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04796 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 20:13:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA04789 for ; Tue, 9 Feb 1999 20:13:10 -0800 (PST) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from mercury (mercury [129.127.36.44]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id OAA17108; Wed, 10 Feb 1999 14:43:07 +1030 (CST) Received: from localhost by mercury; (5.65v3.2/1.1.8.2/27Nov97-0404PM) id AA18894; Wed, 10 Feb 1999 14:43:06 +1030 Date: Wed, 10 Feb 1999 14:43:04 +1030 (CST) From: Kris Kennaway To: Max Khon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: 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 Tue, 9 Feb 1999, Max Khon wrote: > what is the current status of softupdates? > is it safe to turn on softupdates (no ccd)? It's been working just fine here for at least the last 6 months.. I haven't heard any softupdates-related panics/crashes on the mailing lists in a while. Kris ----- (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 23:42:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25781 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 23:42:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA25775 for ; Tue, 9 Feb 1999 23:42:54 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA17352; Wed, 10 Feb 1999 06:27:21 +0100 From: Luigi Rizzo Message-Id: <199902100527.GAA17352@labinfo.iet.unipi.it> Subject: Re: Dummynet pipes truble To: smith@scn.ru Date: Wed, 10 Feb 1999 06:27:21 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <36C0FE36.9A2116D8@scn.ru> from "Vladimir N. Kovalev" at Feb 10, 99 10:33:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The bw values are rounded (or truncated ?) to some near integer > > depending on the value of HZ and it could be that setting too low a > > bandwidth results in 0 which means unlimited. > > The value of HZ in my kernel equal to 1000. > And then I set bw to 1KB, I get bandwidth value equal to 8 Kbit/s, like this : if i remember well dummynet cannot set the BW to less than 1 byte/tick, that means 8000 bit/s with HZ=1000. I have to fix this... apart from this there might be parsing problem in the ipfw command. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 23:54:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26968 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 23:54:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from keep.scn.ru (keep.scnet.ru [195.239.174.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26955 for ; Tue, 9 Feb 1999 23:54:33 -0800 (PST) (envelope-from smith@scn.ru) Received: from scn.ru (quick.scnet.ru [195.239.174.3]) by keep.scn.ru (8.9.1/8.9.1) with ESMTP id OAA25583; Wed, 10 Feb 1999 14:53:04 +0700 (KRS) Message-ID: <36C139C9.17B09702@scn.ru> Date: Wed, 10 Feb 1999 14:48:25 +0700 From: "Vladimir N. Kovalev" Reply-To: smith@scn.ru Organization: Sibchallenge Telecom Inc. X-Mailer: Mozilla 4.07 [en] (Win95; I) MIME-Version: 1.0 To: Luigi Rizzo CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Dummynet pipes truble References: <199902100527.GAA17352@labinfo.iet.unipi.it> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > > The bw values are rounded (or truncated ?) to some near integer > > > depending on the value of HZ and it could be that setting too low a > > > bandwidth results in 0 which means unlimited. > > > > The value of HZ in my kernel equal to 1000. > > And then I set bw to 1KB, I get bandwidth value equal to 8 Kbit/s, like this : > > if i remember well dummynet cannot set the BW to less than 1 byte/tick, > that means 8000 bit/s with HZ=1000. I have to fix this... > apart from this there might be parsing problem in the ipfw command. Thanks ! Vladimir Kovalev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 9 23:59:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27466 for freebsd-hackers-outgoing; Tue, 9 Feb 1999 23:59:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27459 for ; Tue, 9 Feb 1999 23:59:08 -0800 (PST) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id IAA11748; Wed, 10 Feb 1999 08:58:48 +0100 (MET) (envelope-from kuku) Message-ID: <19990210085847.A11710@gil.physik.rwth-aachen.de> Date: Wed, 10 Feb 1999 08:58:47 +0100 From: Christoph Kukulies To: Peter Wemm , Terry Lambert Cc: Christoph Kukulies , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91 In-Reply-To: <199902100403.MAA55849@spinner.netplex.com.au>; from Peter Wemm on Wed, Feb 10, 1999 at 12:03:43PM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 10, 1999 at 12:03:43PM +0800, Peter Wemm wrote: > Terry Lambert wrote: > [...] > > > FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since sockets are not backed by true vnode objects. > > Terry, read the bloody source before spreading unverified FUD like this.. > The fcntl(2) ops F_SETOWN/F_GETOWN are translated into FIOSETOWN/FIOGETOWN > ioctl's and are fully implemented. However, as you point out, the fcntl() > (and flock()) *locking* operations are not implemented. IMHO file locking > on a socket is of pretty marginal value since there is no seek space > (with the possible exception of using it for a mutex instead of using > sendmsg() or something sensible). > > > > pipes - ? named pipes? > > > > FreeBSD pipes are bidirectional, since they are implemented with the > > AF_UNIX socket code. > > Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been > for a *long* time (since 1996 when 2.2 was branched). > > As in kern/sys_pipe.c: > /* > * This file contains a high-performance replacement for the socket-based > * pipes scheme originally used in FreeBSD/4.4Lite. It does not support > * all features of sockets, but does do everything that pipes normally > * do. > */ > > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since pipes are not backed by true vnode objects. > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > *Only* the file locking parts are not implemented since it's of such little > value with no seek space. > > > Terry Lambert > > terry@lambert.org > > Cheers, > -Peter > > Seems I have kicked off an avalanche :-) Someone was mentioning in an off-net discussion with some linux guys, that when using timeval struct in select the time structure members were dealt differently (units, offsets? - not clear what my discussion partner meant, but it alarmed me a bit). But OTOH, when XFree86 is running on both all I'd have to do is looking perhaps in the XFree86 source.. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 01:07:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02392 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 01:07:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA02387 for ; Wed, 10 Feb 1999 01:07:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id BAA79553; Wed, 10 Feb 1999 01:07:44 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 01:07:44 -0800 (PST) From: Matthew Dillon Message-Id: <199902100907.BAA79553@apollo.backplane.com> To: Christoph Kukulies Cc: Peter Wemm , Terry Lambert , Christoph Kukulies , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Seems I have kicked off an avalanche :-) : :Someone was mentioning in an off-net discussion with some linux :guys, that when using timeval struct in select the time structure :members were dealt differently (units, offsets? - not clear what :my discussion partner meant, but it alarmed me a bit). But OTOH, :when XFree86 is running on both all I'd have to do is looking perhaps :in the XFree86 source.. : :-- :Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de Ah yes, I remember it well. select(fd, rfds, wfds, xfds, tv) The problem is that linux updates the timeval structure on return, telling you how much time is left. Many programs assumed that tv was const... i.e. not modified by the call, and so would initialize the structure once then use it multiple times. I don't know what linux does now, but most programs these days reinitialize tv on each select() call in order to work around any potential problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 01:55:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA06558 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 01:55:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06547 for ; Wed, 10 Feb 1999 01:55:34 -0800 (PST) (envelope-from etxgnon@etxb.ericsson.se) Received: from avx6 (avx6-unix2.etxb.ericsson.se [130.100.190.16]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with SMTP id KAA25798 for ; Wed, 10 Feb 1999 10:55:28 +0100 (MET) Received: from avc354.etxb.ericsson.se by avx6 (SMI-8.6/LME-2.2.6) id KAA09552; Wed, 10 Feb 1999 10:55:29 +0100 Received: from etxb.ericsson.se by avc354.etxb.ericsson.se (SMI-8.6/client-1.6) id KAA06584; Wed, 10 Feb 1999 10:55:30 +0100 Message-ID: <36C15791.1AB1F18A@etxb.ericsson.se> Date: Wed, 10 Feb 1999 10:55:29 +0100 From: Gunnar Olsson Organization: ETX-DN-SL X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" , etxgnon@etxb.ericsson.se Subject: real time measurements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi there, I'm doing real time measurements through a PC, which I use as a router. Sometimes a packet is delayed through the system, even though the load is low. I have tried to disable all not necessary processes, but still I can see this delay. Does anyone know if something is going around in the system? Some parameter I can set? Please let me know! Regards Gunnar (gunnar.olsson@ericsson.com) -- wwwww g( o o )g --oOO--(_)---OOo-------------------------------------------- E-mail: gunnar.olsson@ericsson.com .ooo0 0ooo. ( ) ( ) ----\ (---) /----------------------------------------------- \_) (_/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 02:32:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA08925 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 02:32:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA08920 for ; Wed, 10 Feb 1999 02:32:40 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id KAA26540; Wed, 10 Feb 1999 10:32:14 GMT From: Emmanuel DELOGET Message-Id: <199902101032.KAA26540@excalibur.oceanis.net> Subject: Re: Adding sysctl entries In-Reply-To: from Boris Popov at "Feb 10, 1999 7:33:41 am" To: bp@butya.kz (Boris Popov) Date: Wed, 10 Feb 1999 11:32:13 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As Boris Popov said... ** On Tue, 9 Feb 1999, Emmanuel DELOGET wrote: ** ** > ** > I wanna add some sysctl entries to a loadable kernel ** > ** > module. As I'm sure I'm not the first doing that, ** > ** > if anybody knows... ** > ** ** > ** It is not possible at the moment. :-( ** > ** > The result seems bad... I had to compile the kernel, then to ** > reboot... Each time I wonder wether I added a bug or not... ** > And if there is a bug, I'm out... Any idea would be welcome... ** ** You can try this: take code from any file system (null fs for ** simplicity) and look at nfs_vfsops variable in /sys/nfs/nfs_vfsops.c file. ** The last structure element do the trick. Of course, your kld become a VFS ** type, but I hope this will not be necessary soon. It seems (but I have not tried yet) that this may not work. A little more precisions : I'm using a 2.2.8 kernel, with nfs built as a lkm, and the nfs related sysctls does not appears when I sysctl(8) -A ... Of course, I may have do something wrong :) But I'll try as soon as possible. If I'm not misunderstanging your mail, the code I need may exists in the nfs_init() function. Tell me if I'm wrong. Thanks a lot. ** ** -- ** Boris Popov ** -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 02:35:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09271 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 02:35:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA09266 for ; Wed, 10 Feb 1999 02:35:23 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id KAA26604; Wed, 10 Feb 1999 10:34:54 GMT From: Emmanuel DELOGET Message-Id: <199902101034.KAA26604@excalibur.oceanis.net> Subject: Re: Adding sysctl entries In-Reply-To: <199902091846.KAA03973@dingo.cdrom.com> from Mike Smith at "Feb 9, 1999 10:46:32 am" To: mike@smith.net.au (Mike Smith) Date: Wed, 10 Feb 1999 11:34:54 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As Mike Smith said... ** > The result seems bad... I had to compile the kernel, then to ** > reboot... Each time I wonder wether I added a bug or not... ** > And if there is a bug, I'm out... Any idea would be welcome... ** ** This is why you have more than one kernel image in /, and why you can ** select which kernel to boot when you come up. ** Er... I would have said : if the kernel hangs/badly boot, I'm to reboot again... That's two boot to add some sysctls... :) ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 02:37:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09487 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 02:37:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA09482 for ; Wed, 10 Feb 1999 02:37:45 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id KAA26651; Wed, 10 Feb 1999 10:36:47 GMT From: Emmanuel DELOGET Message-Id: <199902101036.KAA26651@excalibur.oceanis.net> Subject: Re: Adding sysctl entries In-Reply-To: from Doug Rabson at "Feb 9, 1999 7:45: 4 pm" To: dfr@nlsystems.com.demon.co.uk (Doug Rabson) Date: Wed, 10 Feb 1999 11:36:47 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As Doug Rabson said... ** On Tue, 9 Feb 1999, Mike Smith wrote: ** ** > > someone said thay had code already.. ** > > was it warner? or maybe one of the Johns. ** > ** > Doug Rabson, IIRC. ** ** I have some code. I would like to commit it but I haven't managed to find ** a reviewer yet (not that I have pushed that hard). Considering what ** happened to the last guy that tried to change sysctl, I'm not going to ** commit it without a review. ** It would be nice if I could see. Thanks. ** ** -- ** Doug Rabson Mail: dfr@nlsystems.com ** Nonlinear Systems Ltd. Phone: +44 181 442 9037 ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 03:05:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11472 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 03:05:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11405; Wed, 10 Feb 1999 03:04:45 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id LAA21824; Wed, 10 Feb 1999 11:03:13 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 10 Feb 1999 11:03:13 +0000 (GMT) From: Doug Rabson X-Sender: dfr@localhost To: Doug Rabson cc: Mike Smith , Julian Elischer , Dag-Erling Smorgrav , Eivind Eklund , Emmanuel DELOGET , FreeBSD Hackers Mail List Subject: Re: Adding sysctl entries In-Reply-To: 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 Tue, 9 Feb 1999, Doug Rabson wrote: > On Tue, 9 Feb 1999, Mike Smith wrote: > > > > someone said thay had code already.. > > > was it warner? or maybe one of the Johns. > > > > Doug Rabson, IIRC. > > I have some code. I would like to commit it but I haven't managed to find > a reviewer yet (not that I have pushed that hard). Considering what > happened to the last guy that tried to change sysctl, I'm not going to > commit it without a review. You can find a set of diffs to a fairly recent -current at http://www.freebsd.org/~dfr/sysctl.diffs. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 03:22:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12684 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 03:22:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12679 for ; Wed, 10 Feb 1999 03:22:55 -0800 (PST) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.1/8.8.8) id LAA76014; Wed, 10 Feb 1999 11:21:17 GMT (envelope-from joe) Date: Wed, 10 Feb 1999 11:21:17 +0000 From: Josef Karthauser To: Kris Kennaway Cc: Max Khon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates Message-ID: <19990210112117.E71367@florence.pavilion.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Wed, Feb 10, 1999 at 02:43:04PM +1030 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-1273-607072 Fax: +44-1273-607073 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 10, 1999 at 02:43:04PM +1030, Kris Kennaway wrote: > On Tue, 9 Feb 1999, Max Khon wrote: > > > what is the current status of softupdates? > > is it safe to turn on softupdates (no ccd)? > > It's been working just fine here for at least the last 6 months.. I haven't > heard any softupdates-related panics/crashes on the mailing lists in a while. We're running FreeBSD3.0-Stable with CCD and softupdates on two systems, each with two 9gb cheetah drives striped, with no problems: Machine1: /dev/ccd0c on /data (local, soft-updates, writes: sync 8069 async 1135034) /dev/ccd0c 17213895 3718658 12118126 23% /data Machine2: /dev/ccd0c on /data (local, soft-updates, writes: sync 130287 async 1420107) /dev/ccd0c 16705735 3433094 11936183 22% /data Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 03:23:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12729 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 03:23:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12724 for ; Wed, 10 Feb 1999 03:23:44 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from daniel.sobral by peach.ocn.ne.jp (8.9.1a/OCN) id UAA09812; Wed, 10 Feb 1999 20:23:39 +0900 (JST) Received: (from dcs@localhost) by daniel.sobral (8.9.1/8.9.2) id UAA00344 for hackers@freebsd.org; Wed, 10 Feb 1999 20:23:00 +0900 (JST) (envelope-from dcs) From: "Daniel C. Sobral" Message-Id: <199902101123.UAA00344@daniel.sobral> Subject: fnsrcw/fninit/fldcw To: hackers@FreeBSD.ORG Date: Wed, 10 Feb 1999 20:22:54 +0900 (JST) Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can anyone explain to me what these intructions do? Are they in any way related to fp? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Iowa State -- the high school after high school! -- Crow T. Robot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 05:02:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23640 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 05:02:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ceia.nordier.com (m2-28-dbn.dial-up.net [196.34.155.92]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23627 for ; Wed, 10 Feb 1999 05:02:06 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id PAA00732; Wed, 10 Feb 1999 15:00:55 +0200 (SAT) From: Robert Nordier Message-Id: <199902101300.PAA00732@ceia.nordier.com> Subject: Re: fnsrcw/fninit/fldcw In-Reply-To: <199902101123.UAA00344@daniel.sobral> from "Daniel C. Sobral" at "Feb 10, 99 08:22:54 pm" To: dcs@newsguy.com (Daniel C. Sobral) Date: Wed, 10 Feb 1999 15:00:52 +0200 (SAT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (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 Daniel C. Sobral wrote: > Can anyone explain to me what these intructions do? Are they in any way > related to fp? Yes, they're all i386 fp instructions (assuming "fnsrcw" is a typo): fninit initialize processor fldcw load control word fnstcw store control word -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 06:30:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03754 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 06:30:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03745 for ; Wed, 10 Feb 1999 06:30:16 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA13435; Wed, 10 Feb 1999 15:30:08 +0100 (CET) (envelope-from des) To: Matthew Dillon Cc: Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 10 Feb 1999 15:30:07 +0100 In-Reply-To: Matthew Dillon's message of "Wed, 10 Feb 1999 01:07:44 -0800 (PST)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > The problem is that linux updates the timeval structure on return, > telling you how much time is left. Yup. I wish FreeBSD did that - the man page already states that one shouldn't rely on tv not being modified, so it shouldn't break POLA. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 06:52:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06767 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 06:52:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA06762 for ; Wed, 10 Feb 1999 06:52:05 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA13745; Wed, 10 Feb 1999 23:51:27 +0900 (JST) Message-ID: <36C19CC9.62FAA6F7@newsguy.com> Date: Wed, 10 Feb 1999 23:50:49 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav CC: Matthew Dillon , Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Matthew Dillon writes: > > The problem is that linux updates the timeval structure on return, > > telling you how much time is left. > > Yup. I wish FreeBSD did that - the man page already states that one > shouldn't rely on tv not being modified, so it shouldn't break POLA. Manual pages aren't POLA. They are specs. Traditional usage is POLA. Wanna different different behavior? Create a different function. Besides, given that most usages have no need for this, it would be a wast of space and time. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Well, as a computer geek, I have to believe in the binary universe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:02:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA08247 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:02:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA08238 for ; Wed, 10 Feb 1999 07:02:39 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id QAA13877; Wed, 10 Feb 1999 16:02:24 +0100 (CET) (envelope-from des) To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , Matthew Dillon , Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> <36C19CC9.62FAA6F7@newsguy.com> From: Dag-Erling Smorgrav Date: 10 Feb 1999 16:02:24 +0100 In-Reply-To: "Daniel C. Sobral"'s message of "Wed, 10 Feb 1999 23:50:49 +0900" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > Dag-Erling Smorgrav wrote: > > Matthew Dillon writes: > > > The problem is that linux updates the timeval structure on return, > > > telling you how much time is left. > > Yup. I wish FreeBSD did that - the man page already states that one > > shouldn't rely on tv not being modified, so it shouldn't break POLA. > Manual pages aren't POLA. They are specs. Traditional usage is POLA. > Wanna different different behavior? Create a different function. Yep, man pages are specs, and when the spec says tv may be modified by select(), that means you can't expect it to remain untouched. > Besides, given that most usages have no need for this, it would be a > wast of space and time. On the contrary, it is extremely useful for implementing higher-level timeouts. If you want to see the new installer come true, I need to implement protocol-level timeouts in libfetch, and that means either add a lot of gettimeofday() logic or fix select() to modify tv. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:19:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA10464 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:19:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA10264 for ; Wed, 10 Feb 1999 07:18:45 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA18468; Wed, 10 Feb 1999 14:04:17 +0100 From: Luigi Rizzo Message-Id: <199902101304.OAA18468@labinfo.iet.unipi.it> Subject: Re: real time measurements To: etxgnon@etxb.ericsson.se (Gunnar Olsson) Date: Wed, 10 Feb 1999 14:04:17 +0100 (MET) Cc: hackers@FreeBSD.ORG, etxgnon@etxb.ericsson.se In-Reply-To: <36C15791.1AB1F18A@etxb.ericsson.se> from "Gunnar Olsson" at Feb 10, 99 10:55:10 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm doing real time measurements through a PC, > which I use as a router. Sometimes a packet is delayed > through the system, even though the load is low. > I have tried to disable all not necessary processes, > but still I can see this delay. > > Does anyone know if something is going around in the > system? Some parameter I can set? > Please let me know! how much delay, and how can you tell that -- it could be delayed by ethernet collisions or anything. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:34:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA12228 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:34:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA12222 for ; Wed, 10 Feb 1999 07:34:41 -0800 (PST) (envelope-from etxgnon@etxb.ericsson.se) Received: from avx6 (avx6-unix2.etxb.ericsson.se [130.100.190.16]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with SMTP id QAA27725; Wed, 10 Feb 1999 16:34:16 +0100 (MET) Received: from avc354.etxb.ericsson.se by avx6 (SMI-8.6/LME-2.2.6) id QAA03624; Wed, 10 Feb 1999 16:34:13 +0100 From: etxgnon@etxb.ericsson.se (Gunnar Olsson) Received: by avc354.etxb.ericsson.se (SMI-8.6/client-1.6) id QAA06615; Wed, 10 Feb 1999 16:34:15 +0100 Date: Wed, 10 Feb 1999 16:34:15 +0100 Message-Id: <199902101534.QAA06615@avc354.etxb.ericsson.se> To: luigi@labinfo.iet.unipi.it Subject: Re: real time measurements Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From majordom@FreeBSD.ORG Wed Feb 10 16:20 MET 1999 > Delivered-To: vmailer-hackers@freebsd.org > From: Luigi Rizzo > Subject: Re: real time measurements > To: etxgnon@etxb.ericsson.se (Gunnar Olsson) > Date: Wed, 10 Feb 1999 14:04:17 +0100 (MET) > Cc: hackers@FreeBSD.ORG, etxgnon@etxb.ericsson.se > X-Loop: FreeBSD.ORG > > > I'm doing real time measurements through a PC, > > which I use as a router. Sometimes a packet is delayed > > through the system, even though the load is low. > > I have tried to disable all not necessary processes, > > but still I can see this delay. > > > > Does anyone know if something is going around in the > > system? Some parameter I can set? > > Please let me know! > > how much delay, and how can you tell that -- it could be delayed by > ethernet collisions or anything. > > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Hi, no collision problems. One incoming port and one outgoing port and no congestion. I have now time stamp the packets trough the system and find an increase from normal 5 microsecunds to 200 microsecund between the functions ip_input and ip_output sometimes. Any ideas? Regards, Gunnar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:47:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13691 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:47:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13686 for ; Wed, 10 Feb 1999 07:47:15 -0800 (PST) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.2/8.9.1) id HAA10217; Wed, 10 Feb 1999 07:46:59 -0800 (PST) (envelope-from mph) Date: Wed, 10 Feb 1999 07:46:58 -0800 From: Matthew Hunt To: phoenix@calldei.com Cc: GReg Sutter , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Proposal: Ignore .nofinger for root Message-ID: <19990210074658.A10003@wopr.caltech.edu> References: <19990209200259.A98301@wopr.caltech.edu> <19990210082606.B58482@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990210082606.B58482@holly.dyndns.org>; from Chris Costello on Wed, Feb 10, 1999 at 08:26:06AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 10, 1999 at 08:26:06AM -0600, Chris Costello wrote: > Yes. Why? Well, I thought the rationale was trivial: To provide accurate information to the superuser. On further reflection, though, that the patch is poor design, although the argument is more subtle than your argument of "why?" or Greg Lehey's argument that using finger on a local system is somehow perverse. I thought a good argument for the patch goes something like this: The superuser has access to all of the information provided by finger on a local system anyhow, so allowing ~/.nofinger only serves to mislead him or make it less convenient for him to get to the information he wants. However, that statement is true for all local users, not just the superuser. Any user on the system who wanted to get around the "protection" of ~/.nofinger could just build a new "finger" with the hide() check removed. The conclusion, therefore, is that if a change were to be made, it should be that finger(1) ignores ~/.nofinger for all local users. The effects of such a change are more far-reaching than I feel appropriate, so I withdraw the proposal. I suppose that root has to use a mixture of w and something like chpass or pw if he wants accurate information. Something still doesn't seem right to me about finger lying to the superuser by saying that a real user doesn't even exist... -- Matthew Hunt * Science rules. http://www.pobox.com/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:51:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14187 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:51:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14176 for ; Wed, 10 Feb 1999 07:51:22 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id QAA02781; Wed, 10 Feb 1999 16:56:46 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 10 Feb 1999 16:56:46 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Gunnar Olsson cc: luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: real time measurements In-Reply-To: <199902101534.QAA06615@avc354.etxb.ericsson.se> 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, 10 Feb 1999, Gunnar Olsson wrote: > no collision problems. > One incoming port and one outgoing port and no congestion. > I have now time stamp the packets trough the system and find > an increase from normal 5 microsecunds to 200 microsecund between > the functions ip_input and ip_output sometimes. > > Any ideas? Yes. You may have been hit by an interrupt. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:53:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14898 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:53:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14891 for ; Wed, 10 Feb 1999 07:53:50 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA24033; Thu, 11 Feb 1999 00:53:43 +0900 (JST) Message-ID: <36C1AB60.EEEED9E0@newsguy.com> Date: Thu, 11 Feb 1999 00:53:04 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> <36C19CC9.62FAA6F7@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > > Manual pages aren't POLA. They are specs. Traditional usage is POLA. > > Wanna different different behavior? Create a different function. > > Yep, man pages are specs, and when the spec says tv may be modified by > select(), that means you can't expect it to remain untouched. What you can "expect" is one thing. What you have been doing all your life is another. The principle of least astonishment concerns with what people are used to do. The way the man page is written right now is so that we have something to point to if we decide we want to break POLA. Not very smart, if you ask me. Point in case, the applications that broke with Linux because of this. They broke because they did not expect such behavior. Ie, Linux violated POLA. > > Besides, given that most usages have no need for this, it would be a > > wast of space and time. > > On the contrary, it is extremely useful for implementing higher-level > timeouts. If you want to see the new installer come true, I need to > implement protocol-level timeouts in libfetch, and that means either > add a lot of gettimeofday() logic or fix select() to modify tv. I'm not saying it is extremely useful where it _is_ useful. :-) In fact, I have needed it on occasion. What I'm saying is that _most_ uses of select() are not concerned with this. It is, therefore, wasteful to add this functionality to select() (aside from breaking POLA). I am all for a *different* function with this added functionality. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Well, as a computer geek, I have to believe in the binary universe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 07:58:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15327 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 07:58:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA15283 for ; Wed, 10 Feb 1999 07:57:59 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id KAA01257 for ; Wed, 10 Feb 1999 10:57:57 -0500 (EST) Message-Id: <199902101557.KAA01257@cs.rpi.edu> To: freebsd-hackers@FreeBSD.ORG Subject: suggestion for modular system configuration Date: Wed, 10 Feb 1999 10:57:57 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I suggested this once before, but I never even saw my own post (I usually do), so I will assume it got tossed in a bit bucket somewhere. We have a large number and diversity of systems here, Irix, Solaris, FreeBSD, and I have worked with DG-UX, SCO, OSF/1, Digital Unix, and a couple of others I cannot remember at a previous job. Of all of these Irix has the easiest and most flexable configuration utility for the stuff that rc.conf does, 'chkconfig'. It is a trivial program that works like the following: if chkconfig inetd; then /usr/sbin/inetd fi when chkconfig is run it looks for a file named /etc/config/$argv[1], that file simply contains one word 'on' or 'off'. If the file contains 'on', chkconfig returns true, 'off' false. This allows one to simply untar a file (or a couple of files) into the directory w/o having to edit any scripts, and have all of the new configs in place. I propose that we adopt this system, with a couple of modifications that will make it even more powerfull and usefull. Have an optional variable 'CHKCONFIGPATH', that would behave similarly to 'XUSERFILESEARCHPATH' with respect to haveing some optional '%' expansions. Here is a preliminary idea: %N _N_ame, equal to what is passed in argv[1]. %H _H_ost, fqdn. %h _h_ost, hostname. A CHKCONFIGPATH path element that had no '%' expansions in it would default to ending with '/%N'. A reasonable default CHKCONFIGPATH may well be: /etc/config/%N:/usr/local/etc/config/%h/%N:/usr/local/etc/config/%N -or perhaps- /etc/config/%h/%N:/etc/config/%N:/usr/local/etc/config/%h/%N:/usr/local/etc/config/%N (the occurance in the path 'wins'). This has tremendous potential, such as being able to reconfigure a system w/o ever needing to log into it (usefull for example if a service is running amuck, and you cannot log into the system; change the config, reboot (which I am assuming for this argument you need to do anyway :), and it comes back w/o haveing to be on console to alter the boot proces at all. This would be a huge win for us here as we have a shared /usr/local, and with putting 'httpd.sh' in /usr/local/etc/rc.d as well as netatalk.sh and others we have had to do some special things to get only certain packages to run on certain hosts (it usually involves sucking in the entire rc.conf for EVERY SINGLE rc-file... as is already done by the system rc-files. *yuck*) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:07:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16175 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:07:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA16162 for ; Wed, 10 Feb 1999 08:07:42 -0800 (PST) (envelope-from dirk.vangulik@jrc.it) Received: from jrc.it (elpc51.jrc.it [139.191.71.51]) by mrelay.jrc.it (LMC5692) with ESMTP id RAA21778 for ; Wed, 10 Feb 1999 17:09:34 +0100 (MET) Message-ID: <36C1ADBF.CE85DF2E@jrc.it> Date: Wed, 10 Feb 1999 17:03:11 +0100 From: Dirk-Willem van Gulik Organization: ISIS/STA - Joint Research Center of the European Commission X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {PEN/1.01} (Win95; I) X-Accept-Language: zh,de,en,fr,sv MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: My ignorance (lsof shows shared lib's). Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Forgive me my ignorance; but why would one see open file descriptors for the shared libraries; long after (I would) assume that they have been read in and used. Is that not a one off thing ? Dw. httpsd 11646 nobody txt VREG 0,131077 422937 61527 /usr/lib/libc.so.3.1 httpsd 11646 nobody txt VREG 0,131077 13581 92418 /usr/local/lib/perl5/i386-freebsd/5.00404/auto/IO/IO.so httpsd 11646 nobody txt VREG 0,131077 184758 77089 /usr/local/lib/perl5/site_perl/i386-freebsd/auto/GD/GD.so httpsd 11646 nobody txt VREG 0,131077 35724 77016 /usr/local/lib/perl5/site_perl/i386-freebsd/auto/Storable/Storable.so httpsd 11646 nobody txt VREG 0,131077 56514 77052 /usr/local/lib/perl5/site_perl/i386-freebsd/auto/DBI/DBI.so httpsd 11646 nobody txt VREG 0,131077 27887 8150 /usr/local/lib/perl5/i386-freebsd/5.00404/auto/DB_File/DB_File.so httpsd 11646 nobody txt VREG 0,131077 22054 92533 /usr/local/lib/perl5/site_perl/i386-freebsd/auto/DBMS/DBMS.so httpsd 11646 nobody txt VREG 0,131077 133977 38841 /usr/local/lib/perl5/site_perl/i386-freebsd/auto/XML/Parser/Expat/Expat.so To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:29:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18427 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:29:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18421 for ; Wed, 10 Feb 1999 08:29:31 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id IAA01051; Wed, 10 Feb 1999 08:29:30 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id IAA53619; Wed, 10 Feb 1999 08:29:29 -0800 (PST) (envelope-from jdp@polstra.com) Date: Wed, 10 Feb 1999 08:29:29 -0800 (PST) Message-Id: <199902101629.IAA53619@vashon.polstra.com> To: dirk.vangulik@jrc.it Subject: Re: My ignorance (lsof shows shared lib's). In-Reply-To: <36C1ADBF.CE85DF2E@jrc.it> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <36C1ADBF.CE85DF2E@jrc.it>, Dirk-Willem van Gulik wrote: > Forgive me my ignorance; but why would one see open file descriptors > for the shared libraries; long after (I would) assume that they have > been read in and used. Is that not a one off thing ? > > Dw. > > httpsd 11646 nobody txt VREG 0,131077 422937 61527 > /usr/lib/libc.so.3.1 > httpsd 11646 nobody txt VREG 0,131077 13581 92418 > /usr/local/lib/perl5/i386-freebsd/5.00404/auto/IO/IO.so > httpsd 11646 nobody txt VREG 0,131077 184758 77089 > /usr/local/lib/perl5/site_perl/i386-freebsd/auto/GD/GD.so > httpsd 11646 nobody txt VREG 0,131077 35724 77016 > /usr/local/lib/perl5/site_perl/i386-freebsd/auto/Storable/Storable.so > httpsd 11646 nobody txt VREG 0,131077 56514 77052 > /usr/local/lib/perl5/site_perl/i386-freebsd/auto/DBI/DBI.so > httpsd 11646 nobody txt VREG 0,131077 27887 8150 > /usr/local/lib/perl5/i386-freebsd/5.00404/auto/DB_File/DB_File.so > httpsd 11646 nobody txt VREG 0,131077 22054 92533 > /usr/local/lib/perl5/site_perl/i386-freebsd/auto/DBMS/DBMS.so > httpsd 11646 nobody txt VREG 0,131077 133977 38841 > /usr/local/lib/perl5/site_perl/i386-freebsd/auto/XML/Parser/Expat/Expat.so There aren't open file descriptors for the shared libraries. I checked the dynamic linker sources just to make sure. It closes the files as soon as they have been mapped into memory. The reason lsof sees them is because they're memory mapped. Shared libraries aren't really "read in and used" all at once. Instead, they're mapped directly into the address space. Over time, as the process accesses various pages from the shared libraries, the pages are demand-loaded from the files by the kernel. Thus the process has a grip on all the shared library files even though it no longer holds open file descriptors for them. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:30:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18603 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:30:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18591 for ; Wed, 10 Feb 1999 08:30:34 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA09410; Wed, 10 Feb 1999 09:30:20 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd009282; Wed Feb 10 09:30:15 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA08698; Wed, 10 Feb 1999 09:30:06 -0700 (MST) From: Terry Lambert Message-Id: <199902101630.JAA08698@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: peter@netplex.com.au (Peter Wemm) Date: Wed, 10 Feb 1999 16:30:05 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902100403.MAA55849@spinner.netplex.com.au> from "Peter Wemm" at Feb 10, 99 12:03:43 pm X-Mailer: ELM [version 2.4 PL25] 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 > > FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since sockets are not backed by true vnode objects. > > Terry, read the bloody source before spreading unverified FUD like this.. > The fcntl(2) ops F_SETOWN/F_GETOWN are translated into FIOSETOWN/FIOGETOWN > ioctl's and are fully implemented. Sorry; I didn't realize that someone had kludged this to "work" after the last time someone complained about it not working. > However, as you point out, the fcntl() > (and flock()) *locking* operations are not implemented. IMHO file locking > on a socket is of pretty marginal value since there is no seek space > (with the possible exception of using it for a mutex instead of using > sendmsg() or something sensible). Yeah; the putative utility isn't really at issue, though, only whether it works on Linux and not on FreeBSD. You could make the same argument about value on SYSV IPC, since it's not select(2)'able. > > > pipes - ? named pipes? > > > > FreeBSD pipes are bidirectional, since they are implemented with the > > AF_UNIX socket code. > > Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been > for a *long* time (since 1996 when 2.2 was branched). Sorry again; I got confused. It's the IPC code that's implemented with the sys_socket.c's struct fileops referenced by uipc_syscalls.c. > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since pipes are not backed by true vnode objects. > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > *Only* the file locking parts are not implemented since it's of such little > value with no seek space. Hmmmm. From my reading of the sources, this is actually a fairly recent addition (November 11th, 1998, by Truckman). I blame my build environment for that particular lapse. I still don't think the non-existance of a real vs. a virtual seek space is relevent. The obvious way to fix this is to hang the locks off the vnode, and move the advisory locking out of all FS's (except the network clients, of course, which may need to veto lock coelescence if the server refuses the lock). In any case, thanks for the corrections; it all adds to the general knowledge base, which is important, since no one else stepped forward with the information. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:36:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA19179 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:36:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19174 for ; Wed, 10 Feb 1999 08:36:16 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id IAA16644; Wed, 10 Feb 1999 08:33:43 -0800 (PST) Message-Id: <199902101633.IAA16644@implode.root.com> To: Terry Lambert cc: peter@netplex.com.au (Peter Wemm), kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Wed, 10 Feb 1999 16:30:05 GMT." <199902101630.JAA08698@usr07.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 10 Feb 1999 08:33:43 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > > pipes - ? named pipes? >> > >> > FreeBSD pipes are bidirectional, since they are implemented with the >> > AF_UNIX socket code. >> >> Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been >> for a *long* time (since 1996 when 2.2 was branched). > >Sorry again; I got confused. It's the IPC code that's implemented with >the sys_socket.c's struct fileops referenced by uipc_syscalls.c. Wrong file for pipes. See sys_pipe.c. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:42:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA19653 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:42:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19646 for ; Wed, 10 Feb 1999 08:42:55 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id JAA23796; Wed, 10 Feb 1999 09:45:32 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd023692; Wed Feb 10 09:45:22 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA10080; Wed, 10 Feb 1999 09:42:26 -0700 (MST) From: Terry Lambert Message-Id: <199902101642.JAA10080@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dg@root.com Date: Wed, 10 Feb 1999 16:42:26 +0000 (GMT) Cc: tlambert@primenet.com, peter@netplex.com.au, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902101633.IAA16644@implode.root.com> from "David Greenman" at Feb 10, 99 08:33:43 am X-Mailer: ELM [version 2.4 PL25] 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 > >> > > pipes - ? named pipes? > >> > > >> > FreeBSD pipes are bidirectional, since they are implemented with the > >> > AF_UNIX socket code. > >> > >> Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been > >> for a *long* time (since 1996 when 2.2 was branched). > > > >Sorry again; I got confused. It's the IPC code that's implemented with > >the sys_socket.c's struct fileops referenced by uipc_syscalls.c. > > Wrong file for pipes. See sys_pipe.c. Right. I am no longer pointing at the pipes and sockets as sharing code, I'm pointing at the socket and the SysV IPC. I was agreeing with Peter that I was wrong about the pipe code being shared. Oh, in case it got lost in the ensuing discussion because of my mistake: FreeBSD pipes *are* bidirectional, which is a difference from Linux and other OS's, in general. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 08:52:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20455 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:52:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20448 for ; Wed, 10 Feb 1999 08:52:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id RAA26213; Wed, 10 Feb 1999 17:52:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA03676; Wed, 10 Feb 1999 17:52:33 +0100 (MET) Date: Wed, 10 Feb 1999 17:52:32 +0100 From: Eivind Eklund To: Kris Kennaway Cc: Max Khon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates Message-ID: <19990210175232.P96008@bitbox.follo.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Wed, Feb 10, 1999 at 02:43:04PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 10, 1999 at 02:43:04PM +1030, Kris Kennaway wrote: > On Tue, 9 Feb 1999, Max Khon wrote: > > > what is the current status of softupdates? > > is it safe to turn on softupdates (no ccd)? > > It's been working just fine here for at least the last 6 months.. I > haven't heard any softupdates-related panics/crashes on the mailing > lists in a while. There was at least one bug in the soft updates code for 3.0-RELEASE. I've not heard of any problems occuring due to it, but it was there :-) I don't know of any problems in 3.0-stable/3.1-beta, except for free space from deletion not becoming available immediately. This needs more code, not bugfixes, however. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 09:23:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23512 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 09:23:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23495 for ; Wed, 10 Feb 1999 09:23:53 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.1/8.9.1) id JAA02400 for freebsd-hackers@FreeBSD.ORG; Wed, 10 Feb 1999 09:22:09 -0800 (PST) (envelope-from dhw) Date: Wed, 10 Feb 1999 09:22:09 -0800 (PST) From: David Wolfskill Message-Id: <199902101722.JAA02400@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: suggestion for modular system configuration In-Reply-To: <199902101557.KAA01257@cs.rpi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Wed, 10 Feb 1999 10:57:57 -0500 >From: "David E. Cross" [Lots of elisions -- dhw] > if chkconfig inetd; then > /usr/sbin/inetd > fi >when chkconfig is run it looks for a file named /etc/config/$argv[1], that >file simply contains one word 'on' or 'off'. If the file contains 'on', >chkconfig returns true, 'off' false. >I propose that we adopt this system, with a couple of modifications that will >make it even more powerfull and usefull. Have an optional variable >'CHKCONFIGPATH', that would behave similarly to 'XUSERFILESEARCHPATH' with >respect to haveing some optional '%' expansions. >Here is a preliminary idea: >%N _N_ame, equal to what is passed in argv[1]. >%H _H_ost, fqdn. >%h _h_ost, hostname. >A CHKCONFIGPATH path element that had no '%' expansions in it would default to >ending with '/%N'. A reasonable default CHKCONFIGPATH may well be: >/etc/config/%N:/usr/local/etc/config/%h/%N:/usr/local/etc/config/%N >-or perhaps- >/etc/config/%h/%N:/etc/config/%N:/usr/local/etc/config/%h/%N:/usr/local/etc/config/%N >(the occurance in the path 'wins'). The idea, dissimilar though it may be to traditional BSD practice, certainly has its attractions. I believe that providing an ability to do a "dry run" (to see what would be started/stopped, and in what order, but without actually starting or stopping processes) would be quite useful. (I tend to do this sort of thing with the Perl scripts that I write, for example.) >This would be a huge win for us here as we have a shared /usr/local, and >with putting 'httpd.sh' in /usr/local/etc/rc.d as well as netatalk.sh and >others we have had to do some special things to get only certain packages >to run on certain hosts (it usually involves sucking in the entire rc.conf >for EVERY SINGLE rc-file... as is already done by the system rc-files. *yuck*) I can empathize with that, certainly.... Cheers, david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 09:24:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23618 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 09:24:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23609 for ; Wed, 10 Feb 1999 09:24:37 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id KAA12874; Wed, 10 Feb 1999 10:27:21 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd012682; Wed Feb 10 10:27:04 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA13526; Wed, 10 Feb 1999 10:24:02 -0700 (MST) From: Terry Lambert Message-Id: <199902101724.KAA13526@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dg@root.com Date: Wed, 10 Feb 1999 17:24:00 +0000 (GMT) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902092341.PAA09407@implode.root.com> from "David Greenman" at Feb 9, 99 03:41:22 pm X-Mailer: ELM [version 2.4 PL25] 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 > >:The overall size of the shared memory segment is limited to that > >: which can fit in the kernels virtual address space; this > >: artificially restricts the maximum size. > > That isn't true and hasn't been true for several years in FreeBSD. Are you sure? >From my reading of sysv_shm.c: shmmap_s = malloc(size, M_SHM, M_WAITOK); seems to limit the size to what's allocable in the KVA. I only make the distinction because files can be mmap'ed in sections to exceed the offset limits for vm_object_t. I guess if we are still examining Linux vs. FreeBSD programming, then I should probably point out that SysV SHM is faster than non-anonymous mmap'ed memory, because writes don't have to be written through to the backing object. This kind of implies that it would be nice to have an extension to the PROCFS code to allow file-based access to backing objects for mapped regions. That would let you mmap MAP_ANON in one process, and access the segment from another (non-descendent) process, and dispense with the backing object that would otherwise be necessary for mmap based rendesvous. As it is right now, there is incentive to use SysV SHM in new programs on BSD to avoid the backing object write-back hit that comes with the use of the "more BSDish" mmap (e.g. this is why Oracle on FreeBSD uses SysV SHM instead of mmap). Hey, this is turning into a very interesting thread! We should ask ourselves more FreeBSD vs. XXX programming questions. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 09:39:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25007 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 09:39:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA25002 for ; Wed, 10 Feb 1999 09:39:04 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id KAA13514; Wed, 10 Feb 1999 10:38:51 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd013473; Wed Feb 10 10:38:48 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA14521; Wed, 10 Feb 1999 10:38:35 -0700 (MST) From: Terry Lambert Message-Id: <199902101738.KAA14521@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Wed, 10 Feb 1999 17:38:35 +0000 (GMT) Cc: dcs@newsguy.com, des@flood.ping.uio.no, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, peter@netplex.com.au, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 10, 99 04:02:24 pm X-Mailer: ELM [version 2.4 PL25] 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 > > > Matthew Dillon writes: > > > > The problem is that linux updates the timeval structure on return, > > > > telling you how much time is left. Linux doesn't do this in the default implementation any more. They have a seperate system call that still does this. > > > Yup. I wish FreeBSD did that - the man page already states that one > > > shouldn't rely on tv not being modified, so it shouldn't break POLA. > > > > Manual pages aren't POLA. They are specs. Traditional usage is POLA. > > Wanna different different behavior? Create a different function. > > Yep, man pages are specs, and when the spec says tv may be modified by > select(), that means you can't expect it to remain untouched. When writing new code. > > Besides, given that most usages have no need for this, it would be a > > wast of space and time. > > On the contrary, it is extremely useful for implementing higher-level > timeouts. If you want to see the new installer come true, I need to > implement protocol-level timeouts in libfetch, and that means either > add a lot of gettimeofday() logic or fix select() to modify tv. Actually, it's not that useful, unless you are somehow aware of the amount of time spent in processing in the case that the descriptors select true. I actually wrote an X game a while ago (a "LodeRunner" clone) that used the processing time information as part of the data. Basically, you have to set your timeout interval down to the amount of time that it takes to process in the case that the select comes true so that the "tick size" in both cases is the same, and then do things in terms of "ticks". Obviously, for smooth game play, the tick size varies based on the system you are running the code on, so a calibration loop is used to initialize it. In general, people bemoan the existance of timeout modification by the underlying code most often when they bring System V expectations into their use of th BSD select(2) call; expectations like "signals will interrupt instead of restarting system calls by default", etc.. In this particular case, a restart is supposed to start it where it left off, not from ground zero (SunOS 4.1.3 will do this, like most BSD4.3 based systems, but most BSD4.4 based systems won't). You can combine this with interval timers (or the badly documented HRT on SVR4) to get very good granularity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 09:47:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA26354 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 09:47:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA26348 for ; Wed, 10 Feb 1999 09:47:24 -0800 (PST) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id RAA62121 for freebsd-hackers@freebsd.org; Wed, 10 Feb 1999 17:47:19 GMT (envelope-from joe) Date: Wed, 10 Feb 1999 17:47:19 +0000 From: Josef Karthauser To: freebsd-hackers@FreeBSD.ORG Subject: Jordan! Did you break rc.conf today? :) Message-ID: <19990210174719.A60173@florence.pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-1273-607072 Fax: +44-1273-607073 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Jordan, I've just updated a production server to latest RELENG_3, and oops. /etc/rc.conf: ... # $Id: rc.conf,v 1.1 1999/02/09 22:15:18 jkh Exp $ rc_conf_files="/etc/rc.conf /etc/rc.conf.local" ... for i in ${rc_conf_files}; do if [ -f $i ]; then . $i fi done --- Oops, rc.conf gets into a big spin now cos it pulls itself in. Probably my fault cos I copied the version from /etc/defaults/rc.conf over the top of /etc/rc.conf because there was no reference to the one in defaults in any of the rc.* scripts. Joe. -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 09:53:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27015 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 09:53:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA27010 for ; Wed, 10 Feb 1999 09:53:45 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id JAA17281; Wed, 10 Feb 1999 09:42:16 -0800 (PST) Message-Id: <199902101742.JAA17281@implode.root.com> To: Terry Lambert cc: dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Wed, 10 Feb 1999 17:24:00 GMT." <199902101724.KAA13526@usr07.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 10 Feb 1999 09:42:16 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >:The overall size of the shared memory segment is limited to that >> >: which can fit in the kernels virtual address space; this >> >: artificially restricts the maximum size. >> >> That isn't true and hasn't been true for several years in FreeBSD. > >Are you sure? Yes, I'm quite sure. >>From my reading of sysv_shm.c: > > shmmap_s = malloc(size, M_SHM, M_WAITOK); > >seems to limit the size to what's allocable in the KVA. The above malloc allocates space for a struct shmmap_state. RTSL. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 10:09:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28399 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 10:09:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28394 for ; Wed, 10 Feb 1999 10:09:40 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.2) with ESMTP id KAA44278; Wed, 10 Feb 1999 10:09:44 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Josef Karthauser cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Jordan! Did you break rc.conf today? :) In-reply-to: Your message of "Wed, 10 Feb 1999 17:47:19 GMT." <19990210174719.A60173@florence.pavilion.net> Date: Wed, 10 Feb 1999 10:09:44 -0800 Message-ID: <44274.918670184@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi Jordan, > > I've just updated a production server to latest RELENG_3, and oops. This should have been deleted, which I've just done, since it's moved into defaults. However, I forgot to commit the changes to the *other* files in /etc which you just reminded me to do also. :) Fixed. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 10:14:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28870 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 10:14:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from server.noc.demon.net (server.noc.demon.net [193.195.224.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28865 for ; Wed, 10 Feb 1999 10:14:28 -0800 (PST) (envelope-from fanf@demon.net) Received: by server.noc.demon.net; id SAA29585; Wed, 10 Feb 1999 18:14:22 GMT Received: from fanf.noc.demon.net(195.11.55.83) by inside.noc.demon.net via smap (3.2) id xma029574; Wed, 10 Feb 99 18:14:09 GMT Received: from fanf by fanf.noc.demon.net with local (Exim 1.73 #2) id 10Ae9I-0004x0-00; Wed, 10 Feb 1999 18:14:08 +0000 To: hackers@FreeBSD.ORG From: Tony Finch Subject: PIPE_BUF Message-Id: Date: Wed, 10 Feb 1999 18:14:08 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been looking at the Apache code for doing buffered writes to logs, which it attempts to do in such a way that log records are not split across buffer boundaries. It therefore buffers up to PIPE_BUF bytes to be written in one go. Unfortunately, on FreeBSD this doesn't win us much because our log format averages over 200 bytes and PIPE_BUF is only 512 bytes, so we'll only be writing at most a couple of records at a time. Other systems have PIPE_BUF sizes like 4K (Linux), 5K (Solaris), and 10K (IRIX). What do I need to worry about if I rebuild the system with a bigger PIPE_BUF? (Actually, I don't really care about the buffer boundary thing so if changing PIPE_BUF is painful I'll just compile Apache to use a bigger buffer regardless of PIPE_BUF.) Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 10:27:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00298 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 10:27:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00293 for ; Wed, 10 Feb 1999 10:27:50 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA10939; Wed, 10 Feb 1999 11:30:30 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd010775; Wed Feb 10 11:30:23 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA17659; Wed, 10 Feb 1999 11:27:15 -0700 (MST) From: Terry Lambert Message-Id: <199902101827.LAA17659@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dg@root.com Date: Wed, 10 Feb 1999 18:27:03 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902101742.JAA17281@implode.root.com> from "David Greenman" at Feb 10, 99 09:42:16 am X-Mailer: ELM [version 2.4 PL25] 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 > >> >:The overall size of the shared memory segment is limited to that > >> >: which can fit in the kernels virtual address space; this > >> >: artificially restricts the maximum size. > >> > >> That isn't true and hasn't been true for several years in FreeBSD. > > > >Are you sure? > > Yes, I'm quite sure. > > >>From my reading of sysv_shm.c: > > > > shmmap_s = malloc(size, M_SHM, M_WAITOK); > > > >seems to limit the size to what's allocable in the KVA. > > The above malloc allocates space for a struct shmmap_state. RTSL. Gotcha. I didn't read it in much depth; I'd assumed that "_s" was "segment", not "state". I thought the "handle" malloc was the state. Mea culpa. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 10:40:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01719 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 10:40:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA01712 for ; Wed, 10 Feb 1999 10:40:19 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA15898; Wed, 10 Feb 1999 11:42:49 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd015858; Wed Feb 10 11:42:45 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA18447; Wed, 10 Feb 1999 11:39:49 -0700 (MST) From: Terry Lambert Message-Id: <199902101839.LAA18447@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 10 Feb 1999 18:39:49 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902092310.PAA61722@apollo.backplane.com> from "Matthew Dillon" at Feb 9, 99 03:10:52 pm X-Mailer: ELM [version 2.4 PL25] 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 > :FreeBSD has a unified vm and buffer cache. In theory, you do not > : need to call msync(2), ever, on such a system. However, > : there are a number of coherency bugs that make it necessary > : to call it (mostly in INN-type situations, where the file is > : being extended while it is mapped). > > What coherency bugs? As far as I know, extending a mmap()'d file > works just fine. You cannot *write* into the mmap()'d area beyond > the end of a file until you ftruncate() the file larger, but that is > true on all implementations that I know of. It is also appropriate - > the validity of the mmap()'d data only extends to the logical end of > file. Yes, yes, that's not the problem. The problem is that INN apparently still fails when using mmap without msync. The utility of msync is overrated; the code does not actually do what the manual page claims it does, in any case. > :FreeBSD semaphores are inadequately resource tracked in _exit(). > > All semaphores are inadequately resource tracked in _exit(), it's a > problem inherited from the SYSV implementation. Shared memory is badly tracked. But semaphores are supposed to be capable of being counted out by _exit(), per the SysV man pages for semop(2) an exit(2): http://www.freebsd.org/cgi/man.cgi?query=semop&sektion=2&apropos=0&manpath=SunOS+5.5.1 http://www.freebsd.org/cgi/man.cgi?query=exit&sektion=2&apropos=0&manpath=SunOS+5.5.1 FreeBSD either doesn't do this, or the FreeBSD manual pages are in error. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 10:57:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03562 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 10:57:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03555 for ; Wed, 10 Feb 1999 10:57:16 -0800 (PST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24189 for ; Wed, 10 Feb 1999 13:57:14 -0500 (EST) Received: from bmcgover-pc.cisco.com (localhost.pa.dtd.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.1/8.9.1) with ESMTP id NAA00779 for ; Wed, 10 Feb 1999 13:57:14 -0500 (EST) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199902101857.NAA00779@bmcgover-pc.cisco.com> To: hackers@FreeBSD.ORG Subject: How to attach line disciplines (aka Stupid Question #2962) Date: Wed, 10 Feb 1999 13:57:14 -0500 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm in the process of writing a relatively simple line discipline for doing some data translations on input and output. I've been looking at the SLIP and PPP line disciplines as examples, but I haven't quite figured out how to attach this new line discipline without having a network interface to go with it. What I really need to have happen is on boot time, call a function vldattach(). This initializes all of the internal strutures, and sets linesw[x] = my discipline, which should allow applications to change to discipline X.... Pointers? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 11:12:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05327 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:12:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05320 for ; Wed, 10 Feb 1999 11:12:06 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA28591; Wed, 10 Feb 1999 12:11:56 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd028359; Wed Feb 10 12:11:34 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id MAA21201; Wed, 10 Feb 1999 12:11:18 -0700 (MST) From: Terry Lambert Message-Id: <199902101911.MAA21201@usr07.primenet.com> Subject: Re: Change to inherit nodump flag? To: julian@whistle.com (Julian Elischer) Date: Wed, 10 Feb 1999 19:11:18 +0000 (GMT) Cc: dillon@apollo.backplane.com, mark.hannon@stockholm.mail.telia.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Feb 9, 99 03:15:50 pm X-Mailer: ELM [version 2.4 PL25] 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 don't think this is a good idea > > a better idea is to make th eapplication not descend into trees that have > the nodump bit set on the directory. > > you can't "inherrit" all the way up a directory tree when it's moved > into a directory with the nodump flag set. > > (I have the same problem with the SUIDDIR option in around the same > piece of code..) The soloution to this is to grab the inheritance from the upper level directory after traversing up, and to make a distinction between "implied" and "explicit". The problem you have with the SUIDDIR code is no different, if the credentials are obtained by inheritance to root. When you traverse to root, if you hit an entry that has an "inherit me" semantic, then you impose the inheritance, and cease traversing. The failure case for this is hard links, where the parent is ambiguos. This is a solvable problem. To resolve this, you need to have the concept of referring inodes, where a hard link takes an inode of type "hard link". The intent of making this a unique inode number is to differentiate one link directory entry from another. You make a chain of these, so that you can change which one is "real" in the case that the "real" one is unlinked, and the reference count is still non-zero. Then you store the parent pointer in both the "real" and the "virtual" hard links. [ Obviously, links in the same directory would not require a seperate inode, since the parent is shared; but you must deal with moves in and out of directories, which can be tricky and expensive enough that it's probably worth the inode to avoid the problem. ] To fully realize this, you need the concept of alias vnodes. This buys you the ability to ask "what path was used to open this file that is currently open?". In order to answer this question, the file opened via one hard link path must have a different vnode to refer to the different inode, but must be backed by the same backing object (inode). Thus, any inherited attributes will vary by path used to access the object, which is as it should be for inherited attributes. You can achieve the same effect, presuming directory hard links are disallowed (which they should be, since they make x/../x nontransitive) by caching a reference to the directory vnode that got you any given vnode in the vnode structure itself. This still requires aliases for vnodes be generates, and that sibling aliases be referenced, so as to keep a single vm_object_t in common between all referencing vnodes. Siblings in the same directory, unlike the inode approach, can use multiple references to the same vnode without incurring the overhead of having to search the inodes in a directory for siblings (in the inode case, they are hidden, since the inode numbers don't match; you have to reference the inode contents; though there is something to be said for faulting inodes into core as a result of a directory traversal, since a subsequent stat or open is likely). The lossage on this, though is that you won't be able to distinguish sibling names for hard links in the same directory. This is no real loss for almost all conceivable applications. This has the advantage of working on all FS types, but the disadvantage (which may be considered an advantage) of not immediately reflecting change in inherited attributes that result from a hard link being moved. This, since all file instances are, in the limit hard links. This is a disadvantage if the intent is to allow revocation, and an advantage if the intent is to "give away" access irrevocably. This particular "advantage" fits with the idea that you can open a file for read/write, and subsequent revocation of write access is not lost (e.g., SUID/SGID programs take advantage of this type of "give away"). This quickly becomes a "disadvantage" if you try and fit it into the model where even a file opened read/write is unwriteable in the case of a mount update of an FS from read/write to read-only. Nice thing that UNIX has a uniform security policy. ;-). My recommendation would be to employ the "give away" model by default, and allow a brute force revocation, to be paid for by only those applications/installations that require revocation. In any case, the other "disadantage" (which I see as "no big deal") is that references to the parent vnodes must remain in core so long as the children are referenced. This is generally "no big deal" because the refrence is most likely to be a reference to a vnode that is held open anyway as the processes current working directory, and because of N:M locality (for N open files, there will be M "open" parent directories, where it is generally true that N >> M). Thinking about this makes you want to rationalize all vnode references as if they were open instances -- e.g., vnode references by the directory name lookup cache -- doesn't it? Add a reference for an entry into the cache, add a reference for an open, add a reference for a parent pointer, etc. -- they all become the same macro in sys/vnode.h. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 11:15:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05622 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:15:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05613 for ; Wed, 10 Feb 1999 11:15:41 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA00341; Wed, 10 Feb 1999 12:15:39 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd000282; Wed Feb 10 12:15:33 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id MAA21530; Wed, 10 Feb 1999 12:15:25 -0700 (MST) From: Terry Lambert Message-Id: <199902101915.MAA21530@usr07.primenet.com> Subject: Re: softupdates To: kkennawa@physics.adelaide.edu.au (Kris Kennaway) Date: Wed, 10 Feb 1999 19:15:25 +0000 (GMT) Cc: fjoe@iclub.nsu.ru, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Kris Kennaway" at Feb 10, 99 02:43:04 pm X-Mailer: ELM [version 2.4 PL25] 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 > > what is the current status of softupdates? > > is it safe to turn on softupdates (no ccd)? > > It's been working just fine here for at least the last 6 months.. I haven't > heard any softupdates-related panics/crashes on the mailing lists in a while. Absence of evidence is not evidence of absence. It could very well be that those people running soft updates are so trashed that they can't post their horror stories to the list... That was a joke, in case it wasn't obvious. I think there are still two or three "rough edges", if not outright bugs, like unexpected behaviour when marking /, etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 11:23:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06634 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:23:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA06629 for ; Wed, 10 Feb 1999 11:23:54 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA09320; Wed, 10 Feb 1999 11:23:38 -0800 Date: Wed, 10 Feb 1999 11:23:38 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902101915.MAA21530@usr07.primenet.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 I have reported, several times, problems having to do with large FFS filesystems, possibly related to softupdates, posibly not, to Kirk, Luoqi, etc... Nobody showed any interest in looking at the problems - in fact, the email wasn't even answered. As a consequence, FreeBSD lost out for being considered a candidate at NASA/Ames for large mass storage. Shrug...It may or may not be true that softupdates, per se, are stable. In my opinion, FFS as offered by FreeBSD (and NetBSD) have not shown themselves to be adequate to large (>500GB) filesystems. Sad to say, ext2 under linux works better. On Wed, 10 Feb 1999, Terry Lambert wrote: > > > what is the current status of softupdates? > > > is it safe to turn on softupdates (no ccd)? > > > > It's been working just fine here for at least the last 6 months.. I haven't > > heard any softupdates-related panics/crashes on the mailing lists in a while. > > Absence of evidence is not evidence of absence. > > It could very well be that those people running soft updates are > so trashed that they can't post their horror stories to the list... > > That was a joke, in case it wasn't obvious. > > I think there are still two or three "rough edges", if not outright > bugs, like unexpected behaviour when marking /, etc.. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > 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 Feb 10 11:49:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10242 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:49:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10237 for ; Wed, 10 Feb 1999 11:49:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA85603; Wed, 10 Feb 1999 11:49:53 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 11:49:53 -0800 (PST) From: Matthew Dillon Message-Id: <199902101949.LAA85603@apollo.backplane.com> To: Matthew Jacob Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have reported, several times, problems having to do with large :FFS filesystems, possibly related to softupdates, posibly not, to :Kirk, Luoqi, etc... Nobody showed any interest in looking at the :problems - in fact, the email wasn't even answered. : :As a consequence, FreeBSD lost out for being considered a candidate :at NASA/Ames for large mass storage. Shrug...It may or may not be :true that softupdates, per se, are stable. In my opinion, FFS as :offered by FreeBSD (and NetBSD) have not shown themselves to be :adequate to large (>500GB) filesystems. Sad to say, ext2 under :linux works better. Matt, I don't recall seeing anything from you in regards to large filesystems. Looking in the archives, I see one report on Jan 27th from you relating to softupdates, but you indicate that softupdates was not enabled on the volume in question, so it seems unlikely that it is related to softupdates specifically. There have been several reports of dirty-buffer panics which is of concern, but I haven't been able to reproduce the panic myself yet. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 11:53:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10666 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:53:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10661 for ; Wed, 10 Feb 1999 11:53:28 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA09468; Wed, 10 Feb 1999 11:53:18 -0800 Date: Wed, 10 Feb 1999 11:53:18 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902101949.LAA85603@apollo.backplane.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 I'll try and collect my notes and copies of mails I sent and resubmit it to hackers. On Wed, 10 Feb 1999, Matthew Dillon wrote: > :I have reported, several times, problems having to do with large > :FFS filesystems, possibly related to softupdates, posibly not, to > :Kirk, Luoqi, etc... Nobody showed any interest in looking at the > :problems - in fact, the email wasn't even answered. > : > :As a consequence, FreeBSD lost out for being considered a candidate > :at NASA/Ames for large mass storage. Shrug...It may or may not be > :true that softupdates, per se, are stable. In my opinion, FFS as > :offered by FreeBSD (and NetBSD) have not shown themselves to be > :adequate to large (>500GB) filesystems. Sad to say, ext2 under > :linux works better. > > Matt, I don't recall seeing anything from you in regards to > large filesystems. Looking in the archives, I see one report > on Jan 27th from you relating to softupdates, but you indicate > that softupdates was not enabled on the volume in question, > so it seems unlikely that it is related to softupdates specifically. > > There have been several reports of dirty-buffer panics which is > of concern, but I haven't been able to reproduce the panic myself > yet. > > -Matt > Matthew Dillon > > > 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 Feb 10 11:59:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11359 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 11:59:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11353 for ; Wed, 10 Feb 1999 11:59:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA85684; Wed, 10 Feb 1999 11:59:05 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 11:59:05 -0800 (PST) From: Matthew Dillon Message-Id: <199902101959.LAA85684@apollo.backplane.com> To: Terry Lambert Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902101839.LAA18447@usr07.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> true on all implementations that I know of. It is also appropriate - :> the validity of the mmap()'d data only extends to the logical end of :> file. : :Yes, yes, that's not the problem. : :The problem is that INN apparently still fails when using mmap without :msync. The utility of msync is overrated; the code does not actually :do what the manual page claims it does, in any case. 'apparently still fails'. In otherwords, you aren't sure whether it's a bug in INN or a bug in the OS. You don't know why exactly INN is not working, but you are blaming FreeBSD. There could be a bug in FreeBSD, but unless someone can track it down a little better then "Well, this one program doesn't work so it MUST be a bug in FreeBSD", there isn't much we can do about it now is there! From where I sit, I don't see any bugs. :> All semaphores are inadequately resource tracked in _exit(), it's a :> problem inherited from the SYSV implementation. : :Shared memory is badly tracked. But semaphores are supposed to be :capable of being counted out by _exit(), per the SysV man pages :for semop(2) an exit(2): :FreeBSD either doesn't do this, or the FreeBSD manual pages are in error. : : : Terry Lambert : terry@lambert.org FreeBSD supports it just fine. If there is a bug, spell it out and demonstrate it and we'll fix it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 12:10:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12981 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 12:10:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12976 for ; Wed, 10 Feb 1999 12:10:54 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id MAA85891; Wed, 10 Feb 1999 12:10:52 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 12:10:52 -0800 (PST) From: Matthew Dillon Message-Id: <199902102010.MAA85891@apollo.backplane.com> To: Matthew Hunt Cc: phoenix@calldei.com, GReg Sutter , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Proposal: Ignore .nofinger for root References: <19990209200259.A98301@wopr.caltech.edu> <19990210082606.B58482@holly.dyndns.org> <19990210074658.A10003@wopr.caltech.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Wed, Feb 10, 1999 at 08:26:06AM -0600, Chris Costello wrote: : :> Yes. Why? : :Well, I thought the rationale was trivial: To provide accurate :information to the superuser. : :On further reflection, though, that the patch is poor design, :although the argument is more subtle than your argument of "why?" :... I dunno. I never run finger as the superuser. Too dangerous. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 12:14:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13572 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 12:14:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA13565 for ; Wed, 10 Feb 1999 12:14:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id MAA85946; Wed, 10 Feb 1999 12:14:45 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 12:14:45 -0800 (PST) From: Matthew Dillon Message-Id: <199902102014.MAA85946@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon writes: :> The problem is that linux updates the timeval structure on return, :> telling you how much time is left. : :Yup. I wish FreeBSD did that - the man page already states that one :shouldn't rely on tv not being modified, so it shouldn't break POLA. : :DES :-- :Dag-Erling Smorgrav - des@flood.ping.uio.no Ick. It was a disaster.... and the feature is overrated anyway. I was actually heavily involved with linux back in those days and I used this select() feature myself, but the disadvantages outweighed the advantages by an order of magnitude. It really isn't all that expensive to do a separate gettimeofday() system call. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 13:30:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21777 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 13:30:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA21771 for ; Wed, 10 Feb 1999 13:30:50 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 27619 invoked from network); 10 Feb 1999 21:30:41 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 10 Feb 1999 21:30:41 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA02531; Wed, 10 Feb 1999 16:30:39 -0500 (EST) Message-Id: <199902102130.QAA02531@y.dyson.net> Subject: Re: PIPE_BUF In-Reply-To: from Tony Finch at "Feb 10, 99 06:14:08 pm" To: dot@dotat.at (Tony Finch) Date: Wed, 10 Feb 1999 16:30:39 -0500 (EST) Cc: hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Tony Finch said: > I've been looking at the Apache code for doing buffered writes to > logs, which it attempts to do in such a way that log records are not > split across buffer boundaries. It therefore buffers up to PIPE_BUF > bytes to be written in one go. > > Unfortunately, on FreeBSD this doesn't win us much because our log > format averages over 200 bytes and PIPE_BUF is only 512 bytes, so > we'll only be writing at most a couple of records at a time. Other > systems have PIPE_BUF sizes like 4K (Linux), 5K (Solaris), and 10K > (IRIX). > > What do I need to worry about if I rebuild the system with a bigger > PIPE_BUF? > > (Actually, I don't really care about the buffer boundary thing so if > changing PIPE_BUF is painful I'll just compile Apache to use a bigger > buffer regardless of PIPE_BUF.) > You can probably get by with compiling with PIPE_BUF being a small multiple of PAGE_SIZE. A good system wide compromise might be to set PIPE_BUF to such a small multiple, and modifying stdio to flush pipes with a smaller buffer size that that. That will help the interactive pipe issue, and improve those processes that go out of their way to maximize performance or produce contiguous messages. Make sure that your PIPE_BUF size doesn't conflict with other manifest constants in the pipe header file. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 13:34:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22027 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 13:34:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA22022 for ; Wed, 10 Feb 1999 13:34:17 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 2044 invoked from network); 10 Feb 1999 21:34:14 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 10 Feb 1999 21:34:14 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA02537; Wed, 10 Feb 1999 16:34:07 -0500 (EST) Message-Id: <199902102134.QAA02537@y.dyson.net> Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902101742.JAA17281@implode.root.com> from David Greenman at "Feb 10, 99 09:42:16 am" To: dg@root.com Date: Wed, 10 Feb 1999 16:34:07 -0500 (EST) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 David Greenman said: > >> >:The overall size of the shared memory segment is limited to that > >> >: which can fit in the kernels virtual address space; this > >> >: artificially restricts the maximum size. > >> > >> That isn't true and hasn't been true for several years in FreeBSD. > > > >Are you sure? > > Yes, I'm quite sure. > DG's statement is accurate. I removed that very artificial restriction over 2 yrs ago. There is no reason to use KVA space for data that the kernel never needs to see. Correcting that deficit was pretty much on my list as soon as I saw that problem when FreeBSD made it an official part of the distribution. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 13:36:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22206 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 13:36:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA22200 for ; Wed, 10 Feb 1999 13:36:19 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 4226 invoked from network); 10 Feb 1999 21:36:15 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 10 Feb 1999 21:36:15 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA02545; Wed, 10 Feb 1999 16:36:15 -0500 (EST) Message-Id: <199902102136.QAA02545@y.dyson.net> Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902101724.KAA13526@usr07.primenet.com> from Terry Lambert at "Feb 10, 99 05:24:00 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 10 Feb 1999 16:36:15 -0500 (EST) Cc: dg@root.com, dillon@apollo.backplane.com, tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Terry Lambert said: > > I guess if we are still examining Linux vs. FreeBSD programming, then > I should probably point out that SysV SHM is faster than non-anonymous > mmap'ed memory, because writes don't have to be written through to the > backing object. > The condition for paging out pages to SysV SHM are very similar to anonymous MMAPed regions. There is no effective difference. If you use file backed MMAPed regions, there are some time consuming sync operations though. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 14:15:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26761 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 14:15:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26737 for ; Wed, 10 Feb 1999 14:15:02 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id RAA11857; Wed, 10 Feb 1999 17:32:05 -0500 (EST) Date: Wed, 10 Feb 1999 17:32:04 -0500 (EST) From: perlsta To: Dag-Erling Smorgrav cc: "Daniel C. Sobral" , Matthew Dillon , Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: 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 10 Feb 1999, Dag-Erling Smorgrav wrote: > "Daniel C. Sobral" writes: > > Dag-Erling Smorgrav wrote: > > > Matthew Dillon writes: > > > > The problem is that linux updates the timeval structure on return, > > > > telling you how much time is left. > > > Yup. I wish FreeBSD did that - the man page already states that one > > > shouldn't rely on tv not being modified, so it shouldn't break POLA. > > Manual pages aren't POLA. They are specs. Traditional usage is POLA. > > Wanna different different behavior? Create a different function. > > Yep, man pages are specs, and when the spec says tv may be modified by > select(), that means you can't expect it to remain untouched. > > > Besides, given that most usages have no need for this, it would be a > > wast of space and time. > > On the contrary, it is extremely useful for implementing higher-level > timeouts. If you want to see the new installer come true, I need to > implement protocol-level timeouts in libfetch, and that means either > add a lot of gettimeofday() logic or fix select() to modify tv. I wish select() did mess with the tv struct, it would have made a lot of code i did recently easier, and faster with less syscalls. However if you impelemnt the change now, i fear that my code will break. (actually i'm quite sure i reinit the tv just to be safe) My suggestion? select2() which offers the same functionality, however DOES mess with tv. Leave select() alone. :) thanks, -Alfred > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 14:18:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27086 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 14:18:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27076 for ; Wed, 10 Feb 1999 14:18:42 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id RAA20006; Wed, 10 Feb 1999 17:36:31 -0500 (EST) Date: Wed, 10 Feb 1999 17:36:30 -0500 (EST) From: perlsta To: Matthew Dillon cc: Matthew Jacob , Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902101949.LAA85603@apollo.backplane.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, 10 Feb 1999, Matthew Dillon wrote: > :I have reported, several times, problems having to do with large > :FFS filesystems, possibly related to softupdates, posibly not, to > :Kirk, Luoqi, etc... Nobody showed any interest in looking at the > :problems - in fact, the email wasn't even answered. > : > :As a consequence, FreeBSD lost out for being considered a candidate > :at NASA/Ames for large mass storage. Shrug...It may or may not be > :true that softupdates, per se, are stable. In my opinion, FFS as > :offered by FreeBSD (and NetBSD) have not shown themselves to be > :adequate to large (>500GB) filesystems. Sad to say, ext2 under > :linux works better. > > Matt, I don't recall seeing anything from you in regards to > large filesystems. Looking in the archives, I see one report > on Jan 27th from you relating to softupdates, but you indicate > that softupdates was not enabled on the volume in question, > so it seems unlikely that it is related to softupdates specifically. > > There have been several reports of dirty-buffer panics which is > of concern, but I haven't been able to reproduce the panic myself > yet. 4.0 has given me some panics on shutdown because it can't sync all buffers, this is usually a result of me using my atapi cdrom both at work and at home. Sometimes as a result of my scsi CD-RW. Sometimes it just shutdown's clean, other times it repeates the last buffer count for a an agonizing 10-20 seconds then shutdowns properly, sometimes it doesn't and just panics after about 30 seconds. I'll break to ddb next time it happensm, right now i have no freebsd access. :/ -Alfred > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 14:20:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27290 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 14:20:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27275 for ; Wed, 10 Feb 1999 14:20:30 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id RAA16242; Wed, 10 Feb 1999 17:38:21 -0500 (EST) Date: Wed, 10 Feb 1999 17:38:19 -0500 (EST) From: perlsta To: Matthew Dillon cc: Terry Lambert , kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902101959.LAA85684@apollo.backplane.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, 10 Feb 1999, Matthew Dillon wrote: > :> true on all implementations that I know of. It is also appropriate - > :> the validity of the mmap()'d data only extends to the logical end of > :> file. > : > :Yes, yes, that's not the problem. > : > :The problem is that INN apparently still fails when using mmap without > :msync. The utility of msync is overrated; the code does not actually > :do what the manual page claims it does, in any case. > > 'apparently still fails'. In otherwords, you aren't sure whether > it's a bug in INN or a bug in the OS. You don't know why exactly > INN is not working, but you are blaming FreeBSD. > > There could be a bug in FreeBSD, but unless someone can track it down > a little better then "Well, this one program doesn't work so it MUST > be a bug in FreeBSD", there isn't much we can do about it now is there! > From where I sit, I don't see any bugs. Unless something was fixed recently i distinctly remember seeing email about this on the lists, check the archives. I really don't remeber seeing a resolution besaideds telling the person to compile INN not to use mmap(). -Alfred > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 14:42:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA00299 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 14:42:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA00294 for ; Wed, 10 Feb 1999 14:42:21 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA19852; Wed, 10 Feb 1999 14:21:29 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdr19844; Wed Feb 10 22:21:26 1999 Date: Wed, 10 Feb 1999 14:21:21 -0800 (PST) From: Julian Elischer To: Brian McGovern cc: hackers@FreeBSD.ORG Subject: Re: How to attach line disciplines (aka Stupid Question #2962) In-Reply-To: <199902101857.NAA00779@bmcgover-pc.cisco.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 use the MODULE_DECALRE macro. (Didn't we answer thsi for you a few days ago?) also see the ng_tty module for netgraph (ftp://ftp.whistle.com/pub/archie/netgraph/index.html) On Wed, 10 Feb 1999, Brian McGovern wrote: > I'm in the process of writing a relatively simple line discipline for doing > some data translations on input and output. I've been looking at the SLIP and > PPP line disciplines as examples, but I haven't quite figured out how to > attach this new line discipline without having a network interface to go > with it. > > What I really need to have happen is on boot time, call a function > vldattach(). This initializes all of the internal strutures, and sets > linesw[x] = my discipline, which should allow applications to change to > discipline X.... Pointers? > -Brian > > 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 Feb 10 15:47:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA09978 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 15:47:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles202.castles.com [208.214.165.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09965 for ; Wed, 10 Feb 1999 15:47:09 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA01160; Wed, 10 Feb 1999 15:42:55 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902102342.PAA01160@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Tony Finch cc: hackers@FreeBSD.ORG Subject: Re: PIPE_BUF In-reply-to: Your message of "Wed, 10 Feb 1999 18:14:08 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 15:42:54 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've been looking at the Apache code for doing buffered writes to > logs, which it attempts to do in such a way that log records are not > split across buffer boundaries. It therefore buffers up to PIPE_BUF > bytes to be written in one go. > > Unfortunately, on FreeBSD this doesn't win us much because our log > format averages over 200 bytes and PIPE_BUF is only 512 bytes, so > we'll only be writing at most a couple of records at a time. Other > systems have PIPE_BUF sizes like 4K (Linux), 5K (Solaris), and 10K > (IRIX). > > What do I need to worry about if I rebuild the system with a bigger > PIPE_BUF? > > (Actually, I don't really care about the buffer boundary thing so if > changing PIPE_BUF is painful I'll just compile Apache to use a bigger > buffer regardless of PIPE_BUF.) If it's actually writing into a pipe, it should write as much as possible at once under FreeBSD to get best performance. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 15:55:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11324 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 15:55:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles202.castles.com [208.214.165.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11314 for ; Wed, 10 Feb 1999 15:55:26 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA01211; Wed, 10 Feb 1999 15:50:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902102350.PAA01211@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dyson@iquest.net cc: dg@root.com, tlambert@primenet.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Wed, 10 Feb 1999 16:34:07 EST." <199902102134.QAA02537@y.dyson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 15:50:51 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > David Greenman said: > > >> >:The overall size of the shared memory segment is limited to that > > >> >: which can fit in the kernels virtual address space; this > > >> >: artificially restricts the maximum size. > > >> > > >> That isn't true and hasn't been true for several years in FreeBSD. > > > > > >Are you sure? > > > > Yes, I'm quite sure. > > > DG's statement is accurate. I removed that very artificial restriction over > 2 yrs ago. There is no reason to use KVA space for data that the kernel never > needs to see. Correcting that deficit was pretty much on my list as soon as > I saw that problem when FreeBSD made it an official part of the distribution. Hmm, so does that mean that the shared memory pages can be paged out? And if so, should we be removing the SHMMAXPGS kernel option (since our current shared memory profile is woefully inadequate for most uses)? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:39:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA19121 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:39:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA19113 for ; Wed, 10 Feb 1999 16:39:04 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: from localhost (mrcpu@localhost) by schizo.cdsnet.net (8.8.8/8.7.3) with SMTP id QAA16699 for ; Wed, 10 Feb 1999 16:33:49 -0800 (PST) Date: Wed, 10 Feb 1999 16:33:49 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@FreeBSD.ORG Subject: Passive backplane PC's? 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 I see these ads every now and again for these boxes with passive PCI backplanes, and 14 slots, and such. Would one of these hold 14 4 port Znyx cards? Is it some kind of special chipset? Do we support it? I'm just not real familiar with this kind of system as opposed to the more common PC hardware. Thanks in advance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:45:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20042 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:45:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles202.castles.com [208.214.165.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20031 for ; Wed, 10 Feb 1999 16:45:46 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA01517; Wed, 10 Feb 1999 16:41:21 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902110041.QAA01517@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jaye Mathisen cc: hackers@FreeBSD.ORG Subject: Re: Passive backplane PC's? In-reply-to: Your message of "Wed, 10 Feb 1999 16:33:49 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 16:41:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I see these ads every now and again for these boxes with passive PCI > backplanes, and 14 slots, and such. > > Would one of these hold 14 4 port Znyx cards? Is it some kind of special > chipset? Do we support it? I'm just not real familiar with this kind of > system as opposed to the more common PC hardware. Most of these boards with large slot counts are ISA backplanes. There are a few around with multiple PCI busses (in most cases you get 7 slots, with 4 behind a bridge). Typically, you will also be paying for a (quite expensive) PICMG CPU card to go with the backplane; probably not so much of an issue if you're looking at such a stoked system. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:48:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20503 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:48:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailer1.yourdomain.com ([212.250.196.101]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA20456; Wed, 10 Feb 1999 16:48:28 -0800 (PST) (envelope-from MobileCostCutter@Hotmail.com) From: MobileCostCutter@Hotmail.com Message-Id: <199902110048.QAA20456@hub.freebsd.org> To: Subject: Notice to all Mobile Phone Users! Date: Thu, 11 Feb 1999 05:04:57 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, You have been referred to us as someone that would benefit from the following information. If you are a mobile phone user then you may be interested to learn about the following. ___________________________________________________________ "Don't pay more for your mobile phone than you have to" ___________________________________________________________ We are an independent mobile phone consultancy based in Hertfordshire that has been formed as a result of the increased competition between the UK's four mobile phone networks. Our team have an extensive and personal understanding of how mobile phone networks compete for your business. Our dedicated team of consultants are available to offer you the cheapest possible package from your existing mobile phone operator. A number of our colleagues are former employees of one of the UK's leading mobile phone networks. Their knowledge and expertise will prove to be a valuabe commodity. 1. We will show you how it is possible to reduce your existing monthly line rental charge by between 10% to 50%. 2. We will show you how you can upgrade your phone at a discounted price or in some cases, FREE. 3. We will show you how to go about obtaining a credit on your account. 4. We will show you how it is possible to transfer from one network to another taking your existing mobile phone number with you and receiving upto £100.00 for your trouble. 5. We will show you how you can take advantage of free local and national calls day and night. 6. We will show you how to achieve cheaper international calls. 7. We will show you how to receive a discounted memorable mobile number. 8. We will show you how you can have two numbers running side by side and pay just one line rental charge. ______________________________ This and a whole lot more! ______________________________ If you require more information regarding the above and what we can offer you then please send an e.mail stating your name, contact number, e.mail address, the network you are with and length of time you have been with them to MobileCostCutter@Hotmail.com. Alternatively, you can contact us on 01438 234961 or send a fax to 0171 681-3495. Please forward this e.mail to other mobile phone users you know. We look forward to hearing from you! Kindest Regards and Best Wishes. Christopher Scott Managing Director To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:52:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20859 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:52:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20854 for ; Wed, 10 Feb 1999 16:52:03 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA10482; Wed, 10 Feb 1999 16:51:14 -0800 Date: Wed, 10 Feb 1999 16:51:13 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Mike Smith cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Passive backplane PC's? In-Reply-To: <199902110041.QAA01517@dingo.cdrom.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 > > > > I see these ads every now and again for these boxes with passive PCI > > backplanes, and 14 slots, and such. > > > > Would one of these hold 14 4 port Znyx cards? Is it some kind of special > > chipset? Do we support it? I'm just not real familiar with this kind of > > system as opposed to the more common PC hardware. > > Most of these boards with large slot counts are ISA backplanes. There > are a few around with multiple PCI busses (in most cases you get 7 > slots, with 4 behind a bridge). > > Typically, you will also be paying for a (quite expensive) PICMG CPU > card to go with the backplane; probably not so much of an issue if > you're looking at such a stoked system. > Expensive? Siliconrax has them for ~200$- not bad when you consider it includes all standard I/O stuff. My main box is a 5 PIC-MIG system each with one ISA and one PCI per PIC-MIG CPU. It's rather a nice arrangement for one box, although I could wish for separate power for each segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:54:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21143 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:54:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles202.castles.com [208.214.165.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21136 for ; Wed, 10 Feb 1999 16:54:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA01587; Wed, 10 Feb 1999 16:50:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902110050.QAA01587@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Passive backplane PC's? In-reply-to: Your message of "Wed, 10 Feb 1999 16:51:13 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 16:50:08 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > Typically, you will also be paying for a (quite expensive) PICMG CPU > > card to go with the backplane; probably not so much of an issue if > > you're looking at such a stoked system. > > Expensive? Siliconrax has them for ~200$- not bad when you consider > it includes all standard I/O stuff. Hmm, that's much more like it. I was used to looking at > AUD$1k for a simple socket-7 card. > My main box is a 5 PIC-MIG system each with one ISA and one PCI per > PIC-MIG CPU. It's rather a nice arrangement for one box, although > I could wish for separate power for each segment. For this we have the Exacto knife, right boss? 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:56:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21372 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:56:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21364 for ; Wed, 10 Feb 1999 16:56:08 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA05319; Wed, 10 Feb 1999 17:55:54 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd005258; Wed Feb 10 17:55:44 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA26497; Wed, 10 Feb 1999 17:55:37 -0700 (MST) From: Terry Lambert Message-Id: <199902110055.RAA26497@usr08.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 00:55:37 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902101959.LAA85684@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 11:59:05 am X-Mailer: ELM [version 2.4 PL25] 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 > :Yes, yes, that's not the problem. > : > :The problem is that INN apparently still fails when using mmap without > :msync. The utility of msync is overrated; the code does not actually > :do what the manual page claims it does, in any case. > > 'apparently still fails'. In otherwords, you aren't sure whether > it's a bug in INN or a bug in the OS. You don't know why exactly > INN is not working, but you are blaming FreeBSD. > > There could be a bug in FreeBSD, but unless someone can track it down > a little better then "Well, this one program doesn't work so it MUST > be a bug in FreeBSD", there isn't much we can do about it now is there! > From where I sit, I don't see any bugs. I am repeating a posting by an INN user to the -current list. I used the word "apparently" to indicate that the information was second-hand and that the original source should be queried instead of mo, *not* to indicate a lack of faith that there *is* a FreeBSD bug. > :> All semaphores are inadequately resource tracked in _exit(), it's a > :> problem inherited from the SYSV implementation. > : > :Shared memory is badly tracked. But semaphores are supposed to be > :capable of being counted out by _exit(), per the SysV man pages > :for semop(2) an exit(2): > > :FreeBSD either doesn't do this, or the FreeBSD manual pages are in error. > > FreeBSD supports it just fine. If there is a bug, spell it out and > demonstrate it and we'll fix it. FreeBSD must maintain and correctly apply at process exit the value of sem_adj. See the referenced Solaris man pages for semantic details. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:56:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21420 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:56:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21408 for ; Wed, 10 Feb 1999 16:56:30 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA10504; Wed, 10 Feb 1999 16:56:00 -0800 Date: Wed, 10 Feb 1999 16:56:00 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Mike Smith cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Passive backplane PC's? In-Reply-To: <199902110050.QAA01587@dingo.cdrom.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 > > > My main box is a 5 PIC-MIG system each with one ISA and one PCI per > > PIC-MIG CPU. It's rather a nice arrangement for one box, although > > I could wish for separate power for each segment. > > For this we have the Exacto knife, right boss? 8) > :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 16:59:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21692 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 16:59:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21682 for ; Wed, 10 Feb 1999 16:59:34 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA06755; Wed, 10 Feb 1999 17:59:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd006728; Wed Feb 10 17:59:23 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA26636; Wed, 10 Feb 1999 17:59:21 -0700 (MST) From: Terry Lambert Message-Id: <199902110059.RAA26636@usr08.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dyson@iquest.net Date: Thu, 11 Feb 1999 00:59:21 +0000 (GMT) Cc: tlambert@primenet.com, dg@root.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902102136.QAA02545@y.dyson.net> from "John S. Dyson" at Feb 10, 99 04:36:15 pm X-Mailer: ELM [version 2.4 PL25] 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 guess if we are still examining Linux vs. FreeBSD programming, then > > I should probably point out that SysV SHM is faster than non-anonymous > > mmap'ed memory, because writes don't have to be written through to the > > backing object. > > The condition for paging out pages to SysV SHM are very similar to anonymous > MMAPed regions. There is no effective difference. If you use file backed > MMAPed regions, there are some time consuming sync operations though. The difference is that anonymous MMAPed regions can only be mapped into multiple processes via forke based inheritance. This makes them useless for sotheming that, for example, attaches to a shared context segment shared by several processes acting as work-to-do engines, so as to be able to examine and manipulate the shared idea of the current context contents. This limitation is the specific reason that NetWare for UNIX uses shared memory segments instead of mmap'ed regions for client context records. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 17:01:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21897 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 17:01:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21888 for ; Wed, 10 Feb 1999 17:01:25 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA01105; Wed, 10 Feb 1999 18:01:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd001008; Wed Feb 10 18:01:11 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id SAA26933; Wed, 10 Feb 1999 18:00:59 -0700 (MST) From: Terry Lambert Message-Id: <199902110100.SAA26933@usr08.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: mike@smith.net.au (Mike Smith) Date: Thu, 11 Feb 1999 01:00:59 +0000 (GMT) Cc: dyson@iquest.net, dg@root.com, tlambert@primenet.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902102350.PAA01211@dingo.cdrom.com> from "Mike Smith" at Feb 10, 99 03:50:51 pm X-Mailer: ELM [version 2.4 PL25] 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 > > DG's statement is accurate. I removed that very artificial > > restriction over 2 yrs ago. There is no reason to use KVA space > > for data that the kernel never needs to see. Correcting that > > deficit was pretty much on my list as soon as I saw that problem > > when FreeBSD made it an official part of the distribution. > > Hmm, so does that mean that the shared memory pages can be paged out? > And if so, should we be removing the SHMMAXPGS kernel option (since our > current shared memory profile is woefully inadequate for most uses)? Man, is this a cool discussion, or what? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 17:15:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23528 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 17:15:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23517 for ; Wed, 10 Feb 1999 17:15:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id RAA87339; Wed, 10 Feb 1999 17:14:58 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 17:14:58 -0800 (PST) From: Matthew Dillon Message-Id: <199902110114.RAA87339@apollo.backplane.com> To: Terry Lambert Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902110055.RAA26497@usr08.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> :FreeBSD either doesn't do this, or the FreeBSD manual pages are in error. :> :> FreeBSD supports it just fine. If there is a bug, spell it out and :> demonstrate it and we'll fix it. : :FreeBSD must maintain and correctly apply at process exit the value of :sem_adj. See the referenced Solaris man pages for semantic details. In other words, you have no idea whether there's a bug or not. This is more second hand ( or worse ) information. Look, I don't have a problem with second hand information - but I do have a problem with it being put out as solid fact when it isn't. It's one thing to say that there might be a bug, quite another to start crying wolf over unproven and unresearched reports. It doesn't do anyone any good to condemn a system for having a 'bug' when you can't even describe what the bug is! -Matt : Terry Lambert : terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 17:19:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24093 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 17:19:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24088 for ; Wed, 10 Feb 1999 17:19:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id RAA87393; Wed, 10 Feb 1999 17:19:34 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 17:19:34 -0800 (PST) From: Matthew Dillon Message-Id: <199902110119.RAA87393@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, tlambert@primenet.com, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902110059.RAA26636@usr08.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > backing object. :> :> The condition for paging out pages to SysV SHM are very similar to anonymous :> MMAPed regions. There is no effective difference. If you use file backed :> MMAPed regions, there are some time consuming sync operations though. : :The difference is that anonymous MMAPed regions can only be mapped :into multiple processes via forke based inheritance. : :This makes them useless for sotheming that, for example, attaches to :a shared context segment shared by several processes acting as :work-to-do engines, so as to be able to examine and manipulate the :shared idea of the current context contents. : :This limitation is the specific reason that NetWare for UNIX uses shared :memory segments instead of mmap'ed regions for client context records. : : : Terry Lambert : terry@lambert.org ... and has absolutely nothing to do with the question that John was replying to, which was related to the fault overhead/expense of using mmap() verses a SYS-V shared memory segment. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 17:38:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26144 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 17:38:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26135 for ; Wed, 10 Feb 1999 17:38:28 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40371>; Thu, 11 Feb 1999 12:27:48 +1100 Date: Thu, 11 Feb 1999 12:38:12 +1100 From: Peter Jeremy Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com, tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb11.122748est.40371@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >FreeBSD semaphores are inadequately resource tracked in _exit(). Matthew Dillon wrote: > All semaphores are inadequately resource tracked in _exit(), it's a > problem inherited from the SYSV implementation. Could someone please describe what the problem(s) are and what impact they have on applications using SysV semaphores. I have an application (running on 3.0-RELEASE) that relies on the kernel correctly tracking SEM_UNDO's. (Basically I have a wrapper that seizes a semaphore with sem_op = -1, sem_flg = SEM_UNDO and then execs a process that knows nothing about the semaphores.) I was seeing some wierd behaviour, but I thought that was a (now fixed) bug in the kernel handling of SEMUME and SEMUSZ (see PR kern/9068). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:16:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA00986 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:16:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00972 for ; Wed, 10 Feb 1999 18:16:40 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA02594; Wed, 10 Feb 1999 19:16:30 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd002458; Wed Feb 10 19:16:24 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA08700; Wed, 10 Feb 1999 19:16:13 -0700 (MST) From: Terry Lambert Message-Id: <199902110216.TAA08700@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 02:16:12 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902110114.RAA87339@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 05:14:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-MIME-Autoconverted: from 8bit to quoted-printable by usr06.primenet.com id TAA08700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA00981 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :FreeBSD must maintain and correctly apply at process exit the value of > :sem_adj. See the referenced Solaris man pages for semantic details. > > In other words, you have no idea whether there's a bug or not. This > is more second hand ( or worse ) information. No. It is a bug. SVR4, per SVID III, tracks sem_adj. Those were just the man pages I had handy that you could read. > Look, I don't have a problem with second hand information - but > I do have a problem with it being put out as solid fact when it > isn't. It's one thing to say that there might be a bug, quite > another to start crying wolf over unproven and unresearched > reports. It doesn't do anyone any good to condemn a system > for having a 'bug' when you can't even describe what the bug is! You must be referring th the INN stuff here, since the sem_adj failure when a process core dumps *is* a bug, right? See kern/sysv_sem.c, ~line 689: if (sopptr->sem_op < 0) { if (semptr->semval + sopptr->sem_op < 0) { #ifdef SEM_DEBUG printf("semop: can't do it now\n"); #endif break; } else { And from the man page: sem_op is a negative integer; {ALTER} . If semval is less than the absolute value of sem_op and (sem_flg&IPC_NOWAIT) is false, semop() increments the semncnt associated with the specified semaphore and suspends execution of the calling process until one of the following conditions occur: . semval becomes greater than or equal to the absolute value of sem_op. When this occurs, the value of semncnt associated with the specified semaphore is decremented, the absolute value of sem_op is sub­ tracted from semval and, if (sem_flg&SEM_UNDO) is true, the absolute value of sem_op is added to the calling process's semadj value for the specified semaphore. . The semid for which the calling process is awaiting action is removed from the system (see semctl(2)). When this occurs, errno is set equal to EIDRM, and a value of -1 is returned. . The calling process receives a signal that is to be caught. When this occurs, the value of semncnt associated with the specified semaphore is decre­ mented, and the calling process resumes execution in the manner prescribed in signal(3C). i.e.: "semop: can't do it now" doesn't cut it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:21:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01677 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:21:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01646 for ; Wed, 10 Feb 1999 18:21:00 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA10064; Wed, 10 Feb 1999 19:24:13 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd009740; Wed Feb 10 19:23:59 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA08932; Wed, 10 Feb 1999 19:20:17 -0700 (MST) From: Terry Lambert Message-Id: <199902110220.TAA08932@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 02:20:14 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902110119.RAA87393@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 05:19:34 pm X-Mailer: ELM [version 2.4 PL25] 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 > :> The condition for paging out pages to SysV SHM are very similar to anonymous > :> MMAPed regions. There is no effective difference. If you use file backed > :> MMAPed regions, there are some time consuming sync operations though. > : > :The difference is that anonymous MMAPed regions can only be mapped > :into multiple processes via forke based inheritance. > : > :This makes them useless for sotheming that, for example, attaches to > :a shared context segment shared by several processes acting as > :work-to-do engines, so as to be able to examine and manipulate the > :shared idea of the current context contents. > : > :This limitation is the specific reason that NetWare for UNIX uses shared > :memory segments instead of mmap'ed regions for client context records. > > ... and has absolutely nothing to do with the question that John was > replying to, which was related to the fault overhead/expense of using > mmap() verses a SYS-V shared memory segment. But has everything to do with his statement to the effect that "There is no effective difference", contained in the answer. The rest was quoted for context. I am not so stupid that I cannot fathom his answer, as you would see if you read the rest of the messages in this thread, where I said "Mea culpa" ("My Fault") to David's quotation of John's reply in a different context. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:29:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02588 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:29:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02581 for ; Wed, 10 Feb 1999 18:29:55 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA08483; Wed, 10 Feb 1999 19:29:54 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd008384; Wed Feb 10 19:29:51 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA09779; Wed, 10 Feb 1999 19:29:34 -0700 (MST) From: Terry Lambert Message-Id: <199902110229.TAA09779@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy) Date: Thu, 11 Feb 1999 02:29:33 +0000 (GMT) Cc: dillon@apollo.backplane.com, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <99Feb11.122748est.40371@border.alcanet.com.au> from "Peter Jeremy" at Feb 11, 99 12:38:12 pm X-Mailer: ELM [version 2.4 PL25] 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 > >FreeBSD semaphores are inadequately resource tracked in _exit(). > > > All semaphores are inadequately resource tracked in _exit(), it's a > > problem inherited from the SYSV implementation. > > Could someone please describe what the problem(s) are and what impact > they have on applications using SysV semaphores. > > I have an application (running on 3.0-RELEASE) that relies on the > kernel correctly tracking SEM_UNDO's. (Basically I have a wrapper > that seizes a semaphore with sem_op = -1, sem_flg = SEM_UNDO and then > execs a process that knows nothing about the semaphores.) I was > seeing some wierd behaviour, but I thought that was a (now fixed) bug > in the kernel handling of SEMUME and SEMUSZ (see PR kern/9068). If the sem_op is a negative integer, and the absolute value of the sem_op is larger than the current value of the semaphore, and the value of (sem_flg&IPC_NOWAIT) is false, then the operation is ignored. The operation is *supposed* to increment the sem_cnt, and suspend the calling process. Apparently, this isn't done because of the need to tie it into the signal code (see the tsleep at ~ line 758 of kern/sysv_sem.c). Oh yeah; while I'm at having to prove someone else's bug report is a valid bug report, it's supposed to return EIDRM instead of EINVAL; contrary to the comments at ~ line 770, BSD *does* define this value. I'm pretty sure no one has bug reported that, though... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:33:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03224 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:33:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from netsrv-1.prologic.com (netsrv-1.prologic.COM [204.17.52.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03208; Wed, 10 Feb 1999 18:33:35 -0800 (PST) (envelope-from terryg@prologic.com) Received: from TECH-5 (tech-5.prologic.COM [204.17.52.184]) by netsrv-1.prologic.com (8.9.1/8.9.1) with SMTP id TAA11550; Wed, 10 Feb 1999 19:32:18 -0700 (MST) Received: by localhost with Microsoft MAPI; Wed, 10 Feb 1999 19:34:42 -0700 Message-ID: <01BE552C.67D6B980.terryg@prologic.com> From: Terry Gilpin Reply-To: "terryg@prologic.com" To: "'gcc-help@gnu.org'" Cc: "'freebsd-hackers@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: elf ld problems Date: Wed, 10 Feb 1999 19:34:41 -0700 Organization: Prologic X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Sorry to bother you, but I am having a problem. I am trying to experimentally build a Unify application on FreeBSD-3.0 that requires solaris elf libraries. The following error occurs. (uld is a unify script front ent to ld). /usr/libexec/elf/ld: uld.29208: Not enough room for program headers (allocated 5 , need 6) /usr/libexec/elf/ld: final link failed: Bad value I have NO idea why this happens. Has anyone seen this? Jim I am not a member of this list, so please respond directly. bodkins@prologic.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:35:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03492 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:35:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03486 for ; Wed, 10 Feb 1999 18:35:22 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40350>; Thu, 11 Feb 1999 13:24:48 +1100 Date: Thu, 11 Feb 1999 13:35:13 +1100 From: Peter Jeremy Subject: Re: Change to inherit nodump flag? To: hackers@FreeBSD.ORG Message-Id: <99Feb11.132448est.40350@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Personally, I think this is the correct way of doing it - nodump > would be inherited just as directory gid is inherited. This sounds like the cleanest solution. > Another solution would be to hack the 'dump' program to be able to > remember 'nodump' recursively. I don't think that is as good a > solution as adjusting i_flags on create. Julian Elischer wrote: >a better idea is to make th eapplication not descend into trees that have >the nodump bit set on the directory. The problem with this is that dump(8) does not traverse the filesystem in a normal fashion. I suspect the code to implement this is non- trivial. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 18:38:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03957 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 18:38:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles202.castles.com [208.214.165.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03937; Wed, 10 Feb 1999 18:38:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA02151; Wed, 10 Feb 1999 18:34:21 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902110234.SAA02151@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "terryg@prologic.com" cc: "'gcc-help@gnu.org'" , "'freebsd-hackers@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: elf ld problems In-reply-to: Your message of "Wed, 10 Feb 1999 19:34:41 MST." <01BE552C.67D6B980.terryg@prologic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Feb 1999 18:34:20 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > Sorry to bother you, but I am having a problem. I am trying to experimentally build a Unify application on FreeBSD-3.0 that > requires solaris elf libraries. The following error occurs. (uld is a unify script front ent to ld). > > > /usr/libexec/elf/ld: uld.29208: Not enough room for program headers (allocated 5 > , need 6) > /usr/libexec/elf/ld: final link failed: Bad value > > I have NO idea why this happens. Has anyone seen this? Just out of curiosity, what major misconception makes you think that you would be able to use Solaris libraries on FreeBSD? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 19:10:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA07770 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 19:10:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA07718 for ; Wed, 10 Feb 1999 19:10:01 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id LAA60544; Thu, 11 Feb 1999 11:08:47 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199902110308.LAA60544@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon cc: Dag-Erling Smorgrav , Christoph Kukulies , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Wed, 10 Feb 1999 12:14:45 PST." <199902102014.MAA85946@apollo.backplane.com> Date: Thu, 11 Feb 1999 11:08:44 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > : > :Matthew Dillon writes: > :> The problem is that linux updates the timeval structure on return, > :> telling you how much time is left. > : > :Yup. I wish FreeBSD did that - the man page already states that one > :shouldn't rely on tv not being modified, so it shouldn't break POLA. > : > :DES > :-- > :Dag-Erling Smorgrav - des@flood.ping.uio.no > > Ick. It was a disaster.... and the feature is overrated anyway. I > was actually heavily involved with linux back in those days and I used > this select() feature myself, but the disadvantages outweighed the > advantages by an order of magnitude. It really isn't all that expensive > to do a separate gettimeofday() system call. I implemented it on FreeBSD back in 1996 or so but gave up in the end. The biggest offender was the libc RPC code, but there were a constant supply of things that mysteriously failed. It was a real nightmare trying to track down and locate them. There were things using timeouts of a day or a week or so, and would gradually reduce the timeout as select chipped it away and after a week or so things would mysteriously start running at a 100% CPU tight loop around select(). I don't think I have the code anymore, I lost it during an accident while working on poll() and never bothered to restore it from backup. > -Matt > Matthew Dillon > 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 Feb 10 20:02:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13716 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 20:02:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail0.atl.bellsouth.net (sgi-b.bellsouth.net [205.152.0.27] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13708 for ; Wed, 10 Feb 1999 20:02:29 -0800 (PST) (envelope-from wghicks@bellsouth.net) Received: from wghicks.bellsouth.net (host-209-214-66-103.atl.bellsouth.net [209.214.66.103]) by mail0.atl.bellsouth.net (8.8.8-spamdog/8.8.5) with ESMTP id XAA15052; Wed, 10 Feb 1999 23:02:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by wghicks.bellsouth.net (8.9.2/8.9.2) with ESMTP id XAA03084; Wed, 10 Feb 1999 23:19:42 -0500 (EST) (envelope-from wghicks@wghicks.bellsouth.net) To: mike@smith.net.au Cc: mrcpu@internetcds.com, hackers@FreeBSD.ORG Subject: Re: Passive backplane PC's? In-Reply-To: Your message of "Wed, 10 Feb 1999 16:41:20 -0800" <199902110041.QAA01517@dingo.cdrom.com> References: <199902110041.QAA01517@dingo.cdrom.com> X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990210231941U.wghicks@wghicks.bellsouth.net> Date: Wed, 10 Feb 1999 23:19:41 -0500 From: W Gerald Hicks X-Dispatcher: imput version 980905(IM100) Lines: 40 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don't forget CompactPCI, a favorite among us telephony types. Ziatech is a vendor with whom I've enjoyed very good relations. They offer very expert support and high quality products too. Cheers, Jerry Hicks wghicks@bellsouth.net From: Mike Smith > > > > > > I see these ads every now and again for these boxes with passive PCI > > backplanes, and 14 slots, and such. > > > > Would one of these hold 14 4 port Znyx cards? Is it some kind of special > > chipset? Do we support it? I'm just not real familiar with this kind of > > system as opposed to the more common PC hardware. > > Most of these boards with large slot counts are ISA backplanes. There > are a few around with multiple PCI busses (in most cases you get 7 > slots, with 4 behind a bridge). > > Typically, you will also be paying for a (quite expensive) PICMG CPU > card to go with the backplane; probably not so much of an issue if > you're looking at such a stoked system. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > 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 Feb 10 21:44:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26174 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 21:44:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26169 for ; Wed, 10 Feb 1999 21:44:36 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40373>; Thu, 11 Feb 1999 16:21:22 +1100 Date: Thu, 11 Feb 1999 16:31:46 +1100 From: Peter Jeremy Subject: Re: portability of shm, mmap, pipes and socket IPC To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb11.162122est.40373@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >If the sem_op is a negative integer, and the absolute value of the >sem_op is larger than the current value of the semaphore, and the >value of (sem_flg&IPC_NOWAIT) is false, then the operation is ignored. As far as I can tell, this is handled correctly. Looking at v 1.22, this is detected at line 690. Then follows a debug statement "can't do it now" and a break. The break exits the inner for loop (ending at line 717) whick is working thru all the semops passed in. Since we haven't made it through all the semops, we fall through lines 725-746, unwinding any partially commited operations. Then there's a tsleep() on semaptr (which is the semaphore descriptor). If the tsleep returns normally, the whole thing is repeated courtesy of the for loop covering lines 671-786. The tsleep is woken up by a semctl() with IPC_RMID, SETVAL, SETALL, or a semop() or semexit() that up's any semaphores in that descriptor. >Oh yeah; while I'm at having to prove someone else's bug report is >a valid bug report, it's supposed to return EIDRM instead of EINVAL; >contrary to the comments at ~ line 770, BSD *does* define this value. >I'm pretty sure no one has bug reported that, though... EIDRM was added (I believe by sos) sometime after 2.2.6. It's only used by sysv_msg.c and sysv_sem.c - and from what I can see, the code is all protected by #ifdef EIDRM's, so the code should work correctly, whether or not EIDRM is defined. Someone with commit priv's just needs to remove the comment saying it doesn't exist. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 22:25:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29594 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 22:25:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29589 for ; Wed, 10 Feb 1999 22:25:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id WAA88612; Wed, 10 Feb 1999 22:25:29 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 22:25:29 -0800 (PST) From: Matthew Dillon Message-Id: <199902110625.WAA88612@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902110220.TAA08932@usr06.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> ... and has absolutely nothing to do with the question that John was :> replying to, which was related to the fault overhead/expense of using :> mmap() verses a SYS-V shared memory segment. : :But has everything to do with his statement to the effect that :"There is no effective difference", contained in the answer. The :rest was quoted for context. I am not so stupid that I cannot :fathom his answer, as you would see if you read the rest of the :messages in this thread, where I said "Mea culpa" ("My Fault") to :David's quotation of John's reply in a different context. : : : Terry Lambert : terry@lambert.org The issue of file-backed storage verses anon mmap is certainly real, but it's divergent enough from the original discussion that it should have been brought up as a separate item rather then as a response, That's all. This brings up a good point, though... I think it might make sense to be able to specify a MAP_ flag to mmap to indicate that the file's dirty data backing the map ( for non-anonymous maps ) does not have to be synced by the syncer. That would make mmap() a much more useful tool for sharing working sets. The file data would be synced on the last close of the vnode and if the program really doesn't want it to be synced at all, the program could madvise() it free ( and we could fix madvise() to actually support throw-away on a vnode ). Another possibility would be adding a memory reference passing capability to unix-domain socket messaging. We can already pass descriptors and access rights, why not memory too? ( ala mach ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 22:28:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29933 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 22:28:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29928 for ; Wed, 10 Feb 1999 22:27:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id WAA88637; Wed, 10 Feb 1999 22:26:56 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 22:26:56 -0800 (PST) From: Matthew Dillon Message-Id: <199902110626.WAA88637@apollo.backplane.com> To: Peter Jeremy Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <99Feb11.122748est.40371@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :they have on applications using SysV semaphores. : :I have an application (running on 3.0-RELEASE) that relies on the :kernel correctly tracking SEM_UNDO's. (Basically I have a wrapper :that seizes a semaphore with sem_op = -1, sem_flg = SEM_UNDO and then :execs a process that knows nothing about the semaphores.) I was :seeing some wierd behaviour, but I thought that was a (now fixed) bug :in the kernel handling of SEMUME and SEMUSZ (see PR kern/9068). : :Peter I think the key issue here is to be able to reproduce the weird behavior deterministically. If that can be done, the problem can be fixed fairly easily. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 10 23:01:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03282 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 23:01:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03276 for ; Wed, 10 Feb 1999 23:01:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id XAA88892; Wed, 10 Feb 1999 23:01:48 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Feb 1999 23:01:48 -0800 (PST) From: Matthew Dillon Message-Id: <199902110701.XAA88892@apollo.backplane.com> To: Peter Jeremy Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <99Feb11.162122est.40373@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :As far as I can tell, this is handled correctly. : :through lines 725-746, unwinding any partially commited operations. :Then there's a tsleep() on semaptr (which is the semaphore :descriptor). If the tsleep returns normally, the whole thing is :repeated courtesy of the for loop covering lines 671-786. :... Looks like the intention of the code is correct to me too, though not being a semaphore expert there could still be a bug. :EIDRM was added (I believe by sos) sometime after 2.2.6. It's only :used by sysv_msg.c and sysv_sem.c - and from what I can see, the code :is all protected by #ifdef EIDRM's, so the code should work correctly, :whether or not EIDRM is defined. Someone with commit priv's just :needs to remove the comment saying it doesn't exist. : :Peter I added an #error inside the #ifdef EIDRM and the compile bombed, so EIDRM is definitely defined from the point of view of the module. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 00:08:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10793 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 00:08:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA10770 for ; Thu, 11 Feb 1999 00:08:06 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id QAA61681; Thu, 11 Feb 1999 16:07:25 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199902110807.QAA61681@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-reply-to: Your message of "Wed, 10 Feb 1999 16:30:05 GMT." <199902101630.JAA08698@usr07.primenet.com> Date: Thu, 11 Feb 1999 16:07:25 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > However, as you point out, the fcntl() > > (and flock()) *locking* operations are not implemented. IMHO file locking > > on a socket is of pretty marginal value since there is no seek space > > (with the possible exception of using it for a mutex instead of using > > sendmsg() or something sensible). > > Yeah; the putative utility isn't really at issue, though, only whether > it works on Linux and not on FreeBSD. You could make the same argument > about value on SYSV IPC, since it's not select(2)'able. I wasn't talking about select(), I was talking about *file* locking on non-files like sockets and pipes. FWIW, it *looks* rather simple to implement this at a higher level since the kern_lockf.c code is not actually vnode specific at all. All that it (in theory) needs is for sockets and pipes to implement an advlock() op entry, fetch their per-pipe/ socket 'struct lockf *' and call lf_advlock(). lf_advlock() takes a VOP_* style argument but it doesn't need to, it could just as well take explicit args. My point is, if it was *useful* or *in use*, then somebody would have implemented it it. > > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > > since pipes are not backed by true vnode objects. > > > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > > *Only* the file locking parts are not implemented since it's of such little > > value with no seek space. > > Hmmmm. From my reading of the sources, this is actually a fairly > recent addition (November 11th, 1998, by Truckman). I blame my > build environment for that particular lapse. I looked at the code and it isn't a new feature. What Don Lewis did was clean up the interfaces a little so that the functionality was tracked better to prevent SIGIO shootdowns. It's always been done this way (fcntl translated into an ioctl()), but it used to be done with TIOCSPGRP etc and now it's done with FIOSETOWN and friends. The functionality is a little more robust, it's not new. > I still don't think the non-existance of a real vs. a virtual seek > space is relevent. Supporting unused features causes bloat. Unless it's actually going to be useful and maybe even *used* then it's irrelevant. Incidently, I can see one use for it, and that's to do a mutex of some sort. Imagine a cooperative process pair that want to get records over a pipe or socket but the data is written non-atomically in multiple chunks, etc. This is a bad example though because there are better ways. > The obvious way to fix this is to hang the locks off the vnode, and > move the advisory locking out of all FS's (except the network clients, > of course, which may need to veto lock coelescence if the server > refuses the lock). This would fix nothing in these cases since sockets and pipes do not *have* a vnode. You've got me bugged now.. I had a quick shot at seeing just how hard it would actually be to implement locking for pipes and sockets. I was suprised at how easy it's turning out and (to my suprise) it slightly tidies a few things up a bit.. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 00:23:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12174 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 00:23:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA12167 for ; Thu, 11 Feb 1999 00:23:17 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 16716 invoked from network); 11 Feb 1999 08:23:08 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 11 Feb 1999 08:23:08 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id DAA03550; Thu, 11 Feb 1999 03:23:08 -0500 (EST) Message-Id: <199902110823.DAA03550@y.dyson.net> Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902102350.PAA01211@dingo.cdrom.com> from Mike Smith at "Feb 10, 99 03:50:51 pm" To: mike@smith.net.au (Mike Smith) Date: Thu, 11 Feb 1999 03:23:07 -0500 (EST) Cc: dyson@iquest.net, dg@root.com, tlambert@primenet.com, dillon@apollo.backplane.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Mike Smith said: > > David Greenman said: > > > >> >:The overall size of the shared memory segment is limited to that > > > >> >: which can fit in the kernels virtual address space; this > > > >> >: artificially restricts the maximum size. > > > >> > > > >> That isn't true and hasn't been true for several years in FreeBSD. > > > > > > > >Are you sure? > > > > > > Yes, I'm quite sure. > > > > > DG's statement is accurate. I removed that very artificial restriction over > > 2 yrs ago. There is no reason to use KVA space for data that the kernel never > > needs to see. Correcting that deficit was pretty much on my list as soon as > > I saw that problem when FreeBSD made it an official part of the distribution. > > Hmm, so does that mean that the shared memory pages can be paged out? > And if so, should we be removing the SHMMAXPGS kernel option (since our > current shared memory profile is woefully inadequate for most uses)? > Shared memory pages *can* be paged out. There are policy issues that DG and others (maybe including you) need to evaluate before deciding that SHMMAXPGS isn't something that is desirable. I suspect that SHMMAXPGS is pretty much redundant, but... :-). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 00:50:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14381 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 00:50:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA14369 for ; Thu, 11 Feb 1999 00:50:03 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 26301 invoked from network); 11 Feb 1999 08:50:00 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 11 Feb 1999 08:50:00 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id DAA03600; Thu, 11 Feb 1999 03:49:59 -0500 (EST) Message-Id: <199902110849.DAA03600@y.dyson.net> Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902110625.WAA88612@apollo.backplane.com> from Matthew Dillon at "Feb 10, 99 10:25:29 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 03:49:59 -0500 (EST) Cc: tlambert@primenet.com, dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Matthew Dillon said: > > The issue of file-backed storage verses anon mmap is certainly real, > but it's divergent enough from the original discussion that it should > have been brought up as a separate item rather then as a response, > That's all. > > This brings up a good point, though... I think it might make sense > to be able to specify a MAP_ flag to mmap to indicate that the file's > dirty data backing the map ( for non-anonymous maps ) does not have to > be synced by the syncer. That would make mmap() a much more useful > tool for sharing working sets. The file data would be synced on the > last close of the vnode and if the program really doesn't want it to be > synced at all, the program could madvise() it free ( and we could fix > madvise() to actually support throw-away on a vnode ). > > Another possibility would be adding a memory reference passing capability > to unix-domain socket messaging. We can already pass descriptors and > access rights, why not memory too? ( ala mach ). > I agree with much of this. I suggest looking at some commerical implementations and/or standards docs to see a good way to implement the above from an API standpoint. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 01:56:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22193 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 01:56:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wind.freenet.am ([194.151.101.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20812 for ; Thu, 11 Feb 1999 01:45:05 -0800 (PST) (envelope-from casper@acc.am) Received: from lemming.acc.am ([209.58.5.202]) by wind.freenet.am (8.9.1/8.9.1) with ESMTP id NAA22710 for ; Thu, 11 Feb 1999 13:43:18 +0400 (GMT) Received: from acc.am (nightmar.acc.am [192.168.100.108]) by lemming.acc.am (8.9.1a/8.9.1) with ESMTP id NAA20772 for ; Thu, 11 Feb 1999 13:44:50 +0400 (AMT) Message-ID: <36C2A5E9.675D0B71@acc.am> Date: Thu, 11 Feb 1999 13:42:01 +0400 From: Casper Organization: Armenian Computer Center X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Quotas implementation Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello All! Are there another ways to implement quota mechanism except that we use now - quota checks on low-level IO operations (when manipulating with disk inodes)? It's impossible to use (or it will be very nasty hack) existing FFS/UFS code for my purposes , because no real uids will be created and stored on disk ... The only way i see , is to patch every daemon that will originate this IO operations. Any ideas ? Best regards, -------- Casper - friendly ghost -------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 02:20:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24472 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 02:20:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA24454 for ; Thu, 11 Feb 1999 02:20:02 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 19090 invoked from network); 11 Feb 1999 10:19:58 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 11 Feb 1999 10:19:58 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id FAA03822; Thu, 11 Feb 1999 05:19:58 -0500 (EST) Message-Id: <199902111019.FAA03822@y.dyson.net> Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902101959.LAA85684@apollo.backplane.com> from Matthew Dillon at "Feb 10, 99 11:59:05 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 05:19:58 -0500 (EST) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Matthew Dillon said: > :> true on all implementations that I know of. It is also appropriate - > :> the validity of the mmap()'d data only extends to the logical end of > :> file. > : > :Yes, yes, that's not the problem. > : > :The problem is that INN apparently still fails when using mmap without > :msync. The utility of msync is overrated; the code does not actually > :do what the manual page claims it does, in any case. > > 'apparently still fails'. In otherwords, you aren't sure whether > it's a bug in INN or a bug in the OS. You don't know why exactly > INN is not working, but you are blaming FreeBSD. > > There could be a bug in FreeBSD, but unless someone can track it down > a little better then "Well, this one program doesn't work so it MUST > be a bug in FreeBSD", there isn't much we can do about it now is there! > From where I sit, I don't see any bugs. > I would like to respectfully petition a modification of the above attitude, in the sense that if an API works for one (and/or many other) OSes, there is a significant chance of a FreeBSD bug. Whether or not I acted on various known bugs, I still considered them to be so, until proven otherwise. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 05:02:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12634 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 05:02:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from luke.pmr.com (luke.pmr.com [207.170.114.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA12622 for ; Thu, 11 Feb 1999 05:02:02 -0800 (PST) (envelope-from bob@luke.pmr.com) Received: (from bob@localhost) by luke.pmr.com (8.9.2/8.9.2) id HAA05362 for freebsd-hackers@freebsd.org; Thu, 11 Feb 1999 07:01:58 -0600 (CST) (envelope-from bob) Date: Thu, 11 Feb 1999 07:01:58 -0600 From: Bob Willcox To: hackers list Subject: Need help disklabeling zip drives Message-ID: <19990211070158.A5111@luke.pmr.com> Reply-To: Bob Willcox Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, Could some kind soul(s) out there please tell me how they go about disklabeling their zip drives? I changed the partition type on my zip cartridge from DOS (6) to FreeBSD (165) but can't figure out how to get disklabel to put a label on it. This is on a scsi zip drive running 3.0-stable (of 2/9). Here's what fdisk tells me about the disk: ******* Working on device /dev/rda3 ******* parameters extracted from in-core disklabel are: cylinders=96 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=96 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 32, size 196576 (95 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 95/ sector 32/ head 63 And here is the output of various failed attempts at disklabeling: root@luke-p7 /dev> disklabel -r da3s4 disklabel: bad pack magic number (label is damaged, or pack is unlabeled) root@luke-p7 /dev> disklabel -r da3 disklabel: bad pack magic number (label is damaged, or pack is unlabeled) root@luke-p7 /dev> disklabel -wr da3s4 zip100 disklabel: No space left on device root@luke-p7 /dev> disklabel -w da3s4 zip100 disklabel: No space left on device Any help would be greatly appreciated! Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no bob@luke.pmr.com further than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been. -- Alan Ashley-Pitt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 05:14:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA13811 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 05:14:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from yoda.pi.musin.de (yoda.pi.musin.de [194.246.250.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA13804 for ; Thu, 11 Feb 1999 05:14:57 -0800 (PST) (envelope-from sec@yoda.pi.musin.de) Received: (from sec@localhost) by yoda.pi.musin.de (8.9.2/8.9.1) id OAA23990 for freebsd-hackers@freebsd.org; Thu, 11 Feb 1999 14:14:54 +0100 (CET) (envelope-from sec) Date: Thu, 11 Feb 1999 14:14:54 +0100 From: Stefan `Sec` Zehl To: freebsd-hackers@FreeBSD.ORG Subject: data recovery ? Message-ID: <19990211141454.A23872@yoda.pi.musin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i I-love-doing-this: really X-URL: http://sec.42.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, A friend of mine (no, not me :-) just managed to do a fresh 3.0 install on his box without saving his previous data to another box. He had one home.tar lying in /usr before he re-paritioned and reinstalled. Is there _any_ way to recover it now? Unfortunately nobody here has enough knowledge of the filesystem structure for ufs. Are there any pointers on what we can try to recover this .tar now, or are we lot ? CU, Sec -- Komme wieder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 05:39:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA16722 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 05:39:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from email.iomega.com (email.iomega.com [147.178.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA16715 for ; Thu, 11 Feb 1999 05:39:41 -0800 (PST) (envelope-from brandon@iomega.com) Received: from ROYNTVRS01.iomega.com by email.iomega.com via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 11 Feb 1999 13:39:05 UT Received: from 147.178.3.10 by royntvrs02.iomega.com (InterScan E-Mail VirusWall NT); Thu, 11 Feb 1999 06:39:09 -0700 (Mountain Standard Time) Received: by IOMEGA.COM with Novell_GroupWise; Thu, 11 Feb 1999 06:38:28 -0700 Received: from ogg.iomega.com ([147.178.80.151]) by iomega.com (GroupWise SMTP/MIME daemon 4.1 v3) ; Thu, 11 Feb 99 06:38:22 MST Received: (from brandon@localhost) by ogg.iomega.com (8.9.1/8.9.1) id GAA00511; Thu, 11 Feb 1999 06:38:46 -0700 (MST) (envelope-from brandon) Message-ID: <19990211063845.A484@iomega.com> Date: Thu, 11 Feb 1999 06:38:45 -0700 From: Brandon Gillespie To: Bob Willcox , freebsd-hackers@FreeBSD.ORG Subject: Re: Need help disklabeling zip drives References: Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="yrj/dFKFPuw6o+aM" X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Bob Willcox on Thu, Feb 11, 1999 at 06:01:58AM -0700 X-Operating-System: FreeBSD 3.0-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Thu, Feb 11, 1999 at 06:01:58AM -0700, Bob Willcox wrote: >=20 > Hi all, >=20 > Could some kind soul(s) out there please tell me how they go about > disklabeling their zip drives? I changed the partition type on my zip > cartridge from DOS (6) to FreeBSD (165) but can't figure out how to get > disklabel to put a label on it. This is on a scsi zip drive running > 3.0-stable (of 2/9). >=20 > Here's what fdisk tells me about the disk: >=20 [snip] >=20 > Any help would be greatly appreciated! Thanks, I'm assuming you have a disktab entry for a Zip100 (I think it was added a little after 3.0-R), but incase you dont (and for posterity), add the following to /etc/disktab: zip100|zip 100:\ :ty=3Dremovable:se#512:nc#96:nt#64:ns#32:\ :pa#196608:oa#0:ba#4096:fa#512:\ :pb#196608:ob#0:bb#4096:fb#512:\ :pc#196608:oc#0:bc#4096:fc#512: Then what I do whenever I'm having problems is just nuke any label whatsoever on the drive (I've been able to recover a lot of hozed zip drives this way)... just switch the device 'wfd0' with the proper device for your system: dd if=3D/dev/zero of=3D/dev/rwfd0 count=3D1024 Then the disklabel should run Ok: disklabel -r -w wfd0 auto -Brandon --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: Oheh5N+hYX179JThz+dBHKW2s9Mqm3g1 iQA/AwUBNsLdZJqTh4ipUsGOEQIZ5QCeKTxM3s/Js3ZnUugkoHM/zBxtx1MAn1el RbfdzjfOg9QK12olQMuqM4Ft =LpfO -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 05:59:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19136 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 05:59:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from keymaster.etla.net (etla.Stanford.EDU [171.64.202.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19130 for ; Thu, 11 Feb 1999 05:59:08 -0800 (PST) (envelope-from hibma@skylink.it) Received: from henny.jrc.it (mitre4.esdim.noaa.gov [140.90.236.164]) by keymaster.etla.net (8.8.8/8.8.7) with ESMTP id FAA08801; Thu, 11 Feb 1999 05:59:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by henny.jrc.it (8.9.1/8.8.7) with SMTP id RAA01380; Wed, 10 Feb 1999 17:44:56 +0100 (CET) (envelope-from hibma@skylink.it) Date: Wed, 10 Feb 1999 17:44:56 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: hibma@skylink.it To: Tom Torrance at home cc: hackers@FreeBSD.ORG Subject: Re: USB minor glitch In-Reply-To: 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 Could send me a dump of that garbage including your kernel config file? I would like to know which parts you did configure, what hardware you have. The output probably shows which part of the source is complaining. Cheers. Nick > > I have a ASUS Tx97 with on-board uhci0 controller. > If I compile a kernel without also specifying 'controller ohci0' > when I boot the system, all seems normal, but when it gets to > the login prompt, all kinds of garbage starts being written > dynamically to the screen. > Either removing the USB stuff or adding the missing controller > entry gets rid of the problem. > > Regards, > Tom > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > FreeBSD USB Driver Development -- e-mail: n_hibma@freebsd.org home page: http://www.etla.net/~n_hibma/usb/usb.pl mailing list: usb-bsd@egroups.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 06:21:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA22348 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 06:21:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA22316 for ; Thu, 11 Feb 1999 06:21:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id PAA21440; Thu, 11 Feb 1999 15:21:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA08476; Thu, 11 Feb 1999 15:21:18 +0100 (MET) Date: Thu, 11 Feb 1999 15:21:18 +0100 From: Eivind Eklund To: Matthew Hunt Cc: phoenix@calldei.com, GReg Sutter , Greg Lehey , hackers@FreeBSD.ORG Subject: Re: Proposal: Ignore .nofinger for root Message-ID: <19990211152118.D96008@bitbox.follo.net> References: <19990209200259.A98301@wopr.caltech.edu> <19990210082606.B58482@holly.dyndns.org> <19990210074658.A10003@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990210074658.A10003@wopr.caltech.edu>; from Matthew Hunt on Wed, Feb 10, 1999 at 07:46:58AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 10, 1999 at 07:46:58AM -0800, Matthew Hunt wrote: > On Wed, Feb 10, 1999 at 08:26:06AM -0600, Chris Costello wrote: > > > Yes. Why? > > Well, I thought the rationale was trivial: To provide accurate > information to the superuser. > > On further reflection, though, that the patch is poor design, > although the argument is more subtle than your argument of "why?" > or Greg Lehey's argument that using finger on a local system > is somehow perverse. > > I thought a good argument for the patch goes something like this: > The superuser has access to all of the information provided by > finger on a local system anyhow, so allowing ~/.nofinger only serves > to mislead him or make it less convenient for him to get to the > information he wants. > > However, that statement is true for all local users, not just the > superuser. Any user on the system who wanted to get around the > "protection" of ~/.nofinger could just build a new "finger" with > the hide() check removed. > > The conclusion, therefore, is that if a change were to be made, it > should be that finger(1) ignores ~/.nofinger for all local users. > The effects of such a change are more far-reaching than I feel > appropriate, so I withdraw the proposal. I consider this appropriate. I'll do this if people don't directly object; I've been fooled by this at least once, and it is inconvenient to have to use other means to get at the info. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 06:31:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23558 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 06:31:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA23535 for ; Thu, 11 Feb 1999 06:31:01 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA18114; Thu, 11 Feb 1999 15:30:44 +0100 (CET) (envelope-from des) To: Peter Wemm Cc: Matthew Dillon , Dag-Erling Smorgrav , Christoph Kukulies , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902110308.LAA60544@spinner.netplex.com.au> From: Dag-Erling Smorgrav Date: 11 Feb 1999 15:30:43 +0100 In-Reply-To: Peter Wemm's message of "Thu, 11 Feb 1999 11:08:44 +0800" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > I implemented it on FreeBSD back in 1996 or so but gave up in the end. > The biggest offender was the libc RPC code, but there were a constant > supply of things that mysteriously failed. It was a real nightmare trying > to track down and locate them. That's what glimpse is for. I'm willing to do the work if someone provides the patches for select(). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 06:37:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24461 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 06:37:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24450 for ; Thu, 11 Feb 1999 06:37:52 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id OAA19405 for hackers@FreeBSD.ORG; Thu, 11 Feb 1999 14:37:50 GMT From: Emmanuel DELOGET Message-Id: <199902111437.OAA19405@excalibur.oceanis.net> Subject: TEXT_SET() macro To: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Date: Thu, 11 Feb 1999 15:37:49 +0100 (MET) 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 [Sorry to disturb you - the third - 2.2.8 user (helas !)] I'm very impressed by inline asm directives. But as I never worked with the AT&T asm syntax, I feel really bad when I find one in the body of a macro. I suppose that the .stabs directive in the MAKE_SET/TEXT_SET macro introduce a stripable symbol, but I may be wrong. Could someone tell me the truth about this ? [thanx, the first]. In addition, could someone tell me what is the purpose of the MAKE_SET/TEXT_SET macro ? I understand that they declare a : static void const * const __set_sss_sym_yyy = &yyy; asm (".stabs \"_sss\", ttt, 0, 0, _yyy") But I don't understand the purpose of this. [thanx, the secondth]. ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 07:01:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27739 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 07:01:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA27733 for ; Thu, 11 Feb 1999 07:01:31 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id HAA13129; Thu, 11 Feb 1999 07:01:17 -0800 Date: Thu, 11 Feb 1999 07:01:17 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902101949.LAA85603@apollo.backplane.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 > :As a consequence, FreeBSD lost out for being considered a candidate > :at NASA/Ames for large mass storage. Shrug...It may or may not be > :true that softupdates, per se, are stable. In my opinion, FFS as > :offered by FreeBSD (and NetBSD) have not shown themselves to be > :adequate to large (>500GB) filesystems. Sad to say, ext2 under > :linux works better. > > Matt, I don't recall seeing anything from you in regards to > large filesystems. Looking in the archives, I see one report > on Jan 27th from you relating to softupdates, but you indicate > that softupdates was not enabled on the volume in question, > so it seems unlikely that it is related to softupdates specifically. I was misremembering. Softupdates wasn't the issue here but there *had* been some question about whether this was a problem with softupdates *not* enabled- that was from way earlier- sorry for jumping into the wrong thread and sorry for also probably letting a less than felicitous tone enter this email- I think I'm just really irritated that I didn't get mail back from Luoqi. > > There have been several reports of dirty-buffer panics which is > of concern, but I haven't been able to reproduce the panic myself > yet. Really? I found it fairly easy to reproduce in that every time I had a large filesystem (e.g. > 10GB) and ran some fairly simple tests that exercise VM and Filesystem interactions (simple code available on request- NetBSD and FreeBSD fail in interesting and uninteresting ways. Solaris and Linux pass unless there's an underlying h/w problem). I stopped testing when I wasn't getting any response on this (see below for why)- but if somebody is thinking of attacking this problem again I can certainly do some testing (I may not be able to make test systems directly available because of some NASA policies but I can probably snag some systems for myself to run tests with- I have a couple of FreeBSD systems running NASA/Ames still plus the ones I have at Feral (although Feral's disk resources are substantially *less* than NASA/Ames!)). Here's a couple of private emails that listed problems I was seeing. It really seems to live down in the realloc blocks code. I wasn't subscribed to freebsd-hackers back then, so I probably just didn't get this problem announced to the right group. ++Date: Thu, 10 Dec 1998 09:01:39 -0800 (PST) ++From: Matthew Jacob ++To: Jordan K. Hubbard ++Cc: Mike Smith , Justin T. Gibbs , ++dg@root.com ++Subject: More panics... ++ ++ ++I have not been able to arrange either a GDB line for this test system, ++nor have I gotten access for others to get to it as yet. ++ ++However, with a kernel built from sources around that of Monday night or ++so, the same testing got: ++ ++swap_pager: suggest more swap space: 1028 MB ++panic: ffs_reallocblks: unallocated block 1 ++ ++ ++With a stack of: ++ ffs_reallocblks ++ cluster_write ++ ffs_write ++ vn_write ++ write ++ ++Is this of interest considering all the recent commits for the ufs code ++and new fsck etc.? This was with even a 'normal' (1K/8K) but quite large ++filesystem. And no, I don't have softupdates on- I just have whatever ++comes out of the box... ++Date: Wed, 16 Dec 1998 08:53:49 -0800 (PST) ++From: Matthew Jacob ++To: Mike Smith ++Cc: Jordan K. Hubbard , Justin T. Gibbs , dg@root.com ++Subject: Re: More panics... ++ ++ ++Neither Luoqi nor Kirk responded. I've had systems panic and crash even ++with the realloc blocks code turn off (somewhere in the ffs alloc layer). ++ ++I have been unsuccessful in getting 'official' remote access to some of ++the large systems because the person in charge has pointed out that there ++is no 'code sharing' Space Act agreement with FreeBSD as there is with ++NetBSD- this is a disappointment. It also was unhelpful that the problem ++couldn't be addressed because the 250GB dump server now is running ++NetBSD-current because it stayed up and was more stable than ++FreeBSD-current. Damn- I'm having bad luck in getting some buyin at NAS ++(which is suffering from budget problems but still has a hell of a lot of ++iron to play with). ++ ++With a modest amount of h/w involved (e.g. a 2x180Mhz PPro) and one fast ++disk, this problem seems to be reproducible. I'm not a filesystem guy (if ++I'm *anything* from having spread myself too thinly)- so I haven't cycles ++nor intelligence (probably) to nail it. Whom really will own this problem? ++I'd rank this is as far more serious than NFS issues. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 07:12:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29448 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 07:12:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29438 for ; Thu, 11 Feb 1999 07:12:15 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id KAA06715; Thu, 11 Feb 1999 10:11:50 -0500 (EST) Date: Thu, 11 Feb 1999 10:11:50 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 To: Emmanuel DELOGET cc: FreeBSD Hackers Mail List Subject: Re: TEXT_SET() macro In-Reply-To: <199902111437.OAA19405@excalibur.oceanis.net> 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 Please search the FreeBSD mailinglist Archive (make sure that you include the hackers list) for keywords "linker and set". They refer to the linker sets - sets declared by you and created by the linker. -------------------------------------------------- | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | | Dept. of Computer Science, SUNY at Binghamton | -------------------------------------------------- On Thu, 11 Feb 1999, Emmanuel DELOGET wrote: > [Sorry to disturb you - the third - 2.2.8 user (helas !)] > > I'm very impressed by inline asm directives. But as I never > worked with the AT&T asm syntax, I feel really bad when I > find one in the body of a macro. I suppose that the > .stabs directive in the MAKE_SET/TEXT_SET macro introduce > a stripable symbol, but I may be wrong. Could someone tell > me the truth about this ? [thanx, the first]. > > In addition, could someone tell me what is the purpose of the > MAKE_SET/TEXT_SET macro ? I understand that they declare > a : > static void const * const __set_sss_sym_yyy = &yyy; > asm (".stabs \"_sss\", ttt, 0, 0, _yyy") > > But I don't understand the purpose of this. [thanx, the > secondth]. > > ____________________________________________________________________ > Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA > -------------------------------------------------------------------- > > 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 Thu Feb 11 07:32:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02552 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 07:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02545 for ; Thu, 11 Feb 1999 07:32:37 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id HAA29608; Thu, 11 Feb 1999 07:30:24 -0800 (PST) Message-Id: <199902111530.HAA29608@implode.root.com> To: mjacob@feral.com cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-reply-to: Your message of "Thu, 11 Feb 1999 07:01:17 PST." From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Feb 1999 07:30:23 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Really? I found it fairly easy to reproduce in that every time I had a >large filesystem (e.g. > 10GB) and ran some fairly simple tests that >exercise VM and Filesystem interactions (simple code available on request- >NetBSD and FreeBSD fail in interesting and uninteresting ways. Solaris and >Linux pass unless there's an underlying h/w problem). I stopped testing >when I wasn't getting any response on this (see below for why)- but if >somebody is thinking of attacking this problem again I can certainly do >some testing (I may not be able to make test systems directly available >because of some NASA policies but I can probably snag some systems for >myself to run tests with- I have a couple of FreeBSD systems running >NASA/Ames still plus the ones I have at Feral (although Feral's disk >resources are substantially *less* than NASA/Ames!)). > >Here's a couple of private emails that listed problems I was seeing. It >really seems to live down in the realloc blocks code. I wasn't subscribed >to freebsd-hackers back then, so I probably just didn't get this problem >announced to the right group. ... >++panic: ffs_reallocblks: unallocated block 1 >++ >++ >++With a stack of: >++ ffs_reallocblks >++ cluster_write >++ ffs_write >++ vn_write >++ write I thought it was made fairly clear that there were problems with missing bmap operations in some places, which are brought to the surface with the reallocblks code. I also thought it was made fairly clear that there is a sysctl variable available to disable reallocblks (vfs.ffs.doreallocblks). I know I've sent many messages on this subject to the FreeBSD lists; I apologize if you didn't see them. In any case, the reallocblks problems are believed to be fixed now. If this isn't true, then we need to make sure that it is set to disabled for the upcoming 3.1 release. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 07:38:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA03329 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 07:38:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA03321 for ; Thu, 11 Feb 1999 07:38:28 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id HAA13231; Thu, 11 Feb 1999 07:38:21 -0800 Date: Thu, 11 Feb 1999 07:38:20 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: David Greenman cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902111530.HAA29608@implode.root.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 I guess it really wasn't clear to me. The second email I included also showed that the problem still occurred even after the realloc stuff was sysctl'd off. Like I said- if folks are really going to work on it I'll start testing it again. > > I thought it was made fairly clear that there were problems with missing > bmap operations in some places, which are brought to the surface with the > reallocblks code. I also thought it was made fairly clear that there is a > sysctl variable available to disable reallocblks (vfs.ffs.doreallocblks). > I know I've sent many messages on this subject to the FreeBSD lists; I > apologize if you didn't see them. > In any case, the reallocblks problems are believed to be fixed now. If > this isn't true, then we need to make sure that it is set to disabled for > the upcoming 3.1 release. > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project > > 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 Thu Feb 11 08:17:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07945 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 08:17:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07935 for ; Thu, 11 Feb 1999 08:17:23 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id QAA21427; Thu, 11 Feb 1999 16:17:16 GMT From: Emmanuel DELOGET Message-Id: <199902111617.QAA21427@excalibur.oceanis.net> Subject: Re: TEXT_SET() macro In-Reply-To: from zhihuizhang at "Feb 11, 1999 10:11:50 am" To: bf20761@binghamton.edu (zhihuizhang) Date: Thu, 11 Feb 1999 17:17:15 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 Of course... I'm begin to read :) (too bad I didn't think to that by myself...) As zhihuizhang said... ** ** Please search the FreeBSD mailinglist Archive (make sure that you include ** the hackers list) for keywords "linker and set". They refer to the linker ** sets - sets declared by you and created by the linker. ** ** -------------------------------------------------- ** | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | ** | Dept. of Computer Science, SUNY at Binghamton | ** -------------------------------------------------- ** ** On Thu, 11 Feb 1999, Emmanuel DELOGET wrote: ** ** [lots of bad stuff deleted] ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 08:52:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11725 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 08:52:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA11694 for ; Thu, 11 Feb 1999 08:51:58 -0800 (PST) (envelope-from vev@michvhf.com) Received: (qmail 25845 invoked by uid 1001); 11 Feb 1999 16:52:00 -0000 Date: Thu, 11 Feb 1999 11:52:00 -0500 (EST) From: Vince Vielhaber To: Bob Willcox cc: hackers list Subject: Re: Need help disklabeling zip drives In-Reply-To: <19990211070158.A5111@luke.pmr.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 Thu, 11 Feb 1999, Bob Willcox wrote: > Hi all, > > Could some kind soul(s) out there please tell me how they go about > disklabeling their zip drives? I changed the partition type on my zip > cartridge from DOS (6) to FreeBSD (165) but can't figure out how to get > disklabel to put a label on it. This is on a scsi zip drive running > 3.0-stable (of 2/9). On 2.2.x after getting a few of those errors that I just snipped out I wrote a quick script based on what I found in the handbook. Works quite well (note this is with an IDE zip disk, you'll need to change the device filenames to match yours): dd if=/dev/zero of=/dev/rwfd0 count=2 disklabel -w -r wfd0 zip100 stuff newfs /dev/rwfd0c mount /dev/wfd0c /zip cp new-zip-disk /zip Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 09:34:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16986 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 09:34:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16976 for ; Thu, 11 Feb 1999 09:34:56 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA13755 for ; Thu, 11 Feb 1999 09:34:52 -0800 Date: Thu, 11 Feb 1999 09:34:52 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-hackers@FreeBSD.ORG Subject: softupdate panic, anyone seen this? 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 Alpha, 4.0 current of Feb 8, during a reboot: syncing disks... 14 10 5 1 done panic: softdep_sync_metadata: Unknown type bmsafemap panic Stopped at Debugger..ng+0x24: ldq ra,0(sp) <0xfffffe0007a959c0> db> t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 softdep_sync_metadata..ng() at softdep_sync_metadata..ng+0x410 ffs_fsync..ng() at ffs_fsync..ng+0x31c vinvalbuf..ng() at vinvalbuf..ng+0x104 vclean..ng() at vclean..ng+0xc0 vflush..ng() at vflush..ng+0x100 ffs_flushfiles..ng() at ffs_flushfiles..ng+0x30 softdep_flushfiles..ng() at softdep_flushfiles..ng+0x90 ffs_unmount..ng() at ffs_unmount..ng+0x58 dounmount..ng() at dounmount..ng+0x130 vfs_unmountall..ng() at vfs_unmountall..ng+0x68 boot..ng() at boot..ng+0x320 reboot..ng() at reboot..ng+0x3c syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x1200007d4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 10:46:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27753 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 10:46:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA27744 for ; Thu, 11 Feb 1999 10:46:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id KAA93962; Thu, 11 Feb 1999 10:45:44 -0800 (PST) (envelope-from dillon) Date: Thu, 11 Feb 1999 10:45:44 -0800 (PST) From: Matthew Dillon Message-Id: <199902111845.KAA93962@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: Peter Wemm , Dag-Erling Smorgrav , Christoph Kukulies , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902110308.LAA60544@spinner.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Peter Wemm writes: :> I implemented it on FreeBSD back in 1996 or so but gave up in the end. :> The biggest offender was the libc RPC code, but there were a constant :> supply of things that mysteriously failed. It was a real nightmare trying :> to track down and locate them. : :That's what glimpse is for. I'm willing to do the work if someone :provides the patches for select(). : :DES :-- :Dag-Erling Smorgrav - des@flood.ping.uio.no I don't think too many people would appreciate anybody screwing around with select's operational semantics. Linux backed out their change to match MOTROTW, we definitely should not be going off playing see-saw. BSD's select() has *never* modified tv and it is never going to modify tv. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 10:58:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA29513 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 10:58:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailhost.det.ameritech.net (mpdr0.detroit.mi.ameritech.net [206.141.239.206]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA29507 for ; Thu, 11 Feb 1999 10:58:21 -0800 (PST) (envelope-from jerry@reillyplating.com) Received: from reillyplating.com ([209.18.31.101]) by mailhost.det.ameritech.net (InterMail v03.02.07 118 124) with SMTP id <19990211195418.MTN21951@reillyplating.com> for ; Thu, 11 Feb 1999 13:54:18 -0600 Received: from reillyplating.com (jerry.lan [10.0.0.9]) by reillyplating.com (8.8.8/8.8.5) with ESMTP id NAA12327 for ; Thu, 11 Feb 1999 13:58:06 -0500 (EST) Message-ID: <36C32825.A1C6294F@reillyplating.com> Date: Thu, 11 Feb 1999 13:57:41 -0500 From: Jerry Bell X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Adding a pnp device id Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Where would I look to add a pnp id number for a modem that is not being detected during the pnp device probe at boot? I have tried putting it in the pnpdata file and sio.c, (remaking & reinstalling afterward), but the modem still is not detected. The modem is detected by the bios and displayed on the list after the post. I am running 4.0 current, built from last weekend (2/7/99). I have tried this on several different pc's with different motherboards with the same results. Thank you, Jerry Bell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 11:10:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01859 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 11:10:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from csgrad.cs.vt.edu (csgrad.cs.vt.edu [128.173.41.41]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01842 for ; Thu, 11 Feb 1999 11:10:36 -0800 (PST) (envelope-from mhabib@vt.edu) Received: from bindgrass (bindgrass.cs.vt.edu [128.173.41.121]) by csgrad.cs.vt.edu (8.9.1a/8.9.1) with SMTP id OAA17945 for ; Thu, 11 Feb 1999 14:10:29 -0500 (EST) Message-Id: <3.0.5.32.19990211140756.0090e4f0@csgrad.cs.vt.edu> X-Sender: palash@csgrad.cs.vt.edu X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 11 Feb 1999 14:07:56 -0500 To: freebsd-hackers@FreeBSD.ORG From: "Md. Ahsan Habib" Subject: /dev/kmem 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 am facing some problems to use /dev/kmem. I tried a lot, post it to the news groups but couldn't come up to a solution. In one of my experiments I need to write in /dev/kmem. I can't use normal file because it will consume more time which will affect my experiments. This is a sample code I tried to execute: #include #include #include extern int errno; int main() { int fp,w,c; long l; char * Buff = "1234"; fp = open("/dev/kmem", O_RDWR); if (fp == -1) { printf("open returned error\n"); perror("open"); } l = lseek(fp, 0x000a000,0); w = write(fp,Buff,4); c = close(fp); return 0; } It can open the file, change the file pointer, close the file but can't write anything in the file. The value of w is always -1. I tried with several locations instead of the beginning one 0x000a000. I set all necessary mod and ownership. I will be happy if anyone can help me. It's really important to me. Sincerely, --Ahsan Habib Department of Computer Science Virginia Tech. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 11:14:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02264 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 11:14:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA02258 for ; Thu, 11 Feb 1999 11:14:01 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id LAA01519; Thu, 11 Feb 1999 11:12:50 -0800 (PST) Message-Id: <199902111912.LAA01519@implode.root.com> To: "Md. Ahsan Habib" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /dev/kmem In-reply-to: Your message of "Thu, 11 Feb 1999 14:07:56 EST." <3.0.5.32.19990211140756.0090e4f0@csgrad.cs.vt.edu> From: David Greenman Reply-To: dg@root.com Date: Thu, 11 Feb 1999 11:12:50 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I am facing some problems to use /dev/kmem. I tried a lot, post it to the >news groups but couldn't come up to a solution. In one of my experiments I >need to write in /dev/kmem. I can't use normal file because it will consume >more time which will affect my experiments. > >This is a sample code I tried to execute: > >#include >#include >#include > >extern int errno; > >int main() >{ > int fp,w,c; > long l; > char * Buff = "1234"; > > fp = open("/dev/kmem", O_RDWR); > if (fp == -1) { > printf("open returned error\n"); > perror("open"); > } > l = lseek(fp, 0x000a000,0); > w = write(fp,Buff,4); > c = close(fp); > return 0; >} > >It can open the file, change the file pointer, close the file but can't >write anything in the file. The value of w is always -1. I tried with >several locations instead of the beginning one 0x000a000. > >I set all necessary mod and ownership. > >I will be happy if anyone can help me. It's really important to me. /dev/kmem addresses start at the kernel start address, KERNBASE. Attempts to access memory locations below that will fail. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 11:33:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04991 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 11:33:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04986 for ; Thu, 11 Feb 1999 11:33:31 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA09149; Thu, 11 Feb 1999 12:37:48 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd008910; Thu Feb 11 12:37:44 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA01698; Thu, 11 Feb 1999 12:32:45 -0700 (MST) From: Terry Lambert Message-Id: <199902111932.MAA01698@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: peter@netplex.com.au (Peter Wemm) Date: Thu, 11 Feb 1999 19:32:43 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902110807.QAA61681@spinner.netplex.com.au> from "Peter Wemm" at Feb 11, 99 04:07:25 pm X-Mailer: ELM [version 2.4 PL25] 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 > > Yeah; the putative utility isn't really at issue, though, only whether > > it works on Linux and not on FreeBSD. You could make the same argument > > about value on SYSV IPC, since it's not select(2)'able. > > I wasn't talking about select(), I was talking about *file* locking on > non-files like sockets and pipes. FWIW, it *looks* rather simple to > implement this at a higher level since the kern_lockf.c code is not > actually vnode specific at all. All that it (in theory) needs is for > sockets and pipes to implement an advlock() op entry, fetch their per-pipe/ > socket 'struct lockf *' and call lf_advlock(). lf_advlock() takes a VOP_* > style argument but it doesn't need to, it could just as well take explicit > args. You would need to do more than just that. Specifically, you would need to add an advlock op to the struct fileops, since those three types of descriptors aren't implemented by a VFS. I've suggested soloutions in the past for this, so I won't suggest them again. > My point is, if it was *useful* or *in use*, then somebody would have > implemented it it. Well, we've been asked the question at least three times, by my count, on the -current mailing list, so it's *in use*. That doesn't preclude anyone from declaring that it's not *useful*, of course, since that's always a subjective judgement. > > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > > > *Only* the file locking parts are not implemented since it's of such > > > little value with no seek space. > > > > Hmmmm. From my reading of the sources, this is actually a fairly > > recent addition (November 11th, 1998, by Truckman). I blame my > > build environment for that particular lapse. > > I looked at the code and it isn't a new feature. What Don Lewis did was > clean up the interfaces a little so that the functionality was tracked > better to prevent SIGIO shootdowns. It's always been done this way (fcntl > translated into an ioctl()), but it used to be done with TIOCSPGRP etc and > now it's done with FIOSETOWN and friends. The functionality is a little > more robust, it's not new. You need to "cvs diff -r 1.44 -r 1.45 -c sys_pipe.c | more". The code was implemented for sockets, but not anything else that used struct fileops. This was an extension to support it on pipes. > > I still don't think the non-existance of a real vs. a virtual seek > > space is relevent. > > Supporting unused features causes bloat. Unless it's actually going to be > useful and maybe even *used* then it's irrelevant. Incidently, I can see > one use for it, and that's to do a mutex of some sort. Imagine a > cooperative process pair that want to get records over a pipe or socket > but the data is written non-atomically in multiple chunks, etc. This is a > bad example though because there are better ways. Right. But "bloat" is a bad example of a reason not to do this, since you could get rid of all the duplicate code in each VFS, and at the same time get rid of the problems with VOP_ADVLOCK stacking, and get rid of the struct fileops entirely. The net amount of code to implement this would be *less* than the amount of code that's in there now. Even if you don't agree that NFS client locking requires a veto based VOP_ADVLOCK, an anti-bloatist can't argue with the reduction of bloat. > > The obvious way to fix this is to hang the locks off the vnode, and > > move the advisory locking out of all FS's (except the network clients, > > of course, which may need to veto lock coelescence if the server > > refuses the lock). > > This would fix nothing in these cases since sockets and pipes do not *have* > a vnode. > > You've got me bugged now.. I had a quick shot at seeing just how hard it > would actually be to implement locking for pipes and sockets. I was > suprised at how easy it's turning out and (to my suprise) it slightly > tidies a few things up a bit.. Well, if getting you bugged gets code to do something from someone who can commit it.... 8-)... while you are in there, you might want to look at what it would take to put pty's, sockets, pipes, and the IPC system calls into specfs-like VFS's. This would let you get rid of struct fileops entirely, and reduce bloat at the same time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 11:45:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06657 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 11:45:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA06650 for ; Thu, 11 Feb 1999 11:45:29 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <53543(5)>; Thu, 11 Feb 1999 11:45:20 PST Received: from mango.parc.xerox.com (localhost.parc.xerox.com [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id LAA29962; Thu, 11 Feb 1999 11:45:19 -0800 (PST) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199902111945.LAA29962@mango.parc.xerox.com> To: Julian Elischer cc: Larry Lile , hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-reply-to: Your message of "Tue, 09 Feb 1999 13:43:07 PST." Date: Thu, 11 Feb 1999 11:45:19 PST From: Bill Fenner Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message you wr ite: >probably the fact that as soon as a cluster is filled, >it's sent.. This is no longer completely true. Larry, what MSS was negotiated? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 12:45:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14813 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 12:45:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14800 for ; Thu, 11 Feb 1999 12:45:05 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id PAA08781; Thu, 11 Feb 1999 15:35:32 -0500 (EST) (envelope-from lile@stdio.com) Date: Thu, 11 Feb 1999 15:35:31 -0500 (EST) From: Larry Lile To: Bill Fenner cc: Julian Elischer , hackers@FreeBSD.ORG Subject: Re: Why did this panic? In-Reply-To: <199902111945.LAA29962@mango.parc.xerox.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 MSS? Is that the maximum send size negotiated in a tcp header? Sorry I just don't recognize that acronym and I don't have my Steven's books with me. If so I missed it in the trace, but I can reproduce it. I had just silently attributed it to "net.local.dgram.maxdgram: 2048" in my own mind but wasn't sure. Larry Lile lile@stdio.com On Thu, 11 Feb 1999, Bill Fenner wrote: > In message you wr > ite: > >probably the fact that as soon as a cluster is filled, > >it's sent.. > > This is no longer completely true. > > Larry, what MSS was negotiated? > > Bill > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 12:54:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15851 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 12:54:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA15846 for ; Thu, 11 Feb 1999 12:54:35 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <53725(4)>; Thu, 11 Feb 1999 12:54:29 PST Received: (from fenner@localhost) by mango.parc.xerox.com (8.8.8/8.8.8) id MAA01500; Thu, 11 Feb 1999 12:54:24 -0800 (PST) (envelope-from fenner) Date: Thu, 11 Feb 1999 12:54:24 PST From: Bill Fenner Message-Id: <199902112054.MAA01500@mango.parc.xerox.com> To: fenner@parc.xerox.com, lile@stdio.com Subject: Re: Why did this panic? Cc: hackers@FreeBSD.ORG, julian@whistle.com In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When the connection was established, the MSS options in the SYN packets determine what size packet each end may send; I was just wondering if somehow the other system had negotiated a 2K MSS. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:20:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19265 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:20:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19249 for ; Thu, 11 Feb 1999 13:20:06 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA25298; Thu, 11 Feb 1999 14:24:22 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd025255; Thu Feb 11 14:24:03 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA10970; Thu, 11 Feb 1999 14:19:30 -0700 (MST) From: Terry Lambert Message-Id: <199902112119.OAA10970@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy) Date: Thu, 11 Feb 1999 21:19:30 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <99Feb11.162122est.40373@border.alcanet.com.au> from "Peter Jeremy" at Feb 11, 99 04:31:46 pm X-Mailer: ELM [version 2.4 PL25] 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 > >If the sem_op is a negative integer, and the absolute value of the > >sem_op is larger than the current value of the semaphore, and the > >value of (sem_flg&IPC_NOWAIT) is false, then the operation is ignored. > > As far as I can tell, this is handled correctly. > > Looking at v 1.22, this is detected at line 690. Then follows a debug > statement "can't do it now" and a break. The break exits the inner > for loop (ending at line 717) whick is working thru all the semops > passed in. Since we haven't made it through all the semops, we fall > through lines 725-746, unwinding any partially commited operations. > Then there's a tsleep() on semaptr (which is the semaphore > descriptor). If the tsleep returns normally, the whole thing is > repeated courtesy of the for loop covering lines 671-786. > > The tsleep is woken up by a semctl() with IPC_RMID, SETVAL, SETALL, > or a semop() or semexit() that up's any semaphores in that descriptor. What about a negative initial value setting? I used this technique on UnixWare to implement an RPC interlock mechanism that involved setting things up in shared memory in one process, and processing in another; roughly, the following states: 99> ,----. | | | | ,----' | ,----. | | | | | | | | | | 0> | | | | | `----' | | | | | -99> ----' `----- listen call reset setup return I had to implement it a different way on FreeBSD because the initialization to a negative value failed the addition (the process slept forever). When the man page says "absolute value", it *means* "absolute value". The zero crossing boundary is broken. It's needed to be able to set it up so that if the caller dies/goes away, the callee has to see an inverted value for the state so it can go back into listen mode -- in other words, a failure to a reset condition, even when the return value is unacknowledged. Since the same parameter area was used by multiple clients of the "Remote Procedure Call" interface, the rturn *must* be acknowlged, instead of being implemented as a one-shot. > EIDRM was added (I believe by sos) sometime after 2.2.6. It's only > used by sysv_msg.c and sysv_sem.c - and from what I can see, the code > is all protected by #ifdef EIDRM's, so the code should work correctly, > whether or not EIDRM is defined. Someone with commit priv's just > needs to remove the comment saying it doesn't exist. And the #if/#else/EINVAL/#endif. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:32:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20763 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:32:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20752 for ; Thu, 11 Feb 1999 13:32:45 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA25643; Thu, 11 Feb 1999 13:23:39 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdm25641; Thu Feb 11 21:23:37 1999 Date: Thu, 11 Feb 1999 13:23:32 -0800 (PST) From: Julian Elischer To: Matthew Jacob cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: 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 Thu, 11 Feb 1999, Matthew Jacob wrote: > > > :As a consequence, FreeBSD lost out for being considered a candidate > > :at NASA/Ames for large mass storage. Shrug...It may or may not be > > :true that softupdates, per se, are stable. In my opinion, FFS as > > :offered by FreeBSD (and NetBSD) have not shown themselves to be > > :adequate to large (>500GB) filesystems. Sad to say, ext2 under > > :linux works better. > > > > Matt, I don't recall seeing anything from you in regards to > > large filesystems. Looking in the archives, I see one report > > on Jan 27th from you relating to softupdates, but you indicate > > that softupdates was not enabled on the volume in question, > > so it seems unlikely that it is related to softupdates specifically. > > I was misremembering. Softupdates wasn't the issue here but there *had* > been some question about whether this was a problem with softupdates *not* > enabled- that was from way earlier- sorry for jumping into the wrong > thread and sorry for also probably letting a less than felicitous tone > enter this email- I think I'm just really irritated that I didn't get mail > back from Luoqi. Luoqi was "out of contact" for a while.. (had a real life plus work) but he's not responsible for softupdates anyway. I am, and I didn't see any unresolved problems from you... There are two open issues with soft updates BTW.. One is that soft updates stresses the disks so hard that the WD driver gets into an infinite loop when in "single-block mode" (I've seen this a couple of times in tests here) (and can reproduce it, even looked at it in ddb but not totally solved it) (work-around is set flags to ide driver to allow multi-block or Ultra-DMA). The second is that under some situations the system can almost deadlock with processes doing large mmaps and stuff. A workaround is known and I'd likeot discuss it with Matt dillon tonight at the freebsd meeting (you be there matt(D)?) julian There was one that happenned while I was out of town for a few days and when I got back there was some email with it that indicated that it had been found to not be a problem with soft-updates so I let it go. > > > > > There have been several reports of dirty-buffer panics which is > > of concern, but I haven't been able to reproduce the panic myself > > yet. > > Really? I found it fairly easy to reproduce in that every time I had a > large filesystem (e.g. > 10GB) and ran some fairly simple tests that > exercise VM and Filesystem interactions (simple code available on request- > NetBSD and FreeBSD fail in interesting and uninteresting ways. Solaris and > Linux pass unless there's an underlying h/w problem). I stopped testing > when I wasn't getting any response on this (see below for why)- but if > somebody is thinking of attacking this problem again I can certainly do > some testing (I may not be able to make test systems directly available > because of some NASA policies but I can probably snag some systems for > myself to run tests with- I have a couple of FreeBSD systems running > NASA/Ames still plus the ones I have at Feral (although Feral's disk > resources are substantially *less* than NASA/Ames!)). > > Here's a couple of private emails that listed problems I was seeing. It > really seems to live down in the realloc blocks code. I wasn't subscribed > to freebsd-hackers back then, so I probably just didn't get this problem > announced to the right group. > > > ++Date: Thu, 10 Dec 1998 09:01:39 -0800 (PST) > ++From: Matthew Jacob > ++To: Jordan K. Hubbard > ++Cc: Mike Smith , Justin T. Gibbs , > ++dg@root.com > ++Subject: More panics... > ++ > ++ > ++I have not been able to arrange either a GDB line for this test system, > ++nor have I gotten access for others to get to it as yet. > ++ > ++However, with a kernel built from sources around that of Monday night or > ++so, the same testing got: > ++ > ++swap_pager: suggest more swap space: 1028 MB > ++panic: ffs_reallocblks: unallocated block 1 > ++ > ++ > ++With a stack of: > ++ ffs_reallocblks > ++ cluster_write > ++ ffs_write > ++ vn_write > ++ write > ++ > ++Is this of interest considering all the recent commits for the ufs code > ++and new fsck etc.? This was with even a 'normal' (1K/8K) but quite large > ++filesystem. And no, I don't have softupdates on- I just have whatever > ++comes out of the box... > > ++Date: Wed, 16 Dec 1998 08:53:49 -0800 (PST) > ++From: Matthew Jacob > ++To: Mike Smith > ++Cc: Jordan K. Hubbard , Justin T. Gibbs , dg@root.com > ++Subject: Re: More panics... > ++ > ++ > ++Neither Luoqi nor Kirk responded. I've had systems panic and crash even > ++with the realloc blocks code turn off (somewhere in the ffs alloc layer). > ++ > ++I have been unsuccessful in getting 'official' remote access to some of > ++the large systems because the person in charge has pointed out that there > ++is no 'code sharing' Space Act agreement with FreeBSD as there is with > ++NetBSD- this is a disappointment. It also was unhelpful that the problem > ++couldn't be addressed because the 250GB dump server now is running > ++NetBSD-current because it stayed up and was more stable than > ++FreeBSD-current. Damn- I'm having bad luck in getting some buyin at NAS > ++(which is suffering from budget problems but still has a hell of a lot of > ++iron to play with). > ++ > ++With a modest amount of h/w involved (e.g. a 2x180Mhz PPro) and one fast > ++disk, this problem seems to be reproducible. I'm not a filesystem guy (if > ++I'm *anything* from having spread myself too thinly)- so I haven't cycles > ++nor intelligence (probably) to nail it. Whom really will own this problem? > ++I'd rank this is as far more serious than NFS issues. > > > 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 Thu Feb 11 13:37:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21289 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:37:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA21282 for ; Thu, 11 Feb 1999 13:37:17 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA02524; Thu, 11 Feb 1999 14:41:26 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd002376; Thu Feb 11 14:41:19 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA12779; Thu, 11 Feb 1999 14:36:19 -0700 (MST) From: Terry Lambert Message-Id: <199902112136.OAA12779@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 21:36:13 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902110625.WAA88612@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 10:25:29 pm X-Mailer: ELM [version 2.4 PL25] 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 > The issue of file-backed storage verses anon mmap is certainly real, > but it's divergent enough from the original discussion that it should > have been brought up as a separate item rather then as a response, > That's all. Well, I guess I can buy that; I was basically in brain-storm mode about the Subject: line (although the subject line is hardly specific to Linux/FreeBSD code portability). > This brings up a good point, though... I think it might make sense > to be able to specify a MAP_ flag to mmap to indicate that the file's > dirty data backing the map ( for non-anonymous maps ) does not have to > be synced by the syncer. That would make mmap() a much more useful > tool for sharing working sets. The file data would be synced on the > last close of the vnode and if the program really doesn't want it to be > synced at all, the program could madvise() it free ( and we could fix > madvise() to actually support throw-away on a vnode ). So the vnode is just for a rendesvous? This has plusses and minuses; the plus is you can have unrelated processes accessing what is, in effect, anonymous memory of the kind that SYSV SHM has, without the performance penalty you pay for the BSD interface. The minus is that you could really get screwed on things like /dev/zero. > Another possibility would be adding a memory reference passing capability > to unix-domain socket messaging. We can already pass descriptors and > access rights, why not memory too? ( ala mach ). I think this should be done in procfs; that's where my money is, anyway. I would have liked to see the vfork behaviour as a set of flags to a procfs ioctl() on the process, actually, instead of a new system call. The behaviour could be inherited (or not; make it another bit, if necessary). The descriptor passing is a kludge. You could almost use procfs for that, as well. The difference is that the exclusive use bit, if set, would foil a procfs-based "open" attempt, but not a pass. Actually, the dup/dup2/F_DUPFD code is a bit broken in this regard; it appears to honor the exclusive use bit when it shouldn't, by virtue of the underlying implementation (note: I haven't tested this in FreeBSD, only looked at the kernel code). Yet another tangent, but clearly labelled as such: There is a related portability bug, in as far as SVR4 is concerned, having to do with the partial open hack, which show up when you are trying to use the same port for HDB UUCP's uugetty on a port, and use it for dialout at the same time. The exclusive use bit is not reset if an O_EXCL open pending DCD is in progress, and another process issues an O_NDELAY open. The second open completes, but bit is not reset, meaning that if the second open is, say, terminal emulation software that uses external file transfer modules, the external transfer modules can't open the tty. I still think the partial open hack is a very elegant soloution, even if SVR4 has 12 lines of code 24 lines to early to do the right thing with the exclusive use bit. It beats the hell out of designating tty ports as modem-control or non-modem-control and/or having a control port to dick with flags. FreeBSD is way down the wrong road in supporting ABI compliance for modem devices. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:38:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21438 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:38:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA21431 for ; Thu, 11 Feb 1999 13:38:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id NAA95018; Thu, 11 Feb 1999 13:38:06 -0800 (PST) (envelope-from dillon) Date: Thu, 11 Feb 1999 13:38:06 -0800 (PST) From: Matthew Dillon Message-Id: <199902112138.NAA95018@apollo.backplane.com> To: Julian Elischer Cc: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :A workaround is known and I'd likeot discuss it with Matt dillon :tonight at the freebsd meeting (you be there matt(D)?) : :julian You bet! :There was one that happenned while I was out of town for a few days and :when I got back there was some email with it that indicated that it had :been found to not be a problem with soft-updates so I let it go. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:47:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22618 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:47:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22595 for ; Thu, 11 Feb 1999 13:47:11 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA22116; Thu, 11 Feb 1999 14:47:08 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd021841; Thu Feb 11 14:46:58 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA14022; Thu, 11 Feb 1999 14:46:29 -0700 (MST) From: Terry Lambert Message-Id: <199902112146.OAA14022@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 21:46:29 +0000 (GMT) Cc: peter.jeremy@auss2.alcatel.com.au, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199902110701.XAA88892@apollo.backplane.com> from "Matthew Dillon" at Feb 10, 99 11:01:48 pm X-Mailer: ELM [version 2.4 PL25] 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 > :EIDRM was added (I believe by sos) sometime after 2.2.6. It's only > :used by sysv_msg.c and sysv_sem.c - and from what I can see, the code > :is all protected by #ifdef EIDRM's, so the code should work correctly, > :whether or not EIDRM is defined. Someone with commit priv's just > :needs to remove the comment saying it doesn't exist. > > I added an #error inside the #ifdef EIDRM and the compile bombed, > so EIDRM is definitely defined from the point of view of the module. It is. This is basically a complaint on the order of the FreeBSD version identification code in the if_de.c driver that prevents you from cross compiling older/newer kernels on newer/older systems. I suppose I should point out the __NetBSD__ tests in various places also count as needless bloat (in if_de.c, but in lots of other places, too). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:53:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA23427 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:53:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23421 for ; Thu, 11 Feb 1999 13:53:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id NAA95188; Thu, 11 Feb 1999 13:52:43 -0800 (PST) (envelope-from dillon) Date: Thu, 11 Feb 1999 13:52:43 -0800 (PST) From: Matthew Dillon Message-Id: <199902112152.NAA95188@apollo.backplane.com> To: Terry Lambert Cc: peter.jeremy@auss2.alcatel.com.au, tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902112146.OAA14022@usr06.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It is. : :This is basically a complaint on the order of the FreeBSD version :identification code in the if_de.c driver that prevents you from :cross compiling older/newer kernels on newer/older systems. : :I suppose I should point out the __NetBSD__ tests in various places :also count as needless bloat (in if_de.c, but in lots of other places, :too). : : Terry Lambert : terry@lambert.org Only if the NetBSD people aren't using the code. Otherwise I don't count it as bloat since it isn't actually compiled into our binaries. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 13:57:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA23878 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 13:57:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23868 for ; Thu, 11 Feb 1999 13:57:25 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA12385; Thu, 11 Feb 1999 14:57:09 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd012354; Thu Feb 11 14:57:05 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA14970; Thu, 11 Feb 1999 14:57:05 -0700 (MST) From: Terry Lambert Message-Id: <199902112157.OAA14970@usr06.primenet.com> Subject: Re: Quotas implementation To: casper@acc.am (Casper) Date: Thu, 11 Feb 1999 21:57:03 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <36C2A5E9.675D0B71@acc.am> from "Casper" at Feb 11, 99 01:42:01 pm X-Mailer: ELM [version 2.4 PL25] 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 > Are there another ways to implement quota mechanism except that we > use now - quota checks on low-level IO operations (when manipulating > with disk inodes)? > > It's impossible to use (or it will be very nasty hack) existing > FFS/UFS code for my purposes , because no real uids will be created > and stored on disk ... The only way i see , is to patch every > daemon that will originate this IO operations. > > Any ideas ? It would help to know the application. It's a very strange request; quotas are enforced against user ids because they are accounted by credential. If you don't have credentials, then, by definition, really you can't distinguish entities using disk space. If you can't distinguish entities, then everyone is the same. If they are all the same, then there is only one resource consumer, and quotas are irrelevent. So without uids, you will need to invent them anyway, to distinguish enforcement zones. You realize that you can enforce quotas against groups instead of uids, right? There are many other (better) ways to implement quotas, rather than wiring them into the bowels of UFS, but *all* of them depend on some type of credential being associated with VOP's that allocate or deallocate disk space on the quota-ed area. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 14:00:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24417 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:00:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24391 for ; Thu, 11 Feb 1999 14:00:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id NAA95236; Thu, 11 Feb 1999 13:59:52 -0800 (PST) (envelope-from dillon) Date: Thu, 11 Feb 1999 13:59:52 -0800 (PST) From: Matthew Dillon Message-Id: <199902112159.NAA95236@apollo.backplane.com> To: Terry Lambert Cc: peter.jeremy@auss2.alcatel.com.au (Peter Jeremy), tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC References: <199902112119.OAA10970@usr06.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :What about a negative initial value setting? : :I used this technique on UnixWare to implement an RPC interlock :mechanism that involved setting things up in shared memory in one :process, and processing in another; roughly, the following states: : : : 99> ,----. : | | : | | : ,----' | : ,----. | | : | | | | : | | | | : 0> | | | | : | `----' | : | | : | | :-99> ----' `----- : listen call reset : setup return : :I had to implement it a different way on FreeBSD because the What does POSIX have to say about it? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 14:07:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25453 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:07:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25445 for ; Thu, 11 Feb 1999 14:07:10 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA27859; Thu, 11 Feb 1999 15:06:50 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd027783; Thu Feb 11 15:06:38 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA15948; Thu, 11 Feb 1999 15:06:37 -0700 (MST) From: Terry Lambert Message-Id: <199902112206.PAA15948@usr06.primenet.com> Subject: Re: Why did this panic? To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 11 Feb 1999 22:06:36 +0000 (GMT) Cc: fenner@parc.xerox.com, lile@stdio.com, hackers@FreeBSD.ORG, julian@whistle.com In-Reply-To: <199902112054.MAA01500@mango.parc.xerox.com> from "Bill Fenner" at Feb 11, 99 12:54:24 pm X-Mailer: ELM [version 2.4 PL25] 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 > When the connection was established, the MSS options in the SYN packets > determine what size packet each end may send; I was just wondering if > somehow the other system had negotiated a 2K MSS. Size negotiation is end-to-end. There have been a number of people using a FreeBSD machine as a gateway, dialing up with PPP, and then having problems with end to end communications because of setting the "don't fragment" bit. The -current list archives are littered with the discussion. If this is your setup, then you might want to look there. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 14:07:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25538 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:07:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25526; Thu, 11 Feb 1999 14:07:45 -0800 (PST) (envelope-from son@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.1a/8.9.1a) with ESMTP id XAA30399; Thu, 11 Feb 1999 23:07:17 +0100 (MET) Received: (from son@localhost) by teaser.fr (8.9.2/8.9.1) id WAA01533; Thu, 11 Feb 1999 22:50:37 +0100 (CET) (envelope-from son) Message-ID: <19990211225037.40571@breizh.prism.uvsq.fr> Date: Thu, 11 Feb 1999 22:50:37 +0100 From: Nicolas Souchu To: Dag-Erling Smorgrav Cc: Mike Smith , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Dag-Erling Smorgrav on Mon, Feb 08, 1999 at 10:59:57PM +0100 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 08, 1999 at 10:59:57PM +0100, Dag-Erling Smorgrav wrote: > >Nicolas Souchu writes: >> On Mon, Feb 08, 1999 at 09:25:26PM +0100, Dag-Erling Smorgrav wrote: >> > Better yet, let's rip it out of -current (I have an lpt-less src/sys >> > tree just waiting to be committed), and stick an #error in -stable's >> > lpt.c saying "This driver is deprecated, use ppbus instead". That way, >> > we give everybody advance warning without risking a botched commit >> > and/or people complaining that their kernel has inexplicably failed to >> > build. >> Ok. Is UPDATING only a -current resource or may it be updated in 3.1? > >I don't know, I was planning to just notify Warner Losh and let him >fix src/UPDATING. > >> > In any case, does anybody mind if I go ahead and remove the lpt driver >> > from -current, say, tomorrow? >> Don't forget GENERIC.. this patch or whatelse. > >Don't worry, I've patched GENERIC, LINT, files.i386 and the PicoBSD >kernels, and removed lpt.c and lpt.4. I'll still have to track down >references to the driver in the documentation though. lpt.4 also? nlpt.4 refers to it. I'll have to complete nlpt.4. Shouldn't we have moved nlpt to lpt to keep the ages dated tags? > >> "This supposes slip/ppp is statically configured for plip", would add Bruce. > >What are the consequences of just setting the interrupt mask to net in >all cases? Does one still need slip? Is it wrong to do so when plip is >not compiled in? So, you choosed 'net'. But it won't work better than 'tty' if ppp is not statically configured. And for a basic configuration, printer may not work with interrupts :( Or we should add the ppp trick as in net/ppp_tty.c. I was waiting for some new stuff for interrupt configuration to update ppc.c. -wollman was working on it in the past. I don't know if it's terminated. /* * Make sure that the soft net "engine" cannot run while spltty code is * active. The if_ppp.c code can walk down into b_to_q etc, and it is * bad if the tty system was in the middle of another b_to_q... */ tty_imask |= softnet_imask; /* spltty() block spl[soft]net() */ net_imask |= softtty_imask; /* splimp() block splsofttty() */ net_imask |= tty_imask; /* splimp() block spltty() */ update_intr_masks(); Enclosed with splhigh(). > >DES >-- >Dag-Erling Smorgrav - des@flood.ping.uio.no > -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - 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 Thu Feb 11 14:31:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28489 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:31:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28480 for ; Thu, 11 Feb 1999 14:31:11 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA12690; Thu, 11 Feb 1999 15:31:09 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd012587; Thu Feb 11 15:31:06 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA18042; Thu, 11 Feb 1999 15:30:53 -0700 (MST) From: Terry Lambert Message-Id: <199902112230.PAA18042@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 22:30:53 +0000 (GMT) Cc: tlambert@primenet.com, peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG In-Reply-To: <199902112159.NAA95236@apollo.backplane.com> from "Matthew Dillon" at Feb 11, 99 01:59:52 pm X-Mailer: ELM [version 2.4 PL25] 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 > :What about a negative initial value setting? > > What does POSIX have to say about it? Uh, it doesn't specifically disallow it. The POSIX RT stuff apparently deprecates the IPC interfaces (according to the Go Solo2 CDROM). The POSIX RT stuff doesn't allow for negative values (the semaphore value in semaphore.h is an unsigned int), but the semctl SETVAL operation does allow a negative number. In the strictest sense, I guess that my use has been deprecated: The POSIX Realtime Extension defines alternative interfaces for interprocess communication. Application developers who need to use IPC should design their applications so that modules using the IPC routines described in _IPC_ can be easily modified to use the alternative interfaces. I guess that this technically means that I should use two semaphores instead of one to implement the interlock (that's what I had to do on FreeBSD). Seems... inelegant, somehow. At the very least, it takes a lot more work to deal with client dropout. Ugh. The new interfaces aren't counting semaphores. That means that I'd need yet another semaphore to acquire the right to use the RPC mechanism. Bletcherous. Hm. On the old interfaces, there's nothing that says a negative semadj value, or one larger than sem_cnt, *isn't* allowed to happen... Go to the other (-1) example. My example is obviously abuse under the portability "should", even though it works on AIX, Solaris, SunOS, Dell UNIX, and UnixWare (they all share source code there, so that's not a surprise). If someone else is flagellating them negative, you could probably defend it not working. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 14:40:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29414 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:40:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Prime-FE2.lvcablemodem.com (prime-fe2.lvcablemodem.com [24.234.0.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA29408 for ; Thu, 11 Feb 1999 14:40:24 -0800 (PST) (envelope-from blackthorne@utah-inter.net) Received: from blackthorne - 24.234.20.200 by lvcablemodem.com with Microsoft SMTPSVC; Thu, 11 Feb 1999 14:45:11 -0800 From: "Micheal Blackthorne" To: Subject: In need of help. Stuck at "Boot:" Date: Thu, 11 Feb 1999 14:42:38 -0800 Message-ID: <000401be560f$d3c73aa0$c814ea18@blackthorne> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01BE55CC.C5A3FAA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BE55CC.C5A3FAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am very new to FreeBSD and have been trying for some time to get it working on a spare PC of mine. The problem is that it appears that I complete the installation of FreeBSD only to reboot and find myself at a "Boot:" prompt. After waiting for a few seconds at this prompt it automatically scrolls the screen displaying "Invalid Format!" and then the same information which appears to be a command options list for the "Boot:" prompt. I have already contacted freebsd-questions@FreeBSD.ORG and the individual that responded was not able to resolve the problem. He in turn suggested I contact this list. The version of FreeBSD that I am trying to install is: CD_VERSION = 3.0-19990209-STABLE I made the CD myself. Here is a list of the entire contents of the CD: Here is a list of the hardware on the system: 486 DX/2 66 Mhz 8 Megs ram 240 Meg HD 1.44 Meg 3 1/2 8x Mitsumi CD-Rom Realtek VGA 1 Meg 8019 ISA Ethernet Controller ALS120 PnP Sound Card and other minor peripherals (mouse, keyboard, etc) ------=_NextPart_000_0005_01BE55CC.C5A3FAA0 Content-Type: text/plain; name="cddir.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cddir.txt" Volume in drive F is FREEBSD =20 Volume Serial Number is E6DA-CCA3 Directory of F:\ ABOUT TXT 8,920 02-10-99 7:55p ABOUT.TXT BIN 02-11-99 7:37a bin CATPAGES 02-11-99 7:37a catpages CDROM INF 33 02-10-99 7:55p cdrom.inf COMMERCE 02-11-99 7:37a commerce COMPAT1X 02-11-99 7:37a compat1x COMPAT20 02-11-99 7:37a compat20 COMPAT21 02-11-99 7:37a compat21 DES 02-11-99 7:37a des DICT 02-11-99 7:37a dict DOC 02-11-99 7:37a doc ERRATA TXT 764 02-10-99 7:55p ERRATA.TXT FLOPPIES 02-11-99 7:37a floppies GAMES 02-11-99 7:37a games HARDWARE TXT 22,993 02-10-99 7:55p HARDWARE.TXT INFO 02-11-99 7:37a info INSTALL TXT 24,066 02-10-99 7:56p INSTALL.TXT LAYOUT TXT 4,612 02-10-99 7:56p LAYOUT.TXT MANPAGES 02-11-99 7:37a manpages PORTS 02-11-99 7:37a ports PROFLIBS 02-11-99 7:37a proflibs README TXT 4,730 02-10-99 7:56p README.TXT RELNOTES TXT 21,259 02-10-99 7:56p RELNOTES.TXT SRC 02-11-99 7:37a src TOOLS 02-11-99 7:37a tools TROUBLE TXT 16,697 02-10-99 7:56p TROUBLE.TXT UPGRADE TXT 8,055 02-10-99 7:56p UPGRADE.TXT XF86332 02-11-99 7:37a XF86332 10 file(s) 112,129 bytes Directory of F:\bin . 02-11-99 7:37a . .. 02-11-99 7:37a .. BIN AA 240,640 02-10-99 6:02p bin.aa BIN AB 240,640 02-10-99 6:02p bin.ab BIN AC 240,640 02-10-99 6:02p bin.ac BIN AD 240,640 02-10-99 6:03p bin.ad BIN AE 240,640 02-10-99 6:03p bin.ae BIN AF 240,640 02-10-99 6:03p bin.af BIN AG 240,640 02-10-99 6:03p bin.ag BIN AH 240,640 02-10-99 6:04p bin.ah BIN AI 240,640 02-10-99 6:04p bin.ai BIN AJ 240,640 02-10-99 6:04p bin.aj BIN AK 240,640 02-10-99 6:05p bin.ak BIN AL 240,640 02-10-99 6:05p bin.al BIN AM 240,640 02-10-99 6:06p bin.am BIN AN 240,640 02-10-99 6:06p bin.an BIN AO 240,640 02-10-99 6:07p bin.ao BIN AP 240,640 02-10-99 6:08p bin.ap BIN AQ 240,640 02-10-99 6:08p bin.aq BIN AR 240,640 02-10-99 6:08p bin.ar BIN AS 240,640 02-10-99 6:10p bin.as BIN AT 240,640 02-10-99 6:10p bin.at BIN AU 240,640 02-10-99 6:11p bin.au BIN AV 240,640 02-10-99 6:11p bin.av BIN AW 240,640 02-10-99 6:12p bin.aw BIN AX 240,640 02-10-99 6:13p bin.ax BIN AY 240,640 02-10-99 6:13p bin.ay BIN AZ 240,640 02-10-99 6:14p bin.az BIN BA 240,640 02-10-99 6:14p bin.ba BIN BB 240,640 02-10-99 6:15p bin.bb BIN BC 240,640 02-10-99 6:15p bin.bc BIN BD 240,640 02-10-99 6:15p bin.bd BIN BE 240,640 02-10-99 6:16p bin.be BIN BF 240,640 02-10-99 6:16p bin.bf BIN BG 240,640 02-10-99 6:16p bin.bg BIN BH 240,640 02-10-99 6:17p bin.bh BIN BI 240,640 02-10-99 6:17p bin.bi BIN BJ 240,640 02-10-99 6:17p bin.bj BIN BK 240,640 02-10-99 6:17p bin.bk BIN BL 240,640 02-10-99 6:18p bin.bl BIN BM 240,640 02-10-99 6:18p bin.bm BIN BN 240,640 02-10-99 6:18p bin.bn BIN BO 240,640 02-10-99 6:19p bin.bo BIN BP 240,640 02-10-99 6:19p bin.bp BIN BQ 240,640 02-10-99 6:19p bin.bq BIN BR 240,640 02-10-99 6:20p bin.br BIN BS 240,640 02-10-99 6:20p bin.bs BIN BT 240,640 02-10-99 6:20p bin.bt BIN BU 240,640 02-10-99 6:20p bin.bu BIN BV 240,640 02-10-99 6:21p bin.bv BIN BW 240,640 02-10-99 6:21p bin.bw BIN BX 240,640 02-10-99 6:21p bin.bx BIN BY 240,640 02-10-99 6:22p bin.by BIN BZ 240,640 02-10-99 6:22p bin.bz BIN CA 240,640 02-10-99 6:22p bin.ca BIN CB 240,640 02-10-99 6:22p bin.cb BIN CC 240,640 02-10-99 6:23p bin.cc BIN CD 240,640 02-10-99 6:23p bin.cd BIN CE 240,640 02-10-99 6:23p bin.ce BIN CF 240,640 02-10-99 6:23p bin.cf BIN CG 240,640 02-10-99 6:24p bin.cg BIN CH 240,640 02-10-99 6:24p bin.ch BIN CI 240,640 02-10-99 6:24p bin.ci BIN CJ 240,640 02-10-99 6:24p bin.cj BIN CK 240,640 02-10-99 6:25p bin.ck BIN CL 240,640 02-10-99 6:25p bin.cl BIN CM 240,640 02-10-99 6:25p bin.cm BIN CN 240,640 02-10-99 6:26p bin.cn BIN CO 240,640 02-10-99 6:26p bin.co BIN CP 240,640 02-10-99 6:26p bin.cp BIN CQ 240,640 02-10-99 6:26p bin.cq BIN CR 240,640 02-10-99 6:27p bin.cr BIN CS 240,640 02-10-99 6:27p bin.cs BIN CT 240,640 02-10-99 6:27p bin.ct BIN CU 240,640 02-10-99 6:27p bin.cu BIN CV 240,640 02-10-99 6:27p bin.cv BIN CW 240,640 02-10-99 6:28p bin.cw BIN CX 240,640 02-10-99 6:28p bin.cx BIN CY 240,640 02-10-99 6:28p bin.cy BIN CZ 240,640 02-10-99 6:28p bin.cz BIN DA 240,640 02-10-99 6:29p bin.da BIN DB 240,640 02-10-99 6:29p bin.db BIN DC 240,640 02-10-99 6:29p bin.dc BIN DD 240,640 02-10-99 6:29p bin.dd BIN DE 240,640 02-10-99 6:30p bin.de BIN DF 240,640 02-10-99 6:30p bin.df BIN DG 240,640 02-10-99 6:30p bin.dg BIN DH 240,640 02-10-99 6:31p bin.dh BIN DI 240,640 02-10-99 6:31p bin.di BIN DJ 240,640 02-10-99 6:31p bin.dj BIN DK 240,640 02-10-99 6:32p bin.dk BIN DL 240,640 02-10-99 6:32p bin.dl BIN DM 240,640 02-10-99 6:32p bin.dm BIN DN 240,640 02-10-99 6:33p bin.dn BIN DO 240,640 02-10-99 6:33p bin.do BIN DP 240,640 02-10-99 6:33p bin.dp BIN DQ 240,640 02-10-99 6:33p bin.dq BIN DR 240,640 02-10-99 6:34p bin.dr BIN DS 240,640 02-10-99 6:34p bin.ds BIN DT 240,640 02-10-99 6:34p bin.dt BIN DU 240,640 02-10-99 6:34p bin.du BIN DV 240,640 02-10-99 6:35p bin.dv BIN DW 240,640 02-10-99 6:35p bin.dw BIN DX 149,595 02-10-99 6:35p bin.dx BIN INF 2,942 02-10-99 6:35p bin.inf BIN~212 MTR 624,234 02-10-99 6:36p bin.mtree CHECKSUM MD5 5,048 02-10-99 6:36p CHECKSUM.MD5 INSTALL SH 340 02-10-99 6:36p install.sh 106 file(s) 25,086,799 bytes Directory of F:\catpages . 02-11-99 7:37a . .. 02-11-99 7:37a .. CATPAGES AA 240,640 02-10-99 6:36p catpages.aa CATPAGES AB 240,640 02-10-99 6:36p catpages.ab CATPAGES AC 240,640 02-10-99 6:37p catpages.ac CATPAGES AD 240,640 02-10-99 6:37p catpages.ad CATPAGES AE 240,640 02-10-99 6:37p catpages.ae CATPAGES AF 240,640 02-10-99 6:37p catpages.af CATPAGES AG 240,640 02-10-99 6:37p catpages.ag CATPAGES AH 240,640 02-10-99 6:37p catpages.ah CATPAGES AI 240,640 02-10-99 6:38p catpages.ai CATPAGES AJ 240,640 02-10-99 6:38p catpages.aj CATPAGES AK 240,640 02-10-99 6:38p catpages.ak CATPAGES AL 240,640 02-10-99 6:38p catpages.al CATPAGES AM 240,640 02-10-99 6:38p catpages.am CATPAGES AN 240,640 02-10-99 6:39p catpages.an CATPAGES AO 240,640 02-10-99 6:39p catpages.ao CATPAGES AP 240,640 02-10-99 6:40p catpages.ap CATPAGES AQ 71,519 02-10-99 6:40p catpages.aq CATPAGES INF 504 02-10-99 6:40p catpages.inf CATPA~42 MTR 393,603 02-10-99 6:40p catpages.mtree CHECKSUM MD5 1,063 02-10-99 6:40p CHECKSUM.MD5 INSTALL SH 158 02-10-99 6:40p install.sh 21 file(s) 4,317,087 bytes Directory of F:\commerce . 02-11-99 7:37a . .. 02-11-99 7:37a .. 3D 02-11-99 7:37a 3D AUDIO 02-11-99 7:37a audio DATABA~9 02-11-99 7:37a databases DESKTOP 02-11-99 7:37a desktop DEVEL~13 02-11-99 7:37a development EMULA~15 02-11-99 7:37a emulators GAMES 02-11-99 7:37a games GRAPHICS 02-11-99 7:37a graphics MAIL 02-11-99 7:37a mail NETWO~23 02-11-99 7:37a networking README TXT 163 02-10-99 11:31p README.TXT UTILS 02-11-99 7:37a utils X 02-11-99 7:37a X 1 file(s) 163 bytes Directory of F:\commerce\3D . 02-11-99 7:37a . .. 02-11-99 7:37a .. BLENDER 02-11-99 7:37a Blender README TXT 60 02-10-99 10:08p README.TXT 1 file(s) 60 bytes Directory of F:\commerce\3D\Blender . 02-11-99 7:37a . .. 02-11-99 7:37a .. BLACKS~6 GZ 1,241,311 02-10-99 8:10p blacksmith.tar.gz BLENDE~8 GZ 1,140,637 02-10-99 8:10p = blender1.56_SGI_5.3_iris.tar.gz BLEND~10 Z 1,686,791 02-10-99 8:10p = blender1.56_Sun_2.6_mesa.tar.Z BLEND~12 GZ 1,174,876 02-10-99 8:10p = blender1.56_SGI_5.3_ogl.tar.gz BLEND~14 GZ 1,262,484 02-10-99 8:10p = blender1.56_SGI_6.2_ogl.tar.gz BLEND~16 GZ 1,224,655 02-10-99 8:11p = blender1.56a_SGI_6.2_iris.tar.gz BLEND~18 GZ 788,640 02-10-99 8:11p = blender1.56d_BSD_i386_2.2-dyn.tar.gz BLEND~20 GZ 1,259,905 02-10-99 8:12p = blender1.56d_BSD_i386_2.2-static.tar.gz BLEND~22 GZ 991,890 02-10-99 8:12p = blender1.56d_Linux_alpha_libc6-dyn.tar.gz BLEND~24 GZ 750,753 02-10-99 8:12p = blender1.56d_Linux_i386_libc5-dyn.tar.gz BLEND~26 GZ 1,350,671 02-10-99 8:13p = blender1.56d_Linux_i386_libc5-static.tar.gz BLEND~28 GZ 729,203 02-10-99 8:13p = blender1.56e_Linux_i386_libc6-dyn.tar.gz GLASS~30 BLE 63,172 02-10-99 8:13p glass-texture.blend HALO2~32 BLE 29,756 02-10-99 8:13p halo2.blend MANUA~34 GZ 141,996 02-10-99 8:13p manual_1.02.tar.gz NEOSG~36 GZ 6,558 02-10-99 8:10p NeoSGI.ftr.tar.gz README 2,073 02-10-99 8:10p README READM~40 8,599 02-10-99 8:10p README_INSTALL RECENT DAY 782 02-10-99 8:10p RECENT.DAY RECEN~44 WEE 1,979 02-10-99 10:08p RECENT.WEEK TUTOR~46 GZ 1,068,711 02-10-99 10:08p tutor_1.01.tar.gz TUTOR~48 GZ 29,629 02-10-99 10:08p tutor_2.0.tar.gz 22 file(s) 14,955,071 bytes Directory of F:\commerce\audio . 02-11-99 7:37a . .. 02-11-99 7:37a .. OSSFRE~6 GZ 370,236 02-10-99 10:09p ossfreebsd38-beta15.tar.gz README TXT 139 02-10-99 10:09p README.TXT 2 file(s) 370,375 bytes Directory of F:\commerce\databases . 02-11-99 7:37a . .. 02-11-99 7:37a .. CBASE 02-11-99 7:37a CBase README TXT 60 02-10-99 10:10p README.TXT 1 file(s) 60 bytes Directory of F:\commerce\databases\CBase . 02-11-99 7:37a . .. 02-11-99 7:37a .. CDROM_~6 GZ 3,636,550 02-10-99 10:10p cdrom_fbsd.tar.gz README TXT 35,613 02-10-99 10:10p README.TXT 2 file(s) 3,672,163 bytes Directory of F:\commerce\desktop . 02-11-99 7:37a . .. 02-11-99 7:37a .. AXENE 02-11-99 7:37a axene README TXT 65 02-10-99 11:19p README.TXT WORDPE~7 02-11-99 7:37a WordPerfect 1 file(s) 65 bytes Directory of F:\commerce\desktop\axene . 02-11-99 7:37a . .. 02-11-99 7:37a .. AXENEI~6 1,732 02-10-99 10:13p AxeneInstall FREE 7,628 02-10-99 10:13p FREE LICENSE 15,151 02-10-99 10:13p LICENSE LICEN~12 FRE 17,223 02-10-99 10:13p LICENSE.French ORDER 20,581 02-10-99 10:13p ORDER PACKAGES 02-11-99 7:37a Packages README 15,169 02-10-99 10:13p README RECENT DAY 704 02-10-99 10:13p RECENT.DAY RECEN~22 WEE 5,640 02-10-99 10:13p RECENT.WEEK 8 file(s) 83,828 bytes Directory of F:\commerce\desktop\axene\Packages . 02-11-99 7:37a . .. 02-11-99 7:37a .. AXENEO~6 GZ 449,706 02-10-99 10:10p = AxeneOffice-v120.i386-freebsd-2.2.tar.gz COMMON~8 GZ 1,080,897 02-10-99 10:10p common.tar.gz DOCXA~10 GZ 28,105 02-10-99 10:10p = Doc.XAllWrite-v10x.English.tar.gz DOCXA~12 GZ 32,021 02-10-99 10:10p = Doc.XAllWrite-v10x.French.tar.gz DOCXC~14 GZ 807,663 02-10-99 10:11p = Doc.Xclamation-v14x.French.tar.gz DOCXM~16 GZ 177,945 02-10-99 10:11p = Doc.XMayday-v12x.English.tar.gz DOCXM~18 GZ 200,528 02-10-99 10:11p = Doc.XMayday-v12x.French.tar.gz DOCXQ~20 GZ 1,052,721 02-10-99 10:11p Doc.XQuad-v14x.French.tar.gz INSTALL SH 43,238 02-10-99 10:11p install.sh XALLW~24 GZ 779,943 02-10-99 10:11p = XAllWrite-v103beta.i386-freebsd-2.2.tar.gz XCLAM~26 GZ 1,087,860 02-10-99 10:12p = Xclamation-v143.i386-freebsd-2.2.tar.gz XINST~28 2 1,540,096 02-10-99 10:12p = XInstall-v112.i386-freebsd-2.2 XMAYD~30 GZ 762,271 02-10-99 10:13p = XMayday-v123.i386-freebsd-2.2.tar.gz XQUAD~32 GZ 1,391,476 02-10-99 10:13p = XQuad-v143.i386-freebsd-2.2.tar.gz 14 file(s) 9,434,470 bytes Directory of F:\commerce\desktop\WordPerfect . 02-11-99 7:37a . .. 02-11-99 7:37a .. GRAPHI~6 GZ 87,087 02-10-99 10:13p graphics.tar.gz LINUX TXT 2,805 02-10-99 10:13p linux.txt LINUX~10 GZ 9,890,346 02-10-99 10:17p linuxceg.tar.gz LINUX~12 GZ 13,717,327 02-10-99 10:22p linuxcfg.tar.gz LINUX~14 GZ 9,723,779 02-10-99 10:26p linuxdeg.tar.gz LINUX~16 GZ 38,511,423 02-10-99 10:39p linuxesg.tar.gz LINUX~18 GZ 9,688,172 02-10-99 10:43p linuxfrg.tar.gz LINUX~20 GZ 38,665,628 02-10-99 10:58p linuxgui.tar.gz LINUX~22 GZ 9,750,176 02-10-99 11:01p linuxitg.tar.gz LINUX~24 GZ 9,642,965 02-10-99 11:04p linuxnlg.tar.gz LINUX~26 GZ 13,934,496 02-10-99 11:09p linuxozg.tar.gz LINUX~28 GZ 9,771,571 02-10-99 11:12p linuxukg.tar.gz MANUA~30 GZ 18,647,006 02-10-99 11:19p manual.tar.gz SDKTA~32 GZ 736,720 02-10-99 11:19p sdk.tar.gz 14 file(s) 182,769,501 bytes Directory of F:\commerce\development . 02-11-99 7:37a . .. 02-11-99 7:37a .. HORUS 02-11-99 7:37a HORUS MOCKA 02-11-99 7:37a MOCKA P4 02-11-99 7:37a p4 README TXT 199 02-10-99 11:23p README.TXT 1 file(s) 199 bytes Directory of F:\commerce\development\HORUS . 02-11-99 7:37a . .. 02-11-99 7:37a .. HORUS-~6 GZ 7,468,302 02-10-99 11:22p horus-demo.tar.gz HORUS-~8 GZ 50,168 02-10-99 11:22p horus-readme.tar.gz README TXT 30,566 02-10-99 11:22p README.TXT 3 file(s) 7,549,036 bytes Directory of F:\commerce\development\MOCKA . 02-11-99 7:37a . .. 02-11-99 7:37a .. MOCKA9~6 GZ 344,271 02-10-99 11:22p mocka9502main.tar.gz MOCKA9~8 GZ 246,116 02-10-99 11:22p mocka9502src.tar.gz README TXT 2,542 02-10-99 11:22p README.TXT 3 file(s) 592,929 bytes Directory of F:\commerce\development\p4 . 02-11-99 7:37a . .. 02-11-99 7:37a .. P4 204,800 02-10-99 11:22p p4 P4D 512,000 02-10-99 11:23p p4d README TXT 1,054 02-10-99 11:23p README.TXT 3 file(s) 717,854 bytes Directory of F:\commerce\emulators . 02-11-99 7:37a . .. 02-11-99 7:37a .. EXECUTOR 02-11-99 7:37a executor README TXT 111 02-10-99 11:24p README.TXT 1 file(s) 111 bytes Directory of F:\commerce\emulators\executor . 02-11-99 7:37a . .. 02-11-99 7:37a .. EXECUT~6 GZ 1,212,035 02-10-99 11:23p executor-aout-demo.tar.gz EXECUT~8 GZ 1,719,008 02-10-99 11:23p executor-common.tar.gz EXECU~10 GZ 1,101,363 02-10-99 11:24p executor-elf-demo.tar.gz INSTA~12 2,100 02-10-99 11:24p install_demo README TXT 499 02-10-99 11:24p README.TXT 5 file(s) 4,035,005 bytes Directory of F:\commerce\games . 02-11-99 7:37a . .. 02-11-99 7:37a .. PHOST 02-11-99 7:37a phost README TXT 126 02-10-99 11:24p README.TXT SIMCITY 02-11-99 7:37a SimCity 1 file(s) 126 bytes Directory of F:\commerce\games\phost . 02-11-99 7:37a . .. 02-11-99 7:37a .. PHOSTV~6 GZ 648,193 02-10-99 11:24p phostv2.9.tar.gz README TXT 14,058 02-10-99 11:24p README.TXT 2 file(s) 662,251 bytes Directory of F:\commerce\games\SimCity . 02-11-99 7:37a . .. 02-11-99 7:37a .. README TXT 1,374 02-10-99 11:24p README.TXT SIMCIT~8 TGZ 1,014,868 02-10-99 11:24p SimCity-3.6b.tgz 2 file(s) 1,016,242 bytes Directory of F:\commerce\graphics . 02-11-99 7:37a . .. 02-11-99 7:37a .. DISLIN~6 GZ 3,228,995 02-10-99 11:25p dislin_fbsd.63.tar.gz README TXT 4,547 02-10-99 11:25p README.TXT 2 file(s) 3,233,542 bytes Directory of F:\commerce\mail . 02-11-99 7:37a . .. 02-11-99 7:37a .. CGATEPRO 02-11-99 7:37a cgatepro 0 file(s) 0 bytes Directory of F:\commerce\mail\cgatepro . 02-11-99 7:37a . .. 02-11-99 7:37a .. CGATEP~6 TGZ 449,934 02-10-99 11:26p = CGatePro-FreeBSD-Intel-26.tgz README TXT 1,142 02-10-99 11:26p README.TXT 2 file(s) 451,076 bytes Directory of F:\commerce\networking . 02-11-99 7:37a . .. 02-11-99 7:37a .. DNEWS 02-11-99 7:37a dnews ETINC 02-11-99 7:37a etinc LEGATO 02-11-99 7:37a legato NETTR~11 02-11-99 7:37a NetTracker README TXT 138 02-10-99 11:27p README.TXT 1 file(s) 138 bytes Directory of F:\commerce\networking\dnews . 02-11-99 7:37a . .. 02-11-99 7:37a .. DNEWS-~6 TGZ 237,749 02-10-99 11:26p dnews-27q.tgz DNEWS2~8 Z 463,806 02-10-99 11:26p dnews27q_freebsd.tar.Z LICENSE TXT 584 02-10-99 11:26p LICENSE.TXT README TXT 3,291 02-10-99 11:26p README.TXT 4 file(s) 705,430 bytes Directory of F:\commerce\networking\etinc . 02-11-99 7:37a . .. 02-11-99 7:37a .. BWMGR TAR 286,720 02-10-99 11:26p bwmgr.tar README TXT 1,515 02-10-99 11:26p README.TXT 2 file(s) 288,235 bytes Directory of F:\commerce\networking\legato . 02-11-99 7:37a . .. 02-11-99 7:37a .. FREEBS~6 GZ 2,795,466 02-10-99 11:27p freebsd2.tar.gz README TXT 76 02-10-99 11:27p README.TXT 2 file(s) 2,795,542 bytes Directory of F:\commerce\networking\NetTracker . 02-11-99 7:37a . .. 02-11-99 7:37a .. N3P-FB~6 Z 1,040,025 02-10-99 11:27p n3p-fbsd.tar.Z README TXT 1,152 02-10-99 11:27p README.TXT 2 file(s) 1,041,177 bytes Directory of F:\commerce\utils . 02-11-99 7:37a . .. 02-11-99 7:37a .. README TXT 40 02-10-99 11:27p README.TXT VSH35B 02-11-99 7:37a vsh35b 1 file(s) 40 bytes Directory of F:\commerce\utils\vsh35b . 02-11-99 7:37a . .. 02-11-99 7:37a .. README TXT 6,211 02-10-99 11:27p README.TXT VSH MAN 59,369 02-10-99 11:27p vsh.man VSH PS 228,659 02-10-99 11:27p vsh.ps VSH-D~12 77,824 02-10-99 11:27p vsh-dynamic VSH-S~14 266,240 02-10-99 11:27p vsh-static 5 file(s) 638,303 bytes Directory of F:\commerce\X . 02-11-99 7:37a . .. 02-11-99 7:37a .. README TXT 143 02-10-99 11:31p README.TXT UNIXCO~5 02-11-99 7:37a UnixCockpit XACCEL 02-11-99 7:37a Xaccel 1 file(s) 143 bytes Directory of F:\commerce\X\UnixCockpit . 02-11-99 7:37a . .. 02-11-99 7:37a .. README TXT 794 02-10-99 11:27p README.TXT UC 1,011,712 02-10-99 11:28p uc UC-BS~10 GZ 449,774 02-10-99 11:28p uc-bsd2.2-v2.0.gz UC-DY~12 688,128 02-10-99 11:28p uc-dynamic 4 file(s) 2,150,408 bytes Directory of F:\commerce\X\Xaccel . 02-11-99 7:37a . .. 02-11-99 7:37a .. AX412T~6 GZ 4,221,479 02-10-99 11:29p AX412.tar.gz LX412T~8 GZ 3,677,067 02-10-99 11:31p LX412.tar.gz README TXT 7,260 02-10-99 11:31p README.TXT 3 file(s) 7,905,806 bytes Directory of F:\compat1x . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 321 02-10-99 6:40p CHECKSUM.MD5 COMPAT1X AA 240,640 02-10-99 6:40p compat1x.aa COMPAT1X AB 240,640 02-10-99 6:40p compat1x.ab COMPAT1X AC 53,618 02-10-99 6:40p compat1x.ac COMPAT1X INF 94 02-10-99 6:40p compat1x.inf COMPA~16 MTR 3,235 02-10-99 6:40p compat1x.mtree INSTALL SH 158 02-10-99 6:40p install.sh 7 file(s) 538,706 bytes Directory of F:\compat20 . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 268 02-10-99 6:41p CHECKSUM.MD5 COMPAT20 AA 240,640 02-10-99 6:41p compat20.aa COMPAT20 AB 65,212 02-10-99 6:41p compat20.ab COMPAT20 INF 69 02-10-99 6:41p compat20.inf COMPA~14 MTR 1,409 02-10-99 6:41p compat20.mtree INSTALL SH 158 02-10-99 6:41p install.sh 6 file(s) 307,756 bytes Directory of F:\compat21 . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 268 02-10-99 6:41p CHECKSUM.MD5 COMPAT21 AA 240,640 02-10-99 6:41p compat21.aa COMPAT21 AB 176,809 02-10-99 6:41p compat21.ab COMPAT21 INF 70 02-10-99 6:41p compat21.inf COMPA~14 MTR 941 02-10-99 6:41p compat21.mtree INSTALL SH 158 02-10-99 6:41p install.sh 6 file(s) 418,886 bytes Directory of F:\des . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 340 02-10-99 6:42p CHECKSUM.MD5 DES AA 240,640 02-10-99 6:42p des.aa DES AB 157,466 02-10-99 6:42p des.ab DES INF 70 02-10-99 6:42p des.inf DES~14 MTR 9,869 02-10-99 6:42p des.mtree INSTALL SH 700 02-10-99 6:42p install.sh KRB AA 240,640 02-10-99 6:43p krb.aa KRB AB 240,640 02-10-99 6:43p krb.ab KRB AC 240,640 02-10-99 6:43p krb.ac KRB AD 240,640 02-10-99 6:44p krb.ad KRB AE 90,238 02-10-99 6:44p krb.ae KRB INF 155 02-10-99 6:44p krb.inf KRB~30 MTR 21,703 02-10-99 6:44p krb.mtree SCRYPTO AA 240,640 02-10-99 6:44p scrypto.aa SCRYPTO AB 240,640 02-10-99 6:44p scrypto.ab SCRYPTO AC 189,212 02-10-99 6:45p scrypto.ac SCRYPTO INF 99 02-10-99 6:45p scrypto.inf SKERBERO AA 12,189 02-10-99 6:45p skerbero.aa SKERBERO INF 40 02-10-99 6:45p skerbero.inf SSECURE AA 163,869 02-10-99 6:45p ssecure.aa SSECURE INF 40 02-10-99 6:45p ssecure.inf 21 file(s) 2,330,470 bytes Directory of F:\dict . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 399 02-10-99 6:45p CHECKSUM.MD5 DICT AA 240,640 02-10-99 6:45p dict.aa DICT AB 240,640 02-10-99 6:45p dict.ab DICT AC 240,640 02-10-99 6:45p dict.ac DICT AD 240,640 02-10-99 6:46p dict.ad DICT AE 136,310 02-10-99 6:46p dict.ae DICT INF 156 02-10-99 6:46p dict.inf DICT~20 MTR 1,789 02-10-99 6:46p dict.mtree INSTALL SH 154 02-10-99 6:46p install.sh 9 file(s) 1,101,368 bytes Directory of F:\doc . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 440 02-10-99 6:46p CHECKSUM.MD5 DOC AA 240,640 02-10-99 6:46p doc.aa DOC AB 240,640 02-10-99 6:47p doc.ab DOC AC 240,640 02-10-99 6:47p doc.ac DOC AD 240,640 02-10-99 6:47p doc.ad DOC AE 240,640 02-10-99 6:48p doc.ae DOC AF 89,386 02-10-99 6:48p doc.af DOC INF 180 02-10-99 6:48p doc.inf DOC~22 MTR 20,113 02-10-99 6:48p doc.mtree INSTALL SH 337 02-10-99 6:48p install.sh 10 file(s) 1,313,656 bytes Directory of F:\floppies . 02-11-99 7:37a . .. 02-11-99 7:37a .. BOOT FLP 2,949,120 02-10-99 6:51p boot.flp CHECKSUM MD5 256 02-10-99 6:51p CHECKSUM.MD5 FIXIT FLP 1,474,560 02-10-99 6:53p fixit.flp KERN FLP 1,474,560 02-10-99 6:56p kern.flp MFSROOT FLP 1,474,560 02-10-99 6:57p mfsroot.flp README TXT 2,689 02-10-99 6:57p README.TXT 6 file(s) 7,375,745 bytes Directory of F:\games . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 656 02-10-99 6:57p CHECKSUM.MD5 GAMES AA 240,640 02-10-99 6:57p games.aa GAMES AB 240,640 02-10-99 6:57p games.ab GAMES AC 240,640 02-10-99 6:58p games.ac GAMES AD 240,640 02-10-99 6:58p games.ad GAMES AE 240,640 02-10-99 6:58p games.ae GAMES AF 240,640 02-10-99 6:58p games.af GAMES AG 240,640 02-10-99 6:59p games.ag GAMES AH 240,640 02-10-99 6:59p games.ah GAMES AI 240,640 02-10-99 6:59p games.ai GAMES AJ 220,166 02-10-99 6:59p games.aj GAMES INF 302 02-10-99 6:59p games.inf GAMES~30 MTR 32,303 02-10-99 7:00p games.mtree INSTALL SH 155 02-10-99 7:00p install.sh 14 file(s) 2,419,342 bytes Directory of F:\info . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 546 02-10-99 7:00p CHECKSUM.MD5 INFO AA 240,640 02-10-99 7:00p info.aa INFO AB 240,640 02-10-99 7:00p info.ab INFO AC 240,640 02-10-99 7:00p info.ac INFO AD 240,640 02-10-99 7:00p info.ad INFO AE 240,640 02-10-99 7:01p info.ae INFO AF 240,640 02-10-99 7:01p info.af INFO AG 240,640 02-10-99 7:01p info.ag INFO AH 15,268 02-10-99 7:01p info.ah INFO INF 241 02-10-99 7:01p info.inf INFO~26 MTR 4,833 02-10-99 7:01p info.mtree INSTALL SH 154 02-10-99 7:01p install.sh 12 file(s) 1,705,522 bytes Directory of F:\manpages . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 1,222 02-10-99 7:01p CHECKSUM.MD5 INSTALL SH 158 02-10-99 7:02p install.sh MANPAGES AA 240,640 02-10-99 7:02p manpages.aa MANPAGES AB 240,640 02-10-99 7:02p manpages.ab MANPAGES AC 240,640 02-10-99 7:02p manpages.ac MANPAGES AD 240,640 02-10-99 7:03p manpages.ad MANPAGES AE 240,640 02-10-99 7:03p manpages.ae MANPAGES AF 240,640 02-10-99 7:03p manpages.af MANPAGES AG 240,640 02-10-99 7:05p manpages.ag MANPAGES AH 240,640 02-10-99 7:05p manpages.ah MANPAGES AI 240,640 02-10-99 7:05p manpages.ai MANPAGES AJ 240,640 02-10-99 7:05p manpages.aj MANPAGES AK 240,640 02-10-99 7:05p manpages.ak MANPAGES AL 240,640 02-10-99 7:06p manpages.al MANPAGES AM 240,640 02-10-99 7:06p manpages.am MANPAGES AN 240,640 02-10-99 7:06p manpages.an MANPAGES AO 240,640 02-10-99 7:06p manpages.ao MANPAGES AP 240,640 02-10-99 7:07p manpages.ap MANPAGES AQ 240,640 02-10-99 7:07p manpages.aq MANPAGES AR 240,640 02-10-99 7:07p manpages.ar MANPAGES AS 240,640 02-10-99 7:08p manpages.as MANPAGES AT 157,437 02-10-99 7:08p manpages.at MANPAGES INF 587 02-10-99 7:08p manpages.inf MANPA~52 MTR 407,034 02-10-99 7:08p manpages.mtree 24 file(s) 5,138,598 bytes Directory of F:\ports . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 103 02-10-99 7:08p CHECKSUM.MD5 INSTALL SH 209 02-10-99 7:08p install.sh PORTS TGZ 7,553,920 02-10-99 7:19p ports.tgz 3 file(s) 7,554,232 bytes Directory of F:\proflibs . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 586 02-10-99 7:19p CHECKSUM.MD5 INSTALL SH 158 02-10-99 7:19p install.sh PROFLIBS AA 240,640 02-10-99 7:19p proflibs.aa PROFLIBS AB 240,640 02-10-99 7:19p proflibs.ab PROFLIBS AC 240,640 02-10-99 7:19p proflibs.ac PROFLIBS AD 240,640 02-10-99 7:19p proflibs.ad PROFLIBS AE 240,640 02-10-99 7:19p proflibs.ae PROFLIBS AF 240,640 02-10-99 7:20p proflibs.af PROFLIBS AG 240,640 02-10-99 7:20p proflibs.ag PROFLIBS AH 220,218 02-10-99 7:20p proflibs.ah PROFLIBS INF 241 02-10-99 7:20p proflibs.inf PROFL~28 MTR 6,212 02-10-99 7:20p proflibs.mtree 12 file(s) 1,911,895 bytes Directory of F:\src . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 12,009 02-10-99 7:20p CHECKSUM.MD5 INSTALL SH 760 02-10-99 7:20p install.sh SBASE AA 17,063 02-10-99 7:20p sbase.aa SBASE INF 40 02-10-99 7:20p sbase.inf SBIN AA 240,640 02-10-99 7:20p sbin.aa SBIN AB 240,640 02-10-99 7:20p sbin.ab SBIN AC 81,828 02-10-99 7:20p sbin.ac SBIN INF 98 02-10-99 7:20p sbin.inf SCONTRIB AA 240,640 02-10-99 7:21p scontrib.aa SCONTRIB AB 240,640 02-10-99 7:21p scontrib.ab SCONTRIB AC 240,640 02-10-99 7:21p scontrib.ac SCONTRIB AD 240,640 02-10-99 7:21p scontrib.ad SCONTRIB AE 240,640 02-10-99 7:21p scontrib.ae SCONTRIB AF 240,640 02-10-99 7:21p scontrib.af SCONTRIB AG 240,640 02-10-99 7:21p scontrib.ag SCONTRIB AH 240,640 02-10-99 7:22p scontrib.ah SCONTRIB AI 240,640 02-10-99 7:22p scontrib.ai SCONTRIB AJ 240,640 02-10-99 7:22p scontrib.aj SCONTRIB AK 240,640 02-10-99 7:22p scontrib.ak SCONTRIB AL 240,640 02-10-99 7:22p scontrib.al SCONTRIB AM 240,640 02-10-99 7:22p scontrib.am SCONTRIB AN 240,640 02-10-99 7:23p scontrib.an SCONTRIB AO 240,640 02-10-99 7:23p scontrib.ao SCONTRIB AP 240,640 02-10-99 7:23p scontrib.ap SCONTRIB AQ 240,640 02-10-99 7:23p scontrib.aq SCONTRIB AR 240,640 02-10-99 7:23p scontrib.ar SCONTRIB AS 240,640 02-10-99 7:23p scontrib.as SCONTRIB AT 240,640 02-10-99 7:24p scontrib.at SCONTRIB AU 240,640 02-10-99 7:24p scontrib.au SCONTRIB AV 240,640 02-10-99 7:24p scontrib.av SCONTRIB AW 240,640 02-10-99 7:24p scontrib.aw SCONTRIB AX 240,640 02-10-99 7:24p scontrib.ax SCONTRIB AY 240,640 02-10-99 7:24p scontrib.ay SCONTRIB AZ 240,640 02-10-99 7:24p scontrib.az SCONTRIB BA 240,640 02-10-99 7:25p scontrib.ba SCONTRIB BB 240,640 02-10-99 7:25p scontrib.bb SCONTRIB BC 240,640 02-10-99 7:25p scontrib.bc SCONTRIB BD 240,640 02-10-99 7:25p scontrib.bd SCONTRIB BE 240,640 02-10-99 7:25p scontrib.be SCONTRIB BF 240,640 02-10-99 7:25p scontrib.bf SCONTRIB BG 240,640 02-10-99 7:25p scontrib.bg SCONTRIB BH 240,640 02-10-99 7:26p scontrib.bh SCONTRIB BI 240,640 02-10-99 7:26p scontrib.bi SCONTRIB BJ 240,640 02-10-99 7:26p scontrib.bj SCONTRIB BK 240,640 02-10-99 7:26p scontrib.bk SCONTRIB BL 240,640 02-10-99 7:26p scontrib.bl SCONTRIB BM 240,640 02-10-99 7:26p scontrib.bm SCONTRIB BN 240,640 02-10-99 7:27p scontrib.bn SCONTRIB BO 240,640 02-10-99 7:27p scontrib.bo SCONTRIB BP 240,640 02-10-99 7:27p scontrib.bp SCONTRIB BQ 240,640 02-10-99 7:27p scontrib.bq SCONTRIB BR 240,640 02-10-99 7:27p scontrib.br SCONTRIB BS 240,640 02-10-99 7:27p scontrib.bs SCONTRIB BT 240,640 02-10-99 7:27p scontrib.bt SCONTRIB BU 240,640 02-10-99 7:27p scontrib.bu SCONTRIB BV 240,640 02-10-99 7:28p scontrib.bv SCONTRIB BW 240,640 02-10-99 7:28p scontrib.bw SCONTRIB BX 240,640 02-10-99 7:28p scontrib.bx SCONTRIB BY 240,640 02-10-99 7:28p scontrib.by SCONTRIB BZ 240,640 02-10-99 7:28p scontrib.bz SCONTRIB CA 240,640 02-10-99 7:28p scontrib.ca SCONTRIB CB 240,640 02-10-99 7:28p scontrib.cb SCONTRIB CC 240,640 02-10-99 7:29p scontrib.cc SCONTRIB CD 240,640 02-10-99 7:29p scontrib.cd SCONTRIB CE 240,640 02-10-99 7:29p scontrib.ce SCONTRIB CF 240,640 02-10-99 7:29p scontrib.cf SCONTRIB CG 240,640 02-10-99 7:29p scontrib.cg SCONTRIB CH 240,640 02-10-99 7:29p scontrib.ch SCONTRIB CI 240,640 02-10-99 7:30p scontrib.ci SCONTRIB CJ 240,640 02-10-99 7:30p scontrib.cj SCONTRIB CK 240,640 02-10-99 7:30p scontrib.ck SCONTRIB CL 240,640 02-10-99 7:30p scontrib.cl SCONTRIB CM 240,640 02-10-99 7:30p scontrib.cm SCONTRIB CN 240,640 02-10-99 7:30p scontrib.cn SCONTRIB CO 240,640 02-10-99 7:31p scontrib.co SCONTRIB CP 240,640 02-10-99 7:31p scontrib.cp SCONTRIB CQ 240,640 02-10-99 7:31p scontrib.cq SCONTRIB CR 240,640 02-10-99 7:31p scontrib.cr SCONTRIB CS 240,640 02-10-99 7:31p scontrib.cs SCONTRIB CT 240,640 02-10-99 7:31p scontrib.ct SCONTRIB CU 240,640 02-10-99 7:31p scontrib.cu SCONTRIB CV 240,640 02-10-99 7:32p scontrib.cv SCONTRIB CW 240,640 02-10-99 7:32p scontrib.cw SCONTRIB CX 240,640 02-10-99 7:33p scontrib.cx SCONTRIB CY 240,640 02-10-99 7:33p scontrib.cy SCONTRIB CZ 240,640 02-10-99 7:34p scontrib.cz SCONTRIB DA 240,640 02-10-99 7:34p scontrib.da SCONTRIB DB 240,640 02-10-99 7:34p scontrib.db SCONTRIB DC 240,640 02-10-99 7:34p scontrib.dc SCONTRIB DD 240,640 02-10-99 7:34p scontrib.dd SCONTRIB DE 240,640 02-10-99 7:34p scontrib.de SCONTRIB DF 240,640 02-10-99 7:35p scontrib.df SCONTRIB DG 240,640 02-10-99 7:35p scontrib.dg SCONTRIB DH 240,640 02-10-99 7:35p scontrib.dh SCONTRIB DI 240,640 02-10-99 7:35p scontrib.di SCONTRIB DJ 240,640 02-10-99 7:35p scontrib.dj SCONTRIB DK 37,372 02-10-99 7:35p scontrib.dk SCONTRIB INF 2,572 02-10-99 7:35p scontrib.inf SETC AA 120,731 02-10-99 7:35p setc.aa SETC INF 40 02-10-99 7:35p setc.inf SGAMES AA 240,640 02-10-99 7:36p sgames.aa SGAMES AB 240,640 02-10-99 7:36p sgames.ab SGAMES AC 240,640 02-10-99 7:36p sgames.ac SGAMES AD 240,640 02-10-99 7:36p sgames.ad SGAMES AE 240,640 02-10-99 7:36p sgames.ae SGAMES AF 240,640 02-10-99 7:36p sgames.af SGAMES AG 240,640 02-10-99 7:36p sgames.ag SGAMES AH 240,640 02-10-99 7:37p sgames.ah SGAMES AI 240,640 02-10-99 7:37p sgames.ai SGAMES AJ 240,640 02-10-99 7:37p sgames.aj SGAMES AK 16,137 02-10-99 7:37p sgames.ak SGAMES INF 326 02-10-99 7:37p sgames.inf SGNU AA 240,640 02-10-99 7:37p sgnu.aa SGNU AB 240,640 02-10-99 7:37p sgnu.ab SGNU AC 240,640 02-10-99 7:38p sgnu.ac SGNU AD 240,640 02-10-99 7:38p sgnu.ad SGNU AE 240,640 02-10-99 7:38p sgnu.ae SGNU AF 240,640 02-10-99 7:38p sgnu.af SGNU AG 240,640 02-10-99 7:38p sgnu.ag SGNU AH 240,640 02-10-99 7:38p sgnu.ah SGNU AI 240,640 02-10-99 7:39p sgnu.ai SGNU AJ 240,640 02-10-99 7:39p sgnu.aj SGNU AK 223,103 02-10-99 7:39p sgnu.ak SGNU INF 331 02-10-99 7:39p sgnu.inf SINCLUDE AA 126,286 02-10-99 7:39p sinclude.aa SINCLUDE INF 41 02-10-99 7:39p sinclude.inf SLIB AA 240,640 02-10-99 7:39p slib.aa SLIB AB 240,640 02-10-99 7:40p slib.ab SLIB AC 240,640 02-10-99 7:40p slib.ac SLIB AD 240,640 02-10-99 7:40p slib.ad SLIB AE 240,640 02-10-99 7:40p slib.ae SLIB AF 240,640 02-10-99 7:40p slib.af SLIB AG 240,640 02-10-99 7:41p slib.ag SLIB AH 240,640 02-10-99 7:41p slib.ah SLIB AI 240,640 02-10-99 7:41p slib.ai SLIB AJ 240,640 02-10-99 7:41p slib.aj SLIB AK 240,640 02-10-99 7:41p slib.ak SLIB AL 240,640 02-10-99 7:41p slib.al SLIB AM 240,640 02-10-99 7:42p slib.am SLIB AN 240,640 02-10-99 7:42p slib.an SLIB AO 240,640 02-10-99 7:42p slib.ao SLIB AP 23,825 02-10-99 7:42p slib.ap SLIB INF 475 02-10-99 7:42p slib.inf SLIBEXEC AA 240,640 02-10-99 7:42p slibexec.aa SLIBEXEC AB 131,683 02-10-99 7:42p slibexec.ab SLIBEXEC INF 70 02-10-99 7:42p slibexec.inf SRELEASE AA 240,640 02-10-99 7:43p srelease.aa SRELEASE AB 240,640 02-10-99 7:43p srelease.ab SRELEASE AC 50,182 02-10-99 7:43p srelease.ac SRELEASE INF 96 02-10-99 7:43p srelease.inf SSBIN AA 240,640 02-10-99 7:43p ssbin.aa SSBIN AB 240,640 02-10-99 7:43p ssbin.ab SSBIN AC 172,650 02-10-99 7:43p ssbin.ac SSBIN INF 97 02-10-99 7:43p ssbin.inf SSHARE AA 240,640 02-10-99 7:43p sshare.aa SSHARE AB 240,640 02-10-99 7:44p sshare.ab SSHARE AC 240,640 02-10-99 7:44p sshare.ac SSHARE AD 240,640 02-10-99 7:44p sshare.ad SSHARE AE 240,640 02-10-99 7:44p sshare.ae SSHARE AF 240,640 02-10-99 7:44p sshare.af SSHARE AG 240,640 02-10-99 7:45p sshare.ag SSHARE AH 240,640 02-10-99 7:45p sshare.ah SSHARE AI 240,640 02-10-99 7:45p sshare.ai SSHARE AJ 240,640 02-10-99 7:45p sshare.aj SSHARE AK 240,640 02-10-99 7:45p sshare.ak SSHARE AL 36,414 02-10-99 7:45p sshare.al SSHARE INF 356 02-10-99 7:45p sshare.inf SSYS AA 240,640 02-10-99 7:46p ssys.aa SSYS AB 240,640 02-10-99 7:46p ssys.ab SSYS AC 240,640 02-10-99 7:46p ssys.ac SSYS AD 240,640 02-10-99 7:46p ssys.ad SSYS AE 240,640 02-10-99 7:46p ssys.ae SSYS AF 240,640 02-10-99 7:46p ssys.af SSYS AG 240,640 02-10-99 7:47p ssys.ag SSYS AH 240,640 02-10-99 7:47p ssys.ah SSYS AI 240,640 02-10-99 7:47p ssys.ai SSYS AJ 240,640 02-10-99 7:47p ssys.aj SSYS AK 240,640 02-10-99 7:47p ssys.ak SSYS AL 240,640 02-10-99 7:47p ssys.al SSYS AM 240,640 02-10-99 7:48p ssys.am SSYS AN 240,640 02-10-99 7:48p ssys.an SSYS AO 240,640 02-10-99 7:48p ssys.ao SSYS AP 240,640 02-10-99 7:48p ssys.ap SSYS AQ 240,640 02-10-99 7:48p ssys.aq SSYS AR 240,640 02-10-99 7:48p ssys.ar SSYS AS 240,640 02-10-99 7:49p ssys.as SSYS AT 240,640 02-10-99 7:49p ssys.at SSYS AU 240,640 02-10-99 7:49p ssys.au SSYS AV 240,640 02-10-99 7:49p ssys.av SSYS AW 240,640 02-10-99 7:49p ssys.aw SSYS AX 240,640 02-10-99 7:50p ssys.ax SSYS AY 240,640 02-10-99 7:50p ssys.ay SSYS AZ 240,640 02-10-99 7:50p ssys.az SSYS BA 240,640 02-10-99 7:50p ssys.ba SSYS BB 240,640 02-10-99 7:51p ssys.bb SSYS BC 240,640 02-10-99 7:51p ssys.bc SSYS BD 240,640 02-10-99 7:51p ssys.bd SSYS BE 76,362 02-10-99 7:51p ssys.be SSYS INF 900 02-10-99 7:51p ssys.inf STOOLS AA 36,073 02-10-99 7:51p stools.aa STOOLS INF 39 02-10-99 7:51p stools.inf SUBIN AA 240,640 02-10-99 7:51p subin.aa SUBIN AB 240,640 02-10-99 7:52p subin.ab SUBIN AC 240,640 02-10-99 7:52p subin.ac SUBIN AD 240,640 02-10-99 7:52p subin.ad SUBIN AE 240,640 02-10-99 7:52p subin.ae SUBIN AF 240,640 02-10-99 7:52p subin.af SUBIN AG 240,640 02-10-99 7:52p subin.ag SUBIN AH 240,640 02-10-99 7:53p subin.ah SUBIN AI 240,640 02-10-99 7:53p subin.ai SUBIN AJ 240,640 02-10-99 7:53p subin.aj SUBIN AK 240,640 02-10-99 7:53p subin.ak SUBIN AL 61,683 02-10-99 7:53p subin.al SUBIN INF 358 02-10-99 7:53p subin.inf SUSBIN AA 240,640 02-10-99 7:53p susbin.aa SUSBIN AB 240,640 02-10-99 7:54p susbin.ab SUSBIN AC 240,640 02-10-99 7:54p susbin.ac SUSBIN AD 240,640 02-10-99 7:54p susbin.ad SUSBIN AE 240,640 02-10-99 7:54p susbin.ae SUSBIN AF 240,640 02-10-99 7:54p susbin.af SUSBIN AG 240,640 02-10-99 7:54p susbin.ag SUSBIN AH 240,640 02-10-99 7:55p susbin.ah SUSBIN AI 240,640 02-10-99 7:55p susbin.ai SUSBIN AJ 240,640 02-10-99 7:55p susbin.aj SUSBIN AK 240,640 02-10-99 7:55p susbin.ak SUSBIN AL 141,809 02-10-99 7:55p susbin.al SUSBIN INF 356 02-10-99 7:55p susbin.inf 227 file(s) 47,815,685 bytes Directory of F:\tools . 02-11-99 7:37a . .. 02-11-99 7:37a .. 00_INDEX TXT 854 02-10-99 9:41p 00_index.txt BOOT BIN 512 02-10-99 9:41p boot.bin BOOTINST EXE 12,092 02-10-99 9:41p bootinst.exe CKDIST EXE 30,011 02-10-99 9:41p ckdist.exe CKDIST MAN 2,792 02-10-99 9:41p ckdist.man DIST 02-11-99 7:37a dist EXTIPL EXE 13,566 02-10-99 9:41p extipl.exe FBSDBOOT EXE 22,487 02-10-99 9:41p fbsdboot.exe FDIMAGE EXE 17,728 02-10-99 9:41p fdimage.exe FIPS EXE 172,096 02-10-99 9:41p fips.exe GUNZIP EXE 37,178 02-10-99 9:41p gunzip.exe GZIP EXE 37,178 02-10-99 9:41p gzip.exe IDE_CONF EXE 10,177 02-10-99 9:41p ide_conf.exe OSBS135 EXE 31,290 02-10-99 9:41p osbs135.exe OSBSBETA EXE 41,111 02-10-99 9:41p osbsbeta.exe PFDISK EXE 17,542 02-10-99 9:41p pfdisk.exe PRESIZER DOC 44,243 02-10-99 9:41p presizer.doc PRESIZER EXE 56,511 02-10-99 9:41p presizer.exe RAWRITE EXE 36,064 02-10-99 9:41p rawrite.exe README 119 02-10-99 9:41p README RESTORRB EXE 13,398 02-10-99 9:41p restorrb.exe SETUP EXE 47,360 02-10-99 9:41p setup.exe SETUP HLP 5,623 02-10-99 9:41p setup.hlp SRCS 02-11-99 7:37a srcs 22 file(s) 649,932 bytes Directory of F:\tools\dist . 02-11-99 7:37a . .. 02-11-99 7:37a .. BTEASY14 ZIP 15,037 02-10-99 9:40p bteasy14.zip BTEASY17 ZIP 23,424 02-10-99 9:40p bteasy17.zip CKDIST10 ZIP 37,217 02-10-99 9:40p ckdist10.zip EXTIPL30 ZIP 46,046 02-10-99 9:40p extipl30.zip FDIMAG12 ZIP 16,193 02-10-99 9:40p fdimag12.zip FIPS11 ZIP 100,913 02-10-99 9:40p fips11.zip FIPS1~18 GZ 157,875 02-10-99 9:40p fips15c.tar.gz IDE_CONF TAR 24,576 02-10-99 9:40p ide_conf.tar PFDISKTC ZIP 23,630 02-10-99 9:40p pfdisktc.zip PRESZ120 ZIP 75,216 02-10-99 9:40p presz120.zip PRESZ130 ZIP 89,061 02-10-99 9:40p presz130.zip SETUP101 ZIP 107,819 02-10-99 9:40p setup101.zip SETUP220 ZIP 108,709 02-10-99 9:40p setup220.zip 13 file(s) 825,716 bytes Directory of F:\tools\srcs . 02-11-99 7:37a . .. 02-11-99 7:37a .. BTEASY 02-11-99 7:37a bteasy EXTIPL 02-11-99 7:37a EXTIPL FDIMAGE C 21,161 02-10-99 9:41p fdimage.c FIPS 02-11-99 7:37a fips IDE_CONF 02-11-99 7:37a ide_conf PFDISK 02-11-99 7:37a pfdisk RAWRITE 02-11-99 7:37a rawrite 1 file(s) 21,161 bytes Directory of F:\tools\srcs\bteasy . 02-11-99 7:37a . .. 02-11-99 7:37a .. BOOT ASM 8,594 02-10-99 9:40p BOOT.ASM BOOT BIN 512 02-10-99 9:40p BOOT.BIN BOOT LST 19,610 02-10-99 9:40p BOOT.LST BOOTINST C 8,329 02-10-99 9:40p BOOTINST.C BOOTINST EXE 12,092 02-10-99 9:40p BOOTINST.EXE COMPILE BAT 182 02-10-99 9:40p COMPILE.BAT README 2,050 02-10-99 9:40p README 7 file(s) 51,369 bytes Directory of F:\tools\srcs\EXTIPL . 02-11-99 7:37a . .. 02-11-99 7:37a .. DEVELOP 02-11-99 7:37a DEVELOP DEVELOP DOC 10,268 02-10-99 9:40p DEVELOP.DOC DEVELOP ENG 7,070 02-10-99 9:40p DEVELOP.ENG EXTIPL C 6,971 02-10-99 9:40p EXTIPL.C EXTIPL DOC 20,285 02-10-99 9:40p EXTIPL.DOC EXTIPL ENG 11,658 02-10-99 9:40p EXTIPL.ENG EXTIPL EXE 13,566 02-10-99 9:40p EXTIPL.EXE MAKEFILE 415 02-10-99 9:40p MAKEFILE README 1ST 2,540 02-10-99 9:41p README.1ST _EXTIPL ASM 8,703 02-10-99 9:40p _EXTIPL.ASM 9 file(s) 81,476 bytes Directory of F:\tools\srcs\EXTIPL\DEVELOP . 02-11-99 7:37a . .. 02-11-99 7:37a .. CAPS-FD ASM 4,353 02-10-99 9:40p CAPS-FD.ASM CAPS-FD BIN 477 02-10-99 9:40p CAPS-FD.BIN CAPS-HD ASM 4,381 02-10-99 9:40p CAPS-HD.ASM CAPS-HD BIN 489 02-10-99 9:40p CAPS-HD.BIN EXTFDTST ASM 4,235 02-10-99 9:40p EXTFDTST.ASM EXTFDTST BIN 483 02-10-99 9:40p EXTFDTST.BIN EXTIPL ASM 4,263 02-10-99 9:40p EXTIPL.ASM EXTIPL BIN 493 02-10-99 9:40p EXTIPL.BIN MKIPL BAT 265 02-10-99 9:40p MKIPL.BAT 9 file(s) 19,439 bytes Directory of F:\tools\srcs\fips . 02-11-99 7:37a . .. 02-11-99 7:37a .. COPYING 17,982 02-10-99 9:41p copying ERRORS TXT 8,371 02-10-99 9:41p errors.txt FIPS DOC 22,908 02-10-99 9:41p fips.doc HISTORY TXT 3,805 02-10-99 9:41p history.txt README 1ST 4,746 02-10-99 9:41p readme.1st RESTORRB 02-11-99 7:37a restorrb SOURCE 02-11-99 7:37a source TECHINFO TXT 9,098 02-10-99 9:41p techinfo.txt 6 file(s) 66,910 bytes Directory of F:\tools\srcs\fips\restorrb . 02-11-99 7:37a . .. 02-11-99 7:37a .. RESTORRB C 6,727 02-10-99 9:41p restorrb.c RTYPES H 2,904 02-10-99 9:41p rtypes.h 2 file(s) 9,631 bytes Directory of F:\tools\srcs\fips\source . 02-11-99 7:37a . .. 02-11-99 7:37a .. CALCULAT CPP 3,872 02-10-99 9:41p calculat.cpp CHECK CPP 8,404 02-10-99 9:41p check.cpp CMDL_ARG CPP 4,696 02-10-99 9:41p cmdl_arg.cpp DISK_IO CPP 6,915 02-10-99 9:41p disk_io.cpp DISK_IO H 4,338 02-10-99 9:41p disk_io.h FAT CPP 4,203 02-10-99 9:41p fat.cpp FAT H 1,830 02-10-99 9:41p fat.h FDSTRUCT H 547 02-10-99 9:41p fdstruct.h FIPSSPEC CPP 4,215 02-10-99 9:41p fipsspec.cpp FIPSSPEC H 2,927 02-10-99 9:41p fipsspec.h GLOBAL CPP 6,822 02-10-99 9:41p global.cpp GLOBAL H 2,116 02-10-99 9:41p global.h HDSTRUCT CPP 3,568 02-10-99 9:41p hdstruct.cpp HDSTRUCT H 6,308 02-10-99 9:41p hdstruct.h HOST_OS CPP 2,147 02-10-99 9:41p host_os.cpp HOST_OS H 797 02-10-99 9:41p host_os.h INPUT CPP 5,766 02-10-99 9:41p input.cpp INPUT H 1,509 02-10-99 9:41p input.h LOGDR_ST CPP 5,084 02-10-99 9:41p logdr_st.cpp LOGDR_ST H 5,599 02-10-99 9:41p logdr_st.h MAIN CPP 6,436 02-10-99 9:41p main.cpp SAVE CPP 2,214 02-10-99 9:41p save.cpp TYPES H 1,249 02-10-99 9:41p types.h 23 file(s) 91,562 bytes Directory of F:\tools\srcs\ide_conf . 02-11-99 7:37a . .. 02-11-99 7:37a .. IDE_CONF C 7,995 02-10-99 9:41p ide_conf.c WDDEFS H 3,057 02-10-99 9:41p wddefs.h 2 file(s) 11,052 bytes Directory of F:\tools\srcs\pfdisk . 02-11-99 7:37a . .. 02-11-99 7:37a .. MAKE_TCC BAT 163 02-10-99 9:41p make_tcc.bat PFDISK DOC 7,019 02-10-99 9:41p pfdisk.doc PFDISKAZ C 18,856 02-10-99 9:41p pfdiskaz.c SYSCODES C 1,476 02-10-99 9:41p syscodes.c SYSCODES H 163 02-10-99 9:41p syscodes.h SYSDEP H 720 02-10-99 9:41p sysdep.h S_MSDOS C 4,094 02-10-99 9:41p s_msdos.c 7 file(s) 32,491 bytes Directory of F:\tools\srcs\rawrite . 02-11-99 7:37a . .. 02-11-99 7:37a .. RAWRITE C 6,552 02-10-99 9:41p rawrite.c RAWRITE DOC 2,138 02-10-99 9:41p rawrite.doc 2 file(s) 8,690 bytes Directory of F:\XF86332 . 02-11-99 7:37a . .. 02-11-99 7:37a .. CHECKSUM MD5 3,122 02-10-99 9:30p CHECKSUM.MD5 EXTRACT 318,387 02-10-99 9:30p extract PC98-S~5 02-11-99 7:37a PC98-Servers PKGRE~12 GZ 54,415 02-10-99 9:30p pkgreg.tar.gz POSTINST SH 3,759 02-10-99 9:30p postinst.sh PREINST SH 4,746 02-10-99 9:30p preinst.sh README 34,871 02-10-99 9:30p README RELNOTES 19,529 02-10-99 9:30p RELNOTES SERVERS 02-11-99 7:37a Servers X9SET TGZ 463,937 02-10-99 9:30p X9set.tgz XBIN TGZ 3,373,080 02-10-99 9:31p Xbin.tgz XCFG TGZ 3,279 02-10-99 9:31p Xcfg.tgz XDOC TGZ 289,859 02-10-99 9:31p Xdoc.tgz XF100 TGZ 1,244,248 02-10-99 9:31p Xf100.tgz XFCYR TGZ 302,177 02-10-99 9:32p Xfcyr.tgz XFNON TGZ 2,219,650 02-10-99 9:32p Xfnon.tgz XFNTS TGZ 1,277,578 02-10-99 9:33p Xfnts.tgz XFSCL TGZ 1,121,312 02-10-99 9:33p Xfscl.tgz XFSRV TGZ 142,038 02-10-99 9:33p Xfsrv.tgz XHTML TGZ 327,924 02-10-99 9:33p Xhtml.tgz XJDOC TGZ 122,151 02-10-99 9:33p Xjdoc.tgz XLIB TGZ 349,047 02-10-99 9:34p Xlib.tgz XLK98 TGZ 5,121,714 02-10-99 9:36p Xlk98.tgz XLKIT TGZ 4,023,009 02-10-99 9:37p Xlkit.tgz XMAN TGZ 1,232,449 02-10-99 9:38p Xman.tgz XNEST TGZ 913,182 02-10-99 9:38p Xnest.tgz XPROG TGZ 1,393,142 02-10-99 9:38p Xprog.tgz XPRT TGZ 1,138,067 02-10-99 9:39p Xprt.tgz XPS TGZ 615,186 02-10-99 9:39p Xps.tgz XSET TGZ 463,864 02-10-99 9:39p Xset.tgz XVFB TGZ 1,113,662 02-10-99 9:40p Xvfb.tgz 29 file(s) 27,689,384 bytes Directory of F:\XF86332\PC98-Servers . 02-11-99 7:37a . .. 02-11-99 7:37a .. X9480 TGZ 954,741 02-10-99 9:22p X9480.tgz X9EGC TGZ 691,655 02-10-99 9:22p X9EGC.tgz X9GA9 TGZ 994,768 02-10-99 9:22p X9GA9.tgz X9GAN TGZ 1,003,632 02-10-99 9:22p X9GAN.tgz X9LPW TGZ 994,404 02-10-99 9:23p X9LPW.tgz X9MGA TGZ 975,951 02-10-99 9:23p X9MGA.tgz X9NKV TGZ 1,003,650 02-10-99 9:23p X9NKV.tgz X9NS3 TGZ 998,629 02-10-99 9:24p X9NS3.tgz X9SPW TGZ 1,001,555 02-10-99 9:24p X9SPW.tgz X9SVG TGZ 1,005,894 02-10-99 9:24p X9SVG.tgz X9TGU TGZ 973,336 02-10-99 9:25p X9TGU.tgz X9WEP TGZ 1,003,522 02-10-99 9:25p X9WEP.tgz X9WS TGZ 1,003,542 02-10-99 9:25p X9WS.tgz X9WSN TGZ 1,003,736 02-10-99 9:26p X9WSN.tgz 14 file(s) 13,609,015 bytes Directory of F:\XF86332\Servers . 02-11-99 7:37a . .. 02-11-99 7:37a .. X8514 TGZ 722,287 02-10-99 9:26p X8514.tgz XAGX TGZ 800,006 02-10-99 9:26p XAGX.tgz XI128 TGZ 895,091 02-10-99 9:26p XI128.tgz XMA32 TGZ 787,021 02-10-99 9:27p XMa32.tgz XMA64 TGZ 834,404 02-10-99 9:27p XMa64.tgz XMA8 TGZ 727,960 02-10-99 9:27p XMa8.tgz XMONO TGZ 797,613 02-10-99 9:28p XMono.tgz XP9K TGZ 809,133 02-10-99 9:28p XP9K.tgz XS3 TGZ 990,926 02-10-99 9:28p XS3.tgz XS3V TGZ 889,526 02-10-99 9:29p XS3V.tgz XSVGA TGZ 1,254,846 02-10-99 9:29p XSVGA.tgz XVG16 TGZ 808,438 02-10-99 9:29p XVG16.tgz XW32 TGZ 741,632 02-10-99 9:30p XW32.tgz 13 file(s) 11,058,883 bytes Total files listed: 769 file(s) 408,743,936 bytes 186 dir(s) 0 bytes free ------=_NextPart_000_0005_01BE55CC.C5A3FAA0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 15:40:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06058 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 15:40:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06053 for ; Thu, 11 Feb 1999 15:40:31 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40405>; Fri, 12 Feb 1999 10:29:55 +1100 Date: Fri, 12 Feb 1999 10:40:23 +1100 From: Peter Jeremy Subject: Re: portability of shm, mmap, pipes and socket IPC To: tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb12.102955est.40405@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Discussing semop(2) behaviour] Terry Lambert wrote: >What about a negative initial value setting? ... > When the man page says "absolute value", it *means* >"absolute value". The spec only refers to the absolute value of negative values of sem_op, ie (-sem_op). A negative initial value _shouldn't_ cause a problem (but see below), although I haven't confirmed this. I've been comparing the FreeBSD man page with Solaris 2.5, Digital UNIX 4.0D, Linux 0.99.13 and The Open Group's `Single Unix Specification, version 2' (http://www.opengroup.org/onlinepubs/7908799/xsh/semop.html). This reveals a number of typos in FreeBSD's man page: - there's a missing `absolute value' in the 2nd point covering negative sem_ops. - the description of behaviour when sem_op is zero is incomplete (no reference to IPC_NOWAIT or semzcnt). - the list of error returns is incomplete. There are a couple of areas of disagreement in the API: - TOG, Solaris and Linux define sem_num as `short', DEC and FreeBSD use u_short. - nsops is defined as size_t by DEC, TOG and Solaris, and unsigned by FreeBSD and Linux. I haven't been thru the code in detail, but I can immediately see the following problems: - if sem_op is 0, the process should only need READ permission on the semaphore. We currently require WRITE permission - there's no check on the range of semval (which should return ERANGE). This may be related to Terry's problem. I'll have a closer look at the code over the weekend (if I get time) and write a PR. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 16:20:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA12673 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 16:20:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12646 for ; Thu, 11 Feb 1999 16:20:35 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA15378; Thu, 11 Feb 1999 16:20:29 -0800 Date: Thu, 11 Feb 1999 16:20:28 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Julian Elischer cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: 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 > > I was misremembering. Softupdates wasn't the issue here but there *had* > > been some question about whether this was a problem with softupdates *not* > > enabled- that was from way earlier- sorry for jumping into the wrong > > thread and sorry for also probably letting a less than felicitous tone > > enter this email- I think I'm just really irritated that I didn't get mail > > back from Luoqi. > > Luoqi was "out of contact" for a while.. (had a real life plus work) > but he's not responsible for softupdates anyway. I am, and I didn't see IIRC, I was specifically asked by Jordan to mail the issues to Luoqi and Kirk. > any unresolved problems from you... > There are two open issues with soft updates BTW.. > > One is that soft updates stresses the disks so hard that the WD driver > gets into an infinite loop when in "single-block mode" (I've seen this a > couple of times in tests here) (and can reproduce it, even looked at it in > ddb but not totally solved it) (work-around is set flags to ide driver to > allow multi-block or Ultra-DMA). I'm working with servers, not desktop systems. I am working with at least 4 channels if not more. The disk units I'm using are either 60GB Adaptec RAID units, or 150GB MegaDrive RAID units. That's for the large stuff. The smaller stuff is anything from 1-10 9GB Seagate drives on either Fibre Channel or parallel SCSI. Again, it's not clear that the problem I have been seeing is a softupdates problem (modulo the panic I saw this morning). > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 16:54:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16987 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 16:54:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA16955; Thu, 11 Feb 1999 16:54:33 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id BAA39233; Fri, 12 Feb 1999 01:54:17 +0100 (CET) (envelope-from des) To: Nicolas Souchu Cc: Dag-Erling Smorgrav , Mike Smith , Bill Fenner , hackers@FreeBSD.ORG, wpaul@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> <19990211225037.40571@breizh.prism.uvsq.fr> From: Dag-Erling Smorgrav Date: 12 Feb 1999 01:54:16 +0100 In-Reply-To: Nicolas Souchu's message of "Thu, 11 Feb 1999 22:50:37 +0100" Message-ID: Lines: 32 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Souchu writes: > On Mon, Feb 08, 1999 at 10:59:57PM +0100, Dag-Erling Smorgrav wrote: > > Don't worry, I've patched GENERIC, LINT, files.i386 and the PicoBSD > > kernels, and removed lpt.c and lpt.4. I'll still have to track down > > references to the driver in the documentation though. > lpt.4 also? nlpt.4 refers to it. I'll have to complete nlpt.4. Hmm, there's no nlpt.4 on my system - I probably need to make world. > Shouldn't we have moved nlpt to lpt to keep the ages dated tags? I don't know. We can't repo copy nlpt.c to lpt.c because that will kill the old lpt.c, but that's not a big problem; we can rename nlpt to lpt in src/sys/conf/files and the users won't know the difference. The man page is a problem, though; it needs to have the same name as the device; but it's young enough that there's not much history to lose. > So, you choosed 'net'. But it won't work better than 'tty' if ppp is not > statically configured. And for a basic configuration, printer may not work > with interrupts :( > [...] My knowledge of the FreeBSD interrupt system is absolutely nil, so don't ask me for an opinion :) (BTW, I wouldn't mind if one of you superhero programmers wrote a short introduction to interrupt masks "for the rest of us") DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 17:01:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18054 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 17:01:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18042 for ; Thu, 11 Feb 1999 17:01:22 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id LAA10673 for ; Fri, 12 Feb 1999 11:31:19 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 12 Feb 1999 11:31:19 +1030 (CST) From: "Daniel O'Connor" To: freebsd-hackers@FreeBSD.ORG Subject: Interrupt processing stops for almost 2 seconds?! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, We have a custom PCI card and an associated driver whos main purpose is to get data from a digitisation system. The problem we are seeing is that occasionally (like once every 2 weeks or so) the kernel apparently pauses in its handling of interrupts for almost 2 seconds. This isn't matched which anything like /etc/daily or any other disk activity like core dumps etc.. Argh! The system is a 2.2.7 + CAM patches on a PII-350 with 64mb of RAM. --- 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 Thu Feb 11 17:21:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20920 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 17:21:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20863 for ; Thu, 11 Feb 1999 17:21:30 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id CAA39496; Fri, 12 Feb 1999 02:21:18 +0100 (CET) (envelope-from des) To: "Micheal Blackthorne" Cc: Subject: Re: In need of help. Stuck at "Boot:" References: <000401be560f$d3c73aa0$c814ea18@blackthorne> From: Dag-Erling Smorgrav Date: 12 Feb 1999 02:21:17 +0100 In-Reply-To: "Micheal Blackthorne"'s message of "Thu, 11 Feb 1999 14:42:38 -0800" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Micheal Blackthorne" writes: > I am very new to FreeBSD and have been trying for some time to get it > working on a spare PC of mine. The problem is that it appears that I > complete the installation of FreeBSD only to reboot and find myself at a > "Boot:" prompt. Freebsd-hackers is not the right list for this kind of questions. Please ask on freebsd-questions instead. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 17:28:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21495 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 17:28:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21458 for ; Thu, 11 Feb 1999 17:28:00 -0800 (PST) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id UAA28544; Thu, 11 Feb 1999 20:27:41 -0500 (EST) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.1/8.8.5) with ESMTP id VAA04508; Thu, 11 Feb 1999 21:11:22 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.9.1/8.6.9) id UAA12564; Thu, 11 Feb 1999 20:29:08 -0500 (EST) Date: Thu, 11 Feb 1999 20:29:08 -0500 (EST) From: Thomas David Rivers Message-Id: <199902120129.UAA12564@lakes.dignus.com> To: blackthorne@utah-inter.net, des@flood.ping.uio.no Subject: Re: In need of help. Stuck at "Boot:" Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > "Micheal Blackthorne" writes: > > I am very new to FreeBSD and have been trying for some time to get it > > working on a spare PC of mine. The problem is that it appears that I > > complete the installation of FreeBSD only to reboot and find myself at a > > "Boot:" prompt. > > Freebsd-hackers is not the right list for this kind of questions. > Please ask on freebsd-questions instead. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Uh.... I'm sorry; I was the one who directed him to FreeBSD-hackers. He's been on the FreeBSD-questions list already, and... didn't have much luck. If I mis-directed him... sorry... If I understand his question correctly, he's made his own CDROM and would like to install from it. But, when he boots from the HD, he just gets the Boot: prompt... after an appropriate amount of time, nothing happens. Seems like that would be a good question for hackers.. Why doesn't something happen? He forwarded the machine specifications, etc... in the previous mail. - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 18:02:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25977 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 18:02:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (b133.mat.net [206.246.122.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25894 for ; Thu, 11 Feb 1999 18:01:51 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id UAA04409 for ; Thu, 11 Feb 1999 20:58:28 -0500 (EST) Date: Thu, 11 Feb 1999 20:58:28 -0500 (EST) From: Chuck Robey To: FreeBSD-Hackers@FreeBSD.ORG Subject: ppp server side startup commands 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 I was wondering if someone can make suggestion here, regarding getting startup actions run, ON THE PPP SERVER. I run user-ppp, where the login is done via chap. The user never has to enter any password; the getty process recognizes the incoming frame as a ppp hdlc frame, and starts up a ppp process just fine. The login works perfectly. The problem comes in when, for instance, the ppp user has a second box that needs to be introduced into the routing. Manually, to do this, on the server (as root) an arp -s command, and a route add command, has to be run, then the second box (this is with static ip) works perfectly. I've tried doing this with either the !bg or sh commands in ppp.linkup, but those commands seem to be run with the user's permission level, and the arp and route commands must be run as root. There are like commands (arp and route commands) that also have to be run on ppp takedown, to eliminate the routes. Does anyone know how to get this automated, so that it happens automatically on ppp startup and takedown? Note that I said that !bg and sh aren't doing it, I think that their permission levels are wrong. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 18:05:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA26445 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 18:05:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles253.castles.com [208.214.165.253]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26435 for ; Thu, 11 Feb 1999 18:05:11 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA08923; Thu, 11 Feb 1999 17:56:58 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902120156.RAA08923@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Thomas David Rivers cc: blackthorne@utah-inter.net, des@flood.ping.uio.no, freebsd-hackers@FreeBSD.ORG Subject: Re: In need of help. Stuck at "Boot:" In-reply-to: Your message of "Thu, 11 Feb 1999 20:29:08 EST." <199902120129.UAA12564@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Feb 1999 17:56:58 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If I understand his question correctly, he's made his own CDROM and > would like to install from it. But, when he boots from the HD, he > just gets the Boot: prompt... after an appropriate amount of time, > nothing happens. > > Seems like that would be a good question for hackers.. Why doesn't > something happen? He's installed the old boot1/boot2 but has built an ELF kernel. He should be able to boot the loader manually to get up, then install the new bootblocks. Basically, you need to be able to diagnose things like this yourself if you're going to try to make your own releases. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 18:09:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27253 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 18:09:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27206 for ; Thu, 11 Feb 1999 18:09:20 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4014.ime.net [209.90.195.24]) by Loki.orland.u91.k12.me.us (8.9.3/8.8.8-Loki) with SMTP id VAA04222; Thu, 11 Feb 1999 21:08:19 -0500 (EST) (envelope-from netmonger@genesis.ispace.com) X-Server-ID: Loki.orland.u91.k12.me.us, OCSNet - Orland Maine USA X-Coord-Name: Drew "Droobie" Baxter, OneNetwork Exchange X-Coord-Addr: Droobie@Openlink.orland.me.us X-Coord-Pager: USA: 207-471-2719, http://pagedroo.orland.me.us Message-Id: <4.1.19990211210644.03b3da20@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 11 Feb 1999 21:07:52 -0500 To: Chuck Robey , FreeBSD-Hackers@FreeBSD.ORG From: Drew Baxter Subject: Re: ppp server side startup commands In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 08:58 PM 2/11/99 , Chuck Robey wrote: >I was wondering if someone can make suggestion here, regarding getting >startup actions run, ON THE PPP SERVER. > >I run user-ppp, where the login is done via chap. The user never has to >enter any password; the getty process recognizes the incoming frame as >a ppp hdlc frame, and starts up a ppp process just fine. The login >works perfectly. > >The problem comes in when, for instance, the ppp user has a second box >that needs to be introduced into the routing. Manually, to do this, on >the server (as root) an arp -s command, and a route add command, has to >be run, then the second box (this is with static ip) works perfectly. >I've tried doing this with either the !bg or sh commands in ppp.linkup, >but those commands seem to be run with the user's permission level, and >the arp and route commands must be run as root. > >There are like commands (arp and route commands) that also have to be >run on ppp takedown, to eliminate the routes. Does anyone know how to >get this automated, so that it happens automatically on ppp startup and >takedown? > >Note that I said that !bg and sh aren't doing it, I think that their >permission levels are wrong. > Use Sudo to exec the bg commands. i.e. sudo -u root /sbin/route add ... Course this requires you to let someone run commands as root.. perhaps you could hack the source to add a password implementation. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP DSS/1024 Public Key ID: 0x409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 11 22:19:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA26160 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 22:19:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from holly.dyndns.org ([208.169.163.124]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA26153 for ; Thu, 11 Feb 1999 22:19:21 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: (from chris@localhost) by holly.dyndns.org (8.9.2+chrismods/8.9.1) id AAA17772; Fri, 12 Feb 1999 00:19:36 -0600 (CST) (envelope-from chris) Date: Fri, 12 Feb 1999 00:19:35 -0600 From: Chris Costello To: Drew Baxter Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ppp server side startup commands Message-ID: <19990212001935.A17616@holly.dyndns.org> Reply-To: phoenix@calldei.com References: <4.1.19990211210644.03b3da20@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1us In-Reply-To: <4.1.19990211210644.03b3da20@genesis.ispace.com>; from Drew Baxter on Thu, Feb 11, 1999 at 09:07:52PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Or you could do something entirely simpler. Write a shell script containing the line - make SURE you set the path (i.e. do this: PATH=/usr/bin:/usr/sbin:/sbin:/usr/local/bin ) Have root own it and make it setuid 0. (chmod u+s yourscript) Don't trust any argument parsing either. #!/bin/sh PATH=/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin arp -s ... ... exit $? I would think this is adequately secure. On Thu, Feb 11, 1999, Drew Baxter put this into my mailbox: > At 08:58 PM 2/11/99 , Chuck Robey wrote: > >I was wondering if someone can make suggestion here, regarding getting > >startup actions run, ON THE PPP SERVER. > > > >I run user-ppp, where the login is done via chap. The user never has to > >enter any password; the getty process recognizes the incoming frame as > >a ppp hdlc frame, and starts up a ppp process just fine. The login > >works perfectly. > > > >The problem comes in when, for instance, the ppp user has a second box > >that needs to be introduced into the routing. Manually, to do this, on > >the server (as root) an arp -s command, and a route add command, has to > >be run, then the second box (this is with static ip) works perfectly. > >I've tried doing this with either the !bg or sh commands in ppp.linkup, > >but those commands seem to be run with the user's permission level, and > >the arp and route commands must be run as root. > > > >There are like commands (arp and route commands) that also have to be > >run on ppp takedown, to eliminate the routes. Does anyone know how to > >get this automated, so that it happens automatically on ppp startup and > >takedown? > > > >Note that I said that !bg and sh aren't doing it, I think that their > >permission levels are wrong. > > > > Use Sudo to exec the bg commands. i.e. sudo -u root /sbin/route add ... > > Course this requires you to let someone run commands as root.. perhaps you > could hack the source to add a password implementation. > > > --- > Drew "Droobie" Baxter > Network Admin/Professional Computer Nerd(TM) > OneEX: The OneNetwork Exchange, Bangor Maine USA > http://www.droo.orland.me.us > > PGP DSS/1024 Public Key ID: 0x409A1F7D > > > 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 Thu Feb 11 23:58:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA04034 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 23:58:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pacman.redwoodsoft.com (redwoodsoft.com [207.181.199.182]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA04029 for ; Thu, 11 Feb 1999 23:58:24 -0800 (PST) (envelope-from dnelson@pacman.redwoodsoft.com) Received: (qmail 4098 invoked by uid 1000); 12 Feb 1999 07:58:20 -0000 Date: Thu, 11 Feb 1999 23:58:20 -0800 (PST) From: Dru Nelson To: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates 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 I'm surprised that there are problems. I have never noticed any. Also, linux has that 2gig filesize limit, which makes it harder to really utilize a large 500GB filesystem. What were the requirements for NASA/Ames? Dru Nelson Redwood City, California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 00:50:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA10178 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 00:50:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fwgw.chiyoda.co.jp (ns.chiyoda.co.jp [202.33.240.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09973 for ; Fri, 12 Feb 1999 00:49:56 -0800 (PST) (envelope-from Arnel_A._Arcena_AT_C&E-PHIL.CCMGW@ykh.chiyoda.co.jp) From: Arnel_A._Arcena_AT_C&E-PHIL.CCMGW@ykh.chiyoda.co.jp Received: from tmp.chiyoda.co.jp by fwgw.chiyoda.co.jp (8.8.7+2.7Wbeta6/3.7W-fwgw) with SMTP id RAA04259 for ; Fri, 12 Feb 1999 17:49:39 +0900 (JST) Received: by tmp.chiyoda.co.jp(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 49256716.0030C910 ; Fri, 12 Feb 1999 17:52:52 +0900 X-Lotus-FromDomain: CHIYODA To: freebsd-hackers@FreeBSD.ORG Message-ID: <49256716.00301A13.00@tmp.chiyoda.co.jp> Date: Fri, 12 Feb 1999 16:46:57 +0900 Mime-Version: 1.0 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 Feb 12 01:02:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11474 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 01:02:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA11466 for ; Fri, 12 Feb 1999 01:02:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id KAA12297; Fri, 12 Feb 1999 10:02:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA13382; Fri, 12 Feb 1999 10:02:43 +0100 (MET) Date: Fri, 12 Feb 1999 10:02:39 +0100 From: Eivind Eklund To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip Message-ID: <19990212100238.N96008@bitbox.follo.net> References: <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> <19990208222829.53422@breizh.prism.uvsq.fr> <19990211225037.40571@breizh.prism.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Dag-Erling Smorgrav on Fri, Feb 12, 1999 at 01:54:16AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 12, 1999 at 01:54:16AM +0100, Dag-Erling Smorgrav wrote: > (BTW, I wouldn't mind if one of you superhero programmers wrote a > short introduction to interrupt masks "for the rest of us") I'll try to get this right, even though it is incomplete, but no guarantee: Interrupt masks are, well, interrupt masks. There are a bit for each interrupt; this bit control whether the interrupt in question will be serviced or delayed. Each of the spl()'s has a connected mask, _imask. This mask contains the actual masks of interrupts that are to be suspended by an spl(). Normally, an interrupt end up in the imask through a register_intr call - here is an example from the clock code: register_intr(/* irq */ apic_8254_intr, /* XXX id */ 0, /* flags */ 0, /* XXX */ (inthand2_t *)clkintr, &clk_imask, /* unit */ 0); INTREN(1 << apic_8254_intr); Note that the cast to inthand2_t seems bogus; inthand_t and inthand2_t are for taking a void * or an int as an argument to the interrupt functions. We're moving from unit numbers to actual softc (soft configuration) structures. INTREN() is a macro to enable the interrupt (in the APIC, I think, but I'm not quite clear on where/how it is used). The call that finally register the interrupt is usually done by the bus controlling code, anyway, so you won't see this. The imasks is the sole thing that controls which interrupts are blocked; this is why you sometimes see code like this tty_imask |= softnet_imask; /* spltty() block spl[soft]net() */ (from /sys/net/ppp_tty.c). Do Not Write Code Like This Unless You Really, Really Know What You Are Doing. Note that parts of the registration system will change as we switch to the new bus architecture - so don't depend too much on how it is done right now. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 03:47:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA26688 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 03:47:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bbs.mpcs.com (bbs.mpcs.com [209.101.88.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA26682 for ; Fri, 12 Feb 1999 03:47:52 -0800 (PST) (envelope-from hg@cally.n2wx.ampr.org) Received: from pickle.n2wx.ampr.org (cc1017255-a.srst1.fl.home.com [24.3.122.197]) by bbs.mpcs.com (8.8.8/8.8.8/MPCS spamzap) with ESMTP id GAA25291; Fri, 12 Feb 1999 06:47:28 -0500 Received: (from root@localhost) by pickle.n2wx.ampr.org (8.9.2/8.8.2/n2wx) id GAA21308; Fri, 12 Feb 1999 06:47:25 -0500 (EST) Received: from cally.south.mpcs.com (cally.n2wx.ampr.org [172.16.0.6]) by pickle.n2wx.ampr.org (8.9.2/8.9.2/n2wx) with ESMTP id GAA21300; Fri, 12 Feb 1999 06:46:59 -0500 (EST) (envelope-from hg@cally.n2wx.ampr.org) Received: (from hg@localhost) by cally.south.mpcs.com (8.9.2/8.9.1) id GAA02357; Fri, 12 Feb 1999 06:46:58 -0500 (EST) (envelope-from hg) Date: Fri, 12 Feb 1999 06:46:58 -0500 (EST) From: Howard Goldstein Message-Id: <199902121146.GAA02357@cally.south.mpcs.com> To: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902101738.KAA14521@usr07.primenet.com> Reply-To: hgoldste@bbs.mpcs.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In muc.lists.freebsd.hackers, you wrote: : > > > Matthew Dillon writes: : > > > > The problem is that linux updates the timeval structure on return, : > > > > telling you how much time is left. : : Linux doesn't do this in the default implementation any more. They : have a seperate system call that still does this. This would save me a gettimeofday() call and some math if we had a call for this too. : [...] : When writing new code. Yes, for that. Realtime signals would help almost as much, perhaps in a more portable way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 03:47:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA26704 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 03:47:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA26694 for ; Fri, 12 Feb 1999 03:47:55 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id MAA40493; Fri, 12 Feb 1999 12:47:37 +0100 (CET) (envelope-from des) To: Thomas David Rivers Cc: blackthorne@utah-inter.net, freebsd-hackers@FreeBSD.ORG Subject: Re: In need of help. Stuck at "Boot:" References: <199902120129.UAA12564@lakes.dignus.com> From: Dag-Erling Smorgrav Date: 12 Feb 1999 12:47:37 +0100 In-Reply-To: Thomas David Rivers's message of "Thu, 11 Feb 1999 20:29:08 -0500 (EST)" Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thomas David Rivers writes: > Seems like that would be a good question for hackers.. Why doesn't > something happen? No - if he had no luck on -questions, he should go to -stable or -current depending on the version of FreeBSD he's trying to run. -hackers is for discussing FreeBSD code internals. To quote the charter, "It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions." DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 03:57:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27260 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 03:57:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27254 for ; Fri, 12 Feb 1999 03:57:26 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10BHCE-000EKl-00; Fri, 12 Feb 1999 13:55:46 +0200 From: Sheldon Hearn To: Jeremy Lea cc: hackers@FreeBSD.ORG Subject: Re: Clobbering includes during ``make world'' In-reply-to: Your message of "Sat, 23 Jan 1999 17:21:43 +0200." <19990123172141.A33428@shale.csir.co.za> Date: Fri, 12 Feb 1999 13:55:46 +0200 Message-ID: <55102.918820546@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Jan 1999 17:21:43 +0200, Jeremy Lea wrote: > > make -DCLOBBER includes > > It would be nice if you could extend this to work with the perl modules. I've forwarded to the perl5 maintainer a suggestion for exactly that. You'll probably see it changed in CURRENT some day. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 04:58:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA06552 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 04:58:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA06518 for ; Fri, 12 Feb 1999 04:58:15 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id NAA04097 for ; Fri, 12 Feb 1999 13:58:11 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id NAA25859 for ; Fri, 12 Feb 1999 13:58:13 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id NAA22351 for ; Fri, 12 Feb 1999 13:58:12 +0100 (CET) Date: Fri, 12 Feb 1999 13:58:11 +0100 From: Andre Albsmeier To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates Message-ID: <19990212135811.A2119@internal> References: <199902101915.MAA21530@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199902101915.MAA21530@usr07.primenet.com>; from Terry Lambert on Wed, Feb 10, 1999 at 07:15:25PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10-Feb-1999 at 19:15:25 +0000, Terry Lambert wrote: > > > what is the current status of softupdates? > > > is it safe to turn on softupdates (no ccd)? > > > > It's been working just fine here for at least the last 6 months.. I haven't > > heard any softupdates-related panics/crashes on the mailing lists in a while. > > Absence of evidence is not evidence of absence. > > It could very well be that those people running soft updates are > so trashed that they can't post their horror stories to the list... > > That was a joke, in case it wasn't obvious. > > I think there are still two or three "rough edges", if not outright > bugs, like unexpected behaviour when marking /, etc.. Speaking of / ... I have three filesystems to mount apart from root. First I enabled softupdates on these three to see if all works well before doing this on the root fs. During every boot I see 3 times: ffs_mountfs: superblock updated for soft updates Than I enabled softupdates for / as well. However, I still see only three times the message above. But mount tells me that softupdates are enabled for all four filesystems. Is it normal that enabling softupdates for the root fs doesn't produce this message? Just wondering... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 05:42:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11747 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 05:42:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11742 for ; Fri, 12 Feb 1999 05:42:16 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id NAA07308; Fri, 12 Feb 1999 13:42:05 GMT From: Emmanuel DELOGET Message-Id: <199902121342.NAA07308@excalibur.oceanis.net> Subject: Re: TEXT_SET() macro In-Reply-To: <199902111617.QAA21427@excalibur.oceanis.net> from Emmanuel DELOGET at "Feb 11, 1999 5:17:15 pm" To: bf20761@binghamton.edu Date: Fri, 12 Feb 1999 14:42:05 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As the well known Emmanuel DELOGET said... -> Of course... I'm begin to read :) -> (too bad I didn't think to that by myself...) -> -> As zhihuizhang said... -> ** -> ** Please search the FreeBSD mailinglist Archive (make sure that you include -> ** the hackers list) for keywords "linker and set". They refer to the linker -> ** sets - sets declared by you and created by the linker. -> ** -> ** -------------------------------------------------- -> ** | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | -> ** | Dept. of Computer Science, SUNY at Binghamton | -> ** -------------------------------------------------- -> ** -> ** On Thu, 11 Feb 1999, Emmanuel DELOGET wrote: -> ** -> ** [lots of bad stuff deleted] -> In fact, once I'v read tons of [archived] mails, I still have a problem. I wanna know how it's working both at compile time and at run time (for example, does a lkm (yes lkm, not kld, since I'm working on a 2.2.8 release...) can declare linker_sets, or add entries in a kernel linker_set, [for example , the sysctl_ one - seems that I'm very interested in sysctls :)]. Thaks a lot. -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 05:50:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12613 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 05:50:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA12608 for ; Fri, 12 Feb 1999 05:50:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id FAA17752; Fri, 12 Feb 1999 05:49:56 -0800 Date: Fri, 12 Feb 1999 05:49:55 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Dru Nelson cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: 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 Hi, Dru! > I'm surprised that there are problems. I have never noticed any. > Also, linux has that 2gig filesize limit, which makes it harder to really > utilize a large 500GB filesystem. Corrected by Matti Aarno's patches. I'm not saying that NASA/Ames has gone with ext2- I'm just saying that of FreeBSD/FFS, NetBSD/FFS and Linux/ext2, Linux/ext2 has shown itself to have the least problems in terms of data corruption or system panics when testing with filesystems > 100GB. Buffer cache suckdown is another problem, and up until Steve Tweedies patches in the last couple of weeks, Linux couldn't possible be considered a real candidate because while writing but large files you'd suck down 95% of primary memory for write behind buffers, making system response go away almost entirely. > > What were the requirements for NASA/Ames? > > Replacement for the Convex (chuck && scott) machines, i.e., > 900GB reliable standard filesystem that you could then put RASH hooks into later. Whether these would be via locally attached disk or via a HIPPI network block device ('raw frame' driver) was/in indeterminate. It's not clear whether anything but NetBSD will be used for these machines, but there had been so many hardware related and also possible FFS related problems with the MSS3 project that I was allowed to go off and search for possible alternatives. Digital Unix/ADVFS as is Solaris/UFS and Solaris/SAMFS (LSC's produce) are also candidates, but those are less attractive because they're not open source solutions. At any rate, at the time I was doing this, I could not demonstrate FreeBSD/FFS to be a superior combo than NetBSD/FFS, hence the term 'loss'. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 06:48:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20427 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 06:48:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA20421 for ; Fri, 12 Feb 1999 06:48:48 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA41138; Fri, 12 Feb 1999 15:47:21 +0100 (CET) (envelope-from des) To: Emmanuel DELOGET Cc: bf20761@binghamton.edu, hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Subject: Re: TEXT_SET() macro References: <199902121342.NAA07308@excalibur.oceanis.net> From: Dag-Erling Smorgrav Date: 12 Feb 1999 15:47:20 +0100 In-Reply-To: Emmanuel DELOGET's message of "Fri, 12 Feb 1999 14:42:05 +0100 (MET)" Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Emmanuel DELOGET writes: > I wanna know how it's working both at compile time and at run time > (for example, does a lkm (yes lkm, not kld, since I'm working on a > 2.2.8 release...) can declare linker_sets, or add entries in a kernel > linker_set, [for example , the sysctl_ one - seems that I'm very > interested in sysctls :)]. Thaks a lot. Yes. You shouldn't be working on 2.2.8 - the 2.2 branch is dead now. Save yourself a lot of trouble and go to 3.1. For linker set examples, look up the definition of the DECLARE_MODULE macro to see how they are declared and read the kldload code to see how they are used. Use e.g. You can declare sysctls in modules, but the sysctl code will not pick them up so it's pretty useless. There is work pending to make that possible. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 07:06:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA23885 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 07:06:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from excalibur.oceanis.net (ns.dotcom.fr [194.133.21.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA23873 for ; Fri, 12 Feb 1999 07:06:41 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id PAA08837; Fri, 12 Feb 1999 15:06:20 GMT From: Emmanuel DELOGET Message-Id: <199902121506.PAA08837@excalibur.oceanis.net> Subject: Re: TEXT_SET() macro In-Reply-To: from Dag-Erling Smorgrav at "Feb 12, 1999 3:47:20 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Fri, 12 Feb 1999 16:06:19 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) 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 As the well known Dag-Erling Smorgrav said... ->Emmanuel DELOGET writes: ->> I wanna know how it's working both at compile time and at run time ->> (for example, does a lkm (yes lkm, not kld, since I'm working on a ->> 2.2.8 release...) can declare linker_sets, or add entries in a kernel ->> linker_set, [for example , the sysctl_ one - seems that I'm very ->> interested in sysctls :)]. Thaks a lot. -> -> Yes. -> -> You shouldn't be working on 2.2.8 - the 2.2 branch is dead now. Save -> yourself a lot of trouble and go to 3.1. -> Helas ! It seems that the 3.1 branch (as said my chief, I have no time to verify) is too far from NetBSD, and I'll have to port may work to NetBSD soon ! So I work on a 2.2.8... (well, I don't know if I will be able to put that stuff in NetBSD, but I'll try !) The goal is to add a kernelized SNMP support, in fact, both to FreeBSD and NetBSD. I'll certainly do that for -current later. -> For linker set examples, look up the definition of the DECLARE_MODULE -> macro to see how they are declared and read the kldload code to see -> how they are used. Use e.g. Oups... Does that mean no linux ? ;) -> -> You can declare sysctls in modules, but the sysctl code will not pick -> them up so it's pretty useless. There is work pending to make that -> possible. -> This seems that the sysctl_order function is called only on the system init (due to SYSINIT), but it may be possible to find a workaroud (I'm working on this for 2.2.8, on the base of the D. Rabson patch for -current). -> DES ->-- -> Dag-Erling Smorgrav - des@flood.ping.uio.no Thaks a lot. -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 07:25:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25284 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 07:25:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25279 for ; Fri, 12 Feb 1999 07:25:07 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id QAA41450; Fri, 12 Feb 1999 16:24:48 +0100 (CET) (envelope-from des) To: Emmanuel DELOGET Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Subject: Re: TEXT_SET() macro References: <199902121506.PAA08837@excalibur.oceanis.net> From: Dag-Erling Smorgrav Date: 12 Feb 1999 16:24:46 +0100 In-Reply-To: Emmanuel DELOGET's message of "Fri, 12 Feb 1999 16:06:19 +0100 (MET)" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Emmanuel DELOGET writes: > -> For linker set examples, look up the definition of the DECLARE_MODULE > -> macro to see how they are declared and read the kldload code to see > -> how they are used. Use e.g. > > Oups... Does that mean no linux ? ;) No, it's the Norwegian Linux user group's Internet domain. LXR (Linux Cross-Reference) originally only indexed the Linux sources. A FreeBSD- friendly company donated a disk to LXR, and I suggested how to put the additional disk capacity to good use :) It goes to show universities are great places for OS advocacy. I've had great success with suggesting FreeBSD to my students as an alternative to Linux :) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 08:29:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02387 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 08:29:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02379 for ; Fri, 12 Feb 1999 08:29:51 -0800 (PST) (envelope-from erich@lodgenet.com) Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.122.30]) by garbo.lodgenet.com (8.9.3/8.9.3) with ESMTP id KAA08477; Fri, 12 Feb 1999 10:29:48 -0600 (CST) Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.9.3/8.8.5) with ESMTP id KAA29685; Fri, 12 Feb 1999 10:28:33 -0600 (CST) Message-Id: <199902121628.KAA29685@jake.lodgenet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG cc: erich@lodgenet.com Subject: dlopen and ELF v. a.out Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-7836634220" Date: Fri, 12 Feb 1999 10:28:33 -0600 From: "Eric L. Hernes" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_-7836634220 Content-Type: text/plain; charset=us-ascii I've been looking at x11amp, and I've run into a bit of a problem. The program is set up as a program and a few shared-library plug-ins. The shared libs all have some common symbol names in global scope, (obviously) to provide an interface between the program and the plugin. What happens, though is that the plug-ins aren't very well encapsulated, so there's big time global symbol polution. If the plug-ins were contained in one .c module, I could just declare the offending symbols as static, and all would be fine. But the plug-ins are often aggregates where some symbols need to be seen from different c-sources. So is there any way to get the linker to export only specific symbols, and hide the rest (and resolve them internally to the lib)? Attached is a test prog that illustrates the problem. There is two source files, a ldsoTest.c, that is the main program that dlopen()s three `plug-ins'. Each plugin is compiled from the same test.c source with different pre-processor defines to get a different message. If the programs are compiled a.out, it works as desired. But if I build with ELF, it's not right. Here's the output when I run it: (code attached below) (ttyp1@jake)$ env OBJFORMAT=aout make cc -O -pipe -g -shared -o test0.so -DTST_MESSAGE="\"This is test 0"\" test.c cc -O -pipe -g -shared -o test1.so -DTST_MESSAGE="\"This is test 1"\" test.c cc -O -pipe -g -shared -o test2.so -DTST_MESSAGE="\"This is test 2"\" test.c cc -O -pipe -g -o ldsoTest ldsoTest.c (ttyp1@jake)$ ./ldsoTest got fp at 0x200170f0 message: This is test 0 got fp at 0x200970f0 message: This is test 1 got fp at 0x200990f0 message: This is test 2 (ttyp1@jake)$ make clean rm -f test0.so test1.so test2.so ldsoTest (ttyp1@jake)$ env OBJFORMAT=elf make cc -O -pipe -g -shared -o test0.so -DTST_MESSAGE="\"This is test 0"\" test.c cc -O -pipe -g -shared -o test1.so -DTST_MESSAGE="\"This is test 1"\" test.c cc -O -pipe -g -shared -o test2.so -DTST_MESSAGE="\"This is test 2"\" test.c cc -O -pipe -g -o ldsoTest ldsoTest.c (ttyp1@jake)$ ./ldsoTest got fp at 0x280d2288 message: This is test 0 got fp at 0x280d4288 message: This is test 0 got fp at 0x280d6288 message: This is test 0 --==_Exmh_-7836634220 Content-Type: text/plain ; name="test.c"; charset=us-ascii Content-Description: test.c Content-Disposition: attachment; filename="test.c" #include char *msg = TST_MESSAGE; char * testFunction(void){ return msg; } --==_Exmh_-7836634220 Content-Type: text/plain ; name="ldsoTest.c"; charset=us-ascii Content-Description: ldsoTest.c Content-Disposition: attachment; filename="ldsoTest.c" #include #include #include typedef char *fcn(void); int main(int ac, char **av){ int i; char *pn; char *cwd=getwd(NULL); void *h; fcn *fp; char *m; for(i=0;i<3;i++) { asprintf(&pn, "%s/test%d.so", cwd, i); h = dlopen(pn, RTLD_NOW); if (h) { fp = dlsym(h, "testFunction"); if (fp){ fprintf(stderr, "got fp at %p\n", fp); m = fp(); fprintf(stderr, "message: %s\n", m); } } else { warn("%s: dlopen failed", pn); } free(pn); } return 0; } --==_Exmh_-7836634220 Content-Type: text/plain ; name="Makefile"; charset=us-ascii Content-Description: Makefile Content-Disposition: attachment; filename="Makefile" CFLAGS+=-g BINS=test0.so test1.so test2.so ldsoTest all: ${BINS} ldsoTest: ldsoTest.c ${CC} ${CFLAGS} -o $@ $< test0.so: test.c ${CC} ${CFLAGS} -shared -o $@ -DTST_MESSAGE="\"This is test 0"\" test.c test1.so: test.c ${CC} ${CFLAGS} -shared -o $@ -DTST_MESSAGE="\"This is test 1"\" test.c test2.so: test.c ${CC} ${CFLAGS} -shared -o $@ -DTST_MESSAGE="\"This is test 2"\" test.c clean: rm -f ${BINS} --==_Exmh_-7836634220 Content-Type: text/plain; charset=us-ascii Eric L. Hernes erich@lodgenet.com --==_Exmh_-7836634220-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 11:21:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21940 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 11:21:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21935 for ; Fri, 12 Feb 1999 11:21:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA06904; Fri, 12 Feb 1999 11:21:23 -0800 (PST) (envelope-from dillon) Date: Fri, 12 Feb 1999 11:21:23 -0800 (PST) From: Matthew Dillon Message-Id: <199902121921.LAA06904@apollo.backplane.com> To: Matthew Jacob Cc: Dru Nelson , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> What were the requirements for NASA/Ames? :> :> : :Replacement for the Convex (chuck && scott) machines, i.e., > 900GB :reliable standard filesystem that you could then put RASH hooks into :later. Whether these would be via locally attached disk or via a HIPPI :network block device ('raw frame' driver) was/in indeterminate. : :It's not clear whether anything but NetBSD will be used for these :machines, but there had been so many hardware related and also possible :FFS related problems with the MSS3 project that I was allowed to go off :and search for possible alternatives. Digital Unix/ADVFS as is Solaris/UFS :and Solaris/SAMFS (LSC's produce) are also candidates, but those are less :attractive because they're not open source solutions. At any rate, at the :time I was doing this, I could not demonstrate FreeBSD/FFS to be a :superior combo than NetBSD/FFS, hence the term 'loss'. : :-matt If you need absolute reliability, I would seriously consider a NetApp. I'd choose that over everything - solaris, irix, *bsd, linux, NT. You name it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 13:05:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06049 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 13:05:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06028 for ; Fri, 12 Feb 1999 13:05:20 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id UAA25031; Fri, 12 Feb 1999 20:59:18 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.2) with ESMTP id SAA55040; Fri, 12 Feb 1999 18:51:40 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902121851.SAA55040@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: ppp server side startup commands In-reply-to: Your message of "Thu, 11 Feb 1999 20:58:28 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Feb 1999 18:51:40 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Add ``enable proxy'' for the proxy arp behaviour that you want and something like ``add HISADDR/24 HISADDR'' if you want to route to more than just a single machine. They're automatically removed when ppp exits. > I was wondering if someone can make suggestion here, regarding getting > startup actions run, ON THE PPP SERVER. > > I run user-ppp, where the login is done via chap. The user never has to > enter any password; the getty process recognizes the incoming frame as > a ppp hdlc frame, and starts up a ppp process just fine. The login > works perfectly. > > The problem comes in when, for instance, the ppp user has a second box > that needs to be introduced into the routing. Manually, to do this, on > the server (as root) an arp -s command, and a route add command, has to > be run, then the second box (this is with static ip) works perfectly. > I've tried doing this with either the !bg or sh commands in ppp.linkup, > but those commands seem to be run with the user's permission level, and > the arp and route commands must be run as root. > > There are like commands (arp and route commands) that also have to be > run on ppp takedown, to eliminate the routes. Does anyone know how to > get this automated, so that it happens automatically on ppp startup and > takedown? > > Note that I said that !bg and sh aren't doing it, I think that their > permission levels are wrong. > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@glue.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run picnic (FreeBSD-current) > (301) 220-2114 | and jaunt (Solaris7). > ----------------------------+----------------------------------------------- -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 14:33:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16793 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 14:33:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from chain.freebsd.os.org.za (chain.freebsd.os.org.za [196.7.74.174]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16785 for ; Fri, 12 Feb 1999 14:32:55 -0800 (PST) (envelope-from khetan@chain.freebsd.os.org.za) To: (original recipient in envelope at chain.freebsd.os.org.za) X-Disclaimer: Contents of this e-mail are the writer's opinion X-Disclaimer2: and may not be quoted, re-produced or forwarded X-Disclaimer3: (in part or whole) without the author's permission. Received: from localhost (khetan@localhost) by chain.freebsd.os.org.za (8.9.3/8.9.3/smtpfeed 0.91) with ESMTP id AAA00612 for ; Sat, 13 Feb 1999 00:32:41 +0200 (SAST) (envelope-from khetan@chain.freebsd.os.org.za) Date: Sat, 13 Feb 1999 00:32:41 +0200 (SAST) From: Khetan Gajjar Reply-To: Khetan Gajjar To: hackers@FreeBSD.ORG Subject: Kernel trap error ? 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 Hi. I saw that my 4-CURRENT box from 8 February dropped to ddb after my last make world. I'm not sure what the trap indicates "caused" the problem. The error is "Kernel type 12 trap, code=0 Stopped at vfs_msync+0x20 : movl 0x28(%ebx),%edi" Does anyone know what this means ? The machine was idle at the time - I'm the only user, and it isn't used as a public access server. I am using softupdates and NFS (not heavily though). I haven't seen anything like this on -current or -hackers, and searching the mailing lists didn't reveal anything relevant. My kernel config and dmesg is listed below. TIA! dmesg ----- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Thu Feb 11 17:30:30 SAST 1999 root@chain.freebsd.os.org.za:/usr/src/sys/compile/CHAIN Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 200455842 Hz CPU: Pentium/P54C (200.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 100663296 (98304K bytes) avail memory = 94633984 (92416K bytes) Preloaded elf kernel "kernel" at 0xf02ca000. ccd0-1: Concatenated disk drivers Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 ide_pci0: rev 0xd0 int a irq 14 on pci0.0.1 chip1: rev 0x01 on pci0.1.0 chip2: rev 0x00 on pci0.2.0 vga0: rev 0x53 int a irq 10 on pci0.9.0 de0: rev 0x11 int a irq 5 on pci0.13.0 de0: SMC 21041 [10Mb/s] pass 1.1 de0: address 00:00:c0:f9:2f:c8 Probing for devices on PCI bus 1: Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model IntelliMouse, device ID 3 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa ide_pci: generic_dmainit 01f0:0: warning, IDE controller timing not set wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S ide_pci: generic_dmainit 01f0:1: warning, IDE controller timing not set wdc0: unit 1 (wd1): , DMA, 32-bit, multi-block-8 wd1: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa ide_pci: generic_dmainit 0170:0: warning, IDE controller timing not set wdc1: unit 0 (wd2): , DMA, 32-bit, multi-block-32 wd2: 2015MB (4127760 sectors), 4095 cyls, 16 heads, 63 S/T, 512 B/S ppc0 at 0x378 irq 7 on isa ppc0: Winbond chipset (NIBBLE-only) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 aha0 at 0x330-0x333 irq 11 drq 6 on isa aha0: AHA-1542CF FW Rev. C.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs npx0 on motherboard npx0: INT 16 interface vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa de0: enabling 10baseT port Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging limited to 100 packets/entry de0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen Waiting 2 seconds for SCSI devices to settle changing root device to wd1s1a da0 at aha0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: 516MB (1057616 512 byte sectors: 64H 32S/T 516C) da1 at aha0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 3.300MB/s transfers da1: 515MB (1056708 512 byte sectors: 64H 32S/T 515C) ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates cd0 at aha0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed de0: enabling 10baseT port Kernel config ------------- #bus devices controller isa0 controller pnp0 controller pci0 #scsi code + adapter controller aha0 at isa? port ? cam irq ? controller scbus0 #processor stuff machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident CHAIN options MATH_EMULATE #Support for x87 emulation options "PQ_LARGECACHE" #enable 512kb+ l2 cache support device npx0 at isa? port IO_NPX irq 13 #performance stuff maxusers 256 options "NMBCLUSTERS=4096" options FAILSAFE #Be conservative options "CMD640" # work around CMD640 chip deficiency #networking pseudo-device loop pseudo-device ether pseudo-device tun 1 options INET #InterNETworking #filesystems options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SOFTUPDATES #console stuff pseudo-device splash pseudo-device pty 128 options UCONSOLE #Allow users to grab the console options SYSVSHM options SYSVSEM options SYSVMSG options VESA options XSERVER # support for X server controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts device sc0 at isa? tty #misc kernel tie ins pseudo-device gzip # Exec gzipped a.out's options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE options DDB options SPX_HACK options "IBCS2" #build ibcs2 into kernel options "COMPAT_LINUX" #build linux into kernel options "VM86" #posix code options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" #security stuff options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity options IPDIVERT options "ICMP_BANDLIM" options "MD5" pseudo-device bpfilter 2 #Berkeley packet filter pseudo-device snp 2 #disk stuff pseudo-device ccd 2 config kernel root on wd0 #floppy controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 #primary ide channel controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 #secondary ide channel controller wdc1 at isa? port "IO_WD2" bio irq 15 flags 0xa0ffa0ff disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 #scsi devices device da0 device cd0 device pass0 #other devices #network card device de0 #serial port device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 #parallel port device ppc0 at isa? port? net irq 7 controller ppbus0 device nlpt0 at ppbus? device plip0 at ppbus? device ppi0 at ppbus? --- Khetan Gajjar (!kg1779) * khetan@iafrica.com ; khetan@os.org.za http://www.os.org.za/~khetan * Talk/Finger khetan@chain.freebsd.os.org.za FreeBSD enthusiast * http://www2.za.freebsd.org/ Security-wise, NT is a OS with a "kick me" sign taped to it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 15:03:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19042 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 15:03:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19037 for ; Fri, 12 Feb 1999 15:03:13 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id AAA05641 for freebsd-hackers@FreeBSD.ORG; Sat, 13 Feb 1999 00:03:11 +0100 (CET) (envelope-from olli) Date: Sat, 13 Feb 1999 00:03:11 +0100 (CET) From: Oliver Fromme Message-Id: <199902122303.AAA05641@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: ISA DMA problems if >= 512 Mb RAM? Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I submitted a PR regarding this last month, but it seems like that was rather inappropriate (and obviously it didn't get any attention). Admittedly, I'm not that much of a VM expert, so maybe the information that I provide is insufficient. In that case please let me know what I can do to help fixing this problem. This is the situation: ASUS P2B-LS mainboard with 512 Mb RAM, Soundblaster AWE64 PnP. (This is NOT a problem with PnP or the sound drivers!). We're running 3.0-stable of 1999-01-28. This is what happens (dmesg excerpt): hermes /kernel: real memory = 536870912 (524288K bytes) hermes /kernel: avail memory = 519753728 (507572K bytes) hermes /kernel: snd0: hermes /kernel: sbxvi0 at drq 5 on isa hermes /kernel: snd0: hermes /kernel: soundcard buffer alloc failed hermes /kernel: snd: Unable to allocate 131072 bytes of buffer hermes /kernel: sbmidi0 at 0x330 on isa hermes /kernel: snd0: hermes /kernel: awe0 at 0x620 on isa hermes /kernel: awe0: hermes /kernel: opl0 at 0x388 on isa hermes /kernel: snd0: It looks like the driver is unable to allocate its DMA buffers. Needless to say, audio playback doesn't work. With Luigi's pcm driver, no error messages appear during boot, but when I try to play audio, the result is a panic: "isa_dmacheck: no physical page present". I noticed that the difference between "real" and "avail" memory (reported during boot) is about 16.3 Mb. Therefore my guess is that the kernel allocates that memory at the lower end of the RAM for some internal bookkeeping related to physical RAM (page tables? Remember, I'm not a VM expert). The sound drivers try to allocate their DMA buffers in the lower 16 Mb, too, because the rest is not accessible by ISA DMA (someone correct me if I'm wrong), which fails, of course. (It's probably a bug in the pcm driver not to check for this case, which leads to the panic, but that's a different story.) When I came to that conclusion, I tried to remove some of the RAM, reducing the total amount to 256 Mb. Voilà: No error messages, and playing audio works fine! This time, dmesg says: hermes /kernel: real memory = 268435456 (262144K bytes) hermes /kernel: avail memory = 258564096 (252504K bytes) The difference is only about 9.5 Mb now. Enough space left for the sound drivers. Out of curiosity, I also tryed 384 Mb RAM: hermes /kernel: real memory = 402653184 (393216K bytes) hermes /kernel: avail memory = 389107712 (379988K bytes) That's 13 Mb difference, audio playback still works fine. However, reducing the amount of RAM is not really a solution. After all, we got that much for a reason. ;-) Has anyone an idea how to solve the problem? Is there a way to tell the kernel to leave some space available in the lower 16 Mb? Or is the problem caused by something completely different? Regards Oliver PS: Hmm... thinking about it, doesn't the floppy driver also use ISA DMA? The floppy drive seems to work fine, even with 512 Mb RAM. (Does the 16 Mb limitation not apply to onboard FD controllers?) PPS: No need to Cc: me, I'm reading the list through a news gateway. -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 15:32:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22517 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 15:32:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22502 for ; Fri, 12 Feb 1999 15:32:25 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA18449; Fri, 12 Feb 1999 16:32:20 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd018379; Fri Feb 12 16:32:14 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA25413; Fri, 12 Feb 1999 16:31:37 -0700 (MST) From: Terry Lambert Message-Id: <199902122331.QAA25413@usr01.primenet.com> Subject: Re: data recovery ? To: sec@pi.musin.de (Stefan `Sec` Zehl) Date: Fri, 12 Feb 1999 23:31:26 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990211141454.A23872@yoda.pi.musin.de> from "Stefan `Sec` Zehl" at Feb 11, 99 02:14:54 pm X-Mailer: ELM [version 2.4 PL25] 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 > A friend of mine (no, not me :-) just managed to do a fresh 3.0 install > on his box without saving his previous data to another box. > He had one home.tar lying in /usr before he re-paritioned and > reinstalled. > > Is there _any_ way to recover it now? Unfortunately nobody here has > enough knowledge of the filesystem structure for ufs. > > Are there any pointers on what we can try to recover this .tar now, or > are we lot ? If you haven't done anything else to the disk since doing this, and the home.tar was truly a home.tar and not compressed, then the contents should be plaintext. In general, if you didn't change the offset of the start, or you changed it in a 4M increment, then you don't have to worry about cylinder group data having squatted on your file. You may have inode data, or other data that has eaten holes in the home directory. Any binary files you had are goners. Write them off now. For text files, you can read the disk for recognizable chunks of the text. They will most likely be in to 9 times runs of data (to account for clustering). I've often thought that tar should ftruncate/fcntl files larger by the run of the file it was about to archive plus metadata, in order to promote clustering of archives. I once recovered 6 weeks of work on a Motif clone this way; it's time consuming, but you can do it. You will probably need to write some dumb little raw device grep and ofset cluster grabbing tools; I tend to rewrite these each time I have to recover data, since they're no more than 30 or so lines of code each, so I don't have them to send to you. If you find the task onerous, be sure to submit them as ports so that they can become widely available. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 15:40:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23242 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 15:40:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23052 for ; Fri, 12 Feb 1999 15:40:47 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA00856; Fri, 12 Feb 1999 16:40:35 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd000713; Fri Feb 12 16:40:21 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA26002; Fri, 12 Feb 1999 16:40:06 -0700 (MST) From: Terry Lambert Message-Id: <199902122340.QAA26002@usr01.primenet.com> Subject: Re: ppp server side startup commands To: phoenix@calldei.com Date: Fri, 12 Feb 1999 23:40:05 +0000 (GMT) Cc: netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990212001935.A17616@holly.dyndns.org> from "Chris Costello" at Feb 12, 99 00:19:35 am X-Mailer: ELM [version 2.4 PL25] 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 > Or you could do something entirely simpler. > > Write a shell script containing the line - make SURE you set the path > (i.e. do this: > > PATH=/usr/bin:/usr/sbin:/sbin:/usr/local/bin > ) > > Have root own it and make it setuid 0. (chmod u+s yourscript) Shell scripts aren't allowed to be SUID root. To solve the problem, though: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt The PPP server should obtain IP addresses via DHCP. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 15:43:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23608 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 15:43:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23595 for ; Fri, 12 Feb 1999 15:43:41 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA02094; Fri, 12 Feb 1999 16:43:30 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd002060; Fri Feb 12 16:43:29 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA26155; Fri, 12 Feb 1999 16:43:22 -0700 (MST) From: Terry Lambert Message-Id: <199902122343.QAA26155@usr01.primenet.com> Subject: Re: In need of help. Stuck at "Boot:" To: mike@smith.net.au (Mike Smith) Date: Fri, 12 Feb 1999 23:43:22 +0000 (GMT) Cc: rivers@dignus.com, blackthorne@utah-inter.net, des@flood.ping.uio.no, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902120156.RAA08923@dingo.cdrom.com> from "Mike Smith" at Feb 11, 99 05:56:58 pm X-Mailer: ELM [version 2.4 PL25] 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 > > If I understand his question correctly, he's made his own CDROM and > > would like to install from it. But, when he boots from the HD, he > > just gets the Boot: prompt... after an appropriate amount of time, > > nothing happens. > > > > Seems like that would be a good question for hackers.. Why doesn't > > something happen? > > He's installed the old boot1/boot2 but has built an ELF kernel. He > should be able to boot the loader manually to get up, then install the > new bootblocks. > > Basically, you need to be able to diagnose things like this yourself if > you're going to try to make your own releases. One of the magic things that Julian and Doug Ambrisko did here when we upgraded a lot of machines to 3.0, was to *not* install the new boot blocks. Instead, there's a little a.out program (named "kernel") that is loaded instead of the real kernel that then loads the real kernel. I don't know the status of this code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 15:46:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23955 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 15:46:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23947 for ; Fri, 12 Feb 1999 15:46:34 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAB24459; Fri, 12 Feb 1999 16:46:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd024189; Fri Feb 12 16:46:18 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA26318; Fri, 12 Feb 1999 16:45:49 -0700 (MST) From: Terry Lambert Message-Id: <199902122345.QAA26318@usr01.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: hgoldste@bbs.mpcs.com Date: Fri, 12 Feb 1999 23:45:49 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902121146.GAA02357@cally.south.mpcs.com> from "Howard Goldstein" at Feb 12, 99 06:46:58 am X-Mailer: ELM [version 2.4 PL25] 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 > : > > > Matthew Dillon writes: > : > > > > The problem is that linux updates the timeval structure on return, > : > > > > telling you how much time is left. > : > : Linux doesn't do this in the default implementation any more. They > : have a seperate system call that still does this. > > This would save me a gettimeofday() call and some math if we had a > call for this too. > > : [...] > : When writing new code. > > Yes, for that. > > Realtime signals would help almost as much, perhaps in a more portable > way. man setitimer Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 16:15:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29193 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 16:15:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29188 for ; Fri, 12 Feb 1999 16:15:49 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA14833; Fri, 12 Feb 1999 17:21:46 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd014780; Fri Feb 12 17:21:42 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA28440; Fri, 12 Feb 1999 17:15:36 -0700 (MST) From: Terry Lambert Message-Id: <199902130015.RAA28440@usr01.primenet.com> Subject: Re: TEXT_SET() macro To: pixel@DotCom.FR (Emmanuel DELOGET) Date: Sat, 13 Feb 1999 00:15:36 +0000 (GMT) Cc: des@flood.ping.uio.no, hackers@FreeBSD.ORG In-Reply-To: <199902121506.PAA08837@excalibur.oceanis.net> from "Emmanuel DELOGET" at Feb 12, 99 04:06:19 pm X-Mailer: ELM [version 2.4 PL25] 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 wanna know how it's working both at compile time and at run time > ->> (for example, does a lkm (yes lkm, not kld, since I'm working on a > ->> 2.2.8 release...) can declare linker_sets, or add entries in a kernel > ->> linker_set, [for example , the sysctl_ one - seems that I'm very > ->> interested in sysctls :)]. Thaks a lot. The answer is that it can declare linker sets for its own use, but can not add entries to a kernel linker set, as in: > -> You can declare sysctls in modules, but the sysctl code will not pick > -> them up so it's pretty useless. There is work pending to make that > -> possible. > -> > This seems that the sysctl_order function is called only on > the system init (due to SYSINIT), but it may be possible > to find a workaroud (I'm working on this for 2.2.8, > on the base of the D. Rabson patch for -current). The reason that this doesn't work is that linker sets are an artifact of the linker. A set can only contain those things which were there at the time the linker was run. For kernel linker sets, this is whatever was there when the kernel was compiled. For linker sets in kernel modules, this is whatever was there at the time the module was loaded. Linker sets in modules are deceiving, if they shadow linker sets in the kernel. This is because the code is relinked against the kernel symbol space as part of loading the module (this is true of both the lkm and the kld code). The deception is that, from the kernel's point of view, the linker set that was shadowed did not change. From the modules point of view, it contains only the module data. In general, linker sets are a structure with an element count, followed by an array of pointers of element count length, followed be a NULL pointer. In application, the element count is not used, and instead the lists are traversed until the NULL pointer is encountered. Linker sets were originally implemented in the linker as a technology to support C++ static constructors and construction of pure virtual base class instances. I haven't investigated whether or not this use actually uses the element count, or if it ignores it, and traverses, like our application of linker sets for non-C++ array of object pointers aggregation. In order to make this work for KLD's, the linker set agregation would need to occur at runtime. There are very good reasons for doing this, the foremost being that an ELF section archiver could aggregate drivers with a generic (tiny) kernel in order to support boot devices not supported by the generic (tiny) kernel. It is very easy to envision a distribution kernel without any drivers or even VFS modules by default. Making KLD's linker sets work is another good reason. There are two technology changes which have to occur to be able to support runtime instead of linktime aggregation: 1) The element count *must* be deprecated entirely, for all cases. This may be a mildly complex change to the C++ compiler, if the element count is used instead of a list traversal. This may be the case, if NULL is a valid tag for a constructor/destructor place holder. A secondary issue is all code relying on linker set technology. Making these changes would fully normalize the lists. 2) Agregation of linker sets needs to span ELF sections. This last item is the most important, since the first item is like removing an appendix. The kernel code would have to treat the linker sets as a list of data on which a procedure needs to be run, *and which can be later rerun*, as needed. This means the linker set data itself can not be treated as static. Finally, the body of the kernel and the body of divisible drivers within the kernel must be treated seperately. The way to do this is to leverage the new ELF nature of the kernel, and implement the kernel and the divisible drivers in seperate ELF sections. This allows the driver to be later severed, if necessary, without damaging what would otherwise be a static aggregate list. I know that GCC supports ELF section attribution of code via a #pragma, per the Visual C++ compiler, in its effort to supply a compiler capable of compiling Windows 95/98/NT/CE code, though I don't know if this has been echo'ed into compilers for all platforms (e.g.: Linux and FreeBSD). You would probably have to implement an inline function identification semantic, or something similar, in order to apply section naming to entire drivers. FreeBSD would also have to relink objects that implemented a single driver from multiple source files, into a single section-attributed module. At that point, you would be able to, at load time, treat the sysctl linker set data atrributed sections as a continuation of the initialization iteration that occurred at system load. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 16:30:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01338 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 16:30:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01333 for ; Fri, 12 Feb 1999 16:30:48 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA24529; Sat, 13 Feb 1999 11:00:46 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA40306; Sat, 13 Feb 1999 11:00:45 +1030 (CST) Message-ID: <19990213110045.U54333@lemis.com> Date: Sat, 13 Feb 1999 11:00:45 +1030 From: Greg Lehey To: Khetan Gajjar , FreeBSD Hackers Subject: Re: Kernel trap error ? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Khetan Gajjar on Sat, Feb 13, 1999 at 12:32:41AM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 13 February 1999 at 0:32:41 +0200, Khetan Gajjar wrote: > Hi. > > I saw that my 4-CURRENT box from 8 February dropped to ddb > after my last make world. I'm not sure what the trap indicates > "caused" the problem. > > The error is > "Kernel type 12 trap, code=0 > Stopped at vfs_msync+0x20 : movl 0x28(%ebx),%edi" > > Does anyone know what this means ? Yes. You've had some kind of a bug. > My kernel config and dmesg is listed below. What we'd like to see would be a backtrace from the point where the bug occurred. Did you take a dump? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 16:31:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01456 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 16:31:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01439 for ; Fri, 12 Feb 1999 16:31:43 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA12666; Fri, 12 Feb 1999 17:31:36 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd012588; Fri Feb 12 17:31:31 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA29859; Fri, 12 Feb 1999 17:31:19 -0700 (MST) From: Terry Lambert Message-Id: <199902130031.RAA29859@usr01.primenet.com> Subject: Re: dlopen and ELF v. a.out To: erich@lodgenet.com (Eric L. Hernes) Date: Sat, 13 Feb 1999 00:31:18 +0000 (GMT) Cc: hackers@FreeBSD.ORG, erich@lodgenet.com In-Reply-To: <199902121628.KAA29685@jake.lodgenet.com> from "Eric L. Hernes" at Feb 12, 99 10:28:33 am X-Mailer: ELM [version 2.4 PL25] 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've been looking at x11amp, and I've run into a bit of a problem. > The program is set up as a program and a few shared-library plug-ins. > The shared libs all have some common symbol names in global scope, > (obviously) to provide an interface between the program and the plugin. > > What happens, though is that the plug-ins aren't very well encapsulated, > so there's big time global symbol polution. If the plug-ins were contained > in one .c module, I could just declare the offending symbols as static, > and all would be fine. But the plug-ins are often aggregates where > some symbols need to be seen from different c-sources. > > So is there any way to get the linker to export only specific symbols, > and hide the rest (and resolve them internally to the lib)? Use ld -r to make a single object per module. See also -x and -X, if you are willing to edit symbol names. You may also look at -s, in combination with either -defsym or --wrap, though I'm not sure about precedence. You could also modify your test program: > Attached is a test prog that illustrates the problem. There is two [ ... ] > for(i=0;i<3;i++) { > asprintf(&pn, "%s/test%d.so", cwd, i); > h = dlopen(pn, RTLD_NOW); > if (h) { > fp = dlsym(h, "testFunction"); > if (fp){ > fprintf(stderr, "got fp at %p\n", fp); > m = fp(); > fprintf(stderr, "message: %s\n", m); > } > } else { > warn("%s: dlopen failed", pn); > } > free(pn); dlclose( h); > } This is probably not an option for you, I'm betting, if the code is that promiscuous. The resoloution order is not specific; a.out's dlopen (apparently) puts newer symbols first, so FreeBSD's behaviour in that case is not really incorrect. One final alternative would be to correct the namespace pollution, and submit the changes back. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 17:34:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08157 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 17:34:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08130 for ; Fri, 12 Feb 1999 17:34:48 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id BAA06881; Sat, 13 Feb 1999 01:34:05 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.2) with ESMTP id BAA58003; Sat, 13 Feb 1999 01:33:56 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902130133.BAA58003@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG Subject: Re: ppp server side startup commands In-reply-to: Your message of "Fri, 12 Feb 1999 23:40:05 GMT." <199902122340.QAA26002@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Feb 1999 01:33:55 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > To solve the problem, though: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > The PPP server should obtain IP addresses via DHCP. Sounds a bit messy - does ppp have to manage the lease information (I haven't read the doc above yet) ? It's far easier & more manageable to ask ppp to assign a dynamic IP or point it at a radius server. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 18:15:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12129 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 18:15:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12122 for ; Fri, 12 Feb 1999 18:15:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA20356; Fri, 12 Feb 1999 19:15:51 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd020261; Fri Feb 12 19:15:43 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA27651; Fri, 12 Feb 1999 19:15:36 -0700 (MST) From: Terry Lambert Message-Id: <199902130215.TAA27651@usr05.primenet.com> Subject: Re: ppp server side startup commands To: brian@Awfulhak.org (Brian Somers) Date: Sat, 13 Feb 1999 02:15:35 +0000 (GMT) Cc: tlambert@primenet.com, phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902130133.BAA58003@keep.lan.Awfulhak.org> from "Brian Somers" at Feb 13, 99 01:33:55 am X-Mailer: ELM [version 2.4 PL25] 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 > > To solve the problem, though: > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > > > The PPP server should obtain IP addresses via DHCP. > > Sounds a bit messy - does ppp have to manage the lease information (I > haven't read the doc above yet) ? > > It's far easier & more manageable to ask ppp to assign a dynamic IP > or point it at a radius server. The IETF DHC working group would prefer that all software that obtains IP addresses from a pool use DHCP to do so. That includes RADIUS servers. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 18:33:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13893 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 18:33:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mailhub.psn.ie (mailhub.psn.ie [194.106.150.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13887 for ; Fri, 12 Feb 1999 18:33:45 -0800 (PST) (envelope-from ad@psn.ie) Received: from gromit.psn.ie ([194.106.150.251] helo=psn.ie ident=soprano) by mailhub.psn.ie with esmtp (Exim 2.12 #1) id 10BUj7-0001yb-00 for freebsd-hackers@FreeBSD.ORG; Sat, 13 Feb 1999 02:22:37 +0000 Message-ID: <36C4E23E.4C38502D@psn.ie> Date: Sat, 13 Feb 1999 02:23:58 +0000 From: Andy Doran Organization: Pobalscoil Neasain X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: ISA DMA problems if >= 512 Mb RAM? References: <199902122303.AAA05641@dorifer.heim3.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > play audio, the result is a panic: "isa_dmacheck: no physical > page present". Olivier reports this problem with the SB driver; after upgrading to 3.0 I'm seeing this about once a week, when I tar to /dev/fd0. Is this a problem with the ISA DMA code? Andy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 18:34:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13978 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 18:34:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13914 for ; Fri, 12 Feb 1999 18:34:01 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.2/8.9.1) with ESMTP id VAA59322; Fri, 12 Feb 1999 21:32:37 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199902130232.VAA59322@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: brian@Awfulhak.org (Brian Somers), phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ppp server side startup commands References: <199902130215.TAA27651@usr05.primenet.com> In-reply-to: Your message of "Sat, 13 Feb 1999 02:15:35 GMT." <199902130215.TAA27651@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Feb 1999 21:32:37 -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > To solve the problem, though: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > > > > > The PPP server should obtain IP addresses via DHCP. > > > > Sounds a bit messy - does ppp have to manage the lease information (I > > haven't read the doc above yet) ? > > > > It's far easier & more manageable to ask ppp to assign a dynamic IP > > or point it at a radius server. > > The IETF DHC working group would prefer that all software that > obtains IP addresses from a pool use DHCP to do so. > > That includes RADIUS servers. This is just nonsense. Both DHCP and PPP IPCP are used to communicate addresses to end users; each has a particular application where it's most suited. RADIUS servers supply service information to a NAS box. In many cases, the RADIUS response from the server might return a static address (and associated route), or perhaps a token which causes an IP address to get allocated out of a pool. DHCP does not have rich enough semantics to be used as a database query mechanism for a RADIUS server to use. DHCP is for use by the end-system to discover configuration information and not as some sort of generalized query mechanism. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 18:35:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14083 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 18:35:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14069 for ; Fri, 12 Feb 1999 18:35:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id SAA10171; Fri, 12 Feb 1999 18:35:03 -0800 (PST) (envelope-from dillon) Date: Fri, 12 Feb 1999 18:35:03 -0800 (PST) From: Matthew Dillon Message-Id: <199902130235.SAA10171@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG Subject: FreeBSD mention in LWN interview with A.C. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There is a small but interesting FreeBSD mention in LWN in an interview with Linux's Alan Cox. http://lwn.net/1999/features/ACInterview/ The whole article is interesting. I sure hope the linux people get a source control system together soon, it really sounds like Linus is getting strained. I checked out the linux kernel list archives and it looks like CVS has been suggested, but there's always someone who has had a really bad experience with it and that is stopping them from using it. Maybe someone in this group with ties into the linux groups can casually mention how well CVS is working for us to maybe get them to move to it a little more quickly. I have no doubt that they will be forced to do it at sometime or another. The sooner they do it, the better. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 19:18:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18836 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 19:18:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from picnic.mat.net (b133.mat.net [206.246.122.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18822 for ; Fri, 12 Feb 1999 19:18:18 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id WAA56286; Fri, 12 Feb 1999 22:16:27 -0500 (EST) Date: Fri, 12 Feb 1999 22:16:27 -0500 (EST) From: Chuck Robey To: Terry Lambert cc: phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG Subject: Re: ppp server side startup commands In-Reply-To: <199902122340.QAA26002@usr01.primenet.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 Fri, 12 Feb 1999, Terry Lambert wrote: > > Or you could do something entirely simpler. > > > > Write a shell script containing the line - make SURE you set the path > > (i.e. do this: > > > > PATH=/usr/bin:/usr/sbin:/sbin:/usr/local/bin > > ) > > > > Have root own it and make it setuid 0. (chmod u+s yourscript) > > Shell scripts aren't allowed to be SUID root. > > > To solve the problem, though: > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > The PPP server should obtain IP addresses via DHCP. Terry, these are static IPs (like I said). Why would I want to get IP numbers that I already know of? I have to experiment with Brian's solution (which bothers me much more, because it doesn't seem to give me a chance to tell ppp what the additional IP number is). I haven't yet tested Brian's answer, but I was under the impression that DHCP was used to ID machines; wny would I want to ID a machine I already know of? OTOH, thanks for the info about the script. I was fairly sure the idea of making any script suid was really wrong, I'd forgotten why that was so. I knew about the sudo suggestion, but using sudo just seems like a security problem. Just in case you forgot, the idea was, ON THE SERVER SIDE ONLY, to take and allow for an extra static IP on the client side. This meant one more arp and one more route command one the server. I can handle the client side fine now. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 20:57:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26857 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 20:57:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from psf.Pinyon.ORG (ppp1-174.presc.dialup.futureone.com [209.250.11.174]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26852 for ; Fri, 12 Feb 1999 20:57:09 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.2/8.9.2) with ESMTP id VAA09966 for ; Fri, 12 Feb 1999 21:53:38 -0700 (MST) (envelope-from rcarter@psf.Pinyon.ORG) Message-Id: <199902130453.VAA09966@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-reply-to: Your message of "Fri, 12 Feb 1999 11:21:23 PST." <199902121921.LAA06904@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Feb 1999 21:53:38 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %:> What were the requirements for NASA/Ames? %:> %:> %: %:Replacement for the Convex (chuck && scott) machines, i.e., > 900GB %:reliable standard filesystem that you could then put RASH hooks into %:later. Whether these would be via locally attached disk or via a HIPPI %:network block device ('raw frame' driver) was/in indeterminate. %: %:It's not clear whether anything but NetBSD will be used for these %:machines, but there had been so many hardware related and also possible %:FFS related problems with the MSS3 project that I was allowed to go off %:and search for possible alternatives. Digital Unix/ADVFS as is Solaris/UFS %:and Solaris/SAMFS (LSC's produce) are also candidates, but those are less %:attractive because they're not open source solutions. At any rate, at the %:time I was doing this, I could not demonstrate FreeBSD/FFS to be a %:superior combo than NetBSD/FFS, hence the term 'loss'. %: %:-matt % % If you need absolute reliability, I would seriously consider a NetApp. % I'd choose that over everything - solaris, irix, *bsd, linux, NT. You % name it. % If the solution were bought off the shelf, there would be no need for NASA Ames. Therefore... Actually, what they want is something that can be claimed to evolve apace with their spreadsheeted extrapolations of user needs for the next 5 and 10 years. These extrapolations more or less follow Moore's law applied to things like current storage requirements, so it's always an interesting process keeping ahead, given NASA's acquisition process. Russell % -Matt % Matthew Dillon % % % %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 Fri Feb 12 22:13:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA01926 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 22:13:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA01921 for ; Fri, 12 Feb 1999 22:13:11 -0800 (PST) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.1a/8.9.1) id AAA03418; Sat, 13 Feb 1999 00:12:50 -0600 (CST) Message-ID: <19990213001250.E25943@futuresouth.com> Date: Sat, 13 Feb 1999 00:12:50 -0600 From: "Matthew D. Fuller" To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. References: <199902130235.SAA10171@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199902130235.SAA10171@apollo.backplane.com>; from Matthew Dillon on Fri, Feb 12, 1999 at 06:35:03PM -0800 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 12, 1999 at 06:35:03PM -0800, a little birdie told me that Matthew Dillon remarked > There is a small but interesting FreeBSD mention in LWN in an interview > with Linux's Alan Cox. > > http://lwn.net/1999/features/ACInterview/ I must say that it's one of the most rounded and best thought-out interviews I've seen recently. It seems in places that LWN was pushing for more condemnation and/or cheerleading than Alan was willing to provide, and he seemed to carry it off nicely. I'd call that a definate 'link me!' interview. --- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew Fuller http://www.over-yonder.net/~fullermd | * fullermd@futuresouth.com fullermd@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | * is because I haven't figured out how to light the * | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 12 22:17:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA02297 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 22:17:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA02292 for ; Fri, 12 Feb 1999 22:17:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id WAA21533; Fri, 12 Feb 1999 22:17:07 -0800 Date: Fri, 12 Feb 1999 22:17:07 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <199902130235.SAA10171@apollo.backplane.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 Larry (McVoy)'s stuff is pretty cool. On Fri, 12 Feb 1999, Matthew Dillon wrote: > There is a small but interesting FreeBSD mention in LWN in an interview > with Linux's Alan Cox. > > http://lwn.net/1999/features/ACInterview/ > > The whole article is interesting. I sure hope the linux people get a > source control system together soon, it really sounds like Linus is > getting strained. I checked out the linux kernel list archives and > it looks like CVS has been suggested, but there's always someone who has > had a really bad experience with it and that is stopping them from using > it. Maybe someone in this group with ties into the linux groups can > casually mention how well CVS is working for us to maybe get them to move > to it a little more quickly. I have no doubt that they will be forced to > do it at sometime or another. The sooner they do it, the better. > > -Matt > Matthew Dillon > > > 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 Fri Feb 12 23:30:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA06737 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 23:30:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06732 for ; Fri, 12 Feb 1999 23:30:57 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id XAA21728; Fri, 12 Feb 1999 23:30:49 -0800 Date: Fri, 12 Feb 1999 23:30:48 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: Dru Nelson , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <199902121921.LAA06904@apollo.backplane.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 > :-matt > > If you need absolute reliability, I would seriously consider a NetApp. > I'd choose that over everything - solaris, irix, *bsd, linux, NT. You > name it. They're even less open than Microsoft. A newer Novell. And I know whereof of what I speak- I worked with a large chunk of these folks either at Auspex or Sun. There are two factors being pursued- one is service goals, and the other is research/development/tech-transfer. If the former goal was the only one, *BSD/Linux would not be considered as it isn't a warrantable item. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 00:41:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12741 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 00:41:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from stage1.thirdage.com (stage1.thirdage.com [204.74.82.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA12736 for ; Sat, 13 Feb 1999 00:41:11 -0800 (PST) (envelope-from jal@thirdage.com) Received: from gigi (gigi.thirdage.com [204.74.82.169]) by stage1.thirdage.com (8.9.1/8.9.1) with SMTP id AAA03389; Sat, 13 Feb 1999 00:40:47 -0800 (PST) Message-Id: <4.1.19990213000333.0765d230@204.74.82.151> X-Sender: jal@204.74.82.151 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 13 Feb 1999 00:41:01 -0800 To: mjacob@feral.com From: Jamie Lawrence Subject: Re: softupdates Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: References: <199902121921.LAA06904@apollo.backplane.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 spent an absurd amount of cash on a Netapp recently. I don't know that I chose correctly; I'm having problems. When it works, It is frankly amazing... when not, the cost compounds the annoyance. >> If you need absolute reliability, I would seriously consider a NetApp. >> I'd choose that over everything - solaris, irix, *bsd, linux, NT. You >> name it. > >They're even less open than Microsoft. A newer Novell. And I know whereof >of what I speak- I worked with a large chunk of these folks either at >Auspex or Sun. In some respects, I know you're right. In others, Netapp is the shit. I'm not going to argue credentials; only performance. I don't yet know that they're more reliable; I'm having trouble with the multiport interface (4 100bT on a card, connected to some Solaris boxes, to be clear on how off-topic this is). When it does work, it is all {T|t}hey promise. I have yet to see it balk at 5 saturated 100Bt FD connections, at least when I can make them all work. I suspect I'm doing something wrong with mine. I will post if that's not the case. In any case, the vast majority of the time, the Netapp is amazingly fast and robust (if not awe inspiring when one considers cost...). >There are two factors being pursued- one is service goals, and the other >is research/development/tech-transfer. If the former goal was the only >one, *BSD/Linux would not be considered as it isn't a warrantable item. Sure. That's why we spent a (frankly) ridiculous amount of money on a Netapp. Support would have saved us a bundle, maybe. Real world, right-here-right-now-we're-doing-it-today applications tend to have nontechnical restraints imposed on them, which hurt; having technical (non)-assurances layered on top create a barrier that no zealot can honestly penetrate, FreeBSD or no. I hate (will become hated) to say this, but if taking on Netapp is a goal, there's a huge hardware requirement for the port, and then there's probably a steep performance curve. They do support "common" protocols, which work most anywhere. At a price. >-matt --j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 00:57:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14315 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 00:57:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14309 for ; Sat, 13 Feb 1999 00:57:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id AAA14274; Sat, 13 Feb 1999 00:57:49 -0800 (PST) (envelope-from dillon) Date: Sat, 13 Feb 1999 00:57:49 -0800 (PST) From: Matthew Dillon Message-Id: <199902130857.AAA14274@apollo.backplane.com> To: hackers@FreeBSD.ORG Subject: VOP_REMOVE() rules for freeing a_cnp ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can't make heads or tails of the VOP_REMOVE() rules for freeing a_cnp. The man page doesn't say anything about having to free cnp. ufs_remove() doesn't bother. nfs_remove() always frees it. And the unlink() system call seems to expect the cnp to be freed by the VOP_REMOVE() function. Typically the rule for freeing a struct componentname in a VOP routine is 'free it if you return an error, otherwise only free it if the SAVESTART flag is not set in cn_flags'. I would appreciate it if a VFS guru could look at this junk and tell me whos right. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 01:36:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17483 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 01:36:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA17476 for ; Sat, 13 Feb 1999 01:36:08 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id SAA00370; Sat, 13 Feb 1999 18:36:04 +0900 (JST) Message-ID: <36C54726.B3A23548@newsguy.com> Date: Sat, 13 Feb 1999 18:34:30 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon CC: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. References: <199902130235.SAA10171@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > The whole article is interesting. I sure hope the linux people get a > source control system together soon, it really sounds like Linus is > getting strained. I checked out the linux kernel list archives and > it looks like CVS has been suggested, but there's always someone who has > had a really bad experience with it and that is stopping them from using > it. Maybe someone in this group with ties into the linux groups can > casually mention how well CVS is working for us to maybe get them to move > to it a little more quickly. I have no doubt that they will be forced to > do it at sometime or another. The sooner they do it, the better. Interestingly, there are people here that don't like CVS either. Now and then there is a thread about using something else for source control. It always dies because there is now free alternative that fixes all problems with cvs, so there wouldn't be much of a benefit. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Well, as a computer geek, I have to believe in the binary universe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 01:41:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17814 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 01:41:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA17806 for ; Sat, 13 Feb 1999 01:41:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id BAA14698; Sat, 13 Feb 1999 01:41:37 -0800 (PST) (envelope-from dillon) Date: Sat, 13 Feb 1999 01:41:37 -0800 (PST) From: Matthew Dillon Message-Id: <199902130941.BAA14698@apollo.backplane.com> To: hackers@FreeBSD.ORG Subject: NFS VOP calls (was Re: Lots of "panic: vrele: negative ref cnt" ) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It looks like there are a number of problems, but the one reported above is the only one that gets 'hit'. The NFS code pretty much ignores the VOP semantics for freeing path name elements but it just happens to get called with the path name (cnp) structure flagged the way it happens to decide to use it, so it works. But there is probably some leakage of NAMEI nodes when NFS errors occur. I've only committed the fix for the vrele panic to -3.x. The fix to the rest of the mis-used path elements has been committed to -4.x and will not be backported to -3.x until after the release since I'm not 100% sure those other fixes are correct. -3.x should not be detrimentally effected by not having the other junk in. Confused yet? :-) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 01:44:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA18161 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 01:44:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18154 for ; Sat, 13 Feb 1999 01:44:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id BAA14725; Sat, 13 Feb 1999 01:44:02 -0800 (PST) (envelope-from dillon) Date: Sat, 13 Feb 1999 01:44:02 -0800 (PST) From: Matthew Dillon Message-Id: <199902130944.BAA14725@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. References: <199902130235.SAA10171@apollo.backplane.com> <36C54726.B3A23548@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Interestingly, there are people here that don't like CVS either. Now :and then there is a thread about using something else for source :control. It always dies because there is now free alternative that :fixes all problems with cvs, so there wouldn't be much of a benefit. : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com :dcs@freebsd.org There isn't much out there that we could replace CVS with, at least not that's proven, free, and works (mostly) without error with lots of people using it all at once. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 04:09:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01275 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 04:09:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bbs.mpcs.com (bbs.mpcs.com [209.101.88.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01270 for ; Sat, 13 Feb 1999 04:09:07 -0800 (PST) (envelope-from hg@penny.n2wx.ampr.org) Received: from pickle.n2wx.ampr.org (cc1017255-a.srst1.fl.home.com [24.3.122.197]) by bbs.mpcs.com (8.8.8/8.8.8/MPCS spamzap) with ESMTP id HAA11146; Sat, 13 Feb 1999 07:08:51 -0500 Received: (from root@localhost) by pickle.n2wx.ampr.org (8.9.2/8.8.2/n2wx) id HAA25761; Sat, 13 Feb 1999 07:08:49 -0500 (EST) Received: from penny.n2wx.ampr.org (penny.n2wx.ampr.org [172.16.0.5]) by pickle.n2wx.ampr.org (8.9.2/8.9.2/n2wx) with ESMTP id HAA25746; Sat, 13 Feb 1999 07:08:40 -0500 (EST) (envelope-from hg@n2wx.ampr.org) Received: (from hg@localhost) by penny.n2wx.ampr.org (8.9.2/8.8.8/n2wx) id HAA03346; Sat, 13 Feb 1999 07:08:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14021.27462.556760.465144@penny.south.mpcs.com> Date: Sat, 13 Feb 1999 07:08:38 -0500 (EST) From: Howard Goldstein To: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902122345.QAA26318@usr01.primenet.com> References: <199902121146.GAA02357@cally.south.mpcs.com> <199902122345.QAA26318@usr01.primenet.com> X-Mailer: VM 6.62 under Emacs 19.34.1 Organization: disorganization Reply-To: hgoldste@bbs.mpcs.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > Realtime signals would help almost as much, perhaps in a more portable > > way. > > man setitimer 'Sir, may I please have some more?' I use it...I always feel dirty when I have setitimer signal a clumsy monolith that is itself in many ways like the one that deals with the aftermath of a select(). More timers, a la posix realtime signals (p1003B? I'm sure I'm citing the wrong posix id) would be cleaner, and would make it easier to write pthreaded applications. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 04:42:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA03831 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 04:42:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from slewsys.org ([140.174.112.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA03823 for ; Sat, 13 Feb 1999 04:42:39 -0800 (PST) (envelope-from alm@SlewSys.Org) Received: from slewsys.org (localhost.slewsys.org [127.0.0.1]) by slewsys.org (8.9.2/8.9.2) with ESMTP id EAA09581; Sat, 13 Feb 1999 04:41:51 -0800 (PST) (envelope-from alm@slewsys.org) Message-Id: <199902131241.EAA09581@slewsys.org> To: tech@openbsd.org, tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG cc: alm@SlewSys.Org Subject: /bin/test bugs and proposed patch Date: Sat, 13 Feb 1999 04:41:51 -0800 From: "Andrew_L. Moore" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Below is a patch to *BSD /bin/test which allows TEST.sh (from the source directory) to complete with 0 syntax errors/fails. Some additional cases which the patch fixes are also included below. In particular, the current /bin/test fails on reasonably common expressions of the form: test -d X -o -f X, where the filename, X, is also a valid /bin/test option (such as `-r'). The switch{} for POSIX compatibility is removed because it actually adds inconsistency. For instance, test \( = \) -a \( = \) evaluates to true on many (all?) test(1)'s, yet a rigid interpretation of POSIX says test \( = \) is false. Several test(1)'s, including Korn's ksh(1), evaluate this to true. If no one disagrees with these changes, the following patches will be submitted for inclusion in the source tree(s). Finally, does anyone know of a comprehensive regression suite for test(1)? Thanks. -Andrew Moore ---- Cut Here ---- --- test.c 1999/02/12 22:39:53 1.1 +++ test.c 1999/02/13 11:48:53 @@ -117,6 +117,8 @@ struct filestat fs; char c, **ap, *opname, *p; int binary, nest, op = 0, pri, ret_val, skipping; + int expecting_unary_arg; + int expecting_binary_arg; if ((p = argv[0]) == NULL) errx(2, "test: argc is zero"); @@ -130,52 +132,6 @@ fs.name = NULL; /* - * Test(1) implements an inherently ambiguous grammer. In order to - * assure some degree of consistency, we special case the POSIX 1003.2 - * requirements to assure correct evaluation for POSIX scripts. The - * following special cases comply with POSIX P1003.2/D11.2 Section - * 4.62.4. - */ - switch(argc - 1) { - case 0: /* % test */ - return (1); - break; - case 1: /* % test arg */ - return (argv[1] == NULL || *argv[1] == '\0') ? 1 : 0; - break; - case 2: /* % test op arg */ - opname = argv[1]; - if (IS_BANG(opname)) - return (*argv[2] == '\0') ? 0 : 1; - else { - ret_val = posix_unary_op(&argv[1]); - if (ret_val >= 0) - return (ret_val); - } - break; - case 3: /* % test arg1 op arg2 */ - if (IS_BANG(argv[1])) { - ret_val = posix_unary_op(&argv[1]); - if (ret_val >= 0) - return (!ret_val); - } else if (lookup_op(argv[2], andor_op) < 0) { - ret_val = posix_binary_op(&argv[1]); - if (ret_val >= 0) - return (ret_val); - } - break; - case 4: /* % test ! arg1 op arg2 */ - if (IS_BANG(argv[1]) && lookup_op(argv[3], andor_op) < 0 ) { - ret_val = posix_binary_op(&argv[2]); - if (ret_val >= 0) - return (!ret_val); - } - break; - default: - break; - } - - /* * We use operator precedence parsing, evaluating the expression as * we parse it. Parentheses are handled by bumping up the priority * of operators using the variable "nest." We use the variable @@ -187,47 +143,70 @@ opsp = opstack + STACKSIZE; valsp = valstack; nest = skipping = 0; + expecting_unary_arg = 0; + expecting_binary_arg = 0; if (*ap == NULL) { valstack[0].type = BOOLEAN; valstack[0].u.num = 0; goto done; } for (;;) { - opname = *ap++; - if (opname == NULL) + if ((opname = *ap++) == NULL) syntax(); - if (opname[0] == '(' && opname[1] == '\0') { + else if (!expecting_binary_arg && !expecting_unary_arg && + *ap && opname[0] == '(' && opname[1] == '\0') { nest += NESTINCR; + expecting_unary_arg = 0; continue; - } else if (*ap && (op = lookup_op(opname, unary_op)) >= 0) { + } else if (!expecting_binary_arg && !expecting_unary_arg && + *ap && (op = lookup_op(opname, unary_op)) >= 0) { if (opsp == &opstack[0]) overflow(); --opsp; opsp->op = op; opsp->pri = op_priority[op] + nest; + expecting_unary_arg = op != NOT; continue; + } else if (expecting_unary_arg && + *ap && (op = lookup_op(opname, binary_op)) >= 0 && + lookup_op(opname, andor_op) < 0) { + op += FIRST_BINARY_OP; + pri = op_priority[op] + nest; + + /* + * Previous unary op is evidently a binary arg, + * so move it from opstack to valstack. + */ + ++opsp; + valsp->type = STRING; + valsp->u.string = *(ap - 2); + valsp++; + + expecting_unary_arg = 0; + expecting_binary_arg = 1; } else { valsp->type = STRING; valsp->u.string = opname; valsp++; - } - for (;;) { - opname = *ap++; - if (opname == NULL) { - if (nest != 0) - syntax(); - pri = 0; - break; - } - if (opname[0] != ')' || opname[1] != '\0') { - if ((op = lookup_op(opname, binary_op)) < 0) + expecting_binary_arg = expecting_unary_arg = 0; + for (;;) { + if ((opname = *ap++) == NULL) { + if (nest != 0) + syntax(); + pri = 0; + break; + } else if (opname[0] != ')' || + opname[1] != '\0') { + if ((op=lookup_op(opname, binary_op))<0) + syntax(); + op += FIRST_BINARY_OP; + pri = op_priority[op] + nest; + expecting_binary_arg = + lookup_op(opname, andor_op) < 0; + break; + } else if ((nest -= NESTINCR) < 0) syntax(); - op += FIRST_BINARY_OP; - pri = op_priority[op] + nest; - break; } - if ((nest -= NESTINCR) < 0) - syntax(); } while (opsp < &opstack[STACKSIZE] && opsp->pri >= pri) { binary = opsp->op; --- TEST.sh 1999/02/13 12:18:28 1.1 +++ TEST.sh 1999/02/13 11:52:38 @@ -131,6 +131,42 @@ t 0 '"a" -a ! ""' t 1 '""' t 0 '! ""' + +t 1 '-e -r' +t 1 '-e -r -a -e -r' +t 0 '! -e -r -o -e -r' +t 1 '-e -r -a ! -e -r' +t 0 '-e -r -o ! -e -r' + +t 1 '-e -a' +t 1 '-e -a -a -e -a' +t 0 '! -e -a -o -e -a' +t 1 '-e -a -a ! -e -a' +t 0 '-e -a -o ! -e -a' + +t 1 '-e -a -o -e = -a' +t 1 '-e -a -o -a = -e' +t 0 '-e -a -o ! -e = -a' +t 0 '-e -a -o ! -a = -e' + +t 1 '! b = b' +t 0 '! b = 0' +t 0 '! b = 1' + +t 1 '\( -h = -h \) -a \( a = -h \)' +t 0 '\( -h = -h \) -o \( a = -h \)' +t 0 '\( a = -h \) -o \( -h = -h \)' + +t 0 '\(' +t 0 '\( = \)' +t 0 '\( = \) -a \( = \)' + +t 1 '-e \(' +t 1 '\( -e \( \)' +t 1 '\( -e \( \) -o \( -e \( \)' +t 1 '\( -e \( \) -o \( -e = \( \)' + +t 0 '\( \( \( a = -h \) \) -o \( -h = -h \) \)' echo "" echo "Syntax errors: $ERROR Failed: $FAILED" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 05:51:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA08970 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 05:51:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA08965 for ; Sat, 13 Feb 1999 05:51:47 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id NAA46119; Sat, 13 Feb 1999 13:50:25 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 13 Feb 1999 13:50:24 +0000 (GMT) From: Doug Rabson To: Matthew Dillon cc: hackers@FreeBSD.ORG Subject: Re: VOP_REMOVE() rules for freeing a_cnp ? In-Reply-To: <199902130857.AAA14274@apollo.backplane.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 Sat, 13 Feb 1999, Matthew Dillon wrote: > I can't make heads or tails of the VOP_REMOVE() rules for freeing > a_cnp. > > The man page doesn't say anything about having to free cnp. > > ufs_remove() doesn't bother. > > nfs_remove() always frees it. > > And the unlink() system call seems to expect the cnp to be freed > by the VOP_REMOVE() function. > > Typically the rule for freeing a struct componentname in a VOP > routine is 'free it if you return an error, otherwise only free > it if the SAVESTART flag is not set in cn_flags'. > > I would appreciate it if a VFS guru could look at this junk and > tell me whos right. I'm sure that someone changed the semantics for who frees the pathnames and who releases the vnodes during the 3.0 development cycle but I can't quite remember who (Mike someone maybe, not Mike Smith). I think that the intention was to always free the path and release the vnodes in the caller, not in the filesystem (which was supposed to make it easier to write layers). I have a vague recollection that VOP_RENAME was the only one which wasn't changed since it does some wildly complicated things with its vnodes. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 06:34:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11506 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 06:34:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from server.noc.demon.net (server.noc.demon.net [193.195.224.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA11485 for ; Sat, 13 Feb 1999 06:33:57 -0800 (PST) (envelope-from fanf@demon.net) Received: by server.noc.demon.net; id OAA21754; Sat, 13 Feb 1999 14:33:55 GMT Received: from fanf.noc.demon.net(195.11.55.83) by inside.noc.demon.net via smap (3.2) id xma021732; Sat, 13 Feb 99 14:33:52 GMT Received: from fanf by fanf.noc.demon.net with local (Exim 1.73 #2) id 10Bg8l-0007WQ-00; Sat, 13 Feb 1999 14:33:51 +0000 To: hackers@FreeBSD.ORG From: Tony Finch Subject: Re: PIPE_BUF In-Reply-To: <199902102342.PAA01160@dingo.cdrom.com> References: Message-Id: Date: Sat, 13 Feb 1999 14:33:51 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: >> I've been looking at the Apache code for doing buffered writes to >> logs, which it attempts to do in such a way that log records are not >> split across buffer boundaries. It therefore buffers up to PIPE_BUF >> bytes to be written in one go. > >If it's actually writing into a pipe, it should write as much as >possible at once under FreeBSD to get best performance. How likely am I to fall foul of concurrency issues when doing that? The reason Apache does what it does is to avoid writes from different httpds to the same pipe getting confused with each other. Why should a large PIPE_BUF have a bad effect on interactive pipes? Is it simply because of the way stdio buffers writes? Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 08:07:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA17674 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 08:07:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA17659 for ; Sat, 13 Feb 1999 08:07:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id RAA02869 for ; Sat, 13 Feb 1999 17:07:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA49120 for hackers@FreeBSD.org; Sat, 13 Feb 1999 17:07:18 +0100 (MET) Date: Sat, 13 Feb 1999 17:07:18 +0100 From: Eivind Eklund To: hackers@FreeBSD.ORG Subject: RC splitting etc Message-ID: <19990213170717.V96008@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've put a small document attempting to list the requirements/nice-to-have's for a new rc system (besides the requirement that any new rc system would have to be acceptable to people in general) at http://www.freebsd.org/~eivind/newrc.html It also contains a couple of notes about things that could be of interest to an implementor. It'd be nice if those interested would read the requirments and tell me of the things I've missed (I'm sure there are some). This is not an attempt at pulling up the discussion about new rc systems again at this point; if I (or somebody else) come up with something that seems to solve enough of the requirements, that may happen, but for the time being I'm just gathering the background info to make it possible to have such a discussion in a useful form. Please keep any comments to private mail for the time being. Thanks! Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 08:40:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20440 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 08:40:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hp9000.chc-chimes.com (hp9000.chc-chimes.com [206.67.97.84]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20435 for ; Sat, 13 Feb 1999 08:40:49 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: from localhost by hp9000.chc-chimes.com with SMTP (1.39.111.2/16.2) id AA038642974; Sat, 13 Feb 1999 05:49:34 -0500 Date: Sat, 13 Feb 1999 05:49:34 -0500 (EST) From: Bill Fumerola To: Matthew Dillon Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <199902130944.BAA14725@apollo.backplane.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 Sat, 13 Feb 1999, Matthew Dillon wrote: > There isn't much out there that we could replace CVS with, at least > not that's proven, free, and works (mostly) without error with lots of > people using it all at once. Not to go Microsoft bashing, BUT... We used MS Sourcesafe here locally for about 4 years, I haven't heard a single person yet who's said "let's go back" or "CVS can't do XXX as well as SS could." WinCVS is a godsend for my point-and-click-only people too. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 09:37:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24735 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 09:37:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24729 for ; Sat, 13 Feb 1999 09:37:14 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.2) with ESMTP id JAA10485; Sat, 13 Feb 1999 09:37:00 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Bill Fumerola cc: Matthew Dillon , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-reply-to: Your message of "Sat, 13 Feb 1999 05:49:34 EST." Date: Sat, 13 Feb 1999 09:37:00 -0800 Message-ID: <10481.918927420@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If we wanted to use a commercial solution then the choice would be more than clear - Perforce! Our CVS repository meister(s) like it a lot and one can get copies of the perforce server for FreeBSD at the low low price of $1 (perforce's generous way of giving something back to the FreeBSD community). However, we don't want to use a commercial solution for lots of various reasons, not least of which the fact that we have one hell of a lot invested in CVS. Our CVS web stuff, the CTM delta generator, the ubiquitous CVSup program, all would have to be substantially redesigned for a new SCM tool and that would be a lot of work. - Jordan > On Sat, 13 Feb 1999, Matthew Dillon wrote: > > > There isn't much out there that we could replace CVS with, at least > > not that's proven, free, and works (mostly) without error with lots of > > people using it all at once. > > Not to go Microsoft bashing, BUT... > > We used MS Sourcesafe here locally for about 4 years, I haven't heard a > single person yet who's said "let's go back" or "CVS can't do XXX as well > as SS could." > > WinCVS is a godsend for my point-and-click-only people too. > > - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - > > > > > 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 Sat Feb 13 10:55:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03242 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 10:55:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sparks.net (gw.sparks.net [209.222.120.18]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA03236 for ; Sat, 13 Feb 1999 10:55:14 -0800 (PST) (envelope-from david@sparks.net) Received: from david by sparks.net with smtp (Exim 1.62 #5) id 10BkDY-0001bN-00; Sat, 13 Feb 1999 13:55:04 -0500 Date: Sat, 13 Feb 1999 13:55:04 -0500 (EST) From: To: freebsd-hackers@FreeBSD.ORG Subject: Need pointers on new scsi device type 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 Hi all:) I'm trying to make a Vela scsi mpeg2 decoder work under 2.2.8. This decoder takes power from the isa bus and all its commands over the scsi bus. The card shows up under the adaptec bios setup as "Vela" and "Decoder" but the kernel doesn't know what to do with it since it's not a tape, disk, or CD. Pointers and general guidelines welcome:) Thanks, --- David Miller ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 11:22:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05658 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 11:22:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA05649 for ; Sat, 13 Feb 1999 11:22:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA23366; Sat, 13 Feb 1999 11:21:32 -0800 Date: Sat, 13 Feb 1999 11:21:32 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Jamie Lawrence cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: <4.1.19990213000333.0765d230@204.74.82.151> 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 > > > >They're even less open than Microsoft. A newer Novell. And I know whereof > >of what I speak- I worked with a large chunk of these folks either at > >Auspex or Sun. > > In some respects, I know you're right. In others, Netapp is > the shit. I'm not going to argue credentials; only performance. Heh. I shouldn't have worded my last sentence that way. > > I don't yet know that they're more reliable; I'm having trouble with > the multiport interface (4 100bT on a card, connected to some Solaris > boxes, to be clear on how off-topic this is). > > When it does work, it is all {T|t}hey promise. I have yet to > see it balk at 5 saturated 100Bt FD connections, at least when I can > make them all work. I suspect I'm doing something wrong with mine. > I will post if that's not the case. In any case, the vast majority > of the time, the Netapp is amazingly fast and robust (if not awe > inspiring when one considers cost...). I'm not saying that they don't do really good work- they do. Much like the model at Auspex, they really optimize data paths and keep data paths separate from control paths. There's classic story for Auspex where the Host Processor (running SunOS) crashed and stayed crashed for some weeks before anyone noticed, despite being the main NFS server for that company. The problem with NetApp is like the problem with a monarchy- you can have a good monarch, and a lot of good may be accomplished. You can have a bad monarch and you all suffer and nothing can be done about it. That NetApp is wonderful and cost effective for today doesn't say what it will be next year. There are some who say that economic factors will ensure that if NetApp (or other like it, e.g. Microsoft) doesn't continue to provide the best product, they'll disappear from the market as customers desert them for better solutions. That's arrant nonsense for the short term (due to capital budget cycles, imperfect information, partially closed markets (can you spell 'oligopoly'?), and the lack of objective comparators (I mean, how do you compare NT's server management tools, Tivoli on Solaris, etc., except qualitatively?)) and irrelevant in the medium and long term. Because they're an intensely proprietary company where they *really* only care about the effectiveness of what they do (as measured in revenues and share value), almost to Randite intensity, I'm sometimes tempted to argue that the use of NetApp's products verges on social irresponsiblity. But that just exposes my weakness for hyperbole. > > >There are two factors being pursued- one is service goals, and the other > >is research/development/tech-transfer. If the former goal was the only > >one, *BSD/Linux would not be considered as it isn't a warrantable item. > > Sure. That's why we spent a (frankly) ridiculous amount of money on > a Netapp. Support would have saved us a bundle, maybe. Real world, > right-here-right-now-we're-doing-it-today applications tend to have > nontechnical restraints imposed on them, which hurt; having technical > (non)-assurances layered on top create a barrier that no zealot can > honestly penetrate, FreeBSD or no. > > I hate (will become hated) to say this, but if taking on Netapp is > a goal, there's a huge hardware requirement for the port, and then > there's probably a steep performance curve. No, their hardware is fairly standard. It started as being commodity PC motherboards, and is now, I believe, fairly standard Alpha motherboards (they do those, I believe). It's not a question of 'competing' with NetApp. It's also a difference of approach and philosophy. They claim to have no interest in an 'OS'- they just want to provide a toaster. If that were really the case then they wouldn't need as much administrative tools as they do have. It's not good to get wrapped up in the System for the sake of the System (as BSD or Solaris or NT zealots can do), but it's even less good to say that you aren't and thus attempt to oversimplify and make static things that by there very nature are protean and complex. NetApp wants your servers to be toasters or coffee grinders. In reality, your servers are organisms (virtual in that the users and maintainers are also part of the organism) that grow and make mistakes and learn. And also, eventually, die. Sigh. Sorry- very off topic. Won't happen again, and, no, I'm not joining one of the advocacy aliases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 11:23:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06102 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 11:23:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA06097 for ; Sat, 13 Feb 1999 11:23:54 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 11912 invoked from network); 13 Feb 1999 19:23:46 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 13 Feb 1999 19:23:46 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA05392; Sat, 13 Feb 1999 14:23:45 -0500 (EST) Message-Id: <199902131923.OAA05392@y.dyson.net> Subject: Re: PIPE_BUF In-Reply-To: from Tony Finch at "Feb 13, 99 02:33:51 pm" To: dot@dotat.at (Tony Finch) Date: Sat, 13 Feb 1999 14:23:45 -0500 (EST) Cc: hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (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 Tony Finch said: > Mike Smith wrote: > >> I've been looking at the Apache code for doing buffered writes to > >> logs, which it attempts to do in such a way that log records are not > >> split across buffer boundaries. It therefore buffers up to PIPE_BUF > >> bytes to be written in one go. > > > >If it's actually writing into a pipe, it should write as much as > >possible at once under FreeBSD to get best performance. > > How likely am I to fall foul of concurrency issues when doing that? > The reason Apache does what it does is to avoid writes from different > httpds to the same pipe getting confused with each other. > > Why should a large PIPE_BUF have a bad effect on interactive pipes? Is > it simply because of the way stdio buffers writes? > It isn't the PIPE_BUF size precisely, but if stdio makes the buffer size too big, the delay for the flush is sometimes too long for interactive use in command line operations. I am running with a special version of libc that causes pipe stdio buffers to flush more often, even though the maximum pipe size is large. I suggest making PIPE_BUF at least 4K (maybe even 8K), and then modifying stdio so that performs it's writes by default in smaller chunks (512bytes or 1K) if the process has a tty, and the file descriptor is a pipe. The reads should have the largest buffer that makes sense (at least the large PIPE_BUF size.) I really should take a look at the priority mgmt in sys_pipe to properly handle the case of small writes, so that the context switch rate for massive transfers isn't seriously adversely affected. It seems that the optimum I/O size in the stat block should still be large, so that applications that are not stdio based can still decide on their own the optimum I/O size for throughput. Those applications, since they are not stdio based, are taking more responsibility, and if they need to provide lower latency or higher throughput, then they can craft a more complete solution. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 13:03:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16559 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 13:03:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16552 for ; Sat, 13 Feb 1999 13:03:23 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id OAA46150; Sat, 13 Feb 1999 14:03:07 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199902132103.OAA46150@panzer.plutotech.com> Subject: Re: Need pointers on new scsi device type In-Reply-To: from "david@sparks.net" at "Feb 13, 1999 1:55: 4 pm" To: david@sparks.net Date: Sat, 13 Feb 1999 14:03:07 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 david@sparks.net wrote... > Hi all:) > > I'm trying to make a Vela scsi mpeg2 decoder work under 2.2.8. This > decoder takes power from the isa bus and all its commands over the scsi > bus. > > The card shows up under the adaptec bios setup as "Vela" and "Decoder" > but the kernel doesn't know what to do with it since it's not a tape, > disk, or CD. > > Pointers and general guidelines welcome:) You should be able to get at it via the uk device. I think that under the old SCSI layer, the uk device attached to all devices that didn't have a "normal" device configured. I would imagine, though, that your mpeg decoder is probably a processor target device. So try configuring the pt0 device in your kernel. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:27:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03671 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:27:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03609 for ; Sat, 13 Feb 1999 18:27:47 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id RAA04322 for ; Sat, 13 Feb 1999 17:34:08 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36C61A00.76960BF1@softweyr.com> Date: Sat, 13 Feb 1999 17:34:08 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. References: <10481.918927420@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > If we wanted to use a commercial solution then the choice would be > more than clear - Perforce! Our CVS repository meister(s) like it a > lot and one can get copies of the perforce server for FreeBSD at the > low low price of $1 (perforce's generous way of giving something back > to the FreeBSD community). > > However, we don't want to use a commercial solution for lots of > various reasons, not least of which the fact that we have one hell of > a lot invested in CVS. Our CVS web stuff, the CTM delta generator, > the ubiquitous CVSup program, all would have to be substantially > redesigned for a new SCM tool and that would be a lot of work. Actually, given the capabilities of Perforce, most of those would be unneeded. They already have a web interface, and the Perforce server supports read-only users and distributed, read-only depots, which could probably replace CVSup and CTM. They even have a Java GUI in the works. I'm a big fan of Perforce, and am one of their original "Consulting Partners," but I feel there is still a compelling reason to use CVS in FreeBSD: running and building FreeBSD using tools that are shipped with the system goes a long way towards proving what a stable, reliable system it is, and just how good the toolset that comes with it is. If I were to recommend a commercial tool for FreeBSD CMS, Perforce would be it, but I don't. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:30:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03888 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:30:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.whistle.com (gatekeeper.whistle.com [207.76.204.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03818 for ; Sat, 13 Feb 1999 18:30:01 -0800 (PST) (envelope-from julian@whistle.com) Received: (from smap@localhost) by gatekeeper.whistle.com (8.8.8/8.8.7) id QAA07616 for ; Sat, 13 Feb 1999 16:42:34 -0800 (PST) (envelope-from julian@whistle.com) Received: from alpo.whistle.com(unknown 207.76.204.38) by gatekeeper.whistle.com via smap (V2.0) id xma007614; Sat, 13 Feb 99 16:42:15 -0800 Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA27796; Sat, 13 Feb 1999 16:30:15 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdd27794; Sun Feb 14 00:30:14 1999 Date: Sat, 13 Feb 1999 16:29:53 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Doug Rabson cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: VOP_REMOVE() rules for freeing a_cnp ? In-Reply-To: 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 Sat, 13 Feb 1999, Doug Rabson wrote: > I'm sure that someone changed the semantics for who frees the pathnames > and who releases the vnodes during the 3.0 development cycle but I can't > quite remember who (Mike someone maybe, not Mike Smith). I think that the > intention was to always free the path and release the vnodes in the > caller, not in the filesystem (which was supposed to make it easier to > write layers). Mr Hancock in Japan.. He cleaned up a lot of those cases.. > > I have a vague recollection that VOP_RENAME was the only one which wasn't > changed since it does some wildly complicated things with its vnodes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:38:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05140 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:38:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05132 for ; Sat, 13 Feb 1999 18:38:14 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA18405; Sat, 13 Feb 1999 17:36:15 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd018394; Sat Feb 13 17:36:14 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA29410; Sat, 13 Feb 1999 17:35:54 -0700 (MST) From: Terry Lambert Message-Id: <199902140035.RAA29410@usr06.primenet.com> Subject: Re: softupdates To: jal@stage1.thirdage.com (Jamie Lawrence) Date: Sun, 14 Feb 1999 00:35:50 +0000 (GMT) Cc: mjacob@feral.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <4.1.19990213000333.0765d230@204.74.82.151> from "Jamie Lawrence" at Feb 13, 99 00:41:01 am X-Mailer: ELM [version 2.4 PL25] 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 > Sure. That's why we spent a (frankly) ridiculous amount of money on > a Netapp. Support would have saved us a bundle, maybe. Real world, > right-here-right-now-we're-doing-it-today applications tend to have > nontechnical restraints imposed on them, which hurt; having technical > (non)-assurances layered on top create a barrier that no zealot can > honestly penetrate, FreeBSD or no. The current implementation of soft updates is incapable of having a transactioning stacking layer stacked on top of it, since it's a UFS/FFS specific soloution instead of a general soloution. This is a big issue for competing with NetApp's implementation. > I hate (will become hated) to say this, but if taking on Netapp is > a goal, there's a huge hardware requirement for the port, and then > there's probably a steep performance curve. > > They do support "common" protocols, which work most anywhere. At a price. I spent last night hacking code with Jeremy Allison (SAMBA/SGI); we had a nice discussion about some of the benchmarks posted on the samba.org site. In general, the NetApp stuff is hindered by its architecture. On a single processor box, they beat SAMBA with their SMB implementation. This is primarily due to their NetWare-like use of non-preemptive multitasking and threading: they don't have the normal context switch thrash, and tasks run to completion. [Note: this is why kernel threads or threaded implementations other than an async call gate will always fall behind NetApp and NetWare, in a uniprocessor benchmark]. At the same time, this means that the NetApp nad NetWare server implementations can not take advantage of symmetric multiprocessing. Given the assumption that threads will run to completion (or to an explicit yield), they do not implement much resource locking, at all, only that needed for interrupt and fault processing. As a result, they are low overhead on UP, but impossible to implement in an SMP CPU architecture due to lacking the necessary locking. They can not even take "the cowards way out" of a Big Giant Lock(tm), like Linux and FreeBSD have done, since they don't have a concurrency barrier for tasks which may be competing for system resources. On a four processor Xeon box, SAMBA seriously outperforms anything that NetApp can field. Finally, it's true that NetApp has a number of pieces of low hanging fruit that they can acquire at some small cost: o They could use character-count prefixes on strings internally (SAMBA can do tis as well; apparently the current profiling bottleneck is strlen calls). o They could avoid the Unicode/non-Unicode codepage based conversions. This would require FS changes to support [NB: SAMBA doesn't currently do Unicode in their release branch]. o They could go to pure Unicode in the FS, instead of doing multibyte encoding and decoding. o etc. These are, in of themselves, insufficient (IMO) for what appears to be the coming widespread use of 4 processor Xeon boxes. This concludes our mini technical analysis; we now return you to your regularly scheduled cat herding. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:40:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05714 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:40:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05707 for ; Sat, 13 Feb 1999 18:40:50 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA13590; Sat, 13 Feb 1999 18:05:36 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd013575; Sat Feb 13 18:05:32 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA01804; Sat, 13 Feb 1999 18:05:30 -0700 (MST) From: Terry Lambert Message-Id: <199902140105.SAA01804@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: hgoldste@bbs.mpcs.com Date: Sun, 14 Feb 1999 01:05:30 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <14021.27462.556760.465144@penny.south.mpcs.com> from "Howard Goldstein" at Feb 13, 99 07:08:38 am X-Mailer: ELM [version 2.4 PL25] 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 > > > Realtime signals would help almost as much, perhaps in a more portable > > > way. > > > > man setitimer > > 'Sir, may I please have some more?' > > I use it...I always feel dirty when I have setitimer signal a clumsy > monolith that is itself in many ways like the one that deals with the > aftermath of a select(). More timers, a la posix realtime signals > (p1003B? I'm sure I'm citing the wrong posix id) would be cleaner, > and would make it easier to write pthreaded applications. Silly Oliver Twist... POSIX is getting more and more barnacle encrusted as time goes on. The POSIX stuff is to the point now that it should be implemented in libraries, instead of kernels, so that the majority of it can be ignored, while still allowing you to claim conformance. My personal preference for high concurrency, low overhead, SMP scalable threads is a user space scheduler that consumes async call gates. POSIX chickened out on this, and there are still calls that you can make that force you to give away your quantum, and which have no async alternatives. 'Some calls are more async than others.' >From my point of view, if the scheduler gives me a quantum, then *it's MY quantum*, and anything that makes me "give part of it back" for the dubious benefit of making a blocking call and taking a full context switch is just plain stupid. See the other thread in this forum on FreeBSD vs. Network Appliance market niches. NetApp uses a non-preemptive multitasking and multithreaded kernel. This is good, because it eliminates context switch thrashing. This is bad, because it's not SMP scalable, and, like Windows 3.1, you have to trust all of your threads of execution to "play nice". An async call gate, combined with a user space scheduler, resolves the context switch thrashing equally well, while still allowing the SMP scalability, and taking into account that God can't write all of your threads of execution at the cost of minimally necessary context switch overhead. Whee! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:40:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05750 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:40:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05743 for ; Sat, 13 Feb 1999 18:40:57 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA25904; Sat, 13 Feb 1999 17:44:12 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd025888; Sat Feb 13 17:44:08 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA00134; Sat, 13 Feb 1999 17:43:49 -0700 (MST) From: Terry Lambert Message-Id: <199902140043.RAA00134@usr06.primenet.com> Subject: Re: VOP_REMOVE() rules for freeing a_cnp ? To: dfr@nlsystems.com (Doug Rabson) Date: Sun, 14 Feb 1999 00:43:34 +0000 (GMT) Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 13, 99 01:50:24 pm X-Mailer: ELM [version 2.4 PL25] 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 can't make heads or tails of the VOP_REMOVE() rules for freeing > > a_cnp. > > > > The man page doesn't say anything about having to free cnp. > > > > ufs_remove() doesn't bother. > > > > nfs_remove() always frees it. > > > > And the unlink() system call seems to expect the cnp to be freed > > by the VOP_REMOVE() function. > > > > Typically the rule for freeing a struct componentname in a VOP > > routine is 'free it if you return an error, otherwise only free > > it if the SAVESTART flag is not set in cn_flags'. > > > > I would appreciate it if a VFS guru could look at this junk and > > tell me whos right. > > I'm sure that someone changed the semantics for who frees the pathnames > and who releases the vnodes during the 3.0 development cycle but I can't > quite remember who (Mike someone maybe, not Mike Smith). I think that the > intention was to always free the path and release the vnodes in the > caller, not in the filesystem (which was supposed to make it easier to > write layers). > > I have a vague recollection that VOP_RENAME was the only one which wasn't > changed since it does some wildly complicated things with its vnodes. I changed them. But the changes were not integrated. It is still "callee free", e.g., in /sys/ufs/ufs/ufs_vnops.c: /* * Ufs abort op, called after namei() when a CREATE/DELETE isn't actually * done. If a buffer has been saved in anticipation of a CREATE, delete it. */ /* ARGSUSED */ int ufs_abortop(ap) struct vop_abortop_args /* { struct vnode *a_dvp; struct componentname *a_cnp; } */ *ap; { if ((ap->a_cnp->cn_flags & (HASBUF | SAVESTART)) == HASBUF) zfree(namei_zone, ap->a_cnp->cn_pnbuf); return (0); } This is incidently, probably what Matt was looking for: VOP_ABORTOP(). As an interesting aside, you will not be able to implement a working writeable NTFS for FreeBSD until these semantics change to "caller frees" instead of "callee frees". See the Helen Custor book on NTFS with specific attention to rollback through operational abort for the gory details. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:43:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06234 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:43:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sparks.net (gw.sparks.net [209.222.120.18]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA06227 for ; Sat, 13 Feb 1999 18:43:56 -0800 (PST) (envelope-from david@sparks.net) From: david@sparks.net Received: from david by sparks.net with smtp (Exim 1.62 #5) id 10Br1K-0001lJ-00; Sat, 13 Feb 1999 21:10:54 -0500 Date: Sat, 13 Feb 1999 21:10:54 -0500 (EST) Reply-To: david@sparks.net To: "Kenneth D. Merry" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need pointers on new scsi device type In-Reply-To: <199902132103.OAA46150@panzer.plutotech.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 Sat, 13 Feb 1999, Kenneth D. Merry wrote: > david@sparks.net wrote... > > Hi all:) > > > > I'm trying to make a Vela scsi mpeg2 decoder work under 2.2.8. This > > decoder takes power from the isa bus and all its commands over the scsi > > bus. > > > > The card shows up under the adaptec bios setup as "Vela" and "Decoder" > > but the kernel doesn't know what to do with it since it's not a tape, > > disk, or CD. > > > > Pointers and general guidelines welcome:) > > You should be able to get at it via the uk device. I think that under the > old SCSI layer, the uk device attached to all devices that didn't have a > "normal" device configured. I'm terribly embarassed to admit that I missed that earlier:( > I would imagine, though, that your mpeg decoder is probably a processor > target device. So try configuring the pt0 device in your kernel. I added pt0 and it didn't come up on the next boot. I'll dig into it more. Is there a good description of the scsi subsystem and the uk/pt drivers which someone could point to me to RTFM? Thanks, --- David ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:47:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06793 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:47:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06771 for ; Sat, 13 Feb 1999 18:47:51 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA27637; Sat, 13 Feb 1999 16:05:10 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd027609; Sat Feb 13 16:05:02 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA01117; Sat, 13 Feb 1999 16:04:56 -0700 (MST) From: Terry Lambert Message-Id: <199902132304.QAA01117@usr02.primenet.com> Subject: Re: ppp server side startup commands To: chuckr@mat.net (Chuck Robey) Date: Sat, 13 Feb 1999 23:04:54 +0000 (GMT) Cc: tlambert@primenet.com, phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Feb 12, 99 10:16:27 pm X-Mailer: ELM [version 2.4 PL25] 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 > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > > > The PPP server should obtain IP addresses via DHCP. > > Terry, these are static IPs (like I said). Why would I want to get IP > numbers that I already know of? I have to experiment with Brian's > solution (which bothers me much more, because it doesn't seem to give me > a chance to tell ppp what the additional IP number is). I haven't yet > tested Brian's answer, but I was under the impression that DHCP was used > to ID machines; wny would I want to ID a machine I already know of? Well, this is how the cable modem addresses are assigned. They have a static address in the A block, and they use DHCP to ask what the static address is. The point of this is that DHCP supports information other than the IP address alone. It does netmask, domain name, DNS server, gateway, etc.. > Just in case you forgot, the idea was, ON THE SERVER SIDE ONLY, to take > and allow for an extra static IP on the client side. This meant one > more arp and one more route command one the server. I can handle the > client side fine now. I sent a draft off to the ISC people with regard to what I call a "blind secondary DNS server". The gist of the draft is that you have a dialup machine that needs more DNS information than you can get via a single DHCP request. The client machine runs a standard split horizon DNS, one on the dialup interface, and one on the internal ethernet. The client acts as the gateway, router, or NAT device to the LAN. The DNS on the dialup port is a true secondary for the domain. The DNS on the LAN believes it is primary for the lan, and designates the dialup interface as its forwarder. The point of a "blind secondary" is that, not only can the ISP, who controls the true primary for the domain, relocate resources that the dialup gateway/router/NAT may need to know about (e.g. secondary MX's, www server, and ftp server, etc.), the ISP can relocate the primary while the secondary is offline. In this case, the secondary can't know the primary has moved via notification, since that would require the ISP bring up the line to the dialup device. To resolve this, when a TTL expires, resulting in a need for the secondary to perform a zone transfer, the secondary attempts to contact the primary to satisfy the transfer. To do this, it goes to the root server, and asks for the primary, as if it were some other (unrelated) DNS trying to resolve an address in the domain. Once the primary is identified this way, a zone transfer is initiated. The semantics of this are: secondary Berkeley.EDU * ucbhosts.bak In other words, instead of the IP address of the primary, an asterisk is used to indicate "I don't know; find the thing". Now, how can this solve your problem? This can solve your problem by setting up DNS information that knows about the other machine on the server. You can use this information to establish explicit routing. Even without "blindness" (since you're the server), this can do the job, though you risk losing sync with the primary while the client is offline. Alternately, you can subnet the line, and assign both addresses in the subnet. Alternately, you can use BGP/EGP on one client to thell the server about the other client. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 13 18:48:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04930 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:36:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA04923 for ; Sat, 13 Feb 1999 18:36:48 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA13421; Sat, 13 Feb 1999 18:02:54 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd013318; Sat Feb 13 18:02:42 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA00998; Sat, 13 Feb 1999 17:54:55 -0700 (MST) From: Terry Lambert Message-Id: <199902140054.RAA00998@usr06.primenet.com> Subject: Re: NFS VOP calls (was Re: Lots of "panic: vrele: negative ref cnt" ) To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 14 Feb 1999 00:54:49 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902130941.BAA14698@apollo.backplane.com> from "Matthew Dillon" at Feb 13, 99 01:41:37 am X-Mailer: ELM [version 2.4 PL25] 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 > It looks like there are a number of problems, but the one reported > above is the only one that gets 'hit'. The NFS code pretty much > ignores the VOP semantics for freeing path name elements but it > just happens to get called with the path name (cnp) structure flagged > the way it happens to decide to use it, so it works. But there is > probably some leakage of NAMEI nodes when NFS errors occur. > > I've only committed the fix for the vrele panic to -3.x. The fix > to the rest of the mis-used path elements has been committed to -4.x > and will not be backported to -3.x until after the release since > I'm not 100% sure those other fixes are correct. -3.x should not be > detrimentally effected by not having the other junk in. > > Confused yet? :-) Beware. It is very easy to introduce a memory leak/multiple free error in the NFS server case. I highly recommend you use my test framework for this; DFR has a copy, and someone brought it up to date. Basically, it allows you to perform a list of operations (system calls) in a test framework, and track the resulting amount of various kernel allocations (as reported by vmstat). The framework comes with code to look at the NAMEI code in particular, since that's excatly the place I introduces a leak in the NFS code in my initial set of "nameifree()" patches. >From the top down, the NFS server is, like the system call layer, a consumer of VFS interfaces. As a result of this, the NFS server does local allocation of path buffers through it's own method of obtaining them, expecting the callee to delete them (in some cases, it, in fact, cretes them for the express purpose of having them there when the callee goes to delete them). If you are *really* interested in cleaning up and speeding this code, FreeBSD really needs the generic idea of a "counted object queue", with high and low watermarks, for drain/fill, and should keep around a preallocated list of path name buffers that are caller alloc/free, instead of allocating via NDINIT (or in NFS) and deallocating everywhere, at random. This would also be somewhat a move in the per CPU pool direction, as well as a move in the direction of doing page starvation avoidance, rather than page starvation detection and correction (you could consider the low watermark point of the object type queue to be your "reserve" from the page reserve design). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message