From owner-freebsd-hackers Sun Dec 3 1:47:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mobile.wemm.org (adsl-64-163-195-99.dsl.snfc21.pacbell.net [64.163.195.99]) by hub.freebsd.org (Postfix) with ESMTP id 3A51237B400; Sun, 3 Dec 2000 01:47:42 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id eB39kJD31001; Sun, 3 Dec 2000 01:46:20 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200012030946.eB39kJD31001@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Andrew Gallatin Cc: "Kenneth D. Merry" , hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? In-Reply-To: <14889.27531.660040.955219@grasshopper.cs.duke.edu> Date: Sun, 03 Dec 2000 01:46:19 -0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Gallatin wrote: > > Kenneth D. Merry writes: > > As for PCIOCREAD, it only allows reading of PCI registers, so the question > > there is whether there are any potential security implications to allowing > > non-root users to read PCI registers. If reading configuration registers > > caused performance degredation, for instance. > > I think that you might be able to crash an alpha with an unaligned > access trap by reading an int or short an from an unaligned offset in > config space. At least this used to be true.. I'd vote for leaving > the access permissions as is. I've accidently toasted boxes with this before. We really should fix it some time.... Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 7:41:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 07:41:19 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 7F37B37B400 for ; Sun, 3 Dec 2000 07:41:18 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id KAA61923 for hackers@freebsd.org; Sun, 3 Dec 2000 10:48:22 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200012031548.KAA61923@hda.hda.com> Subject: Arg! Siginfo and pthreads again To: hackers@freebsd.org Date: Sun, 3 Dec 2000 10:48:17 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: dufault@hda.hda.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Again I've forgotten that SIGINFO dumps the pthread info and created several gigabytes of /tmp files: > rt% rm /tmp/uthread* > /bin/rm: Argument list too long. I don't consider it bad form to use SIGINFO to see if processes are still around without first installing a SIGINFO handler. Am I the only one ever burnt by this? Do other user-space thread systems handle this similarly? Maybe an info thread can block at an info fifo in conjunction with a "psthread" program. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 10: 0:58 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 10:00:56 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from west.lustig.com (west.lustig.com [209.157.26.130]) by hub.freebsd.org (Postfix) with SMTP id 5CB8B37B400 for ; Sun, 3 Dec 2000 10:00:56 -0800 (PST) Received: (qmail 66634 invoked from network); 3 Dec 2000 18:00:55 -0000 Received: from lustig.ne.mediaone.net (HELO devious.lustig.com) (@24.91.125.166) by west.lustig.com with SMTP; 3 Dec 2000 18:00:55 -0000 Received: (qmail 10356 invoked by uid 1001); 3 Dec 2000 18:00:54 -0000 Message-ID: <20001203180054.10355.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach_patches v148.2) X-Nextstep-Mailer: Mail 4.2mach_patches [i386] (Enhance 2.2p2) Received: by NeXT.Mailer (1.148.2.RR) From: Barry Lustig Date: Sun, 3 Dec 2000 13:00:54 -0500 To: emulation@freebsd.org, hackers@freebsd.org Subject: VMware hanging -- Memory deadlock? Reply-To: barry@Lustig.COM X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a vaio z505le with 192MB running 4.2-STABLE (cvsupped today). I've been trying to get vmware running properly on it. I first configured vmware on the vaio, created a win2k type virtual disk, set ram in the VM to 80M, and copied a happily working win2k virtual disk from another system over the skeleton one that the config wizard created. I'm running the latest port of XFree86 4.0.1. Each time I start vmware the system gets part of the way through the VM boot process and then hangs. The only thing that still responds is the mouse. A top process running in an xterm locks up, as does the getty on the serial console. I can break into ddb from the serial console. I've found that dropping the memory size for the VM down to 64MB works (68MB doesn't). When running the 64MB VM top shows: 70M Active, 34M Inactive, 75M Wired, ~9M Cache, 29M Buf, ~6M Free Does anyone have any suggestions on how to debug this? Thanks, barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 10:18:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 10:18:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BB13737B401 for ; Sun, 3 Dec 2000 10:18:31 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA11476; Sun, 3 Dec 2000 13:18:03 -0500 (EST) Date: Sun, 3 Dec 2000 13:18:03 -0500 (EST) From: Daniel Eischen To: Peter Dufault Cc: hackers@FreeBSD.ORG Subject: Re: Arg! Siginfo and pthreads again In-Reply-To: <200012031548.KAA61923@hda.hda.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 Sun, 3 Dec 2000, Peter Dufault wrote: > Again I've forgotten that SIGINFO dumps the pthread info and created > several gigabytes of /tmp files: > > > rt% rm /tmp/uthread* > > /bin/rm: Argument list too long. > > I don't consider it bad form to use SIGINFO to see if processes are > still around without first installing a SIGINFO handler. Can't you use `kill -0 pid` if you just want to see if the process is around? > Am I the only one ever burnt by this? > Do other user-space thread systems handle this similarly? > Maybe an info thread can block at an info fifo in conjunction > with a "psthread" program. Now that we can accomodate more than 31 signals, we could always add a SIGTHRINFO (or something more aptly named) instead of using SIGINFO. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 10:39:13 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 10:39:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id 81A3C37B400 for ; Sun, 3 Dec 2000 10:39:08 -0800 (PST) Received: from therock (betterguard.epconline.net [209.83.132.193]) by kira.epconline.net (8.9.3/8.9.3) with SMTP id MAA24631 for ; Sun, 3 Dec 2000 12:39:05 -0600 (CST) Reply-To: From: "Chuck Rock" To: "FreeBSD Hackers" Subject: More logging questions.... Date: Sun, 3 Dec 2000 12:39:14 -0600 Message-ID: <000101c05d58$5617cf00$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a machine running FreeBSD 4.2, and when it boots up, I can watch the console, and everything is highlighted (bright white), then I guess it moves on to starting processes from init, rc.local and such, and the console is loggin stuff on the screen in normal text (not highlighted). This information is NOT in the messages file, nor in the dmesg output. The last information logged to both (dmesg and /var/log/messages) is the last disk drive initialization. I see on the screen some error about ld.so not found, Apache, and some other things, but I can't find out where that information is being logged, so I can look at it remotely. Does anyone have any idea where I can find this information? The rc.local file, and scripts in the /usr/local/etc/rc.d directory don't appear to be executing on startup, and I need to figure out what's causing the problem. Help appreciated, Chuck Rock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 11:33:33 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 11:33:31 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id BE65737B401 for ; Sun, 3 Dec 2000 11:33:30 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB3JWCw68109; Sun, 3 Dec 2000 11:32:12 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Dec 2000 11:32:12 -0800 (PST) From: Matt Dillon Message-Id: <200012031932.eB3JWCw68109@earth.backplane.com> To: News History File User Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm going to take this off of hackers and to private email. My reply will be via private email. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 12: 8:51 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 12:08:49 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 27FE737B400 for ; Sun, 3 Dec 2000 12:08:48 -0800 (PST) Received: from harare-39.budapest.interware.hu ([195.70.50.39] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 142fRF-0000y4-00; Sun, 03 Dec 2000 21:08:46 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A2AA83B.BB7186B9@elischer.org> Date: Sun, 03 Dec 2000 12:08:27 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Matt Dillon Cc: News History File User , hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012031932.eB3JWCw68109@earth.backplane.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > I'm going to take this off of hackers and to private email. My reply > will be via private email. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message errr then keep me in the CC it's interesting.... -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 12:15:12 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 12:15:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id E7EB437B401 for ; Sun, 3 Dec 2000 12:15:10 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB3KEXQ68288; Sun, 3 Dec 2000 12:14:33 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Dec 2000 12:14:33 -0800 (PST) From: Matt Dillon Message-Id: <200012032014.eB3KEXQ68288@earth.backplane.com> To: Julian Elischer Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012031932.eB3JWCw68109@earth.backplane.com> <3A2AA83B.BB7186B9@elischer.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :errr then keep me in the CC : :it's interesting.... : :-- : __--_|\ Julian Elischer : / \ julian@elischer.org Sure thing. Anyone else who wants to be in the Cc, email me. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 13: 0:55 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 13:00:51 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 822F037B400 for ; Sun, 3 Dec 2000 13:00:50 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 3 Dec 2000 21:00:49 +0000 (GMT) To: hackers@freebsd.org Subject: M_ZERO patches. X-Request-Do: Date: Sun, 03 Dec 2000 21:00:49 +0000 From: David Malone Message-ID: <200012032100.aa61925@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to commit a large chunk of the remaining M_ZERO patches I've collected up later this week. These patches touch various parts of the system, so I'd apreciate if people could take a look at them. http://www.maths.tcd.ie/~dwmalone/mzero.patch I've listed the files it effects below. It is rather long, so to try to even out which bits of it get looked at, I've put a letter beside some of the files. If you have 10 minutes to spare then start at the letter your name begins with and keep going 'till you're fed up! David. sys/compat/linux/linux_mib.c A sys/contrib/dev/oltr/if_oltr.c sys/dev/ccd/ccd.c sys/dev/eisa/eisaconf.c sys/dev/fb/fb.c sys/dev/ida/ida.c B sys/dev/kbd/atkbd.c sys/dev/kbd/atkbdc.c sys/dev/kbd/kbd.c sys/dev/lmc/if_lmc.c sys/dev/lmc/if_lmc_fbsd3.c C sys/dev/lnc/if_lnc_pci.c sys/dev/md/md.c sys/dev/musycc/musycc.c sys/dev/null/null.c sys/dev/pdq/if_fpa.c D sys/dev/ppbus/ppbconf.c sys/dev/ppbus/vpo.c sys/dev/rp/rp.c sys/dev/rp/rp_isa.c sys/dev/rp/rp_pci.c E sys/dev/si/si.c sys/dev/syscons/syscons.c sys/dev/vn/vn.c sys/fs/devfs/devfs_devs.c sys/fs/devfs/devfs_vfsops.c F sys/fs/hpfs/hpfs_vfsops.c sys/i386/i386/busdma_machdep.c sys/i386/i386/i686_mem.c sys/i386/i386/k6_mem.c sys/i386/i386/mp_machdep.c G sys/i386/i386/nexus.c sys/i386/i386/userconfig.c sys/i386/i386/vm_machdep.c sys/i386/isa/cy.c sys/i386/isa/if_ar.c H sys/i386/isa/if_sr.c sys/i386/isa/intr_machdep.c sys/i386/isa/isa_compat.c sys/i386/isa/istallion.c sys/i386/isa/rp.c I sys/i386/isa/stallion.c sys/i386/isa/bs/bsfunc.c sys/i386/isa/bs/bsif.c sys/ia64/ia64/busdma_machdep.c sys/ia64/ia64/sscdisk.c J sys/isa/atkbdc_isa.c sys/isa/fd.c sys/isa/isa_common.c sys/isa/pnpparse.c sys/isofs/cd9660/cd9660_vfsops.c K sys/kern/kern_conf.c sys/kern/kern_descrip.c sys/kern/kern_event.c sys/kern/kern_jail.c sys/kern/kern_linker.c L sys/kern/kern_mutex.c sys/kern/kern_sysctl.c sys/kern/link_elf.c sys/kern/subr_blist.c sys/kern/subr_bus.c M sys/kern/subr_kobj.c sys/kern/subr_prof.c sys/kern/subr_rman.c sys/kern/tty.c sys/kern/tty_pty.c N sys/kern/tty_snoop.c sys/kern/uipc_socket.c sys/kern/uipc_syscalls.c sys/kern/vfs_init.c sys/kern/vfs_subr.c O sys/kern/vfs_syscalls.c sys/miscfs/union/union_vfsops.c sys/msdosfs/msdosfs_vfsops.c sys/net/bpf.c sys/net/bridge.c P sys/net/if.c sys/net/if_ef.c sys/net/if_sl.c sys/net/if_tap.c sys/net/if_tun.c R sys/net/rtsock.c sys/netatalk/at_control.c sys/netatalk/ddp_usrreq.c sys/netinet/in.c sys/netinet/in_hostcache.c S sys/netinet/in_pcb.c sys/netinet/ip_dummynet.c sys/netinet/ip_fw.c sys/netinet/tcp_input.c sys/netipx/ipx.c T sys/netipx/ipx_ip.c sys/netipx/ipx_pcb.c sys/netipx/spx_usrreq.c sys/netnatm/natm_pcb.c sys/nfs/nfs_nqlease.c U sys/nfs/nfs_srvcache.c sys/nfs/nfs_syscalls.c sys/ntfs/ntfs_subr.c sys/ntfs/ntfs_vfsops.c sys/pc98/i386/userconfig.c V sys/pc98/pc98/fd.c sys/pc98/pc98/syscons.c sys/pc98/pc98/wd.c sys/pc98/pc98/wd_cd.c sys/pc98/pc98/wfd.c W sys/pc98/pc98/wst.c sys/pci/if_fxp.c sys/pci/if_mn.c sys/pci/if_tx.c sys/pci/isp_pci.c XY sys/pci/ncr.c sys/pci/pci.c sys/pci/pci_compat.c sys/pci/simos.c sys/ufs/ffs/ffs_softdep.c Z sys/ufs/ffs/ffs_vfsops.c sys/ufs/ufs/ufs_quota.c sys/vm/swap_pager.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 13:37:45 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 13:37:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id BAE6837B400 for ; Sun, 3 Dec 2000 13:37:41 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id QAA62661; Sun, 3 Dec 2000 16:44:40 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200012032144.QAA62661@hda.hda.com> Subject: Re: Arg! Siginfo and pthreads again In-Reply-To: from Daniel Eischen at "Dec 3, 2000 01:18:03 pm" To: Daniel Eischen Date: Sun, 3 Dec 2000 16:44:40 -0500 (EST) Cc: Peter Dufault , hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: dufault@hda.hda.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 3 Dec 2000, Peter Dufault wrote: > > Again I've forgotten that SIGINFO dumps the pthread info and created > > several gigabytes of /tmp files: > > > > > rt% rm /tmp/uthread* > > > /bin/rm: Argument list too long. > > > > I don't consider it bad form to use SIGINFO to see if processes are > > still around without first installing a SIGINFO handler. > > Can't you use `kill -0 pid` if you just want to see if the process > is around? Yes, I can and I should. I guess I forgot. I'll fix my code. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 14:24:36 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 14:24:33 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 0781E37B400 for ; Sun, 3 Dec 2000 14:24:29 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id JAA03679; Mon, 4 Dec 2000 09:23:52 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01JXAV2TYKLC902V69@cim.alcatel.com.au>; Mon, 4 Dec 2000 09:23:50 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.0/8.11.0) id eB3MNn592356; Mon, 04 Dec 2000 09:23:49 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 04 Dec 2000 09:23:48 +1100 From: Peter Jeremy Subject: Re: BSD random for Alpha? To: hackers@FreeBSD.ORG Cc: sheldonh@uunet.co.za, arnold@skeeve.com Message-id: <20001204092348.A92196@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: jeremyp@gsmx07.alcatel.com.au Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000 15:18:27 +0200, Sheldon Hearn wrote: >Anyone want to have a look at this? It's from the GNU awk maintainer. >- ------- Forwarded Message > >From: Aharon Robbins >Date: Wed, 22 Nov 2000 11:59:10 +0200 >Message-ID: <974887150.75c0d57f@skeeve.com> >To: sheldonh@uunet.co.za >Subject: BSD random for Alpha? >Cc: bostic@bostic.com, michal@phys.ualberta.ca > >Hi. I've switched to the new random.c you sent me for gawk. My >Linux/Alpha Guru reports that the code in it assumes that sizeof(long) >is always 4, and one particular test doesn't "look" very random on >the Alpha. > >My question is, is there a better version of random that can deal >with both 32 and 64 bit systems in the same source code? Would >the NetBSD people maybe have such a thing? Try a Fibonacci-sequence random number generator (they're mentioned in Knuth). The general form is: X[n] = (X[n-j] + X[n-k]) mod m where m is any power of 2 (implying that the same generator can be used with any word-size) and k-j > 15. Knuth includes a table of `good' values for j and k. The period is >> 2^k. Off the top of my head (24,55) is a good pair. (The only downside according to Knuth is a lack of theory to explain the behaviour, though this may have been rectified in the 25(?) years since it was written). The normal implementation is an array of size k with two indices representing [n-j] and [n-k], which wrap as appropriate. The initial values should not be all even. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 15:14:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 15:14:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 519DD37B400; Sun, 3 Dec 2000 15:14:27 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB3NEPQ89603; Sun, 3 Dec 2000 16:14:26 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA41644; Sun, 3 Dec 2000 16:14:25 -0700 (MST) Message-Id: <200012032314.QAA41644@harmony.village.org> To: Andrew Gallatin Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Cc: "Kenneth D. Merry" , hackers@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Sat, 02 Dec 2000 16:39:39 EST." <14889.27531.660040.955219@grasshopper.cs.duke.edu> References: <14889.27531.660040.955219@grasshopper.cs.duke.edu> <200012012056.eB1KuDI32343@orthanc.ab.ca> <20001201174408.A17122@panzer.kdm.org> Date: Sun, 03 Dec 2000 16:14:25 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14889.27531.660040.955219@grasshopper.cs.duke.edu> Andrew Gallatin writes: : I'd vote for leaving the access permissions as is. I'd agree with that. We don't know that all PCI hardware will not cause problems when arbitrary locations in config space are read. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 16:19:16 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 16:19:14 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 263D737B400 for ; Sun, 3 Dec 2000 16:19:14 -0800 (PST) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id eB40J8q11723 for ; Sun, 3 Dec 2000 16:19:08 -0800 From: "Jonathan Graehl" To: Subject: most efficient/precise monotonic clock for I686_CPU? Date: Sun, 3 Dec 2000 16:23:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What is the most efficient way to get a relatively precise (say, at least millisecond) time value that is guaranteed to inrease monotonically (even if, say, xntpd adjust the system clock), either portable, or FreeBSD-specific? Is there some user library for using the Pentium performance clock thingy? I have, of course, looked at gettimeofday(2). Is this what I should be using? Does it involve a system call? -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 16:39:25 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 16:39:23 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 02F9D37B400 for ; Sun, 3 Dec 2000 16:39:22 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA29949; Sun, 3 Dec 2000 17:38:05 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id RAA19094; Sun, 3 Dec 2000 17:38:04 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14890.59243.833322.50357@nomad.yogotech.com> Date: Sun, 3 Dec 2000 17:38:03 -0700 (MST) To: Matt Dillon Cc: News History File User , hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness In-Reply-To: <200012031932.eB3JWCw68109@earth.backplane.com> References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012031932.eB3JWCw68109@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm going to take this off of hackers and to private email. My reply > will be via private email. Actually, I was enjoying the discussion, since I was learning something in the process of hearing you debug this remotely. It sure beats the K&R vs. ANSI discussion. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 16:42:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 16:42:44 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1273337B401 for ; Sun, 3 Dec 2000 16:42:44 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB40fwJ69338; Sun, 3 Dec 2000 16:41:58 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Dec 2000 16:41:58 -0800 (PST) From: Matt Dillon Message-Id: <200012040041.eB40fwJ69338@earth.backplane.com> To: Nate Williams Cc: News History File User , hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012031932.eB3JWCw68109@earth.backplane.com> <14890.59243.833322.50357@nomad.yogotech.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I'm going to take this off of hackers and to private email. My reply :> will be via private email. : :Actually, I was enjoying the discussion, since I was learning something :in the process of hearing you debug this remotely. : :It sure beats the K&R vs. ANSI discussion. :) : :Nate Heh. Well, I didn't think there'd be as much interest as there is, so I guess I'll throw it back onto the mailing list. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 16:55:10 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 16:55:06 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 4DC1937B400 for ; Sun, 3 Dec 2000 16:55:06 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB40rnm69425; Sun, 3 Dec 2000 16:53:49 -0800 (PST) (envelope-from dillon) Date: Sun, 3 Dec 2000 16:53:49 -0800 (PST) From: Matt Dillon Message-Id: <200012040053.eB40rnm69425@earth.backplane.com> To: News History File User Cc: hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ok, since I got about 6 requests in four hours to be Cc'd, I'm throwing this back onto the list. Sorry for the double-response that some people are going to get! I am going to include some additional thoughts in the front, then break to my originally private email response. I ran a couple of tests with MAP_NOSYNC to make sure that the fragmentation issue is real. It definitely is. If you create a file by ftruncate()ing it to a large size, then mmap() it SHARED + NOSYNC, then modify the file via the mmap, massive fragmentation occurs on the file. This is easily demonstrated by issuing a sequential read on the file and noting that the system is not able to do any clustering whatsoever and gets a measily 0.6MB/sec of throughput (on a disk that can do 12-15MB/sec). (and the disk seeks wildly during the read). When you create a large file and fill it with zero's, THEN mmap() it SHARED + NOSYNC and write to it randomly via the mmap(), the file remains laid on disk optimally. However, I noticed something interesting! When I dd if=file of=/dev/null bs=32k the file the first time after randomly writing it and then fsync()ing it, I only get 4MB/sec of throughput. If I dd the file a second time I get around 8MB/sec. If I dd it the third time I get the platter speed - 12-15MB/sec. The issue here has to do with the fact that the file is partially cached in the first two dd runs. The partially cached file shortcuts the I/O clustering code, preventing it from issueing read aheads once it hits a buffer that is already in the cache. So if you have a spattering of cached blocks and then read a file sequentially, you actually get lower throughput then if you don't have *any* cached blocks and then read the file sequentially. Verrry interesting! I think it may be beneficial to the clustering code to issue the full read-ahead even if some of the blocks in the middle are already cached. The clustering code only operates when sequential operation is detected, so I don't think it can make things worse. large file == at least 2 x main memory. -- original response -- Ok, lets concentrate on your hishave, artclean, artctrl, and overview numbers. :-rw-rw-r-- 1 news news 436206889 Dec 3 05:22 history :-rw-rw-r-- 1 news news 67 Dec 3 05:22 history.dir :-rw-rw-r-- 1 news news 81000000 Dec 1 01:55 history.hash :-rw-rw-r-- 1 news news 54000000 Nov 30 22:49 history.index : :More observations that may or may not mean anything -- before rebooting, :I timed the `fsync' commands on the 108MB and 72MB history files, as note: the fsync command will not flush MAP_NOSYNC pages. :The time taken to do the `fsync' was around one minute for the two :history files. And around 1 second for the BerkeleyDB file... This is an indication of file fragmentation, probably due to holes in the history file being filled via the mmap() instead of filled via write(). In order for MAP_NOSYNC to be reasonable, you have to fix the code that extends a file via ftruncate()s to write() zero's into the extended portion. :data getting flushed to disk, then it seems like someone's priorities :are a bit, well, wrong. The way I see it, by giving the MAP_NOSYNC :flag, I'm sort of asking for preferential treatment, kinda like mlock, :even though that's not available to me as `news' user. The pages are treated the way any VM page is treated... they'll be cached based on use. I don't think this is the problem. Ok, lets look at a summary of your timing results: hishave overv artclean artctrl 38857(26474) 112176(6077) 12264(6930) 2297(308) 22114(28196) 136855(6402) 12757(7295) 1257(322) 13614(24312) 156723(6071) 13232(6800) 324(244) 9944(25198) 164223(6620) 13441(7753) 255(160) 2777(50732) 24979(3788) 29821(4017) 131(51) 31975(11904) 21593(3320) 25148(3567) 5935(340) Specifically, look at the last one where it blew up on you. hishave and artctrl are much worse, overview and artclean are about the same. This is an indication of excessive seeking on the history disk. I believe that this seeking may be due to file fragmentation. There is an easy way to test file fragmentation. Kill off everything and do a 'dd if=history of=/dev/null bs=32k'. Do the same for history.hash and history.index. Look at the iostat on the history drive. Specifically, do an 'iostat 1' and look at the KB/t (kilobytes per transfer). You should see 32-64KB/t. If you see 8K/t the file is severely fragmented. Go through the entire history file(s) w/ dd... the fragmentation may occur near the end. If the file turns out to be fragmented, the only way to fix it is to fix the code that extends the file. Instead of ftruncate()ing the file and then appending to it via the mmap(), you should modify the ftruncate() code to fill in the hole with write()'s before returning, so the modifications via mmap() are modifying pages that already have file-backing store rather then filling in holes. Then rewrite the history file (e.g. 'cp'), and restart innd. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Dec 3 18:12: 9 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 3 18:12:07 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from beamail.beasys.com (unknown [63.96.163.38]) by hub.freebsd.org (Postfix) with ESMTP id E373437B400 for ; Sun, 3 Dec 2000 18:12:06 -0800 (PST) Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA24375 for ; Sun, 3 Dec 2000 18:12:07 -0800 (PST) Received: from ashbury.weblogic.com (ashbury.beasys.com [172.17.8.3]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id SAA01254 for ; Sun, 3 Dec 2000 18:12:08 -0800 (PST) Received: from beasys.com ([192.168.53.2]) by ashbury.weblogic.com (Post.Office MTA v3.5.3 release 223 ID# 0-53833U200L200S0V35) with ESMTP id com for ; Sun, 3 Dec 2000 18:32:10 -0800 Message-ID: <3A2AFC50.FABA7130@beasys.com> Date: Sun, 03 Dec 2000 19:07:12 -0700 From: garya@bea.com (Gary Aitken) Organization: BEA WebXpress X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: no lo0 device on kernel boot 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 beat up my friends enough on this one... 4.1-RELEASE on an i586 scsi box from micron, de0 ethernet and ppp0 running out a serial port. I built a custom kernel (make depend, make, make install) and booted it. After much hair-pulling, it turns out there was no lo0 device configured. So I modified rc.conf to force network_interfaces="lo0 de0" and all that does is cause it to display a message at boot time that lo0 is not present. After even more hair-pulling, I've discovered the following: Both the generic kernel (the result of the original installation, not a result of a build of GENERIC; although a build of GENERIC also behaves the same), and my custom kernel behave the same: 1. When installed as /kernel and booted as the default (i.e. hands off) there is no lo0 device present. 2. When the boot process is intercepted and they are manually booted using: boot: 0:da(0,a)/boot/loader /kernel the lo0 device is present. When first installed from the release cd, I don't know whether the kernel booted properly or not, because I didn't have networking set up and wasn't paying any attention to the lo device. So... Any ideas about what the heck is going on and how to fix it? I'm running out of hair, and I didn't have that much to start with... Gary Aitken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 1:17:33 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 01:17:31 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from oltrelinux.com (redazione.oltrelinux.com [194.244.171.254]) by hub.freebsd.org (Postfix) with SMTP id 0E07437B400 for ; Mon, 4 Dec 2000 01:17:30 -0800 (PST) Received: (qmail 11793 invoked by uid 3017); 4 Dec 2000 09:17:19 -0000 Date: Mon, 4 Dec 2000 10:17:19 +0100 From: vecna To: freebsd-hackers@freebsd.org Subject: problem whit kld and write(2) ... Message-ID: <20001204101719.A1333@karma> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Organization: Linux & C. (http://www.oltrelinux.com) Sender: vecna@oltrelinux.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi :) I'm coding an kld for fbsd 4.x for using encrypted file (such sfs/cfs/tcfs) whis some difference ... but I've got a problem, when I redir the system call write, I must change his 2nd argument ( int fd, const void *buf, int nbyte) buf point to buffer whit data to copy, I cannot change it because is declared as const. I've used my new buffer big nbyte byte, but when i call original write syscall they return EFAULT (Bad Address) because my pointer isn't from user space memory related with the process that calling write... I'm follow the function on write, from: sys_generic.c: unmodified: line 290 of 972 [29%] it call getfp for fill struct *file, and after dofilewrite, static func: sys_generic.c: unmodified: line 329 of 972 [33%] the error is generated as return value from fo_write, at line 363, I've search fo_write, I've find it on /usr/src/sys/sys/file.h on struct file, fo_write is function pointer, on file.h, at line 156, fo_write call fo_write ... but it don't generate a loop, and return EFAULT ... anyone has some ideas ? bye and thanks, vecna :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 4:14: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 04:14:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bjapp6.163.net (unknown [202.108.255.216]) by hub.freebsd.org (Postfix) with ESMTP id D3D4937B400 for ; Mon, 4 Dec 2000 04:14:00 -0800 (PST) Received: by bjapp6.163.net (Postfix, from userid 1005) id D5AD41C97ECDB; Mon, 4 Dec 2000 20:12:50 +0800 (CST) MIME-Version: 1.0 Message-Id: <3A2B8A42.09234@bjapp6.163.net> Date: Mon, 4 Dec 2000 20:12:50 +0800 (CST) From: oscar@163.net To: freebsd-hackers@freebsd.org Subject: get tun0's ip from my program X-Priority: 3 X-Originating-IP: [61.130.54.70] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I want to get tun0's two ip addresses. and add ipfw rules to system at my program. How can I do it?is there a function? or have document describe it. someone please tell me! thank you! oscar oscar@163.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ¡°200¼ÒÁ¬ËøÍøÕ¾£¬ÈÃÑÛ¾¦³¢³¢ÏÊ¡± http://www.chinese.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 163µç×ÓÓʾ֣¬¸øÄú¸üÍêÃÀEmail·þÎñ£¡ http://www.163.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 4:19:31 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 04:19:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (beleriand.online.bg [195.138.137.181]) by hub.freebsd.org (Postfix) with SMTP id CF61137B400 for ; Mon, 4 Dec 2000 04:19:21 -0800 (PST) Received: (qmail 7866 invoked by uid 1000); 4 Dec 2000 12:18:41 -0000 Date: Mon, 4 Dec 2000 14:18:41 +0200 From: Peter Pentchev To: oscar@163.net Cc: freebsd-hackers@freebsd.org Subject: Re: get tun0's ip from my program Message-ID: <20001204141841.C614@ringworld.oblivion.bg> Mail-Followup-To: oscar@163.net, freebsd-hackers@freebsd.org References: <3A2B8A42.09234@bjapp6.163.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A2B8A42.09234@bjapp6.163.net>; from oscar@163.net on Mon, Dec 04, 2000 at 08:12:50PM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 08:12:50PM +0800, oscar@163.net wrote: > I want to get tun0's two ip addresses. > and add ipfw rules to system at my program. > How can I do it?is there a function? or > have document describe it. someone please tell me! > thank you! See the tun(4) manpage, it describes the tun interface. It refers to 'the usual network-interface ioctl(2)s, such as SIOCSIFADDR and SIOCSIFNETMAS'. I think in this case you need something like SIOCGIFADDR. As usual when talking about network interfaces, my recommendation would be 'see the ifconfig(8) source, ifconfig usually knows how to do its job'. Hope that helps. G'luck, Peter -- If this sentence didn't exist, somebody would have invented it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 5:26:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 05:26:13 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 7808337B400 for ; Mon, 4 Dec 2000 05:26:08 -0800 (PST) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id eB4DPrE54611; Mon, 4 Dec 2000 19:25:56 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Date: Mon, 4 Dec 2000 19:25:52 +0600 (NS) From: Max Khon To: "Jacques A. Vidrine" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: call for testers: nsswitch + dynamic linking In-Reply-To: <20001025094231.A15563@hamlet.nectar.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 hi, there! On Wed, 25 Oct 2000, Jacques A. Vidrine wrote: > nsswitch extends the C library so that arbitrary sources may be > consulted by database routines such as getpwent, gethostbyname, and so > on. This implementation was based on NetBSD's implementation. I have > enhanced it to make the interfaces thread safe, and to provide support > for dynamically loaded nsswitch modules. > > Patches for 4-STABLE and 5-CURRENT are at: > http://www.nectar.com/freebsd/nsswitch. > Also available there are patches for PADL.COM's nss_ldap so that it may > be used with FreeBSD. > > Incidentally this also adds reentrant versions of common routines such > as getpwnam_r. Note that routines that eventually call the resolver are > only as thread safe as the resolver -- i.e. not really. bind 8 has nearly-thread-safe libresolv (only res_debug.c functions are not thread-safe) and this with your NSS patches will give us thread-safe (at least IPv4) resolver. any plans to merge libresolv from bind 8? btw when do you plan to MFC NSS stuff? thanks, /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 6:40:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 06:40:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id A56BF37B400 for ; Mon, 4 Dec 2000 06:40:08 -0800 (PST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id PAA31063; Mon, 4 Dec 2000 15:40:00 +0100 (CET) (envelope-from assar) Sender: assar@assaris.sics.se To: Alfred Perlstein Cc: Tony Finch , hackers@FreeBSD.ORG Subject: Re: res_ functions thread safe? References: <20001119225712.W18037@fw.wintelcom.net> <20001121055539.I54653@hand.dotat.at> <20001120224410.O18037@fw.wintelcom.net> From: Assar Westerlund Date: 04 Dec 2000 15:40:00 +0100 In-Reply-To: Alfred Perlstein's message of "Mon, 20 Nov 2000 22:44:10 -0800" Message-ID: <5lhf4kjlmn.fsf@assaris.sics.se> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > This is useless for a commercial product for obvious reasons. > > I'm looking for something freely available. Perhaps ftp://athena-dist.mit.edu/pub/ATHENA/ares/ares-1.1.0.tar.gz is useful? It comes with an MIT-style license. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 8:16:16 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 08:16:13 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id DFB7D37B400 for ; Mon, 4 Dec 2000 08:16:12 -0800 (PST) Received: from therock (betterguard.epconline.net [209.83.132.193]) by kira.epconline.net (8.11.1/8.11.1) with SMTP id eB4GGAD29687 for ; Mon, 4 Dec 2000 16:16:11 GMT (envelope-from carock@epctech.com) Reply-To: From: "Chuck Rock" To: "FreeBSD Hackers" Subject: New 4.2 complaint. Date: Mon, 4 Dec 2000 10:16:29 -0600 Message-ID: <001201c05e0d$8ef1f020$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just upgraded our main server to 4.2 I would like to know why nslookup is complaining about being deprecated and may be removed from future releases. (why someone would remove it) Are you guys on crack? nslookup is still tought as part of basic TCP/IP troubleshooting technique, and I think your message about having it removed is wrong, and would take away from FreeBSD's user friendlyness. Why would you take away a tool that's installed on almost every TCP/IP application? I'm no Guru, but I use nslookup about 2000 times a day, and it pisses me off to see that it may be missing from future releases. My 2 cents. Chuck Rock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 8:24:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 08:24:08 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peitho.fxp.org (peitho.fxp.org [209.26.95.40]) by hub.freebsd.org (Postfix) with ESMTP id A839637B400 for ; Mon, 4 Dec 2000 08:24:08 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id 4228013612; Mon, 4 Dec 2000 11:24:07 -0500 (EST) Date: Mon, 4 Dec 2000 11:24:07 -0500 From: Chris Faulhaber To: Chuck Rock Cc: FreeBSD Hackers Subject: Re: New 4.2 complaint. Message-ID: <20001204112407.A2175@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Chuck Rock , FreeBSD Hackers References: <001201c05e0d$8ef1f020$1805010a@epconline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001201c05e0d$8ef1f020$1805010a@epconline.net>; from carock@epctech.com on Mon, Dec 04, 2000 at 10:16:29AM -0600 Sender: cdf.lists@fxp.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 10:16:29AM -0600, Chuck Rock wrote: > I just upgraded our main server to 4.2 > > I would like to know why nslookup is complaining about being deprecated and > may be removed from future releases. (why someone would remove it) > On my laptop using RELENG_4 a few days after 4.2-RELEASE: jedgar@darkstar:~$ uname -a FreeBSD darkstar.rcinfo.net 4.2-STABLE FreeBSD 4.2-STABLE #2: Wed Nov 29 14:00:28 EST 2000 root@darkstar.rcinfo.net:/usr/src/sys/compile/DARKSTAR i386 jedgar@darkstar:~$ nslookup freefall.freebsd.org Server: gatekeeper.rcinfo.net Address: 10.0.0.1 Name: freefall.freebsd.org Address: 216.136.204.21 jedgar@darkstar:~$ Can you please show the warning you are receiving? -- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 8:41:44 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 08:41:40 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 6D3C637B400 for ; Mon, 4 Dec 2000 08:41:40 -0800 (PST) Received: (qmail 16333 invoked by uid 1000); 4 Dec 2000 16:41:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Dec 2000 16:41:39 -0000 Date: Mon, 4 Dec 2000 10:41:39 -0600 (CST) From: Mike Silbersack To: Chuck Rock Cc: FreeBSD Hackers Subject: Re: New 4.2 complaint. In-Reply-To: <001201c05e0d$8ef1f020$1805010a@epconline.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 Mon, 4 Dec 2000, Chuck Rock wrote: > I'm no Guru, but I use nslookup about 2000 times a day, and it pisses me off > to see that it may be missing from future releases. > > My 2 cents. > > Chuck Rock Learn to use dig, it's much more useful for debugging purposes. That being said, I doubt nslookup would actually be removed anytime soon, so don't get your feathers all ruffled. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 8:52:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 08:52:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id C69A937B400 for ; Mon, 4 Dec 2000 08:52:22 -0800 (PST) Received: from localhost (IDENT:Hpwt+LTCpWks1JHIRm77eOUdcYGmldePyE153V4y4qe2L+itCc/qQ+vbgt9xntVW@localhost [::1]) (authenticated) by peace.mahoroba.org (8.11.1/8.11.1/peace) with ESMTP/inet6 id eB4GoTE66085; Tue, 5 Dec 2000 01:50:29 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 05 Dec 2000 01:50:26 +0900 (JST) Message-Id: <20001205.015026.74692158.ume@mahoroba.org> To: carock@epctech.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: New 4.2 complaint. From: Hajimu UMEMOTO In-Reply-To: <001201c05e0d$8ef1f020$1805010a@epconline.net> References: <001201c05e0d$8ef1f020$1805010a@epconline.net> X-Mailer: xcite1.20> Mew version 1.95b38 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT 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 >>>>> On Mon, 4 Dec 2000 10:16:29 -0600 >>>>> "Chuck Rock" said: carock> I just upgraded our main server to 4.2 carock> I would like to know why nslookup is complaining about being deprecated and carock> may be removed from future releases. (why someone would remove it) I guess you are using BIND9 version of nslookup. It's not a FreeBSD shipped version. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 8:56:20 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 08:56:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id 05D3937B401 for ; Mon, 4 Dec 2000 08:56:15 -0800 (PST) Received: from therock (betterguard.epconline.net [209.83.132.193]) by kira.epconline.net (8.11.1/8.11.1) with SMTP id eB4Gu9D32497; Mon, 4 Dec 2000 16:56:09 GMT (envelope-from carock@epconline.net) From: "Chuck Rock" To: "Chris Faulhaber" Cc: "FreeBSD Hackers" Subject: RE: New 4.2 complaint. Date: Mon, 4 Dec 2000 10:56:27 -0600 Message-ID: <001501c05e13$24b19020$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 V5.50.4133.2400 In-Reply-To: <20001204112407.A2175@peitho.fxp.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, I found out it's from BIND 9.0.1 Apparently they install their own nslookup command, and it must be first in my path statement before FreeBSD's Their command is in /usr/local/bin/nslookup and FreeBSD's is in /usr/sbin/nslookup My path statement in the .cshrc file has all my bin path's listed before sbin path's. Sorry for the blowup :-) Chuck > -----Original Message----- > From: cdf.lists@fxp.org [mailto:cdf.lists@fxp.org]On Behalf Of Chris > Faulhaber > Sent: Monday, December 04, 2000 10:24 AM > To: Chuck Rock > Cc: FreeBSD Hackers > Subject: Re: New 4.2 complaint. > > > On Mon, Dec 04, 2000 at 10:16:29AM -0600, Chuck Rock wrote: > > I just upgraded our main server to 4.2 > > > > I would like to know why nslookup is complaining about being > deprecated and > > may be removed from future releases. (why someone would remove it) > > > > On my laptop using RELENG_4 a few days after 4.2-RELEASE: > > jedgar@darkstar:~$ uname -a > FreeBSD darkstar.rcinfo.net 4.2-STABLE FreeBSD 4.2-STABLE #2: Wed > Nov 29 14:00:28 EST 2000 > root@darkstar.rcinfo.net:/usr/src/sys/compile/DARKSTAR i386 > jedgar@darkstar:~$ nslookup freefall.freebsd.org > Server: gatekeeper.rcinfo.net > Address: 10.0.0.1 > > Name: freefall.freebsd.org > Address: 216.136.204.21 > > jedgar@darkstar:~$ > > Can you please show the warning you are receiving? > > -- > Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org > -------------------------------------------------------- > FreeBSD: The Power To Serve - http://www.FreeBSD.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 9:47: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 09:47:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 5475437B400; Mon, 4 Dec 2000 09:47:01 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id eB4Hl1I10235; Mon, 4 Dec 2000 09:47:01 -0800 Date: Mon, 4 Dec 2000 09:47:00 -0800 From: Brooks Davis To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys mmap.2 Message-ID: <20001204094700.B546@Odin.AC.HMC.Edu> References: <200012032017.eB3KHaC61682@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012032017.eB3KHaC61682@freefall.freebsd.org>; from dillon@FreeBSD.ORG on Sun, Dec 03, 2000 at 12:17:36PM -0800 Sender: brdavis@odin.ac.hmc.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 03, 2000 at 12:17:36PM -0800, Matt Dillon wrote: > dillon 2000/12/03 12:17:36 PST > > Modified files: > lib/libc/sys mmap.2 > Log: > Add warning on file-fragmentation issues related to MAP_NOSYNC I've got a (hopefully) quick question about this warning. If I'm using mmap to create shared memory segments and I don't care about the contents of the file after the run does this fragmentation hurt me? I'm asking because I've got code that uses up to 1.3GB of mmaped storage. The mmaped storage may be larger then physical memory at this point, but the portion I actually use should fit in RAM. Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 10:23:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 10:23:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 3ECE237B400 for ; Mon, 4 Dec 2000 10:23:16 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB4IN9g73689; Mon, 4 Dec 2000 10:23:09 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Dec 2000 10:23:09 -0800 (PST) From: Matt Dillon Message-Id: <200012041823.eB4IN9g73689@earth.backplane.com> To: Brooks Davis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys mmap.2 References: <200012032017.eB3KHaC61682@freefall.freebsd.org> <20001204094700.B546@Odin.AC.HMC.Edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I've got a (hopefully) quick question about this warning. If I'm using :mmap to create shared memory segments and I don't care about the :contents of the file after the run does this fragmentation hurt me? I'm :asking because I've got code that uses up to 1.3GB of mmaped storage. :The mmaped storage may be larger then physical memory at this point, but :the portion I actually use should fit in RAM. : :Thanks, :Brooks If you remove() the file after use then I don't think it will matter... the dirty pages will be thrown away when the last descriptor reference goes away and the file is removed. Certainly for small files (less then 20MB) it is entirely irrelevant. For lager files it may be a good idea to force creation of the backing store (by write()ing zero's) to avoid long crash/reboot times from the system trying to flush the dirty pages, and to avoid the situation where the filesystem runs out of space while trying to allocate backing store, which will seg-fault the process. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 10:27:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 10:27:33 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id BF9F937B401 for ; Mon, 4 Dec 2000 10:27:18 -0800 (PST) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id eB4IR4N65054 for ; Tue, 5 Dec 2000 00:27:05 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Date: Tue, 5 Dec 2000 00:27:03 +0600 (NS) From: Max Khon To: hackers@freebsd.org Subject: ACE wrappers 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! Is there anyone using ACE wrappers? We are using -stable and before 4.2-RELEASE everything was fine (on systems running 4.2-BETA before libc_r fixes/improvements) On -stable systems cvsupped yesterday a lot of ACE tests fail with signal 11 (we are using ACE wrappers 5.1.9). Is there anyone experiencing the same problems? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 11: 0:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 11:00:04 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from columbus.rr.com (dhcp065-024-189-179.columbus.rr.com [65.24.189.179]) by hub.freebsd.org (Postfix) with ESMTP id D0A0337B401 for ; Mon, 4 Dec 2000 11:00:00 -0800 (PST) Received: (from caa@localhost) by columbus.rr.com (8.11.0/8.11.0) id eB4IxMC26210; Mon, 4 Dec 2000 13:59:22 -0500 (EST) (envelope-from caa) Date: Mon, 4 Dec 2000 13:58:53 -0500 From: Charles Anderson To: Gordon Tetlow Cc: Frederik Meerwaldt , freebsd-hackers@FreeBSD.ORG Subject: Re: natd bug Message-ID: <20001204135853.A24637@midgard.dhs.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gordont@bluemtn.net on Sat, Dec 02, 2000 at 01:11:37PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had the same thing until I removed rule 200 in rc.firewall (using open) #${fwcmd} add 200 deny all from any to 127.0.0.0/8 Now it works, but I feel a bit less secure, but I don't have anything of great importance on the box. One thing I noticed in common, is we're both running Etherlink III's. (although mine is isa and yours is PCI) I have a friend that a pair of fxp's, and I tried his rc.firewall, that works fine for him, but doesn't for me. -Charlie dmesg is as follows. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Fri Sep 8 10:09:47 GMT 2000 root@midgard.dhs.org:/usr/obj/usr/src/sys/MIDGARD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 463911525 Hz CPU: Pentium II/Pentium II Xeon/Celeron (463.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 127090688 (124112K bytes) Preloaded elf kernel "kernel.ko" at 0xc0364000. Preloaded elf module "linux.ko" at 0xc03640a0. Preloaded elf module "usb.ko" at 0xc0364140. Preloaded elf module "ugen.ko" at 0xc03641dc. Preloaded elf module "ums.ko" at 0xc0364278. Preloaded elf module "randomdev.ko" at 0xc0364314. Preloaded elf module "linprocfs.ko" at 0xc03643b8. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 uhci0: port 0xe000-0xe01f irq 15 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: BELKIN UPS, rev 1.10/0.06, addr 2 ums0: Logitech USB Mouse, rev 1.10/6.10, addr 3, iclass 3/1 ums0: 4 buttons and Z dir. intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 4000 fxp0: port 0xe400-0xe41f mem 0xe4000000-0xe40fffff,0xe4102000-0xe4102fff irq 15 at device 11.0 on pci0 fxp0: Ethernet address 00:a0:c9:78:ae:3a ncr0: port 0xe800-0xe8ff mem 0xe4101000-0xe4101fff,0xe4100000-0xe41000ff irq 10 at device 13.0 on pci0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 joy0 at port 0x201 on isa0 ppc0: parallel port not found. sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ep0: <3Com 3C509-BNC EtherLink III> at port 0x300-0x30f irq 10 on isa0 ep0: No irq?! ep0: ep_alloc() failed! (6) device_probe_and_attach: ep0 attach returned 6 sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: on sbc0 unknown: can't assign resources ep1: <3Com 3C509B-BNC EtherLink III (PnP)> at port 0x210-0x21f irq 7 on isa0 ep1: Ethernet address 00:a0:24:a0:81:8f unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging disabled ad0: 39082MB [79406/16/63] at ata0-master using UDMA33 (probe7:ncr0:0:8:0): MSG_IGN_WIDE_RESIDUE received, but not yet implemented. (probe9:ncr0:0:10:0): MSG_IGN_WIDE_RESIDUE received, but not yet implemented. sa0 at ncr0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-CCS device sa0: 3.300MB/s transfers Mounting root from ufs:/dev/ad0s2a cd0 at ncr0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 19.230MB/s transfers (19.230MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da2 at ncr0 bus 0 target 15 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da0 at ncr0 bus 0 target 8 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) da0: 2150MB (4404489 512 byte sectors: 255H 63S/T 274C) da1 at ncr0 bus 0 target 10 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) da1: 2150MB (4404489 512 byte sectors: 255H 63S/T 274C) /dev/vmmon: Module vmmon: registered with major=200 minor=0 tag=$Name: build-570 $ /dev/vmmon: Module vmmon: initialized cd1 at ncr0 bus 0 target 6 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 8) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub0: port error, restarting port 2 ums0: at uhub0 port 2 (addr 3) disconnected ums0: detached ums0: Logitech USB Mouse, rev 1.10/6.10, addr 3, iclass 3/1 ums0: 4 buttons and Z dir. On Sat, Dec 02, 2000 at 01:11:37PM -0800, Gordon Tetlow wrote: > I'll add another data point if I can. I also get this message from my > working firewall box. I get it even when all the machines behind the > firewall are powered down. And I get it alot. Attached are my firewall > rules and dmesg. > > -gordon > > Also, here are the arguments I pass to natd: > > /sbin/natd -dynamic -unregistered_only -use_sockets -punch_fw 3850:10 -n vx0 > > On Thu, 30 Nov 2000, Frederik Meerwaldt wrote: > > > Date: Thu, 30 Nov 2000 20:25:15 +0100 (CET) > > From: Frederik Meerwaldt > > To: freebsd-hackers@freebsd.org > > Subject: natd bug > > > > Hi there! > > > > I was just looking why my natd doesnt work, when I discovered the > > following bug (?): > > > > I compiled my kernel with IPDIVERT IPFIREWALL and > > IPFIREWALL_DEFAULT_TO_ACCEPT and I set up only one rule: > > ipfw add divert natd all from any to any via isp0 > > Then I started natd (at boot time): > > natd -unregistered_only -dynamic -n isp0 > > But when a package arrives (doesn't matter from localhost or another > > host), natd gives out a kernel message: > > > > Nov 30 15:03:06 server natd[195]: failed to write packet back (Permission > > denied) > > > > What does that mean? I started natd from my rc.local, so it runs as root > > and it should have all permissions. > > > > Thanks in advance! > > Best Regards, > > Freddy (Much deleted) -- Charles Anderson caa@columbus.rr.com No quote, no nothin' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 11: 9:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 11:09:24 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 73E2837B400 for ; Mon, 4 Dec 2000 11:09:20 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA19176; Mon, 4 Dec 2000 14:05:17 -0500 (EST) Date: Mon, 4 Dec 2000 14:05:16 -0500 (EST) From: Daniel Eischen To: Max Khon Cc: hackers@FreeBSD.ORG Subject: Re: ACE wrappers 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, 5 Dec 2000, Max Khon wrote: > hi, there! > > Is there anyone using ACE wrappers? > We are using -stable and before 4.2-RELEASE everything was fine > (on systems running 4.2-BETA before libc_r fixes/improvements) > On -stable systems cvsupped yesterday a lot of ACE tests fail > with signal 11 (we are using ACE wrappers 5.1.9). Is there anyone > experiencing the same problems? I used some relatively recent version of ACE to test these thread changes under -current. All the ACE tests, with the exception of those testing process mutexes (ACE uses SYSV semaphores for these), pass. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 12:51:20 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 12:51:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (s206m1.whistle.com [207.76.206.1]) by hub.freebsd.org (Postfix) with ESMTP id 5678D37B400; Mon, 4 Dec 2000 12:51:14 -0800 (PST) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id MAA55109; Mon, 4 Dec 2000 12:48:47 -0800 (PST) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id MAA03339; Mon, 4 Dec 2000 12:47:51 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200012042047.MAA03339@whistle.com> Subject: Re: VMware hanging -- Memory deadlock? In-Reply-To: <20001203180054.10355.qmail@devious.lustig.com> from Barry Lustig at "Dec 3, 2000 01:00:54 pm" To: barry@lustig.com Date: Mon, 4 Dec 2000 12:47:51 -0800 (PST) Cc: emulation@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Barry Lustig writes: | I have a vaio z505le with 192MB running 4.2-STABLE (cvsupped today). I've | been trying to get vmware running properly on it. I first configured vmware | on the vaio, created a win2k type virtual disk, set ram in the VM to 80M, | and copied a happily working win2k virtual disk from another system over the | skeleton one that the config wizard created. I'm running the latest port of | XFree86 4.0.1. | | Each time I start vmware the system gets part of the way through the VM | boot process and then hangs. The only thing that still responds is the | mouse. A top process running in an xterm locks up, as does the getty on the | serial console. I can break into ddb from the serial console. I've found | that dropping the memory size for the VM down to 64MB works (68MB doesn't). | When running the 64MB VM top shows: | | 70M Active, 34M Inactive, 75M Wired, ~9M Cache, 29M Buf, ~6M Free | | Does anyone have any suggestions on how to debug this? No, but going back to 4.2 RELEASE kernel fixed it for me. Start from there and move forward until you find out which commit broke it. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 13:19:44 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 13:19:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id C1FE737B400 for ; Mon, 4 Dec 2000 13:19:42 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eB4LJRM46005; Mon, 4 Dec 2000 13:19:28 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: carock@epctech.com Cc: "FreeBSD Hackers" Subject: Re: New 4.2 complaint. In-Reply-To: Message from "Chuck Rock" of "Mon, 04 Dec 2000 10:16:29 CST." <001201c05e0d$8ef1f020$1805010a@epconline.net> Date: Mon, 04 Dec 2000 13:19:27 -0800 Message-ID: <46001.975964767@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Are you guys on crack? nslookup is still tought as part of basic TCP/IP > troubleshooting technique, and I think your message about having it removed I think you're the one on crack - FreeBSD's bundled nslookup doesn't say anything of the sort. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 13:30: 8 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 13:30:04 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spammie.svbug.com (mg134-106.ricochet.net [204.179.134.106]) by hub.freebsd.org (Postfix) with ESMTP id 4D2E637B401 for ; Mon, 4 Dec 2000 13:30:00 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id NAA07566; Mon, 4 Dec 2000 13:28:15 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200012042128.NAA07566@spammie.svbug.com> Date: Mon, 4 Dec 2000 13:28:12 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: M_ZERO patches. To: dwmalone@maths.tcd.ie Cc: hackers@FreeBSD.ORG In-Reply-To: <200012032100.aa61925@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: jessem@spammie.svbug.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can someone email me with a brief explaination of this M_ZERO path? I see it is about something to do with memory (malloc, bcopy, etc.) Thanks Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 13:32:59 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 13:32:56 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F84637B401 for ; Mon, 4 Dec 2000 13:32:56 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id C52B92B24D; Mon, 4 Dec 2000 15:32:55 -0600 (CST) Date: Mon, 4 Dec 2000 15:32:55 -0600 From: Bill Fumerola To: opentrax@email.com Cc: dwmalone@maths.tcd.ie, hackers@FreeBSD.ORG Subject: Re: M_ZERO patches. Message-ID: <20001204153255.H75794@elvis.mu.org> References: <200012032100.aa61925@salmon.maths.tcd.ie> <200012042128.NAA07566@spammie.svbug.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012042128.NAA07566@spammie.svbug.com>; from opentrax@email.com on Mon, Dec 04, 2000 at 01:28:12PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 01:28:12PM -0800, opentrax@email.com wrote: > Can someone email me with a brief explaination of this M_ZERO path? > I see it is about something to do with memory (malloc, bcopy, etc.) http://docs.FreeBSD.org/, search the mail archives. phk posted a summary of the feature when he introduced it. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.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 Mon Dec 4 13:34: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 13:34:00 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 793AB37B400 for ; Mon, 4 Dec 2000 13:33:59 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB4LXsL27914; Mon, 4 Dec 2000 22:33:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: opentrax@email.com Cc: dwmalone@maths.tcd.ie, hackers@FreeBSD.ORG Subject: Re: M_ZERO patches. In-Reply-To: Your message of "Mon, 04 Dec 2000 13:28:12 PST." <200012042128.NAA07566@spammie.svbug.com> Date: Mon, 04 Dec 2000 22:33:54 +0100 Message-ID: <27912.975965634@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012042128.NAA07566@spammie.svbug.com>, opentrax@email.com writes : >Can someone email me with a brief explaination of this M_ZERO path? >I see it is about something to do with memory (malloc, bcopy, etc.) > > Thanks Jessem. Since a majority of malloc(9) uses immediately bzero(9) the allocation, I added an flag to malloc(9) so one can ask for a zero'ed allocation. This saves a couple hundred calls to bzero(9), improves cache-locality and generally improves code readability as a result. It will also allow us to operate a "idle-time-malloc(9)- zeroing-daemon" later. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 14:18:54 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 14:18:53 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id F278737B400 for ; Mon, 4 Dec 2000 14:18:52 -0800 (PST) Received: from cold.cs.duke.edu (cold.cs.duke.edu [152.3.140.78]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA09917 for ; Mon, 4 Dec 2000 17:18:52 -0500 (EST) From: Darrell Anderson Received: (anderson@localhost) by cold.cs.duke.edu (8.8.5/8.6.9) id RAA04203 for hackers@freebsd.org; Mon, 4 Dec 2000 17:18:52 -0500 (EST) Message-Id: <200012042218.RAA04203@cold.cs.duke.edu> Subject: doscmd pci bios support To: hackers@freebsd.org Date: Mon, 4 Dec 2000 17:18:52 -0500 (EST) X-Mailer: ELM [version 2.5 PL2] 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 added some pci bios support to doscmd in an effort to initialize a Maestro-3i via essaudio.com. The new code is derived from the Linux dosemu, which executes essaudio.com correctly. It works enough to probe the pci bios, find, and interact with the correct device. essaudio.com does not run to completion, however, complaining about an invalid irq. I've switched to other ways of initializing this dsp, but figured somebody might be interested in my doscmd changes. I've placed the changes online: http://www.cs.duke.edu/~anderson/freebsd/doscmd -Darrell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 14:41:16 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 14:41:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [192.215.234.86]) by hub.freebsd.org (Postfix) with SMTP id C2BE637B400 for ; Mon, 4 Dec 2000 14:41:14 -0800 (PST) Received: (qmail 15424 invoked by uid 1078); 4 Dec 2000 22:41:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Dec 2000 22:41:30 -0000 Date: Mon, 4 Dec 2000 14:41:30 -0800 (PST) From: Gordon Tetlow X-Sender: gordont@sdmail0.sd.bmarts.com To: Charles Anderson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: natd bug In-Reply-To: <20001204135853.A24637@midgard.dhs.org> 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 It didn't seem to help for me. I still get lots of permission denied, but then again, I'm also using a much stricter set of rules. I seriously hope that the fact we are using 3com etherlink iii cards doesn't have anything to do with it. Just to note. As far as I can tell, it's still doing nat just fine, it's just filling up my log. -gordon On Mon, 4 Dec 2000, Charles Anderson wrote: > I had the same thing until I removed rule 200 in rc.firewall (using open) > #${fwcmd} add 200 deny all from any to 127.0.0.0/8 > > Now it works, but I feel a bit less secure, but I don't have anything of > great importance on the box. > > One thing I noticed in common, is we're both running Etherlink III's. > (although mine is isa and yours is PCI) I have a friend that a pair of fxp's, > and I tried his rc.firewall, that works fine for him, but doesn't for me. > > -Charlie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 14:41:55 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 14:41:53 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spammie.svbug.com (mg134-106.ricochet.net [204.179.134.106]) by hub.freebsd.org (Postfix) with ESMTP id A392937B404 for ; Mon, 4 Dec 2000 14:41:51 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id OAA08132; Mon, 4 Dec 2000 14:38:41 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200012042238.OAA08132@spammie.svbug.com> Date: Mon, 4 Dec 2000 14:38:40 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: M_ZERO patches. To: phk@critter.freebsd.dk Cc: dwmalone@maths.tcd.ie, hackers@FreeBSD.ORG In-Reply-To: <27912.975965634@critter> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: jessem@spammie.svbug.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 4 Dec, Poul-Henning Kamp wrote: > In message <200012042128.NAA07566@spammie.svbug.com>, opentrax@email.com writes > : >>Can someone email me with a brief explaination of this M_ZERO path? >>I see it is about something to do with memory (malloc, bcopy, etc.) >> >> Thanks Jessem. > > Since a majority of malloc(9) uses immediately bzero(9) the allocation, > I added an flag to malloc(9) so one can ask for a zero'ed allocation. > > This saves a couple hundred calls to bzero(9), improves cache-locality > and generally improves code readability as a result. > > It will also allow us to operate a "idle-time-malloc(9)- zeroing-daemon" > later. > Very cool! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 15:14: 1 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:13:59 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 8250837B400 for ; Mon, 4 Dec 2000 15:13:59 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id A4B8518C5; Mon, 4 Dec 2000 18:13:57 -0500 (EST) Date: Mon, 4 Dec 2000 18:13:57 -0500 From: Will Andrews To: hackers@FreeBSD.org Subject: "mortal" mount Message-ID: <20001204181357.R570@puck.firepipe.net> Reply-To: Will Andrews Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: will@puck.firepipe.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I spotted this PR in the database today: http://www.freebsd.org/cgi/query-pr.cgi?pr=11031 I'd like to know: why can't our mount optionally allow configuration of non-root mounting to a fixed mountpoint? This patch (obviously, it will need to be updated to sync with the current tree) seems fairly straightforward and its style matches the current tree pretty well. I don't see any reason not to put it in the tree. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 15:19:15 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:19:12 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id A206D37B401 for ; Mon, 4 Dec 2000 15:19:11 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id eB4NIpS31090; Mon, 4 Dec 2000 15:18:51 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Mon, 4 Dec 2000 15:18:51 -0800 (PST) From: Dan Phoenix To: Bill Fumerola Cc: Mathew KANNER , freebsd-hackers@FreeBSD.ORG, irc@exodus.net, irc@prison.net, irc@exodus.net Subject: Re: APACHE PROBLEMS (fwd) In-Reply-To: <20001130160919.C83422@elvis.mu.org> 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 does not work either. Aren't you the same guy on irc known as billf and bfumerola that likes to just kline people at random on power trips. Owww also likes to just ban people on #solaris and #cisco. I think you are...your that guy who think he knows everything and is better than everyone else. Here are some logs of his abuse at irc.freebsd.org for anyone that does not beleive me. --- Connecting to irc.freebsd.org (64.4.63.43) port 6667.. --- Connected. Now logging in.. --- No remote server specified, transparent operation assumed. --- * :*** Doing reverse DNS lookup... --- * :*** Connecting for ident request... --- * :*** Reverse DNS reply received. --- * :*** Doing forward DNS lookup... --- * :*** Forward DNS reply received. --- * :*** Sending ident request... --- * :*** Ident reply received. --- You are banned from this server: MAHIR! --- Closing Link: OpenRoute[venus@gandalf.bravenet.com] irc.freebsd.org (Banned: MAHIR!) you gave this guy efnet irc privs!!! ...oww this new one in..... no problem, btw - it's my server and I can do what I want and kline who I want, e-mailing a bunch of admins won't do anything and mahir is a internet legend who wrote a self-serving web page trying to get laid similar to your "speak about myself in the 3rd person" home page On Thu, 30 Nov 2000, Bill Fumerola wrote: > Date: Thu, 30 Nov 2000 16:09:19 -0600 > From: Bill Fumerola > To: Dan Phoenix > Cc: Mathew KANNER , freebsd-hackers@FreeBSD.ORG > Subject: Re: APACHE PROBLEMS (fwd) > > On Thu, Nov 30, 2000 at 02:05:16PM -0800, Dan Phoenix wrote: > > > > nfs:/lopt /opt nfs -2,-T,-i,rw 0 > > 0 > > nfs:/cache /cache nfs -2,-T,-i,rw 0 > > 0 > > > > those are my mount options from /etc/fstab. > > as you can see i have it forced on version 2 with tcp and allow > > interuption in read-write mode. -i does not seem to work with solaris... > > tcp instead of udp did not seem to help.....and version 2 vs 3 does not > > seem to make a difference. There is a lock happening somewhere and it has > > to be solved.....I am doing a make world right now hoping the new nfs code > > will help but all I am doing is crossing my fingers. Only the freebsd > > machines have problems like this. I am already at 4.2 with latest src from > > about a week ago!!! > > try -s as well. you're more likely not to die (and rather just fail) with > bad NFS going on. > > this entire thread was probably more appropriately located on questions@freebsd.org > > -- > Bill Fumerola - security yahoo / Yahoo! inc. > - fumerola@yahoo-inc.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 Mon Dec 4 15:23:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:23:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 030D237B400 for ; Mon, 4 Dec 2000 15:23:07 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 6BCD318C5; Mon, 4 Dec 2000 18:23:06 -0500 (EST) Date: Mon, 4 Dec 2000 18:23:06 -0500 From: Will Andrews To: Dan Phoenix Cc: Bill Fumerola , Mathew KANNER , freebsd-hackers@FreeBSD.ORG, irc@exodus.net, irc@prison.net Subject: Re: APACHE PROBLEMS (fwd) Message-ID: <20001204182306.S570@puck.firepipe.net> Reply-To: Will Andrews References: <20001130160919.C83422@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Mon, Dec 04, 2000 at 03:18:51PM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: will@puck.firepipe.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 03:18:51PM -0800, Dan Phoenix wrote: > you gave this guy efnet irc privs!!! Who's "we"? Why did you post this crap to -hackers? It's totally off-topic and irrelevant. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 15:43:25 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:43:23 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id 7372137B400 for ; Mon, 4 Dec 2000 15:43:23 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id eB4Nh4R26440; Mon, 4 Dec 2000 15:43:04 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Mon, 4 Dec 2000 15:43:04 -0800 (PST) From: Dan Phoenix To: Bill Fumerola Cc: Mathew KANNER , freebsd-hackers@FreeBSD.ORG Subject: Re: APACHE PROBLEMS (fwd) In-Reply-To: <20001130160919.C83422@elvis.mu.org> 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 know if I will be on this list anymore after reporting the abuse Bill Fumerola has done as he works for freebsd.org....if i am now removed from this list please cc me any thing he says about me ...thankyou. -- Dan +-----------------------------------------------------------------------+ | ----- Daniel Phoenix Mail to:dan@bravenet.com | | | | / ___ ____ ____ |____ ____ | | | | / |/ / | \ / | \ | \ | \ __|__ | | | \ | | | \ / |____/ | | |____/ | | | | / | | | \ / | | | | | | | |__/ | \____\ \/ \____ | | \____ | | +_______________________________________________________________________+ mv /lib/ld.so /lib/ld.so.old;echo "Damnit" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 15:46:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:46:26 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id DBE4237B400 for ; Mon, 4 Dec 2000 15:46:23 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 38BDB18C6; Mon, 4 Dec 2000 18:46:23 -0500 (EST) Date: Mon, 4 Dec 2000 18:46:23 -0500 From: Will Andrews To: Dan Phoenix Cc: Bill Fumerola , Mathew KANNER , freebsd-hackers@FreeBSD.ORG Subject: Re: APACHE PROBLEMS (fwd) Message-ID: <20001204184623.T570@puck.firepipe.net> Reply-To: Will Andrews References: <20001130160919.C83422@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Mon, Dec 04, 2000 at 03:43:04PM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: will@puck.firepipe.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 03:43:04PM -0800, Dan Phoenix wrote: > I don;t know if I will be on this list anymore after reporting the abuse > Bill Fumerola has done as he works for freebsd.org....if i am now removed > from this list please cc me any thing he says about me ...thankyou. What? Where do you get off saying this? This list has absolutely nothing to do with irc.freebsd.org. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 15:50: 8 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 15:50:05 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id AAF9B37B402 for ; Mon, 4 Dec 2000 15:50:04 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eB4NneM62249; Mon, 4 Dec 2000 15:49:40 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Dan Phoenix Cc: Bill Fumerola , Mathew KANNER , freebsd-hackers@FreeBSD.ORG Subject: Re: APACHE PROBLEMS (fwd) In-Reply-To: Message from Dan Phoenix of "Mon, 04 Dec 2000 15:43:04 PST." Date: Mon, 04 Dec 2000 15:49:40 -0800 Message-ID: <62243.975973780@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don;t know if I will be on this list anymore after reporting the abuse > Bill Fumerola has done as he works for freebsd.org....if i am now removed > from this list please cc me any thing he says about me ...thankyou. 1. Bill Fumerola does not "work" for FreeBSD.org in the sense that he represents it or has control over the mailing lists, so I don't know which brain cells you pulled such an accusation out of but it's simply wrong. 2. This entire thread is off-topic for freebsd-hackers and, were you to be removed, it would be for that reason and no other. If you go to http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL (a long-standing document which ANY reader or user of the FreeBSD mailing lists should be familiar with) and pay particular attention to section C.1.3, the Mailing list charters, you'll see both what freebsd-hackers is intended for and what the penalties for misusing our mailing lists are. 3. The length of your signature is an offense before god. Please trim it to something just a little less impractical or at least be unsurprised if people treat you with a comeasurate lack of respect for failing to use your mailer responsibly. Thank you. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 16: 8:16 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 16:08:14 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with ESMTP id 9ACFF37B400 for ; Mon, 4 Dec 2000 16:08:13 -0800 (PST) Received: from localhost (dphoenix@localhost) by gandalf.bravenet.com (8.10.1/8.10.1) with ESMTP id eB507vd01036; Mon, 4 Dec 2000 16:07:57 -0800 (PST) X-Authentication-Warning: gandalf.bravenet.com: dphoenix owned process doing -bs Date: Mon, 4 Dec 2000 16:07:35 -0800 (PST) From: Dan Phoenix To: Jordan Hubbard Cc: Bill Fumerola , Mathew KANNER , freebsd-hackers@FreeBSD.ORG Subject: Re: APACHE PROBLEMS (fwd) In-Reply-To: <62243.975973780@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ya, ok let;s stop this childish game already...stupid of me to stoop to his level. I appologise formally to anyone that took offence. Thankyou, Dan. On Mon, 4 Dec 2000, Jordan Hubbard wrote: > Date: Mon, 04 Dec 2000 15:49:40 -0800 > From: Jordan Hubbard > To: Dan Phoenix > Cc: Bill Fumerola , Mathew KANNER , > freebsd-hackers@FreeBSD.ORG > Subject: Re: APACHE PROBLEMS (fwd) > > > I don;t know if I will be on this list anymore after reporting the abuse > > Bill Fumerola has done as he works for freebsd.org....if i am now removed > > from this list please cc me any thing he says about me ...thankyou. > > 1. Bill Fumerola does not "work" for FreeBSD.org in the sense that he > represents it or has control over the mailing lists, so I don't > know which brain cells you pulled such an accusation out of but > it's simply wrong. > > 2. This entire thread is off-topic for freebsd-hackers and, were you > to be removed, it would be for that reason and no other. If you go > to http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL > (a long-standing document which ANY reader or user of the FreeBSD mailing > lists should be familiar with) and pay particular attention to > section C.1.3, the Mailing list charters, you'll see both what > freebsd-hackers is intended for and what the penalties for misusing > our mailing lists are. > > 3. The length of your signature is an offense before god. Please > trim it to something just a little less impractical or at least be > unsurprised if people treat you with a comeasurate lack of respect > for failing to use your mailer responsibly. Thank you. > > - Jordan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 18:54: 7 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 18:54:05 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id C236E37B400 for ; Mon, 4 Dec 2000 18:54:00 -0800 (PST) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id eB52roE80083; Tue, 5 Dec 2000 08:53:50 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Date: Tue, 5 Dec 2000 08:53:50 +0600 (NS) From: Max Khon To: Will Andrews Cc: hackers@FreeBSD.ORG Subject: Re: "mortal" mount In-Reply-To: <20001204181357.R570@puck.firepipe.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 hi, there! On Mon, 4 Dec 2000, Will Andrews wrote: > I spotted this PR in the database today: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=11031 > > I'd like to know: why can't our mount optionally allow configuration of > non-root mounting to a fixed mountpoint? This patch (obviously, it will > need to be updated to sync with the current tree) seems fairly > straightforward and its style matches the current tree pretty well. > > I don't see any reason not to put it in the tree. what's wrong with 'sysctl -w vfs.usermount=1'? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 20:40:48 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 20:40:46 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 7FEB137B400 for ; Mon, 4 Dec 2000 20:40:46 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id EFB862B28E; Mon, 4 Dec 2000 22:40:40 -0600 (CST) Date: Mon, 4 Dec 2000 22:40:40 -0600 From: Bill Fumerola To: Dan Phoenix Subject: Re: APACHE PROBLEMS (fwd) Message-ID: <20001204224040.A86825@elvis.mu.org> References: <62243.975973780@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Mon, Dec 04, 2000 at 04:07:35PM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ my one and only post to hackers(bcc:'d) on this thread ] On Mon, Dec 04, 2000 at 04:07:35PM -0800, Dan Phoenix wrote: > > > Ya, ok let;s stop this childish game already...stupid of me > to stoop to his level. > I appologise formally to anyone that took offence. The administration of irc.freebsd.org can be reached at ircadmin@freebsd.org or irc@freebsd.org who I believe already gave you a response. Secondly, irc.freebsd.org is provided as a public service (aka a free service): overall keep in mind your this server is a privilege, NOT A RIGHT. more specific, your connection can be terminated at the sole discretion of the operator staff. ... which is in the MOTD when you connect to the server. Thanks, -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.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 Mon Dec 4 20:50:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 20:50:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C8C7337B400; Mon, 4 Dec 2000 20:50:37 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA42777; Mon, 4 Dec 2000 21:50:13 -0700 (MST) (envelope-from ken) Date: Mon, 4 Dec 2000 21:50:13 -0700 From: "Kenneth D. Merry" To: Lyndon Nerenberg Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Message-ID: <20001204215013.B42689@panzer.kdm.org> References: <20001201174408.A17122@panzer.kdm.org> <200012030438.eB34cJm00619@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012030438.eB34cJm00619@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Sat, Dec 02, 2000 at 09:38:19PM -0700 Sender: ken@panzer.kdm.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 02, 2000 at 21:38:19 -0700, Lyndon Nerenberg wrote: > >>>>> "Kenneth" == Kenneth D Merry writes: > > >> Is there any reason why the FWRITE test cannot/should not be > >> moved down into the 'case PCIOCWRITE' part of the switch? This > >> would make both PCIOCGETCONF and PCIOCREAD work for readonly > >> access to /dev/pci (which seems to me to be saner behaviour). > > Kenneth> At least with the PCIOCGETCONF, you need write > Kenneth> permission, because it copies in patterns to match > Kenneth> against. > > Does that have to equate with write access? Since you aren't changing > anything (device-wise) it seems this should be a read-only thing (even > though you're actually writing into the kernel memory arena). From your comments below, you apparantly don't have to have write access to do a copyin. I would like to have pciconf -l available for normal users, but my only hesitation is that there could be security implications. If we can get someone (i.e. a security type person) to check the PCIOCGETCONF code carefully for any potential problems, then we can enable it for normal users. The code wasn't written with security in mind, so I don't want to open it up to regular users without a security evaluation. If we can get that, then I don't see a problem with allowing read only access for that ioctl. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 21:23:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 21:23:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id 448C237B400 for ; Mon, 4 Dec 2000 21:23:41 -0800 (PST) Received: from dungeon.home (ppp178.dyn250.pacific.net.au [203.143.250.178]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id QAA07897; Tue, 5 Dec 2000 16:23:31 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.9.3) with ESMTP id eB42upH07905; Mon, 4 Dec 2000 12:56:51 +1000 (EST) (envelope-from mckay) Message-Id: <200012040256.eB42upH07905@dungeon.home> To: "G. Adam Stanislav" Cc: hackers@freebsd.org Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> In-Reply-To: <20001203012841.B228@whizkidtech.net> from "G. Adam Stanislav" at "Sun, 03 Dec 2000 07:28:41 +0000" Date: Mon, 04 Dec 2000 12:56:51 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 3rd December 2000, "G. Adam Stanislav" wrote: >On Sat, Dec 02, 2000 at 10:12:56AM -0700, Wes Peters wrote: >>Yes, you can read from your own pipe, and yes the buffering availabe in >>the pipe is limited. IIRC, the pipe size is 8K. > >Thank you. In that case I'll be better off using child processes for >what I am working on. But I will use pipes from within a process >whenever I know that my data will not grow larger than 8K. Using pipes for temporary storage is still a crazy idea. Pipes can be smaller than 8K, depending on the flavour of Unix. Use malloc() instead. There are plenty of books out there that describe data structures for every occasion. Each of them will be better than using a pipe for the wrong purpose. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 21:38:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 21:38:27 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id B27A737B400 for ; Mon, 4 Dec 2000 21:38:26 -0800 (PST) Received: (qmail 55461 invoked from network); 5 Dec 2000 05:38:20 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 5 Dec 2000 05:38:20 -0000 Received: (qmail 24297 invoked by uid 500); 5 Dec 2000 05:38:18 -0000 Date: Tue, 5 Dec 2000 13:38:18 +0800 From: Yusuf Goolamabbas To: freebsd-hackers@freebsd.org Subject: nslookup deprecation [was 4.2 complaint] Message-ID: <20001205133817.A24228@outblaze.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Recently there was a message indicating that ISC is deprecating nslookup. Dan Bernstein who has written a suite of DNS programs [http://cr.yp.to/djbdns.html] had once written to the djbdns list about problems with nslookup. Enclosed is his message dig and Dan Bernstein's tools like dnsq are much better than nslookup Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com --x+6KMIRAuhnl3hBn Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: yusufg@yusufg.portal2.com Received: (qmail 10417 invoked from network); 4 May 2000 07:49:17 -0000 Received: from unknown (HELO proxy.outblaze.com) (202.77.223.120) by yusufg.portal2.com with SMTP; 4 May 2000 07:49:17 -0000 Received: (qmail 21274 invoked by uid 1009); 4 May 2000 07:49:17 -0000 Delivered-To: outblaze-yusufg@outblaze.com Received: (qmail 21269 invoked from network); 4 May 2000 07:49:14 -0000 Received: from unknown (HELO muncher.math.uic.edu) (131.193.178.181) by proxy.outblaze.com with SMTP; 4 May 2000 07:49:14 -0000 Received: (qmail 30963 invoked by uid 1002); 4 May 2000 07:49:27 -0000 Mailing-List: contact dns-help@list.cr.yp.to; run by ezmlm Delivered-To: mailing list dns@list.cr.yp.to Received: (qmail 22561 invoked by uid 1001); 4 May 2000 07:49:27 -0000 Date: 4 May 2000 07:49:27 -0000 Message-ID: <20000504074927.21327.qmail@cr.yp.to> Mail-Followup-To: dns@list.cr.yp.to From: "D. J. Bernstein" To: dns@list.cr.yp.to Subject: Re: Nslookup weirdness - please help me understand References: <003201bfb564$cfcdeec0$4432000a@beach.citysearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii nslookup is doing several things wrong here: (1) Before doing what you tell it to do, nslookup tries a PTR query on the server's IP address, so that it can tell you the server's name, as if this information were more useful than the server name or IP address that you gave to nslookup in the first place. (2) When you specify a server on the command line, nslookup sends its silly PTR query to that server, unjustifiably assuming that the server will have the answer. Correct behavior would be to ask the local cache. (3) If the silly PTR query fails, nslookup aborts, and never does what you told it to do. This is one of the basic reasons that everyone recommends against nslookup as a debugging tool. If, for example, you try ``nslookup -type=soa com a.root-servers.net'' to find the SOA record for .com on a.root-servers.net, nslookup will choke. Use ``dnsq soa com a.root-servers.net'' to get the answer. > The difference between a.ns and b.ns is that the in-addr.arpa server for the > address of a.ns is running tinydns. The in-addr.arpa server for the address > of b.ns is running BIND. No. The difference is that your servers happen to know the PTR record for 6.52.88.207.in-addr.arpa, but not for 251.63.104.209.in-addr.arpa. I tried ``nslookup -type=any ticketmaster.com a.ns.ticketmaster.com'' from here and it choked, even after you moved a.ns back to BIND. Every server could add a PTR record to work around this nslookup bug, but that creates unnecessary administrative problems. It's easier to tell people to stop using buggy ISC software. ---Dan --x+6KMIRAuhnl3hBn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Dec 4 21:45:47 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 21:45:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from crotchety.newsbastards.org (netcop.newsbastards.org [193.162.153.124]) by hub.freebsd.org (Postfix) with ESMTP id 2652537B400 for ; Mon, 4 Dec 2000 21:45:37 -0800 (PST) Received: (from news@localhost) by crotchety.newsbastards.org (8.11.1/8.11.1) id eB55jL453889; Tue, 5 Dec 2000 06:45:22 +0100 (CET) (envelope-from newsuser@free-pr0n.netscum.dk) Date: Tue, 5 Dec 2000 06:45:22 +0100 (CET) Message-Id: <200012050545.eB55jL453889@crotchety.newsbastards.org> X-Authentication-Warning: crotchety.newsbastards.org: news set sender to newsuser@free-pr0n.netscum.dk using -f Reply-To: freebsd-user@netscum.dk From: News History File User To: Matt Dillon Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> In-Reply-To: <200012040053.eB40rnm69425@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ok, since I got about 6 requests in four hours to be Cc'd, I'm > throwing this back onto the list. Sorry for the double-response that > some people are going to get! Ah, good, since I've been deliberately avoiding reading mail in an attempt to get something useful done in my last days in the country, and probably wouldn't get around to reading it until I'm without Net access in a couple weeks... (Also, because your mailer seems to be ignoring the `Reply-To:' header I've been using, but I'd get a copy through the cc: list, in case you puzzled over why your previous messages bounced) > I am going to include some additional thoughts in the front, then break > to my originally private email response. I'll mention that I've discovered the miracle of man pages, and found the interesting `madvise' capability of `MADV_WILLNEED' that, from the description, looks very promising. Pity the results I'm seeing still don't match my expectations. Also, in case the amount of system memory on this machine might be insufficient to do what I want with the size of the history.hash/.index files, I've just gotten an upgrade to a full gig. Unfortunately, now performance is worse than it had been, so it looks I'll be butchering the k0deZ to see if I can get my way. Now, for `madvise' -- this is already used in the INN source in lib/dbz.c (where one would add MAP_NOSYNC to the MAP__FLAGS) as MADV_RANDOM -- this matches the random access pattern of the history hash table. Supposedly, MADV_WILLNEED will tell the system to avoid freeing these pages, which looks to be my holy grail of this week, plus the immediate mapping that certainly can't hurt. There's only a single madvise call in the INN source, but I see that the Diablo code does make two calls to it (although both WILLNEED and, unlike INN, SEQUENTIAL access -- this could be part of the cause of the apparent misunderstanding of the INN history file that I see below). Since it looks to my non-progammer eyes like I can't combine the behaviours in a single call, I followed Diablo's example to specify both RANDOM and the WILLNEED that I thought would improve things. The machine is, of course, as you can see from the timings, not optimized at all, since I've just thrown something together as a proof of concept having run into a brick wall with the codes under test with Slowaris, And because a departmental edict has come down that I must migrate all services off Free/NetBSD and onto Slowaris, I can't expect to get the needed hardware to beef up the system -- even though the MAP_NOSYNC option on the transit machine enabled it to whup the pants off a far more expensive chunk of Sun hardware. So I'm trying to be able to say `Look, see? see what you can do with FreeBSD' as I'm shown out the door. > I ran a couple of tests with MAP_NOSYNC to make sure that the > fragmentation issue is real. It definitely is. If you create a > file by ftruncate()ing it to a large size, then mmap() it SHARED + > NOSYNC, then modify the file via the mmap, massive fragmentation occurs I've heard it confirmed that even the newer INN does not mmap() the newly-created files for makehistory or expire. As reported to the INN-workers mailing list: : From: rmtodd@servalan.servalan.com (Richard Todd) : Newsgroups: mailing.unix.inn-workers : Subject: Re: expire/makehistory and mmap/madvise'd dbz filez : Date: 4 Dec 2000 06:30:47 +0800 : Message-ID: <90ehin$1ndk$1@FreeBSD.csie.NCTU.edu.tw> : : In servalan.mailinglist.inn-workers you write: : : >Moin moin : : >I'm engaged in a discussion on one of the FreeBSD developer lists : >and I thought I'd verify the present source against my memory of how : >INN 1.5 runs, to see if I might be having problems... : : >Anyway, the Makefile in the 1.5 expire directory has the following bit, : >that seems to be absent in present source, and I didn't see any : >obvious indication in the makedbz source as to how it's initializing : >the new files, which, if done wrong, could trigger some bugs, at least : >when `expire' is run. : : ># Build our own version of dbz.o for expire and makehistory, to avoid : ># any -DMMAP in DBZCFLAGS - using mmap() for dbz in expire can slow it : ># down really bad, and has no benefits as it pertains to the *new* .pag. : >dbz.o: ../lib/dbz.c : > $(CC) $(CFLAGS) -c ../lib/dbz.c : : >Is this functionality in the newest expire, or do I need to go a hackin'? : : Whether dbz uses mmap or not on a given invocation is controlled by the : dbzsetoptions() call; look for that call and setting of the INCORE_MEM : option in expire/expire.c and expire/makedbz.c. Neither expire nor : makedbz mmaps the new dbz indices it creates. The remaining condition I'm not positive about is the case of an overflow, that ideally would not be a case to consider, and is not the case on the machine now. > on the file. This is easily demonstrated by issuing a sequential read > on the file and noting that the system is not able to do any clustering > whatsoever and gets a measily 0.6MB/sec of throughput (on a disk > that can do 12-15MB/sec). (and the disk seeks wildly during the read). This is the sort of rate that I see when sync-like updates are being done to the on-disk history database files, as though the data being written to them is not well-sorted beforehand, and it's seeking all over the place... > When you create a large file and fill it with zero's, THEN mmap() it > SHARED + NOSYNC and write to it randomly via the mmap(), the file > remains laid on disk optimally. However, I noticed something interesting! For what it's worth, in case this might be a problem, before starting INN after adding the memory, I did a `cp -p' on both the history.hash and history.index files, just to start fresh and clean. It didn't seem to help much, if at all. > large file == at least 2 x main memory. Okay, but what about small files? The particular files where I have performance problems are each about 1/5 or less the size of main memory (108000000 and 72000000 bytes each) on this system, comparable to the sizes on the other well-running system with less memory (400+MB) you quoted below... > -- original response -- > Ok, lets concentrate on your hishave, artclean, artctrl, and overview > numbers. Hey! HEY!@! I'm not ready to do a complete tuning yet! ;-) > :-rw-rw-r-- 1 news news 436206889 Dec 3 05:22 history > :-rw-rw-r-- 1 news news 67 Dec 3 05:22 history.dir > :-rw-rw-r-- 1 news news 81000000 Dec 1 01:55 history.hash > :-rw-rw-r-- 1 news news 54000000 Nov 30 22:49 history.index > : > :More observations that may or may not mean anything -- before rebooting, > :I timed the `fsync' commands on the 108MB and 72MB history files, as > > note: the fsync command will not flush MAP_NOSYNC pages. Ummm... Uh... Really? It seems that it did... For after I gave the userland `fsync' command on these files just before rebooting, I did not see the lengthy disk activity I've normally associated with using NOSYNC at times of reboot. Normally I'll see three or four minutes of disk grinding following the `syncing disks -- done' messages, but this time, the history drive light flashed for a fraction of a second before continuing with the reboot. Also, the timestamps on the files got updated, just as they do after shutdown at reboot time... > :The time taken to do the `fsync' was around one minute for the two > :history files. And around 1 second for the BerkeleyDB file... > > This is an indication of file fragmentation, probably due to holes > in the history file being filled via the mmap() instead of filled via > write(). But... If the message I quoted is accurate (I don't trust myself to look at the source), or if I initialize the history database files with `cp' prior to starting and no expire or any process that would extend the files has run, wouldn't the time needed to `fsync' the files indicate that the in-memory data to be dumped isn't well-sorted before being written to disk? The data is accessed and updated randomly in the INN history mechanism... > :are a bit, well, wrong. The way I see it, by giving the MAP_NOSYNC > :flag, I'm sort of asking for preferential treatment, kinda like mlock, > > The pages are treated the way any VM page is treated... they'll > be cached based on use. I don't think this is the problem. I think it is a problem -- at least, it's enough of a performance hit that I'm willing to sacrifice a couple hundred megs of RAM to avoid hitting the disk -- our NetBSD machines, in spite of the bug, achieve stellar performance levels by leaving the history files alone for days. The problem is that the pages are accessed randomly, so that prior use is no indication of future use. Also, what seems to be happening is that a random selection of pages are being updated on-disk now, which takes, oh, looks like four or five seconds every so often. During this update time (which MAP_NOSYNC helps to avoid, sometimes), all other history access blocks, including that I'm doing as a reader. Then grabbing a random page that needs to be consulted but isn't still in memory gets expensive. Eeep, that last slowdown took 8 seconds... It's true that I haven't rebuilt things without MAP_NOSYNC to see how much time is spent on periodic sync activity, but what I'm seeing now, even with a gig of RAM and an ever-increasing list of null-routed networks to keep abusers away, is starting to resemble that level of poor performance. > Ok, lets look at a summary of your timing results: > > hishave overv artclean artctrl > 38857(26474) 112176(6077) 12264(6930) 2297(308) > 22114(28196) 136855(6402) 12757(7295) 1257(322) > 13614(24312) 156723(6071) 13232(6800) 324(244) > 9944(25198) 164223(6620) 13441(7753) 255(160) > 2777(50732) 24979(3788) 29821(4017) 131(51) > 31975(11904) 21593(3320) 25148(3567) 5935(340) > > Specifically, look at the last one where it blew up on you. hishave > and artctrl are much worse, overview and artclean are about the same. Artctrl, at six seconds out of five minutes, isn't of too much concern to me now. This would be (almost exclusively) cancel messages -- I haven't looked to see just how the CNFS cyclical buffer multiple-articles- in-one-large-file method of storage handles cancels... Certainly not by unlinking an inode as with the old news spool we all grew up to know and loathe. Artclean is an addition I've made that wasn't present in Joe Greco's timer (I don't remember if you had much experience with this, or if you were busy writing Diablo at this time, so if I'm explaining something that's obvious, just assume it's for the benefit of the audience who may appreciate a bit of background). It's an in-memory operation that one of the developers recently realized is pretty expensive, and it is dependant on the size of the article being processed. The top timings are about twice the normal average rate of ten articles/second (though I have seen well in excess of 35/sec sustained for a one hour period, arrrg) and are that way as I'm bringing in backlogs. For whatever reason, a backlogged feed gives priority to taking in smaller articles first, and as a result, even though more articles are processed, the time taken overall is less than when handling a smaller number of articles with an order of magnitude more volume. But this explanation is all pretty irrelevant to the immediate discussion... Anyway... > This is an indication of excessive seeking on the history disk. I > believe that this seeking may be due to file fragmentation. To me, sitting on the floor in front of the machine, it looks like it indicates there is activity on the history disk. The ideal situation (from my experience with both NetBSD and the transit machines) is that the history drive light stays off. Which it does, mostly, during the Good Timings after the bulk of the text data is read from the disk. The problem is, right now, rather than remaining idle and letting the other disks take a pounding, I'm seeing non-stop flickering of the history drive, which I don't see on the transit machines, and during the 5 to 10 seconds worth of blocked history lookups, the light is constantly lit as it seeks, which, since I've done a `cp' on the two files, I believe is a result of the randomness of the pages being written. > There is an easy way to test file fragmentation. Kill off everything > and do a 'dd if=history of=/dev/null bs=32k'. Do the same for > history.hash and history.index. Look at the iostat on the history > drive. Specifically, do an 'iostat 1' and look at the KB/t (kilobytes > per transfer). You should see 32-64KB/t. If you see 8K/t the file > is severely fragmented. Go through the entire history file(s) w/ dd... > the fragmentation may occur near the end. Okay, I'm doing this: The two hash-type files give me between 9 and 10K/t; the history text file gives me more like 60KB/t. Hmmm. It's not the best drive in the world, I know that, but I had set up a NetBSD transit machine with five-year-old drives and saw average history lookup times of less than 10 microseconds each, just because it wasn't hitting the disk much. On an old PPro 200. > If the file turns out to be fragmented, the only way to fix it is to > fix the code that extends the file. Instead of ftruncate()ing the file > and then appending to it via the mmap(), you should modify the > ftruncate() code to fill in the hole with write()'s before returning, > so the modifications via mmap() are modifying pages that already have > file-backing store rather then filling in holes. > > Then rewrite the history file (e.g. 'cp'), and restart innd. But... But... But... but... but but but but... but butbutbut*BANG*but but... (Sorry, running a bit low on fuel) The thing is, before I started this particular instance of INN, I had just made a copy of the two hash files, the ones that give the less-than-ideal throughput as shown. I didn't bother with the text file, as it's never even consulted in the recent history k0deZ (unless one uses what's now called `tagged hash' that uses the text file as a reference after hashes are looked up in the .pag file), and I've been sure that hasn't been a problem -- all accesses there are sequential. What I did note as interesting was that Diablo's k0deZ use the madvise MADV_WILLNEED which seems reasonable, but unlike the random access of INN's hash files, it hints at SEQUENTIAL access. Now, I'll be the first to confess to not having looked at your history k0deZ that you wrote for Diablo and just how it does work, but whatever is happening when handling the INN random history is definitely not very optimal. Now, there appear to be several things conspiring against me. It looks like the MAP_NOSYNC option to mmap is best suited for mmap'ed file-based IPC, where the contents of what's on the disk is less critical. When I use it with a history file, I run the risk of a crash (read: I get my leg wrapped in the power cord as I thrash about in my sleep) where most of the updates to the .index and .hash files go to the Big Blue Bitbucket to join most of my work over the last years. This isn't fatal, as the two files can be recreated from the text file when one is aware of a crash. I can live with it, as, at the moment, it seems to be the only way to get decent history performance without a significant hardware investment or accepting the will of my boss and using a different OS. Now, about madvise: I'm not quite sure how specifying `MADV_RANDOM' changes the behaviour and if it would have any affect on the flushing of the data to the disk when needed -- it appears to my addled brane that with a truly random set of data like the .index/.hash files, you can't attempt to predict what pages will be best to flush due to inactivity, since any random page should be equally likely to be accessed as any other. If anything, you'd want to write out sequential pages for speed. Now, if that's what is happening, then somehow things look to be getting messed up from the time I made the `cp' some hours ago that should have created virginally pure unfragmented database files... I had suggested that `MAP_NOSYNC' be a hint that the pages should get preferential treatment to be locked in memory. Maybe overkill for your typical IPC file, but perhaps the combination of MAP/MADV_NOSYNC and MADV_RANDOM should be a hint to prioritize these pages. Okay, now to MADV_WILLNEED -- I hoped that would be the needed kick to effectively give me the `mlock'-like performance, but even with a full gig of memory and a dozen relatively-behaved readers, there's still way too much history disk activity that really drags down overall performance. Okay, so maybe the combination of MAP/MADV_NOSYNC and MADV_WILLNEED should be the hint needed to avoid paging out those pages, even if they haven't been accessed in quite some time. Especially if it's in combination with MADV_RANDOM... The numbers you've seen aren't very impressive -- I'm quite sure that I was able to keep up easily with NetBSD, although the corruption that resulted there caused me to abandon ship quickly. As it is, I can't keep up with the overnight binaries peak in a full feed, as the history times are taking up two minutes out of every five now. Bleeecccchhh. The actual history lookups and updates that matter are all done within the memory taken up by the .index and .hash files. So, by keeping them in memory, one doesn't need to do any disk activity at all for lookups, and updates, well, so long as you commit them to the disk at shutdown, all should be okay. That's what I'm attempting to achieve. These lookups and updates are bleedin' expensive when disk activity rears its ugly head. Not to worry, I'm going to keep plugging to see if there is a way for me to lock these two files into memory so that they *stay* there, just to prove whether or not that's a significant performance improvement. I may have to break something, but hey... (sheesh, two minutes... :~-) thanks, barry bouwsma, obstinate stubborn newsbast'rd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 1:39:44 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 01:39:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 5F50537B401 for ; Tue, 5 Dec 2000 01:39:06 -0800 (PST) Received: from timbuktu-59.budapest.interware.hu ([195.70.51.251] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 143EYx-0006qp-00; Tue, 05 Dec 2000 10:39:04 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A2C1917.AFF94A06@elischer.org> Date: Mon, 04 Dec 2000 14:22:15 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: oscar@163.net Cc: freebsd-hackers@freebsd.org Subject: Re: get tun0's ip from my program References: <3A2B8A42.09234@bjapp6.163.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oscar@163.net wrote: > > I want to get tun0's two ip addresses. > and add ipfw rules to system at my program. > How can I do it?is there a function? or > have document describe it. someone please tell me! ifconfig tun0 | awk {small awk program} of course WHY do you want to do this? that may help more.. . > thank you! > > oscar > oscar@163.net > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ¡°200¼ÒÁ¬ËøÍøÕ¾£¬ÈÃÑÛ¾¦³¢³¢ÏÊ¡± > http://www.chinese.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 163µç×ÓÓʾ֣¬¸øÄú¸üÍêÃÀEmail·þÎñ£¡ > http://www.163.net > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 1:57:48 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 01:57:45 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 350F837B404 for ; Tue, 5 Dec 2000 01:57:44 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA23062; Tue, 5 Dec 2000 10:57:18 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Yusuf Goolamabbas Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] References: <20001205133817.A24228@outblaze.com> From: Dag-Erling Smorgrav Date: 05 Dec 2000 10:57:18 +0100 In-Reply-To: Yusuf Goolamabbas's message of "Tue, 5 Dec 2000 13:38:18 +0800" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yusuf Goolamabbas writes: > Recently there was a message indicating that ISC is deprecating > nslookup. "Recently"? nslookup has been officially deprecated for about a year and a half, I believe. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 4:15:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 04:15:35 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id CDAF837B400 for ; Tue, 5 Dec 2000 04:15:34 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JXCHGGUGCQ0016BN@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Tue, 5 Dec 2000 13:15:32 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 05 Dec 2000 13:15:32 +0100 Content-return: allowed Date: Tue, 05 Dec 2000 13:15:21 +0100 From: "Koster, K.J." Subject: RE: nslookup deprecation [was 4.2 complaint] To: 'Dag-Erling Smorgrav' Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7A85@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Recently there was a message indicating that ISC is deprecating > > nslookup. > > "Recently"? nslookup has been officially deprecated for about a year > and a half, I believe. > Public Enemy said it before: don't believe the hype. In this case, the hype that an Internet year is only a few weeks of wallclock time. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 4:37:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 04:37:28 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by hub.freebsd.org (Postfix) with ESMTP id 81C8A37B401 for ; Tue, 5 Dec 2000 04:37:28 -0800 (PST) Received: from snail.stack.nl (snail.ipv6.stack.nl [2001:610:1108:5010:4a54:e8ff:fe29:b98c]) by mailhost.stack.nl (Postfix) with ESMTP id 2963F159C6 for ; Tue, 5 Dec 2000 13:37:27 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1598) id 37496D3D; Tue, 5 Dec 2000 13:37:26 +0100 (CET) To: freebsd-hackers@freebsd.org Subject: pccard driver docs Message-Id: <20001205123726.37496D3D@snail.stack.nl> Date: Tue, 5 Dec 2000 13:37:26 +0100 (CET) From: wvengen@stack.nl (Willem van Engen) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm writing a pcmcia device driver for the PhyDAS system used in our university for measurements. I have been searching the internet for information on programming a driver on the pccard bus, but I haven't found any good overview of a pcmcia driver (well, the 'FreeBSD device driver writer's guide' on http://people.freebsd.org/~erich/ddwg/ddwg.html seems useful, but currently it's mostly empty). If you know useful information about programming drivers on the pccard bus, please share it with me. Thanks in advance. Willem van Engen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 4:38:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 04:38:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0AA4F37B400 for ; Tue, 5 Dec 2000 04:38:09 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA24185; Tue, 5 Dec 2000 13:38:01 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Koster, K.J." Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] References: <59063B5B4D98D311BC0D0001FA7E4522026D7A85@l04.research.kpn.com> From: Dag-Erling Smorgrav Date: 05 Dec 2000 13:38:01 +0100 In-Reply-To: "Koster, K.J."'s message of "Tue, 05 Dec 2000 13:15:21 +0100" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Koster, K.J." writes: > > > Recently there was a message indicating that ISC is deprecating > > > nslookup. > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > Public Enemy said it before: don't believe the hype. In this case, the hype > that an Internet year is only a few weeks of wallclock time. I'm sure there must be some meaning to what you write, but it keeps eluding me. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 4:51:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 04:51:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id B205E37B400 for ; Tue, 5 Dec 2000 04:51:09 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JXCIPK8EBQ00133N@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Tue, 5 Dec 2000 13:51:07 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 05 Dec 2000 13:51:06 +0100 Content-return: allowed Date: Tue, 05 Dec 2000 13:51:05 +0100 From: "Koster, K.J." Subject: RE: nslookup deprecation [was 4.2 complaint] To: 'Dag-Erling Smorgrav' Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7A86@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Public Enemy said it before: don't believe the hype. In > > this case, the hype that an Internet year is only a few weeks of > > wallclock time. > > I'm sure there must be some meaning to what you write, but it keeps > eluding me. > I don't think that a year and a half is a long time for nslookup to be marked as deprecated but still being in wide use. I know that the current fad is to think that the Internet is a fastpaced environment. For some it may be, for nslookup it is not. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 6:52:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 06:52:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id 201FE37B400 for ; Tue, 5 Dec 2000 06:52:32 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JXCMY2M8SS00132H@research.kpn.com> for freebsd-hackers@freebsd.org; Tue, 5 Dec 2000 15:52:30 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 05 Dec 2000 15:52:30 +0100 Content-return: allowed Date: Tue, 05 Dec 2000 15:52:20 +0100 From: "Koster, K.J." Subject: Re: yet another unsupported PHY in fxp driver To: 'FreeBSD Hackers mailing list' Cc: "Metz, E.T." Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7A88@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear All, I found this thread, but no real resolution, so pardon me for dragging this back up. Relevant dmesg output: fxp0: Ethernet address 00:08:c7:7b:05:bd bpf: fxp0 attached fxp1: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps bpf: fxp1 attached fxp2: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps bpf: fxp2 attached fxp3: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps Say what? I lived under the impression that MAC addresses were unique. Here I have three cards that have identical MAC adresses. Finally, we finish off with: bpf: fxp0.0 attached fxp1: warning: unsupported PHY, type = 0, addr = 0 bpf: fxp1.0 attached fxp2: warning: unsupported PHY, type = 0, addr = 0 bpf: fxp2.0 attached fxp3: warning: unsupported PHY, type = 0, addr = 0 bpf: fxp3.0 attached fxp3: link media DOWN 10Mb / half-duplex fxp2: link media DOWN 10Mb / half-duplex fxp0: link media DOWN 10Mb / half-duplex fxp1: link media DOWN 10Mb / half-duplex The dmesg is from FreeBSD 2.2.8 (boot -v) by the way, but booting 4.1 yields the same results. Now (finally) my question: how do we get this particular PHY supported? This seems to have remained unanswered back in October. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 6:58:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 06:58:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (r1.bfm.org [216.127.220.97]) by hub.freebsd.org (Postfix) with ESMTP id 8AF8F37B400 for ; Tue, 5 Dec 2000 06:58:42 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id IAA00249; Tue, 5 Dec 2000 08:57:17 -0600 (CST) (envelope-from adam) Date: Tue, 5 Dec 2000 08:56:45 -0600 From: "G. Adam Stanislav" To: Stephen McKay Cc: hackers@FreeBSD.ORG Subject: Re: pipe Message-ID: <20001205085645.A228@whizkidtech.net> References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200012040256.eB42upH07905@dungeon.home>; from mckay@thehub.com.au on Mon, Dec 04, 2000 at 12:56:51PM +1000 Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 04, 2000 at 12:56:51PM +1000, Stephen McKay wrote: >Using pipes for temporary storage is still a crazy idea. Pipes can be >smaller than 8K, depending on the flavour of Unix. It was just a thought, and it did not work. :) Other flavors of Unix are not too important in this case: I'm writing a FreeBSD assembly language tutorial. Though I do discuss portability issues in it. I'm writing the tutorial, not because I'm the expert (I am, on assembly language, but not on Unix system calls--yet), but because, in my experience, it is the best way to learn. > Use malloc() instead. Unfortunately, that only works in C. :) I tried to figure out how to allocate memory, but, so far, was completely unsuccessful. I studied the source for the C malloc, but did not understand any of it. It uses something called mmap. I read the man page for mmap, and was totally frustrated. It talks about mapping files into memory, but I am not looking for files. It talks about passing an address to the function. I don't get it... What address? I want it to allocate memory for me and tell me its address. How am I supposed to know what address is available??? Thanks, Adam -- When two do the same, it's not the same -- Slovak proverb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 7: 0:38 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 07:00:36 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 650F037B400 for ; Tue, 5 Dec 2000 07:00:35 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id GAA23226; Tue, 5 Dec 2000 06:58:07 -0800 (PST) Message-Id: <200012051458.GAA23226@implode.root.com> To: "Koster, K.J." Cc: "'FreeBSD Hackers mailing list'" , "Metz, E.T." Subject: Re: yet another unsupported PHY in fxp driver In-reply-to: Your message of "Tue, 05 Dec 2000 15:52:20 +0100." <59063B5B4D98D311BC0D0001FA7E4522026D7A88@l04.research.kpn.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 05 Dec 2000 06:58:07 -0800 Sender: dg@implode.root.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Say what? I lived under the impression that MAC addresses were unique. Here >I have three cards that have identical MAC adresses. > >Finally, we finish off with: > >bpf: fxp0.0 attached >fxp1: warning: unsupported PHY, type = 0, addr = 0 >bpf: fxp1.0 attached >fxp2: warning: unsupported PHY, type = 0, addr = 0 >bpf: fxp2.0 attached >fxp3: warning: unsupported PHY, type = 0, addr = 0 >bpf: fxp3.0 attached >fxp3: link media DOWN 10Mb / half-duplex >fxp2: link media DOWN 10Mb / half-duplex >fxp0: link media DOWN 10Mb / half-duplex >fxp1: link media DOWN 10Mb / half-duplex > >The dmesg is from FreeBSD 2.2.8 (boot -v) by the way, but booting 4.1 yields >the same results. > >Now (finally) my question: how do we get this particular PHY supported? This >seems to have remained unanswered back in October. All of the above is caused by the SEEPROM not being read properly. Since it doesn't work with 4.1, this probably indicates that you're using an on-motherboard NIC (Supermicro?). I'm running out the door to the airport, however, and won't be able to get a fix to you until next week. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 7: 8:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 07:08:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by hub.freebsd.org (Postfix) with ESMTP id DA17A37B400 for ; Tue, 5 Dec 2000 07:08:14 -0800 (PST) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JXCNHJVR76000VH0@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Tue, 5 Dec 2000 16:08:12 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 05 Dec 2000 16:08:12 +0100 Content-return: allowed Date: Tue, 05 Dec 2000 16:08:01 +0100 From: "Koster, K.J." Subject: RE: yet another unsupported PHY in fxp driver To: "'dg@root.com'" , "Koster, K.J." Cc: 'FreeBSD Hackers mailing list' , "Metz, E.T." Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7A89@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear David, > > All of the above is caused by the SEEPROM not being read > properly. Since it doesn't work with 4.1, this probably indicates that > you're using an on-motherboard NIC (Supermicro?). > These are not on-board NICs, but PCI cards. (Do you know of a motherboard that comes with four on-board NICs?) > > I'm running out the door to the airport, however, and won't be able to > get a fix to you until next week. > Sorry to hear that you're in a hurry. I was secretly hoping that you'd have time. :-) Anything we can do in the mean time? Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 7:32:36 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 07:32:34 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BF93F37B400 for ; Tue, 5 Dec 2000 07:32:33 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA24845; Tue, 5 Dec 2000 16:32:30 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "G. Adam Stanislav" Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> From: Dag-Erling Smorgrav Date: 05 Dec 2000 16:32:29 +0100 In-Reply-To: "G. Adam Stanislav"'s message of "Tue, 5 Dec 2000 08:56:45 -0600" Message-ID: Lines: 24 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" writes: > > Use malloc() instead. > Unfortunately, that only works in C. :) Use mmap() or brk()/sbrk(). > I tried to figure out how to allocate memory, but, so far, was completely > unsuccessful. I studied the source for the C malloc, but did not understand > any of it. It uses something called mmap. I read the man page for mmap, > and was totally frustrated. It talks about mapping files into memory, > but I am not looking for files. Look for MAP_ANON in the mmap(2) man page. > It talks about passing an address to the > function. I don't get it... What address? I want it to allocate memory > for me and tell me its address. How am I supposed to know what address > is available??? Did you even read the man page? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 7:43:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 07:43:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from kai.qix.co.uk (kai.qix.co.uk [195.149.39.121]) by hub.freebsd.org (Postfix) with ESMTP id B459C37B400 for ; Tue, 5 Dec 2000 07:43:29 -0800 (PST) Received: from localhost (aledm@localhost) by kai.qix.co.uk (8.9.3/8.9.3) with ESMTP id PAA01022; Tue, 5 Dec 2000 15:43:10 GMT (envelope-from aledm@qix.co.uk) Date: Tue, 5 Dec 2000 15:43:10 +0000 (GMT) From: Aled Morris To: "G. Adam Stanislav" Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe In-Reply-To: <20001205085645.A228@whizkidtech.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, 5 Dec 2000, G. Adam Stanislav wrote: >> Use malloc() instead. > >Unfortunately, that only works in C. :) > >I tried to figure out how to allocate memory, but, so far, was completely >unsuccessful. malloc appears to mmap pages from fd -1, and makes them private and read/write (except on sparc architecture, where it uses /dev/zero rather than -1, which makes more sense to me) It isn't particularly complicated: newmem = mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); Aled To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 7:45:50 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 07:45:46 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5710237B400 for ; Tue, 5 Dec 2000 07:45:44 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 143KI2-0000OM-00; Tue, 05 Dec 2000 08:45:58 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A2D0DB6.F67E2DE@softweyr.com> Date: Tue, 05 Dec 2000 08:45:58 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: oscar@163.net, freebsd-hackers@freebsd.org Subject: Re: get tun0's ip from my program References: <3A2B8A42.09234@bjapp6.163.net> <3A2C1917.AFF94A06@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > oscar@163.net wrote: > > > > I want to get tun0's two ip addresses. > > and add ipfw rules to system at my program. > > How can I do it?is there a function? or > > have document describe it. someone please tell me! > ifconfig tun0 | awk {small awk program} > > of course WHY do you want to do this? > > that may help more.. It's easier to record your addresses in some convenient form, then use that information to both set the addresses for the interface via ifconfig, and to "program" the firewall (and nat, if used). We store ours in a pair of shell scripts, which look like: /etc/extern.config: # DoBox network configuration created Tue Dec 5 08:33:49 MST 2000 extern_interface=rl0 extern_port=rl0 extern_ipaddress=0.0.0.0 extern_netmask=0.0.0.0 extern_cidr=0 extern_broadcast=0.0.0.0 extern_network=0.0.0.0 extern_configured=no /etc/intern.config: # DoBox network configuration created Tue Dec 5 08:33:49 MST 2000 intern_interface=dc0 intern_ipaddress=172.31.0.1 intern_netmask=255.255.252.0 intern_cidr=22 intern_broadcast=172.31.3.255 intern_network=172.31.0.0 intern_netpart=172.31.0 intern_domain=my.dobox These files can be sourced by scripts that (re-)create the ipfilter and ipnat rules (in our case), run ifconfig, etc. The extern config can be modified by dhclient exit hook scripts, ppp "up" configuration scripts, or by the web interface. The internal configuration can be changed some- what from the web interface, or by registering a real domain name. The internal and external interface names are decided automagically during the "first birthday" boot, by a script with intimate knowledge of what interfaces actually occur in various types of DoBox hardware. Most of the configuration files that need to be edited with this information we have renamed to file.in. We have a script, configure.net, that sources the above files and then edits each of the .in files to the actual file and restarts whatever is needed to bring the system up to date with the new configuration. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 8:43:22 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 08:43:19 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A47A37B400 for ; Tue, 5 Dec 2000 08:43:18 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB5GhH597618; Tue, 5 Dec 2000 09:43:17 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA70919; Tue, 5 Dec 2000 09:43:17 -0700 (MST) Message-Id: <200012051643.JAA70919@harmony.village.org> To: wvengen@stack.nl (Willem van Engen) Subject: Re: pccard driver docs Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Dec 2000 13:37:26 +0100." <20001205123726.37496D3D@snail.stack.nl> References: <20001205123726.37496D3D@snail.stack.nl> Date: Tue, 05 Dec 2000 09:43:17 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001205123726.37496D3D@snail.stack.nl> Willem van Engen writes: : I'm writing a pcmcia device driver for the PhyDAS system used in our university : for measurements. I have been searching the internet for information on : programming a driver on the pccard bus, but I haven't found any good overview : of a pcmcia driver (well, the 'FreeBSD device driver writer's guide' on : http://people.freebsd.org/~erich/ddwg/ddwg.html seems useful, but currently : it's mostly empty). : If you know useful information about programming drivers on the pccard bus, : please share it with me. I know. Usually I just follow if_ed or if_ep as an example. For the most part things are done for you so there's very little pccard specific code. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 8:48:49 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 08:48:47 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from po3.glue.umd.edu (po3.glue.umd.edu [128.8.10.123]) by hub.freebsd.org (Postfix) with ESMTP id 3AE6037B400 for ; Tue, 5 Dec 2000 08:48:42 -0800 (PST) Received: from glue.umd.edu (poseidon.student.umd.edu [129.2.144.21]) by po3.glue.umd.edu (8.10.1/8.10.1) with ESMTP id eB5GmPL21055; Tue, 5 Dec 2000 11:48:26 -0500 (EST) Message-ID: <3A2D1C5A.3234E4C5@glue.umd.edu> Date: Tue, 05 Dec 2000 11:48:26 -0500 From: Brandon Fosdick X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Yusuf Goolamabbas , freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] References: <20001205133817.A24228@outblaze.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Yusuf Goolamabbas writes: > > Recently there was a message indicating that ISC is deprecating > > nslookup. > > "Recently"? nslookup has been officially deprecated for about a year > and a half, I believe. Will a replacement be added to the base distro? When? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 8:51: 1 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 08:50:58 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mmap.nyct.net (mmap.nyct.net [216.44.109.243]) by hub.freebsd.org (Postfix) with ESMTP id 7275037B400 for ; Tue, 5 Dec 2000 08:50:58 -0800 (PST) Received: by mmap.nyct.net (Postfix, from userid 1000) id B6B6BFAB2; Tue, 5 Dec 2000 11:49:40 -0500 (EST) Date: Tue, 5 Dec 2000 11:49:40 -0500 To: Brandon Fosdick Cc: Dag-Erling Smorgrav , Yusuf Goolamabbas , freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] Message-ID: <20001205114940.A27123@mmap.nyct.net> References: <20001205133817.A24228@outblaze.com> <3A2D1C5A.3234E4C5@glue.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A2D1C5A.3234E4C5@glue.umd.edu>; from bfoz@glue.umd.edu on Tue, Dec 05, 2000 at 11:48:26AM -0500 From: mbac@mmap.nyct.net (Michael Bacarella) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 05, 2000 at 11:48:26AM -0500, Brandon Fosdick wrote: > > > Recently there was a message indicating that ISC is deprecating > > > nslookup. > > > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > > Will a replacement be added to the base distro? When? If you play with BIND v9, 'nslookup' itself tells you that it's deprecated and that 'host' should be used instead. I'm not a fan either. -- Michael Bacarella ;finger address for public key GPG Key Fingerprint: B4E4 82F5 BCAC AB83 E6F7 B5AA 933E 2A75 79A4 A9C1 Technical Staff / New York Connect Net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 9: 0:33 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 09:00:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DE95B37B400 for ; Tue, 5 Dec 2000 09:00:30 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA25166; Tue, 5 Dec 2000 18:00:23 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Brandon Fosdick Cc: Yusuf Goolamabbas , freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] References: <20001205133817.A24228@outblaze.com> <3A2D1C5A.3234E4C5@glue.umd.edu> From: Dag-Erling Smorgrav Date: 05 Dec 2000 18:00:22 +0100 In-Reply-To: Brandon Fosdick's message of "Tue, 05 Dec 2000 11:48:26 -0500" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brandon Fosdick writes: > Dag-Erling Smorgrav wrote: > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > Will a replacement be added to the base distro? When? 1) nslookup is still in the base FreeBSD distribution, and will probably be for a long time. 2) use dig(1), which is a lot more useful (and less magical). DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 9: 5:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 09:05:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (rh7.bfm.org [216.127.220.200]) by hub.freebsd.org (Postfix) with ESMTP id 8297C37B400 for ; Tue, 5 Dec 2000 09:05:29 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id LAA00252; Tue, 5 Dec 2000 11:03:59 -0600 (CST) (envelope-from adam) Date: Tue, 5 Dec 2000 11:03:28 -0600 From: "G. Adam Stanislav" To: Dag-Erling Smorgrav Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe Message-ID: <20001205110328.A228@whizkidtech.net> References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from des@ofug.org on Tue, Dec 05, 2000 at 04:32:29PM +0100 Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 05, 2000 at 04:32:29PM +0100, Dag-Erling Smorgrav wrote: >Did you even read the man page? Many times, actually. And on different days, too. :) I guess I just don't understand what is meant by "map" in this context. My Unix programming "bible" (POSIX Programmer's Guide) does not even mention it. I still consider myself a Unix newbie--some of its concepts are very hard to grasp. I could use a good introductory text, but our local college library has very little on Unix (this is a small town in the middle of nowhere). I spent many years programming for MS DOS and Windows. Unix is a whole new ball game to me. So, please, bear with me. Adam -- Cogitans me cogito esse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 9: 9:22 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 09:09:20 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (rh7.bfm.org [216.127.220.200]) by hub.freebsd.org (Postfix) with ESMTP id 3258137B400 for ; Tue, 5 Dec 2000 09:09:18 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id LAA00260; Tue, 5 Dec 2000 11:07:44 -0600 (CST) (envelope-from adam) Date: Tue, 5 Dec 2000 11:07:43 -0600 From: "G. Adam Stanislav" To: Aled Morris Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe Message-ID: <20001205110743.B228@whizkidtech.net> References: <20001205085645.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from aledm@qix.co.uk on Tue, Dec 05, 2000 at 03:43:10PM +0000 Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 05, 2000 at 03:43:10PM +0000, Aled Morris wrote: >malloc appears to mmap pages from fd -1, and makes them private and >read/write (except on sparc architecture, where it uses /dev/zero rather >than -1, which makes more sense to me) > >It isn't particularly complicated: > >newmem = mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); Thanks, Aled. I'll play with it. Will try both -1 and /dev/zero. Cheers, Adam -- Suppose you were an idiot. Suppose you were a member of Congress. But I'm repeating myself... -- Mark Twain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 9:11:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 09:11:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CBB6137B400 for ; Tue, 5 Dec 2000 09:11:14 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA25236; Tue, 5 Dec 2000 18:11:06 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "G. Adam Stanislav" Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> From: Dag-Erling Smorgrav Date: 05 Dec 2000 18:11:06 +0100 In-Reply-To: "G. Adam Stanislav"'s message of "Tue, 5 Dec 2000 11:03:28 -0600" Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" writes: > On Tue, Dec 05, 2000 at 04:32:29PM +0100, Dag-Erling Smorgrav wrote: > > Did you even read the man page? > Many times, actually. And on different days, too. :) No, you didn't. You probably read the first line, then your eyes glazed over and you skipped to the bottom. The second and third sentences of the second paragraph (the one that starts on line 23), as well as the entire eighth paragraph (that starts on line 45), address the questions you asked in your previous mail. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 10:16:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 10:16:35 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (r3.bfm.org [216.127.220.99]) by hub.freebsd.org (Postfix) with ESMTP id F045B37B401 for ; Tue, 5 Dec 2000 10:16:33 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id MAA00248; Tue, 5 Dec 2000 12:14:54 -0600 (CST) (envelope-from adam) Date: Tue, 5 Dec 2000 12:14:23 -0600 From: "G. Adam Stanislav" To: Dag-Erling Smorgrav Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe Message-ID: <20001205121423.A228@whizkidtech.net> References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from des@ofug.org on Tue, Dec 05, 2000 at 06:11:06PM +0100 Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: >No, you didn't. You probably read the first line, then your eyes >glazed over and you skipped to the bottom. Believe what you want. >The second and third sentences of the second paragraph (the one that >starts on line 23), as well as the entire eighth paragraph (that >starts on line 45), address the questions you asked in your previous >mail. I know it addresses it. Unfortunately, I didn't understand a word of it. Perhaps I'm not as brilliant as you. Or, perhaps too old (yeah, they did not teach me Unix when I went to school in the sixties, because Unix did not exist yet). But please don't tell me that I did not read it, when I did over and over, and it all sounded Greek to me. I am starting to understand some of it after reading messages from people who were willing to help instead of throwing out accusations. It is still not clear, but I think I have gotten enough advice to do further experimenting with it. BTW, as for the suggestion to use brk: All I get from it is an error. I noticed that even the C function of the same name does not use the brk system call. Adam -- Apply standard disk lamer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 10:55:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 10:55:44 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3A3A537B400 for ; Tue, 5 Dec 2000 10:55:42 -0800 (PST) Received: from casablanca-41.budapest.interware.hu ([195.70.53.41] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 143NFb-0005Kj-00; Tue, 05 Dec 2000 19:55:40 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A2D3A15.BF3357B4@elischer.org> Date: Tue, 05 Dec 2000 10:55:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Warner Losh Cc: Willem van Engen , freebsd-hackers@FreeBSD.ORG Subject: Re: pccard driver docs References: <20001205123726.37496D3D@snail.stack.nl> <200012051643.JAA70919@harmony.village.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <20001205123726.37496D3D@snail.stack.nl> Willem van Engen writes: > : I'm writing a pcmcia device driver for the PhyDAS system used in our university > : for measurements. I have been searching the internet for information on > : programming a driver on the pccard bus, but I haven't found any good overview > : of a pcmcia driver (well, the 'FreeBSD device driver writer's guide' on > : http://people.freebsd.org/~erich/ddwg/ddwg.html seems useful, but currently > : it's mostly empty). > : If you know useful information about programming drivers on the pccard bus, > : please share it with me. > > I know. Usually I just follow if_ed or if_ep as an example. For the > most part things are done for you so there's very little pccard Of course of someone who knew about pccard would add the appropriate code to the example driver...... > specific code. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 10:57:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 10:57:12 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.integratus.com (unknown [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id A24EB37B400 for ; Tue, 5 Dec 2000 10:57:12 -0800 (PST) Received: (qmail 23304 invoked from network); 5 Dec 2000 18:57:06 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 5 Dec 2000 18:57:06 -0000 Sender: jar@FreeBSD.ORG Message-ID: <3A2D3A82.2F5FC6B@integratus.com> Date: Tue, 05 Dec 2000 10:57:06 -0800 From: Jack Rusher Organization: http://www.integratus.com/ X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "G. Adam Stanislav" Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> <20001205121423.A228@whizkidtech.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" wrote: > > On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: > >No, you didn't. You probably read the first line, then your eyes > >glazed over and you skipped to the bottom. Dudes. This is a programmer from another environment coming to us to learn more about our programming paradigm. Don't blast him for not picking it up fast enough. Give the guy some help. Geez. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 11: 1:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 11:01:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1614437B699 for ; Tue, 5 Dec 2000 11:01:06 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB5J14598301; Tue, 5 Dec 2000 12:01:05 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA72035; Tue, 5 Dec 2000 12:01:04 -0700 (MST) Message-Id: <200012051901.MAA72035@harmony.village.org> To: Julian Elischer Subject: Re: pccard driver docs Cc: Willem van Engen , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Dec 2000 10:55:17 PST." <3A2D3A15.BF3357B4@elischer.org> References: <3A2D3A15.BF3357B4@elischer.org> <20001205123726.37496D3D@snail.stack.nl> <200012051643.JAA70919@harmony.village.org> Date: Tue, 05 Dec 2000 12:01:04 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A2D3A15.BF3357B4@elischer.org> Julian Elischer writes: : Of course of someone who knew about pccard would add the appropriate code to the : example driver...... That would make things too easy :-) Seriously, however, in 4.x and earlier it would be no different. In 5.x there's a new requirement for self identification that is used by NEWCARD, but not by OLDCARD. As soon as that settles down, I'll put it into the sample driver. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 11:13:29 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 11:13:27 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id C49A337B401 for ; Tue, 5 Dec 2000 11:13:26 -0800 (PST) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with ESMTP id OAA18748; Tue, 5 Dec 2000 14:12:07 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20001205141310.02cda850@mail.etinc.com> X-Sender: dennis@mail.etinc.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 05 Dec 2000 14:15:07 -0500 To: "Koster, K.J." , "'dg@root.com'" , "Koster, K.J." From: Dennis Subject: RE: yet another unsupported PHY in fxp driver Cc: "'FreeBSD Hackers mailing list'" , "Metz, E.T." In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522026D7A89@l04.research.kpn. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:08 AM 12/05/2000, Koster, K.J. wrote: >Dear David, > > > > > All of the above is caused by the SEEPROM not being read > > properly. Since it doesn't work with 4.1, this probably indicates that > > you're using an on-motherboard NIC (Supermicro?). > > >These are not on-board NICs, but PCI cards. (Do you know of a motherboard >that comes with four on-board NICs?) it seems that these are the "rev 8" parts...supermicro must have gotten an early shipment as they were the first to have them, but these are likely to be showing up everywhere soon. What can you do? anyone with access to intel docs might leak a hint as to what changed or is new in this rev part. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 12:15:55 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 12:15:54 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (c228380-a.sfmissn1.sfba.home.com [24.20.90.44]) by hub.freebsd.org (Postfix) with ESMTP id EFAB937B400 for ; Tue, 5 Dec 2000 12:15:53 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB5KOpF00897; Tue, 5 Dec 2000 12:24:52 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012052024.eB5KOpF00897@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Koster, K.J." Cc: "'FreeBSD Hackers mailing list'" , "Metz, E.T." Subject: Re: yet another unsupported PHY in fxp driver In-reply-to: Your message of "Tue, 05 Dec 2000 16:08:01 +0100." <59063B5B4D98D311BC0D0001FA7E4522026D7A89@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Dec 2000 12:24:51 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > All of the above is caused by the SEEPROM not being read > > properly. Since it doesn't work with 4.1, this probably indicates that > > you're using an on-motherboard NIC (Supermicro?). > > > These are not on-board NICs, but PCI cards. (Do you know of a motherboard > that comes with four on-board NICs?) Actually, I do. You might want to talk to Larry Baird (lab@gta.com) about it. Quite a sexy device, actually. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 12:35: 1 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 12:34:57 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3701537B400; Tue, 5 Dec 2000 12:34:57 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB5KYvW27383; Tue, 5 Dec 2000 12:34:57 -0800 (PST) Date: Tue, 5 Dec 2000 12:34:56 -0800 From: Alfred Perlstein To: peter@freebsd.org Cc: dillon@freebsd.org, hackers@freebsd.org Subject: phys backed shm patch. Message-ID: <20001205123456.D8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I spent quite some time trying to figure out why postgresql would "hang" when using the 'kern.ipc.shm_use_phys' sysctl. It finally came down to some spinlocks that were being corrupted in a very tiny shared memory segment. It seems like the phys_pager doesn't correctly allocate when given a non PAGE_SIZE'd 'size' so then I think odd stuff happens to the memory in the pages: Index: phys_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/phys_pager.c,v retrieving revision 1.3.2.1 diff -u -u -r1.3.2.1 phys_pager.c --- phys_pager.c 2000/08/04 22:31:11 1.3.2.1 +++ phys_pager.c 2000/12/05 20:13:25 @@ -83,7 +83,7 @@ * Allocate object and associate it with the pager. */ object = vm_object_allocate(OBJT_PHYS, - OFF_TO_IDX(foff + size)); + OFF_TO_IDX(foff + PAGE_MASK + size)); object->handle = handle; TAILQ_INSERT_TAIL(&phys_pager_object_list, object, pager_object_list); I basically grabbed this from the swap_pager.c code and it seems to work. I'd like to commit it to both current and stable asap (afaik no one uses kern.ipc.shm_use_phys anyhow, we missed the boat on Oracle) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 13:38:55 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 13:38:53 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 0C48937B400 for ; Tue, 5 Dec 2000 13:38:53 -0800 (PST) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id eB5Lcmq27730 for ; Tue, 5 Dec 2000 13:38:48 -0800 From: "Jonathan Graehl" To: Subject: POSIX clock_gettime, clock_getres return errno invalid argument for CLOCK_PROF and CLOCK_VIRTUAL Date: Tue, 5 Dec 2000 13:43:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The resolution (clock_getres) of CLOCK_REALTIME is 783 ns on my 4.2-STABLE/Pentium 2. Is there a more accurate timer available? (clearly, gettimeofday is limited to 1000ns resolution ;) (submitted pr follows) While there is no problem with CLOCK_REALTIME, POSIX clock_gettime, clock_getres return errno invalid argument for CLOCK_PROF and CLOCK_VIRTUAL, which are documented in the man pages (section 2) as being user+system and user time, respectively. FreeBSD 3jane 4.2-STABLE FreeBSD 4.2-STABLE #0: Sat Dec 2 14:46:10 PST 2000 root@3jane:/ext/obj/usr/src/sys/NEWJANE i386 /* demonstrates that the clock_get... calls succed for CLOCK_REALTIME but fail for CLOCK_PROF and CLOCK_VIRTUAL */ #include #include int main() { struct timespec t; puts("CLOCK_PROF"); if (clock_gettime(CLOCK_PROF, &t)) perror(NULL); if (clock_getres(CLOCK_PROF, &t)) perror(NULL); puts("\nCLOCK_VIRTUAL"); if (clock_gettime(CLOCK_VIRTUAL, &t)) perror(NULL); if (clock_getres(CLOCK_VIRTUAL, &t)) perror(NULL); puts("\nCLOCK_REALTIME"); if (clock_gettime(CLOCK_REALTIME, &t)) perror(NULL); if (clock_getres(CLOCK_REALTIME, &t)) perror(NULL); } Immediate fix: remove mention of CLOCK_VIRTUAL AND CLOCK_PROF from sys/time.h and man 2 clock_gettime Real fix: implement the documented POSIX functionality To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 13:44:33 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 13:44:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id E74A737B400; Tue, 5 Dec 2000 13:44:29 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB5LiNT86399; Tue, 5 Dec 2000 13:44:23 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Dec 2000 13:44:23 -0800 (PST) From: Matt Dillon Message-Id: <200012052144.eB5LiNT86399@earth.backplane.com> To: Alfred Perlstein Cc: peter@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: phys backed shm patch. References: <20001205123456.D8051@fw.wintelcom.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Ok, I spent quite some time trying to figure out why postgresql :would "hang" when using the 'kern.ipc.shm_use_phys' sysctl. : :It finally came down to some spinlocks that were being corrupted :in a very tiny shared memory segment. : :It seems like the phys_pager doesn't correctly allocate when :given a non PAGE_SIZE'd 'size' so then I think odd stuff happens :to the memory in the pages: Yes, you are absolutely right. That's definitely a bug and your fix is the correct one. In regards to simultanious commit, unless someone makes the rules a little more reasonable for simple bug fixes like this you'll probably get fried for doing it by bozos who have nothing better to do with their time. -Matt :Index: phys_pager.c :=================================================================== :RCS file: /home/ncvs/src/sys/vm/phys_pager.c,v :retrieving revision 1.3.2.1 :diff -u -u -r1.3.2.1 phys_pager.c :--- phys_pager.c 2000/08/04 22:31:11 1.3.2.1 :+++ phys_pager.c 2000/12/05 20:13:25 :@@ -83,7 +83,7 @@ : * Allocate object and associate it with the pager. : */ : object = vm_object_allocate(OBJT_PHYS, :- OFF_TO_IDX(foff + size)); :+ OFF_TO_IDX(foff + PAGE_MASK + size)); : object->handle = handle; : TAILQ_INSERT_TAIL(&phys_pager_object_list, object, : pager_object_list); : : :I'd like to commit it to both current and stable asap (afaik no :one uses kern.ipc.shm_use_phys anyhow, we missed the boat on :Oracle) : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 13:53:24 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 13:53:21 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 558B737B400 for ; Tue, 5 Dec 2000 13:53:20 -0800 (PST) Received: (qmail 80007 invoked by uid 1001); 5 Dec 2000 21:53:17 +0000 (GMT) To: K.J.Koster@kpn.com Cc: freebsd-hackers@freebsd.org, E.T.Metz@kpn.com Subject: Re: yet another unsupported PHY in fxp driver From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 05 Dec 2000 15:52:20 +0100" References: <59063B5B4D98D311BC0D0001FA7E4522026D7A88@l04.research.kpn.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 05 Dec 2000 22:53:17 +0100 Message-ID: <80005.976053197@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Relevant dmesg output: > > fxp0: Ethernet address 00:08:c7:7b:05:bd > bpf: fxp0 attached > fxp1: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps > bpf: fxp1 attached > fxp2: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps > bpf: fxp2 attached > fxp3: Ethernet address 00:b4:c0:91:d2:9c, 10Mbps > > Say what? I lived under the impression that MAC addresses were unique. Here > I have three cards that have identical MAC adresses. This is probably tangential to the rest of the discussion, but: The requirement is a unique MAC address per *host*, not per card. Sun workstations have traditionally been setup this way. 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 Tue Dec 5 14:10:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 14:10:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 302A937B400 for ; Tue, 5 Dec 2000 14:10:25 -0800 (PST) Received: (qmail 6121 invoked by uid 0); 5 Dec 2000 22:10:22 -0000 Received: from p3ee21602.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.2) by mail.gmx.net (mail06) with SMTP; 5 Dec 2000 22:10:22 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id WAA13114 for freebsd-hackers@FreeBSD.ORG; Tue, 5 Dec 2000 22:56:56 +0100 Date: Tue, 5 Dec 2000 22:56:56 +0100 From: Gerhard Sittig To: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <20001205225656.Z27042@speedy.gsinet> References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001120193326.C27042@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Mon, Nov 20, 2000 at 07:33:26PM +0100 Organization: System Defenestrators Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ I'm not subscribed to -hackers, please keep CC'ing me; thanks! ] On Mon, Nov 20, 2000 at 19:33 +0100, Gerhard Sittig wrote: > > [ ... cron and DST ... ] > > But I thought modifying cron(8) itself would be the best way. > Is someone already working on this or should I try to do it > myself (within the next few weeks)? Since I dared to offer my working on cron.c in the above cited cvs-all message <20001120193326.C27042@speedy.gsinet> and nobody stopped me :) I did as sketched here: $ diff -r -u \ fbsd/src/usr.sbin/cron/cron \ obsd/src/usr.sbin/cron \ > $PATCHFILE $ $EDITOR $PATCHFILE $ cd fbsd/src/usr.sbin/cron/cron $ patch -p4 < $PATCHFILE $ make all This took the DST handling code of OpenBSD's cron, leaving the other diffs / details (capabilities, logging, errno handling, gcc work arounds, formatting, pipe/env etc stuff) aside. But what keeps me from feeding the changes back into the FreeBSD project by means of send-pr(1) is that I don't want to do so before testing that everything works as it should. That's where I fail miserably: # script # kill `cat /var/run/cron.pid` # ./cron -x sch & ... watch it for a while ... # date -v+1H ... further watch it ... # echo 'date 0300' | at 0200 ... further watch it ... Normal run is not broken. :) Small jumps (the first date command) work as expected. But the DST emulation (the second date command, delayed) fails since "something" turns back the clock some two minutes after the scheduled jump. And I feel it's adjkerntz(8) run by cron doing so (scheduled for 03:01:00 by default). Remembering the fortune "Don't force it. Get a larger hammer!" and after reading "man 5 tzfile; man 8 zic zdump" I applied the following patch to simulate another DST change: Index: /usr/src/share/zoneinfo/europe =================================================================== RCS file: /usr/fcvs/src/share/zoneinfo/europe,v retrieving revision 1.18.2.2 diff -u -r1.18.2.2 europe --- /usr/src/share/zoneinfo/europe 2000/10/25 19:44:08 1.18.2.2 +++ /usr/src/share/zoneinfo/europe 2000/12/03 12:36:54 @@ -406,6 +406,10 @@ Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - +# this is my private modification to test out DST handling code in cron(8). +Rule EU 2000 only - Dec 4 1:00u 1:00 S +Rule EU 2000 only - Dec 5 1:00u 0 - + # W-Eur differs from EU only in that W-Eur uses standard time. Rule W-Eur 1977 1980 - Apr Sun>=1 1:00s 1:00 S Rule W-Eur 1977 only - Sep lastSun 1:00s 0 - After "make buildworld; make installworld; mergemaster; cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime" (you know, grabbing the _big_ stick ...) I tried to double check: $ zdump -v /etc/localtime | grep 2000 /etc/localtime Sun Mar 26 00:59:59 2000 UTC = Sun Mar 26 01:59:59 2000 CET isdst=0 gmtoff=3600 /etc/localtime Sun Mar 26 01:00:00 2000 UTC = Sun Mar 26 03:00:00 2000 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 29 00:59:59 2000 UTC = Sun Oct 29 02:59:59 2000 CEST isdst=1 gmtoff=7200 /etc/localtime Sun Oct 29 01:00:00 2000 UTC = Sun Oct 29 02:00:00 2000 CET isdst=0 gmtoff=3600 /etc/localtime Mon Dec 4 00:59:59 2000 UTC = Mon Dec 4 01:59:59 2000 CET isdst=0 gmtoff=3600 /etc/localtime Mon Dec 4 01:00:00 2000 UTC = Mon Dec 4 03:00:00 2000 CEST isdst=1 gmtoff=7200 /etc/localtime Tue Dec 5 00:59:59 2000 UTC = Tue Dec 5 02:59:59 2000 CEST isdst=1 gmtoff=7200 /etc/localtime Tue Dec 5 01:00:00 2000 UTC = Tue Dec 5 02:00:00 2000 CET isdst=0 gmtoff=3600 (Actually this was done in two steps: First I copied the "EU" and "Germany" sections from the europe file, inserted the additional DST switch between 01:00 and 04:00 UTC on an earlier date, compiled and installed with "zic -d . tzfile; cp CronDST /etc/localtime", tested with the above zdump command and failed to get the expected DST messages when running cron, too. :< ) Afterwards I started the test again ("script; kill `cat /var/run/cron.pid`; ./cron -x sch") and failed to see _any_ "DST" log messages I've seen before. Although local time did change (jump forward for an hour) for this one day. Hmmm ... I'm lost. Please advise on how to best test this scenario. Without local tests I definitely won't publish the patch (don't feel at all like bothering others with code which doesn't work in its basic functionality). Having the logic in cron itself would eliminate the never ending discussion bubbling up twice a year on why cronjobs didn't run / ran multiple times and where to move daily cronjobs to (ending up every time with the result that _no_ time suits _all_ the FreeBSD users -- there simply are way too many of them ... :). Thank you for your attention (and patience to read this lengthy message)! virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 14:15: 2 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 14:15:00 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from dell.dannyland.org (dell.dannyland.org [64.81.36.13]) by hub.freebsd.org (Postfix) with ESMTP id A4B3D37B400 for ; Tue, 5 Dec 2000 14:15:00 -0800 (PST) Received: by dell.dannyland.org (Postfix, from userid 1001) id 901B25BF3; Tue, 5 Dec 2000 14:15:08 -0800 (PST) Date: Tue, 5 Dec 2000 14:15:08 -0800 From: dannyman To: Brandon Fosdick Cc: Dag-Erling Smorgrav , Yusuf Goolamabbas , freebsd-hackers@FreeBSD.ORG Subject: Re: nslookup deprecation [was 4.2 complaint] Message-ID: <20001205141508.O7279@dell.dannyland.org> References: <20001205133817.A24228@outblaze.com> <3A2D1C5A.3234E4C5@glue.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A2D1C5A.3234E4C5@glue.umd.edu>; from bfoz@glue.umd.edu on Tue, Dec 05, 2000 at 11:48:26AM -0500 X-Loop: djhoward@uiuc.edu X-URL: http://www.dannyland.org/~dannyman/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Dec 05, 2000 at 11:48:26AM -0500, Brandon Fosdick wrote: > Dag-Erling Smorgrav wrote: > > Yusuf Goolamabbas writes: > > > Recently there was a message indicating that ISC is deprecating > > > nslookup. > > > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > > Will a replacement be added to the base distro? When? The host(1) man page dates from late 1994. -danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 14:19: 2 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 14:19:00 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8B07937B400; Tue, 5 Dec 2000 14:19:00 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB5MJ0c01005; Tue, 5 Dec 2000 14:19:00 -0800 (PST) Date: Tue, 5 Dec 2000 14:18:59 -0800 From: Alfred Perlstein To: Matt Dillon Cc: peter@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: phys backed shm patch. Message-ID: <20001205141859.F8051@fw.wintelcom.net> References: <20001205123456.D8051@fw.wintelcom.net> <200012052144.eB5LiNT86399@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012052144.eB5LiNT86399@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Dec 05, 2000 at 01:44:23PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [001205 13:44] wrote: > : > :Ok, I spent quite some time trying to figure out why postgresql > :would "hang" when using the 'kern.ipc.shm_use_phys' sysctl. > : > :It finally came down to some spinlocks that were being corrupted > :in a very tiny shared memory segment. > : > :It seems like the phys_pager doesn't correctly allocate when > :given a non PAGE_SIZE'd 'size' so then I think odd stuff happens > :to the memory in the pages: > > Yes, you are absolutely right. That's definitely a bug and your fix > is the correct one. k thnx. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 21:19:53 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 21:19:48 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from crotchety.newsbastards.org (netcop.newsbastards.org [193.162.153.124]) by hub.freebsd.org (Postfix) with ESMTP id 49C7D37B400 for ; Tue, 5 Dec 2000 21:19:47 -0800 (PST) Received: (from news@localhost) by crotchety.newsbastards.org (8.11.1/8.11.1) id eB65JS910042; Wed, 6 Dec 2000 06:19:28 +0100 (CET) (envelope-from newsluser@free-pr0n.netscum.dk) Date: Wed, 6 Dec 2000 06:19:28 +0100 (CET) Message-Id: <200012060519.eB65JS910042@crotchety.newsbastards.org> X-Authentication-Warning: crotchety.newsbastards.org: news set sender to newsluser@free-pr0n.netscum.dk using -f Reply-To: freebsd-user@netscum.dk From: News History File User To: Matt Dillon Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> In-Reply-To: <200012050545.eB55jL453889@crotchety.newsbastards.org> Sender: newsluser@free-pr0n.netscum.dk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Howdy, I'm going to breach all sorts of ethics in the worst way by following up to my own message, just to throw out some new info... 'kay? Matt wrote, and I quote -- : > However, I noticed something interesting! Of course I clipped away the interesting Thing, but note the following that I saw... : INN after adding the memory, I did a `cp -p' on both the history.hash : and history.index files, just to start fresh and clean. It didn't seem [...] : > There is an easy way to test file fragmentation. Kill off everything : > and do a 'dd if=history of=/dev/null bs=32k'. Do the same for : > history.hash and history.index. Look at the iostat on the history : > drive. Specifically, do an 'iostat 1' and look at the KB/t (kilobytes : > per transfer). You should see 32-64KB/t. If you see 8K/t the file : > is severely fragmented. Go through the entire history file(s) w/ dd... : : Okay, I'm doing this: The two hash-type files give me between 9 and : 10K/t; the history text file gives me more like 60KB/t. Hmmm. It's Now, remember what Matt wrote, that partially-cached data played havoc with read-ahead. That is apparently what I was seeing here, pulling some bit of data off the disk proper, but then pulling a chunk of data that was cached, and so on. I figured that out as I attempted to copy one of the files to create an unfragmented copy to test transfer size and saw the expected 64K (well DUH, that was the write size), and then attempted to `dd' these to /dev/null and saw ... no disk activity. The file was in cache. Bummer. Oh well, I had to reboot anyway for some reason, and did so. Immediately after reboot I `dd'ed the two database files and got the expected 64K/t of an unfragmented file. I also made copies of them just to push their contents into memory, because... : The actual history lookups and updates that matter are all done within : the memory taken up by the .index and .hash files. So, by keeping : them in memory, one doesn't need to do any disk activity at all for : lookups, and updates, well, so long as you commit them to the disk at : shutdown, all should be okay. That's what I'm attempting to achieve. : These lookups and updates are bleedin' expensive when disk activity : rears its ugly head. : : Not to worry, I'm going to keep plugging to see if there is a way for : me to lock these two files into memory so that they *stay* there, just : to prove whether or not that's a significant performance improvement. : I may have to break something, but hey... I b0rked something. I `fixed' the mlock operation to allow a lowly user such as myself to use it, just as proof of concept. (I still need to do a bit of tuning, I can see, but hey, I got results) So I attempt to pass all the madvise suggestions I can for both the history.index and .hash files, and then I attempt to mlock both of them. I don't get a failure, although the history.hash file (108MB) doesn't quite achieve the desired results -- I do see Good Things with the smaller history.index (72MB and don't remind me that 1MB really isn't 1000000bytes). Anyway, the number of `Wired' Megs in `top' is up from 71MB to 200+, and after some hours of operation, look at the timestamps of the two database files (the .n.* files are those I copied after reboot, and serve as a nice reference for when I started things) -rw-rw-r-- 1 news news 755280213 Dec 5 19:05 history -rw-rw-r-- 1 news news 57 Dec 5 19:05 history.dir -rw-rw-r-- 1 news news 108000000 Dec 5 19:05 history.hash -rw-rw-r-- 1 news news 72000000 Dec 5 08:44 history.index -rw-rw-r-- 1 news news 108000000 Dec 5 08:43 history.n.hash -rw-rw-r-- 1 news news 72000000 Dec 5 08:44 history.n.index So, okay, history.hash still sees disk activity, but look at a handful of INN timer stats following the boot: The last two stats with the default vm k0deZ before restart: Dec 5 08:30:40 crotchety innd: ME time 301532 idle 28002(120753) artwrite 70033(2853) artlink 0(0) hiswrite 49396(3097) hissync 28(6) ^^^^^ sitesend 460(5706) artctrl 296(25) artcncl 295(25) hishave 32016(8923) ^^^^^ hisgrep 45(10) artclean 20816(3150) perl 12536(3082) overv 29927(2853) python 0(0) ncread 33729(152735) ncproc 227796(152735) 80 seconds of 300 spent on history activity... urk... on a steady-state system with a few readers that had been running for some hours. Dec 5 08:35:37 crotchety innd: ME time 300052 idle 16425(136209) artwrite 77811(2726) artlink 0(0) hiswrite 35676(2941) hissync 28(6) sitesend 571(5450) artctrl 454(41) artcncl 451(41) hishave 33311(7392) hisgrep 55(14) artclean 22778(3000) perl 14137(2914) overv 28516(2726) python 0(0) ncread 38832(172145) ncproc 226513(172145) [REB00T] Dec 5 08:59:32 crotchety innd: ME time 300059 idle 62840(189385) artwrite 68361(5580) artlink 0(0) hiswrite 8782(6567) hissync 104(12) ^^^^ sitesend 784(11160) artctrl 40(112) artcncl 38(112) hishave 5371(24250) ^^^^ hisgrep 0(35) artclean 20274(6510) perl 16160(6490) overv 59032(5580) python 0(0) ncread 31477(214268) ncproc 192853(214268) Hmmm, 15 seconds to do twice as many lookups. Normally the times start out after a restart pretty high and drop as the accessed pages are pulled into memory, so long as they don't get dumped back to disk. Dec 5 09:04:32 crotchety innd: ME time 300069 idle 33289(253926) artwrite 94561(3510) artlink 0(0) hiswrite 1758(3897) hissync 1(8) sitesend 472(7020) artctrl 26(42) artcncl 26(42) hishave 23394(39303) ^^^^^ hisgrep 0(25) artclean 28223(3892) perl 16704(3880) overv 19391(3510) python 0(0) ncread 44259(300338) ncproc 203424(300338) I'll go out on a limb and claim that the much higher time for the history lookups here is because the on-disk copy of history.hash is getting updated and this activity causes needed pages to be written out and read back in. Dec 5 09:09:32 crotchety innd: ME time 300031 idle 31795(270764) artwrite 99006(3474) artlink 0(0) hiswrite 1653(3914) hissync 23(8) sitesend 512(6948) artctrl 57(136) artcncl 56(136) hishave 13301(34866) hisgrep 1(54) artclean 29608(3863) perl 16995(3832) overv 20565(3474) python 0(0) ncread 47222(319176) ncproc 201221(319176) Dec 5 09:14:32 crotchety innd: ME time 300020 idle 31741(275290) artwrite 101160(3596) artlink 0(0) hiswrite 1608(3941) hissync 0(8) sitesend 512(7192) artctrl 58(121) artcncl 57(121) hishave 8062(29428) hisgrep 1(75) artclean 29083(3905) perl 17264(3895) overv 22364(3596) python 0(0) ncread 47022(322682) ncproc 201300(322682) Dec 5 09:19:32 crotchety innd: ME time 300000 idle 36150(258630) artwrite 95591(3410) artlink 0(0) hiswrite 4945(3799) hissync 1(8) sitesend 468(6820) artctrl 47(89) artcncl 46(89) hishave 6242(25413) hisgrep 0(47) artclean 28568(3831) perl 16320(3757) overv 22914(3410) python 0(0) ncread 47191(302273) ncproc 195326(302273) Still, as the history times fall, I'm starting to chew on the backlogs that I hadn't been able to take in before. Skipping a bit of time... Dec 5 10:24:33 crotchety innd: ME time 300017 idle 15118(112875) artwrite 74383(3305) artlink 0(0) hiswrite 11005(3837) hissync 42(8) sitesend 595(6610) artctrl 1751(359) artcncl 1713(359) hishave 13512(10514) hisgrep 6(50) artclean 25837(3573) perl 15504(3528) overv 69173(3305) python 0(0) ncread 44935(151577) ncproc 227542(151577) Dec 5 10:29:33 crotchety innd: ME time 300118 idle 24125(179647) artwrite 85188(3535) artlink 0(0) hiswrite 9523(4021) hissync 11(8) sitesend 543(7070) artctrl 672(398) artcncl 663(398) hishave 15373(11343) hisgrep 3(188) artclean 28574(3819) perl 16549(3811) overv 36233(3535) python 0(0) ncread 48899(223058) ncproc 210626(223058) Not optimal timings, but decent -- compare 25 seconds devoted to history activity with as much as two minutes that I had been seeing previously, when the smaller history.index file was being scribbled to on disk too. Another thing is that there is still the noticeable time when the system is dumping data to the history drive every 30-some seconds, and related history access freezes up. Previously, this had taken from, oh, four to eight seconds, but now it's one to two seconds in duration. Still not as perfect as if I could convince the history.hash file not to be flushed to disk as well, but it certainly shows that it is a performance killer when one does have to do this history update activity. Dec 5 12:24:33 crotchety innd: ME time 300075 idle 7271(44156) artwrite 66376(2715) artlink 0(0) hiswrite 1607(3018) hissync 104(7) sitesend 594(5430) artctrl 17(29) artcncl 17(29) hishave 4170(16315) hisgrep 0(8) artclean 22926(3002) perl 13387(2997) overv 117031(2715) python 0(0) ncread 41060(75619) ncproc 243805(75619) Whoa, how did that happen. I can live with it... Dec 5 17:59:37 crotchety innd: ME time 300001 idle 39108(186389) artwrite 78561(3271) artlink 0(0) hiswrite 15946(4020) hissync 11(9) sitesend 700(6542) artctrl 307(88) artcncl 303(88) hishave 18674(13309) hisgrep 14(24) artclean 23868(3966) perl 15008(3956) overv 35097(3271) python 0(0) ncread 41240(217018) ncproc 204095(217018) And an extreme in the other direction. To recap, the difference here is that by cheating, I was able to mlock one of the two files (the behaviour I was hoping to be able to achieve through first MAP_NOSYNC alone, then in combination with MADV_WILLNEED to keep all the pages in memory so much as possible) and achieve a much improved level of performance -- I'm able to catch up on backlogs from a full feed that had built up during the time I wasn't cheating -- by using memory for the history database files rather than for general filesystem caching. I even have spare capacity! Woo. The mlock man page refers to some system limit on wired pages; I get no error when mlock()'ing the hash file, and I'm reasonably sure I tweaked the INN source to treat both files identically (and on the other machines I have running, the timestamps of both files remains pretty much unchanged). I'm not sure why I'm not seeing the desired results here with both files (maybe some call hidden somewhere I haven't located yet), but I hope you can see the improvements so far. I even let abusive readers pound on me. Well, for a while 'til I got tired of 'em. I still don't know for certain if the disk updates I am seeing are slow because they aren't sorted well, or if they're random pages and not a sequential set, given that I hope I've ruled out fragmentation of the database files. I still maintain that in the case of a true MADV_RANDOM madvise'd file, any attempts to clean out `unused' pages are ill-advised, or if they're needed, anything other than freeing of sequential pages results in excess disk activity that gains nothing, if it's the case that this is not how it's done, due to the nature of random access. Yeah, hacking the vm source to allow me to mlock() isn't kosher, but I wanted to test a theory. Doing so probably requires a few more tweaks in the INN source to handle expiry, so it seems, so I'd rather the vm subsystem do this for me automagically with the right invocation of the suitable mmap/madvise operations, if this is reasonable. ThaNk U 4 uR atTenT1oN aNd pLz haVe a NICE DaY bArRy b0uWsmA, tElE dAnmArk IntErnEt nEws k0dEhaX0r To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 21:25:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 21:25:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.iconz.co.nz (etrn.iconz.co.nz [210.48.22.36]) by hub.freebsd.org (Postfix) with ESMTP id 4A46837B69C; Tue, 5 Dec 2000 21:24:56 -0800 (PST) Received: from creativejuice.co.nz (ip-210-48-60-242.iconz.net.nz [210.48.60.242] (may be forged)) by mail.iconz.co.nz (8.9.3/8.9.3) with ESMTP id SAA043700976080139; Wed, 6 Dec 2000 18:22:19 +1300 (NZDT) From: tom@aba.com Message-Id: <200012060522.SAA043700976080139@mail.iconz.co.nz> Received: from [62.159.146.73] by [192.168.1.2] with SMTP (QuickMail Pro Server for Mac 2.0.1); 06-Dec-2000 18:23:08 +1300 To: Subject: Search Engine Optimization Kit-2001 24123 Date: Wed, 06 Dec 2000 00:16:29 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Errors-To: X-Mailer: Outlook Express X-Originating-IP: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG
Get Top 10 Positions With The Search Engine Optimization Kit-2001

No hype ... no gimmicks ... just the facts ... and only $59!

Hello Friend,

We created the Search Engine Optimization Kit-2001 to achieve high positions in search engines. This unique Kit includes:
  • Detailed information about how search engines work,

  • Step-by-step instructions to create, high-ranking,"search-= engine-friendly" pages,

  • All the tools and resources you need to create pages, submit to= engines and track your placements, and

  • Ongoing personal support by email and phone.

Click to receive Free In= formation about Search Engines and the Kit, or call direct to 937-640-2762.

We reply promptly to all inquires.

Dr. Jerry R. Perrich, Director
The Internet Marketing Institute, Inc.
Helping You Be Successful Online
937-640-2762


PS - Please forward this email to any of your business associates or friends who may benefit from it.

REMOVAL INSTRUCTIONS=
Per federal legislation, you can be removed from this mailing list at no c= ost to you by simply clicking here Remove Ple= ase. You will be promptly removed. Please note that interfering with this feder= ally approved method of removal will deny others the opportunity to be removed.

<= p>

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 22:57:40 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 22:57:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 96CE837B400 for ; Tue, 5 Dec 2000 22:57:34 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB66u6f91456; Tue, 5 Dec 2000 22:56:06 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Dec 2000 22:56:06 -0800 (PST) From: Matt Dillon Message-Id: <200012060656.eB66u6f91456@earth.backplane.com> To: News History File User Cc: hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wouldn't worry about madvise() too much. 4.2 has a really good heuristic that figures it out for the most part. (still reading the rest of your postings) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Dec 5 23:14:29 2000 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 5 23:14:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id A237637B400 for ; Tue, 5 Dec 2000 23:14:25 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB67D8I91529; Tue, 5 Dec 2000 23:13:08 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Dec 2000 23:13:08 -0800 (PST) From: Matt Dillon Message-Id: <200012060713.eB67D8I91529@earth.backplane.com> To: News History File User Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :To recap, the difference here is that by cheating, I was able to mlock :one of the two files (the behaviour I was hoping to be able to achieve :through first MAP_NOSYNC alone, then in combination with MADV_WILLNEED :to keep all the pages in memory so much as possible) and achieve a much :improved level of performance -- I'm able to catch up on backlogs from :a full feed that had built up during the time I wasn't cheating -- by :using memory for the history database files rather than for general :filesystem caching. I even have spare capacity! Woo. : :The mlock man page refers to some system limit on wired pages; I get no :error when mlock()'ing the hash file, and I'm reasonably sure I tweaked :the INN source to treat both files identically (and on the other machines :I have running, the timestamps of both files remains pretty much unchanged). :I'm not sure why I'm not seeing the desired results here with both files :(maybe some call hidden somewhere I haven't located yet), but I hope you :can see the improvements so far. I even let abusive readers pound on :me. Well, for a while 'til I got tired of 'em. I think you are on to something here. It's got to be mlock(). Run 'limit' from csh/tcsh and you will see a 'memorylocked' resource. Whatever this resource is as of when innd is run -- presumably however it is initialized for the 'news' user (see /etc/login.conf) is going to effect mlock() operation. mlock() will wire pages. I think you can safely call it on your two smaller history files (history.hash, history.index). I can definitely see how this could result in better performance. :I still don't know for certain if the disk updates I am seeing are :slow because they aren't sorted well, or if they're random pages and :not a sequential set, given that I hope I've ruled out fragmentation :of the database files. I still maintain that in the case of a true :MADV_RANDOM madvise'd file, any attempts to clean out `unused' pages :are ill-advised, or if they're needed, anything other than freeing of :sequential pages results in excess disk activity that gains nothing, :if it's the case that this is not how it's done, due to the nature :of random access. History files are nortorious for random I/O... the problem is due to the hash table being, well, a hash table. The hash table lookups are bad enough but this will also result in random-like lookups on the main history file. You get a little better locality of reference on the main history file (meaning the system can do a better job caching it optimally), but the hash tables are a lost cause so mlock()ing them could be a very good thing. :Yeah, hacking the vm source to allow me to mlock() isn't kosher, but :I wanted to test a theory. Doing so probably requires a few more :tweaks in the INN source to handle expiry, so it seems, so I'd rather :the vm subsystem do this for me automagically with the right invocation :of the suitable mmap/madvise operations, if this is reasonable. At the moment madvise() MADV_WILLNEED does nothing more then activate the pages in question and force them into the process'es mmap. You have to call it every so often to keep the pages 'fresh'... calling it once isn't going to do anything. When you call madvise() MADV_WILLNEED the system has to go through a number of steps before the pages will be thrown away: - it has to remove them from the process pmap - it has to deactivate them - it has to cache them - then it can free them You may be able to achieve an effect very similar to mlock(), but runnable by the 'news' user without hacking the kernel, by writing a quick little C program to mmap() the two smaller history files and then madvise() the map using MADV_WILLNEED in a loop with a sleep(15). Keeping in mind that expire may recreate those files, the program should unmap, close(), and re-open()/mmap/madvise the descriptors every so often (like once a minute). You shouldn't have to access the underlying pages but that would also have a similar effect. If you do, use a volatile pointer so GCC doesn't optimize the access out of the loop. e.g. for (ptr = mapBase; ptr < mapEnd; ptr += pageSize) { volatile char c = *ptr; } or for (ptr = mapBase; ptr < mapEnd; ptr += pageSize) { dummyroutine(*ptr); } And my earlier suggestion above would look something like: for (;;) { open descriptor map for (i = 0; i < 15; ++i) { madvise(mapBase, mapSize, MADV_WILLNEED); sleep(15); } munmap close descriptor } -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 0:51: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 00:51:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 05D6037B400 for ; Wed, 6 Dec 2000 00:51:01 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id JAA28321; Wed, 6 Dec 2000 09:50:56 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "G. Adam Stanislav" Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> <20001205121423.A228@whizkidtech.net> From: Dag-Erling Smorgrav Date: 06 Dec 2000 09:50:55 +0100 In-Reply-To: "G. Adam Stanislav"'s message of "Tue, 5 Dec 2000 12:14:23 -0600" Message-ID: Lines: 26 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" writes: > On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: > >The second and third sentences of the second paragraph (the one that > >starts on line 23), as well as the entire eighth paragraph (that > >starts on line 45), address the questions you asked in your previous > >mail. > I know it addresses it. Unfortunately, I didn't understand a word of it. I don't see how it could get any clearer. [...] If addr is zero, an address will be selected by the system. The actual starting address of the region is returned. This means you don't need to provide an address to mmap, it'll pick one on its own. MAP_ANON Map anonymous memory not associated with any specific file. The file descriptor used for creating MAP_ANON must be -1. The offset parameter is ignored. This means you can mmap() memory that isn't associated with a file by passing -1 instead of a file descriptor and adding MAP_ANON to flags. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 2: 6:50 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 02:06:47 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id 8430B37B404 for ; Wed, 6 Dec 2000 02:06:45 -0800 (PST) Received: from dungeon.home (ppp52.dyn250.pacific.net.au [203.143.250.52]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id VAA03320; Wed, 6 Dec 2000 21:06:39 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.9.3) with ESMTP id eB6A6o504244; Wed, 6 Dec 2000 20:06:50 +1000 (EST) (envelope-from mckay) Message-Id: <200012061006.eB6A6o504244@dungeon.home> To: Dag-Erling Smorgrav Cc: "G. Adam Stanislav" , Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> <20001205121423.A228@whizkidtech.net> In-Reply-To: from Dag-Erling Smorgrav at "06 Dec 2000 09:50:55 +0100" Date: Wed, 06 Dec 2000 20:06:50 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 6th December 2000, Dag-Erling Smorgrav wrote: >"G. Adam Stanislav" writes: >> I know it addresses it. Unfortunately, I didn't understand a word of it. > MAP_ANON Map anonymous memory not associated with any specific file. > The file descriptor used for creating MAP_ANON must be -1. > The offset parameter is ignored. > >This means you can mmap() memory that isn't associated with a file by >passing -1 instead of a file descriptor and adding MAP_ANON to flags. I think you are being too hard on the guy. It's not at all obvious that mmap() can be used to allocate memory. Read the first sentence of the manual to see what mmap() used to be about. It was a way to avoid read() and write() calls. All this MAP_ANON memory allocation stuff came later. If I were new to Unix, I wouldn't be looking around for anonymous memory mapping primitives as a way to implement malloc(). It has only been a good way to do that in recent times. While I don't like to see people shooting themselves in the foot by using the wrong system calls, I don't think we need to hammer them into the dirt to change their minds. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 5:55:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 05:55:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from crotchety.newsbastards.org (netcop.newsbastards.org [193.162.153.124]) by hub.freebsd.org (Postfix) with ESMTP id 14CEA37B400 for ; Wed, 6 Dec 2000 05:55:25 -0800 (PST) Received: (from news@localhost) by crotchety.newsbastards.org (8.11.1/8.11.1) id eB6DtGS34255; Wed, 6 Dec 2000 14:55:16 +0100 (CET) (envelope-from newslooser@free-pr0n.netscum.dk) Date: Wed, 6 Dec 2000 14:55:16 +0100 (CET) Message-Id: <200012061355.eB6DtGS34255@crotchety.newsbastards.org> X-Authentication-Warning: crotchety.newsbastards.org: news set sender to newslooser@free-pr0n.netscum.dk using -f Reply-To: freebsd-user@netscum.dk To: Matt Dillon In-Reply-To: <200012060713.eB67D8I91529@earth.backplane.com> From: News History File User Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> <200012060713.eB67D8I91529@earth.backplane.com> Sender: newslooser@free-pr0n.netscum.dk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :The mlock man page refers to some system limit on wired pages; I get no > :error when mlock()'ing the hash file, and I'm reasonably sure I tweaked > :the INN source to treat both files identically (and on the other machines > :I have running, the timestamps of both files remains pretty much unchanged). > :I'm not sure why I'm not seeing the desired results here with both files > > I think you are on to something here. It's got to be mlock(). Run > 'limit' from csh/tcsh and you will see a 'memorylocked' resource. > Whatever this resource is as of when innd is run -- presumably however > it is initialized for the 'news' user (see /etc/login.conf) is going Yep, `unlimited'... same as the bash `ulimit -a'. OH NO. I HAVE IT SET TO `infinity' IN LOGIN DOT CONF, no wonder it is all b0rken-like. The weird thing is that mlock() does return success, the amount of wired memory matches the two files, and I've seen nothing obvious in the source code as to why it's different, but I'll keep plugging away at it. > History files are nortorious for random I/O... the problem is due > to the hash table being, well, a hash table. The hash table > lookups are bad enough but this will also result in random-like > lookups on the main history file. You get a little better > locality of reference on the main history file (meaning the system Ah, but ... This is how the recent history format (based on MD5 hashes) introduced as dbz v6 at the time you were busy with Diablo and your history mechanism there differs from that which you remember -- AIEEEE, speaking of your 64-bit CRC history mechanism, whatever happened to the links that would get you there from the backplane homepage... -- in this case, you don't do the random-like lookups to verify message ID presence in the text file at all. Everything you do is in the data in the two hash tables. At least for transit. I'm not sure if the reader requests do require a hit on the main file -- it'd be worth it to point a Diablo frontend at such a box to see how it does there even when the overview performance for traditional readership is, uh, suboptimal. I think it does but that's a trivial seek to one specific known offset. I'm sure this is applicable to other databases somehow, for those who aren't doing news and are bored stiff by this. > At the moment madvise() MADV_WILLNEED does nothing more then activate > the pages in question and force them into the process'es mmap. > You have to call it every so often to keep the pages 'fresh'... calling > it once isn't going to do anything. Well, it definitely does do a Good Thing when I call it once, as you can see from the initial timer numbers that approach the long-running values I'm used to (that I tried to simulate by doing lookups on a small fraction of history entries, in hope of activating a majority of the needed pages, that wasn't perfect but was a decent hack). You can see from the timestamps of the debugging here that while it slows down the startup somewhat, the work of reading in the data happens quickly and is a definite positive tradeoff: Dec 6 07:32:14 crotchety innd: dbz openhashtable /news/db/history.index Dec 6 07:32:14 crotchety innd: dbz madvise WILLNEED ok Dec 6 07:32:14 crotchety innd: dbz madvise RANDOM ok Dec 6 07:32:14 crotchety innd: dbz madvise NOSYNC ok Dec 6 07:32:27 crotchety innd: dbz mlock ok Dec 6 07:32:27 crotchety innd: dbz openhashtable /news/db/history.hash Dec 6 07:32:27 crotchety innd: dbz madvise WILLNEED ok Dec 6 07:32:27 crotchety innd: dbz madvise RANDOM ok Dec 6 07:32:27 crotchety innd: dbz madvise NOSYNC ok Dec 6 07:32:38 crotchety innd: dbz mlock ok This happens quickly when the data is still in cache, leading me to believe it's something else affecting the .hash file (I added the madvise() MADV_NOSYNC call just in case somehow it wasn't happening in the mmap() for some reason): Dec 6 09:29:34 crotchety innd: dbz openhashtable /news/db/history.index Dec 6 09:29:34 crotchety innd: dbz madvise WILLNEED ok Dec 6 09:29:34 crotchety innd: dbz madvise RANDOM ok Dec 6 09:29:34 crotchety innd: dbz madvise NOSYNC ok Dec 6 09:29:34 crotchety innd: dbz mlock ok Dec 6 09:29:34 crotchety innd: dbz openhashtable /news/db/history.hash Dec 6 09:29:34 crotchety innd: dbz madvise WILLNEED ok Dec 6 09:29:34 crotchety innd: dbz madvise RANDOM ok Dec 6 09:29:34 crotchety innd: dbz madvise NOSYNC ok Dec 6 09:29:34 crotchety innd: dbz mlock ok > You may be able to achieve an effect very similar to mlock(), but > runnable by the 'news' user without hacking the kernel, by Yeah, sounds like a hack, but I figured out what was going on earlier with my mlock() hack -- INN and the reader daemon now use a dynamically linked library so the nnrpd processes also were trying to mlock() the files too. Hmmm. Either I can statically compile INN (which I chose to do) or I can further butcher the source by attempting to prevent nnrpd from making the mlock() call -- it makes the same mmap() and madvise() calls in the lib/dbz.c routines. Or I can lobby for the basic functionality of mlock() in userland, or try such a hack as you outline: > writing a quick little C program to mmap() the two smaller history > files and then madvise() the map using MADV_WILLNEED in a loop > with a sleep(15). Keeping in mind that expire may recreate those > files, the program should unmap, close(), and re-open()/mmap/madvise the > descriptors every so often (like once a minute). You shouldn't have Yeah, and because the reader processes do hold open the inodes for a good long time as long as the reader hangs around, I can see having to be a bit careful about planning reserve space. Thanks for the input. I can see that such a machine would be busy trying to manage the data for * more than 10GB per hour of incoming articles * some amount of newly-created or updated overview data * readers concentrating on pulling down the entire overview data, repeatedly, for a few groups, due to poorly-designed reader clients * readers pulling down several gigs per hour, concentrated on pr0n and similar newsgroups, in article data. And above all that, I want to keep a couple hundred megs of history hash table data in memory for quick access. No wonder the transit machines had no difficulty doing this most of the time, while I had to cheat to get this to happen when doing the additional filesystem work to support readers... Er, quick correction -- make that more than 11GB per hour of incoming articles. I just looked at today's stats. Urk. Be glad you got out of news when you did... thanks for all the input! barry bouwsma, bandwidth hog To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 6:37:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 06:37:22 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 77DE737B400; Wed, 6 Dec 2000 06:37:21 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA10667; Wed, 6 Dec 2000 15:37:20 +0100 (MET) Date: Wed, 6 Dec 2000 15:37:19 +0100 (CET) From: Harti Brandt To: hackers@freebsd.org, current@freebsd.org Subject: ATM broken in -current 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, the ATM stuff in /sys/dev/h{e,f}a and /sys/netatm seems to be seriously broken in current. A simple 'atm show config' command leads to a kernel panic. I have tracked down the problem (and had to learn, that bzero is a function pointer rather than a function on i386). I cannot track, how the problem was introduced, but it appears to be somehow connected to phk's header file reorganisation in the ATM code in october. Many of the files miss a include and give a missing prototyp warning for functions like splnet, printf, log, bzero... This appears to be deadly for bzero(), because this is a function pointer now. (I always had the fealing, that the ANSI-C syntax for calling functions through pointers is bad ( fooptr() instead of (*fooptr)()). Now I know why :-( ) Adding a #include to the following files seem to fix the problem: dev/hea/eni_intr.c dev/hea/eni_vcm.c netatm/atm_if.c netatm/atm_signal.c netatm/atm_socket.c netatm/atm_usrreq.c netatm/ipatm/ipatm_event.c netatm/ipatm/ipatm_if.c netatm/ipatm/ipatm_load.c netatm/ipatm/ipatm_output.c netatm/ipatm/ipatm_vcm.c netatm/spans/spans_cls.c netatm/spans/spans_subr.c netatm/uni/sscf_uni.c netatm/uni/sscf_uni_lower.c netatm/uni/sscf_uni_upper.c netatm/uni/sscop.c netatm/uni/sscop_lower.c netatm/uni/sscop_subr.c netatm/uni/sscop_upper.c netatm/uni/uni_load.c netatm/uni/uniarp_input.c netatm/uni/uniarp_output.c netatm/uni/uniarp_vcm.c netatm/uni/unisig_encode.c netatm/uni/unisig_mbuf.c netatm/uni/unisig_msg.c netatm/uni/unisig_print.c netatm/uni/unisig_proto.c netatm/uni/unisig_sigmgr_state.c Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 7:54:40 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 07:54:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizkidtech.net (r39.bfm.org [216.127.220.135]) by hub.freebsd.org (Postfix) with ESMTP id C80AC37B402 for ; Wed, 6 Dec 2000 07:54:35 -0800 (PST) Received: (from adam@localhost) by whizkidtech.net (8.9.2/8.9.2) id JAA00252 for hackers@FreeBSD.org; Wed, 6 Dec 2000 09:53:29 -0600 (CST) (envelope-from adam) Date: Wed, 6 Dec 2000 09:53:28 -0600 From: "G. Adam Stanislav" To: hackers@FreeBSD.org Subject: It's all clear now Message-ID: <20001206095328.B228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: Whiz Kid Technomagic X-URL: http://www.whizkidtech.net/ X-Castle: http://www.redprince.net/ X-Special-Effects: http://www.FilmSFX.com/ X-Operating-System: FreeBSD whizkidtech.net 3.1-RELEASE FreeBSD 3.1-RELEASE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to thank everyone who has answered my recent question about memory allocation via mmap. I received many message via private e-mail in addition to those here. One of them sent me to an online sample chapter of one of Stevens' book (Interprocess Communication) which explains mmap. That was exactly what I needed. It's all clear now, plus I ordered the entire book from amazon, and should have it within 3-7 business days. I really appreciate all of the help I received. Cheers, Adam -- "I am the first and only logician in Athens," said the teacher. "If you are the first, how can you be the only?" asked a student. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 8:12:35 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 08:12:34 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id D04DB37B400 for ; Wed, 6 Dec 2000 08:12:25 -0800 (PST) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id RAA30340 for ; Wed, 6 Dec 2000 17:12:17 +0100 (CET) Message-Id: <200012061612.RAA30340@luxren2.boostworks.com> Date: Wed, 6 Dec 2000 17:11:53 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: free() not freing pagedirs pages. To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: root@boostworks.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I'm encountering a problem with the stardard libc malloc/free library. if a program allocates a huge (and temporary) amount of memory with small structures then free it, the library gives back only a few pages to the system. From the /usr/src/lib/libc/stdlib/malloc.c sources, it seems that this is due to not shrinking/relocating pagedir pages (free_pages(), comment around line 940). This means that returning pages stop at first allocated pagedir. It seems to be a problem also in some other Unixes, anyway, but i would like to know if: 1) This is historical and must not be fixed. 2) This can be easily fixed. 3) Fixing it would lead to enormous problems. Better keep it like this. Thanks. RN. IhM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 8:24: 5 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 08:24:02 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 6F8A037B400 for ; Wed, 6 Dec 2000 08:24:01 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB6GNUL51352; Wed, 6 Dec 2000 17:23:30 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: remy@boostworks.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. In-Reply-To: Your message of "Wed, 06 Dec 2000 17:11:53 +0100." <200012061612.RAA30340@luxren2.boostworks.com> Date: Wed, 06 Dec 2000 17:23:30 +0100 Message-ID: <51350.976119810@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012061612.RAA30340@luxren2.boostworks.com>, Remy Nonnenmacher wr ites: >>From the /usr/src/lib/libc/stdlib/malloc.c sources, it seems that this >is due to not shrinking/relocating pagedir pages (free_pages(), comment >around line 940). This means that returning pages stop at first >allocated pagedir. That is actually not correct. the pagedir is allocated with mmap from anonymous memory and does not affect the sbrk(2)'ing. >It seems to be a problem also in some other Unixes, anyway, but i would >like to know if: Presuming your question then is "can the pagedir be shrunk ?" the answers are: >1) This is historical and must not be fixed. no. >2) This can be easily fixed. maybe. >3) Fixing it would lead to enormous problems. Better keep it like this. unlikely. Have you read the paper in src/share/doc/papers/malloc ? Also, if you are truly concerned with the returning to the OS of memory, examine the 'H' option to phkmalloc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 10: 5:48 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 10:05:46 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 61F2D37B400 for ; Wed, 6 Dec 2000 10:05:42 -0800 (PST) Received: from jade (jade.cs.binghamton.edu [128.226.140.161]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id NAA20878 for ; Wed, 6 Dec 2000 13:05:41 -0500 (EST) Date: Wed, 6 Dec 2000 13:04:36 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@jade To: freebsd-hackers@freebsd.org Subject: ptrace(PT_GETDBREGS) message in remote debugging 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 tried remote debugging on FreeBSD 4.2 this morning. Everything was fine, except that I saw the following messages: (gdb) step ptrace(PT_GETDBREGS) failed: No such process ptrace(PT_GETDBREGS) failed: No such process ptrace(PT_GETDBREGS) failed: No such process 201 cred = p ? p->p_ucred : NOCRED; This ptrace stuff never appear before. Is this a new feature or was I doing something wrong? Any help is appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 11: 6:52 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 11:06:51 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 1B54237B401 for ; Wed, 6 Dec 2000 11:06:51 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB6J5XV96902; Wed, 6 Dec 2000 11:05:33 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Dec 2000 11:05:33 -0800 (PST) From: Matt Dillon Message-Id: <200012061905.eB6J5XV96902@earth.backplane.com> To: News History File User Cc: hackers@freebsd.org, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> <200012060713.eB67D8I91529@earth.backplane.com> <200012061355.eB6DtGS34255@crotchety.newsbastards.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Excellent. What I believe is going on is that without the madvise()/mlock() the general accesses to the 1 GB main history file are causing the pages to be flushed from the .hash and .index files too quickly. The performance problems in general appear to be due to the system trying to cache more of the (essentially uncacheable) main history file at the expense of not caching as much of the (emminently cacheable) .index and .hash files. One possible fix would be to have the kernel track cache hits and misses on a file and implement a heuristic from those statistics which is used to reduce the 'initial page weighting' for pages read-in from the 'generally uncacheable file'. This would cause the kernel to reuse those cache pages more quickly and prevent it from throwing away (reusing) cache pages associated with more cacheable files like the .index and .hash files. I don't have time to do this now, but it's definitely something I am going to keep in mind for a later release. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 11: 9:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 11:09:34 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 406BA37B400 for ; Wed, 6 Dec 2000 11:09:32 -0800 (PST) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id UAA31917; Wed, 6 Dec 2000 20:07:30 +0100 (CET) Message-Id: <200012061907.UAA31917@luxren2.boostworks.com> Date: Wed, 6 Dec 2000 20:07:07 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: free() not freing pagedirs pages. To: phk@critter.freebsd.dk Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <51350.976119810@critter> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: root@boostworks.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. In fact my problem was just a printf that allocated a buffer via __smakebuf at the very last moment (when all memory was allocated). This prevent free() to give back all previous pages up to this one. The problem was _not_ in malloc.c. Anyway, i learned a lot from hacking the source to catch the caller. Thanks. RN. IhM On 6 Dec, Poul-Henning Kamp wrote: > In message <200012061612.RAA30340@luxren2.boostworks.com>, Remy Nonnenmacher wr > ites: > >>>From the /usr/src/lib/libc/stdlib/malloc.c sources, it seems that this >>is due to not shrinking/relocating pagedir pages (free_pages(), comment >>around line 940). This means that returning pages stop at first >>allocated pagedir. > > That is actually not correct. the pagedir is allocated with mmap > from anonymous memory and does not affect the sbrk(2)'ing. > >>It seems to be a problem also in some other Unixes, anyway, but i would >>like to know if: > > Presuming your question then is "can the pagedir be shrunk ?" the > answers are: > >>1) This is historical and must not be fixed. > > no. > >>2) This can be easily fixed. > > maybe. > >>3) Fixing it would lead to enormous problems. Better keep it like this. > > unlikely. > > Have you read the paper in src/share/doc/papers/malloc ? > > Also, if you are truly concerned with the returning to the OS of > memory, examine the 'H' option to phkmalloc. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 11:23:52 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 11:23:51 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 9077337B400 for ; Wed, 6 Dec 2000 11:23:50 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB6JNlL52720; Wed, 6 Dec 2000 20:23:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: remy@boostworks.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. In-Reply-To: Your message of "Wed, 06 Dec 2000 20:07:07 +0100." <200012061907.UAA31917@luxren2.boostworks.com> Date: Wed, 06 Dec 2000 20:23:47 +0100 Message-ID: <52718.976130627@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012061907.UAA31917@luxren2.boostworks.com>, Remy Nonnenmacher wr ites: >OK. In fact my problem was just a printf that allocated a buffer via >__smakebuf at the very last moment (when all memory was allocated). >This prevent free() to give back all previous pages up to this one. The >problem was _not_ in malloc.c. > >Anyway, i learned a lot from hacking the source to catch the caller. >Thanks. Yeah, I often find a "print a traceback" function missing in libc... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 11:54:57 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 11:54:55 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 746EC37B400 for ; Wed, 6 Dec 2000 11:54:39 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eB6JsTD22959 for hackers@freebsd.org; Wed, 6 Dec 2000 21:54:29 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200012061954.eB6JsTD22959@zibbi.icomtek.csir.co.za> Subject: Support for Syba pci multi i/o card? To: hackers@freebsd.org Date: Wed, 6 Dec 2000 21:54:29 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: jhay@zibbi.icomtek.csir.co.za Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know of patches or something to support these cards? The cards that I have is by Syba Tech and is a 4 x serial and 2 x parallel port pci card. It has 2 winbond W83877TF 2 x serial + 1 x parallel port "superio" chips and some pci glue. The card has 0x400 bytes of io space, as big as the isa io area. Also from what I understand they all share one interrupt. FreeBSD probes it like this: found-> vendor=0x1592, dev=0x0781, revid=0x92 bus=0, slot=8, func=0 class=07-81-15, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=15 map[10]: type 4, range 32, base 00006000, size 10, enabled If there aren't any patches I might look at adding support for it. Probably only the serial ports, because that is what I need. I would like some advice on how to do it though. I had a look at the sio driver and it has support for a few pci cards, but it looks like they are single serial port cards and not dual or quad. So how should I go about getting the sio probe and attach to do more than one serial port per pci card? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 13:28:51 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 13:28:48 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 3615837B400 for ; Wed, 6 Dec 2000 13:28:48 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 143mAB-0000LH-00; Wed, 06 Dec 2000 14:31:43 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A2EB03F.8D9105A8@softweyr.com> Date: Wed, 06 Dec 2000 14:31:43 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "G. Adam Stanislav" Cc: Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "G. Adam Stanislav" wrote: > > On Mon, Dec 04, 2000 at 12:56:51PM +1000, Stephen McKay wrote: > >Using pipes for temporary storage is still a crazy idea. Pipes can be > >smaller than 8K, depending on the flavour of Unix. > > It was just a thought, and it did not work. :) Other flavors of Unix > are not too important in this case: I'm writing a FreeBSD assembly > language tutorial. Though I do discuss portability issues in it. > I'm writing the tutorial, not because I'm the expert (I am, on assembly > language, but not on Unix system calls--yet), but because, in my > experience, it is the best way to learn. > > > Use malloc() instead. > > Unfortunately, that only works in C. :) You are, of course, wrong here. You can (and should) link your assembly programs with the C library -- half the power of UNIX is in the libraries. You can call all of the library functions just fine, as long as you under- stand the calling conventions. > I tried to figure out how to allocate memory, but, so far, was completely > unsuccessful. I studied the source for the C malloc, but did not understand > any of it. It uses something called mmap. I read the man page for mmap, > and was totally frustrated. It talks about mapping files into memory, > but I am not looking for files. It talks about passing an address to the > function. I don't get it... What address? I want it to allocate memory > for me and tell me its address. How am I supposed to know what address > is available??? If you pass it NULL as the address, mmap will select an address for you. If you just want to allocate some memory, mmap /dev/null MAP_PRIVATE. You need to read the man pages and the malloc code more carefully. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 13:40:31 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 13:40:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id DA11337B6A2 for ; Wed, 6 Dec 2000 13:40:24 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB6LdkE99051; Wed, 6 Dec 2000 13:39:46 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Dec 2000 13:39:46 -0800 (PST) From: Matt Dillon Message-Id: <200012062139.eB6LdkE99051@earth.backplane.com> To: Remy Nonnenmacher Cc: phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012061907.UAA31917@luxren2.boostworks.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :OK. In fact my problem was just a printf that allocated a buffer via :__smakebuf at the very last moment (when all memory was allocated). :This prevent free() to give back all previous pages up to this one. The :problem was _not_ in malloc.c. : :Anyway, i learned a lot from hacking the source to catch the caller. :Thanks. : :RN. :IhM Not to mention library routines which might malloc() something and keep it around. I find that the best way to allocate a large chunk of memory is to use mmap( ... MAP_ANON ... ). That way you have complete control over the memory. You need only page-align the request size (getpagesize() helps there). You can then manage the memory with madvise(), and free it completely with munmap(). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 14:12:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 14:12:19 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spot.fool.com (spot.fool.com [208.241.66.9]) by hub.freebsd.org (Postfix) with SMTP id E72D637B400 for ; Wed, 6 Dec 2000 14:12:18 -0800 (PST) Received: by SPOT with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 17:12:18 -0500 Message-ID: <13CDDE6A53DBD311BC3200508B6F0C480219308A@rover.foolhq.com> From: Michael Chong To: "'hackers@FreeBSD.ORG'" Subject: Date: Wed, 6 Dec 2000 17:12:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a question about FreeBSD...is it possible to set acl's on commands? (eg..giving one specific user the abiltity to execute a command w/o putting them in a group) I'm talking about something like this: http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html. Can we do something like this with FreeBSD? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 15:36:53 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 15:36:52 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.getrelevant.com (mail.getrelevant.com [63.211.149.12]) by hub.freebsd.org (Postfix) with ESMTP id 2337337B400 for ; Wed, 6 Dec 2000 15:36:48 -0800 (PST) Received: from khmere.com ([63.211.149.44]) by mail.getrelevant.com (Lotus Domino Release 5.0.5) with ESMTP id 2000120615341077:79640 ; Wed, 6 Dec 2000 15:34:10 -0800 Sender: nathan@FreeBSD.ORG Message-ID: <3A2ECD7A.1E6A1FF3@khmere.com> Date: Wed, 06 Dec 2000 15:36:26 -0800 From: Nathan Boeger Organization: Getrelevant X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-hackers@FreeBSD.ORG" Subject: 4.2-RELEASE will not boot after install ? X-MIMETrack: Itemize by SMTP Server on notes/GetRelevant(Release 5.0.5 |September 22, 2000) at 12/06/2000 03:34:10 PM, Serialize by Router on notes/GetRelevant(Release 5.0.5 |September 22, 2000) at 12/06/2000 03:34:15 PM, Serialize complete at 12/06/2000 03:34:15 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don't know if I should post here but.... I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install went without a hich. Then when I rebooted, the box just stopped. It seemed like it could not read the mbr. So I booted again off the floppies and I used the loader to switched the currdev to the harddrive (disk1s1a) it found the hardrive. I then loaded the kernel from the harddrive and booted off the harddrive. After I was up on the box I then ran disklabel -B ad0 and thought that maybe the installation did not add the boot reccord info. Rebooted agian to have the same problem as before. I then tried it agian with the flags for the boot code, no luck. Finally I dd out the first 512 blocks of the harddrive and ran strings on it. Seems that thier was nothing their ! so I was lucky enough to have another 4.2 box and I just copied its first 512 blocks. Now it boots fine ! Is their a known issue with this ? or maybe I did something wrong ? thank you nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 16: 6:49 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 16:06:47 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mailhub.iastate.edu (mailhub.iastate.edu [129.186.1.102]) by hub.freebsd.org (Postfix) with ESMTP id C7F7E37B400 for ; Wed, 6 Dec 2000 16:06:46 -0800 (PST) Received: from iastate.edu ([129.186.232.231]) by mailhub.iastate.edu (8.9.3/8.9.3) with ESMTP id SAA18830 for ; Wed, 6 Dec 2000 18:06:46 -0600 Sender: ccsanady@iastate.edu Message-ID: <3A2ED495.397B46A3@iastate.edu> Date: Thu, 07 Dec 2000 00:06:46 +0000 From: Chris X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: PAM issues.. 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 have been writing a PAM module to do Kerberos 5 and AFS stuff, and have run across a couple of problems. First of all, the simple one. :) How do you set or modify an environment variable? Neither setenv, pam_misc_setenv, or pam_putenv seem to be work. From what I gather from the pam_ssh module, there may be issues with where the environment is located, but they are not terribly clear to me. The next is pam_setcred(). I've noticed that this is not actually called from login/etc, so it doesn't do much good. Is this intentional? Not that it matters much, for anything other than compatibility with other modules. Also, are there any thoughts on session support? It seems like it would be pretty trivial to have login hang around to execute these hooks. Most any other method of logging in (ssh, xdm, etc) already provides a context to do this from. What is the thought on keeping login around? I would be willing to try to fix the last two, but I'm not sure what to do with the first. Any ideas as to that problem would be welcome. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 16:42:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 16:42:14 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 156B137B400 for ; Wed, 6 Dec 2000 16:42:13 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id eB70gAW36778; Wed, 6 Dec 2000 19:42:11 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id eB70g9d03226; Wed, 6 Dec 2000 19:42:10 -0500 (EST) (envelope-from bsd) Date: Wed, 6 Dec 2000 19:42:09 -0500 From: Brian Dean To: Zhiui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ptrace(PT_GETDBREGS) message in remote debugging Message-ID: <20001206194209.B94389@vger.bsdhome.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Wed, Dec 06, 2000 at 01:04:36PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 06, 2000 at 01:04:36PM -0500, Zhiui Zhang wrote: > I tried remote debugging on FreeBSD 4.2 this morning. Everything was > fine, except that I saw the following messages: > > (gdb) step > ptrace(PT_GETDBREGS) failed: No such process > ptrace(PT_GETDBREGS) failed: No such process > ptrace(PT_GETDBREGS) failed: No such process > 201 cred = p ? p->p_ucred : NOCRED; > > This ptrace stuff never appear before. Is this a new feature or was I > doing something wrong? > > Any help is appreciated. You're not doing anything wrong, and this is a new feature. The problem is that gdb is trying to load the debug registers for its target process, except that it doesn't realize that it's a remote target. In looking through the GDB code, its not at all obvious to me how to determine this fact, except maybe by checking inferior_pid against MAGIC_NULL_PID, but that is defined local to remote.c only. The following patch below simply checks the return code from ptrace() and doesn't complain of the pid is not found, making the assumption that if the pid is not found, it must be a remote target. Whether or not this is a valid assumption or not in all cases, I'm not sure. The patch is against -STABLE, but I don't think this has diverged any from -CURRENT. Give this a try and let me know. -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com Index: freebsd-nat.c =================================================================== RCS file: /usr00/FreeBSD/mirror/ncvs/src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c,v retrieving revision 1.21.4.2 diff -u -r1.21.4.2 freebsd-nat.c --- freebsd-nat.c 2000/08/22 12:28:19 1.21.4.2 +++ freebsd-nat.c 2000/12/07 00:31:52 @@ -478,14 +478,16 @@ { struct dbreg dbr; extern int inferior_pid; - + if (inferior_pid != 0 && core_bfd == NULL) { int pid = inferior_pid & ((1 << 17) - 1); /* XXX extract pid from tid */ - + if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); return 0; } #if WATCHPOINT_DEBUG > 1 @@ -520,7 +522,10 @@ if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); + return 0; } @@ -615,7 +620,9 @@ if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) { - perror("ptrace(PT_GETDBREGS) failed"); + /* don't complain on ESRCH, assume we are debugging a remote target */ + if (errno != ESRCH) + perror("ptrace(PT_GETDBREGS) failed"); return 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 17: 3:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 17:03:28 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1C79837B400 for ; Wed, 6 Dec 2000 17:03:27 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB713Ps38233; Wed, 6 Dec 2000 18:03:26 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA83207; Wed, 6 Dec 2000 18:03:22 -0700 (MST) Message-Id: <200012070103.SAA83207@harmony.village.org> To: John Hay Subject: Re: Support for Syba pci multi i/o card? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 06 Dec 2000 21:54:29 +0200." <200012061954.eB6JsTD22959@zibbi.icomtek.csir.co.za> References: <200012061954.eB6JsTD22959@zibbi.icomtek.csir.co.za> Date: Wed, 06 Dec 2000 18:03:22 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012061954.eB6JsTD22959@zibbi.icomtek.csir.co.za> John Hay writes: : Does anyone know of patches or something to support these cards? The cards : that I have is by Syba Tech and is a 4 x serial and 2 x parallel port pci : card. It has 2 winbond W83877TF 2 x serial + 1 x parallel port "superio" : chips and some pci glue. The card has 0x400 bytes of io space, as big as : the isa io area. Also from what I understand they all share one interrupt. I have some really bad patches for a similar card. : If there aren't any patches I might look at adding support for it. Probably : only the serial ports, because that is what I need. I would like some advice : on how to do it though. I had a look at the sio driver and it has support : for a few pci cards, but it looks like they are single serial port cards : and not dual or quad. So how should I go about getting the sio probe and : attach to do more than one serial port per pci card? I'm not sure this is the right way to do that. I believe that the right way is to create an attachment for this that attaches N devices. I had some preliminary code that did this, but it has decayed too much so I lost it. Basically: pci0 --- multi-io0 +--- sio0 +--- sio1 +--- sio2 +--- sio3 +--- ppc0 is what I had in mind. Multi-io would register an interrupt and dispatch it to the interrupt to each of the sub devices as necessary. There are other cards like this that also have an extra interrupt register that says which sub device interrupted. I also think that the isa sio multi-port cards should be handled in a similar way. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 18: 7:22 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 18:07:20 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id EEAC837B400 for ; Wed, 6 Dec 2000 18:07:18 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id eB727C506188; Wed, 6 Dec 2000 21:07:13 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200012070207.eB727C506188@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Nathan Boeger Cc: "freebsd-hackers@FreeBSD.ORG" X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: 4.2-RELEASE will not boot after install ? References: <3A2ECD7A.1E6A1FF3@khmere.com> In-reply-to: Your message of "Wed, 06 Dec 2000 15:36:26 PST." <3A2ECD7A.1E6A1FF3@khmere.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 2000 21:07:12 -0500 Sender: louie@TransSys.COM Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had the same problem on an old PPro box. The BIOS seemingly doesn't like the new (2 sector long) boot manager. If you fire up sysinstall again, and tell it to install the "standard bootblocks" (forgot the exact phrase), rather than the boot manager, you'll probably be OK. louie > Don't know if I should post here but.... > > I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install > went without a hich. Then when I rebooted, the box just stopped. It > seemed like it could not read the mbr. So I booted again off the > floppies and I used the loader to switched the currdev to the harddrive > (disk1s1a) it found the hardrive. I then loaded the kernel from the > harddrive and booted off the harddrive. After I was up on the box I then > ran disklabel -B ad0 and thought that maybe the installation did not add > the boot reccord info. Rebooted agian to have the same problem as > before. I then tried it agian with the flags for the boot code, no > luck. Finally I dd out the first 512 blocks of the harddrive and ran > strings on it. Seems that thier was nothing their ! so I was lucky > enough to have another 4.2 box and I just copied its first 512 blocks. > Now it boots fine ! > > Is their a known issue with this ? or maybe I did something wrong ? > > thank you > > nathan > > > > 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 Dec 6 18:14:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 18:14:39 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 4F00937B400 for ; Wed, 6 Dec 2000 18:14:39 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 61C76193E1; Wed, 6 Dec 2000 20:14:38 -0600 (CST) Date: Wed, 6 Dec 2000 20:14:38 -0600 From: "Jacques A. Vidrine" To: Chris Cc: freebsd-hackers@freebsd.org Subject: Re: PAM issues.. Message-ID: <20001206201438.B64751@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Chris , freebsd-hackers@freebsd.org References: <3A2ED495.397B46A3@iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A2ED495.397B46A3@iastate.edu>; from ccsanady@iastate.edu on Thu, Dec 07, 2000 at 12:06:46AM +0000 X-Url: http://www.nectar.com/ Sender: nectar@nectar.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 12:06:46AM +0000, Chris wrote: > Hi, I have been writing a PAM module to do Kerberos 5 and AFS stuff, and > have run across a couple of problems. Have you looked at ports/security/pam_krb5, by the way? This does Kerberos 5, but not AFS. > The next is pam_setcred(). I've noticed that this is not actually > called from login/etc, so it doesn't do much good. Is this > intentional? Not that it matters much, for anything other than > compatibility with other modules. Patching login et. al. to call pam_setcred is trivial. The only reason I haven't done so yet is because pam_setcred is all but useless. :-) I'm enclosing a previous message that I sent to the FreeBSD PAM maintainer (ok well it went to jdp first and then later to markm) to explain more fully. None of us have had time to address it yet, and this appears to be a bug in Linux-PAM (which is the implementation we use). Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org Date: Mon, 6 Nov 2000 12:51:46 -0600 From: "Jacques A. Vidrine" To: jdp@polstra.com Subject: pam_setcred in login.c Hi John, You look like the PAM maintainer. Can I commit the following to src/usr.bin/login.c (actually, the below patch is for -STABLE but I mean to commit the equivalent to -CURRENT)? --- login.c.orig Fri Nov 3 21:12:40 2000 +++ login.c Mon Nov 6 12:00:46 2000 @@ -714,6 +714,9 @@ } else syslog(LOG_ERR, "Couldn't get PAM_USER: %s", pam_strerror(pamh, e)); + if ((e = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) + syslog(LOG_ERR, "Couldn't establish credentials: %s", + pam_strerror(pamh, e)); rval = 0; break; By the way, is it just me, or is pam_setcred broken? For example, with the following config file: login auth sufficient pam_skey.so login auth sufficient pam_krb5.so login auth required pam_unix.so Regardless of whether you authenticate with `skey', `krb5', or `unix', pam_sm_setcred is called in pam_skey.so, i.e. the search starts over. By my reading of the Solaris man page, pam_sm_setcred should be called in the module that successfully authenticated the user. At any rate this seems infinitely more useful. Excerpt from Solaris 2.6 pam(3): If the user has been successfully authenticated, the application calls pam_setcred() to set any user credentials associated with the authentication service. [...] For example, during the call to pam_authenticate(), service modules may store data in the handle that is intended for use by pam_setcred(). Just looking for a sanity check... Thanks! -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 18:45:36 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 18:45:34 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gw.carpoolbc.com (cr45465-a.abtsfd1.bc.wave.home.com [24.113.176.126]) by hub.freebsd.org (Postfix) with ESMTP id AAAF037B400 for ; Wed, 6 Dec 2000 18:45:30 -0800 (PST) Received: from localhost (roop@localhost) by gw.carpoolbc.com (8.11.1/8.9.3) with ESMTP id eB72kG603765; Wed, 6 Dec 2000 18:46:17 -0800 (PST) (envelope-from roop@gw.carpoolbc.com) Date: Wed, 6 Dec 2000 18:46:16 -0800 (PST) From: Roop Nanuwa To: Michael Chong Cc: "'hackers@FreeBSD.ORG'" Subject: Re: your mail In-Reply-To: <13CDDE6A53DBD311BC3200508B6F0C480219308A@rover.foolhq.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 think what you're looking for is something similar (or exactly like) 'sudo'.. You can get it under your ports tree: /usr/ports/security/sudo/ Or on-line: www.freebsd.org/ports/security.html RSN On Wed, 6 Dec 2000, Michael Chong wrote: > I have a question about FreeBSD...is it possible to set acl's on commands? > (eg..giving one specific user the abiltity to execute a command w/o putting > them in a group) I'm talking about something like this: > http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html. Can we do > something like this with FreeBSD? > > > > > > 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 Dec 6 19:52:51 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 19:52:50 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hightemplar.com (alex.telmap.com [192.116.157.233]) by hub.freebsd.org (Postfix) with ESMTP id 1DA9437B401 for ; Wed, 6 Dec 2000 19:52:49 -0800 (PST) Received: from freenet.co.uk (alex@hightemplar.com [127.0.0.1]) by hightemplar.com (8.11.1/8.11.1) with ESMTP id eB73qW022214; Thu, 7 Dec 2000 05:52:41 +0200 (IST) (envelope-from ak@freenet.co.uk) Sender: alex@hightemplar.com Message-ID: <3A2F097F.15D592DD@freenet.co.uk> Date: Thu, 07 Dec 2000 05:52:31 +0200 From: A G F Keahan X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Optimal UFS parameters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What parameters should I choose for a large (say, 60 or 80Gb) filesystem? I remember a while ago someone (phk?) conducted a survey, but nothing seems to have come of it. In the meantime, the capacity of an average hard drive has increased tenfold, and the defaults have become even less reasonable. What's the current consensus of opinion? newfs -b ????? -f ????? -c ????? Thanks Alex Keahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 20: 0:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 20:00:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (dhcp245.osd.bsdi.com [204.216.28.245]) by hub.freebsd.org (Postfix) with ESMTP id 42EC637B401 for ; Wed, 6 Dec 2000 20:00:29 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB749gF07307 for ; Wed, 6 Dec 2000 20:09:42 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012070409.eB749gF07307@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: hackers@freebsd.org Subject: HEADS UP - PCI code changes, review requested Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 2000 20:09:42 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As people may have noticed, I've been working on a cleanup of parts of our PCI subsystem. The next round of changes are ready for review. In summary, the changes: - Break out our bridge support into separate PCI:PCI, PCI:EISA and PCI:ISA modules. - Move all PCI core code into sys/dev/pci. - Add interrupt routing support for the Alpha platform. - Remove description strings for PCI infrastructure components from the PCI code. (pciconf now has a better database). A diff against -current is at http://people.freebsd.org/~msmith/pci.diff, comments are very much welcome. Note in particular for the Alpha folks - support is not yet in place for PCI:PCI bridges with nonstandard interrupt routing, I think I know how to do this fairly cleanly though (but I only just realised it was a problem, whoops). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 20:39:45 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 20:39:40 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id D357B37B400; Wed, 6 Dec 2000 20:39:39 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB74ddE69221; Wed, 6 Dec 2000 20:39:39 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Dec 2000 20:39:39 -0800 (PST) From: Matt Dillon Message-Id: <200012070439.eB74ddE69221@earth.backplane.com> To: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader References: <200012070203.eB7231C44996@earth.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ah ha! I think I found the culprit, but I'm not sure exactly where in the tftp code the problem is occuring. I have been setting LOADER_TFTP_SUPPORT in /etc/make.conf so my pxeboot file uses tftp to get the kernel rather then NFS (since NFS appears to only be able to get [rootfs]:/kernel, which is the wrong kernel for a diskless boot). The option works wonderfully for /boot/pxeboot. But it turns out that the normal /boot/loader, when compiled with the above option, will crash horribly whenever it tries to open() a file and can't find it in the UFS filesystem on disk... it falls through the filesystem list until it hits the tftp FS and BEWM. Explosion. I sure would appreciate it if one of the bootstrap gurus could take a look at what happens when the tftp open routine is called from a normal disk-based /boot/loader! -Matt : I've experimented a bit more. If I do an installworld and reboot, : the machine crashes in one of two ways (randomly): : : #1 Crashes with a BTX error : : int 5 err 0 efl 00010206 eip 00000012 : eax 00000039 ebx 00023920 ecx 00023934 edx 00000000 : esi 00000000 edi 0000000c ebp 000943c8 esp 000943cc : cs 002b ds 0033 es 0033 fs 0033 gs 0033 ss 0033 : cs:eip 62 00 00 00 e8 05 04 00 00 90 31 c0 cd 30 58 01 : ss:esp 1c 8a 01 00 00 00 00 00 6c 44 09 00 1a 00 00 00 : : #2 Loader has all sorts of 'can't find file BLAH' errors, stack undeflow : errors, and winds up at an 'ok ' prompt. : : Trying to run commands from the prompt sometimes work, sometimes return : a 'stack underflow' error. : : -- : : That's with the latest -stable /boot/loader. : : If I take that machine and net-boot it, then mount / and copy a : /boot/loader from March 20th, then reboot the machine, the machine : now boots just fine. : : If I put the -stable /boot/loader back into /boot, the machine dies. : If I put the March 20th /boot/loader in, the machine boots just fine. : : Anybody have any ideas? What happened to /boot/loader between March : and now? I am at a loss. : : -r-xr-xr-x 1 root wheel 163840 Dec 6 17:33 loader.NEW : -r-xr-xr-x 1 root wheel 143360 Dec 6 17:47 loader.OLD : : -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 20:48:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 20:48:33 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 78B9637B402 for ; Wed, 6 Dec 2000 20:48:33 -0800 (PST) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id VAA12874; Wed, 06 Dec 2000 21:48:28 -0700 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 06 Dec 2000 21:48:30 -0700 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id ; Wed, 6 Dec 2000 21:48:28 -0700 Message-ID: <8D18712B2604D411A6BB009027F644980DD7B4@0SEA01EXSRV1> From: "Matt Simerson" To: "'A G F Keahan'" Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Optimal UFS parameters Date: Wed, 6 Dec 2000 21:47:59 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 1631C914102197-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG That's because any "consensus" would be inappropriate for mass consumtion. It really depends on a lot of fun things like the average file size and the number of files that the drives will be storing. For example, a mail server might want more inodes than a database server. The mail server will likely have a lot of tiny files where the database server would have a collection of much larger (a few k vs several mb's each). What makes you think the defaults are unreasonable? I set up a 300GB filesystem a few months ago. I ran a few numbers, calculated my average file size, compared it to the defaults and found they were very close to reasonable. When I get a couple hundred gig's of data on there I'll know better but I think my guess-timates are very good. Matt > -----Original Message----- > From: A G F Keahan [mailto:ak@freenet.co.uk] > Sent: Wednesday, December 06, 2000 7:53 PM > To: freebsd-hackers@freebsd.org > Subject: Optimal UFS parameters > > What parameters should I choose for a large (say, 60 or 80Gb) > filesystem? I remember a while ago someone (phk?) conducted a survey, > but nothing seems to have come of it. In the meantime, the capacity of > an average hard drive has increased tenfold, and the defaults have > become even less reasonable. > > What's the current consensus of opinion? > > newfs -b ????? -f ????? -c ????? > > Thanks > > Alex Keahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 20:55: 2 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 20:55:00 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.67.48]) by hub.freebsd.org (Postfix) with ESMTP id 22EDD37B401 for ; Wed, 6 Dec 2000 20:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id eB74swt25293 for ; Wed, 6 Dec 2000 23:54:58 -0500 (EST) Date: Wed, 6 Dec 2000 23:54:58 -0500 (EST) From: Alwyn Goodloe To: freebsd-hackers@FreeBSD.org Subject: Router Alert 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 Folks, I need to use Router Alert (rfc2113) (http://www.phys-iasi.ro/Library/RFCs/rfc2113.htm) * Is there any documentation for using Router Alert in the FreeBSD environement. * Are there specific options that the Kernel must be compiled with? * I know in Linux there is a IP_ROUTER_ALERT option that can be applied by Root users to IP sockets to intercept all forwarded packets with the Router Alert option. Does it work similarly for FreeBSD. Alwyn Goodloe agoodloe@gradient.cis.upenn.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 20:59:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 20:59:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from firefly.prairienet.org (firefly.prairienet.org [192.17.3.3]) by hub.freebsd.org (Postfix) with ESMTP id CDF2737B401 for ; Wed, 6 Dec 2000 20:59:29 -0800 (PST) Received: from sherman.spotnet.org (slip-88.prairienet.org [192.17.3.108]) by firefly.prairienet.org (8.9.3/8.9.3) with ESMTP id WAA19568; Wed, 6 Dec 2000 22:59:26 -0600 (CST) Date: Wed, 6 Dec 2000 22:59:24 -0600 (CST) From: David Talkington X-Sender: dtalk@sherman.spotnet.org To: Roop Nanuwa Cc: Michael Chong , "'hackers@FreeBSD.ORG'" Subject: Re: your mail 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 think what you're looking for is something similar (or exactly >like) 'sudo'.. sudo definitely helps if it's carefully administered, but it still grants root access to a file, which may not really be what you want. As a Unix advocate in general, I'm looking forward to seeing how well Sun does this. ACLs are one of the things that NTFS does well, and Unix traditionally doesn't really provide for. In an environment like ours, where we have a plethora of community members and volunteers doing various things on our Solaris system, you quickly discover the limits of sudo's ability to dispense privileges surgically without creating security holes. You can do a lot with carefully configured groups, but as the number of users increases and the system activities become more disparate, this gets complicated... My $.02 -d >On Wed, 6 Dec 2000, Michael Chong wrote: > >> I have a question about FreeBSD...is it possible to set acl's on commands? >> (eg..giving one specific user the abiltity to execute a command w/o putting >> them in a group) I'm talking about something like this: >> http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html. Can we do >> something like this with FreeBSD? >> >> >> >> >> >> 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 Wed Dec 6 21:20:25 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 21:20:23 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.khmere.com (sdsl-216-36-70-194.dsl.sjc.megapath.net [216.36.70.194]) by hub.freebsd.org (Postfix) with ESMTP id 12FF337B400 for ; Wed, 6 Dec 2000 21:20:23 -0800 (PST) Received: from khmere.com (ns2.khmere.com [216.36.70.196]) by ns1.khmere.com (8.11.0/8.8.7) with ESMTP id eB75K1G86655; Wed, 6 Dec 2000 21:20:01 -0800 (PST) Sender: nathan@ns1.khmere.com Message-ID: <3A2F1E0A.BC5ADBC9@khmere.com> Date: Wed, 06 Dec 2000 21:20:10 -0800 From: nathan@khmere.com X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.17 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: 4.2-RELEASE will not boot after install ? References: <3A2ECD7A.1E6A1FF3@khmere.com> <200012070207.eB727C506188@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > I had the same problem on an old PPro box. The BIOS seemingly doesn't > like the new (2 sector long) boot manager. If you fire up sysinstall > again, and tell it to install the "standard bootblocks" (forgot the > exact phrase), rather than the boot manager, you'll probably be OK. > > louie > > > Don't know if I should post here but.... > > > > I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install > > went without a hich. Then when I rebooted, the box just stopped. It > > seemed like it could not read the mbr. So I booted again off the > > floppies and I used the loader to switched the currdev to the harddrive > > (disk1s1a) it found the hardrive. I then loaded the kernel from the > > harddrive and booted off the harddrive. After I was up on the box I then > > ran disklabel -B ad0 and thought that maybe the installation did not add > > the boot reccord info. Rebooted agian to have the same problem as > > before. I then tried it agian with the flags for the boot code, no > > luck. Finally I dd out the first 512 blocks of the harddrive and ran > > strings on it. Seems that thier was nothing their ! so I was lucky > > enough to have another 4.2 box and I just copied its first 512 blocks. > > Now it boots fine ! > > > > Is their a known issue with this ? or maybe I did something wrong ? > > > > thank you > > > > nathan > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message Hey thanks !! I finally got a reply from this list for once :-) (please flames for that !!) I think maybe you are right but I stil don't understand why the mbr was different between my 2 4.2-RELEASE box's ? The one that worked was 4.2 by make world... so maybe it has the left over boot code ? I thought that it gets made and updated with make world ? anyway no big deal, at least if someone else has the problem they can read these posts !! thanks once agian nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 21:41:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 21:41:19 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 7ECFC37B400 for ; Wed, 6 Dec 2000 21:41:17 -0800 (PST) Received: (qmail 47137 invoked by uid 1001); 7 Dec 2000 15:41:08 +1000 X-Posted-By: GBA-Post 2.07 04-Dec-2000 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: Message-Id: Date: Thu, 07 Dec 2000 15:41:08 +1000 From: Greg Black To: David Talkington Cc: Roop Nanuwa , Michael Chong , "'hackers@FreeBSD.ORG'" Subject: sudo [was: Re: your mail] References: In-reply-to: of Wed, 06 Dec 2000 22:59:24 CST Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Talkington wrote: > sudo definitely helps if it's carefully administered, but it still > grants root access to a file, This is wrong -- sudo will grant access with whatever user privileges you wish to grant, maybe root and maybe some other user. It all depends on the way you set it up. It can also allow a selected set of users to run just one command with some specific set of arguments. It is quite a flexible tool, although that comes at a price -- somewhat difficult syntax in the config file for non-trivial tricks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 21:53:59 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 21:53:58 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 3BC5D37B400 for ; Wed, 6 Dec 2000 21:53:58 -0800 (PST) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id eB75rsh13666 for ; Wed, 6 Dec 2000 22:53:55 -0700 Message-Id: <200012070553.eB75rsh13666@chopper.Poohsticks.ORG> To: hackers@FreeBSD.ORG Subject: Re: sudo [was: Re: your mail] In-reply-to: Your message of "Thu, 07 Dec 2000 15:41:08 +1000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13662.976168434.1@chopper.Poohsticks.ORG> Date: Wed, 06 Dec 2000 22:53:54 -0700 From: Drew Eckhardt Sender: drew@chopper.Poohsticks.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , gjb@gbch.net writes: >David Talkington wrote: > >> sudo definitely helps if it's carefully administered, but it still >> grants root access to a file, > >This is wrong -- sudo will grant access with whatever user >privileges you wish to grant, maybe root and maybe some other >user. It all depends on the way you set it up. Unlike a potential ACL solution, sudo also logs which privledged commands were executed when and how, thus letting you know who within the hierchy broke what and how... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 21:54:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 21:54:40 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from firefly.prairienet.org (firefly.prairienet.org [192.17.3.3]) by hub.freebsd.org (Postfix) with ESMTP id 53EF737B400 for ; Wed, 6 Dec 2000 21:54:40 -0800 (PST) Received: from sherman.spotnet.org (slip-43.prairienet.org [192.17.3.63]) by firefly.prairienet.org (8.9.3/8.9.3) with ESMTP id XAA23749; Wed, 6 Dec 2000 23:54:16 -0600 (CST) Date: Wed, 6 Dec 2000 23:54:15 -0600 (CST) From: David Talkington X-Sender: dtalk@sherman.spotnet.org To: Greg Black Cc: Roop Nanuwa , Michael Chong , "'hackers@FreeBSD.ORG'" Subject: Re: sudo [was: Re: your mail] 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 Greg Black wrote: >> sudo definitely helps if it's carefully administered, but it still >> grants root access to a file, > >This is wrong -- sudo will grant access with whatever user >privileges you wish to grant, maybe root and maybe some other >user. It all depends on the way you set it up. Wow, the gaps in my education ... thanks, and apologies. I'll go read some more... -d To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 22:48: 9 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 22:48:06 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id CEF5237B400 for ; Wed, 6 Dec 2000 22:48:05 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB76llo07506; Wed, 6 Dec 2000 22:47:47 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Dec 2000 22:47:47 -0800 (PST) From: Matt Dillon Message-Id: <200012070647.eB76llo07506@earth.backplane.com> To: "Matt Simerson" Cc: "'A G F Keahan'" , "'freebsd-hackers@freebsd.org'" Subject: Re: RE: Optimal UFS parameters References: <8D18712B2604D411A6BB009027F644980DD7B4@0SEA01EXSRV1> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :That's because any "consensus" would be inappropriate for mass consumtion. :It really depends on a lot of fun things like the average file size and the :number of files that the drives will be storing. For example, a mail server :might want more inodes than a database server. The mail server will likely :have a lot of tiny files where the database server would have a collection :of much larger (a few k vs several mb's each). : :What makes you think the defaults are unreasonable? I set up a 300GB :filesystem a few months ago. I ran a few numbers, calculated my average file :size, compared it to the defaults and found they were very close to :reasonable. When I get a couple hundred gig's of data on there I'll know :better but I think my guess-timates are very good. : :Matt : :> -----Original Message----- :> From: A G F Keahan [mailto:ak@freenet.co.uk] :> Sent: Wednesday, December 06, 2000 7:53 PM :> To: freebsd-hackers@freebsd.org :> Subject: Optimal UFS parameters :> :> What parameters should I choose for a large (say, 60 or 80Gb) :> filesystem? I remember a while ago someone (phk?) conducted a survey, :> but nothing seems to have come of it. In the meantime, the capacity of :> an average hard drive has increased tenfold, and the defaults have :> become even less reasonable. :> :> What's the current consensus of opinion? :> :> newfs -b ????? -f ????? -c ????? Well, in general I think the defaults are a little overkill... but that may be a good thing. I don't recall us ever getting more then a handful of complaints about a filesystem running out of inodes. Running out of inodes is really annoying and it is best to avoid it. Still, unless your large partition is being used for something like, oh, /home in a multi-user environment, you can probably optimize the newfs parameters a bit to reduce fsck times and indirect block lookup overhead. The default filesystem parameters are: newfs -f 1024 -b 8192 -i 8192 -c 16 ... If you are not going to have a lot of tiny files I would recommend something like this: newfs -f 2048 -b 16384 -i 16384 -c 32 ... You can play with -c and -i, but for a production system the block size (-b) should be either 8192 (the default), or 16384. The filesystem buffer cache is only tuned well for those two sizes and going larger won't help anyway since the kernel already clusters adjacent blocks. Doubling -i from the default halves the number of inodes available. Doubling the cylinders per group reduces the number of allocation groups. If you reduce the number of groups too much your filesystems will become more prone to fragmentation, so don't go overboard. If you increase the number of bytes/inode (-i) too much the filesystem will not have enough inodes and you will run out. For a general purpose filesystem I would not go above -i 16384 -c 64. If the filesystem is going to house a big database (which has many fewer files), you can use a much larger -i but you still shouldn't go overboard with -c. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Dec 6 22:55:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 6 22:55:12 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 39ED837B400 for ; Wed, 6 Dec 2000 22:55:12 -0800 (PST) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id PAA59970; Thu, 7 Dec 2000 15:54:57 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id PAA82856; Thu, 7 Dec 2000 15:54:57 +0900 (JST) To: agoodloe@gradient.cis.upenn.edu Cc: freebsd-hackers@FreeBSD.org Subject: Re: Router Alert In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001207155457V.kjc@csl.sony.co.jp> Date: Thu, 07 Dec 2000 15:54:57 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alwyn Goodloe wrote: > I need to use Router Alert (rfc2113) > (http://www.phys-iasi.ro/Library/RFCs/rfc2113.htm) > > * Is there any documentation for using Router Alert in the FreeBSD > environement. > * Are there specific options that the Kernel must be compiled with? > * I know in Linux there is a IP_ROUTER_ALERT option that can be applied by > Root users to IP sockets to intercept all forwarded packets with the > Router Alert option. Does it work similarly for FreeBSD. Router alert is supported only in IPv6. Take a look at usr.sbin/{pim6sd,pim6dd} for how to use it. The advanced socket API for IPv6 router alert option is defined in http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-02.txt There's no standard API for IPv4, though. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0: 4: 1 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:03:56 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 9AB0737B400; Thu, 7 Dec 2000 00:03:56 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB78D7F00560; Thu, 7 Dec 2000 00:13:08 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012070813.eB78D7F00560@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matt Dillon Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader In-reply-to: Your message of "Wed, 06 Dec 2000 20:39:39 PST." <200012070439.eB74ddE69221@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 00:13:07 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ah ha! I think I found the culprit, but I'm not sure exactly where > in the tftp code the problem is occuring. > > I have been setting LOADER_TFTP_SUPPORT in /etc/make.conf so my pxeboot > file uses tftp to get the kernel rather then NFS (since NFS appears to > only be able to get [rootfs]:/kernel, which is the wrong kernel for a > diskless boot). This isn't the case; pxeboot will load whichever kernel you've specified in your loader config. > The option works wonderfully for /boot/pxeboot. But it turns out > that the normal /boot/loader, when compiled with the above > option, will crash horribly whenever it tries to open() a file and > can't find it in the UFS filesystem on disk... it falls through the > filesystem list until it hits the tftp FS and BEWM. Explosion. > > I sure would appreciate it if one of the bootstrap gurus could take > a look at what happens when the tftp open routine is called from a > normal disk-based /boot/loader! Probably hits an uninitialised function vector; this would be a good catch for someone looking to learn a bit about the loader and libstand. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0: 5:16 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:05:13 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from isua3.iastate.edu (isua3.iastate.edu [129.186.1.139]) by hub.freebsd.org (Postfix) with ESMTP id 2F86B37B400 for ; Thu, 7 Dec 2000 00:05:13 -0800 (PST) Received: from localhost (ccsanady@localhost) by isua3.iastate.edu (8.8.8/8.8.5) with SMTP id CAA20128; Thu, 7 Dec 2000 02:05:10 -0600 (CST) Message-Id: <200012070805.CAA20128@isua3.iastate.edu> To: "Jacques A. Vidrine" Cc: freebsd-hackers@freebsd.org Subject: Re: PAM issues.. In-reply-to: Your message of Wed, 06 Dec 2000 20:14:38 -0600. <20001206201438.B64751@spawn.nectar.com> Date: Thu, 07 Dec 2000 02:05:10 CST From: Chris Csanady Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Thu, Dec 07, 2000 at 12:06:46AM +0000, Chris wrote: >> Hi, I have been writing a PAM module to do Kerberos 5 and AFS stuff, and >> have run across a couple of problems. > >Have you looked at ports/security/pam_krb5, by the way? This does >Kerberos 5, but not AFS. IIRC, this module will authenticate you, but will not get you tickets. I think this was because the tickets are stored using pam_setcred(), hence my question. I haven't looked at it for a while though--its possible the situation has changed. Anyways, what I have written gets Kerb 5 tickets, converts them to v4, and then adds the token after setting up a PAG. Basically, what the mit aklog does, but it actually compiles and works with our kafs library. >> The next is pam_setcred(). I've noticed that this is not actually >> called from login/etc, so it doesn't do much good. Is this >> intentional? Not that it matters much, for anything other than >> compatibility with other modules. > >Patching login et. al. to call pam_setcred is trivial. The only reason I >haven't done so yet is because pam_setcred is all but useless. :-) I'm >enclosing a previous message that I sent to the FreeBSD PAM maintainer >(ok well it went to jdp first and then later to markm) to explain more >fully. None of us have had time to address it yet, and this appears to >be a bug in Linux-PAM (which is the implementation we use). I figured it was something along these lines. :) I realize the pam_setcred is about useless, but it would be nice to have session support. Anyways, thanks for the pointer. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:12:38 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:12:36 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 4122937B400 for ; Thu, 7 Dec 2000 00:12:35 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB78CVL58938; Thu, 7 Dec 2000 09:12:31 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: A G F Keahan Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: Your message of "Thu, 07 Dec 2000 05:52:31 +0200." <3A2F097F.15D592DD@freenet.co.uk> Date: Thu, 07 Dec 2000 09:12:30 +0100 Message-ID: <58936.976176750@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A2F097F.15D592DD@freenet.co.uk>, A G F Keahan writes: >What parameters should I choose for a large (say, 60 or 80Gb) >filesystem? I remember a while ago someone (phk?) conducted a survey, >but nothing seems to have come of it. In the meantime, the capacity of >an average hard drive has increased tenfold, and the defaults have >become even less reasonable. > >What's the current consensus of opinion? > >newfs -b ????? -f ????? -c ????? Right now I tend to use: -b 16384 -f 4096 -c 159 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:19:28 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:19:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AB58F37B400 for ; Thu, 7 Dec 2000 00:19:25 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB78HFF26874; Thu, 7 Dec 2000 00:17:15 -0800 (PST) Date: Thu, 7 Dec 2000 00:17:15 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters Message-ID: <20001207001715.I16205@fw.wintelcom.net> References: <3A2F097F.15D592DD@freenet.co.uk> <58936.976176750@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <58936.976176750@critter>; from phk@critter.freebsd.dk on Thu, Dec 07, 2000 at 09:12:30AM +0100 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [001207 00:12] wrote: > In message <3A2F097F.15D592DD@freenet.co.uk>, A G F Keahan writes: > >What parameters should I choose for a large (say, 60 or 80Gb) > >filesystem? I remember a while ago someone (phk?) conducted a survey, > >but nothing seems to have come of it. In the meantime, the capacity of > >an average hard drive has increased tenfold, and the defaults have > >become even less reasonable. > > > >What's the current consensus of opinion? > > > >newfs -b ????? -f ????? -c ????? > > Right now I tend to use: > > -b 16384 -f 4096 -c 159 I know you're pretty busy, but any chance of getting this into sysinstall? Maybe hindged on the size of the partition? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:24:12 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:24:09 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 90A2C37B400 for ; Thu, 7 Dec 2000 00:24:09 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB78O0507941; Thu, 7 Dec 2000 00:24:00 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 00:24:00 -0800 (PST) From: Matt Dillon Message-Id: <200012070824.eB78O0507941@earth.backplane.com> To: Alfred Perlstein Cc: Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <3A2F097F.15D592DD@freenet.co.uk> <58936.976176750@critter> <20001207001715.I16205@fw.wintelcom.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> Right now I tend to use: :> :> -b 16384 -f 4096 -c 159 : :I know you're pretty busy, but any chance of getting this into :sysinstall? Maybe hindged on the size of the partition? : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] :"I have the heart of a child; I keep it in a jar on my desk." It would be nice to up the default cylinders/group in sysinstall for larger partitions (anything over 8GB). I wouldn't up it to 159 as a default, but 32 would be a whole lot better then the current default 16, especially for fsck times. I think the default fragment/block should still be 1K/8K, even though I use 2K/16K on my own partitions. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:24:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:24:18 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 5EB3037B401 for ; Thu, 7 Dec 2000 00:24:18 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB78LeQ07926; Thu, 7 Dec 2000 00:21:40 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 00:21:40 -0800 (PST) From: Matt Dillon Message-Id: <200012070821.eB78LeQ07926@earth.backplane.com> To: Poul-Henning Kamp Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <58936.976176750@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message <3A2F097F.15D592DD@freenet.co.uk>, A G F Keahan writes: :>What parameters should I choose for a large (say, 60 or 80Gb) :>filesystem? I remember a while ago someone (phk?) conducted a survey, :>but nothing seems to have come of it. In the meantime, the capacity of :>an average hard drive has increased tenfold, and the defaults have :>become even less reasonable. :> :>What's the current consensus of opinion? :> :>newfs -b ????? -f ????? -c ????? : :Right now I tend to use: : : -b 16384 -f 4096 -c 159 : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 I think Bruce swears by 4K (page-sized) fragments. Not a bad way to go. I use 2K because I (and others) put in so much hard work to fix all the little niggling bugs in the VM system related to partial page validation and, damn it, I intend to use those features! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:24:53 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:24:50 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 1E9E037B400 for ; Thu, 7 Dec 2000 00:24:49 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB78OgL59296; Thu, 7 Dec 2000 09:24:42 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: Your message of "Thu, 07 Dec 2000 00:17:15 PST." <20001207001715.I16205@fw.wintelcom.net> Date: Thu, 07 Dec 2000 09:24:41 +0100 Message-ID: <59294.976177481@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001207001715.I16205@fw.wintelcom.net>, Alfred Perlstein writes: >> Right now I tend to use: >> >> -b 16384 -f 4096 -c 159 > >I know you're pretty busy, but any chance of getting this into >sysinstall? Maybe hindged on the size of the partition? sysinstall supports you changing the args to newfs, it has for a long time. The default lives in the options screen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:33:12 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:33:09 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 15AD337B400 for ; Thu, 7 Dec 2000 00:33:09 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB78V0027309; Thu, 7 Dec 2000 00:31:00 -0800 (PST) Date: Thu, 7 Dec 2000 00:31:00 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters Message-ID: <20001207003100.J16205@fw.wintelcom.net> References: <20001207001715.I16205@fw.wintelcom.net> <59294.976177481@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <59294.976177481@critter>; from phk@critter.freebsd.dk on Thu, Dec 07, 2000 at 09:24:41AM +0100 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [001207 00:25] wrote: > In message <20001207001715.I16205@fw.wintelcom.net>, Alfred Perlstein writes: > > >> Right now I tend to use: > >> > >> -b 16384 -f 4096 -c 159 > > > >I know you're pretty busy, but any chance of getting this into > >sysinstall? Maybe hindged on the size of the partition? > > sysinstall supports you changing the args to newfs, it has for > a long time. The default lives in the options screen. I know that, I meant making it automagically scale as Matt suggested. I'd do it, but I don't really have a grasp on the optimal parameters to set based on FS size. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:37:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:37:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iservern.teligent.se (mail.teligent.se [194.17.198.3]) by hub.freebsd.org (Postfix) with ESMTP id 066BC37B401 for ; Thu, 7 Dec 2000 00:37:38 -0800 (PST) Received: from blackice (dyn-office-107.teligent.se [172.18.0.107]) by iservern.teligent.se (8.8.7/8.8.7) with SMTP id JAA03561 for ; Thu, 7 Dec 2000 09:37:31 +0100 (CET) (envelope-from wille@teligent.se) Reply-To: From: "William Carlsson - Teligent Nordic, AB - Sweden" To: Subject: Shared Memory Date: Thu, 7 Dec 2000 09:32:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: High Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Could anyone enlighten me on how to set the amount of shared memory? I'd like that info for FreeBSD 2.2.2, 3.x, 4.x Thanks... ---------------------------------------------------- William Carlsson Second Line Support Teligent Nordic AB P.O. Box 213 S-149 21 Nynäshamn SWEDEN Telephone: +46 - 8 - 59 99 11 92 eMail: william.carlsson@teligent.se http://www.teligent.se ---------------------------------------------------- "And then it comes to be that the soothing light at the end of your tunnel was just a freight train, comin' your way." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:42:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:42:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 5770C37B401 for ; Thu, 7 Dec 2000 00:42:16 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eB78bVw06968; Thu, 7 Dec 2000 00:37:31 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Matt Dillon Cc: Alfred Perlstein , Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: Message from Matt Dillon of "Thu, 07 Dec 2000 00:24:00 PST." <200012070824.eB78O0507941@earth.backplane.com> Date: Thu, 07 Dec 2000 00:37:30 -0800 Message-ID: <6963.976178250@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It would be nice to up the default cylinders/group in sysinstall > for larger partitions (anything over 8GB). I wouldn't up it to > 159 as a default, but 32 would be a whole lot better then the Well, if somebody wants to figure out the best defaults, they're easily set in sysinstall/label.c:new_part(); just calcuate the values dynamically rather than copying in the contents of VAR_NEWFS_ARGS. I'm sure it'd be a snap for a bunch of bright guys like you. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:52:22 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:52:20 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id F3AE137B400 for ; Thu, 7 Dec 2000 00:52:19 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB78qBL59516; Thu, 7 Dec 2000 09:52:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: Your message of "Thu, 07 Dec 2000 00:31:00 PST." <20001207003100.J16205@fw.wintelcom.net> Date: Thu, 07 Dec 2000 09:52:11 +0100 Message-ID: <59514.976179131@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001207003100.J16205@fw.wintelcom.net>, Alfred Perlstein writes: >I'd do it, but I don't really have a grasp on the optimal parameters >to set based on FS size. So far I don't see any indication here (or elsewhere) that anybody has that grasp. I guess that is really a testimony to FFS/UFS's qualites... The main thing is that you significantly reduce your fsck time if you reduce the number of inodes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:58:49 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:58:46 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7DDA637B400 for ; Thu, 7 Dec 2000 00:58:46 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB78uAo28072; Thu, 7 Dec 2000 00:56:10 -0800 (PST) Date: Thu, 7 Dec 2000 00:56:10 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters Message-ID: <20001207005610.M16205@fw.wintelcom.net> References: <20001207003100.J16205@fw.wintelcom.net> <59514.976179131@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <59514.976179131@critter>; from phk@critter.freebsd.dk on Thu, Dec 07, 2000 at 09:52:11AM +0100 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [001207 00:52] wrote: > In message <20001207003100.J16205@fw.wintelcom.net>, Alfred Perlstein writes: > > >I'd do it, but I don't really have a grasp on the optimal parameters > >to set based on FS size. > > So far I don't see any indication here (or elsewhere) that anybody > has that grasp. > > I guess that is really a testimony to FFS/UFS's qualites... > > The main thing is that you significantly reduce your fsck time if > you reduce the number of inodes. Oh, your tunables just reduce the number of inodes? That may come as a suprise to people that are using the larger disks to store images and web/ftp stuff. I guess we ought to leave it alone, maybe if I have the time I'll see about popping up a dialog to ask if they'd like to make the inode/fsck tradeoff. But since Kirk is getting close with his snapshot work it might really not be necessary. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:59:12 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:59:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2D03437B400 for ; Thu, 7 Dec 2000 00:59:10 -0800 (PST) Received: from newsguy.com (p31-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.96]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id RAA29719; Thu, 7 Dec 2000 17:57:53 +0900 (JST) Message-ID: <3A2F5073.C8C1A2FE@newsguy.com> Date: Thu, 07 Dec 2000 17:55:15 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Matt Dillon Cc: News History File User , hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> <200012060713.eB67D8I91529@earth.backplane.com> <200012061355.eB6DtGS34255@crotchety.newsbastards.org> <200012061905.eB6J5XV96902@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > One possible fix would be to have the kernel track cache hits and misses > on a file and implement a heuristic from those statistics which is used > to reduce the 'initial page weighting' for pages read-in from the > 'generally uncacheable file'. This would cause the kernel to reuse > those cache pages more quickly and prevent it from throwing away (reusing) > cache pages associated with more cacheable files like the .index and > .hash files. I don't have time to do this now, but it's definitely > something I am going to keep in mind for a later release. That sounds very, very clever. In fact, it sounds so clever I keep wondering what is the huge flaw with it. :-) Still, promising, to say the least. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 0:59:17 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 00:59:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2D20E37B402 for ; Thu, 7 Dec 2000 00:59:14 -0800 (PST) Received: from newsguy.com (p31-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.96]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id RAA29703; Thu, 7 Dec 2000 17:57:50 +0900 (JST) Message-ID: <3A2F4F57.A7EDEAEC@newsguy.com> Date: Thu, 07 Dec 2000 17:50:31 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Matt Dillon Cc: News History File User , hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> <200012060713.eB67D8I91529@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > You may be able to achieve an effect very similar to mlock(), but > runnable by the 'news' user without hacking the kernel, by > writing a quick little C program to mmap() the two smaller history > files and then madvise() the map using MADV_WILLNEED in a loop > with a sleep(15). Keeping in mind that expire may recreate those > files, the program should unmap, close(), and re-open()/mmap/madvise the > descriptors every so often (like once a minute). You shouldn't have > to access the underlying pages but that would also have a similar > effect. If you do, use a volatile pointer so GCC doesn't optimize > the access out of the loop. e.g. Err... wouldn't it be better to write a quick little C program that mlocked the files? It would need suid, sure, but as a small program without user input it wouldn't have security problems. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 1: 5:31 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 01:05:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 89F5037B400 for ; Thu, 7 Dec 2000 01:05:28 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB795NL59717; Thu, 7 Dec 2000 10:05:23 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: Your message of "Thu, 07 Dec 2000 00:56:10 PST." <20001207005610.M16205@fw.wintelcom.net> Date: Thu, 07 Dec 2000 10:05:23 +0100 Message-ID: <59715.976179923@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001207005610.M16205@fw.wintelcom.net>, Alfred Perlstein writes: >> So far I don't see any indication here (or elsewhere) that anybody >> has that grasp. >> >> I guess that is really a testimony to FFS/UFS's qualites... >> >> The main thing is that you significantly reduce your fsck time if >> you reduce the number of inodes. > >Oh, your tunables just reduce the number of inodes? That may come >as a suprise to people that are using the larger disks to store >images and web/ftp stuff. No they don't, I mainly reduce the number of cylinder-groups. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 1:24:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 01:24:35 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 3BAAE37B400 for ; Thu, 7 Dec 2000 01:24:35 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB79XDF00934; Thu, 7 Dec 2000 01:33:19 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012070933.eB79XDF00934@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Hay Cc: hackers@freebsd.org Subject: Re: Support for Syba pci multi i/o card? In-reply-to: Your message of "Sat, 06 Dec 2000 21:54:29 +0200." <200012061954.eB6JsTD22959@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 01:33:13 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If there aren't any patches I might look at adding support for it. Probably > only the serial ports, because that is what I need. I would like some advice > on how to do it though. I had a look at the sio driver and it has support > for a few pci cards, but it looks like they are single serial port cards > and not dual or quad. So how should I go about getting the sio probe and > attach to do more than one serial port per pci card? As Warner suggested, you probably want to create a "bus-like" device that looks to the sio/ppc drivers like an ISA bus, and then forcibly attach the relevant sio/ppc instances as children of this device. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 4: 3:13 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 04:03:09 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 5A45037B400 for ; Thu, 7 Dec 2000 04:03:05 -0800 (PST) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id NAA35634; Thu, 7 Dec 2000 13:00:19 +0100 (CET) Message-Id: <200012071200.NAA35634@luxren2.boostworks.com> Date: Thu, 7 Dec 2000 12:59:55 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: free() not freing pagedirs pages. To: dillon@earth.backplane.com Cc: phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG In-Reply-To: <200012062139.eB6LdkE99051@earth.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: root@boostworks.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 6 Dec, Matt Dillon wrote: > : > :OK. In fact my problem was just a printf that allocated a buffer via > :__smakebuf at the very last moment (when all memory was allocated). > :This prevent free() to give back all previous pages up to this one. The > :problem was _not_ in malloc.c. > : > :Anyway, i learned a lot from hacking the source to catch the caller. > :Thanks. > : > :RN. > :IhM > > Not to mention library routines which might malloc() something and > keep it around. > > I find that the best way to allocate a large chunk of memory is to > use mmap( ... MAP_ANON ... ). That way you have complete control > over the memory. You need only page-align the request size > (getpagesize() helps there). You can then manage the memory with > madvise(), and free it completely with munmap(). > > -Matt > Well, I may think using this solution if it remains portable between Unixes. I finally tracked down the problem, after suppressing the reason to call __smakebuf and tooling malloc.c. What happens is that malloc() uses the pages to store pginfo chains. If all memory is used, it allocates high addresses pages and (seems to) keeps these pages when all memory have been freed(). Here is a case: In the following example, about 60 Mbytes have been allocated then freed. Only one structure remains allocated at the very beginning of the memory (It is the first one allocated). page_dir size is 69632 bytes (17408 entries). Quiet all page_dir entries are either MALLOC_NOT_MINE (mainly backed to system, at end of page_dir) or MALLOC_FREE: (gdb) p *page_dir@17408 $33 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x815b000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x2, 0x3 , 0x1 , 0x815b000, 0x1 , 0x81cb000, 0x1 , 0x836c000, 0x1 , 0x8610000, 0x1 , 0x92ad000, 0x1 , 0x974b000, 0x1 , 0x9997000, 0x1 , 0x9e6e000, 0x1 , 0x0 } Here is the chain if non-magic entries: (gdb) p *page_dir[5] $22 = {next = 0x81cb000, page = 0x815b000, size = 32, shift = 5, free = 121, total = 127, bits = {4294963088}} (gdb) p *page_dir[5]->next $23 = {next = 0x836c000, page = 0x81cb000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} (gdb) p *page_dir[5]->next->next $24 = {next = 0x8610000, page = 0x836c000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} (gdb) p *page_dir[5]->next->next->next $25 = {next = 0x92ad000, page = 0x8610000, size = 32, shift = 5, free = 125, total = 127, bits = {4294901758}} (gdb) p *page_dir[5]->next->next->next->next $26 = {next = 0x974b000, page = 0x92ad000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} (gdb) p *page_dir[5]->next->next->next->next->next $27 = {next = 0x9997000, page = 0x974b000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} (gdb) p *page_dir[5]->next->next->next->next->next->next $28 = {next = 0x9e6e000, page = 0x9997000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} (gdb) p *page_dir[5]->next->next->next->next->next->next->next $29 = {next = 0x0, page = 0x9e6e000, size = 32, shift = 5, free = 126, total = 127, bits = {4294967294}} So the program appears as a memory hog on the 'top' view, from a user perspective. I agree that letting malloc madvise() usage hints of pages to the kernel would prevent/help swapping but it is difficult to explain in comprehensible words to many customers. Thanks for any hint about this situation. RN. IhM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 4:56: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 04:56:03 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0C22A37B400 for ; Thu, 7 Dec 2000 04:55:59 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA33823; Thu, 7 Dec 2000 13:55:33 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: remy@boostworks.com Cc: dillon@earth.backplane.com, phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012071200.NAA35634@luxren2.boostworks.com> From: Dag-Erling Smorgrav Date: 07 Dec 2000 13:55:33 +0100 In-Reply-To: Remy Nonnenmacher's message of "Thu, 7 Dec 2000 12:59:55 +0100 (CET)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Remy Nonnenmacher writes: > Well, I may think using this solution if it remains portable between > Unixes. It's perfectly portable, with one small variation - on BSD systems, you pass -1 instead of a file descriptor, while on SysV systems, you pass a descriptor to /dev/zero (or was it /dev/null?) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 5:12:55 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 05:12:54 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2112237B400 for ; Thu, 7 Dec 2000 05:12:53 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA33879; Thu, 7 Dec 2000 14:12:29 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: remy@boostworks.com Cc: dillon@earth.backplane.com, phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012071200.NAA35634@luxren2.boostworks.com> From: Dag-Erling Smorgrav Date: 07 Dec 2000 14:12:29 +0100 In-Reply-To: Dag-Erling Smorgrav's message of "07 Dec 2000 13:55:33 +0100" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Remy Nonnenmacher writes: > > Well, I may think using this solution if it remains portable between > > Unixes. > It's perfectly portable, with one small variation - on BSD systems, > you pass -1 instead of a file descriptor, while on SysV systems, you > pass a descriptor to /dev/zero (or was it /dev/null?) FWIW, I just did some tests - mmap()'ing /dev/zero works on FreeBSD as well, and mapping the same fd multiple times gives you separate areas, so you don't need a new fd for each. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 5:19: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 05:19:03 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.rila.bg (earth.rila.bg [212.39.75.31]) by hub.freebsd.org (Postfix) with ESMTP id 784A437B400 for ; Thu, 7 Dec 2000 05:19:00 -0800 (PST) Received: from earth (localhost [127.0.0.1]) by earth.rila.bg (8.11.1/8.11.1) with ESMTP id eB7DIm600430 for ; Thu, 7 Dec 2000 15:18:52 +0200 (EET) (envelope-from mitko@earth.rila.bg) Message-Id: <200012071318.eB7DIm600430@earth.rila.bg> X-Mailer: exmh version 2.1.1 10/15/1999 To: hackers@freebsd.org Reply-To: mitko@rila.bg From: "Dimitar V. Peikov" Subject: mount_smbfs & read_error Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 15:18:48 +0200 Sender: mitko@earth.rila.bg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've mount Win2k share, and for some reason there were read_error that cause REBOOT on my box. -- Dimitar Peikov Programmer Analyst "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 5:30:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 05:30:40 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 8024937B400 for ; Thu, 7 Dec 2000 05:30:39 -0800 (PST) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 144189-0004Gk-01; Thu, 7 Dec 2000 14:30:37 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.0/8.11.0) id eB7DM2N19527 for freebsd-hackers@freebsd.org; Thu, 7 Dec 2000 14:22:02 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Optimal UFS parameters Date: Thu, 7 Dec 2000 13:22:01 +0000 (UTC) Message-ID: <90o2tp$imk$1@kemoauc.mips.inka.de> References: <8D18712B2604D411A6BB009027F644980DD7B4@0SEA01EXSRV1> <200012070647.eB76llo07506@earth.backplane.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-hackers@freebsd.org Sender: daemon@mips.inka.de Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > The default filesystem parameters are: > > newfs -f 1024 -b 8192 -i 8192 -c 16 ... -i 4096 -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 5:32:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 05:32:26 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (hades.cybercity.dk [212.242.42.118]) by hub.freebsd.org (Postfix) with ESMTP id 8576D37B400 for ; Thu, 7 Dec 2000 05:32:25 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB7DW3L89940; Thu, 7 Dec 2000 14:32:03 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: remy@boostworks.com Cc: dillon@earth.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. In-Reply-To: Your message of "Thu, 07 Dec 2000 12:59:55 +0100." <200012071200.NAA35634@luxren2.boostworks.com> Date: Thu, 07 Dec 2000 14:32:03 +0100 Message-ID: <89938.976195923@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012071200.NAA35634@luxren2.boostworks.com>, Remy Nonnenmacher wr ites: >Well, I may think using this solution if it remains portable between >Unixes. I finally tracked down the problem, after suppressing the >reason to call __smakebuf and tooling malloc.c. Please examine the 'H' option to malloc. This does a much better job. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 6:14:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 06:14:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id B114C37B401 for ; Thu, 7 Dec 2000 06:14:12 -0800 (PST) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id PAA36266; Thu, 7 Dec 2000 15:12:13 +0100 (CET) Message-Id: <200012071412.PAA36266@luxren2.boostworks.com> Date: Thu, 7 Dec 2000 15:11:50 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: free() not freing pagedirs pages. To: phk@critter.freebsd.dk Cc: dillon@earth.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <89938.976195923@critter> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: root@boostworks.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 7 Dec, Poul-Henning Kamp wrote: > In message <200012071200.NAA35634@luxren2.boostworks.com>, Remy Nonnenmacher wr > ites: > >>Well, I may think using this solution if it remains portable between >>Unixes. I finally tracked down the problem, after suppressing the >>reason to call __smakebuf and tooling malloc.c. > > Please examine the 'H' option to malloc. This does a much better > job. > I agree about the hints, but as i said at the end of my previous mail, this is hardly a clean-bill winning response against a customer sighting a 30/40 Mbytes 'top' column ;). RN. ItM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 6:28:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 06:28:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (hades.cybercity.dk [212.242.42.118]) by hub.freebsd.org (Postfix) with ESMTP id B7F6637B400 for ; Thu, 7 Dec 2000 06:28:15 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB7ERwL90375; Thu, 7 Dec 2000 15:27:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: remy@boostworks.com Cc: dillon@earth.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. In-Reply-To: Your message of "Thu, 07 Dec 2000 15:11:50 +0100." <200012071412.PAA36266@luxren2.boostworks.com> Date: Thu, 07 Dec 2000 15:27:58 +0100 Message-ID: <90373.976199278@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Please examine the 'H' option to malloc. This does a much better >> job. >> >I agree about the hints, but as i said at the end of my previous mail, >this is hardly a clean-bill winning response against a customer >sighting a 30/40 Mbytes 'top' column ;). Top is not a very good indicator of memory use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 7:49:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 07:49:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id EF8AC37B400 for ; Thu, 7 Dec 2000 07:49:31 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Dec 2000 15:49:26 +0000 (GMT) Date: Thu, 7 Dec 2000 15:49:25 +0000 From: David Malone To: Jonathan Lemon Cc: Alfred Perlstein , Dan Kegel , hackers@FreeBSD.ORG Subject: Re: kqueue microbenchmark results Message-ID: <20001207154925.A25785@walton.maths.tcd.ie> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025170117.C87091@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Oct 25, 2000 at 05:01:17PM -0500 Sender: dwmalone@maths.tcd.ie Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: > I'd love to do that, but am not quite sure how I'd go about it. > If you read the l-k mailing list, you'll see Linus calling kqueue > "overengineered", and what he is proposing is something that is > definitely not well thought out. Maybe Alexander Viro could help? He often follows what's happening in the BSD world and seems to do lots of good VFS type work in the Linux world. Matt Dillon recently worked with him on the file discriptor locking patches he committed. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 8:36:57 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 08:36:54 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id 50F8837B401 for ; Thu, 7 Dec 2000 08:36:53 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.0/8.11.0) id eB7GXXm32836; Thu, 7 Dec 2000 16:33:33 GMT (envelope-from nik) Date: Thu, 7 Dec 2000 16:33:32 +0000 From: Nik Clayton To: Dag-Erling Smorgrav Cc: "G. Adam Stanislav" , Stephen McKay , hackers@FreeBSD.ORG Subject: Re: pipe Message-ID: <20001207163332.A32725@canyon.nothing-going-on.org> References: <20001202085127.A301@int80h.org> <3A292D98.E655D755@softweyr.com> <20001203012841.B228@whizkidtech.net> <200012040256.eB42upH07905@dungeon.home> <20001205085645.A228@whizkidtech.net> <20001205110328.A228@whizkidtech.net> <20001205121423.A228@whizkidtech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Dec 06, 2000 at 09:50:55AM +0100 Organization: FreeBSD Project Sender: nik@nothing-going-on.demon.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 06, 2000 at 09:50:55AM +0100, Dag-Erling Smorgrav wrote: > "G. Adam Stanislav" writes: > > On Tue, Dec 05, 2000 at 06:11:06PM +0100, Dag-Erling Smorgrav wrote: > > >The second and third sentences of the second paragraph (the one that > > >starts on line 23), as well as the entire eighth paragraph (that > > >starts on line 45), address the questions you asked in your previous > > >mail. > > I know it addresses it. Unfortunately, I didn't understand a word of it. > > I don't see how it could get any clearer. > > [...] If addr is zero, an address will be selected by > the system. The actual starting address of the region is returned. NAME mmap - map files or devices into memory [...] doesn't immediately shout "You can use this function to allocate memory as well". Perhaps mmap - allocate memory, or map files or devices into memory would be better? In addition, mmap isn't listed in the SEE ALSO for malloc(3), nor is it listed in memory(3). mmap() is listed in malloc(3), but only in an error message. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 8:55:17 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 08:55:12 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 572F937B400 for ; Thu, 7 Dec 2000 08:55:12 -0800 (PST) Received: from marcwin (marcwin.etinc.com [207.252.1.25]) by etinc.com (8.9.3/8.9.3) with SMTP id LAA27493 for ; Thu, 7 Dec 2000 11:54:40 GMT (envelope-from mark@etinc.com) Message-Id: <3.0.32.20001207115830.00841740@129.45.17.190> X-Sender: mark@129.45.17.190 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 07 Dec 2000 11:58:30 -0800 To: freebsd-hackers@freebsd.org From: Mark Subject: Iomega ZIP boot problem Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No answer from the -questions list, so I figured I'd try here. I'm encountering difficulties booting from a 250MB Iomega ZIP drive. The ZIP drive is installed as the primary master IDE. There's a UFS filesystem on /dev/afd0a. At the boot prompt, I enter boot: 0:ad(0,a)kernel afd0? is of course not an option here. Since the ZIP is configured in the BIOS to emulate an IDE HD, I take a stab. The kernel loads properly, devices are detected as per usual. At the stage where the root filesystem is remounted r/w, I get the following: < Times New Romanafd0: 239MB < [239/64/32] at ata0-master using PIO3 Mounting root from ufs:ad0s1a Root mount failed: 6 Mounting root from ufs:ad0sa Root mount failed: 6 Manual root filesystem specification: <:< Mount < using filesystem < eg. ufs:/dev/da0s1a ? List valid disk boot devices < Abort manual input mountroot> /dev/afd0a Mounting root from /dev/afd0a Root mount failed: 22 mountroot> ufs:/dev/afd0a Mounting root from ufs:/dev/afd0a spec_getpages:(#afd/0) IO read failure: (error=0) bp 0xc1c78438 vp 0xc5ae1d40 size: 53248, resid: 32768, a_count: 53248, valid: 0x0 nread: 20480, reqpage: 7, pindex: 51, pcount: 13 vm_fault: pager read error, pid 1 (init) Nov 28 10:31:15 init: setlogin() failed: Bad address spec_getpages:(#afd/0) IO read failure: (error=0) bp 0xc1c78438 vp 0xc5ae1d40 size: 57344, resid: 32768, a_count: 57344, valid: 0x0 nread: 24576, reqpage: 7, pindex: 73, pcount: 14 vm_fault: pager read error, pid 6 (sh) pid 6 (sh), uid 0: exited on signal 11 Nov 28 10:31:16 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /sbin/sh: < As you can see, manually selecting "/dev/afd0a" seems to be a valid option. However, once / is mounted, I get a series of read errors. There's more, though. If I hit "enter" a few times, it manages to execute /bin/sh and give me a prompt. At this point, most any command I type that isn't a shell builtin results in a few inital read failures followed by any number of successful operations. For example, if I tried to 'newfs' a partition, the first two attempts fail, and then I can 'newfs' as many partitions as I need. Seems like a caching issue, as if the latency of the drive exceeds the driver's expectation. This should not be an issue if it's using the "afd" driver. I'm wondering if this kind of operation is even supported? There don't seem to be any problems with the drive or the media, I can read and write files w/o errors with the drive mounted on a running system. Has anyone done this sort of thing successfully? If so, what am I missing? Thanks in advance... -Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 9:54:13 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 09:54:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id 663C337B401 for ; Thu, 7 Dec 2000 09:54:10 -0800 (PST) Received: (qmail 23305 invoked from network); 7 Dec 2000 17:54:09 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Dec 2000 17:54:09 -0000 Received: (qmail 24510 invoked from network); 7 Dec 2000 17:54:10 -0000 Received: from explorer.rsa.com (10.81.217.59) by spirit.dynas.se with SMTP; 7 Dec 2000 17:54:10 -0000 Received: (from mikko@localhost) by explorer.rsa.com (8.11.1/8.11.1) id eB7Hs5C22914; Thu, 7 Dec 2000 09:54:05 -0800 (PST) (envelope-from mikko) Date: Thu, 7 Dec 2000 09:54:05 -0800 (PST) From: Mikko Tyolajarvi Message-Id: <200012071754.eB7Hs5C22914@explorer.rsa.com> To: wille@teligent.se Cc: freebsd-hackers@freebsd.org Subject: Re: Shared Memory Newsgroups: local.freebsd.hackers References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In local.freebsd.hackers you write: >Could anyone enlighten me on how to set the amount of shared memory? If you mean the wretched System V IPCs, the parameters are in LINT. Search for "SHM". >I'd like that info for FreeBSD 2.2.2, 3.x, 4.x The parameters only have descriptive comments in 4.2, but I think they are the same in all releases (they're in LINT in RELENG_2 from '98 at least). $.02, /Mikko P.S. Hmm... there seems to be writable sysctl values  (e.g. kern.ipc.shmmax). Maybe a kernel recompile isn't needed anymore. -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10: 2: 8 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:02:05 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id D9D6637B401 for ; Thu, 7 Dec 2000 10:01:57 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7I1OF10367; Thu, 7 Dec 2000 10:01:24 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 10:01:24 -0800 (PST) From: Matt Dillon Message-Id: <200012071801.eB7I1OF10367@earth.backplane.com> To: Dag-Erling Smorgrav Cc: remy@boostworks.com, phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012071200.NAA35634@luxren2.boostworks.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Dag-Erling Smorgrav writes: :> Remy Nonnenmacher writes: :> > Well, I may think using this solution if it remains portable between :> > Unixes. :> It's perfectly portable, with one small variation - on BSD systems, :> you pass -1 instead of a file descriptor, while on SysV systems, you :> pass a descriptor to /dev/zero (or was it /dev/null?) : :FWIW, I just did some tests - mmap()'ing /dev/zero works on FreeBSD as :well, and mapping the same fd multiple times gives you separate areas, :so you don't need a new fd for each. : :DES :-- :Dag-Erling Smorgrav - des@ofug.org There are three ways to use mmap() to allocate memory: #1 MAP_ANON, when supported, should be used. #2 /dev/zero, when supported, should be used (tends to be more portable then MAP_ANON). #3 Create a temporary file, hold the descriptor, remove() the file, ftruncate() to the proper length, then mmap using MAP_PRIVATE. And then you can close the descriptor. This actually takes up *NO* filesystem space, since it's a private map. You can also keep the descriptor around and allocate/free chunks using mmap()/munmap() out of it. Just remember that you have to ftruncate() the file to be big enough to 'hold' your mmap ranges. This tends to be the most portable. Which of the three one uses depends on the OS. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10: 6:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:06:39 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id A05E137B400 for ; Thu, 7 Dec 2000 10:06:39 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7I66A10423; Thu, 7 Dec 2000 10:06:06 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 10:06:06 -0800 (PST) From: Matt Dillon Message-Id: <200012071806.eB7I66A10423@earth.backplane.com> To: Remy Nonnenmacher Cc: phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012071200.NAA35634@luxren2.boostworks.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Er, I obviously meant 'not use mmap' in that last posting. I'm sure that first sentence was confusing :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10: 6:56 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:06:53 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id C085037B401 for ; Thu, 7 Dec 2000 10:06:53 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7I6KX10417; Thu, 7 Dec 2000 10:06:20 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 10:06:20 -0800 (PST) From: Matt Dillon Message-Id: <200012071806.eB7I6KX10417@earth.backplane.com> To: Remy Nonnenmacher Cc: phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: free() not freing pagedirs pages. References: <200012071200.NAA35634@luxren2.boostworks.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Well, I may think using this solution if it remains portable between :Unixes. I finally tracked down the problem, after suppressing the :reason to call __smakebuf and tooling malloc.c. : :What happens is that malloc() uses the pages to store pginfo chains. If :all memory is used, it allocates high addresses pages and (seems :to) keeps these pages when all memory have been freed(). : :Here is a case: In the following example, about 60 Mbytes have been :allocated then freed. Only one structure remains allocated at the very :beginning of the memory (It is the first one allocated). : Another thing you can do, if you really want to continue to use mmap(), is to malloc() a large chunk of memory and then allocate the smaller structures out of the large chunk. That way you can free the large chunk all in one go. If the smaller structures are all the same size, writing a little support code to do this is trivial. If not, then you can use a simple zero-overhead allocator such as the one I wrote for libstand, /usr/src/lib/libstand/zalloc*, to allocate out of the big chunk you malloc'd. Whatever you do, do *NOT* depend on malloc being able to clean up small allocations and release their underlying pages. It might work in FreeBSD under certain circumstance, but it isn't a portable assumption. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10: 7: 6 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:07:02 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 7762337B401 for ; Thu, 7 Dec 2000 10:07:02 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7I6h410456; Thu, 7 Dec 2000 10:06:43 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 10:06:43 -0800 (PST) From: Matt Dillon Message-Id: <200012071806.eB7I6h410456@earth.backplane.com> To: "Daniel C. Sobral" Cc: News History File User , hackers@FreeBSD.ORG, usenet@tdk.net Subject: Re: vm_pageout_scan badness References: <200012011918.eB1JIol53670@earth.backplane.com> <200012020525.eB25PPQ92768@newsmangler.inet.tele.dk> <200012021904.eB2J4An63970@earth.backplane.com> <200012030700.eB370XJ22476@newsmangler.inet.tele.dk> <200012040053.eB40rnm69425@earth.backplane.com> <200012050545.eB55jL453889@crotchety.newsbastards.org> <200012060519.eB65JS910042@crotchety.newsbastards.org> <200012060713.eB67D8I91529@earth.backplane.com> <3A2F4F57.A7EDEAEC@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matt Dillon wrote: :> :> You may be able to achieve an effect very similar to mlock(), but :> runnable by the 'news' user without hacking the kernel, by :> writing a quick little C program to mmap() the two smaller history :> files and then madvise() the map using MADV_WILLNEED in a loop :> with a sleep(15). Keeping in mind that expire may recreate those :> files, the program should unmap, close(), and re-open()/mmap/madvise the :> descriptors every so often (like once a minute). You shouldn't have :> to access the underlying pages but that would also have a similar :> effect. If you do, use a volatile pointer so GCC doesn't optimize :> the access out of the loop. e.g. : :Err... wouldn't it be better to write a quick little C program that :mlocked the files? It would need suid, sure, but as a small program :without user input it wouldn't have security problems. : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com :dcs@freebsd.org mlock()ing is dangerous when used on a cyclic file. If you aren't careful you can run your system out of memory. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10: 7:40 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:07:37 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from nordier.com (c2-dbn-108.dial-up.net [196.34.155.236]) by hub.freebsd.org (Postfix) with ESMTP id 674F237B400; Thu, 7 Dec 2000 10:07:27 -0800 (PST) Received: (from rnordier@localhost) by nordier.com (8.11.1/8.11.1) id eB7I6Fb00619; Thu, 7 Dec 2000 20:06:15 +0200 (SAST) (envelope-from rnordier) From: Robert Nordier Message-Id: <200012071806.eB7I6Fb00619@nordier.com> Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader To: dillon@earth.backplane.com (Matt Dillon) Date: Thu, 7 Dec 2000 20:06:04 +0200 (SAST) Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <200012070439.eB74ddE69221@earth.backplane.com> from "Matt Dillon" at Dec 06, 2000 08:39:39 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > I sure would appreciate it if one of the bootstrap gurus could take > a look at what happens when the tftp open routine is called from a > normal disk-based /boot/loader! I've already looked at this, investigating a problem reported in connection with PR 21559. I'll probably sort it out in the next day or two, unless someone else gets there first. -- Robert Nordier rnordier@nordier.com rnordier@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 10:49:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 10:49:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id E193837B400; Thu, 7 Dec 2000 10:49:37 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7InDs10965; Thu, 7 Dec 2000 10:49:13 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 10:49:13 -0800 (PST) From: Matt Dillon Message-Id: <200012071849.eB7InDs10965@earth.backplane.com> To: Robert Nordier Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader References: <200012071806.eB7I6Fb00619@nordier.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've already looked at this, investigating a problem reported in :connection with PR 21559. I'll probably sort it out in the next day :or two, unless someone else gets there first. : :-- :Robert Nordier : :rnordier@nordier.com :rnordier@FreeBSD.org That'd be great. When you have a patch, if you email it to me I will test it on a box that I know crashes on the currennt problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12: 9:47 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:09:44 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 88F5A37B400 for ; Thu, 7 Dec 2000 12:09:43 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB7K9fs45012; Thu, 7 Dec 2000 13:09:41 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA06489; Thu, 7 Dec 2000 13:09:32 -0700 (MST) Message-Id: <200012072009.NAA06489@harmony.village.org> To: Matt Dillon Subject: Re: Optimal UFS parameters Cc: Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 07 Dec 2000 00:21:40 PST." <200012070821.eB78LeQ07926@earth.backplane.com> References: <200012070821.eB78LeQ07926@earth.backplane.com> <58936.976176750@critter> Date: Thu, 07 Dec 2000 13:09:32 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012070821.eB78LeQ07926@earth.backplane.com> Matt Dillon writes: : : -b 16384 -f 4096 -c 159 : I think Bruce swears by 4K (page-sized) fragments. Not a bad : way to go. I use 2K because I (and others) put in so much hard work : to fix all the little niggling bugs in the VM system related to partial : page validation and, damn it, I intend to use those features! At the other end of the spectrum, 32M [sic] and 64M [sic] disks work well with -b 4096 -f 512 -c 10 But I tend to do what phk has done with the large -c flags on my insanely-sized, rediculously-cheap XXG IDE drives. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12:12:17 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:12:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2396037B400; Thu, 7 Dec 2000 12:12:14 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB7KCCs45034; Thu, 7 Dec 2000 13:12:13 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA06519; Thu, 7 Dec 2000 13:12:07 -0700 (MST) Message-Id: <200012072012.NAA06519@harmony.village.org> To: Mike Smith Subject: Re: Support for Syba pci multi i/o card? Cc: John Hay , hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 07 Dec 2000 01:33:13 PST." <200012070933.eB79XDF00934@mass.osd.bsdi.com> References: <200012070933.eB79XDF00934@mass.osd.bsdi.com> Date: Thu, 07 Dec 2000 13:12:07 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012070933.eB79XDF00934@mass.osd.bsdi.com> Mike Smith writes: : > If there aren't any patches I might look at adding support for it. Probably : > only the serial ports, because that is what I need. I would like some advice : > on how to do it though. I had a look at the sio driver and it has support : > for a few pci cards, but it looks like they are single serial port cards : > and not dual or quad. So how should I go about getting the sio probe and : > attach to do more than one serial port per pci card? : : As Warner suggested, you probably want to create a "bus-like" device that : looks to the sio/ppc drivers like an ISA bus, and then forcibly attach : the relevant sio/ppc instances as children of this device. sio doesn't care what bus it attaches to, so long as it can get its resources. ppc still has some isa specific calls in it, but those map to bus generic ones so would just work. I've been holding off working on this until I saw what haked out of the bus unification work that Matt Dodd has been working on. I think he's mostly done, but I wasn't sure enough of that to proceed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12:30:25 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:30:23 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from link.mirror.org (link.mirror.org [216.38.7.35]) by hub.freebsd.org (Postfix) with ESMTP id BA1F737B400 for ; Thu, 7 Dec 2000 12:30:22 -0800 (PST) Received: from hal (14-d13-1.svg1.netcom.no [212.45.183.143]) by link.mirror.org (8.7.5/8.7.3) with ESMTP id QAA12069 for ; Thu, 7 Dec 2000 16:58:48 -0500 Date: Thu, 7 Dec 2000 21:30:54 +0100 (CET) From: Torbjorn Kristoffersen X-Sender: To: FreeBSD-Hackers Subject: Kernel question (detecting a user log-on) 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 Hackers, I'm wondering about two things, how does the kernel detect that a user logs on a tty, and what should I know if I was to write a kernel module that detects it (And does something about it)? Must I read the TCP in-packets for port 23 and detect if a user logged on? I'm pretty unsure about this.. I know it could easier be implemented in userland by reading the _PATH_UTMP file, but I'm more interested in doing it in kernel space. Thanks in advance -- Torbjorn Kristoffersen sgt@netcom.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12:32:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:32:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 96BDB37B401 for ; Thu, 7 Dec 2000 12:32:37 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id PAA18824; Thu, 7 Dec 2000 15:32:32 -0500 (EST) Date: Thu, 7 Dec 2000 15:30:51 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@onyx To: Brian Dean Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ptrace(PT_GETDBREGS) message in remote debugging In-Reply-To: <20001206194209.B94389@vger.bsdhome.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 Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a stable or current), but I failed: # make Warning: Object directory not changed from original /usr/src/gnu/usr.bin/binutils/gdb cc: ../libbfd/libbfd.a: No such file or directory cc: ../libopcodes/libopcodes.a: No such file or directory cc: ../libiberty/libiberty.a: No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. What should I do? -Zhihui On Wed, 6 Dec 2000, Brian Dean wrote: > Index: freebsd-nat.c > =================================================================== > RCS file: /usr00/FreeBSD/mirror/ncvs/src/gnu/usr.bin/binutils/gdb/i386/freebsd-nat.c,v > retrieving revision 1.21.4.2 > diff -u -r1.21.4.2 freebsd-nat.c > --- freebsd-nat.c 2000/08/22 12:28:19 1.21.4.2 > +++ freebsd-nat.c 2000/12/07 00:31:52 > @@ -478,14 +478,16 @@ > { > struct dbreg dbr; > extern int inferior_pid; > - > + > if (inferior_pid != 0 && core_bfd == NULL) > { > int pid = inferior_pid & ((1 << 17) - 1); /* XXX extract pid from tid */ > - > + > if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) > { > - perror("ptrace(PT_GETDBREGS) failed"); > + /* don't complain on ESRCH, assume we are debugging a remote target */ > + if (errno != ESRCH) > + perror("ptrace(PT_GETDBREGS) failed"); > return 0; > } > #if WATCHPOINT_DEBUG > 1 > @@ -520,7 +522,10 @@ > > if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) > { > - perror("ptrace(PT_GETDBREGS) failed"); > + /* don't complain on ESRCH, assume we are debugging a remote target */ > + if (errno != ESRCH) > + perror("ptrace(PT_GETDBREGS) failed"); > + > return 0; > } > > @@ -615,7 +620,9 @@ > > if (ptrace(PT_GETDBREGS, pid, (caddr_t)&dbr, 0) == -1) > { > - perror("ptrace(PT_GETDBREGS) failed"); > + /* don't complain on ESRCH, assume we are debugging a remote target */ > + if (errno != ESRCH) > + perror("ptrace(PT_GETDBREGS) failed"); > return 0; > } > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12:46:12 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:46:10 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 01B6337B400 for ; Thu, 7 Dec 2000 12:46:09 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id eB7Kk2W39548; Thu, 7 Dec 2000 15:46:02 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id eB7Kk2D08307; Thu, 7 Dec 2000 15:46:02 -0500 (EST) (envelope-from bsd) Date: Thu, 7 Dec 2000 15:46:02 -0500 From: Brian Dean To: Zhiui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ptrace(PT_GETDBREGS) message in remote debugging Message-ID: <20001207154602.A8268@vger.bsdhome.com> References: <20001206194209.B94389@vger.bsdhome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zzhang@cs.binghamton.edu on Thu, Dec 07, 2000 at 03:30:51PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote: > Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a > stable or current), but I failed: > > # make > > Warning: Object directory not changed from original > /usr/src/gnu/usr.bin/binutils/gdb > > > cc: ../libbfd/libbfd.a: No such file or directory > cc: ../libopcodes/libopcodes.a: No such file or directory > cc: ../libiberty/libiberty.a: No such file or directory > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils/gdb. > > What should I do? Hmmm, looks like you haven't built world on this machine. No worries, just do this: % cd /usr/src/gnu/usr.bin/binutils % (cd libbfd && make) % (cd libopcodes && make) % (cd libiberty && make) % (cd gdb && make && make install) This should build the missing libs and then gdb should link correctly. -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 12:56:13 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 12:56:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 48E7237B400 for ; Thu, 7 Dec 2000 12:56:11 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB7Ku3112378; Thu, 7 Dec 2000 12:56:03 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 12:56:03 -0800 (PST) From: Matt Dillon Message-Id: <200012072056.eB7Ku3112378@earth.backplane.com> To: Warner Losh Cc: Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <200012070821.eB78LeQ07926@earth.backplane.com> <58936.976176750@critter> <200012072009.NAA06489@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200012070821.eB78LeQ07926@earth.backplane.com> Matt Dillon writes: :: : -b 16384 -f 4096 -c 159 :: I think Bruce swears by 4K (page-sized) fragments. Not a bad :: way to go. I use 2K because I (and others) put in so much hard work :: to fix all the little niggling bugs in the VM system related to partial :: page validation and, damn it, I intend to use those features! : :At the other end of the spectrum, 32M [sic] and 64M [sic] disks work :well with : -b 4096 -f 512 -c 10 : :But I tend to do what phk has done with the large -c flags on my :insanely-sized, rediculously-cheap XXG IDE drives. : :Warner Well, too-large a C/G will result in greater file fragmentation, because FFS can't manage the file layouts in the cylinder groups as well. The default of 16 is definitely too little. 100+ is probably too much. Something in the middle will be about right. The fragmentation value returned by fsck would be an interesting number to publish. 'fsck -n /dev/...' on an idle fs (you don't have to unmount it). Anything over 3% fragmentation is a problem. Something like /usr will typically be in the 1-3% range. A large partition that is still half empty should be in the 0.0-0.5% range. A combination of a larger C/G (meaning fewer groups on the disk) and fewer inodes (a higher -i value) will dramatically decrease fsck times. After a certain point, though, continuing to increase C/G will not effect the fsck times. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 13:42: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 13:42:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195]) by hub.freebsd.org (Postfix) with ESMTP id 87F4937B400; Thu, 7 Dec 2000 13:42:00 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eB7LflL92920; Thu, 7 Dec 2000 22:41:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: Mike Smith , John Hay , hackers@FreeBSD.ORG Subject: Re: Support for Syba pci multi i/o card? In-Reply-To: Your message of "Thu, 07 Dec 2000 13:12:07 MST." <200012072012.NAA06519@harmony.village.org> Date: Thu, 07 Dec 2000 22:41:47 +0100 Message-ID: <92918.976225307@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012072012.NAA06519@harmony.village.org>, Warner Losh writes: >In message <200012070933.eB79XDF00934@mass.osd.bsdi.com> Mike Smith writes: >: > If there aren't any patches I might look at adding support for it. Probably >: > only the serial ports, because that is what I need. I would like some advice >: > on how to do it though. I had a look at the sio driver and it has support >: > for a few pci cards, but it looks like they are single serial port cards >: > and not dual or quad. So how should I go about getting the sio probe and >: > attach to do more than one serial port per pci card? >: >: As Warner suggested, you probably want to create a "bus-like" device that >: looks to the sio/ppc drivers like an ISA bus, and then forcibly attach >: the relevant sio/ppc instances as children of this device. > >sio doesn't care what bus it attaches to, so long as it can get its >resources. ppc still has some isa specific calls in it, but those map >to bus generic ones so would just work. I've been holding off working >on this until I saw what haked out of the bus unification work that >Matt Dodd has been working on. I think he's mostly done, but I wasn't >sure enough of that to proceed. There is a PR already with a patch for some multiport cards... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 13:45: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 13:45:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 12EF337B400 for ; Thu, 7 Dec 2000 13:45:00 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB7Liws45567; Thu, 7 Dec 2000 14:44:58 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA07216; Thu, 7 Dec 2000 14:44:57 -0700 (MST) Message-Id: <200012072144.OAA07216@harmony.village.org> To: Poul-Henning Kamp Subject: Re: Support for Syba pci multi i/o card? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 07 Dec 2000 22:41:47 +0100." <92918.976225307@critter> References: <92918.976225307@critter> Date: Thu, 07 Dec 2000 14:44:57 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <92918.976225307@critter> Poul-Henning Kamp writes: : There is a PR already with a patch for some multiport cards... Yes. I'm aware of that patch... But I don't like it because it doesn't use the multiio pseudo-bus thing that I talked about. Bruce also has some style concerns with it :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 14:48:17 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 14:48:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 5B82237B400 for ; Thu, 7 Dec 2000 14:48:15 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eB7Mfaa23249; Thu, 7 Dec 2000 16:41:36 -0600 (CST) (envelope-from dan) Date: Thu, 7 Dec 2000 16:41:36 -0600 From: Dan Nelson To: Matt Dillon Cc: Warner Losh , Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters Message-ID: <20001207164136.A1760@dan.emsphone.com> References: <200012070821.eB78LeQ07926@earth.backplane.com> <58936.976176750@critter> <200012072009.NAA06489@harmony.village.org> <200012072056.eB7Ku3112378@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <200012072056.eB7Ku3112378@earth.backplane.com>; from "Matt Dillon" on Thu Dec 7 12:56:03 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: dan@dan.emsphone.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Dec 07), Matt Dillon said: > Well, too-large a C/G will result in greater file fragmentation, > because FFS can't manage the file layouts in the cylinder groups as > well. The default of 16 is definitely too little. 100+ is probably > too much. Something in the middle will be about right. Here's the output of "newfs -N -b 16384 -f 2048 -i 262144 -c 107" on a 100-gig RAID filesystem: Warning: 468 sector(s) in last cylinder unallocated /dev/da4s1e: 216612396 sectors in 52884 cylinders of 1 tracks, 4096 sectors 105767.8MB in 495 cyl groups (107 c/g, 214.00MB/g, 896 i/g) and the fsck outputs for eight filesystems formatted like this: 195227 files, 30914874 used, 22947139 free (48723 frags, 2862302 blocks, 0.1% fragmentation) 16258 files, 33527019 used, 20587979 free (4283 frags, 2572962 blocks, 0.0% fragmentation) 747 files, 15748237 used, 38366761 free (657 frags, 4795763 blocks, 0.0% fragmentation) 9517 files, 23425935 used, 30689063 free (3039 frags, 3835753 blocks, 0.0% fragmentation) 1220 files, 16551150 used, 37563848 free (736 frags, 4695389 blocks, 0.0% fragmentation) 325 files, 25023763 used, 29091235 free (243 frags, 3636374 blocks, 0.0% fragmentation) 99 files, 18106183 used, 36008815 free (127 frags, 4501086 blocks, 0.0% fragmentation) 295 files, 22555093 used, 31559905 free (129 frags, 3944972 blocks, 0.0% fragmentation) The first filesystem has a full CVS repo, plus a checked-out copy of -stable, and took 90 seconds to check. All the others took under 20 seconds. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 15: 6:11 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 15:06:08 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 50A3637B400 for ; Thu, 7 Dec 2000 15:06:08 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id SAA18059; Thu, 7 Dec 2000 18:06:06 -0500 (EST) Date: Thu, 7 Dec 2000 18:04:13 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@onyx To: Brian Dean Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ptrace(PT_GETDBREGS) message in remote debugging In-Reply-To: <20001207154602.A8268@vger.bsdhome.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 Your patch works for me on FreeBSD 4.2-Release. Thanks. -Zhihui On Thu, 7 Dec 2000, Brian Dean wrote: > On Thu, Dec 07, 2000 at 03:30:51PM -0500, Zhiui Zhang wrote: > > Thanks. I tried this on FreeBSD 4.2-Release (because I do not have a > > stable or current), but I failed: > > > > # make > > > > Warning: Object directory not changed from original > > /usr/src/gnu/usr.bin/binutils/gdb > > > > > > cc: ../libbfd/libbfd.a: No such file or directory > > cc: ../libopcodes/libopcodes.a: No such file or directory > > cc: ../libiberty/libiberty.a: No such file or directory > > *** Error code 1 > > > > Stop in /usr/src/gnu/usr.bin/binutils/gdb. > > > > What should I do? > > Hmmm, looks like you haven't built world on this machine. No worries, > just do this: > > % cd /usr/src/gnu/usr.bin/binutils > % (cd libbfd && make) > % (cd libopcodes && make) > % (cd libiberty && make) > % (cd gdb && make && make install) > > This should build the missing libs and then gdb should link correctly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 15:14:28 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 15:14:26 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail3.aracnet.com (mail3.aracnet.com [216.99.193.38]) by hub.freebsd.org (Postfix) with ESMTP id 8725D37B401 for ; Thu, 7 Dec 2000 15:14:26 -0800 (PST) Received: from shell1.aracnet.com (shell1.aracnet.com [216.99.193.21]) by mail3.aracnet.com (8.11.0/8.11.0) with ESMTP id eB7N7qY30823; Thu, 7 Dec 2000 15:07:52 -0800 Received: by shell1.aracnet.com (8.9.3) id PAA20351; Thu, 7 Dec 2000 15:07:49 -0800 Date: Thu, 7 Dec 2000 15:07:49 -0800 (PST) From: Darren Pilgrim To: Matt Dillon Cc: Warner Losh , Poul-Henning Kamp , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters In-Reply-To: <200012072056.eB7Ku3112378@earth.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 This is a interesting topic (to me, anyway), and is one of the things that often gets overlooked by those of us with less experience. Rather than getting into a long discussion about modifying the newfs defaults across the board, what if the newfs options used were based on the size of the FS? There could be a simple rule in sysinstall that increased the newfs options from their default values if the defaults meant there would be more an x number of inodes and cg's. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 16: 2:35 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 16:02:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.alink.net (spoon.alink.net [207.135.127.97]) by hub.freebsd.org (Postfix) with ESMTP id 2502837B400; Thu, 7 Dec 2000 16:02:30 -0800 (PST) Received: from [216.39.8.88] (netility88.hq.netility.com [216.39.8.88]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id QAA28026; Thu, 7 Dec 2000 16:02:28 -0800 (PST) Mime-Version: 1.0 X-Sender: jbrowne@pop.alink.net Message-Id: In-Reply-To: <200012070813.eB78D7F00560@mass.osd.bsdi.com> References: <200012070813.eB78D7F00560@mass.osd.bsdi.com> Date: Thu, 7 Dec 2000 16:02:26 -0800 To: Mike Smith , Matt Dillon , jhb@FreeBSD.ORG, ps@FreeBSD.ORG From: Jim Browne Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 00:13 -0800 12/7/00, Mike Smith wrote: > > The option works wonderfully for /boot/pxeboot. But it turns out > > that the normal /boot/loader, when compiled with the above > > option, will crash horribly whenever it tries to open() a file and > > can't find it in the UFS filesystem on disk... it falls through the > > filesystem list until it hits the tftp FS and BEWM. Explosion. > > > > I sure would appreciate it if one of the bootstrap gurus could take > > a look at what happens when the tftp open routine is called from a > > normal disk-based /boot/loader! > >Probably hits an uninitialised function vector; this would be a good >catch for someone looking to learn a bit about the loader and libstand. Devsw "pxedisk" treats struct open_file member f_devdata as a pointer to a socket number[1]. Other devsw drivers treat f_devdata as a pointer to a struct i386_devdesc[2]. When you boot via PXE, sys/boot/i386/loader/main.c sets the current device to "pxedisk". If you do not boot via PXE, your current device is likely to be some take on "disk". When TFTP tries to open a file, it is expecting struct open_file member f_devdata to be a pointer to a socket number. When currdev is "pxe", that assumption is correct. When currdev is "disk*", that assumption is incorrect. Specifically, tftp.c does: tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); In my case, that often winds up making tftpfile->iodesc = 0. That parameter is later passed in tftp_makereq to sendrecv as the iodesc, which via sendudp (and possibly the ARP functions) winds up calling netif_put. netif_put derefs the bogus iodesc to get a function pointer for the put function of the network interface and calls it. WHAM. QED. :) I happen to be knee deep in this code right now as I am adding two things: support for booting from a flash based FS and porting the netboot Ethernet drivers to work under libstand(3) so I can use loader(8) with an AMD LANCE compatible chip. I was lurking until my code was finished, but your problem (which I was debugging today for my own configuration) is a good opportunity to speak up. I think the correct solution is to not overload f_devdata. Perhaps another field should be added to struct open_file specifically for a socket number and perhaps some error checking code is in order? :) I have to have my code working yesterday, so I'll keep plugging along on a solution. I'll email patches when finished. However, there are others who are far more familiar with this code than I, so pointers are appreciated especially from Alpha aware people. (I haven't even looked at the Alpha version of loader(8).) [1] sys/boot/i386/libi386/pxe.c function pxe_open towards the bottom. Actually, pxe.c just overwrites what is likely a pointer to a i386_devdesc that was allocated by i386_parsedev (i.e. memory leak). [2] sys/boot/i386/libi386/devicename.c function i386_parsedev On a final note: why is netif_drivers defined in pxe.c rather than conf.c? I'm currently working around that with a Makefile define, but I really think the defition of netif_drivers belongs in conf.c, especially if one is to have more than one netif_driver compiled into the binary (i.e. "pxe" and "ether") Jim Browne jbrowne@jbrowne.com "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 16:30:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 16:30:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.alink.net (spoon.alink.net [207.135.127.97]) by hub.freebsd.org (Postfix) with ESMTP id ED5E737B400; Thu, 7 Dec 2000 16:30:37 -0800 (PST) Received: from [216.39.8.88] (netility88.hq.netility.com [216.39.8.88]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id QAA07928; Thu, 7 Dec 2000 16:30:33 -0800 (PST) Mime-Version: 1.0 X-Sender: jbrowne@pop.alink.net Message-Id: In-Reply-To: References: <200012070813.eB78D7F00560@mass.osd.bsdi.com> Date: Thu, 7 Dec 2000 16:29:49 -0800 To: Mike Smith , Matt Dillon From: Jim Browne Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 16:02 -0800 12/7/00, Jim Browne wrote: >When TFTP tries to open a file, it is expecting struct open_file >member f_devdata to be a pointer to a socket number. When currdev >is "pxe", that assumption is correct. When currdev is "disk*", that >assumption is incorrect. Specifically, tftp.c does: > >tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); > >In my case, that often winds up making tftpfile->iodesc = 0. That >parameter is later passed in tftp_makereq to sendrecv as the iodesc, >which via sendudp (and possibly the ARP functions) winds up calling >netif_put. netif_put derefs the bogus iodesc to get a function >pointer for the put function of the network interface and calls it. >WHAM. QED. :) How does this look? *** tftp.c Thu Dec 7 16:20:02 2000 --- tftp2.c Thu Dec 7 16:20:55 2000 *************** tftp_open(path, f) *** 257,260 **** --- 257,262 ---- tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); + if (io == NULL) + return (EINVAL); io->destip = servip; tftpfile->off = 0; (I suppose I could have included this earlier. Ugh.) Jim Browne jbrowne@jbrowne.com "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 16:40:24 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 16:40:17 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 8504B37B400; Thu, 7 Dec 2000 16:40:17 -0800 (PST) Received: from laptop.baldwin.cx (root@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eB80dD735115; Thu, 7 Dec 2000 16:39:13 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 07 Dec 2000 16:40:03 -0800 (PST) From: John Baldwin To: Jim Browne Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loa Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, Matt Dillon , Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-Dec-00 Jim Browne wrote: > At 16:02 -0800 12/7/00, Jim Browne wrote: >>When TFTP tries to open a file, it is expecting struct open_file >>member f_devdata to be a pointer to a socket number. When currdev >>is "pxe", that assumption is correct. When currdev is "disk*", that >>assumption is incorrect. Specifically, tftp.c does: >> >>tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); >> >>In my case, that often winds up making tftpfile->iodesc = 0. That >>parameter is later passed in tftp_makereq to sendrecv as the iodesc, >>which via sendudp (and possibly the ARP functions) winds up calling >>netif_put. netif_put derefs the bogus iodesc to get a function >>pointer for the put function of the network interface and calls it. >>WHAM. QED. :) > > How does this look? > > *** tftp.c Thu Dec 7 16:20:02 2000 > --- tftp2.c Thu Dec 7 16:20:55 2000 > *************** tftp_open(path, f) > *** 257,260 **** > --- 257,262 ---- > > tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); > + if (io == NULL) > + return (EINVAL); > io->destip = servip; > tftpfile->off = 0; > > (I suppose I could have included this earlier. Ugh.) Looks fine to me.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 17:35:19 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 17:35:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 9CA1837B400; Thu, 7 Dec 2000 17:35:14 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB81iXN00495; Thu, 7 Dec 2000 17:44:33 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012080144.eB81iXN00495@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jim Browne Cc: Matt Dillon , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader In-reply-to: Your message of "Thu, 07 Dec 2000 16:29:49 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 17:44:33 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is probably an OK workaround. I think that there's something fundamentally wrong with the 'net' filesystems getting called for an open against a disk device, but I've paged out all the libstand state and I can't get it back fast enough to comment more usefully. 8( BTW Jim, the stuff you're working on sounds really cool. Thanks for taking it on! > At 16:02 -0800 12/7/00, Jim Browne wrote: > >When TFTP tries to open a file, it is expecting struct open_file > >member f_devdata to be a pointer to a socket number. When currdev > >is "pxe", that assumption is correct. When currdev is "disk*", that > >assumption is incorrect. Specifically, tftp.c does: > > > >tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); > > > >In my case, that often winds up making tftpfile->iodesc = 0. That > >parameter is later passed in tftp_makereq to sendrecv as the iodesc, > >which via sendudp (and possibly the ARP functions) winds up calling > >netif_put. netif_put derefs the bogus iodesc to get a function > >pointer for the put function of the network interface and calls it. > >WHAM. QED. :) > > How does this look? > > *** tftp.c Thu Dec 7 16:20:02 2000 > --- tftp2.c Thu Dec 7 16:20:55 2000 > *************** tftp_open(path, f) > *** 257,260 **** > --- 257,262 ---- > > tftpfile->iodesc = io = socktodesc(*(int *) (f->f_devdata)); > + if (io == NULL) > + return (EINVAL); > io->destip = servip; > tftpfile->off = 0; > > (I suppose I could have included this earlier. Ugh.) > > Jim Browne jbrowne@jbrowne.com > "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 18:24:19 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 18:24:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.alink.net (spoon.alink.net [207.135.127.97]) by hub.freebsd.org (Postfix) with ESMTP id 517BB37B400; Thu, 7 Dec 2000 18:24:10 -0800 (PST) Received: from [216.39.8.88] (netility88.hq.netility.com [216.39.8.88]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id SAA13007; Thu, 7 Dec 2000 18:24:08 -0800 (PST) Mime-Version: 1.0 X-Sender: jbrowne@pop.alink.net Message-Id: In-Reply-To: <200012080144.eB81iXN00495@mass.osd.bsdi.com> References: <200012080144.eB81iXN00495@mass.osd.bsdi.com> Date: Thu, 7 Dec 2000 18:22:53 -0800 To: Mike Smith From: Jim Browne Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader Cc: Matt Dillon , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 17:44 -0800 12/7/00, Mike Smith wrote: >This is probably an OK workaround. I think that there's something >fundamentally wrong with the 'net' filesystems getting called for an open >against a disk device, but I've paged out all the libstand state and I >can't get it back fast enough to comment more usefully. 8( A "better" thing to do would be for tftp_open to check the dv_type of the struct devsw member of struct open_file to see if it is a network device. However, stand.h has a comment stating that the dv_type member of struct devsw is an "opaque type constant, arch-dependant". Since tftp.c is in the arch-neutral libstand(3), I figured it would be bad for tftp.c to gain knowledge of the "opaque" db_type field. Regardless, the check I added should be there as it was an uncovered error condition. >BTW Jim, the stuff you're working on sounds really cool. Thanks for >taking it on! Apparently I am a glutton for punishment. Expect more bugfix patches in the near future. Jim Browne jbrowne@jbrowne.com "We lost our lease. You lose culture" - sign on SF Arts Comission Bldg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 18:37:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 18:37:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 0CD8237B400; Thu, 7 Dec 2000 18:37:43 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB82l2F00436; Thu, 7 Dec 2000 18:47:02 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012080247.eB82l2F00436@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jim Browne Cc: Matt Dillon , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: More on BTX halted / crashes trying to use -stable /boot/loader In-reply-to: Your message of "Thu, 07 Dec 2000 18:22:53 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 18:47:02 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Regardless, the check I added should be there as it was an uncovered > error condition. ... and I just realised I deleted your patch. D'oh! > >BTW Jim, the stuff you're working on sounds really cool. Thanks for > >taking it on! > > Apparently I am a glutton for punishment. Expect more bugfix patches > in the near future. Heh. If you're interested in maintaining this, maybe we need to get you commit access... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 21: 3:19 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 21:03:17 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.67.48]) by hub.freebsd.org (Postfix) with ESMTP id 799ED37B400 for ; Thu, 7 Dec 2000 21:03:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id eB853Ct29644 for ; Fri, 8 Dec 2000 00:03:12 -0500 (EST) Date: Fri, 8 Dec 2000 00:03:12 -0500 (EST) From: Alwyn Goodloe To: freebsd-hackers@FreeBSD.org Subject: Packet Header Filtering 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 We are about to begin a little project that has the following requiremnet. Perform IP packet filtering in the following way : i) look at an ip packet header. If some conditions are met let the packet pass otherwise reject the packet. ii) Look at ip packet headers of established connections and when certain conditions are met tear down the connection. Obviously this isn't the kind of thing we will be using the usual firewall software, at least not as I understand the software. What I want to know from you FreeBSD hackers is: i) if anyone has done something similar do you have any advice. ii) Anyone know where I should start hacking. Would it be best to try to hack the firewall code or the ipforwarding code.... Any such advise would be helpful. Alwyn Goodloe agoodloe@gradient.cis.upenn.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 21:18:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 21:18:06 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.kyx.net (unknown [216.232.16.88]) by hub.freebsd.org (Postfix) with ESMTP id 2F75637B400 for ; Thu, 7 Dec 2000 21:18:06 -0800 (PST) Received: from smp.kyx.net (unknown [10.22.22.45]) by mail.kyx.net (Postfix) with SMTP id 8BF6E1DC03; Thu, 7 Dec 2000 21:19:11 -0800 (PST) From: Dragos Ruiu Organization: kyx.net To: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@freebsd.org, tech@openbsd.org Subject: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Date: Thu, 7 Dec 2000 21:06:04 -0800 X-Mailer: KYX-CP/M [version core00-mail-92] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <0012072118150Q.09615@smp.kyx.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Hurm.... Wintendo outperforming unix???!?? Something's improper about this, and it ought to be fixed... :-) Comments? Other OS numbers: more recent FreeBSD versions? Solaris? Tru64? Optimization patches? Can those OO MSDN lobotomies actually be good things? Hurm... The Italian gauntlet has been thrown down.... --dr :-) url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Performance and tests 1. Packet Capture Driver Performance The main goal of a packet capture driver are performance. This means low use of system resources (memory and processor) but also low probability of loosing packets. The following main parameters influence the performances of the capture process: the efficiency of the filter, size of the packet buffer, the number of bytes copied and the number of system call that needs to be executed by the application. 1. The efficiency of the packet filter is a very important parameter, because the filter must be applied to every incoming packet (i.e. thousands of times per second). The packet capture driver uses the fast and highly optimized BPF filter (for more details about the performances of BPF filter, see [McCanne and Jacobson 1993]), whose virtual-processor architecture is suited for modern computers architectures. 2. More optimized packet filters have been developed after the original BPF. The more interesting for this kind of applications are MPF [13], and BPF+ [12]. The packet capture driver does not offer at the moment the advenced features of these two filters. It could be very useful to include in the driver the possibility to efficiently handle similar filters in a way similar to MPF. 3. Kernel buffer's size is the parameter that influences the number of packet loss during a capture; a bigger buffer means lower loss probability. Since the correct size of the buffer is a very subjective parameter and depends on various factors like network speed or machine characteristics, the packet capture driver offers a dynamic buffer that can be set to any size whenever the user wants to do that. In this way it is possible to set very big buffers on machines with an huge amount of RAM. Notice however that the buffer is freed when the driver's instance is closed, therefore the memory is used by the driver only during the capture process (i.e. when really needed). 4. Performances are strongly influenced by the number of bytes that need to be copied by the system. This task can absorb a lot of processor time and buffer memory. To overcome the problem, the packet capture driver applies the filter to an incoming packet as soon as it arrives to the system: the packet is filtered when it is still in the NIC driver's memory, without copying it. This means that no copy is needed to filter the packet. The filter tells how many bytes of the packets are needed by the user-level application (for example WinDump needs only the first 68 bytes of each packet). The packet capture driver copies only this amount of bytes (instead of the whole packet) to the circular buffer. This is very important also because reduces the space occupied by the packet in the circular buffer that is used more efficiently. The selected packet is then copied to the user-level application during a read system call. Summarizing, there are two copies of the cut packet, none of the entire packet that is equivalent of the number of copies done by the UNIX version. 5. Each read system call implies a context switch from user-mode (ring 3) to kernel-mode (ring 0) plus another another to return to user-mode. This process is notoriously slow and can influence the capture performances. Since a user-level application might want to look at every packet on the network and the time between packets can be only a few microseconds, it is not possible to do a read system call for each packet. The packet capture driver collects the data from several packets and copies it to the application's buffers in a single read call. The number of packets copied is not fixed and depends on the dimension of the application's buffer that will receive the packets: the driver detects the size of this buffer, and copies packets to it until it's full. Therefore, it is possible to decrease the number of system calls increasing the size of the application's read buffer. 2. Tests This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. 2.1 Testbed The testbed (shown in next figure) involves two PCs directly connected by means of a Fast Ethernet link. This assures the isolation of the testbed from external sources (our LAN), allowing accurate tests. A Windows NT workstation using the 'TG' tool (available into the developer's pack) based on the packet capture device driver generates traffic. This program is able to send data to the network using almost directly NDIS primitives, avoiding the overhead of the upper protocols and assuring the highest transfer rate compared to other traffic generator tools. Packet sizes have been selected in such way to generate the maximum amount of packets per second, that is usually the worst operating situation for a network analyzer. Packet sizes that maximized the number of packet sent was 101 bytes, as shown in next figure. The generated traffic is usually able to fill all the available bandwidth and there is no other traffic on that link. Tests are repeated several times in order to get accurate results and it has been derived their average value. Operating Systems under tests are installed in different disk partitions on the same workstation in order to avoid differences due to the hardware. Traffic is sent to a non-existent host in order not to have any interaction between the workstations. The second PC sets the interface in promiscuous mode and captures the traffic using WinDump / TCPdump in various configurations. Depending on the test type, packets captured are either saved to disk, printed on screen or dropped. The top program in FreeBSD, the task manager in Windows NT4/2000 and cpumeterin Windows 98 are the programs used to measure the CPU load. First two tools are shipped with the operating system, while the third one is available on the Internet. WinDump tested was version 2.02; TCPdump was the one included in the FreeBSD 3.3 distribution (TCPdump version 3.4, libpcap version 0.4). Even if our tests manage to isolate the impact of each subsystem (BPF and filtering, BPF and copying overhead), results are not able to compare exactly the performances of each component. This is due to the different architecture of the various versions, and to the impossibility to isolate each component from interacting one to the others and to the Operating System. In our opinion, the most representative test is test number 3 that measures performances "as a whole", including the packet driver, libpcap, WinDump as well as the operating system overhead (kernel processing, data transfer to disk, etc). The reason is that the "whole system" performance is what the end user is most interested in. 2.2 Results Test 1: Filter performances This test aims at measuring the impact of the BPF filter machine on the capture process. Packets are received by the network tap and checked by the BPF filter. The filter receives and processes all the packets sent. WinDump/TCPdump is launched with the following command line: windump 'filter' Where 'filter' is a packet filter with the TCPdump syntax. This test was executed with two different filters: 'udp': accepts only UDP packets. It is made by 5 instructions. 'src host 1.1.1.1 and dst host 2.2.2.2': accepts only packets coming from 1.1.1.1 and going to 2.2.2.2. This filter is a bit more complex, and is made by 13 instructions. Since no packet satisfying these filters passes on the network (because all the packets are generated by the TG tool), the filters reject all the packets. In this way, there is no copy and no interaction with the application. Only the filter function uses system resources. The filtering function does not use memory, so what is interesting to see here is the processor usage, shown in next figure. The figure shows that differences between different OSs are very limited. This is what we expect and confirms that our choice to create the BPF as a protocol was good enough to compete with original BPF. CPU load varies among different platforms, remaining however at acceptable levels. Windows platforms have sensibly better results. This is due probably to the fact that NDIS usually invokes the packet_tap function before the DMA transfer of the packet is finished, giving a bit of time to BPF. bpf_tap, instead, is called after the end of the DMA transfer. Notice finally that the values are very similar for the two filters. This confirms that the BPF filtering machine is well optimized, and that its efficiency increases with longer filters. Test 2: Driver's performance For this second test, a "fake" capture application based on libpcap was created and compiled for Windows and FreeBSD. This application receives ALL the packets from the driver (setting an accept-all filter), but discards them without any further processing, because the libpcap 'callback' function is empty. All the packets are processed by the underlying network levels, then by the packet driver, but there is NO packet processing at user level. The portion of packet to be accepted can be decided by user. This test aims at a global evaluation of efficiency of packet driver, including the copy processes from the interface driver to the kernel buffer and then to the user buffer. There was no filter in these tests, so the filtering function does not influence the results. Next figure shows CPU usage for various combinations "packet length-portion copied". FreeBSD has better performance than Windows, mainly because the tap function, that in FreeBSD is very simple and fast, in Windows is more complex and slow. For longer packets (i.e. for lower frequencies) the CPU use under FreeBSD decreases, but this does not happen in windows. This results stems from the "delayed write" ability of the UNIX BPF, as explained in Section 2.1. For high packets frequencies, the CPU load of the different systems is quite similar. However the system calls frequency (and therefore the CPU load) under UNIX decreases considerably when the size of incoming packets increases (i.e. the frequency is lower), while in Windows it remains stable. This behavior is not a problem for Windows implementations because it uses more CPU time only when it is available. Figure 7, in fact, shows that all systems loose very few packets. Test 3: WinDump capture performance In our opinion, this is the most important test, because involves the use of WinDump in order to measure the entire capture process. No filter is defined. Packets are captured and stored on disk using the "-w" WinDump option. Next figure shows the results when, for each packet, a "snapshot" of 68 bytes is saved on file, i.e. when the "windump -w test.acp" is executed. Results are very interesting when the network is overloaded by an high number of packets per second (i.e. packet size 101 bytes, that means about 67000 packets per second). All systems suffer noticeable losses: a certain amount of packets is lost for the lack of CPU time (a new packet arrives while the tap was processing a previous one), while others are dropped because the kernel buffer has no more space to hold them. It can be noted that Windows versions work noticeably better than the FreeBSD one. This is due mainly to the better buffering method of windows versions. Windows NT 4 is able to 'detect' less packets than FreeBSD (i.e. the number of packet received by filter is lower), but saves to disk 20% more packets. Windows 98 has a very good behavior compared to FreeBSD, but the real surprise is the Windows 2000 that is able to save to disk 73% of the packets on a NTFS partition, and 89% on a FAT partition. Since the packet driver for Windows 2000 is very similar to the one for Windows NT 4, the differences are due mainly to the improvements of NDIS and of file systems brought to Windows 2000. The heaviness of the file system is in fact a very important parameter in a test like this: notice that the same machine can capture under Windows 2000 a larger amount of packets if used with a faster file system like FAT32. This is one of the reasons because Windows 98 is faster than Windows NT 4. When the dimension of the packets grows (i.e. packet size 500 and 1514 bytes), the situation becomes less critical because the frequency of the packets decreases, but the portion saved is always 68 bytes. The values obtained tend to become more similar, and also the slower systems have good results. Next figure shows the results when the whole packets are saved to disk, i.e. when the "windump -s 1514 -w test.acp" is executed. (graphic ommitted) This is quite a hard test, and the kernel buffer is very important. In fact every packet must be entirely stored, and tends to fill the kernel buffer, especially with big packet sizes. FreeBSD is the system with the most serious problems because of its smaller buffer. Windows 2000 remains the system with better results, above all with long packets where it's the only able to capture without loosing anything. Discussion First and second tests show that the Windows implementation of BPF architecture has approximately the same impact on the system than the FreeBSD one and performances are quite similar; differences are located in the CPU load, where FreeBSD is the clear winner. This is due to the fewer code needed to implement the architecture in FreeBSD (because of the possibility to modify the OS sources) compared to the Windows one and to the "delayed write" capability of TCPdump. The results obtained are very important because show that our main goal, i.e. to create a free capture architecture with performance comparable with BPF for UNIX, has been reached. Moreover, the results show that the choice to implement the packet driver at protocol level is good enough to obtain performance comparable with the one of BPF in UNIX. However the interesting test from the end-user standpoint is the third one, because it shows the behavior of the BPF capture driver in conjunction with the most important tool based on it: WinDump. WinDump for Windows2000 is the clear winner and TCPdump for FreeBSD is the clear looser. While the BPF architecture performs on Windows 2000 like on other systems, Windows 2000 shows the best performances because of its optimized storage management. Packets are quickly saved on file, therefore buffers are freed and the incoming packets can be received with a small number of drops. FreeBSD is the clear looser because of its different buffering architecture that is not able to sustain heavy data rates. Notice that WinDump has been launched with the standard kernel buffer (1MB); in presence of heavy traffic the size of this buffer can be increased with a simple command line switch, improving further the overall performance of the system. Our conclusions are that BPF architecture for Windows performs well, that the dynamic buffer improves effectively the overall performances and that, among all the Windows flavors, Windows 2000 is the best platform for an high performance network analyzer. -- Dragos Ruiu dursec.com ltd. / kyx.net - we're from the future gpg/pgp key on file at wwwkeys.pgp.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 21:39:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 21:39:28 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by hub.freebsd.org (Postfix) with ESMTP id 0039B37B400 for ; Thu, 7 Dec 2000 21:39:27 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB85lIN00544; Thu, 7 Dec 2000 21:47:18 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012080547.eB85lIN00544@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@freebsd.org, tech@openbsd.org Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? In-reply-to: Your message of "Thu, 07 Dec 2000 21:06:04 PST." <0012072118150Q.09615@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 21:47:18 -0800 From: Mike Smith Sender: msmith@mass.osd.bsdi.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Please don't spam this many lists with such a large message.) The test is pretty questionable. FreeBSD 3.3 is over a year old, and I would suspect that the one actual outstanding criticism here (filesystem latency) is probably due to the default synchronous-mode filesystem. A more valid test would use one of the 4.x family FreeBSD releases and soft updates. There are still plenty of things that could be done to further accelerate the system, but that's the one clear item here. > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down.... --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 21:48:53 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 21:48:51 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 0AAB037B400 for ; Thu, 7 Dec 2000 21:48:51 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB85lKc17216; Thu, 7 Dec 2000 21:47:20 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 21:47:20 -0800 (PST) From: Matt Dillon Message-Id: <200012080547.eB85lKc17216@earth.backplane.com> To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? References: <0012072118150Q.09615@smp.kyx.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :(Hurm.... Wintendo outperforming unix???!?? Something's : improper about this, and it ought to be fixed... :-) : Comments? Other OS numbers: more recent : FreeBSD versions? Solaris? Tru64? Optimization : patches? Can those OO MSDN lobotomies actually : be good things? Hurm... The Italian gauntlet has : been thrown down.... --dr :-) : :url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Oh yah, I remember this... this is a pretty old benchmark, by the way. Sigh. All this demonstrates is that the person tring to write the packets to disk doesn't know what he's doing. There's nothing wrong with FreeBSD, per say. Looking at the data I would guess that they are appending to a file using write()'s on a packet-by-packet basis or with a redirect from tcpdump on a shell line, rather then spend the 60 seconds it would take to program-in some fairly trivial user-level buffering. The program is obviously stalling on the write and causing the BPF filter to overflow its output buffer. Just because FreeBSD refuses to use all available memory to buffer a single file's writes doesn't mean it's broken, just that the benchmark is. I'm guessing simply double-buffering the disk writeing with two dd's would be sufficient to capture all packets to disk and if someone seriously intended to use a FreeBSD box as a packet-capture system they would write a capture program to talk to the BPF socket directly and implement proper buffering in that rather then tring to use tcpdump. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 21:53: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 21:53:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0F2AF37B400 for ; Thu, 7 Dec 2000 21:53:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB85pgK02654; Thu, 7 Dec 2000 21:51:42 -0800 (PST) Date: Thu, 7 Dec 2000 21:51:42 -0800 From: Alfred Perlstein To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, freebsd-hackers@FreeBSD.ORG, winpcap@netgroup-serv.polito.it Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207215142.H16205@fw.wintelcom.net> References: <0012072118150Q.09615@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0012072118150Q.09615@smp.kyx.net>; from dr@kyx.net on Thu, Dec 07, 2000 at 09:06:04PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dragos Ruiu [001207 21:18] wrote: > > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down.... --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm I'm looking at this, FreeBSD seems to better on all accounts except writing the packets to disk. Can any of the winpcap people explain exactly how they measured the disk performance? The graph's title is: "WinDump performance" under the section called "WinDump capture performance". I'm very curious how they managed to run "windump" on FreeBSD. I'd also be interested in at least getting a copy of their emulator. :) Honestly, it really looks like the fault lies with the way tcpdump writes to disk and not with FreeBSD. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 22:57:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 22:57:18 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 2096737B400 for ; Thu, 7 Dec 2000 22:55:41 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eB86md171647; Fri, 8 Dec 2000 08:48:39 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200012080648.eB86md171647@zibbi.icomtek.csir.co.za> Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? In-Reply-To: <20001207215142.H16205@fw.wintelcom.net> from Alfred Perlstein at "Dec 7, 2000 09:51:42 pm" To: bright@wintelcom.net (Alfred Perlstein) Date: Fri, 8 Dec 2000 08:48:39 +0200 (SAT) Cc: dr@kyx.net (Dragos Ruiu), tcpdump-workers@tcpdump.org, freebsd-hackers@FreeBSD.ORG, winpcap@netgroup-serv.polito.it X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: jhay@zibbi.icomtek.csir.co.za Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > (Hurm.... Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down.... --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > I'm looking at this, FreeBSD seems to better on all accounts except > writing the packets to disk. > > Can any of the winpcap people explain exactly how they measured > the disk performance? > ... > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. What I couldn't figure out from the url was if they were using dma for the disk. Maybe they were using it on Windows and not on FreeBSD? (On FreeBSD 3 you have to enable it with flags in the kernel config file.) Also they don't say if they have changed the debug.bpf_bufsize sysctl from its default smallish 4096 bytes. Those 2 things can make a huge difference. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23: 8: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:08:00 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from freeway.dcfinc.com (cx74889-a.phnx3.az.home.com [24.1.193.157]) by hub.freebsd.org (Postfix) with ESMTP id 1CA6337B401; Thu, 7 Dec 2000 23:08:00 -0800 (PST) Received: (from chad@localhost) by freeway.dcfinc.com (8.8.8/8.8.8) id AAA12102; Fri, 8 Dec 2000 00:07:50 -0700 (MST) (envelope-from chad) From: "Chad R. Larson" Message-Id: <200012080707.AAA12102@freeway.dcfinc.com> Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? In-Reply-To: from Matthew Jacob at "Dec 2, 0 01:43:18 pm" To: mjacob@feral.com Date: Fri, 8 Dec 2000 00:07:49 -0700 (MST) Cc: gallatin@cs.duke.edu, ken@kdm.org, hackers@FreeBSD.ORG, stable@FreeBSD.ORG Reply-To: chad@DCFinc.com Organization: DCF, Inc. X-O/S: FreeBSD 2.2.8-STABLE X-Unexpected: The Spanish Inquisition X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: chad@freeway.dcfinc.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I recall, Matthew Jacob wrote: > > Agreed. Thanks for spotting this, Andrew. > > No, we should not let users read PCI registers in such a fashion that > will cauase the system to crash. Ok, I guess just because it's the holiday season, I feel like opening a can of worms. I thought the space staked out by the *BSD gang was approximately this: NetBSD - the least amount of platform-specific code possible; run on most anything OpenBSD - pro-active security, bullet-proof from attacks FreeBSD - best performing on the Intel PC platform If that's accurate (and it may not be), then how concerned should we be about the Alpha port? Isn't Alpha (and SPARC, etc) the space stake out by the NetBSD gang? I'm not trying to foster a war here. There seems to be enough of that anyway. But unless this PCI register reading thingie is an issue for i386 boxen (and I don't think it is) we shouldn't cripple functionality on the i386 for the Alpha. Has the core group ever weighed in on this? Does the BSDi merger change any of the FreeBSD focus with regard to other hardware architectures? -crl -- Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm? chad@dcfinc.com chad@larsons.org larson1@home.net DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:13:35 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:13:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5E02137B400; Thu, 7 Dec 2000 23:13:31 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB87DTs48213; Fri, 8 Dec 2000 00:13:29 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA10039; Fri, 8 Dec 2000 00:13:29 -0700 (MST) Message-Id: <200012080713.AAA10039@harmony.village.org> To: chad@DCFinc.com Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Cc: mjacob@feral.com, gallatin@cs.duke.edu, ken@kdm.org, hackers@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "Fri, 08 Dec 2000 00:07:49 MST." <200012080707.AAA12102@freeway.dcfinc.com> References: <200012080707.AAA12102@freeway.dcfinc.com> Date: Fri, 08 Dec 2000 00:13:29 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012080707.AAA12102@freeway.dcfinc.com> "Chad R. Larson" writes: : Has the core group ever weighed in on this? Does the BSDi merger : change any of the FreeBSD focus with regard to other hardware : architectures? Core, per se, hasn't. There's a very strong history in this project that if a port is supported, breaking it is unacceptible. FreeBSD has moved beyond intel only, and we need to deal with that, even if there are things we can get away with on i386 and can't on other platforms. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:27:27 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:27:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h003.c014.sfo.cp.net [209.228.12.67]) by hub.freebsd.org (Postfix) with SMTP id 6BB4F37B400 for ; Thu, 7 Dec 2000 23:27:25 -0800 (PST) Received: (cpmta 10450 invoked from network); 7 Dec 2000 23:27:24 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.67) with SMTP; 7 Dec 2000 23:27:24 -0800 X-Sent: 8 Dec 2000 07:27:24 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id XAA00484; Thu, 7 Dec 2000 23:27:22 -0800 (PST) (envelope-from gharris) Date: Thu, 7 Dec 2000 23:27:22 -0800 From: Guy Harris To: Matt Dillon Cc: Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207232722.A352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200012080547.eB85lKc17216@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Dec 07, 2000 at 09:47:20PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote: > Looking at the data I would guess that they > are appending to a file using write()'s on a packet-by-packet basis Unlikely, given that they're using "tcpdump", which, with the "-w" flag, writes using standard I/O, and doesn't do "fflush()"es on a packet-by-packet basis. > or with a redirect from tcpdump on a shell line, Assuming, as I suspect is the case, that they're using the same command on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:34: 0 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:33:59 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id D619537B400 for ; Thu, 7 Dec 2000 23:33:58 -0800 (PST) Received: (cpmta 9498 invoked from network); 7 Dec 2000 23:33:58 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 7 Dec 2000 23:33:58 -0800 X-Sent: 8 Dec 2000 07:33:58 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id XAA00512; Thu, 7 Dec 2000 23:33:57 -0800 (PST) (envelope-from gharris) Date: Thu, 7 Dec 2000 23:33:56 -0800 From: Guy Harris To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@freebsd.org, tech@openbsd.org Subject: Re: [tcpdump-workers] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207233356.B352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <0012072118150Q.09615@smp.kyx.net>; from dr@kyx.net on Thu, Dec 07, 2000 at 09:06:04PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 09:06:04PM -0800, Dragos Ruiu wrote: > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? As an experiment, changing BPF_MAXBUFSIZE to 1MB, and changing libpcap to use a 1MB buffer, on FreeBSD? (That might help the "whole packet dumped" test.) Somehow measuring how large the byte count in the capture file "write()" calls in FreeBSD and "WriteFile()" calls are? (FreeBSD is probably doing 8K writes, assuming it's writing to an 8K/1K file system; I don't know what block size the MSVC++ version of the standard I/O library uses, but it might well use bigger chunks than 8K.) > Can those OO MSDN lobotomies actually be good things? I'm not sure the parts of the OS that are actually involved are particularly object-oriented; I have the impression most of the COM, etc. stuff lives well up in userland on Windows. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:38:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:38:19 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 2B94B37B400 for ; Thu, 7 Dec 2000 23:38:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB87c9817756; Thu, 7 Dec 2000 23:38:09 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 23:38:09 -0800 (PST) From: Matt Dillon Message-Id: <200012080738.eB87c9817756@earth.backplane.com> To: Guy Harris Cc: Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207232722.A352@quadrajet.flashcom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> or with a redirect from tcpdump on a shell line, : :Assuming, as I suspect is the case, that they're using the same command :on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on :Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp". It amounts to the same thing, since -w does nothing more then an fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't even double buffered. But I think the last poster had it right... if the bpf buffer size was not changed from the default 4096, just about anything can interrupt the packet flow. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:45:38 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:45:37 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from tj2.demon.co.uk (tj2.demon.co.uk [158.152.29.119]) by hub.freebsd.org (Postfix) with SMTP id 5A38E37B402 for ; Thu, 7 Dec 2000 23:45:36 -0800 (PST) Received: from tj2.demon.co.uk, ID 3A30774E-1217F, Fri, 8 Dec 2000 05:53:18 UTC To: freebsd-hackers@freebsd.org From: 207.100@tj2.demon.co.uk X-Date: Fri, 8 Dec 2000 05:53:18 +0000 Subject: Re: Optimal UFS parameters Message-ID: <3A30774E.1217F@tj2.demon.co.uk> Date: Fri, 8 Dec 2000 05:53:18 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How frequently do people fsck? -- TJ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:46: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:46:02 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id 16B7D37B400 for ; Thu, 7 Dec 2000 23:45:58 -0800 (PST) Received: (cpmta 11445 invoked from network); 7 Dec 2000 23:39:59 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 7 Dec 2000 23:39:59 -0800 X-Sent: 8 Dec 2000 07:39:59 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id XAA00529; Thu, 7 Dec 2000 23:39:58 -0800 (PST) (envelope-from gharris) Date: Thu, 7 Dec 2000 23:39:58 -0800 From: Guy Harris To: Matt Dillon Cc: Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207233958.C352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200012080547.eB85lKc17216@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Dec 07, 2000 at 09:47:20PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote: > Looking at the data I would guess that they > are appending to a file using write()'s on a packet-by-packet basis Or, as per my other mail, perhaps using, on Windows, a version of the standard I/O library that does bigger writes, hence fewer system calls. (That might require a bigger kernel buffer in the capture mechanism to keep the capture buffer from overflowing whilst you're busy copying data to file pages in the write, but, in fact, WinPcap is using a 1MB kernel buffer on Windows, rather than the 32K buffer that's used on FreeBSD.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Dec 7 23:55:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 7 23:55:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id 7360937B401 for ; Thu, 7 Dec 2000 23:55:42 -0800 (PST) Received: (cpmta 15886 invoked from network); 7 Dec 2000 23:55:41 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 7 Dec 2000 23:55:41 -0800 X-Sent: 8 Dec 2000 07:55:41 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id XAA00585; Thu, 7 Dec 2000 23:55:36 -0800 (PST) (envelope-from gharris) Date: Thu, 7 Dec 2000 23:55:36 -0800 From: Guy Harris To: Matt Dillon Cc: Guy Harris , Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207235536.D352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207232722.A352@quadrajet.flashcom.com> <200012080738.eB87c9817756@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200012080738.eB87c9817756@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Dec 07, 2000 at 11:38:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote: > It amounts to the same thing, since -w does nothing more then an > fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't > even double buffered. > > But I think the last poster had it right... if the bpf buffer size > was not changed from the default 4096, just about anything can interrupt > the packet flow. (If "the last poster" suggested cranking up BPF_MAXBUFSIZE, that was me.) libpcap's default in FreeBSD 3.4 is 32768, not 4096 - 4096 is the kernel's default, but libpcap overrides that - but that's still significantly lower than 1MB. I'm curious whether there's any compelling reason why you can't do an SIOCSBLEN on a device that's already been attached to an interface; perhaps it could do a "bpf_detachd()" if it was attached to an interface, and then do a "bpf_attachd()" after changing the size. However, that would work only on systems with a modified kernel; an alternative would be to add an variant of "pcap_open_live()" that took a buffer size argument, which could be made to work on existing BSD systems (as well as many other systems - including Windows :-)). That wouldn't help, though, unless BPF_MAXBUFSIZE were cranked up; it's 524288 in 4.x - that happened in delta 1.21: Revision 1.21 / (download) - annotate - [select for diffs], Sat Jan 15 19:46:12 2000 UTC (10 months, 3 weeks ago) by phk CVS Tags: RELENG_4_BP Branch point for: RELENG_4 Changes since 1.20: +2 -2 lines Diff to previous 1.20 (colored) |The hard limit for the BPF buffer size is 32KB, which appears too low |for high speed networks (even at 100Mbit/s this corresponds to 1/300th |of a second). The default buffer size is 4KB, but libpcap and ipfilter |both override this (using the BIOCSBLEN ioctl) and allocate 32KB. | |The following patch adds an sysctl for bpf_maxbufsize, similar to the |one for bpf_bufsize that you added back in December 1995. I choose to |make the default for this limit 512KB (the value suggested by NFR). so it might be interesting to retry the tests on a 4.x system, with the 32768 in pcap-bpf.c changed to 524288. It might also be interesting to try throwing a "setvbuf()" call into libpcap, to crank up the standard I/O buffer size (although on systems with small kernel buffers in the capture mechanism, a large write *might* take enough time that you could fill up and then overflow that buffer). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:20:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:20:16 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 20CED37B400 for ; Fri, 8 Dec 2000 00:20:16 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA22903; Fri, 8 Dec 2000 03:48:45 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eB87XhF07040; Fri, 8 Dec 2000 02:33:43 -0500 (EST) Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id BAA19038 for ; Fri, 8 Dec 2000 01:21:40 -0500 (EST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB85pgK02654; Thu, 7 Dec 2000 21:51:42 -0800 (PST) Date: Thu, 7 Dec 2000 21:51:42 -0800 From: Alfred Perlstein To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, freebsd-hackers@FreeBSD.ORG, winpcap@netgroup-serv.polito.it Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001207215142.H16205@fw.wintelcom.net> References: <0012072118150Q.09615@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0012072118150Q.09615@smp.kyx.net>; from dr@kyx.net on Thu, Dec 07, 2000 at 09:06:04PM -0800 Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dragos Ruiu [001207 21:18] wrote: > > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down.... --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm I'm looking at this, FreeBSD seems to better on all accounts except writing the packets to disk. Can any of the winpcap people explain exactly how they measured the disk performance? The graph's title is: "WinDump performance" under the section called "WinDump capture performance". I'm very curious how they managed to run "windump" on FreeBSD. I'd also be interested in at least getting a copy of their emulator. :) Honestly, it really looks like the fault lies with the way tcpdump writes to disk and not with FreeBSD. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:20:28 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:20:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 674FF37B400 for ; Fri, 8 Dec 2000 00:20:24 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA22925; Fri, 8 Dec 2000 03:48:54 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eB87WJw07014; Fri, 8 Dec 2000 02:32:19 -0500 (EST) Received: from mass.osd.bsdi.com (adsl-63-202-176-64.dsl.snfc21.pacbell.net [63.202.176.64]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id BAA18799 for ; Fri, 8 Dec 2000 01:07:57 -0500 (EST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eB85lIN00544; Thu, 7 Dec 2000 21:47:18 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200012080547.eB85lIN00544@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? In-reply-to: Your message of "Thu, 07 Dec 2000 21:06:04 PST." <0012072118150Q.09615@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 21:47:18 -0800 From: Mike Smith Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Please don't spam this many lists with such a large message.) The test is pretty questionable. FreeBSD 3.3 is over a year old, and I would suspect that the one actual outstanding criticism here (filesystem latency) is probably due to the default synchronous-mode filesystem. A more valid test would use one of the 4.x family FreeBSD releases and soft updates. There are still plenty of things that could be done to further accelerate the system, but that's the one clear item here. > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down.... --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:20:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:20:25 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 47F8937B402 for ; Fri, 8 Dec 2000 00:20:25 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA22931; Fri, 8 Dec 2000 03:48:56 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eB87XVq07037; Fri, 8 Dec 2000 02:33:31 -0500 (EST) Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id BAA18970 for ; Fri, 8 Dec 2000 01:18:10 -0500 (EST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB85lKc17216; Thu, 7 Dec 2000 21:47:20 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 21:47:20 -0800 (PST) From: Matt Dillon Message-Id: <200012080547.eB85lKc17216@earth.backplane.com> To: Dragos Ruiu Cc: tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? References: <0012072118150Q.09615@smp.kyx.net> Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :(Hurm.... Wintendo outperforming unix???!?? Something's : improper about this, and it ought to be fixed... :-) : Comments? Other OS numbers: more recent : FreeBSD versions? Solaris? Tru64? Optimization : patches? Can those OO MSDN lobotomies actually : be good things? Hurm... The Italian gauntlet has : been thrown down.... --dr :-) : :url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Oh yah, I remember this... this is a pretty old benchmark, by the way. Sigh. All this demonstrates is that the person tring to write the packets to disk doesn't know what he's doing. There's nothing wrong with FreeBSD, per say. Looking at the data I would guess that they are appending to a file using write()'s on a packet-by-packet basis or with a redirect from tcpdump on a shell line, rather then spend the 60 seconds it would take to program-in some fairly trivial user-level buffering. The program is obviously stalling on the write and causing the BPF filter to overflow its output buffer. Just because FreeBSD refuses to use all available memory to buffer a single file's writes doesn't mean it's broken, just that the benchmark is. I'm guessing simply double-buffering the disk writeing with two dd's would be sufficient to capture all packets to disk and if someone seriously intended to use a FreeBSD box as a packet-capture system they would write a capture program to talk to the BPF socket directly and implement proper buffering in that rather then tring to use tcpdump. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:21:41 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:21:37 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id DAC4537B401 for ; Fri, 8 Dec 2000 00:21:36 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA22962; Fri, 8 Dec 2000 03:48:58 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eB87al807102; Fri, 8 Dec 2000 02:36:47 -0500 (EST) Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA21797 for ; Fri, 8 Dec 2000 03:07:35 -0500 (EST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB87c9817756; Thu, 7 Dec 2000 23:38:09 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Dec 2000 23:38:09 -0800 (PST) From: Matt Dillon Message-Id: <200012080738.eB87c9817756@earth.backplane.com> To: Guy Harris Cc: Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207232722.A352@quadrajet.flashcom.com> Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> or with a redirect from tcpdump on a shell line, : :Assuming, as I suspect is the case, that they're using the same command :on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on :Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp". It amounts to the same thing, since -w does nothing more then an fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't even double buffered. But I think the last poster had it right... if the bpf buffer size was not changed from the default 4096, just about anything can interrupt the packet flow. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:21:41 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:21:36 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 5901937B400 for ; Fri, 8 Dec 2000 00:21:36 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id DAA22913; Fri, 8 Dec 2000 03:48:49 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eB87YS107043; Fri, 8 Dec 2000 02:34:28 -0500 (EST) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id CAA20034 for ; Fri, 8 Dec 2000 02:23:24 -0500 (EST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eB86md171647; Fri, 8 Dec 2000 08:48:39 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200012080648.eB86md171647@zibbi.icomtek.csir.co.za> Subject: Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? In-Reply-To: <20001207215142.H16205@fw.wintelcom.net> from Alfred Perlstein at "Dec 7, 2000 09:51:42 pm" To: bright@wintelcom.net (Alfred Perlstein) Date: Fri, 8 Dec 2000 08:48:39 +0200 (SAT) Cc: dr@kyx.net (Dragos Ruiu), tcpdump-workers@tcpdump.org, freebsd-hackers@FreeBSD.ORG, winpcap@netgroup-serv.polito.it X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > (Hurm.... Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down.... --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > I'm looking at this, FreeBSD seems to better on all accounts except > writing the packets to disk. > > Can any of the winpcap people explain exactly how they measured > the disk performance? > ... > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. What I couldn't figure out from the url was if they were using dma for the disk. Maybe they were using it on Windows and not on FreeBSD? (On FreeBSD 3 you have to enable it with flags in the kernel config file.) Also they don't say if they have changed the debug.bpf_bufsize sysctl from its default smallish 4096 bytes. Those 2 things can make a huge difference. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:27: 9 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:27:08 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 9E8FB37B400 for ; Fri, 8 Dec 2000 00:27:07 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA10473; Fri, 8 Dec 2000 00:26:50 -0800 (PST) (envelope-from DougB@FreeBSD.org) Sender: doug@dt051n37.san.rr.com Message-ID: <3A309B4A.268EE653@FreeBSD.org> Date: Fri, 08 Dec 2000 00:26:50 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brandon Fosdick Cc: Dag-Erling Smorgrav , Yusuf Goolamabbas , freebsd-hackers@FreeBSD.org Subject: Re: nslookup deprecation [was 4.2 complaint] References: <20001205133817.A24228@outblaze.com> <3A2D1C5A.3234E4C5@glue.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brandon Fosdick wrote: > > Dag-Erling Smorgrav wrote: > > > > Yusuf Goolamabbas writes: > > > Recently there was a message indicating that ISC is deprecating > > > nslookup. > > > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > > Will a replacement be added to the base distro? When? This comes up VERY often, please make a habit of checking the mail archives before posting questions of this sort. If all you need to do is look up a name -> address or address -> name mapping, 'host' provides everything you need, and then some. If you are doing serious DNS debugging, you have to learn dig, period. HTH, Doug -- So what I want to know is, where does the RED brick road go? Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:38:43 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:38:41 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id 5C6F437B400 for ; Fri, 8 Dec 2000 00:38:41 -0800 (PST) Received: (cpmta 28065 invoked from network); 8 Dec 2000 00:38:40 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 8 Dec 2000 00:38:40 -0800 X-Sent: 8 Dec 2000 08:38:40 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id AAA00405; Fri, 8 Dec 2000 00:38:39 -0800 (PST) (envelope-from gharris) Date: Fri, 8 Dec 2000 00:38:39 -0800 From: Guy Harris To: Guy Harris Cc: Matt Dillon , Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org Subject: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001208003839.A352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207233958.C352@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001207233958.C352@quadrajet.flashcom.com>; from gharris@flashcom.net on Thu, Dec 07, 2000 at 11:39:58PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 11:39:58PM -0800, Guy Harris wrote: > Or, as per my other mail, perhaps using, on Windows, a version of the > standard I/O library that does bigger writes, hence fewer system calls. Nope. According to "strace for NT": http://www.securiteam.com/tools/Strace_for_NT_-_low_level_system_calls_tracer.html and the Windows(R) NT(R)/2000 Native API Reference: http://www.newriders.com/books/title.cfm?isbn=1578701996 it's doing 4K writes in the underlying NT system call "NtWriteFile()". I suspect that running the test on FreeBSD 4.x and tweaking libpcap to use a 512KB buffer might make a big difference here. At this point, we might want to limit followups to one or more of: tcpdump-workers@tcpdump.org - for discussing changes to libpcap to allow the buffer size to be set from an application and/or changing the size it initially tries on BSD (the current version in CVS starts at 32768 and keeps dividing that in half until it finds something that works); freebsd-hackers@freebsd.org, tech@openbsd.org - for discussing changes to allow the buffer size to be changes with BIOCSBLEN even if the BPF device is attached to an interface. (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB in the top of the CVS tree; NetBSD still has it as 32K.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 0:50:13 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 00:50:11 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id 363C837B400 for ; Fri, 8 Dec 2000 00:50:11 -0800 (PST) Received: (cpmta 799 invoked from network); 8 Dec 2000 00:50:10 -0800 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 8 Dec 2000 00:50:10 -0800 X-Sent: 8 Dec 2000 08:50:10 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id AAA00442; Fri, 8 Dec 2000 00:50:09 -0800 (PST) (envelope-from gharris) Date: Fri, 8 Dec 2000 00:50:09 -0800 From: Guy Harris To: Alfred Perlstein Cc: Dragos Ruiu , tcpdump-workers@tcpdump.org, freebsd-hackers@FreeBSD.ORG, winpcap@netgroup-serv.polito.it Subject: Re: [tcpdump-workers] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001208005009.B352@quadrajet.flashcom.com> References: <0012072118150Q.09615@smp.kyx.net> <20001207215142.H16205@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001207215142.H16205@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Dec 07, 2000 at 09:51:42PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 09:51:42PM -0800, Alfred Perlstein wrote: > I'm very curious how they managed to run "windump" on FreeBSD. Presumably they're referring to tcpdump there, as per the first paragraph in "2. Tests": This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. Perhaps. However, from my stracing of windump on NT 4 SP4 and trussing of tcpdump on FreeBSD 3.4, the only difference appears to be that tcpdump does 8K writes and windump does 4K writes.... Currently, I suspect that it lies with the BPF kernel buffer only being 32K; that's the most you can get on FreeBSD 3.x, but you can crank it up to 512KB on 4.x - libpcap on 4.x only sets it to 32K, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 2:19:32 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 02:19:30 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gekko.i-clue.de (server.ms-agentur.de [62.153.134.194]) by hub.freebsd.org (Postfix) with ESMTP id 881F937B400 for ; Fri, 8 Dec 2000 02:19:29 -0800 (PST) Received: from i-clue.de (automatix.i-clue.de [192.168.0.112]) by gekko.i-clue.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA20142; Fri, 8 Dec 2000 12:24:20 +0100 Message-ID: <3A30B5C6.23D5B50B@i-clue.de> Date: Fri, 08 Dec 2000 11:19:50 +0100 From: Christoph Sold Organization: i-clue GmbH X-Mailer: Mozilla 4.75 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: 207.100@tj2.demon.co.uk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <3A30774E.1217F@tj2.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 207.100@tj2.demon.co.uk schrieb: > > How frequently do people fsck? Only at boot time, or when problems surface. Just my $.02 -Christoph Sold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 2:21: 4 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 02:21:02 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from genius.tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id EA18A37B400 for ; Fri, 8 Dec 2000 02:21:01 -0800 (PST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 9AC209B36; Fri, 8 Dec 2000 10:26:53 +0000 (GMT) Date: Fri, 8 Dec 2000 10:26:53 +0000 From: Josef Karthauser To: 207.100@tj2.demon.co.uk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters Message-ID: <20001208102653.A988@bsdi.com> Mail-Followup-To: Josef Karthauser , 207.100@tj2.demon.co.uk, freebsd-hackers@FreeBSD.ORG References: <3A30774E.1217F@tj2.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A30774E.1217F@tj2.demon.co.uk>; from 207.100@tj2.demon.co.uk on Fri, Dec 08, 2000 at 05:53:18AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 08, 2000 at 05:53:18AM +0000, 207.100@tj2.demon.co.uk wrote: > > How frequently do people fsck? Once per reboot usually. Joe -- Josef Karthauser [joe@FreeBSD.org, joe@tao.org.uk] ......... FreeBSD: The power to change the world ........ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 2:37:10 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 02:37:07 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool207-tch-1.Sofia.0rbitel.net [212.95.170.207]) by hub.freebsd.org (Postfix) with SMTP id C6BF137B402 for ; Fri, 8 Dec 2000 02:36:59 -0800 (PST) Received: (qmail 776 invoked by uid 1000); 8 Dec 2000 10:36:14 -0000 Date: Fri, 8 Dec 2000 12:36:14 +0200 From: Peter Pentchev To: Torbjorn Kristoffersen Cc: FreeBSD-Hackers Subject: Re: Kernel question (detecting a user log-on) Message-ID: <20001208123614.A451@ringworld.oblivion.bg> Mail-Followup-To: Torbjorn Kristoffersen , FreeBSD-Hackers References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sgt@netcom.no on Thu, Dec 07, 2000 at 09:30:54PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 07, 2000 at 09:30:54PM +0100, Torbjorn Kristoffersen wrote: > Hi Hackers, > > I'm wondering about two things, how does the kernel detect that a > user logs on a tty, and what should I know if I was to write a kernel > module that detects it (And does something about it)? Must I > read the TCP in-packets for port 23 and detect if a user logged on? > I'm pretty unsure about this.. > > I know it could easier be implemented in userland by reading the > _PATH_UTMP file, but I'm more interested in doing it in kernel space. Generally the kernel does not know anything about user logins. Those are handled either by login(1) in the case of console, serial or telnet logins, or by sshd(8) and similar remote login daemons. Monitoring TCP activity on port 23 would only catch plain telnet logins, and probably not always. You'd be far better off hacking support for what you need into login(1), sshd(8) and all other such daemons; or a much simpler, though FreeBSD-specific solution (not that hacking login(1) isn't FreeBSD-specific) - modify the login(3) libutil function. It is used by login(1) and by the OpenSSH daemon in the FreeBSD base system; I *think* the original SSH daemon also uses it if present. You'd want to either add a syscall, or some tty ioctl to alert your kernel module about a user login, and then have login(3) perform that alert. Hope that helps, and when you come up with something working, please post more information either on the list, or to me privately - what you've hinted at doing sounds interesting :) G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 3:31:47 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 03:31:45 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 09FB937B400 for ; Fri, 8 Dec 2000 03:31:44 -0800 (PST) Received: from lanczos.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 8 Dec 2000 11:31:43 +0000 (GMT) Date: Fri, 8 Dec 2000 11:31:40 +0000 From: David Malone To: Alwyn Goodloe Cc: freebsd-hackers@FreeBSD.org Subject: Re: Packet Header Filtering Message-ID: <20001208113140.A21021@lanczos.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from agoodloe@gradient.cis.upenn.edu on Fri, Dec 08, 2000 at 12:03:12AM -0500 Sender: dwmalone@maths.tcd.ie Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 08, 2000 at 12:03:12AM -0500, Alwyn Goodloe wrote: > i) look at an ip packet header. If some conditions are met let the packet pass > otherwise reject the packet. > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. I presume you mean TCP in the second case, IP doesn't have a notion of an established connection by itself. > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: This sounds exactly like what regular packet filtering software like ipfw or ipf do (both have man pages). Another possibility would be to use netgraph and the ng_bpf device, which can do any filtering that the Berekley Packet Filter can do. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 4: 1:31 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 04:01:29 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iservern.teligent.se (mail.teligent.se [194.17.198.3]) by hub.freebsd.org (Postfix) with ESMTP id 3DFD137B400 for ; Fri, 8 Dec 2000 04:01:28 -0800 (PST) Received: from blackice (dyn-office-107.teligent.se [172.18.0.107]) by iservern.teligent.se (8.8.7/8.8.7) with SMTP id NAA21716; Fri, 8 Dec 2000 13:01:19 +0100 (CET) (envelope-from wille@teligent.se) Reply-To: From: "William Carlsson - Teligent Nordic, AB - Sweden" To: "Mikko Tyolajarvi" Cc: Subject: RE: Shared Memory Date: Fri, 8 Dec 2000 13:01:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200012071754.eB7Hs5C22914@explorer.rsa.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Isn't all kern.* read only? Seems like it can't be changed more than it's in theory changeable Something like the maximum nuber of files and processes, that is suposed to be soft configurable in login.conf (doesn't work either) ,D Does anything work in FreeBSD? ,D -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Mikko Tyolajarvi Sent: den 7 december 2000 18:54 To: wille@teligent.se Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Shared Memory In local.freebsd.hackers you write: >Could anyone enlighten me on how to set the amount of shared memory? If you mean the wretched System V IPCs, the parameters are in LINT. Search for "SHM". >I'd like that info for FreeBSD 2.2.2, 3.x, 4.x The parameters only have descriptive comments in 4.2, but I think they are the same in all releases (they're in LINT in RELENG_2 from '98 at least). $.02, /Mikko P.S. Hmm... there seems to be writable sysctl values  (e.g. kern.ipc.shmmax). Maybe a kernel recompile isn't needed anymore. -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 4:11:31 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 04:11:28 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from security.za.net (security.za.net [196.2.146.22]) by hub.freebsd.org (Postfix) with ESMTP id DF6A237B400 for ; Fri, 8 Dec 2000 04:11:23 -0800 (PST) Received: from localhost (lists@localhost) by security.za.net (8.9.3/8.9.3) with ESMTP id OAA89790; Fri, 8 Dec 2000 14:10:54 +0200 (SAST) (envelope-from lists@security.za.net) Date: Fri, 8 Dec 2000 14:10:54 +0200 (SAST) From: Lists Account To: Alwyn Goodloe Cc: freebsd-hackers@FreeBSD.org Subject: Re: Packet Header Filtering 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 Look at IPF/IPFW they both have state table stuff in them, and analyzing the ip header is done by both as well. I would suggest you hack ipf to do what you want if it doesnt do it already. Cheers Andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: > We are about to begin a little project that has the following requiremnet. > > Perform IP packet filtering in the following way : > > > i) look at an ip packet header. If some conditions are met let the packet pass > otherwise reject the packet. > > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. > > > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: > > i) if anyone has done something similar do you have any advice. > ii) Anyone know where I should start hacking. Would it be best to try to > hack the firewall code or the ipforwarding code.... > > Any such advise would be helpful. > > > Alwyn Goodloe > agoodloe@gradient.cis.upenn.edu > > > > > 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 Dec 8 4:55:36 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 04:55:35 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6F26537B400 for ; Fri, 8 Dec 2000 04:55:34 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA38633; Fri, 8 Dec 2000 13:55:33 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Torbjorn Kristoffersen Cc: FreeBSD-Hackers Subject: Re: Kernel question (detecting a user log-on) References: From: Dag-Erling Smorgrav Date: 08 Dec 2000 13:55:32 +0100 In-Reply-To: Torbjorn Kristoffersen's message of "Thu, 7 Dec 2000 21:30:54 +0100 (CET)" Message-ID: Lines: 13 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Torbjorn Kristoffersen writes: > I'm wondering about two things, how does the kernel detect that a > user logs on a tty, and what should I know if I was to write a kernel > module that detects it (And does something about it)? Must I > read the TCP in-packets for port 23 and detect if a user logged on? > I'm pretty unsure about this.. Why don't you tell us what you want to do, instead of how you think it must be done? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 5: 0:58 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 05:00:56 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool207-tch-1.Sofia.0rbitel.net [212.95.170.207]) by hub.freebsd.org (Postfix) with SMTP id 165F537B400 for ; Fri, 8 Dec 2000 05:00:53 -0800 (PST) Received: (qmail 1549 invoked by uid 1000); 8 Dec 2000 12:59:59 -0000 Date: Fri, 8 Dec 2000 14:59:59 +0200 From: Peter Pentchev To: william.carlsson@teligent.se Cc: Mikko Tyolajarvi , freebsd-hackers@FreeBSD.ORG Subject: Re: Shared Memory Message-ID: <20001208145959.C451@ringworld.oblivion.bg> Mail-Followup-To: william.carlsson@teligent.se, Mikko Tyolajarvi , freebsd-hackers@FreeBSD.ORG References: <200012071754.eB7Hs5C22914@explorer.rsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from wille@teligent.se on Fri, Dec 08, 2000 at 01:01:16PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 08, 2000 at 01:01:16PM +0100, William Carlsson - Teligent Nordic, AB - Sweden wrote: > Isn't all kern.* read only? > Seems like it can't be changed more than it's in theory changeable > > Something like the maximum nuber of files and processes, that is suposed to > be > soft configurable in login.conf (doesn't work either) > > ,D Does anything work in FreeBSD? ,D Uhm.. what version of FreeBSD do you have in mind? On a 4.2 I have.. [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 256 [roam@ringworld:v2 ~]$ On another console: [root@ringworld:v0 /etc]# perl -pi -e 's/maxproc=256/maxproc=512/' login.conf [root@ringworld:v0 /etc]# Logout and re-login on the first one: [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 512 [roam@ringworld:v2 ~]$ Feels quite changeable to me :) And btw - no, almost none of the kern.* sysctls are read-only. [root@ringworld:v0 /etc]# sysctl kern.coredump kern.corefile kern.syncdelay ker n.consmute kern.coredump: 1 kern.corefile: %N.core kern.syncdelay: 30 kern.consmute: 0 [root@ringworld:v0 /etc]# sysctl -w kern.coredump=0 kern.corefile='%N.CORE' ker n.syncdelay=100 kern.consmute=1 kern.coredump: 1 -> 0 kern.corefile: %N.core -> %N.CORE kern.syncdelay: 30 -> 100 kern.consmute: 0 -> 1 [root@ringworld:v0 /etc]# ..to name an (almost) random sample :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 5: 9:45 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 05:09:43 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 4B56037B400 for ; Fri, 8 Dec 2000 05:09:42 -0800 (PST) Received: from victoria-173.budapest.interware.hu ([195.70.63.173] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 144NHN-0002ad-00; Fri, 08 Dec 2000 14:09:38 +0100 Sender: julian@FreeBSD.ORG Message-ID: <3A30DC79.A5F26525@elischer.org> Date: Fri, 08 Dec 2000 05:04:57 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Lists Account Cc: Alwyn Goodloe , freebsd-hackers@FreeBSD.org Subject: Re: Packet Header Filtering References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lists Account wrote: > > Look at IPF/IPFW they both have state table stuff in them, and analyzing > the ip header is done by both as well. I would suggest you hack ipf to do > what you want if it doesnt do it already. > > Cheers > > Andrew > > On Fri, 8 Dec 2000, Alwyn Goodloe wrote: > > > We are about to begin a little project that has the following requiremnet. > > > > Perform IP packet filtering in the following way : > > > > > > i) look at an ip packet header. If some conditions are met let the packet pass > > otherwise reject the packet. you could hack your chacks into if_fw.c if they are not already supported.. what kinds of checks do you want to do? Alternatively you could use teh divert sockets to make all packets that might need filtering, up to a userland process that can do arbitrarily complicated filtering. If you want a framework with which to start, you could start with natd and strip out the address translation calls and replace them with your filtering calls. OR you could catch packets at the ethernet using netgraph and either write a loadable netgraph module that does your filtering, or passes it up to a daemon that can do arbitrary filtering. it would be easier for us to answer if you said what kind of filtering you want to do. > > > > > > ii) Look at ip packet headers of established connections and when certain > > conditions are met tear down the connection. > > > > > > Obviously this isn't the kind of thing we will be using the usual > > firewall software, at least not as I understand the software. What I > > want to know from you FreeBSD hackers is: > > > > i) if anyone has done something similar do you have any advice. > > ii) Anyone know where I should start hacking. Would it be best to try to > > hack the firewall code or the ipforwarding code.... > > > > Any such advise would be helpful. > > > > > > Alwyn Goodloe > > agoodloe@gradient.cis.upenn.edu > > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 5:38:30 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 05:38:26 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from iservern.teligent.se (mail.teligent.se [194.17.198.3]) by hub.freebsd.org (Postfix) with ESMTP id CE3A837B400 for ; Fri, 8 Dec 2000 05:38:24 -0800 (PST) Received: from blackice (dyn-office-107.teligent.se [172.18.0.107]) by iservern.teligent.se (8.8.7/8.8.7) with SMTP id OAA27930; Fri, 8 Dec 2000 14:38:19 +0100 (CET) (envelope-from wille@teligent.se) Reply-To: From: "William Carlsson - Teligent Nordic, AB - Sweden" To: "Peter Pentchev" Cc: Subject: RE: Shared Memory Date: Fri, 8 Dec 2000 14:38:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20001208145959.C451@ringworld.oblivion.bg> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FreeBSD 4+ I had something like 8192 processes in mind and same goes for max open files I'd like 256M shared memory... ---------------------------------------------------- William Carlsson Second Line Support Teligent Nordic AB P.O. Box 213 S-149 21 Nynäshamn SWEDEN Telephone: +46 - 8 - 59 99 11 92 eMail: william.carlsson@teligent.se http://www.teligent.se ---------------------------------------------------- "And then it comes to be that the soothing light at the end of your tunnel was just a freight train, comin' your way." -----Original Message----- From: Peter Pentchev [mailto:roam@orbitel.bg] Sent: den 8 december 2000 14:00 To: william.carlsson@teligent.se Cc: Mikko Tyolajarvi; freebsd-hackers@FreeBSD.ORG Subject: Re: Shared Memory On Fri, Dec 08, 2000 at 01:01:16PM +0100, William Carlsson - Teligent Nordic, AB - Sweden wrote: > Isn't all kern.* read only? > Seems like it can't be changed more than it's in theory changeable > > Something like the maximum nuber of files and processes, that is suposed to > be > soft configurable in login.conf (doesn't work either) > > ,D Does anything work in FreeBSD? ,D Uhm.. what version of FreeBSD do you have in mind? On a 4.2 I have.. [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 256 [roam@ringworld:v2 ~]$ On another console: [root@ringworld:v0 /etc]# perl -pi -e 's/maxproc=256/maxproc=512/' login.conf [root@ringworld:v0 /etc]# Logout and re-login on the first one: [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 512 [roam@ringworld:v2 ~]$ Feels quite changeable to me :) And btw - no, almost none of the kern.* sysctls are read-only. [root@ringworld:v0 /etc]# sysctl kern.coredump kern.corefile kern.syncdelay ker n.consmute kern.coredump: 1 kern.corefile: %N.core kern.syncdelay: 30 kern.consmute: 0 [root@ringworld:v0 /etc]# sysctl -w kern.coredump=0 kern.corefile='%N.CORE' ker n.syncdelay=100 kern.consmute=1 kern.coredump: 1 -> 0 kern.corefile: %N.core -> %N.CORE kern.syncdelay: 30 -> 100 kern.consmute: 0 -> 1 [root@ringworld:v0 /etc]# ..to name an (almost) random sample :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 5:56:26 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 05:56:24 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns.klondike.ru (unknown [195.170.237.2]) by hub.freebsd.org (Postfix) with ESMTP id EFD3637B400 for ; Fri, 8 Dec 2000 05:56:21 -0800 (PST) Received: from freebsd.klondike.ru (freebsd [195.170.237.64]) by ns.klondike.ru (8.9.3/8.9.3) with SMTP id QAA14326 for ; Fri, 8 Dec 2000 16:56:16 +0300 (MSK) Message-Id: <200012081356.QAA14326@ns.klondike.ru> Date: Fri, 8 Dec 2000 16:56:17 +0000 From: Kaltashkin Eugene To: freebsd-hackers@freebsd.org Subject: umodem and manual X-Mailer: stuphead version 0.4.5 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Organization: Klondike 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 Hi ppls. I try testing 3com USB modem, but don't know, how connect to him ? Maybe i can get some help about it ? ZHECKA-RIPN -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 7: 9:25 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 07:09:23 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9541437B401 for ; Fri, 8 Dec 2000 07:09:19 -0800 (PST) Received: from newsguy.com (p60-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.61]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA26018; Sat, 9 Dec 2000 00:09:15 +0900 (JST) Message-ID: <3A30D9FF.468414F2@newsguy.com> Date: Fri, 08 Dec 2000 21:54:23 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: 207.100@tj2.demon.co.uk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <3A30774E.1217F@tj2.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 207.100@tj2.demon.co.uk wrote: > > How frequently do people fsck? Well, that depends on whether I'm attached atm or not. Oh, you mean filesystems? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 7: 9:44 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 07:09:41 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 82E0A37B400 for ; Fri, 8 Dec 2000 07:09:40 -0800 (PST) Received: from newsguy.com (p60-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.61]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA26065; Sat, 9 Dec 2000 00:09:22 +0900 (JST) Message-ID: <3A30E115.CF7C76E8@newsguy.com> Date: Fri, 08 Dec 2000 22:24:37 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: David Malone Cc: Jonathan Lemon , Alfred Perlstein , Dan Kegel , hackers@FreeBSD.ORG Subject: Re: kqueue microbenchmark results References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> <20001207154925.A25785@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Malone wrote: > > On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: > > I'd love to do that, but am not quite sure how I'd go about it. > > If you read the l-k mailing list, you'll see Linus calling kqueue > > "overengineered", and what he is proposing is something that is > > definitely not well thought out. > > Maybe Alexander Viro could help? He often follows what's happening > in the BSD world and seems to do lots of good VFS type work in the > Linux world. Matt Dillon recently worked with him on the file > discriptor locking patches he committed. Why is it that I get the feeling more and more nowadays that Linus is suffering from a worsening case of NIH when it comes to things originated on BSD? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 7:15:53 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 07:15:50 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from ns.klondike.ru (unknown [195.170.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 90A3A37B401 for ; Fri, 8 Dec 2000 07:15:48 -0800 (PST) Received: from freebsd.klondike.ru (freebsd [195.170.237.64]) by ns.klondike.ru (8.9.3/8.9.3) with SMTP id SAA16086 for ; Fri, 8 Dec 2000 18:15:46 +0300 (MSK) Message-Id: <200012081515.SAA16086@ns.klondike.ru> Date: Fri, 8 Dec 2000 18:15:46 +0000 From: Kaltashkin Eugene To: freebsd-hackers@FreeBSD.ORG Subject: Re: umodem and manual In-Reply-To: <200012081356.QAA14326@ns.klondike.ru> References: <200012081356.QAA14326@ns.klondike.ru> X-Mailer: stuphead version 0.4.5 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Organization: Klondike 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 KE: I try testing 3com USB modem, but don't know, how connect to him ? KE: Maybe i can get some help about it ? I found problem (MAKEDEV create umodem0 with rw------- permissions, change it to 660) When Zyxel Omni USB modems be supported in FreeBSD kernel ? -- Best Regards ZHECKA-RIPN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 8: 2:48 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 08:02:45 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 2C4AE37B400 for ; Fri, 8 Dec 2000 08:02:45 -0800 (PST) Received: (qmail 24071 invoked by uid 1000); 8 Dec 2000 16:02:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Dec 2000 16:02:44 -0000 Date: Fri, 8 Dec 2000 10:02:44 -0600 (CST) From: Mike Silbersack To: "Chad R. Larson" Cc: mjacob@feral.com, gallatin@cs.duke.edu, ken@kdm.org, hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? In-Reply-To: <200012080707.AAA12102@freeway.dcfinc.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, 8 Dec 2000, Chad R. Larson wrote: > I'm not trying to foster a war here. There seems to be enough of > that anyway. But unless this PCI register reading thingie is an > issue for i386 boxen (and I don't think it is) we shouldn't cripple > functionality on the i386 for the Alpha. Allowing programs direct access to hardware is Windows 95's thing, though. We don't want to tread on its turf. Seriously, though. There must be some way to abuse such direct access to the pci configuration registers. Just because nobody has figured it out how yet doesn't mean that enabling the feature is a good idea. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 9:12:34 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 09:12:32 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id D0F9337B401 for ; Fri, 8 Dec 2000 09:12:31 -0800 (PST) Received: from alumni.caltech.edu ([63.201.176.178]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G59003P9DGJ2I@mta6.snfc21.pbi.net> for hackers@FreeBSD.ORG; Fri, 8 Dec 2000 08:50:44 -0800 (PST) Date: Fri, 08 Dec 2000 08:53:34 -0800 From: Dan Kegel Subject: Re: kqueue microbenchmark results Sender: dank@mta6.snfc21.pbi.net To: "Daniel C. Sobral" Cc: David Malone , Jonathan Lemon , Alfred Perlstein , hackers@FreeBSD.ORG Reply-To: dank@alumni.caltech.edu Message-id: <3A31120E.3536F07D@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> <20001207154925.A25785@walton.maths.tcd.ie> <3A30E115.CF7C76E8@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > David Malone wrote: > > > > On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: > > > I'd love to do that, but am not quite sure how I'd go about it. > > > If you read the l-k mailing list, you'll see Linus calling kqueue > > > "overengineered", and what he is proposing is something that is > > > definitely not well thought out. > > > > Maybe Alexander Viro could help? He often follows what's happening > > in the BSD world and seems to do lots of good VFS type work in the > > Linux world. Matt Dillon recently worked with him on the file > > discriptor locking patches he committed. > > Why is it that I get the feeling more and more nowadays that Linus is > suffering from a worsening case of NIH when it comes to things > originated on BSD? Don't jump to conclusions. He's honestly trying to understand what the optimal interface would be. Let him catch up. Help him understand the requirements which motivated the kqueue design and why his proposed system call does not meet them. His role right now is to keep the kernel as simple as possible. You need to prove that his proposed interface is simpler than possible :-) - Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 9:14:42 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 09:14:39 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EFEF437B400 for ; Fri, 8 Dec 2000 09:14:38 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.1/8.11.1) with SMTP id eB8HEN049163; Fri, 8 Dec 2000 12:14:24 -0500 (EST) (envelope-from arr@watson.org) Date: Fri, 8 Dec 2000 12:14:23 -0500 (EST) From: "Andrew R. Reiter" To: Alwyn Goodloe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Packet Header Filtering 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 Look at ipproto switch table... That might help you find some function pointers that would be logical to hijack in order to do this sort of thing. it's in /usr/src/sys/netinet/*.c somewhere. andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: > We are about to begin a little project that has the following requiremnet. > > Perform IP packet filtering in the following way : > > > i) look at an ip packet header. If some conditions are met let the packet pass > otherwise reject the packet. > > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. > > > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: > > i) if anyone has done something similar do you have any advice. > ii) Anyone know where I should start hacking. Would it be best to try to > hack the firewall code or the ipforwarding code.... > > Any such advise would be helpful. > > > Alwyn Goodloe > agoodloe@gradient.cis.upenn.edu > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 10:38:56 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 10:38:54 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 155E237B400 for ; Fri, 8 Dec 2000 10:38:54 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB8IcgQ20941; Fri, 8 Dec 2000 10:38:42 -0800 (PST) (envelope-from dillon) Date: Fri, 8 Dec 2000 10:38:42 -0800 (PST) From: Matt Dillon Message-Id: <200012081838.eB8IcgQ20941@earth.backplane.com> To: Josef Karthauser Cc: 207.100@tj2.demon.co.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: Optimal UFS parameters References: <3A30774E.1217F@tj2.demon.co.uk> <20001208102653.A988@bsdi.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Fri, Dec 08, 2000 at 05:53:18AM +0000, 207.100@tj2.demon.co.uk wrote: :> :> How frequently do people fsck? : :Once per reboot usually. : :Joe :-- :Josef Karthauser [joe@FreeBSD.org, joe@tao.org.uk] No, that's an fsck -p ... if the filesystem is clean, it doesn't do anything. fsck scans the filesystem only when booting after a crash. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 12: 0: 6 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 11:59:59 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C4EBA37B400; Fri, 8 Dec 2000 11:59:59 -0800 (PST) Received: from dragon.nuxi.com (Ipittythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA39714; Fri, 8 Dec 2000 11:59:58 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id eB8Jo5N81688; Fri, 8 Dec 2000 11:50:05 -0800 (PST) (envelope-from obrien) Date: Fri, 8 Dec 2000 11:50:04 -0800 From: "David O'Brien" To: "Chad R. Larson" Cc: hackers@FreeBSD.org, stable@FreeBSD.org Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Message-ID: <20001208115004.B81619@dragon.nuxi.com> Reply-To: stable@FreeBSD.org References: <200012080707.AAA12102@freeway.dcfinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012080707.AAA12102@freeway.dcfinc.com>; from chad@DCFinc.com on Fri, Dec 08, 2000 at 12:07:49AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: obrien@NUXI.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote: > I thought the space staked out by the *BSD gang was approximately > this: > NetBSD - the least amount of platform-specific code possible; run > on most anything > OpenBSD - pro-active security, bullet-proof from attacks > FreeBSD - best performing on the Intel PC platform s/the Intel PC/server/ The Alpha has very good I/O bandwidth and 64-bit address space. Thus it fits our niche. You also mentioned Sparc, but really should have said sparc64(pci based). hopefully embeded soon too. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 14:14:20 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 14:14:17 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lh04.opsion.fr (lh04.opsion.fr [212.73.208.230]) by hub.freebsd.org (Postfix) with SMTP id EE14937B400 for ; Fri, 8 Dec 2000 14:14:16 -0800 (PST) Received: from 198.168.78.67 [198.168.78.67] by lh04.opsion.fr; Fri, 8 Dec 2000 22:13:19 GMT From: Thierry Reply-To: tjmsdn@ifrance.com To: freebsd-hackers@freebsd.org Subject: PPP connection Date: Fri, 8 Dec 2000 17:14:30 -0500 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00120817171600.00320@FreeBSD.eicon.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm trying to use kppp with freeBSD, but when I want to connect, My modem dials, ID and the password are accepted, and I receive a message : pppd 2.3.5 started by root, uid 0 Connect: ppp0 <--> /dev/modem Modem hangup, connected for 1 minutes Connection terminated, connected for 1 minutes and the modem port is closed. and kppp print in a dialog "Logging on to Network..." Can you help me ? Thank in advance. Thierry Jonas. ______________________________________________________________________________ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 15: 8: 0 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 15:07:58 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from beamail.beasys.com (unknown [63.96.163.38]) by hub.freebsd.org (Postfix) with ESMTP id E847937B6C4 for ; Fri, 8 Dec 2000 15:02:23 -0800 (PST) Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA16754; Fri, 8 Dec 2000 15:02:23 -0800 (PST) Received: from ashbury.weblogic.com (ashbury.beasys.com [172.17.8.3]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id PAA06253; Fri, 8 Dec 2000 15:02:29 -0800 (PST) Received: from beasys.com ([192.168.53.2]) by ashbury.weblogic.com (Post.Office MTA v3.5.3 release 223 ID# 0-53833U200L200S0V35) with ESMTP id com; Fri, 8 Dec 2000 15:22:36 -0800 Message-ID: <3A316753.1B81EC84@beasys.com> Date: Fri, 08 Dec 2000 15:57:23 -0700 From: garya@bea.com (Gary Aitken) Organization: BEA WebXpress X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tjmsdn@ifrance.com Cc: freebsd-hackers@freebsd.org Subject: Re: PPP connection References: <00120817171600.00320@FreeBSD.eicon.com> 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 only used kernel ppp for a dedicated line, and there wasn't any user authentication required in that case, so I'm probably not much help... What does your /etc/ppp/options file look like, and the associated /etc/ppp/pap-secrets and /etc/ppp/chap-secrets? What kind of authentication is the machine you are connecting to set up to use? (If it's simply prompting for a username & password, that's pap). You might add the "debug" option to your options file and check the logs in /var/log. Thierry wrote: > I'm trying to use kppp with freeBSD, but when I want to connect, > > My modem dials, ID and the password are accepted, > > and I receive a message : > > pppd 2.3.5 started by root, uid 0 > Connect: ppp0 <--> /dev/modem > Modem hangup, connected for 1 minutes > Connection terminated, connected for 1 minutes > > and the modem port is closed. > > and kppp print in a dialog "Logging on to Network..." > > Can you help me ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 15:16:14 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 15:16:12 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from beamail.beasys.com (unknown [63.96.163.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CAB537B400 for ; Fri, 8 Dec 2000 15:16:12 -0800 (PST) Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA18828; Fri, 8 Dec 2000 15:16:12 -0800 (PST) Received: from ashbury.weblogic.com (ashbury.beasys.com [172.17.8.3]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id PAA13784; Fri, 8 Dec 2000 15:16:19 -0800 (PST) Received: from beasys.com ([192.168.53.2]) by ashbury.weblogic.com (Post.Office MTA v3.5.3 release 223 ID# 0-53833U200L200S0V35) with ESMTP id com; Fri, 8 Dec 2000 15:36:26 -0800 Message-ID: <3A316A90.7B718DF4@beasys.com> Date: Fri, 08 Dec 2000 16:11:12 -0700 From: garya@bea.com (Gary Aitken) Organization: BEA WebXpress X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tjmsdn@ifrance.com Cc: freebsd-hackers@freebsd.org Subject: Re: PPP connection References: <00120817171600.00320@FreeBSD.eicon.com> <3A316753.1B81EC84@beasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Forget this; I didn't read your message closely. I see now that the authentication passed. Gary Aitken wrote: > > I've only used kernel ppp for a dedicated line, > and there wasn't any user authentication required in that case, > so I'm probably not much help... > What does your /etc/ppp/options file look like, > and the associated /etc/ppp/pap-secrets and /etc/ppp/chap-secrets? > What kind of authentication is the machine you are connecting to set up to use? > (If it's simply prompting for a username & password, that's pap). > > You might add the "debug" option to your options file and check the logs > in /var/log. > > Thierry wrote: > > > I'm trying to use kppp with freeBSD, but when I want to connect, > > > > My modem dials, ID and the password are accepted, > > > > and I receive a message : > > > > pppd 2.3.5 started by root, uid 0 > > Connect: ppp0 <--> /dev/modem > > Modem hangup, connected for 1 minutes > > Connection terminated, connected for 1 minutes > > > > and the modem port is closed. > > > > and kppp print in a dialog "Logging on to Network..." > > > > Can you help me ? > > 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 Dec 8 15:29:57 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 15:29:53 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by hub.freebsd.org (Postfix) with ESMTP id 2957A37B400; Fri, 8 Dec 2000 15:29:53 -0800 (PST) Received: from Gatekeeper.FreeBSD.org (koln-3e366334.pool.mediaWays.net [62.54.99.52]) by sender.ngi.de (Postfix) with ESMTP id 48E0F96D39; Sat, 9 Dec 2000 00:22:50 +0100 (CET) Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 7C4D0C; Fri, 8 Dec 2000 23:40:39 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id E8308D93; Fri, 8 Dec 2000 23:41:14 +0100 (CET) Date: Fri, 8 Dec 2000 23:41:14 +0100 From: Stefan Esser To: Mike Silbersack Cc: "Chad R. Larson" , mjacob@feral.com, gallatin@cs.duke.edu, ken@kdm.org, hackers@FreeBSD.ORG, stable@FreeBSD.ORG, Stefan Esser Subject: Re: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Message-ID: <20001208234114.A1638@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser Mail-Followup-To: Stefan Esser , Mike Silbersack , "Chad R. Larson" , mjacob@feral.com, gallatin@cs.duke.edu, ken@kdm.org, hackers@FreeBSD.ORG, stable@FreeBSD.ORG References: <200012080707.AAA12102@freeway.dcfinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Fri, Dec 08, 2000 at 10:02:44AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-12-08 10:02 -0600, Mike Silbersack wrote: > Seriously, though. There must be some way to abuse such direct access to > the pci configuration registers. Just because nobody has figured it out > how yet doesn't mean that enabling the feature is a good idea. Well, what makes you think, that nobody has figured out why read access to the pci config space registers might not be a good idea ? ;-) The reason is simple: There are a number of PCI devices that fail in a number of ways, if certain config space registers are accessed while the device is active. This is counterintuitive at first, but just try to read a config register beyond 0x80 from an NCR SCSI chip while it is executing SCRIPTS code ... The PCI spec made higher numbered config space registers implementation dependent. Some vendors mapped their devices' operational registers into config space, even though the spec never encouraged that (though I'm not sure that such an (ab)use of config registers was declared forbidden in later revisions of the spec.). Since there are a number of devices that could be severely impacted by read accesses to configuration space registers, we can't safely permit any user such read access. Root hopefully knows what he is doing and only accesses such registers that are meant to be accessed while the device is operating ... Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 16:29:28 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 16:29:26 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by hub.freebsd.org (Postfix) with ESMTP id 90CF637B400 for ; Fri, 8 Dec 2000 16:29:26 -0800 (PST) Received: from bleep.craftncomp.com (cs2777-167.houston.rr.com [24.27.77.167]) by sm10.texas.rr.com (8.11.0/8.11.1) with ESMTP id eB90R9Q30847 for ; Fri, 8 Dec 2000 18:27:10 -0600 Received: from bloop.craftncomp.com (bloop.craftncomp.com [202.12.111.1]) by bleep.craftncomp.com (8.11.0/8.9.3) with ESMTP id eB90TFG16544 for ; Fri, 8 Dec 2000 18:29:15 -0600 (CST) (envelope-from shocking@houston.rr.com) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by bloop.craftncomp.com (8.11.0/8.9.3) with ESMTP id eB90TQG48955 for ; Fri, 8 Dec 2000 18:29:26 -0600 (CST) (envelope-from shocking@bloop.craftncomp.com) Message-Id: <200012090029.eB90TQG48955@bloop.craftncomp.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: hackers@freebsd.org Subject: GDB Displaying all vars in a stack frame. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Dec 2000 18:29:26 -0600 From: Stephen Hocking Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there some simple one-liner command that allows me to display the values of all the variables within the current stack frame? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 16:52:39 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 16:52:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 6BD7437B400 for ; Fri, 8 Dec 2000 16:52:37 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id CDF596AB68; Sat, 9 Dec 2000 11:22:34 +1030 (CST) Date: Sat, 9 Dec 2000 11:22:34 +1030 From: Greg Lehey To: Stephen Hocking Cc: hackers@freebsd.org Subject: Re: GDB Displaying all vars in a stack frame. Message-ID: <20001209112234.H53111@wantadilla.lemis.com> References: <200012090029.eB90TQG48955@bloop.craftncomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012090029.eB90TQG48955@bloop.craftncomp.com>; from shocking@houston.rr.com on Fri, Dec 08, 2000 at 06:29:26PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 8 December 2000 at 18:29:26 -0600, Stephen Hocking wrote: > Is there some simple one-liner command that allows me to display the values of > all the variables within the current stack frame? info local Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 16:53: 0 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 16:52:58 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id ACC0D37B400 for ; Fri, 8 Dec 2000 16:52:58 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eB90qH771032; Fri, 8 Dec 2000 16:52:17 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200012090029.eB90TQG48955@bloop.craftncomp.com> Date: Fri, 08 Dec 2000 16:53:06 -0800 (PST) From: John Baldwin To: Stephen Hocking Subject: RE: GDB Displaying all vars in a stack frame. Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Dec-00 Stephen Hocking wrote: > Is there some simple one-liner command that allows me to display the values > of > all the variables within the current stack frame? 'info locals' I think, or 'show locals' if that doesn't work.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 22: 2:57 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 22:02:55 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 01DE237B400 for ; Fri, 8 Dec 2000 22:02:55 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 144d95-0000CE-00; Fri, 08 Dec 2000 23:06:07 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A31CBCF.B8E21E1B@softweyr.com> Date: Fri, 08 Dec 2000 23:06:07 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: dank@alumni.caltech.edu Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: kqueue microbenchmark results References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> <20001207154925.A25785@walton.maths.tcd.ie> <3A30E115.CF7C76E8@newsguy.com> <3A31120E.3536F07D@alumni.caltech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Kegel wrote: > > "Daniel C. Sobral" wrote: > > > > Why is it that I get the feeling more and more nowadays that Linus is > > suffering from a worsening case of NIH when it comes to things > > originated on BSD? > > Don't jump to conclusions. He's honestly trying to > understand what the optimal interface would be. > Let him catch up. Help him understand the requirements > which motivated the kqueue design and why his proposed > system call does not meet them. > > His role right now is to keep the kernel as simple as possible. So the major advancements of pushing file servers and web servers into the kernel fit into this role how? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 22:13:17 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 22:13:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A089D37B400 for ; Fri, 8 Dec 2000 22:13:14 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB96DCs54467 for ; Fri, 8 Dec 2000 23:13:13 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA18688 for ; Fri, 8 Dec 2000 23:13:12 -0700 (MST) Message-Id: <200012090613.XAA18688@harmony.village.org> To: hackers@freebsd.org Subject: Partial start on pci + serial/parallel cards Date: Fri, 08 Dec 2000 23:13:12 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. I have a partial start on the serial/parallel cards. It isn't attaching anything yet, but should give people an idea on the direction I'd like to head. As part of this work, I'll likely remove pci attachment of sio, and change it to puc. puc is the name NetBSD uses (I snagged the tables and some code from NetBSD's puc driver, btw) so I kept using it. I'll also need to add puc attachments to sio and ppc drivers. I'll also need to add the bus resource allocations stuff so that the client drivers can just use bus resource 0, ala isa. I think that Matt Dodd's recent work makes this relatively easy, but haven't had a chance to look at that closely. Again, this is preliminary and posted for commentary only. I wanted to get this out. http://people.freebsd.org/~imp/puc.tar.gz Comments and patches welcome. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 22:49:41 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 22:49:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id E01D637B400 for ; Fri, 8 Dec 2000 22:49:38 -0800 (PST) Received: from alumni.caltech.edu ([63.201.176.178]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G5A008AEFUJMD@mta5.snfc21.pbi.net> for hackers@FreeBSD.ORG; Fri, 8 Dec 2000 22:39:56 -0800 (PST) Date: Fri, 08 Dec 2000 22:42:25 -0800 From: Dan Kegel Subject: Re: kqueue microbenchmark results Sender: dank@mta5.snfc21.pbi.net To: Wes Peters Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG Reply-To: dank@alumni.caltech.edu Message-id: <3A31D451.CD333721@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> <20001207154925.A25785@walton.maths.tcd.ie> <3A30E115.CF7C76E8@newsguy.com> <3A31120E.3536F07D@alumni.caltech.edu> <3A31CBCF.B8E21E1B@softweyr.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > Dan Kegel wrote: > > "Daniel C. Sobral" wrote: > > > Why is it that I get the feeling more and more nowadays that Linus is > > > suffering from a worsening case of NIH when it comes to things > > > originated on BSD? > > > > Don't jump to conclusions. He's honestly trying to > > understand what the optimal interface would be. > > Let him catch up. Help him understand the requirements > > which motivated the kqueue design and why his proposed > > system call does not meet them. > > > > His role right now is to keep the kernel as simple as possible. > > So the major advancements of pushing file servers and web servers into > the kernel fit into this role how? Regardless of whether those complicate the kernel - and I suspect khttpd and tux don't complicate the kernel much - what Linus is doing here is different: he's doing a reductionist analysis of what it takes to do poll() right. I've done the same thing before, and yes, the people whose favorite interface I seemed to be ignoring were pissed off. But it was the only way for me to understand the true requirements. In the end, I usually add back part of the stuff I initially stripped out, once I understood what it was for. That said, I like kqueue, and I don't like the interface Linus proposed. But I'm still not quite sure how to demonstrate that his interface won't do the job. (Wish I had time.) - Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Dec 8 23:31: 3 2000 From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 8 23:31:01 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from tetsuo.zabbo.net (tetsuo.zabbo.net [204.138.55.44]) by hub.freebsd.org (Postfix) with ESMTP id E641837B400 for ; Fri, 8 Dec 2000 23:31:00 -0800 (PST) Received: by tetsuo.zabbo.net (Postfix, from userid 500) id A931117821C; Sat, 9 Dec 2000 02:30:50 -0500 (EST) Date: Sat, 9 Dec 2000 02:30:50 -0500 From: Zach Brown To: Wes Peters Cc: dank@alumni.caltech.edu, "Daniel C. Sobral" , hackers@FreeBSD.ORG Subject: Re: kqueue microbenchmark results Message-ID: <20001209023050.B30968@tetsuo.zabbo.net> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025115457.X28123@fw.wintelcom.net> <20001025170117.C87091@prism.flugsvamp.com> <20001207154925.A25785@walton.maths.tcd.ie> <3A30E115.CF7C76E8@newsguy.com> <3A31120E.3536F07D@alumni.caltech.edu> <3A31CBCF.B8E21E1B@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A31CBCF.B8E21E1B@softweyr.com>; from wes@softweyr.com on Fri, Dec 08, 2000 at 11:06:07PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 08, 2000 at 11:06:07PM -0700, Wes Peters wrote: > Dan Kegel wrote: > > > > His role right now is to keep the kernel as simple as possible. > > So the major advancements of pushing file servers and web servers into > the kernel fit into this role how? totally orthoganal to the `linus thinks bsd has cooties' "discussion", but I'll take a stab at shedding some light. as we're veering wildy off-topic for -hackers, I'll be brief. the few people who may actually care can email me off list for more info. as dan mentioned, khttpd added no complexity at all to the 'core kernel'. That is, it added no controversial APIs that have to be maintained over time, etc. Thats simply because it was a lame hack of moving a wimpy static http responder into kernel threads :) tux, being a much more interesting design, messes with all sorts of stuff. Most notably it added working "zero copy" tcp and lots of SMP scalability fixes. getting damn-near-linear performance inprovements as cpu and interfaces are added is definitely interesting, if not even remotely useful for 99% of the userbase. Ingo did it as an intial exploratory implementation. It served its role, current more careful "zero copy" development is branched from early tux code. so anyway, the trend isn't to push servers into the kernel. khttpd was put in because it was of no risk to Linus and ended up acting as motivation to do it right, if its going to be done at all. Doing it then showed the possible gains which are now being folded into proper APIs that userland servers will be able to use. (dunno if kiofd and such interfaces have been discussed in public yet, I know they've been babbled about at conferences. think splice meets iolite, using fds rather than new syscalls and without the VM tricks..) -- zach To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 6:16:44 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 06:16:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (unknown [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id B835637B400 for ; Sat, 9 Dec 2000 06:16:41 -0800 (PST) Received: (from jgreco@localhost) by aurora.sol.net (8.9.3/8.9.2/SNNS-1.02) id IAA61771; Sat, 9 Dec 2000 08:16:39 -0600 (CST) From: Joe Greco Message-Id: <200012091416.IAA61771@aurora.sol.net> Subject: Re: Optimal UFS parameters To: hackers@freebsd.org Date: Sat, 9 Dec 2000 08:16:39 -0600 (CST) Cc: dillon@earth.backplane.com, phk@critter.freebsd.dk In-Reply-To: <200012090354.VAA15571@earth.execpc.com> from "jgreco@execpc.com" at Dec 08, 2000 09:54:53 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: jgreco@aurora.sol.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :In message <200012070821.eB78LeQ07926@earth.backplane.com> Matt Dillon writes: > :: : -b 16384 -f 4096 -c 159 > :: I think Bruce swears by 4K (page-sized) fragments. Not a bad > :: way to go. I use 2K because I (and others) put in so much hard work > :: to fix all the little niggling bugs in the VM system related to partial > :: page validation and, damn it, I intend to use those features! > : > :At the other end of the spectrum, 32M [sic] and 64M [sic] disks work > :well with > : -b 4096 -f 512 -c 10 > : > :But I tend to do what phk has done with the large -c flags on my > :insanely-sized, rediculously-cheap XXG IDE drives. > : > :Warner > > Well, too-large a C/G will result in greater file fragmentation, > because FFS can't manage the file layouts in the cylinder groups > as well. The default of 16 is definitely too little. 100+ is probably > too much. Something in the middle will be about right. > > The fragmentation value returned by fsck would be an interesting number > to publish. 'fsck -n /dev/...' on an idle fs (you don't have to unmount > it). Anything over 3% fragmentation is a problem. Something like > /usr will typically be in the 1-3% range. A large partition that is > still half empty should be in the 0.0-0.5% range. > > A combination of a larger C/G (meaning fewer groups on the disk) > and fewer inodes (a higher -i value) will dramatically decrease fsck > times. After a certain point, though, continuing to increase C/G will not > effect the fsck times. So. Previously, FreeBSD had various issues with larger block and fragment sizes - I think Matt was the guy who told me this. A larger B/F size also allows a larger C/G, so I'm wondering if this is still true (both for FreeBSD 3.5 stable and 4.2 stable). Comments? -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 7:57: 8 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 07:57:06 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by hub.freebsd.org (Postfix) with ESMTP id 452AC37B400; Sat, 9 Dec 2000 07:57:06 -0800 (PST) Received: from Gatekeeper.FreeBSD.org (koln-3e3664ad.pool.mediaWays.net [62.54.100.173]) by sender.ngi.de (Postfix) with ESMTP id 0F7B696D4C; Sat, 9 Dec 2000 16:49:53 +0100 (CET) Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 5ED15C; Sat, 9 Dec 2000 14:20:55 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 5DECDDAD; Sat, 9 Dec 2000 14:21:32 +0100 (CET) Date: Sat, 9 Dec 2000 14:21:32 +0100 From: Stefan Esser To: Guy Harris Cc: Matt Dillon , Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.ORG, tech@openbsd.org, Stefan Esser Subject: Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001209142132.A822@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207233958.C352@quadrajet.flashcom.com> <20001208003839.A352@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001208003839.A352@quadrajet.flashcom.com>; from gharris@flashcom.net on Fri, Dec 08, 2000 at 12:38:39AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-12-08 00:38 -0800, Guy Harris wrote: > (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB > in the top of the CVS tree; NetBSD still has it as 32K.) You can change both the default and maximum BPF buffer sizes at run time (affecting an subsequent open()) in FreeBSD: # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 makes the default buffer size 32K and limits the size to 4MB, for example. There were further changes to the BPF kernel code suggested by the NFR folks, which do not seem to have made it into FreeBSD, though. The original patches were for FreeBSD-2.2.x, I ported them to 3.x, but there have been many changes to bpf.c since then ... I can dig out the old patch and accompanying rationale, if anybody is interested, since it has been removed from the NFR download area. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 9:18:43 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 09:18:38 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fep21-svc.tin.it (mta21-acc.tin.it [212.216.176.74]) by hub.freebsd.org (Postfix) with ESMTP id B8DE337B69E for ; Sat, 9 Dec 2000 09:18:35 -0800 (PST) Received: from lorix ([213.45.186.120]) by fep21-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001209171830.JYDX9573.fep21-svc.tin.it@lorix>; Sat, 9 Dec 2000 18:18:30 +0100 Message-ID: <001001c06203$db84a0a0$016464c8@lorix> From: "Loris Degioanni" To: "Dragos Ruiu" , , , , , References: <0012072118150Q.09615@smp.kyx.net> Subject: R: [Ethereal-dev] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Date: Sat, 9 Dec 2000 18:10:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I am quite astonished by the interest aroused by our tests a year after = their publication on the web. We (the Italians, i.e. the network group = of the Politecnico di Torino) performed these tests in November 1999 in = order to obtain quantitative results for my graduation thesis that was = focused on the development of WinPcap. Since, as far as I know, BPF is = the best public capture device in the Unix world, we used the latest = freebsd distribution of that period (3.3) and compared the results = obtained. Since then, we never updated that page. I know that freebsd = and its BPF implementation have been updated meanwhile, but winpcap as = well has been improved and optimized. This means that the results are = outdated, but the comparison is acceptable, because it takes in = consideration the best implementations of that period. FYI, we have done = other tests in September 2000 comparing the new WinPcap 2.1 with BPF = under freebsd 4.1, and the results were quite interesting, but I will = speak of this later. Our goal was to create a suite of tests able to: - measure the performance of the various components (although this is = difficult because of the impossibility to isolate each component from = interacting one with the others and with the OS). - measure capture performance "as a whole", from the NIC to the hard = disk. I know perfectly that the second point involves measuring the = performance of the whole operating system, and not only of the capture = driver, but we included it because (as we wrote commenting the tests) in = our opinion it is the most interesting from the end-user standpoint. I = know also that better capture performance can be obtained tuning the OS = (eliminating the unnecessary protocol stacks, setting bigger buffers, = choosing a fast file system for the dumps, etc), but we were interested = in measuring the usage that the standard tcpdump/windump user makes of = these tools, so we installed a fresh win2k professional and a fresh = freebsd on the same disk of a P2 400 and launched the tests without = modifying anything. In my opinion, those tests demonstrate that: - BPF for freebsd 3.3 is more efficient in the CPU usage. On the other = side, winpcap 2.02 is more responsive, because it delivers the packets = to userland as soon as the application is ready to receive them. Both = the problems have been solved by recent releases: BPF now has an = 'immediate mode' that can be used to pass the packets to user-mode = without the need to fill the hold buffer, winpcap has the 'delayed = write' capability that optimizes the CPU usage. - The filtering and pre-filtering process has about the same impact in = Windows and freebsd. However, since the Win32 version of the BPF virtual = processor is nearly identical to the original, the Windows kernels (and = in particular the one of win NTx) seem sensibly faster in the = pre-filtering (interrupt+dma(or equivalent)+nic driver), in particular = when al lot of packets are discarded by the BPF filter. This was very = surprising for us when we performed the test, because comparing the = linear and elegant implementation of the bsd networking with the = enormous and complex NDIS we expected exactly the opposite situation. = However our recent tests seems to confirm this situation. I think I have = an explanation for this, and I will write about it only if somebody is = interested. - When the packets are dumped to disk, the file system plays a very = important role. This is quite obvious. Notice for example that, = according to our tests, a fat32 partition under Windows 2k is able to = save 15-20% more packets than a NFTS partition of the same disk: fat is = a very poor file system, but for this reason it is very fast, and not = only in Windows. However, Win2k seems to have a very efficient storage = management. In my opinion, the block size of the stdio library is not = the only parameter that influences the dump perormance. Don't forget = that the data that tcpdump saves to disk is already buffered by libpcap = (with a 32k buffer in bsd and a 256k buffer in win), so a further = buffering is not so essential. FS kernel-level cache (that in Win2k is = quite large) is very important too, because it is the last buffer before = the physical write. Moreover, the method used by the application to save = the data has to be taken in consideration: libpcap requires = pcap_dispatch() to be invoked for every saved packet, and is able to = save with pcap_dump() only a packet at a time. This is very inefficient, = because requires a lot of cpu and doesn't make a good use of the libpcap = packet buffer. In my opinion, a pcap_write() function able to directly = save the content of the packet buffer would be noticeably faster. Now, some words on our new tests. We performed them in order to measure = the performance of the new version of winpcap (2.1) that currently is in = beta on our web site. We compared it to BPF for freebsd 4.1, trying to = obtain more accurate and objective results. In particular, we saved = every dump (under Win98,Win2k and freebsd) on the same fat32 partition, = and tested tcpdump also with a kernel-buffer size of 2*512K. Moreover, = we stressed the capture architectures with a more sustained traffic = (until 83kpps). I don't attach the results to this message because they = are in an 88k excel file, but I have not problems to send them to the = people interested. They show that the cpu performance of winpcap for winNTx is now = comparable with the one of freebsd and that freebsd has still lower dump = performance, but saving on fat32 it is able to obtain better results and = in a case (22000 500bytes packets per second) it is better than win2k. = The really strange thing is that BPF seems not to perform noticeably = better if a 1 megabyte buffer is used instead of the standard 64k = buffer, and in some cases the 32k buffer performs even better. I wrote a = message to the tcpdump mailing list = (http://www.tcpdump.org/lists/workers/2000/msg01135.html) to ask about = this behaviour, but I obtained no satisfactory answer. Finally, I would like to say that since I know we can't be considered = very impartial, we would like to see other tests and evaluations on this = subject, because we think it is a very important matter. We had to make = a comparison with bpf because we didn't find any quantitative value on = this subject before. If anyone obtained different results, please let us = know. Loris. From: Dragos Ruiu To : ; ; = ; ; = Subject: [Ethereal-dev] Fwd: kyxtech: freebsd outsniffed by wintendo = !!?!? >=20 > (Hurm.... Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-)=20 > Comments? Other OS numbers: more recent=20 > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down.... --dr :-) >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 12:41:38 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 12:41:36 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by hub.freebsd.org (Postfix) with ESMTP id 6B2CC37B400 for ; Sat, 9 Dec 2000 12:41:34 -0800 (PST) Received: from hermes.tue.nl (hermes.tue.nl [131.155.2.46]) by mailhost.tue.nl (8.11.0/8.11.0) with ESMTP id eB9KfXx20835 for ; Sat, 9 Dec 2000 21:41:33 +0100 (MET) Received: from deathstar (t-27-122.athome.tue.nl [131.155.228.122]) by hermes.tue.nl (Postfix) with ESMTP id B4C372E802 for ; Sat, 9 Dec 2000 21:41:32 +0100 (CET) From: "Marco van de Voort" To: hackers@freebsd.org Date: Sat, 9 Dec 2000 21:41:35 +0100 Subject: Text console programming on a low level. Message-ID: <3A32A70F.20316.23C44FD@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: marcov@toad.stack.nl Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've ported a Linux app, but am still having some problems with a fullscreen textmode editor to work with FreeBSD consoles. (I already use NCurses, but I don't think I'm doing it right) The problems are many: - Codepages. Is there anyway to force cp437, for linedrawing? (or even better on the phys console, work in 512 character font mode, saving the original font) The fact that Midnight Commander doesn't use all linedrawing chars is worrying :-) - Keyboard. mainly the extended keys. (alt, ctrl, F-keys) - Mouse support (console, xterm) Of course I want it to work on as many consoles as possible, but for now standard telnet between PCs (FreeBSD and Linux standard clients + some win32 clients like putty and dtelnet) The win32 clients are already working quite right, and I can even get the Linux and FreeBSD clients to work (by killing off some code for the linux console) However the physical (the default one from FreeBSD 4.2 btw, I assume it is syscons) console hardly does anything. When I set the terminal to one of the vtxxx terminals I can get some life out of it, but cons25 totally messes up. Are there some ((Free)BSD specific) docs about this? Or other "really" fullscreen textconsole programs (so with extended keys, mouse and codepage support) as examples? I already went through Ncurses docs, but those are more generic in nature. Marco van de Voort (MarcoV@Stack.nl or marco@freepascal.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 16: 2:49 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 16:02:47 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by hub.freebsd.org (Postfix) with ESMTP id 967AD37B400 for ; Sat, 9 Dec 2000 16:02:45 -0800 (PST) Received: from hppav ([62.255.229.185]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20001210000236.RJHY22403.mta03-svc.ntlworld.com@hppav> for ; Sun, 10 Dec 2000 00:02:36 +0000 Message-ID: <000a01c0623c$93f2da20$b9e5ff3e@hppav> Reply-To: "n.posnett" From: "n.posnett" To: Subject: how? Date: Sun, 10 Dec 2000 00:02:58 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0623C.8DF55800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0623C.8DF55800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable my friend has already cracked his download. he won't tell me how.give us = an idea.cheers pozz=20 ------=_NextPart_000_0007_01C0623C.8DF55800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

my friend has already cracked his = download. he=20 won't tell me how.give us an idea.cheers = pozz 
------=_NextPart_000_0007_01C0623C.8DF55800-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 16:12:23 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 16:12:21 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mail.theinternet.com.au (zeus.theinternet.com.au [203.34.176.2]) by hub.freebsd.org (Postfix) with ESMTP id D150037B400 for ; Sat, 9 Dec 2000 16:12:18 -0800 (PST) Received: (from akm@localhost) by mail.theinternet.com.au (8.9.3/8.9.3) id KAA60949; Sun, 10 Dec 2000 10:13:26 +1000 (EST) (envelope-from akm) Date: Sun, 10 Dec 2000 10:13:25 +1000 From: Andrew Kenneth Milton To: "n.posnett" Cc: hackers@FreeBSD.ORG Subject: Re: how? Message-ID: <20001210101325.D2979@zeus.theinternet.com.au> References: <000a01c0623c$93f2da20$b9e5ff3e@hppav> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <000a01c0623c$93f2da20$b9e5ff3e@hppav>; from n.posnett on Sun, Dec 10, 2000 at 12:02:58AM -0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG +-------[ n.posnett ]---------------------- | my friend has already cracked his download. he won't tell me how.give | us an idea.cheers pozz He should seek medical advice if he has cracked his download. He wouldn't want to end up sterile. I'm sure when you're older and your flexibility is lower you'll crack your download too. Your friend is probably embarrassed about his injury that's why he won't tell you how he did it. Finally, this is freebsd-hackers not freebsd-crackers, please address your email to the correct list. You might want to check the mailling lists to see that you get the one you really want at; http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL Good Luck removing yourself from the gene pool. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Dec 9 18:48:57 2000 From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 9 18:48:54 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by hub.freebsd.org (Postfix) with ESMTP id 5D01537B401; Sat, 9 Dec 2000 18:48:53 -0800 (PST) Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA27058; Sat, 9 Dec 2000 22:17:08 -0500 (EST) Received: by sandelman.ottawa.on.ca (8.11.0/8.11.0) id eBA2Ee203226; Sat, 9 Dec 2000 21:14:40 -0500 (EST) Received: from sender.ngi.de (sender.ngi.de [212.79.47.18]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id LAA20667 for ; Sat, 9 Dec 2000 11:26:33 -0500 (EST) Received: from Gatekeeper.FreeBSD.org (koln-3e3664ad.pool.mediaWays.net [62.54.100.173]) by sender.ngi.de (Postfix) with ESMTP id 0F7B696D4C; Sat, 9 Dec 2000 16:49:53 +0100 (CET) Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 5ED15C; Sat, 9 Dec 2000 14:20:55 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 5DECDDAD; Sat, 9 Dec 2000 14:21:32 +0100 (CET) Date: Sat, 9 Dec 2000 14:21:32 +0100 From: Stefan Esser To: Guy Harris Cc: Matt Dillon , Dragos Ruiu , tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@FreeBSD.org, tech@openbsd.org, Stefan Esser Subject: Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <20001209142132.A822@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser References: <0012072118150Q.09615@smp.kyx.net> <200012080547.eB85lKc17216@earth.backplane.com> <20001207233958.C352@quadrajet.flashcom.com> <20001208003839.A352@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001208003839.A352@quadrajet.flashcom.com>; from gharris@flashcom.net on Fri, Dec 08, 2000 at 12:38:39AM -0800 Sender: mcr@sandelman.ottawa.on.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-12-08 00:38 -0800, Guy Harris wrote: > (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB > in the top of the CVS tree; NetBSD still has it as 32K.) You can change both the default and maximum BPF buffer sizes at run time (affecting an subsequent open()) in FreeBSD: # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 makes the default buffer size 32K and limits the size to 4MB, for example. There were further changes to the BPF kernel code suggested by the NFR folks, which do not seem to have made it into FreeBSD, though. The original patches were for FreeBSD-2.2.x, I ported them to 3.x, but there have been many changes to bpf.c since then ... I can dig out the old patch and accompanying rationale, if anybody is interested, since it has been removed from the NFR download area. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message